dotfiles/claude/reviewed-drafts-2026-07-28.md

REVIEWED drafts — 2026-07-28

Copy-paste-clean blocks for ~/REVIEWED.md, drafted by the executor. Nothing here is a ruling until the steward places it. The decision lines record what the steward said in session; where a decision was not stated, both variants are given and the choice is left open.

Place in numeric order. Three entries, not two — see the note at the bottom on why REVIEWED-78 is needed even though PENDING-78 is resolved by REVIEWED-81.

---

REVIEWED-78 — Claude.app personal preferences: three verified-false claims

## REVIEWED-78 — Claude.app personal preferences: three verified-false claims
**Date:** 2026-07-28
**Decision:** AUTHORIZED
**Notes:** Resolved in full by the fresh preferences draft placed under REVIEWED-81, which
repairs all three claims at their source rather than patching them: the `fix/replay-durability-
contracts` branch pointer (merged as `c9746ae`; HEAD is `main`), "L2 blocked pending L1 stability"
(L1 dormant 30 days — re-expressed as an open question rather than a status), and the ARC
"near-operational" framing (Stage G sealed 2026-06-10 — finished and quiet, not nearly ready).
Recorded as its own entry rather than folded into REVIEWED-81 for a mechanical reason: the
closure rule in `wake-digest.py` matches a PENDING item to `REVIEWED-<same number>`, so a
cross-numbered closure stated only in prose would leave PENDING-78 listed as open at every wake.
**If AUTHORIZED:** Closed by the placement of the fresh preferences document. No further work.

---

REVIEWED-81 — Keeping CLAUDE.md and the Claude.app preferences fresh with respect to each other

## REVIEWED-81 — Keeping CLAUDE.md and the Claude.app preferences fresh with respect to each other
**Date:** 2026-07-28
**Decision:** AUTHORIZED
**Notes:** Finding #1 ruled by the steward: **Cowork is not a party.** Removed from the Claude.app
preferences by the steward the same day; `COWORK.md` and every reference to it go with it. Two
grounds, the second only visible once the MCP question was answered: a third executor costs a
third copy of doctrine that is `CLAUDE.md` with the nouns changed; and Cowork could not have
served as the jurist's filesystem eyes even in principle, since `coworkUserFilesPath` points at
`~/Claude`, which does not exist, and remote Cowork — the incoming default execution mode — runs
no local MCP server at all.

The §Standing Context split is authorized and drafted afresh at
`~/dotfiles/claude/app-preferences-draft-2026-07-28.md`, from the live text the steward pasted.
Doctrine and identity sections are preserved verbatim — PENDING-81 established they do not drift,
so rewriting them would have been loss disguised as tidying, and the census that would have
licensed it was not run. Every repair is confined to §Standing Context, which is where every
finding in PENDING-78 and PENDING-81 actually sat.

Three tiers, because the parts fail in three different ways: **Projects** (generated by
`wake-digest.py --brief`, dated, replaced wholesale), **Live questions** (hand-held but phrased as
questions — *"what has to be true of L1 first?"* survives time in a way *"L2 blocked pending L1
stability"* did not), and **Personal** (steward-held; the generator excludes it by design, not by
convention, and no instrument pretends to check it).

Two divergences were flagged rather than decided, correctly: "principal **ethics** architect"
(preferences) against "principal architect" (`CLAUDE.md`) — a conflict between records is a
verification trigger, not a precedence call; and the divorce entry's four-month-past date, whose
operative instruction ("treat as closed") was preserved exactly while the stale "awaiting" was
removed for the steward to restore if wrong.
**If AUTHORIZED:** Steward pastes the fresh document into Claude.app. Executor keeps the durable
copy in `~/dotfiles/claude/` current, and the wake continues to report the generated block's age
past 30 days — tracking **generation, not pasting**, which is a lower bound on the jurist's
staleness and never a guarantee of freshness.

---

REVIEWED-82 — Read-only MCP server: giving the jurist eyes on the substrate

## REVIEWED-82 — Read-only MCP server: giving the jurist eyes on the substrate
**Date:** 2026-07-28
**Decision:** AUTHORIZED
**Notes:** Steward confirmed that local MCP servers are exposed to Claude.app's **chat** surface
and always have been, predating Cowork by about a year. The executor's framing ("chat, not only
Cowork") was 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, which makes this design less exposed to product drift than the Cowork-dependent
alternative that was considered and rejected.

`~/dotfiles/scripts/governance-mcp.py` is authorized for installation via the `mcpServers` key in
`claude_desktop_config.json`. Five read-only tools; the one no pasted cache can ever match is
`governance_item(id)`, which returns the **verbatim** body of any item or ruling — the jurist can
read the thing it is ruling on instead of ruling on a summary of it.

Four refusals are designed in, each with a same-run control proving the refusal detectable: no
writes (audited by AST — 0 mutating calls, git subcommands `{log, status}` only); no path
arguments at all (keys from a fixed enum, so there is no traversal to defend and the reachable
domain is enumerable rather than defined by the instrument); no second parser ("an item" is
defined once, in `wake-digest.py`'s `item_spans()`, imported); and not an agent (a tool returns
data, where a second Claude sent to look would return testimony about the substrate).

Verified: 29 self-test controls pass, 0 fail, plus a live stdio round-trip — `initialize` →
`notifications/initialized` (correctly unanswered) → `tools/list` → two `tools/call` → malformed
input surviving as `-32700` rather than a crash, with only JSON-RPC on stdout and stderr empty.

Reading is not executing: the role boundary is unchanged. The `[FIX]` to `item_spans()`
fence-awareness carried in the same commit changed no behaviour today (17 open items before and
after) but closes a latent defect whose trigger is the steward's own drafting practice.
**If AUTHORIZED:** Steward merges the `mcpServers` key and restarts Claude.app. Reversal is
deleting the key. Tag any follow-on commits REVIEWED-82.

If the steward prefers to wait, substitute:

**Decision:** DEFERRED
**Notes:** [as above]
**If DEFERRED:** The server is inert — nothing loads it until the `mcpServers` key exists. Revisit
when the steward wants the jurist reading the substrate directly rather than through the generated
brief. No work is blocked meanwhile; `wake-digest.py --brief` remains the fallback.

---

Why three entries and not two

wake-digest.py's closure rule resolves a PENDING-<n> against a REVIEWED-<n> by number. So an item closed only in another entry's prose stays "open" to every consumer of that rule — it would appear at every wake and in every generated jurist brief indefinitely. REVIEWED-78 exists to make a real closure legible to the instrument.

This is worth noticing on its own terms: the closure mechanism cannot express "closed by a different item." Today that costs one extra stub entry, which is cheap and honest. If cross-numbered closure becomes common, the rule needs a **Closes:** field rather than a convention — that would be a [HARDENING], not something to decide here.