Two unrelated things found while establishing what PENDING-134 actually
needs, which turned out to be nothing.
1. governance-mcp.py --selftest was FAILING. The delegate read-only
guarantee flagged five undeclared mutating calls in wake-digest.py,
all inside selftest(), all added by yesterday's REVIEWED-131 (e)/(c)
build: a job dir with state.json, and two transcripts with and
without a human turn.
Declared rather than detector-widened, because failing until someone
names it is the mechanism's design, not an obstacle to it. Why it is
safe: every write goes to a tempfile.mkdtemp() tree the same function
removes, and selftest is reachable from --selftest alone, never from
a tool call. Its weakness is declared in the same comment: this is a
FUNCTION-level exemption, so a future non-tempdir write inside
selftest now passes silently. The narrower rule — "writes confined to
a tempdir" — is not expressible in this check without data-flow
analysis, and naming that limit is preferred to a detector that would
be wrong in a harder-to-see way. Selftest now PASSES, 62 controls.
2. MEMORY.md said "ratio_A_to_B VOID until PENDING-134 lands" and
"NEXT: rule PENDING-134". Both stale by 18 days: PENDING-134 was
ruled REVIEWED-121 on 2026-08-14. REVIEWED-121's own closing sets the
real condition — re-derive ONCE after BOTH it and PENDING-137 land —
and PENDING-137 is still [PROPOSAL], awaiting a jurist ruling. The
live blocker on the fr cell is -137, and it needs the jurist, not the
executor.
Corrected in place with the superseded text quoted, per the memory
discipline: a conflict between a memory layer and the substrate is a
verification trigger, and the substrate wins.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vKkg2EJF1rGwdFdBogwqx
