Development record
The fidelity audit runs after the merge, so its verdict arrives when the cheap remedies are already gone, and the code refuses any other ordering: the ingest rejects an intent that is not in the shipped bucket, and the emit fires from the ship move itself, so an intent cannot be audited against the candidate diff on a branch. The stated reason is sound as far as it goes, that a report-only review must never un-ship what has already shipped, but it answers a question that only arises because the audit was placed after the merge in the first place. Audited before the merge, a failing criterion has three cheap answers: fix the branch, revise the promise before making it, or decline to merge. Audited after, it has none, because there is no un-ship path and the code is on the trunk. The counter-argument is real and should not be waved away: a branch is not the tree that lands, since the merge queue lands merge commits and a semantic conflict with a concurrently merging change can alter the delivered reality after the verdict was formed, so the post-merge audit judges what is actually true while a pre-merge one judges a candidate. The shape that gets both is to gate on the pre-merge verdict and bind it to a content hash of the tree it judged, then check deterministically after the merge that the landed content still matches, reopening the receipt only on a mismatch, which costs one hash comparison rather than a second audit and reuses the content-addressing the transcript store already relies on. Whatever the ordering, the model's verdict must stay a proposal and a human acknowledgement must remain the gate, because a non-deterministic verdict that can block a merge on its own is a trust step this repository has not taken and would train people to route around the gate.
The fidelity audit runs after the merge, so its verdict arrives when the cheap remedies are already gone, and the code refuses any other ordering: the ingest rejects an intent that is not in the shipped bucket, and the emit fires from the ship move itself, so an intent cannot be audited against the candidate diff on a branch. The stated reason is sound as far as it goes, that a report-only review must never un-ship what has already shipped, but it answers a question that only arises because the audit was placed after the merge in the first place. Audited before the merge, a failing criterion has three cheap answers: fix the branch, revise the promise before making it, or decline to merge. Audited after, it has none, because there is no un-ship path and the code is on the trunk. The counter-argument is real and should not be waved away: a branch is not the tree that lands, since the merge queue lands merge commits and a semantic conflict with a concurrently merging change can alter the delivered reality after the verdict was formed, so the post-merge audit judges what is actually true while a pre-merge one judges a candidate. The shape that gets both is to gate on the pre-merge verdict and bind it to a content hash of the tree it judged, then check deterministically after the merge that the landed content still matches, reopening the receipt only on a mismatch, which costs one hash comparison rather than a second audit and reuses the content-addressing the transcript store already relies on. Whatever the ordering, the model's verdict must stay a proposal and a human acknowledgement must remain the gate, because a non-deterministic verdict that can block a merge on its own is a trust step this repository has not taken and would train people to route around the gate.
Reframed 2026-08-29 under adr-55: the agents run autonomously and stop only to obtain a verdict, which decides this. The audit IS the stop, so it belongs before the merge, where a failed criterion still has cheap answers. A post-merge audit never stops the loop; it leaves a note. The content-hash check after the merge remains the safety net for the branch-is-not-the-landed-tree objection.
Deferral 2026-09-29
Deferred past v0.11.1: The direction is settled (adr-2609151528057260: the audit is the stop, so it belongs before the merge), and the work waits on itd-165 (draft): a pre-merge gate tuned before a corpus of real audit verdicts exists would baseline nothing. Owed: itd-165's planning interview, then an intent for the reorder with the post-merge content-hash check; filing both needs the product thinker's adoption.
Remedy grounds (2026-09-29)
- adr-2609151528057260 settles the direction (the audit is the stop, so it sits before the merge); the content-hash check answers the record's own objection that a branch is not the landed tree, at the cost of one comparison.
- The emit still refuses any intent outside shipped/ (internal/core/intent/audit.go, the not-shipped refusal), so the reorder is unbuilt.
- Rejected: a model verdict that blocks the merge on its own, which the record rules out.
Frontmatter
| id | iss-2608290822140563 |
|---|---|
| type | issue |
| lifecycle | open |
| severity | major |
.abcd/work/issues/open/iss-2608290822140563-the-fidelity-audit-runs-after-the-merge.md
open on GitHub ↗ · commit history ↗
mentions4
- adr-55The construal stands in the record; its history does not
- adr-2609151528057260Three roles, who each artefact addresses, and when the loop stops
- dcn-26093000000000092026-09-30 — The person answered eighteen rulings of autonomous run A on 2026-09-30 (CF1, CF2, CG1, CI1, CI2, CJ1, CK1, CL1, CM1, DR1, DR2, DR4, DR5, DR6, DQ1a, DQ1b, DQ2, DQ3), relayed by the run's interviewer abcd-23 [b1e81b] and recorded by lane recRulingsDR for orchestrator abcd-8d [5bfdfb]. The answers are kept in the local-tier file `.abcd/.work.local/scratch/reports/rulings-answered-2609-29-b.md`, lines 13 to 30, and are restated here because that file is not committed. SETTLED BLOCKERS: a blocker replaced by an accepted ADR counts as settled, so the waiting intent may start (CF1); a blocker reclassified as a discipline counts as settled too (CF2). Neither is built at this entry's base: the blocked pre-start check still refuses both shapes, and iss-2609300751191426 carries the change. AS BUILT: the App token for the dependency re-authoring workflow is minted in the shell, an openssl-signed JWT exchanged with curl and revoked on exit, with no new action (CG1); when the prompt router cannot evaluate a prompt, its envelope carries the error and leaves the active-domain list out, so the client keeps what it had (CI1); a domain that returns to the active set is re-injected on every host, one that appends to a transcript included, not only on a client that snapshots (CI2); `abcd update` shows progress only when stderr is a terminal, and saved output stays clean (DR4). BUILD: the installer (`hooks/bootstrap.sh`) writes the previous release tag into binary-meta when it swaps a binary, the session hook stays read-only, and that tag replaces the setup_version comparison of the itd-111 update notice (CJ1); the SHELL domain also teaches a repository's own guard entries, generated the same way as the bundled registry's (CK1); `step` in `abcd implement check` is renamed `stage` too, in the same breaking v0.12.0 (CM1); the fix rounds a run spends before it hands a lane back are a per-run setting beside `--pace`, for example `--fix-rounds`, default 3 (DR1); the dependency-bump intent itd-2609221842494980 ships now, with the first live bump recorded as owed until the person has created the App and its secrets (DR2); only a self-contained agent is sent to a paid provider by default, so the cold-reading positions may go while a file-reading agent such as the intent auditor is refused with the reason, and a central override, a machine-level settings list the person keeps that no agent or repository can change, may name providers that take bundled-context requests for file-reading agents (DR5); a run works in parallel, building several pieces and running reviewers at once up to its agent limit, which is new build-loop work that makes the pacing intent's criterion 6 testable (DR6); an undecided fidelity audit reopens the work, sending the feature back to a lane, and never closes like a pass (DQ1a, iss-2608290820473197); the audit moves before the merge, as part of the build loop's last lane (per ruling AI), and until that loop is ready it stays after the merge and reopens on an undecided or failed verdict (DQ1b, iss-2608290822140563); the filing-time duplicate check covers every route, the promoted inbox report, the consistency pass and the reading ingest, in a lane after remedyRequired (DQ2, iss-2609281911024185); `abcd ahoy` offers to install gh on an explicit yes (DQ3, iss-2609281911024838). KEEP: a promoted inbox report's own remedy is kept but not usable: the sender's suggestion stays in the issue's text for reference, the remedy field is `none (filed automatically)`, and a drain skips the record until a person writes the fix, so the conservative default recorded above on 2026-09-30 stands and is not widened (CL1). The person added to CL1 that when a person comes to write the real fix for such an issue, the agent offers a state-of-the-art research pass first (principle `prefer-sota`), which `commands/capture.md` says under the `capture remedy` verb. The three rulings of 2026-09-29 owed to this ledger by earlier sessions of the run, the ceilings of five and of eight sub-agents and the remedies ruling, already have their entries above, so this entry adds none.
- itd-165A failed fidelity verdict becomes work somebody can see