Preserve First, Verify the Verifier, Reconcile Later

What a cloud/local AI-agent consolidation taught me about stale Git refs, false green checks, and prompt-level safety boundaries.

The setup

One evening in early May I asked a cloud instance of Claude Code - running from my phone - to start and fully finish a small tool. The tool itself is almost beside the point. It is a mechanical compliance gate for my Five-Point Protocol (5PP), the working discipline behind most of the agent work on this site. You hand the gate a markdown work record. It checks that the work actually moved through Clarification, Scope, Plan, Execution and Verification, and that the record closes with exactly one verdict. A linter for process rather than for code.

The cloud session delivered. Nine commits in well under two hours, a merged pull request, a CI pipeline that gates the project's own process records, and 107 green tests. It closed its loop after 21 of the 150 iterations I had allowed it, and wrote a tidy close-out report.

There was one catch, and it is the catch this whole article hangs on. The original design for that tool - seven design documents and a 1,205-line prototype - existed only as untracked files on my local disk. Never committed. Never pushed. The cloud environment could not reach my machine, so it built version 1.0 without ever seeing the design the tool was supposed to come from.

Here is the part worth stealing before anything goes wrong. The agent knew it was blind, and said so out loud. It flagged the already-tracked gap in its own notes, built from the sources it could reach, placed its own design documents under a versioned namespace, and left every path the originals would need deliberately unoccupied. Then it wrote a reconciliation plan describing how the two design lineages should eventually meet, and noted that the next move - publishing the originals - was mine, because only I could see them.

A day later I sat down at the local machine with the other half of the problem. Ten commits I had never reviewed line-by-line were sitting on a remote. Eight irreplaceable files were sitting untracked in my working copy. The job was to land the first without harming the second, and then to decide how much of the new code to trust.

That second decision is where things got interesting, because the honest answer to "can I trust this?" turned out to be "not until I stop trusting my own verification tooling."

A green checkmark is not evidence. The evidence trail behind the green checkmark is the evidence.

I should also name the lens I brought to this. It is not primarily a software-developer reading of the incident. My background is DevOps and systems technician work, with cybersecurity as a long-running part of the job.

So I tend to look first for boundaries, trust assumptions, evidence chains, handoff points, control surfaces and failure modes. That matters here, because this story is less about clever code and more about how a system can produce a confident answer from incomplete visibility.

Landing ten unseen commits without breaking anything

The first surprise was banal, which is exactly what makes it dangerous. git status on my local clone reported that the branch was up to date with its remote. That statement was true and useless at the same time. The clone had never been fetched since its first commit, so the remote-tracking reference was a snapshot from almost six weeks earlier. The remote actually held ten commits my machine had never heard of. The local ref was not lying about what it knew. It was hiding how little it knew.

So the first rule of consolidation is embarrassing in its simplicity. Ask the remote, not your cache of the remote. A single git ls-remote call revealed the real state of the world, and everything that followed keyed off that answer instead of the stale one.

Then came the safety sequence. Four read-only checks, in order, before a single byte moved.

First, the divergence check. Was my local branch an ancestor of the remote branch? It was - zero local commits at risk, ten remote commits to receive. That meant a fast-forward was possible, and a fast-forward cannot rewrite history. It moves a pointer and writes new files, nothing more.

Second, the collision check. Every one of my eight untracked files was tested against the remote's full file tree. Zero collisions - because the cloud agent had reserved those paths on purpose. Its foresight and my caution met in the middle, and that meeting is the quiet hero of this story.

Third, the ignore-rules check. I read the remote's ignore file before merging, to be sure none of my untracked originals would silently fall under a new ignore pattern and vanish from view.

Fourth, archive first. All eight originals were copied to a separate location, a hash manifest was written for them, and the pre-merge commit id was recorded as a rollback anchor. Total cost, a few minutes. Insurance value, total.

This is the boring part of the story. It is also the part that made the rest survivable.

Only then did the merge run, restricted to fast-forward only. Forty-one files arrived, just under six thousand added lines. The hash manifest verified all eight originals byte-identical afterwards. Then I made the new code prove itself by execution rather than by narrative. The full test suite passed locally. The gate accepted its passing example and rejected its failing example with the documented exit codes. The CI job's logic, replicated step by step on my machine, behaved as advertised.

