Stop the chain verifier from reporting tampering on its own output

[b-macker]

Summary

L24-06 — the level added in #106 precisely because the example had been building a tamper-evident chain nothing ever verified — failed on real run files:

BREAK in run …: RunEnd declares 717 chained events but 770 observed

That is a hard BREAK, exit 1, on files nobody had touched.

emitEndOfRunHealthWarnings() is the only chained-telemetry writer in the engine that did not go through chainPrevLocked(). It seeded prev_hash from the in-memory last_telemetry_hash_ and never incremented chained_events_this_run_. Three symptoms from those two lines:

• RunEnd under-declared its count, so the verifier reported tampering.
• When the warnings were a process's first chained events the in-memory hash was empty, so prev_hash fell back to genesis mid-file — a spurious LEGACY RESTART on any shared telemetry file.
• The lazy RunStart anchor landed behind the events it anchors, because only chainPrevLocked() emits it.

Reproduced on a print("hello") script with governance_health, CDD and BSD enabled and no agent activity: 4 chained events, RunEnd declaring 2. The unit is 2 per affected run — the two inert-instrumentation warnings — which matches the diff observed across four live run groups. The originally reported 53 was an artifact of aggregating run groups, not one large gap.

A verifier that cries tamper on its own output is worse than no verifier: it trains the reader to ignore the one signal meant to be unignorable.

Changes

• src/runtime/governance_engine.cpp — emitEndOfRunHealthWarnings() now does what every other chained writer already does: chainPrevLocked(fp) plus the counter increment, inside the lock the lambda already held. No new lock, no lock-ordering change; chained_events_this_run_ was already guarded by telemetry_hash_mutex_ at every other site.
• tests/governance_v4/test_evidence_chain.sh — Group E (4 assertions). E-01 is the control: without health warnings actually firing, E-02..E-04 would be vacuous. E-02 verifies a shared file across three runs, E-03 checks declared-vs-observed counts per run_id, E-04 checks anchor ordering.
• docs/governance-campaign-findings.md — new Transition-admissibility phase section covering the five defects from Test that a blocked action leaves no trace of having happened #104–Govern the example's LLM-output-to-execution flow #108 plus this one, each with mechanism, pinning test, and a separately-scoped live status. Adds a fourth method note recording the defect class this phase kept producing: an assertion that looks specific but is satisfiable without the property holding (C-05 matching an empty value, L24-02's unsound equality, L25-03's wrong-scope total). Running the degraded case was the only defence that ever caught it.
• CLAUDE.md — states the invariant as an invariant: every writer emitting a prev_hash/hash pair must use chainPrevLocked(fp) and increment the counter, both under telemetry_hash_mutex_.
• examples/living-script_extended/run.sh — records the second keyed observation against the L25-03 taint baseline (see below). Comment only; the threshold is unchanged.

Test Plan

• Ran bash run-all-tests.sh with no new failures — 441 tests, 0 unexpected failures (376 passed, 52 error-behavior, 1 missing-executor, 12 needs-tree-walk)
• Added/updated tests for new functionality — test_evidence_chain.sh Group E, 24 assertions total in the file, all passing
• Vacuity-checked: reverted the fix, rebuilt, re-ran. E-02, E-03, E-04 all fail; E-01 (the control) still passes. Group A passes either way — which is why this defect survived.
• bash tests/security/test_error_msg_leaks.sh — 874 checks, 0 failures
• Tested manually in the REPL — n/a, this path is only reachable at end-of-run report time

Before and after, three runs sharing one telemetry file:

# before
BREAK in run …: RunEnd declares 2 chained events but 4 observed   (×3)
LEGACY RESTART at event 5: chain re-seeded from genesis
Chain BROKEN: 3 break(s) in 12 chained events

# after
Scanned 12 lines: 12 chained events across 3 run(s), 0 unchained line(s)
Chain verified: 12 chained events, no breaks (0 warning(s), 0 legacy restart(s))

Not in this change

Tightening the L25-03 taint baseline. The second keyed run put the count at 7–8 against a ceiling of 18, which is loose — a leak would need to add ~10 violations to trip it. But the 18 came from a less complete run (feature 2 never finished) and the 7–8 from a more complete one, so the count is not monotone in run length. Two non-monotone points do not support picking a lower number, and a baseline that fails on a healthy run teaches everyone to raise it. Left at 18 with both observations and the reasoning recorded next to it; tightening properly means attributing the spread to one of the four contributing sites, which is its own change.

Related Issues

Follow-up to #104, #105, #106, #107, #108. The defect was surfaced by the verifier added in #106.

---

Generated by Claude Code

[github-actions]

NAAb Governance Report

Metric	Count
Files checked	16
Passed	16
Failed	0

All governance checks passed!

_{Generated by NAAb Governance Engine v4.0}