Stranded at Green
My verification chain instruments the whole agent run and then stops one handoff too early, at the moment the work is supposed to land. A fix sat gate-green on a branch for six weeks while the bug it killed ran in production. On the seventh seam, why its failure mode is absence rendered as success, and the three-question audit that catches it.
The verification chain I have spent a year building ends one handoff too early. Everything instruments the run: the pre-flight audit, the egress floor, the judgment score, the receipt a human signs. And then nothing owns the step where the work actually lands. The merge, the pull request, the deploy. That last handoff fails silently, at scale, and its failure mode is not red. It is absence, rendered as success.
Start with one image, because the whole essay is in it.
On July 27 I audited one repository, personal-ops, and found three separate branches carrying finished, gate-green work that had never been merged. One branch held a retirement of the old worklist system, 1,159 of 1,159 tests green at build time, stranded fifteen days. One held a completed contract migration, zero commits behind main, mergeable as a fast-forward, meaning the merge would have cost nothing and changed nothing except making the work real. And one, the one that matters, held a fix for a real palette bug in the console. That fix had been sitting on its branch for about six weeks. For all six of those weeks, the bug it fixed was live on main.
Read that again slowly, because it is easy to file under ordinary mess and it is not. An agent found a bug. It wrote the fix. It ran the gate. The gate went green. A receipt was produced. And then the fix sat on a branch, complete and verified and inert, while the defect it existed to kill kept running in production, every day, for a month and a half. Nothing was wrong with the fix. Nothing was wrong with the tests. Nothing was wrong with any individual step. The work was simply never handed to the place where work becomes true.
Here is the line from my own audit notes that I have not been able to put down since: every individual session looks successful. That is the spine of this essay. Not “sessions fail and we miss it.” Sessions succeed, one by one, in a way that is fully visible and fully honest at the session level, and the sum of those successes is a fix that never ships and a bug that never dies. The failure lives in no session. It lives between them.
The seam after the signature
A week before that audit note hardened into this essay, I published “Trust Doesn’t Survive the Handoff,” which walked six seams along the life of a single agent run: what a tool can touch, where a call may reach, what the run did, whether the decision was right, whether the verification claim is honest. Six instruments, each one placed where trust was about to be passed forward on a self-report. And that essay ends, deliberately, at a reviewable artifact that a human signs. The receipt is not proof, I wrote. It is the end of self-report.
It is also, I now think, one seam short.
Every one of those six instruments scopes to a run. They ask what this agent, in this session, did and claimed. The seventh seam sits after the signature, and it is structurally different from the other six in a way that took me three separate incidents to see. At every earlier seam, there is something to catch: a lie, a bad call, an overreach, a false claim. The instrument’s job is to turn a hidden failure into a visible one, red where there would have been silence. At the seventh seam there is nothing to catch, because nothing false was ever asserted. The tests really passed. The commit really exists. The push really happened. Every claim along the way was true. The failure is that no claim was ever made about the one thing that matters, whether the work became part of the thing that runs, and in the absence of that claim, every surface you might glance at quietly defaults to yes.
The first six seams are about narration standing in for a check. The seventh is worse: there is no narration at all, and absence photographs identically to success.
Then I looked at the fleet
If the July 27 finding were one repository’s bad habit, it would be a process note, not an essay. So on August 11 I audited the whole portfolio, and the seventh seam turned out to be where finished work goes to disappear at scale.
Two portfolio-wide sweeps, both complete, both verified, both unlandable, in two different ways that both present as done.
The first was a redaction sweep, scrubbing home paths out of repositories before anything public-facing could leak them. The sweep ran. It committed its fix in 35 repositories and pushed to the remote in 31 of them. The number of pull requests it opened: zero. Thirty-one repositories with the fix sitting on GitHub, on a branch, pushed, visible, real, and permanently orphaned, because nothing existed that would ever turn those branches into merges. The bitter detail is what I was doing when I found them: I was about to fix the exposed paths myself, and discovered that every line I was about to fix had already been fixed hours earlier, in commits that nothing would ever apply.
The second sweep failed in a way I find genuinely elegant, in the way a good magic trick is elegant. A guard-consolidation commit landed in each repository on whatever branch that repository happened to have checked out at the time. In 11 repositories, the checked-out branch was one whose pull request had already merged, weeks earlier. In one repo the commit is dated August 11 on a branch whose PR merged July 14. A closed pull request cannot carry a commit added after it closed. So the commit exists, the branch exists, and the repository’s PR list shows the work as reviewed, approved, and merged. Every surface a person would check reads done. Local log: the commit is there. Remote branches: pushed. PR list: merged. All three true, and the work will never land.
And then the audit itself lied to me, which completes the set. When I first went looking for the redaction sweep, I searched for its branch name and found it in 6 repositories out of 32. The real number was 35, because the sweep only created its named branch where a repo sat on its default branch, and otherwise committed onto whatever was checked out. A conditionally named sweep cannot be audited by branch name, and the wrong query does not error. It returns a plausible small number, which is the most dangerous thing a query can return.
Tally it honestly. Dozens of repositories holding finished, verified work that reads as delivered from every angle and can never become real without someone noticing the specific way in which it is stranded. No alert fired. No dashboard went red. There is no red for this. The tooling has no state that means written, pushed, and orphaned, so it renders that state using the same pixels as success.
The judge that never showed up
It gets one layer worse, because the same absence-reads-as-success mechanism turns out to live inside CI itself, at the exact point where you would go to double-check.
A GitHub Actions workflow that dies in startup_failure, a run that fails before it ever begins, a broken trigger, a missing secret, a malformed config, produces no check run at all. Not a red check. No check. It contributes nothing to the PR’s status rollup, and the pull request displays the checks that did run, all green, and reports itself CLEAN.
Measured on August 11, across the two open sweeps: 6 of 31 pull requests in one and 10 of 22 in the other had at least one workflow that never started. One workflow had failed to start 16 times across the fleet, another 12 times, and nothing anywhere had ever surfaced it. Four repositories had been reported to me, by my own tooling, as green and mergeable. They were green because the workflow that would have judged them never ran. The verdict was not favorable. There was no verdict, and the interface renders no verdict and acquittal identically.
Every other CI failure is loud. A failing test is red. A crashed job is red. This one is invisible precisely because visibility itself is what failed to start. It is the CI-layer version of the whole seventh seam: the system does not distinguish “checked and fine” from “never checked,” and everything downstream inherits the conflation.
Even the obvious probe has teeth. You can query the runs directly and look for startup_failure, but for pull-request events the runs are recorded against the PR’s internal ref, not the branch name, so the natural branch filter silently returns nothing. And the flag that fetches failure logs returns nothing for a run that never started, because there are no logs of a thing that did not happen. Absence, all the way down.
Merged is still not shipped
By now the shape should be familiar enough to predict the last extension, and it holds: even a merge is not the end of the chain, because on any real system the running code is not the repository.
The scheduled jobs on my machine execute from content-addressed release bundles, frozen snapshots staged by a release tool, not from the live checkout. That tool builds a release from an explicit allowlist of managed files. A script committed to the repository and merged to main is still not deployed until its path is added to that allowlist. I learned this at a cost of three pull requests: one of them added a scheduled job pointing at a file that its own release process would never include, so staging produced a 28-file bundle with the new file simply not in it, and arming the job would have died on a missing path. Merged, reviewed, on main, and not shipped, with nothing red anywhere.
So the ladder has four rungs, and each one is routinely mistaken for the one above it. Committed is not pushed. Pushed is not merged. Merged is not shipped. Every instrument I built, and nearly every instrument the industry builds, certifies rung one and lets the reader assume rung four.
Why there is no red
It is worth being precise about why this seam stays dark, because the reflex answer, “add a check,” misses what is structurally different here.
Every earlier seam fails inside a run, and a run has an owner. The session that made the bad call is right there; an instrument bolted to it has something to attach to and someone to alarm. The seventh seam fails between runs, in the gap after one session ends and before a merge that no session owns. The session that wrote the fix completed successfully and exited. The next session starts fresh and has no reason to go looking for the last one’s unlanded branches. The human in the loop signed a receipt that said, truthfully, the work is verified. Nobody’s job description, human or agent, includes the sentence “confirm the last thing actually landed,” so the confirmation belongs to nobody, and work committed by nobody does not get done.
And the failure emits nothing. That is the deepest difference. A stranded branch is not an event. It is the continuing absence of an event, and monitoring is built out of events. You cannot subscribe to a merge that did not happen. Six weeks of a fix not shipping produces exactly as much telemetry as six weeks of a fix shipped and stable: none. The two states are indistinguishable to every passive observer, which means the only thing that separates them is an active probe that someone deliberately owns.
I have started building those probes, and the commit log shows the turn. In one project the fix reads “persist the completion receipt instead of only printing it,” because a receipt that scrolls away in a terminal is narration, and a receipt on disk is something a later process can notice is missing. In another, a scheduled pipeline now carries an explicit alarm “when the last run’s output is stranded,” a check that fires not when something fails but when something finished and then failed to go anywhere. Both commits are small. Both encode the same inversion: stop instrumenting whether the work succeeded, start instrumenting whether the work arrived.
The three questions, asked separately
Here is the method, stated so you can steal it. It is small, and every part of it exists because the obvious version failed on real work.
After any sweep, any agent session, any batch that produces commits, verify three things, separately, because they are three different facts with three different answers:
First, is the branch pushed? Second, does it have an open pull request? Not “a pull request,” an open one; the 11 repositories parked behind already-merged PRs pass the sloppy version of this question. Third, is the commit an ancestor of the published base branch? One command answers it: git merge-base --is-ancestor <sha> origin/main. Ancestry is the fact the other two are proxies for, and the proxies diverge from it in exactly the ways this essay has catalogued.
Find the work by commit subject, searched across all refs. Never by branch name. Branch names are a convention the tooling applies conditionally, and a name-based query fails by returning a smaller, plausible number rather than an error. The commit subject is the one string the sweep writes unconditionally, so it is the one handle that reaches everything the sweep touched.
And when you audit a whole repository for stranded work, know your instruments’ blind spots, because both standard tools lie here in opposite directions. Ancestry checks miss work that landed by another route and will tell you a shipped branch is stranded. The patch-id comparison that fixes this is itself defeated by squash-merging, which rewrites the combined diff so that pre-squash originals still read as unmerged; that one artifact made 12 branches of already-shipped work look stranded in a single audit, and acting on it would have meant re-landing or deleting work that was already live. So before you call a branch stranded, or safe to delete, confirm by content: does a file the branch adds exist on main? Does a distinctive symbol from it grep there? Does main call the thing the branch added? Content probes are clumsy and unglamorous and they are the only instrument in this list that cannot be fooled by history rewriting, because they ignore history entirely and ask about the present.
None of this is sophisticated. That is the point. The seventh seam does not need a clever verifier. It needs an owner, three questions, and the discipline to treat “gate green” as the middle of delivery rather than the end.
The loop ends at landed
The previous essay closed by saying the chain does not end in certainty, it ends in a reviewable artifact that a human signs. I still believe that sentence and I now know it is incomplete. The signature is where verification ends. It is not where delivery ends, and the gap between those two has been, on my machine, the single largest sink of finished work: dozens of repositories, multiple completed sweeps, and one fix that spent six weeks stranded at green while its bug ran in production.
What makes this failure mode worth an essay rather than a checklist is its camouflage. Agent washing sells you activity as capability. Tool poisoning smuggles instructions past your attention. This one does something quieter than either: it takes work that is genuinely done, genuinely verified, genuinely pushed, and lets it evaporate in a gap that renders as success on every surface anyone checks. There is no lie to catch. There is only a question nobody asked, and systems are extraordinarily good at not volunteering answers to questions nobody asked.
So instrument the last handoff like it is the first-class seam it is. Persist the receipt where a later process can miss it. Alarm on the output that finished and went nowhere. Ask pushed, open, and ancestor as three separate questions, find the work by what it says rather than where it sits, and trust content over history. The run is over when the gate goes green. The work is done when it lands, and nothing in the world will tell you the difference unless you build the thing that checks.