The test bed is built. Its scenario suite is being rebuilt from scratch: the first set was authored breadth-first and, on review, could not carry a measurement — so it was retired in full on 12 Aug rather than patched. The same review found that the pipeline was being started through an intermediary rather than by the command a person actually types, so measurement restarts from zero under the corrected entry point. The next piece of work is admitting the first scenario back.
Landed 10 Aug.
Read the workspace mode end to end, inventoried every blocker it can report.
The Docker bed, its harness and its bookkeeping stand. The scenario suite was retired on 12 Aug and is being rebuilt one scenario at a time, each admitted only after it fires cold and then reproduces. The bar for calling this done is coverage, not count: two independent avoidable-stop controls on different seams, plus a guardrail, plus the clean path.
Now the single mechanism task, absorbing what was T5: survey the candidates, score them against the three questions the stop map produced, and propose one. The honest prize is fewer false completions, not fewer stops — the stop map found that stops are permission gaps, so driving the count down would be a warning sign, not a win. The stop map itself is the evidence base: 32 stop sites, each classified by whether it lacks permission or information.
Retired on 12 Aug and folded into T4, which it overlapped. Kept in this list under its own number because it is referenced by that number elsewhere.
The main design work. What to re-check after a change, what to carry forward, how to tell a fix from a loop. The stops that should happen must survive it.
No column is collected. The figures gathered on 12 Aug were set aside with the entry-point correction; the “before” column is re-measured from the rebuilt suite, and the “after” waits on the loop design.
No model is measured yet. 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.
One ticket per scenario, written when that scenario is admitted and not before. The earlier batch was written up front, ahead of any scenario having earned its place, and was retired with the suite on 12 Aug.
Each ticket describes a feature whose surface travels the full chain — an engine API option, then the command-line flag that exposes it, then the Compose flag. Where a scenario needs a fault, the fault sits in the ticket's own text rather than being introduced by the harness mid-run: a run that has to be interrupted to produce its fault is not measuring something a real run would hit.
One fault per stop class, planted on purpose — and nothing is listed here until it has earned its place. A scenario is admitted only as exactly one of three kinds: an avoidable stop the loop is meant to eliminate, a guardrail stop it must preserve, or the clean path, where it must introduce no stop at all. Anything that fits none of the three is not a control, however interesting it is.