sec_pending() suppressed any PENDING-N whose number appeared as a REVIEWED-N,
never checking the ruling was about that item. The two sequences have drifted:
REVIEWED-84 rules on PENDING-87. So PENDING-84 was invisible at wake on the very
morning the steward's pulling thread pointed at it, and closing it later produced
no visible count change because it had never been counted. Found 2026-08-01 at
wake, surfaced not fixed; register row 179.
Resolution now reads the PENDING each ruling names in its header. Rulings that
name none (REVIEWED-78, -81, -82) suppress nothing.
Extracted as ruled_pendings() so it is testable at all -- the logic was buried in
a file-reading routine with no way to exercise it. Five self-tests added,
including the 2026-08-01 bug as a regression control and an empty-input positive
control.
Bounded-change proof against the live files: 18 -> 19 visible. Three items
surfaced that were falsely hidden (PENDING-78, -81, -82); two stopped being shown
that are genuinely ruled (PENDING-87 by REVIEWED-84, PENDING-88 by REVIEWED-85 --
no REVIEWED-87 or -88 exists, so number-matching had never suppressed them).
That proof also caught an overclaim in this fix's own docstring, which asserted
the correction could only ever surface more items and never fewer. It corrects in
both directions. Comment repaired to say what the code does; the false version
would have been a comment promising behaviour the code does not deliver, in a
file whose purpose is to stop governance hiding from the steward.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
Two loose ends closed before the Harrison re-gate, both surfaced by the steward.
Memory pointers. Six links in MEMORY.md / MEMORY-reference.md pointed at files
that all existed, via hand-counted relative depths that resolved from neither of
the memory dir's two addresses (it is ~/dotfiles/claude/memory, symlinked from
~/.claude/projects/…). The wake canary detected this correctly FOUR times over
two days and the banked remedy was to change the canary's path resolution — i.e.
to silence a true positive. The defect was never the pointers: the alarm emitted
one undifferentiated word, MISSING, so every firing had to be re-diagnosed by
hand and the cheapest re-diagnosis is always "known bug". wake-digest.py now
reports four outcomes (ok / mis-authored / dead / non-portable), hands back the
exact replacement, and carries a regression control replaying this bug's shape.
Pointers are home-anchored (~/…), not absolute — steward's correction; absolute
hardcodes this machine into the repo whose purpose is surviving a machine change.
Maps. With the noise gone, one genuine dead pointer surfaced:
arc-current-state-2026-05-07.md, a live ARC dashboard the steward read to orient.
It lived only on the Desktop and went with a tidy-up. A census found four more in
the same condition, zero copies anywhere — including the Making-Sequence
architecture and reading list, load-bearing for current corpus work. The cause is
structural: code, session records and memories are durable; the one artifact
class addressed to the steward had no home. All five now live in maps/ and are
symlinked back to their exact Desktop paths (Desktop view unchanged), moved under
a checksum gate with a positive control. wake-digest.py reports stray Desktop
maps; it never moves them — the Desktop is the steward's.
How to verify:
python3 scripts/wake-digest.py --selftest # 28 controls, PASS
python3 scripts/wake-digest.py | grep -A3 'MEMORY POINTERS'
cd ~/Desktop && shasum -a 256 *.md # reads through the symlinks
What was not changed: ~/CLAUDE.md and REVIEWED.md untouched (Constraint #1). No
Desktop file was deleted or renamed. MEMORY-reference.md's May entry is marked
superseded, not rewritten.
Known limitation: maps/ has no successor for the ARC map's FUNCTION — the
open-work register carries the content, but nothing exists that the steward can
open and orient by. Named in the entry rather than quietly closed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
The three-party model asks Claude.app to rule on items it cannot read. Steward
confirmed 2026-07-28 that local MCP servers are exposed to the app's *chat*
surface — and always have been, predating Cowork by about a year. My earlier
framing ("chat, not only Cowork") had the relationship backwards: it is "chat,
always; Cowork, only while its loop still runs locally," and local Cowork is the
mode being phased out as default. The jurist chat is therefore the sturdy target.
Five read-only tools. The one a pasted cache can never provide is
governance_item(id): the verbatim body of any item or ruling, across PENDING.md,
PENDING-archive.md and REVIEWED.md. Four refusals are designed in, each with a
control proving the refusal is detectable — no writes (AST-audited), no path
arguments (keys from a fixed enum, so there is no traversal to defend), no second
parser (item_spans is imported, not reimplemented), and not an agent (tools
return data; an agent would return testimony about the substrate instead).
[FIX] to the shared definition while here: item_spans() is now fence-aware. A
'## ' header inside a fenced block is neither an item nor a boundary. Zero such
headers exist today — 17 open items before and after — but governance drafts are
written as fenced markdown carrying '## REVIEWED-N' headers, which is the
steward's own practice, so the next draft would have created a phantom item and
truncated the item containing it. PENDING-82's own fenced JSON block confirms the
fix within the hour.
Not installed. The mcpServers key edits the steward's desktop-app config; the
snippet is in PENDING-82 and the server is inert until someone loads it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