Finally, the preservation commit. The eight originals went into version control on their own branch, verbatim - eight added files, zero modifications, zero deletions. And then the one verification step I would now never skip. I did not hash the files in my working directory and call it done. I read the committed blobs back out of the object database and hashed those against the pre-merge manifest. The working tree tells you what is on disk. The object database tells you what git actually stored. Only the second one is preservation evidence. That branch later went to the remote as a plain checkpoint push - no pull request, no merge, just an off-machine copy.

Takeaways

• git status reports your cache of the remote. git ls-remote asks the remote. Before consolidating anything, ask the remote.
• Landing foreign work safely is four cheap checks - divergence, collisions against untracked files, ignore rules, archive-first with a hash manifest.
• Fast-forward-only is a safety property, not a style preference. It cannot rewrite what you already have.
• After committing irreplaceable files, verify the committed blobs, not the working tree.
• If your agents work where they cannot see everything, have them reserve paths for what they cannot see - that reservation is itself a design act.

The verification that verified nothing

Ten commits of agent-written code that no human had reviewed were now my local reality. Running the tests was necessary but nowhere near sufficient - tests written by the same session that wrote the code share that session's blind spots. So I set up an adversarial verification. Six independent reader agents, each with a different lens - claim accuracy, gate evasion, security, CI soundness, correctness, and the design delta against my original documents. Every finding they produced would be judged by three more agents with three different angles - reproduce it from scratch, check whether the behavior was actually documented intent, and judge whether it mattered in context. Majority refutation kills a finding. What survives is at least worth taking seriously.

The run came back with a result that read like a verdict. Zero findings survived adversarial refutation across six lenses.

Comforting. Also false.

The six lenses had actually found sixteen findings. All sixteen were destroyed by a one-line mistake in my orchestration script - the refuter configuration was declared as a constant after the pipeline that consumed it. In JavaScript, function declarations hoist but constants do not initialize until their line runs. So the judging function was callable, and every single call into it threw. The parallel runner had one more surprise in store. Instead of failing the run, it resolved each crashed branch to a null. And one idiom later - a plain filter(Boolean) to tidy the list - the nulls disappeared entirely. Sixteen findings in, zero out, and no error anywhere in the result.

The synthesis step, handed an empty list, did exactly what a language model does with the data it receives. It wrote a fluent, confident, well-structured verdict about how clean the code was.

The failure was small enough to miss and structural enough to invalidate the whole run.

phase('Lenses')
const results = await pipeline(LENSES, runLens, judgeFindings)

// ...two hundred lines further down...
const REFUTER_PANEL = [reproduce, checkIntent, judgeImpact]

function judgeFindings(findings) {
  // hoisted, so callable early - but REFUTER_PANEL has not initialized yet
  return parallel(findings.map(f => () => refuteWith(REFUTER_PANEL, f)))
}

const survivors = (await parallel(jobs)).filter(Boolean)
// a crash and an honest "nothing found" are now the same value

The only trace of the disaster was sixteen identical error lines in a failures channel off to the side of the main result - a channel nothing required me to read. A crash, laundered into a clean bill of health.

The fix took two minutes. The constants moved above the pipeline, and the run resumed from cache, so the expensive reading work replayed for free and only the judging ran fresh. The true result - sixteen raw findings, eight survived refutation. Two of the survivors are worth describing here in generalized form, because both are live in a private tool and the point is the pattern, not the coordinates.

The first was an over-eager pattern match. A feature that auto-activates a stricter checking overlay would trigger on an incidental mention of its keyword anywhere in a document's prose, silently assigning a stricter setting the author never declared, or overriding one they did. The tool's flagship demo record, which declared no such setting at all, turned out to pass its own gate for the wrong reason because of exactly this auto-assignment.

The second was a CI blind spot. The pipeline's negative test - the step that proves the gate rejects a bad record - only checked that the command exited non-zero. But a crash also exits non-zero. The test cannot tell "the gate correctly said no" from "the gate never ran at all." If a future change made the parser crash on the failing example, CI would stay green while the gate was broken.

Takeaways

