refactor(review): state the fix-delta scope instead of certifying it

Thirty review rounds went into making `fix-delta` certify that its hunks were the whole edit: nested-repository digests, ignored-path and symlink classification, sparse/skip-worktree bits, redirected excludes, filter screening, record fingerprints. fix-delta.ts grew from 222 to 5,680 lines and held 142 of the loop's 185 Criticals, each round's fixes opening the next round's entrances — for a check whose output is a disclosure that changes no verdict. Replace the certification with a fixed scope printed on every `--since` run: the hunks hold what `git add -A` records in this repository, and an edit inside a submodule or nested repository, or to a gitignored file, is named as outside it. What stays is what the audit needs: the throwaway-index capture, the review's own side files excluded (both the name and the directory form, at any depth, plus the command's own --out/--since), the second capture seeded from the snapshot tree, and a moved-HEAD disclosure. HEAD is now read once and the capture is seeded from that sha, so the record and the tree describe one moment (R30-1). agent-prompt drops --hunks-fingerprint and the C-quoted patch-path parser; whether a fixed finding's edit is among the hunks is now the auditor's check, which has both in front of it. SKILL.md Step 6B, DESIGN.md and the user docs follow; lib/worktree.ts is back to main and lib/git.ts keeps only gitWithEnv.
wenshao · Sep 24, 2026 · Aug 26, 2026 · Aug 26, 2026 · Aug 26, 2026 · Aug 27, 2026
commit 2f1bf302d46f285ef95d334cdbc3e7243cba84a1
diff --git a/docs/users/features/code-review.md b/docs/users/features/code-review.md
@@ -234,7 +234,7 @@ A finding is skipped when its fix would change intended behavior, would need cha
 
 **Every finding gets an outcome, and this is enforced rather than requested.** The ledger goes through `qwen review findings --outcomes`, which refuses a set that does not cover all of them — a fixer that applies six of nine findings and reports six has not lied about any one of them, it has silently shortened the list, and you would have no way to see the three that fell off.
 
-**The applied fix is then audited — by one agent, and not by re-reviewing your tree.** The review does not re-run itself over code it just edited (that would be a new review of different code, wearing this one's verdict). Instead it records your working tree before the first edit (`qwen review fix-delta --snapshot`, through a throwaway index — your own index and stash are never touched), diffs the tree against that record afterwards (`fix-delta --since`), and hands exactly those hunks, together with the `fixed` findings each claims to close, to a single `fix-audit` agent. That agent never sees the reviewed diff and files no findings. It answers one question per hunk: what does this edit newly assume — a bound, a key, a lifetime, a shared resource, an ordering — and does anything in the tree pin it (a test that goes red, a type, a single source the value derives from)? Only the unpinned ones come back, each with what would pin it. They are reported in a **Fix audit** block in the terminal and as the affected finding's outcome note; they are not findings, change no verdict, and are left for you to act on — the measured reason this exists is that a third of a multi-round review's later findings were introduced by the fix immediately before them, and the two Criticals a real fix round shipped were exactly assumptions of this kind that a mutation probe of the intended fix sites could not reach (that round was a PR review whose author applied the posted comments — the path this audit does not run on; it runs where `--fix` is effective, on local and file targets). If nothing was `fixed` and nothing was applied, the audit is skipped and says so; if the ledger and the tree disagree — no `fixed` outcome beside hunks that landed — you are told, because that is a bookkeeping problem rather than an audit question; a `fixed` finding no hunk touches is annotated in the auditor's input rather than refused, since a fix can legitimately land entirely in files the finding does not name. And because the hunks are the audit's whole input, the snapshot command also reports what it cannot see: uncommitted content inside a submodule or a nested repository (an edit there moves no gitlink, so no tree records it), paths its probe could not resolve, a HEAD that moved between the two moments (a change that landed by commit alone — an ignored path force-added, a tracked path untracked — leaves no hunk, because the second capture is measured against the snapshot's own tree rather than against the new commit), and repo-local git configuration that shapes what is captured or how it renders — a content filter, a `.git/info/exclude` rule, or a `diff` attribute that turns a text edit into an opaque binary patch. The capture itself never runs inside a submodule or nested repository, so nothing configured there is executed on your behalf.
+**The applied fix is then audited — by one agent, and not by re-reviewing your tree.** The review does not re-run itself over code it just edited (that would be a new review of different code, wearing this one's verdict). Instead it records your working tree before the first edit (`qwen review fix-delta --snapshot`, through a throwaway index — your own index and stash are never touched), diffs the tree against that record afterwards (`fix-delta --since`), and hands exactly those hunks, together with the `fixed` findings each claims to close, to a single `fix-audit` agent. That agent never sees the reviewed diff and files no findings. It answers one question per hunk: what does this edit newly assume — a bound, a key, a lifetime, a shared resource, an ordering — and does anything in the tree pin it (a test that goes red, a type, a single source the value derives from)? Only the unpinned ones come back, each with what would pin it. They are reported in a **Fix audit** block in the terminal and as the affected finding's outcome note; they are not findings, change no verdict, and are left for you to act on — the measured reason this exists is that a third of a multi-round review's later findings were introduced by the fix immediately before them, and the two Criticals a real fix round shipped were exactly assumptions of this kind that a mutation probe of the intended fix sites could not reach (that round was a PR review whose author applied the posted comments — the path this audit does not run on; it runs where `--fix` is effective, on local and file targets). If nothing was `fixed` and nothing was applied, the audit is skipped and says so; if the ledger and the tree disagree — no `fixed` outcome beside hunks that landed, or a `fixed` outcome beside no hunk at all — you are told, because that is a bookkeeping problem rather than an audit question. A `fixed` finding whose file no hunk touches is reported by the auditor as unattested rather than refused, since a fix can legitimately land entirely in files the finding does not name. The hunks have a fixed scope, printed beside the audit: what `git add -A` records in your repository — tracked files, and untracked files no ignore rule hides. An edit inside a submodule or a nested repository, or to a gitignored file, is not in them, and a commit made between the snapshot and the diff is reported, since a change that landed by commit alone leaves no hunk.
 
 ## Resuming an interrupted review (`--resume`)