Commit Graph
6 Commits
Author SHA1 Message Date
David F Glidden 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 19bddd5 (2026-08-08), wired to SessionStart, with controls. The
gap was that the executable was incomplete, and the incompleteness had already
produced a false positive.

Four defects, three named in the spec and one found by building it:

1. CODE SPANS. `](file.md)` inside backticks read as a pointer, so the single
   DEAD pointer reported on 2026-08-09 was the link pattern written inside
   MEMORY.md's own specification of this canary. An instrument that flags its
   own documentation flags it every wake forever, and the real signal drowns —
   the same "known canary bug" dismissal the 2026-07-28 block was written to
   end, arriving by a second route. Fences and inline spans are blanked with
   offsets preserved; inline spans may not cross a newline and an unterminated
   fence does not match, so a stray backtick can never blank the file and HIDE
   dead pointers.

2. WIKILINKS. reference-verification-ladder.md has specified this canary as
   covering "every `](file.md)` and `[[wikilink]]`" since 2026-07-06. Only the
   first half was ever built. 31 wikilinks now checked.

3. BREAKAGE AGE, derived from git rather than a stored prior run — a state file
   would make this the one cached section in a digest whose governing property
   is that it is computed. Where git cannot answer, it says so.

4. Found by running it: the first wikilink pass reported only UNWRITTEN, and
   both live hits were [[trust-prior-pass-frame]], whose file EXISTS as
   feedback-trust-prior-pass-frame.md. That is precisely the one-word alarm the
   comment ten lines above it was written to forbid. Wikilinks now report three
   outcomes and hand back the replacement slug. Both are repaired here.

The wake-up skill and the ladder now POINT AT the executable instead of
describing the check — the described-not-invoked gap is why it kept being
retyped by hand on 2026-08-08 and 2026-08-09.

Verify: python3 scripts/wake-digest.py --selftest   (61 checks, exit 0)
        python3 scripts/wake-digest.py | grep 'MEMORY POINTERS'
Induced red: blank_code reverted to a no-op (behaviour, not the symbol) →
        exit 2, five named failures, no traceback; direction controls held.

Not changed: the wrap_inside detector, which announced "PREVIOUS SESSION DID
NOT WRAP" for a session that wrapped at 19:48 and kept working until 21:54 —
a two-valued detector over a three-case state. Named in the ledger, not fixed.
2026-08-10 16:01:51 +02:00
David F GliddenandClaude Opus 5 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
2026-08-03 20:57:41 +02:00
David F GliddenandClaude Opus 5 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
2026-08-02 11:59:47 +02:00
David F GliddenandClaude Opus 5 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
2026-07-28 14:10:03 +02:00
David F GliddenandClaude Opus 5 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
2026-07-28 10:20:17 +02:00
David F Glidden 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 2026-07-28 09:45:44 +02:00