The test bed and injection suite are built and validated. The first measurement column — claude-sonnet-5 — was collected 12 Aug. The next piece of work is the cross-repo loop design (T6).
Landed 10 Aug.
Read the workspace mode end to end, inventoried every blocker it can report.
Docker bed built and instrumented. Injection suite validated — four controls plus a standing probe. First measurement campaign ran 12 Aug.
32 stop sites, each classified by whether it lacks permission or information — the stops are driven by permission gaps, not missing facts. The campaign added one more entry — a stop can be evaded by rewriting the record it checks against.
Made optional by T4. The gaps that cause stops are not the kind better retrieval fixes. If it runs, it runs narrow and is scored separately.
The main design work, next up. What to re-check after a change, what to carry forward, how to tell a fix from a loop. The legitimate stops (S4–S6) must survive it.
The “before” column — clean path plus injected scenarios on claude-sonnet-5 — was measured 12 Aug. The “after” waits on the T6 loop.
Only claude-sonnet-5 is measured; other models are pending. Per-stage switching queues behind the loop design.
The pipeline takes a ticket and delivers finished work. It plans, writes the code, runs the tests, reviews its own output, fixes what the review finds, opens a pull request. Against a single repository it needs no supervision.
Real tickets cross repositories. An API change lands in the service that provides it, then in the client library that calls it, then in the tool that wraps that client, in that order. The pipeline stops at the repository boundary.
A stop is the pipeline halting and handing back to a person. It reports what it found, what it expected and what it needs, then does nothing further.
A stop is the pipeline declining to guess, and usually that is correct. Carrying on past a mismatch produces code that compiles, passes its own tests, and breaks the contract the next repository depends on.
The problem is frequency. Every stop interrupts a person.
The goal: reduce how often a stop is necessary, without turning a legitimate stop into a guess.
Stopping less often by learning to guess would score better on the primary metric and make the pipeline worse.
A bigger context window does not solve it. Four questions have no answer today once a task crosses a repository boundary:
Four points, each a different kind of missing knowledge.
The ticket cannot become an ordered list of per-repository jobs, because the dependencies form a cycle or a repository it needs is not in the workspace. Nothing has been built, so nothing is at risk.
Either the plan needs something from a dependency that no contract states, or the ticket forces an architecture decision nobody has made. The first is a missing fact. The second is a missing human judgement.
A repository delivered, and what it provides no longer matches what the next one was told to expect. The run stops before the next repository starts, so no work is done against a stale assumption. The pipeline found the problem and named the right repository; it is not permitted to act.
The final gate checks the whole graph, including edges the step-by-step check cannot see. Those are the edges where a repository was never told what to expect and only declared afterwards what it used. Same shape as point 3, but everything is already built.
Three real repositories with a real dependency chain.
| Repository | Role in the chain |
|---|---|
moby/moby |
The engine. Defines the API and the Go client library everything else calls. |
docker/cli |
The docker command. Consumes the engine's client library. |
docker/compose |
docker compose. Consumes both the engine's client and the CLI. |
One ticket produces three dependency edges in a forced order — engine before CLI before Compose. The dependencies are real and versioned, each repository has a substantial test suite, and a ticket's surface travels visibly — from an engine API option to a command-line flag to a Compose flag.
Three repositories. A soft limit on container processes, landing as an engine API
option, a docker run flag, and a Compose flag. One detail is deliberate — the ticket does not state what Compose
should expect from the CLI, so the run has to handle an unstated dependency.
Two repositories. A timeout option on the engine's client library, surfaced as a global CLI flag. A single edge, stated precisely.
Three more tickets exist only to seed scenarios S4–S6. Each is written so the fault sits in the ticket's own text rather than being smuggled in by the harness.
One fault per stop class, planted on purpose. Each scenario has a manifest recording where the fault sits, so a stop is scored against ground truth. S4, S5 and S6 are stops that should happen — they count inversely.