You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a red phase introduces a new test file containing several tests, the first suite run yields not_found for the declared target plus a multiple_new_tests event, and adoption takes additional advance round-trips (target_named_by_agent, re-run, adopt). Each round-trip is a full suite run.
On fast JS/Python suites this is a nuisance. On slow suites (device/simulator-backed XCTest, Gradle instrumentation) it is expensive: observed in a real agent-driven run, cycle 1 burned five AWAITING_TEST suite runs before the target was adopted — several minutes of simulator time to establish an id the tool arguably had enough information to resolve on run one.
Compiled targets add a variant: a brand-new test class fails compilation, the first run is not_collected, and the stub-directive path adds another round-trip before the test can even be seen.
Proposal
On the first run where the declared target is not_found but the diff-vs-run-start collection shows new tests, attempt adoption immediately within the same advance: if exactly one new test matches the declared target after normalisation (advance: normalise describe/test id separator so a formatting-only difference is not a declared_test_mismatch #57), or if the declared target unambiguously corresponds to one of the new tests (same file, closest name), adopt it and evaluate the red verdict from the run that already happened — no extra suite run.
Only fall back to the ask-the-agent round-trip when the mapping is genuinely ambiguous (several new tests, none matching).
For the not_collected compile-failure case, consider allowing the red phase to accept "new target's file fails to compile referencing a missing symbol" as the red evidence directly, instead of requiring a stub round-trip first.
An xfail-batch operating mode (proposed separately) would eliminate this class entirely for plans that use it, since all targets exist from the authoring cycle; this issue covers classic mode.
Task file:
tasks/issue-72-adopt-on-first-run.mdProblem
When a red phase introduces a new test file containing several tests, the first suite run yields
not_foundfor the declared target plus amultiple_new_testsevent, and adoption takes additional advance round-trips (target_named_by_agent, re-run, adopt). Each round-trip is a full suite run.On fast JS/Python suites this is a nuisance. On slow suites (device/simulator-backed XCTest, Gradle instrumentation) it is expensive: observed in a real agent-driven run, cycle 1 burned five AWAITING_TEST suite runs before the target was adopted — several minutes of simulator time to establish an id the tool arguably had enough information to resolve on run one.
Compiled targets add a variant: a brand-new test class fails compilation, the first run is
not_collected, and the stub-directive path adds another round-trip before the test can even be seen.Proposal
not_foundbut the diff-vs-run-start collection shows new tests, attempt adoption immediately within the same advance: if exactly one new test matches the declared target after normalisation (advance: normalise describe/test id separator so a formatting-only difference is not a declared_test_mismatch #57), or if the declared target unambiguously corresponds to one of the new tests (same file, closest name), adopt it and evaluate the red verdict from the run that already happened — no extra suite run.not_collectedcompile-failure case, consider allowing the red phase to accept "new target's file fails to compile referencing a missing symbol" as the red evidence directly, instead of requiring a stub round-trip first.An
xfail-batchoperating mode (proposed separately) would eliminate this class entirely for plans that use it, since all targets exist from the authoring cycle; this issue covers classic mode.