ebd0aa76489b417558aa8e028f56f2d83debc0e0
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
32b0c9dfc6 |
[FIX] The link canary was blind to code spans, to wikilinks, and to its own class
The steward's 2026-08-09 to-do read "the gap is neither knowledge nor home but
the absence of an EXECUTABLE." The premise was false: classify_pointers has
existed since
|
||
|
|
0a48e6934d |
[FIX] L1 pin root-caused and cleared; S-series closed; instrument census
mindfabric-00 had been event-loop-pinned for 6+ days (100% CPU, /health silent).
Profile + CDP inspector named two hot paths, both from runTemporalPipeline:
checkForCycle -> getCausalEdgesFromSqlite 99.8% of samples
tryExtendChains -> getChainsContainingSeq now dominant (json_each scan)
Cause of the first: ANALYZE had never been run, so SQLite preferred a boolean
index (idx_caused_tombstoned, matching ~all 836k edges) over idx_caused_from.
ANALYZE across 15 module DBs flipped the plan; 6.4x on a microbenchmark and
99.8% -> 6.0% in the live profile. /health went from silent to 200 in 0.13s.
B1.1's fan-out cap is IMPLEMENTED AND WORKING (today: max in-degree exactly 20,
zero violations; pre-23-June: max 629, avg 67.6). The defect is data, not code —
836k edges / 813k chains minted under ungoverned fan-out before the fix landed.
Repair run: derived stores wiped, logchain preserved, replay in flight.
S-series closed (jurist had already ruled all of Q1-Q5 on 2026-05-18):
S6/S7/S9 implemented (Symmetria §3 flags, `suspend` outcome, wrap-up §8 tenses)
S2 rebuilt as [FIX] — wake-digest unwrapped-session detector, discrimination-
gated on real sessions (11 wrapped / 2 unwrapped)
S4/S5 withdrawn with MemPalace (steward ruling)
Dormant legacy dispositioned: PENDING-4/5/11/12, CD-03, ICP-19 duplicate.
Open authorization items 22 -> 10.
Census 01: which instruments have no real negative instance. Finding — the
governance drift-check has 3 of 5 families inert against the current CLAUDE.md,
and 71 of 75 verification-ladder entries are cited nowhere outside the ladder.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WuMjg3ipEVa3n8CoSzoyvc
|
||
|
|
4dc38e69b9 |
[FIX] wake-digest: resolve rulings by subject, not by number
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 |
||
|
|
19bddd5ecb |
[FIX] A home for steward-facing maps; memory pointers made portable and self-diagnosing
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 |
||
|
|
3df09228c0 |
[PROPOSAL] governance-mcp: read-only substrate access for the jurist (PENDING-82)
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
|
||
|
|
8abfe8835a | session 2026-07-28: governance block closed — CLAUDE.md drift 9→0 (REVIEWED-76/77/79/80), PENDING.md split 1848→430 + archive, wake-digest SessionStart hook, doctrine ids live, PENDING-79/80/81 |