• Any filter that can empty a result set must log its counts. "Sixteen in, zero out" printed once would have exposed the whole failure in a second.
• Distrust suspiciously clean zeros. A broken verification and a passing verification look identical if you only read the summary.
• Read the failure channel even when the result looks fine. Especially when the result looks fine.
• Crashed branches that resolve to null, plus a tidy-up filter, is a silent-data-loss pattern. Grep your orchestration code for it today.

Three more bugs, all in the glue

With the refuters actually running, I went back through their raw votes instead of trusting my own summary of them. That pass surfaced three more defects - all mine, all in deterministic glue code, none in any model's judgment.

The first was a sort direction. My severity reducer was supposed to publish the consensus severity for each confirmed finding. It sorted the votes and took the first element - of the wrong end. It published the most lenient vote instead of the strictest. A finding that two of three refuters confirmed as real was published as not-a-defect.

The second was a quorum hole. One refuter agent crashed mid-run on an output-format limit. Its finding now had two votes instead of three, split one against one. My kill rule, written with three votes in mind, treated the tie as a kill. The finding was not refuted - its jury was incomplete. Those are profoundly different outcomes, and my code had collapsed them into one.

The third was the most instructive. Every verification agent received a written boundary in its instructions - the repository is read-only, do not modify anything. One of them ran a package build inside the repository anyway, leaving build artifacts behind. They were caught by ignore rules and harmed nothing. But the lesson generalizes to every agent system I have ever run. A prompt-level boundary is a request. Enforcement is a filesystem, a separate worktree, a permission model - something that does not depend on being obeyed.

That is the part my systems background kept pulling me back to. The interesting question was not only whether the agent followed the instruction. It was where the instruction stopped being a control.

That was the deeper lesson - once the models have spoken, the plumbing still gets a vote.

Takeaways

• Aggregation code is part of the safety surface. A sort direction, a tie rule, or a filter can invert the meaning of an entire verification run.
• Write quorum rules for judging panels. An incomplete jury is inconclusive, never resolved-by-default.
• Prompt constraints are requests. When repository state matters, give agents an isolated copy and let the isolation do the enforcing.

The correction moment

Verification cut both ways, and this is the part I most want to be honest about.

The boldest claim I had made during the review was about design fidelity. I asserted, in writing, with confidence, that the cloud build had inverted the locked principle at the heart of my original design - that code, not a model, must own the final verdict. My own refuter panel killed that claim three votes to zero. They were right. I had conflated two different fields in the result object. The pass-fail decision was computed in plain code all along. What the new tool actually lacked was the graded scoring model from my prototype - a true gap, but a much weaker claim than "the core principle is inverted." I corrected the record the way I would want any collaborator to - the original wording preserved, the correction underneath it, both visible, nothing silently rewritten.

Then I did the same thing to this article's own source material. Before drafting, I compiled everything above into an evidence pack and ran a fresh adversarial pass over it - one lens checking every number and quote against the primary sources, one sweeping for information that should not be published, one hunting overclaims. Eleven findings, ten survived.

Two of them still make me smile. The pack's own pre-publication safety gate - the first line of the document, telling any future reader which section to check before anything leaves the machine - pointed at the wrong section. Anyone obeying it would have landed on a list of lessons learned and never reached the redaction table. And the table row warning that directory layout is a fingerprint contained, in its example cell, the actual directory prefix it was warning about. The remaining findings were smaller but real - a citation off by three lines, a quoted error message with the wrong glyph in it, and one narrative sentence that compressed four different refutation reasons into a single tidy story my own findings table contradicted.

One quiet win landed in the same run. The quorum guard I had added after the tie bug fired for real when another judging agent crashed - and this time the system marked the affected finding single-vote-inconclusive instead of silently killing it. Guards prove themselves on the next failure, not on the day you write them.

Takeaways

• Point the verification at your own claims, not just the agent's. If it has never killed one of your conclusions, it is not calibrated yet.
• Supersede in writing. Keep the wrong version visible under the correction. Silent edits destroy the trail that makes the rest of your record credible.
• Audit the audit. My evidence pack - the document built specifically to be reliable - contained ten defects, including a broken safety pointer.
• Run your own conclusions through the same refutation panel you built for the agent's work. The instinct to verify does not exempt the verifier.

