Restore three commits dropped when PR #101 merged short of the branch tip

[b-macker]

Summary

PR #101 merged at 85b29da, three commits behind the branch tip, and the branch was then deleted. Those three commits were not squashed into master — verified absent by content, not just by SHA — so they existed only in one ephemeral container clone and would have been lost when it was reclaimed.

This restores them unchanged. Two are from the session doing the engine/test work, one is mine.

Commit	Origin	Contents
555b67d	engine session	Pulse degradation streak fix — report the streak that caused the degradation rather than the post-reset zero (governance.h, governance_engine.cpp, test_pulse_uniformity.sh)
29d8b47	engine session	test_developer_blindspot.sh (337 lines) + run-all-tests.sh wiring — tests whether a 1.0 coherence score is measurement or the absence of it
1757371	this session	Fixes a misleading log line in the living-script (see below)

No rebase or conflict resolution was involved: origin/master is exactly 85b29da, so this branch is a clean fast-forward of master plus those three commits, byte-identical to what was on the branch before deletion.

Why the third commit matters

Run 7 logged OA|developer|commit_inadmissible|score=0.625 against a 0.60 threshold, and it was read — reasonably — as the gate refusing a candidate whose score had passed. That is not what happened.

agentCommit derives output_admissible from a live checkOutputAdmissibility() call against the handle's current coherence (0.51–0.53 at that point in the run). The score in the returned admissibility dict is the propose-time candidate score and plays no part in the verdict. Printing it beside the word "inadmissible" put the one number that did not decide the outcome where a reader would take it as the one that did.

It is now labelled propose_score=…|verdict=coherence_at_commit, pointing at the OUTPUT_INADMISSIBLE telemetry (source=agent.commit) — the only place the deciding coherence and threshold are recorded, since agent.commit()'s response omits both while including the score that did not matter.

Test Plan

This exact tree was built and tested before the branch was deleted:

• Rebuild including the engine session's changes — clean
• bash run-all-tests.sh — 441 accounted for, 0 unexpected fails
• All nine of the engine session's new governance tests pass (test_adversarial_detection, test_challenge_discrimination, test_developer_blindspot, test_drift_sensitivity, test_failure_mode_coverage, test_pulse_uniformity, test_quarantine_corroboration, test_signal_discrimination, test_validation_signal)
• Merged govern.json parses under the new binary with no unknown-key warnings
• --lint-only clean on the living-script
• Live run with real API keys on this combined tree — not yet done

One thing worth watching after this lands

The two sessions independently attacked the same quarantine_streak kill from opposite ends, neither aware of the other:

• require_corroboration: 2 (engine session) — the streak only advances when 2 distinct signals fired
• step_up_cooldown_turns 2→1 (this session) — recovery challenges fire twice as often

Each is defensible alone, and the corroboration change is the better-evidenced of the two. But compounded, the quarantine kill may now be hard to reach at all — and a run that always completes looks like success while the output-admissibility demonstration quietly stops demonstrating anything. Runs 3, 6 and 7 all ended on quarantine_streak; if the next live run sails through with SUMMARY_OA_MAX_STREAK at 0–1, that is the hypothesis to test rather than a result to celebrate. My cooldown change is the one I would revert first, since it was a judgement call and theirs has live evidence behind it.

---

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}