The diff touches only pipeline code, a test file, and a DECISIONS.md log entry — AGENTS.md is untouched, and no content/ records or citations are added (verification tooling found no identifiers). The change strengthens rather than weakens a check: `correctionBlocker` now covers `images.yaml`, the file the writer already knew, and the Corrections section of `verification.md` is rewritten from the writer's actual `applied`/`skipped` lists so the report records what happened rather than a pre-run forecast, with a stderr note when the two differ. That directly serves §3.14 and the provenance-honesty requirements of §3.15 by removing a case where two records of one run disagreed. The added tests pin both behaviours (an image record counts as in-ledger; the lines end in whatever the status function reports), and `correctionLines` is a pure helper so forecast and outcome are comparable. The DECISIONS.md entry describes the fix and stamps the founder direction with date and channel, consistent with the operating-record allowance. My only reservation is stylistic — the rewrite uses a string `replace` of the forecast block, which could silently no-op if the forecast text ever fails to appear verbatim — but that is ordinary implementation risk, not a constitutional violation.

The change makes the verification record reflect the correction writer’s actual applied and skipped outcomes, eliminating contradictory provenance for a single run. It also extends the pre-write blocker lookup to image records and adds tests for both image lookup and outcome rendering. This strengthens rather than weakens the fail-closed checks and visible run history required by §3.14 and §3.15. No content citations, confidence material, constitution edits, or fabricated provenance are introduced by the shown diff.

seat failed: SyntaxError: Unexpected token '§', ..." ["§3.8", §3.14", §3"... is not valid JSON

The diff only touches verify.ts, its tests, and a DECISIONS.md log entry. It widens correctionBlocker to include images (matching ledgerFileFor) and rewrites the Corrections section from the writer's applied/skipped outcome so the report cannot disagree with the run. That tightens honesty of provenance and does not fabricate citations, publish confidence material, edit AGENTS.md, or weaken §3.15 checks. No content/ ledger or run records are in scope.

This is a code fix that makes the verification report truthful, not a weakening of §3.15's checks: the correction writer already searched five ledger files (including images), so the report's four-file lookup was simply wrong, and expanding correctionBlocker aligns the report with reality rather than loosening any gate — the writer still applies or skips each correction on its own merits. Rewriting verification.md's Corrections section from the writer's own applied/skipped lists replaces a stale forecast with the actual outcome, and the discrepancy is disclosed on stderr rather than hidden, which serves the §3.14/§3.15 accountability aim (two records of one run must not disagree). The fallback label 'NOT applied: the writer did not apply it' is honest when no skip reason exists. The DECISIONS.md append is the normal decisions log, not an edit to AGENTS.md, so §3.15's amendment reservation is not implicated; no citations are added; and no content-run records are carried. I see no fabrication, confidence exposure, check-dodging, or provenance misattribution in the visible diff.