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
