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.

That is where the pipeline stops.

What a stop is

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.

It is not a crash and not a wrong answer. It 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.

Both halves matter. Stopping less often by learning to guess would score better on the primary metric while being worse in every way that counts.

Why it is hard

A bigger context window does not solve it. Four questions have no answer today once a task crosses a repository boundary:

• Which repositories should this change be validated against?
• What carries forward to the next step, and what gets dropped?
• When something turns out wrong, which repository do we go back to?
• Is this a real fix, or the same failure again? Inside one repository the pipeline already counts repeat failures and gives up rather than thrashing. Across repositories there is no equivalent.

Where a run stops

Four points, each a different kind of missing knowledge.

The method is validated and the measuring instrument works. The headline result cannot exist yet, because the thing that creates stops on purpose is still being built.

Three repositories that genuinely depend on each other, in a chain.

Three dependency edges from one ticket, with a forced order: the engine lands before the CLI, which lands before Compose.

Why Docker

A real dependency chain at a workable size. Large enough that the contracts between repositories are genuine, small enough that a full run finishes in an hour or two and can be repeated.

The dependencies are real and versioned. Each repository has a substantial test suite that runs without exotic infrastructure. And a ticket's surface travels visibly, from an engine API option through a command-line flag into a Compose flag, which makes behaviour easy to observe.

Carving one repository into pieces was rejected as the only test bed: it exercises context selection, but not discovery, merge sequencing or version skew, which need real boundaries.

Setup

• Frozen private copies. Each repository pinned to its state on 10 August and re-hosted privately, upstream commit recorded. Runs are reproducible, and no test pull request can reach real Docker.
• A test gate per repository, trialled green before any run, so a failing gate means the agent broke something rather than the setup being wrong.
• No live engine. Build, unit and parse-level checks only, which keeps runs hermetic and failures attributable. Each repository also declares off-limits paths and branch naming.

Most of the setup effort went into making the three compile against each other locally. Two edges were routine. The third was not: the CLI carries no standard module file at its root, only a vendored variant, so the usual redirection fails silently. Presenting the vendored files under the names the tooling expects fixes it. Worth recording because it decides whether a test bed is usable at all, and it is invisible until you try.

The two tickets

Both written as real tickets, with acceptance criteria and exact expected help text.

Three repositories. A new soft limit on container processes: added to the engine API, exposed as a docker run flag, surfaced as a Compose flag. One detail is deliberate: for the Compose-to-CLI edge the ticket does not state what Compose should expect, 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.

What the baseline runs showed

Four complete runs across two tickets and two models, all clean-path. Every run completed: ten cross-linked draft pull requests, every edge satisfied, no human intervention, no stops.

Two behaviours worth naming:

It handled a mismatch that was not one. The ticket named a new field on a particular type. Both models built it nested one level deeper, mirroring how the neighbouring option is structured. A strict reading would have called that a contradiction and stopped. Both judged the named field still reachable and carried on. That judgement separates a useful stop from an annoying one.

A review caught what the tests could not. On the two-repository ticket, the new flag was wired into a constructor with no production callers. Every unit test passed and the feature did nothing. The self-review caught it, one bounded fix cycle followed, round two was clean.

Four faults we inject on purpose, one per kind of stop. Each is a situation we know should halt the run, so “stops went down” can be measured against something real. Each carries a manifest recording where the fault was planted, which is the ground truth for scoring whether the pipeline goes back to the right repository.