What this actually teaches about agentic development

The agents were the strongest links in this chain, not the weakest. A quick skim of this story might leave the opposite impression, so it is worth being precise about where the failures actually lived.

This is the systems-designer lens at work - not "where is the bug?" first, but "where can trust cross a boundary without evidence?"

The cloud agent declared its own blind spot, reserved file paths for documents it could not see, and left a written reconciliation plan. The reading agents surfaced sixteen candidate findings in code that looked clean, and eight of those held up as real under adversarial refutation. The refuters killed my own overconfident claim before it hardened into project truth.

Every dangerous failure in this story lived in the glue between parts, much of it orchestration I either wrote myself or had agents help design, review, and judge - a sort direction, a tidy-up filter, a tie rule, a cross-reference pointing at the wrong section, and an instruction that looked like a boundary but was not enforced as one.

Four observations survived contact with all of the above. They are the observations of a systems designer more than a code reviewer - agents, repositories, memory, permissions, summaries, CI, local state, remote state, and the gaps between them.

The most valuable single behavior an agent showed was declaring what it could not see. Ask for that explicitly when you brief agents for partial-visibility environments - a named blind spot in the close-out report, and a written hand-back plan for the human who can see what the agent cannot.

Verification pipelines fail in aggregation, not in judgment. The model-driven parts of my pipeline did their jobs. The failures were in the plumbing between them, where thrown errors became nulls and nulls became silence. If you build multi-agent verification, your reducers, filters and quorum rules deserve the same review discipline as the checks themselves.

Boundaries need enforcement surfaces. The read-only instruction was violated not out of defiance but out of ordinary task momentum. Isolation that does not depend on obedience - separate copies, separate worktrees, scoped permissions - is cheap. Use it whenever state matters.

And records need supersession discipline. Agent-generated conclusions arrive fast, fluent and confident, which means wrong ones arrive fast, fluent and confident too. A working convention of correcting in place, with both versions visible, is what keeps a knowledge base trustworthy after months of agent traffic.

The reusable checklist

Preserve first

• Inventory what is untracked and irreplaceable before touching anything remote.
• Copy it out, write a hash manifest, record a rollback anchor.
• Check for path collisions and ignore-rule swallows before merging.
• Merge fast-forward-only where possible. Verify the originals byte-identical afterwards.
• Commit preserved material verbatim on its own branch, then verify the committed blobs against the pre-merge manifest.

Verify the verifier

• Demand counts at every pipeline stage. Sixteen in, zero out is a claim that needs a reason.
• Treat clean zeros as findings about the pipeline until proven otherwise.
• Read failure channels on success, not just on failure.
• Use adversarial refutation, and let it target your own claims too.

Audit the aggregator

• Test reducers with hostile inputs. A wrong sort direction survives every happy-path test.
• Define quorum rules before you need them. Incomplete jury means inconclusive.
• Never allow a silent drop. Everything that removes items from a list logs what it removed.

Reconcile later

• Reconciliation of divergent designs is its own lane, started only after preservation is provably lossless.
• Product-identity decisions - which of two designs is the product - belong to the human, documented, not to whichever agent got there first.

Publication note

Everything in this article comes from a single evidence pack assembled during the work and then adversarially fact-checked before drafting - three lenses, two refuters per finding, every number re-read from the primary sources. Some details are deliberately generalized. The two live defects described in the verification section are given as patterns, without file names, check names or line numbers, because they are real and not yet fixed in a private tool. Repository names, host paths, account identities and internal tooling names are generalized for a plainer reason, ordinary privacy. The commit counts, test counts, finding counts and the sixteen-to-zero-to-eight sequence are reported exactly as they happened.

The tool that started all of this now sits in a strange and honest place. The cloud's version is landed, tested and adversarially reviewed. My originals are preserved bit-for-bit with their integrity provable from the object database. The two designs still disagree about what the tool ultimately is, and that reconciliation is tracked as its own future piece of work with a written plan. Nothing was lost, nothing was rushed, and every claim in the trail can be replayed.

A green checkmark is not evidence. The evidence trail behind the green checkmark is the evidence.