fb02605735e5071c77f6ac9e49558236f1d47bf3
13
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 David F GliddenandClaude Opus 5
|
9d152f1d48 |
[FIX] The closure rule reads three header forms the register writes, and declines a fourth
ruled_pendings() intended to detect "the PENDING ids that rulings actually DISPOSE OF" and matched exactly one header form. The register writes four. Censused over 132 placed rulings: 80 em-dash single, 3 parenthetical, 1 plus-joined, 1 slash-joined, 47 naming no PENDING at all. Eight items were counted open while ruled — four of them by the three most recent rulings — which is how the queue reported 64 when 56 was defensible. [FIX] against existing specification: the code failed its own stated intent, and no ruling widens it. Also read: closure declared on an item's own **Awaiting:** line. Two items were counted open with their own bodies saying otherwise (PENDING-82 "CLOSED 2026-08-08", the STATE-CLAIM marker "DISCHARGED 2026-08-26"), because the rule read headers only. THE SLASH-JOINED FORM IS DECLINED, AND THAT IS THE LOAD-BEARING PART. Its sole instance is REVIEWED-116 — PENDING-131/132/133/134, a design gate on a package rather than a disposition of four items, and PENDING-133's body still reads "Awaiting: Steward authorization". Reading it would have falsely closed a live item. Closure detection HIDES items, so an unrecognised form never yields the permissive answer (REVIEWED-132 condition 1). unreadable_ruling_headers() reports the decline so the gap is visible rather than looking like a clean pass. The same reasoning set the body-closure anchor. A bare \bCLOSED\b search of item bodies matches 20 items, including PENDING-95, -108 and -109 — all live, all merely discussing closure. Anchored to the Awaiting line it matches exactly the two closed. Controls are paired throughout: every form that is read has a negative twin holding the form that must not be. 99 controls pass. Verified end-to-end against the live register, not by selftest alone: 64 -> 56, and PENDING-133 still visible. PENDING.md is NOT touched. Widening the instrument to the record is authorized; normalising the record to fit the instrument is not (REVIEWED-132 §6). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X3L79vgAnt1x2kxvf23Qt7 |
||
|
David F GliddenandClaude Opus 5
|
70440db147 |
[FIX] REVIEWED-131: build (e) and (c), and annotate the digest per (b)
(e) parked_workers reads ~/.claude/jobs/<id>/state.json's respawnFlags — harness state, not the session, so its enforcement does not depend on the party checked. Fails to NOT ESTABLISHED, never to safety: a missing dir, an unparseable state.json, and an absent respawnFlags are each enumerated rather than counted as "no parked workers" (cond. 1). (c) human_turns counts genuine human turns in a transcript, discounting hook-injected and /clear-/exit records. Retrospective by construction and says so. Output names which control produced each line (cond. 2). (b) the OPEN QUESTION field is marked orientation-not-instruction, in the code and in the output, explicitly not a control (cond. 3). Two corrections found while building. json was never imported, which the top-level guard would have turned into WAKE DIGEST UNAVAILABLE at every session start — the selftest caught it on first run. And the first draft asserted that a STOPPED job carrying the flag would take a turn on restart; whether the daemon respawns a stopped job is NOT ESTABLISHED, and it now says so rather than claiming either way. previous_session() lifted out of sec_unwrapped so both consumers share one definition of "the session before this one" — this file already refuses a second definition of "an item". Controls run in both directions, two of them against the real transcripts: b7e7eb39 (the unattended session) returns 0 human turns, this session returns 10. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wn9mxsFjHJkzYjuDdrtxwp |
||
|
David F GliddenandClaude Opus 5
|
5a350c7059 |
[FIX] The wake digest read an anchor case its producer was never told to emit
The digest read `PULLING THREAD` and `LITERAL QUESTION` with a case-sensitive `str.find`. /wrap-up names these fields in prose — "The pulling thread", "**Pulling thread:**" — and has never mandated a case. The reader was demanding a shape its own producer had no instruction to write, so the wrap wrote correctly and the digest reported DEGRADED. Censused by running the real function over all 195 wrap files rather than by grep: 102 threads and 103 questions unreadable, of which 86 and 84 were present in the body in the wrong case. The remaining 16 and 19 are wraps that never wrote the field. After the fix: 16 and 19. Predicted and achieved agree. Second defect, distinct and found only because the first was traced to its class: the label terminator was "first colon within 40 characters", a proxy for "same line". When an aside pushed the colon past the window the function returned THE LABEL, and with the paragraph cut assuming label and content share a paragraph, a question written below its heading was invisible. The 2026-08-22 wrap hit both defects at once. The terminator is now the first colon on the anchor's own line, and a label that ends its line takes the paragraph below. Case-insensitivity alone would have let a narrative "…as the pulling thread showed…" outrank the field it describes, so a match in label position now wins over an earlier mention. Four checks added (71 -> 75), including that negative control and a positive control proving it cannot pass vacuously. Not changed: file selection (ledgers were already excluded correctly, line 124), frontmatter stripping, and the verbatim-never-summarised contract. The ladder's "61 checks" is stale — it was 71 before this commit — and stays stale: the ladder is frozen under REVIEWED-123 and this is not an exemption. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JQKeKY9T9d95KpvHwwok8T |
||
|
David F GliddenandClaude Opus 5
|
fb7bd6849f |
[FIX] REVIEWED-122 conditions 6, 7, 11 — and a fifth defect class found by the ruling's own placement (REVIEWED-122)
Executes the three legs REVIEWED-122 severed from the gated mechanism. COND. 6 (second requirement, which the earlier docstring commit did NOT discharge): checked what else relies on the discarded reading. Two sites. (1) The selftest asserts `ruled_pendings ignores a ruling that names no PENDING` using REVIEWED-82 as its fixture — a real AUTHORIZED ruling on PENDING-82, presented as an example of correct ignoring. The assertion is mechanically true and stays true; what is wrong is the fixture and what the name implies. Annotated, NOT repaired: the repair sits inside the gated mechanism. (2) governance-mcp.py asserts `governance_state item count == sec_pending()` — a count-based agreement check, the exact shape finding 9 names, which passes regardless of whether the classification is right. Reported, not changed. COND. 7: PENDING-121 restored to the open list by hand as PENDING-143, a disclosed CARRIER. Direct restoration was impossible without one of three acts the executor may not take — editing REVIEWED.md (Constraint #1, and cond. 5), inducing a Class-A header (trading hidden for unclosable), or changing the gated parser. The carrier is labelled as a proxy, not as the item. -124 and -128 deliberately not carried: cond. 7 preserves their UNDETERMINED status. COND. 11: filed separately as PENDING-144 rather than folded — script-resident substrate claims are checked by nothing, including the drift-check. One confirmed occupant; population explicitly unmeasured. AND A FIFTH DEFECT CLASS, found by watching this ruling land. A ruling claims a NUMBER, not a record. REVIEWED-122 named PENDING-142 and hid all four of its records at once — fine here, since its conditions do dispose of them, but the mechanism never checked that. Where it is not fine: REVIEWED-115 (2026-08-10) claimed `131`, so all five PENDING-131 records are hidden — including ADDENDUM 4, dated 2026-08-13 and therefore SUPPRESSED ON ARRIVAL, three days after the ruling that silenced it, while awaiting steward direction. PENDING-131 (c) is the unbuilt fence: the pulling thread of every session since 08-10, made a CONDITION by REVIEWED-121, and it has never once appeared in the list of items awaiting authorization. The work was not lost only because MEMORY.md and the session records were carrying it by hand. The same item fails the other way too: REVIEWED-116's header `PENDING-131/132/133/134` parses to one token matching no id, so a four-item design-gate ruling suppresses nothing. Filed as PENDING-145 — a new item, not a PENDING-142 addendum, because an addendum would have been hidden on arrival, which is the defect. None of PENDING-142's options (a)/(b)/(d) covers this: all three still resolve id -> ruled. Flagged as something the pre-registered answer key must encode BEFORE implementation, or the key will certify this behaviour as correct. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4 |
||
|
David F GliddenandClaude Opus 5
|
aa745bcfb0 |
[FIX] ruled_pendings' docstring asserted the opposite of the record
Jurist-ruled 2026-08-17 to correct independently of the mechanism, since it is a false claim whichever remedy wins. The docstring described REVIEWED-78/-81/-82 as "like-numbered rulings … concerning other matters" that had "falsely hidden" three items. Both halves are false. They are the AUTHORIZED rulings on PENDING-78/-81/-82 — same date, titles verbatim identical, and REVIEWED-81 names "PENDING-81" twice in its own body. They are like-numbered on purpose: REVIEWED-78's Notes say it was filed separately "for a mechanical reason: the closure rule in wake-digest.py matches a PENDING item to REVIEWED-<same number>." So the number→subject fix broke the three entries deliberately authored to satisfy the rule it replaced, then recorded their compliance as coincidence. Surfacing them was a regression; they have read open since 2026-07-28. The change proof could not see it because it measured a count (18→19) while the claim was each item's disposition — and the counts stay equal either way: removing 3 false-opens and restoring 3 false-closeds both leave 29. Superseded wording retained in the note rather than overwritten. Also filed as PENDING-142 ADDENDUM 3: the jurist ruling with its condition that (b)'s closing-verb enumeration must default to NOT CLOSED on unrecognized verbs; and the verified finding that governance-drift-check.py's subject is exactly one file (~/CLAUDE.md), so the scripts implementing governance checks make substrate claims nothing checks — one confirmed occupant, population unmeasured. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4 |
||
|
David F GliddenandClaude Opus 5
|
c2df868104 |
[FIX] Repair 39 files' frontmatter — including 3 I damaged an hour earlier
The 2026-06-06 normalization sweep ( |
||
|
David F GliddenandClaude Opus 5
|
b6e1b5e470 |
[FIX] The unwrapped-session detector compared two different clocks
The wake digest's `PREVIOUS SESSION DID NOT WRAP` alarm fired falsely at three consecutive wakes and was overridden by hand at two of them. It was scoped as a two-valued-detector problem. Diagnosing the class first found four defects, and the scoped one was not the cause: 1. TIME BASE (the cause). Transcript timestamps are UTC (`...Z`); the code dropped the suffix and called `time.mktime`, which reads a struct_time as LOCAL, then compared the result against `os.path.getmtime`, a true epoch. Measured: +7201 s skew against a 900 s tolerance. Because the skew exceeds the tolerance, a wrap written at the end of a session could NEVER land inside the window — the alarm was systematic, not intermittent. 2. SELECTION. "Newest transcript quiet for >60 s" excluded the previous session at exactly the moment it mattered: on 2026-08-17 it had ended 12 s before the wake, was skipped, and the session from four days earlier was reported instead. The defect is time-dependent and disappears ~60 s later, which is why re-running the digest afterwards showed nothing wrong. 3. EVIDENCE. Wrap records were dated by mtime, which any later edit moves — the 08-14 record read 08-17 because a CODA was appended to it. Now dated by git add-time, which cannot move once committed; mtime is a labelled fallback. 4. ARITY. `verdict is None` (could not assess) was folded into silence with "wrapped fine". Now four outcomes, per REVIEWED-104: wrapped · unwrapped · unassessable-subject (environment) · unassessable-check (defect). Acceptance is old-vs-new on the real case, not a unit pass. At the reconstructed wake instant the old code selects the wrong transcript AND returns a false alarm on the right one; the new code selects correctly and returns `wrapped`. Both defects independently produced the alarm, so fixing only the arity — the scoped task — would have shipped a fix that left it firing. The selftest gains a control derived from the property rather than from the check: a transcript's last inner timestamp and its file mtime are two readings of one moment, so their MEDIAN skew detects a systematic clock mismatch (1 s now, ~7200 s before). Max is printed too, because one transcript legitimately skews 31 h — the same mutable-mtime problem, on the transcript side. The old real-substrate gate demanded both verdicts occur across live sessions and PASSED while the detector was broken: it established that outcomes were spread, never that any was correct. Demoted to a printed note with its limit stated beside it. Filed as PENDING-142 ADDENDUM 1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4 |
||
|
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
|
||
|
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
|
||
|
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 |
||
|
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 |
||
|
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
|
||
|
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 |