The task was deliberately trivial: a one-line bug behind a failing unit test, the kind of fixture you build specifically so nothing about the difficulty of the bug can explain a failure. Four real runs went through the full pipeline, no stubs, real models, real cloud calls where the chain reached them. Routing worked. Decline detection worked. The escalation chain worked. The privacy gate worked. The confirmation gate worked, correctly, in both autonomous and interactive mode. And the bug was never fixed, not once, in any of the four attempts.
Two questions that look like one
“Did the pipeline run correctly” and “did the task get done” are dangerously easy to conflate, especially when the pipeline is the thing you just spent a phase building and are eager to see prove itself. A smoke test that only asks the first question will report a pass on evidence that the second question’s answer is no. This run asked both questions separately, and the two answers didn’t match: the machinery, real yes. The mission, no.
What the mismatch was actually made of
The failure wasn’t one thing wearing two disguises. It was three distinct, real problems layered under one visible symptom. The local model timed out on the first attempt, and confirmed-warm on the second attempt, ruling out cold-load time as the cause. A longer timeout on the third attempt removed the timeout itself but exposed a different problem: the model got evicted mid-run for a smaller fallback, which then failed to produce a working fix over two more iterations. The fourth attempt, interactive, correctly escalated to a cloud engine, got a real human confirmation, and still didn’t fix the bug: the cloud adapter had never been taught to work in a repo other than its own, so it dutifully asked for permission to touch code it had never been pointed at. None of those three problems are the pipeline being broken. All three are real, and all three needed separate follow-up work, not the same fix wearing different traces.
What almost didn’t get recorded at all
The sharper risk sat one layer below the fix-worthy bugs: three of the four real, model-time-consuming attempts left no ledger entry whatsoever. Only the interactive run, the one that reached a human confirmation prompt, wrote a trace. A declined-and-unconfirmed run vanishing without a record isn’t a cosmetic gap. It means the system’s own audit trail silently under-reports how much real work it actually attempted, which is exactly the kind of blind spot that erodes trust in every other number the ledger reports.
What next
Two of the three named risks drove real, same-day fixes, tracked as formal risk-register entries: the cloud adapter learned to route to the actual target repo, and the decline branch learned to write a ledger entry on every exit path, not just the ones that reach a human. The third, model/timeout tuning, was never a risk-register item in this lab at all; it lived in the sibling repo’s own backlog, and it took three more days and two further retries before a fresh fixture finally converged on a working fix. Real, but not same-day, and not uniform with the other two. What those fixes made possible is the subject of a companion post, about a very different way for a correct piece of machinery to still produce a meaningless result.
What Next
Verifying the Wrong Universe
Worktree isolation was correct. Post-task verification was correct. Composed together with no check at the seam, a relative path silently pointed the verify step at the wrong directory entirely, and reported back exactly as confidently as if it hadn't.