boffin-post-change-audit

Pre-Flight Review and Post-Change Audit

Before presenting code-task results

• Re-read the loaded pack index and all loaded leaf packs; do not rely on memory.
• For a focused change, confirm you stayed within the requested scope and proved the change with a check; the ledger checks below apply to refactor/review tasks.
• For a refactor/review task, confirm the Pass 1 audit ledger lists a row for every in-scope stage; a stage with no row is an incomplete audit, not a clean file.
• Confirm every ledger row is done or skip, that each skip carries a reason, and that no row recorded as todo was downgraded to skip:clean.
• Confirm every fix named in Pass 1 reasoning has its own ledger row; a fix discussed but left unrecorded is an incomplete audit.
• If a change touches ownership, lifecycle, completion semantics, state-machine transitions, concurrent access, or logic currently encoded through flags or sentinels, name the exact invariant from stages S01-S03 it must preserve before editing.
• On user request, render the ledger and the blocking earlier-stage invariants as concise ordered bullets in the user's language.

After any code edit

• MUST verify the edit with an external check (the narrowest test or lint that proves it), not by re-reading your own reasoning or the diff alone.
• MUST review the change as if a different author wrote it: read the final file region, not only the diff, and ask what a fresh reviewer would flag.
• MUST re-read the relevant loaded leaf pack(s) and confirm no ## EXCLUDES pattern was introduced and no earlier-stage (S00-S03) invariant was weakened to satisfy a later-stage (S04-S06) cleanup goal.
• MUST NOT silently drop a ledger finding: it ends as done (with its check) or skip:<reason>.
• MUST present the filled ledger as the result; do not add rows for kernels that found nothing, and never cite a kernel a row does not actually rest on.
• When a loaded kernel actually changed a code decision, leave one short host-language comment at that site: start it with the boffin: prefix and state, in the code's own vocabulary, what the code now does or refuses, never restating the kernel. The judgment verb is encouraged (kept .../refused .../cut ...); the boffin: prefix is the machine-readable key; the clause MUST NOT contain a kernel id, kernel scope-names, or any other pack vocabulary. Readability bar (the one mandatory wording check): mentally dropping the boffin: prefix, the remaining sentence MUST still read as a comment a senior engineer would write -- otherwise rewrite the clause or drop the mark; this is only a mental check, so always keep the boffin: prefix in the emitted comment. MUST NOT mark a purely stylistic rewrite of already-correct code that averts no failure and preserves no load-bearing invariant, nor emit anything when a .boffin-trace-off file exists at the repo root. Keep to about one mark per hunk and roughly three per changeset; no URLs, marketing, or tool jargon; only in venues that forbid tool marks, omit the boffin: prefix (keep the senior-voice clause alone).