diff --git a/.claude/board/EPIPHANIES.md b/.claude/board/EPIPHANIES.md index 04bd74a6b..39e0177df 100644 --- a/.claude/board/EPIPHANIES.md +++ b/.claude/board/EPIPHANIES.md @@ -1,3 +1,140 @@ +## 2026-09-03 — E-A-HAND-SWEEP-UNDERCOUNTS-TOWARD-DONE-AND-THE-CRITERION-IS-THE-WHOLE-DESIGN-1 — I reported 1 of 208; five defensible definitions give 32 to 125 + +**Status:** FINDING (measured, five variants, each reproducible from the +command in this entry). +**Confidence:** High on the measurements; **explicitly unresolved** on which +number is canonical — that is the point of the entry. +**Corrects:** my own claim, relayed cross-session, that +`r2il-machine-semantic-contract-v1.md` was *"the ONLY genuinely untracked +standalone plan in the tree."* + +**The error, and its direction.** I noticed five candidate plans from a +four-day `mtime` window, checked them by hand, found four declared an owner +plan and one did not, and reported **1 of 208**. The r2il session's own sweep +found **53 of 208**. Their framing is the part worth keeping: a hand sweep +*"undercounted in the direction that feels like completion."* The sample was +selected by recency, not by coverage, and the conclusion was stated about the +tree. + +**Then reconciliation failed, and that is the larger finding.** Attempting to +verify 53, five defensible readings of "untracked" were measured at +`79d82376`: + +| criterion | count | +|---|---:| +| no `D--` anywhere in the plan file | **91** | +| no `INTEGRATION_PLANS.md` entry naming the file | **61** | +| both of the above | **32** | +| no D-ids, **or** none of its D-ids on `STATUS_BOARD` | **125** | +| has D-ids but none of them on `STATUS_BOARD` | **34** | + +**None reproduces 53.** A sub-check diverges too: `3DGS-*` is **20** files +under both case-foldings, where their census reports 19. So this entry does +not claim their number is wrong — it claims the number is **not determined +until the criterion is**, and that two careful sessions produced six different +figures for one question on one tree. + +**Consequence for the CI check that was proposed** (a gate on the +`SUPERSESSION-INDEX` precedent, so the count cannot regrow): the proposal is +right, and its first deliverable is **not the workflow**. Five reasonable +definitions span **32 to 125 — a 4× range** — so the grep IS the design, and a +gate shipped before the criterion is pinned would encode an arbitrary choice +and then report a stable-looking number forever. Pin the criterion first, +state it in the workflow file, and only then write the check. + +Two constraints such a gate must satisfy, both learned here rather than +assumed: + +- **Diff-scoped, not tree-scoped.** Whatever the criterion, dozens of existing + plans fail it today. A gate that fails them turns `main` red for every + session and gets disabled within the hour. It must judge only plans a PR + ADDS or MODIFIES — stop the bleeding, do not bill the past. +- **The criterion should track DISCOVERABILITY, not tidiness.** What actually + went wrong in the r2il case is that a 1,427-line plan was invisible to a + session doing the mandatory reads, which is why its question got re-derived. + The index entry is the discovery path a session consults; + `STATUS_BOARD` rows are per-deliverable and secondary. That argues for the + `INTEGRATION_PLANS`-entry criterion (61) as the causal one — proposed, not + ruled. + +**The generalizable rule.** A census answers a question only as precisely as +its predicate is pinned. "How many plans are untracked" has no answer; "how +many plans lack an `INTEGRATION_PLANS` entry" has exactly one. When a count is +about to become a decision — a backfill, a gate, a scope call — write the +predicate down first, because otherwise every later re-run silently measures +something else and the disagreement looks like drift in the tree rather than +drift in the question. + +## 2026-09-03 — E-A-CROSS-REPO-SYMBOL-GREP-IS-ONLY-AS-FRESH-AS-THE-SIBLING-CHECKOUT-1 — the null was my clone, not their claim + +**Status:** FINDING (measured; the near-miss was real and is reproduced below). +**Confidence:** High — every step verified against a current tree, and the +stale-tree result is exactly reproducible by rewinding the sibling clone. +**Extends:** the cross-repo citation rule proposed the same day by the +`r2il-machine-semantic-contract-v1` owner session — *a citation to a removal +reads identically to a citation to the thing removed, so grep the sibling tree +for the SYMBOL, not the epiphany id.* That rule is right. This entry adds the +precondition it needs to be sound. + +**What happened.** Acting on that advice, I audited this plan's cross-repo +citations by symbol. Two greps returned zero hits for `ogar_loco::TERNLOG` — +first across `lance-graph/crates/`, then across the local OGAR checkout. Zero +hits in both trees, for a symbol a peer session had just asserted was minted +and live. The tempting write-up was ready: *a peer's central claim does not +survive verification.* + +It was my clone. `/home/user/OGAR` was **10 commits behind** `origin/main`. +`ogar-loco` exists exactly where the dependency says it does, and after a fetch +every claim verified precisely: + +| claim | verified at | +|---|---| +| `TERNLOG = FnIndex(0x86)` | `ogar-loco/src/lib.rs:607` | +| `0x87..0x8B` retracted, reserved-not-reclaimable | `lib.rs:596` | +| zero consumers | only `vocabulary.rs` arity/name registration — declared and addressable, never called | +| `BELNAP_JOIN` / `INFO_GAIN` / `STANCE_ENTROPY` / `EpistemicBassin24` | 0 hits each | + +`vocabulary.rs:1431` corroborates the retraction independently, recording a +re-pin *"to 96 (−5): only the generic TERNLOG"* — the −5 being the band. + +**The rule, stated so it does not have to be re-earned.** A cross-repo symbol +grep answers *"is this symbol in the tree I have"*, never *"does this symbol +exist"*. The two coincide only when the sibling checkout is current, and in +this workspace a sibling can be ten commits stale within a day. So: + +> **Fetch AND fast-forward the sibling tree — or grep the fetched ref +> directly (`git grep origin/main`) — then search. A zero-hit result +> on a stale working tree is a statement about your clone.** +> +> **⊘ CORRECTED pre-merge (Codex, #1157).** This rule first read *"fetch, then +> grep"*, which does not work and would not have reproduced the audit that +> produced it: `git fetch` updates remote-tracking refs and `FETCH_HEAD`, it +> does **not** touch the working tree, so a subsequent `grep` still reads the +> stale files. What actually recovered the result here was `git fetch` **plus +> `git rebase origin/main`**. A rule stated one step short of what was actually +> done is a rule that fails for its next reader — and this one was published in +> the same entry that warns against asserting from an incomplete view. + +This is the same shape as `E-A-RUNG-WRITE-PATH-ALREADY-SHIPPED-IN-A-SIBLING-REPO-1` +(below): an absence asserted from an incomplete view. That entry's failure was +not looking in the sibling repo at all; this one's would have been looking at a +stale copy of it. The correction is one line of `git fetch` in both cases, and +the cost of skipping it is asserting that a colleague's verified work does not +exist. + +**Sharpened, the cross-repo citation check is three steps, not one:** +1. `git fetch` the sibling — otherwise steps 2-3 measure your clone. +2. Grep for the **symbol**, not the epiphany id or the doc anchor. +3. Read the hit's surroundings — a symbol can survive inside a *retraction* + heading, which is the failure the original rule was written against. + +**Also verified in the same pass, and clean:** all eleven cross-repo symbols +this plan's §C cites (`ogar_loco`, `DOMAIN_FLOOR`, `ladder_program`, +`domain_stack_arity`, `ewa_sandwich`, `EvidenceMask`, `ReasoningBand`, +`CausalTopology`, `counterfactual`, `EpistemicMode`, `for_rung`) are PRESENT at +`5e2cb31d`. The September retraction did not strand any of them. Recorded +because a clean audit result is evidence too, and because the next session +should not have to re-run it blind. ## 2026-09-03 — E-THE-FIX-FOR-A-REVIEW-FINDING-SHIPS-UNREVIEWED-BY-DEFAULT-1 — the cap was the visible half **Status:** FINDING (measured on this PR's own review metadata). diff --git a/.claude/board/STATUS_BOARD.md b/.claude/board/STATUS_BOARD.md index 7f8356275..59961edf5 100644 --- a/.claude/board/STATUS_BOARD.md +++ b/.claude/board/STATUS_BOARD.md @@ -136,7 +136,7 @@ earns a row because it has a merged artifact of its own. | D-RLR-1 | **the one first Wave** — non-rung-4 horizon → loco Frozen atom → alpha → receipt → Evaluation/Revision → #879 → replay | Queued | | D-RLR-2 | rung-4 census closure: confirm no PHYSICAL hit at scale (`F-RLR-1`) | Queued | | D-RLR-3 | atom census → which candidates earn loco addresses (Shannon has no exemption) | Queued | -| D-RLR-4 | R2IL/r2sleigh membrane readiness vs lance-graph-java (`F-RLR-6`) | Queued | +| D-RLR-4 | **RE-SCOPED 2026-09-03** by the R2IL plan's owner session, who asked that it be kept rather than retired. The STORAGE half is answered — `r2il-machine-semantic-contract-v1` §4 settles how a session stores R2IL, now tracked as `D-R2IL-1` (lance-graph #1155); my §E is a thinner restatement and defers. What REMAINS is the half that plan never touches and that just went live: **what does the lance-graph-java membrane consume**, now that the `0x87..0x8B` loco band is retracted and `ogar_loco::TERNLOG` (`FnIndex(0x86)`) is minted-but-unconsumed? | **HELD pending cross-session resolution** (was: Queued — re-scoped). Codex on #1157 falsified the re-scope's premise from the owner session's own plan: §6 **W5** is a `lance-graph-java` facade wave, §6 W3 owns the palette→microcode route, and the ABI call is pinned at `:743` — all tracked by `D-R2IL-5`. Queueing this row would create a second owner for one membrane. Any genuinely new post-retraction gate attaches to `D-R2IL-5`. Not closed: its requester asked it be kept | | D-RLR-5 | **RE-SCOPED TWICE 2026-08-29.** Round 1 corrected the model (alpha is rung-level STORAGE, not a delta budget). Round 2 corrects the SCOPE: a real write path for a `rung: u8` field already shipped in a sibling repo (`MedCare-rs::medcare-nodesoa::alpha`, PR #565/#590, built directly on `lance_graph_contract::canonical_node::{NodeGuid,NodeRow}`, Lance-persisted). Now: (a) confirm whether `AlphaStamp.rung` is the same ladder `RungLevel` names or an unrelated attention-depth scale, (b) name the `(classid, rail)` each of rungs 1–10 would occupy IN `lance-graph`'s own contract, (c) decide whether `lance-graph` should consume the MedCare-rs pattern rather than re-derive it | **HELD, narrower reason than previously stated.** `D-ACR-2` (Rung-ladder rail UNMINTED, HTT §8 Q3) still blocks a `lance-graph`-native row. `D-ACR-3` ("no ontology-owned write path exists") is true only because `lance-graph` owns no live `NodeRow` spine to attach one to — the write path itself is proven, once, in `MedCare-rs`, against real data. See `EPIPHANIES.md` `E-A-RUNG-WRITE-PATH-ALREADY-SHIPPED-IN-A-SIBLING-REPO-1` | | D-RLR-6 | smallest invariant making Revision unavoidable per completed cycle (`F-RLR-5`) | Queued | diff --git a/.claude/plans/rubicon-loco-rung-cognitive-fabric-v1.md b/.claude/plans/rubicon-loco-rung-cognitive-fabric-v1.md index 3e5269b21..5afc03d1d 100644 --- a/.claude/plans/rubicon-loco-rung-cognitive-fabric-v1.md +++ b/.claude/plans/rubicon-loco-rung-cognitive-fabric-v1.md @@ -124,6 +124,33 @@ DOMAIN_FLOOR}` and provides: represents Frozen atoms AND composed programs. A new carrier is NOT justified, and proposing one is a STOP.** +> **⊘ TENSION RESOLVED 2026-09-03 — no conflict, and a shipped symbol proves +> it.** #1152's §F.6 flagged a possible contradiction between this verdict +> (`classid/vocabulary + u8 FnIndex` already carries Frozen atoms and composed +> programs) and `r2il-machine-semantic-contract-v1` §4 R4 (*"the macro +> vocabulary is a PALETTE, not a `FnIndex` per macro"*). I declined to +> adjudicate it from a partial read. The owner session has, and the answer is +> that R4's target is **one FnIndex per macro** — which would burn the slot +> space — never FnIndex as the addressing mechanism. +> +> `ogar_loco::TERNLOG` settles it concretely: **one `FnIndex`, with the call's +> value byte carrying the 8-bit truth table, so a single address covers all 256 +> combinators** (`ogar-loco/src/lib.rs:607`, `vocabulary.rs:92-98`). That is +> palette-as-vocabulary and FnIndex-as-address in one shipped symbol. This +> verdict stands unchanged. +> +> **⊘ NARROWED pre-merge (Codex, #1157) — `TERNLOG` does NOT settle the macro +> question, and the owner session's "settles it" is an overclaim I repeated +> without checking it against their own plan.** `TERNLOG` is a shared-core op +> whose operand is an *immediate* truth table; R4 concerns a **macro-id ordinal +> into the `System`/`Learned`/`Explore` palettes**, and that plan's §6 **W3** +> routes `{Learned,Explore}Palette[id]` → R2IL×BPE microcode. Different +> mechanisms. What survives is the narrow claim this section actually needs — +> R4 is not an argument against FnIndex-as-addressing, and a parameterized +> primitive shows one address can carry many behaviours. **How COMPOSED macros +> are addressed is W3's question and stays open.** + + | candidate | status | |---|---| | recipe kernels | **EXISTS + CALLABLE** via `FnIndex` | @@ -156,6 +183,39 @@ contract**, with per-host adapters — never a lance-graph-specific thinking DSL and never an R2IL→pseudo-IR transcode unless the operator contract demands it. **Measure readiness before designing the membrane** (`D-RLR-4`). +> **⊘ RESOLVED 2026-09-03 by the plan's owner session (cross-session).** The +> storage half of this section — *how a session stores R2IL* — is answered by +> `.claude/plans/r2il-machine-semantic-contract-v1.md` §4, now tracked as +> `D-R2IL-1` (lance-graph #1155). This §E verdict was an independent, thinner +> restatement of it, arrived at because that plan carried **no D-ids at all**, +> so `STATUS_BOARD` had nothing to hold and it was invisible to a +> mandatory-reads pass. It defers to §4; it does not compete with it. +> +> **`D-RLR-4` is re-scoped, NOT retired** — at the owner session's explicit +> request. What survives is the half §4 never touches: **what does the +> lance-graph-java membrane consume**, now that the `0x87..0x8B` loco band is +> retracted and `ogar_loco::TERNLOG` = `FnIndex(0x86)` is minted-but-unconsumed +> (`ogar-loco/src/lib.rs:607`; the reservation at `:596`). That question went +> live with lgj #70, which blocks the `BELNAP_JOIN` mint. +> +> **⊘ PREMISE FALSIFIED pre-merge (Codex, #1157) — and the source is the owner +> session's own plan.** The re-scope above rests on their statement that their +> plan "never touches" the lgj membrane. It does: §6 **W5** is literally +> *"`lance-graph-java` facade: `PcodeOp`/`Instruction`/`Varnode` as lazy views +> over handles + masks"*, §6 **W3** owns the palette→microcode route, and the +> Java/Valhalla section pins the call as `(program_ref, mask_handle) → +> mask_handle` (`r2il-machine-semantic-contract-v1.md:222`, `:221`, `:743`). +> `D-R2IL-5` already tracks that wave order. +> +> **Consequence:** as written this re-scope creates a SECOND queued owner for +> one membrane. `D-RLR-4` is therefore **HELD pending cross-session +> resolution**, not re-scoped-and-queued. If the post-retraction question — what +> lgj consumes now that `0x87..0x8B` is gone and `TERNLOG` sits unconsumed — is +> genuinely new (it postdates the plan, which is 2026-08-25), it attaches to +> `D-R2IL-5`, not here. I am not closing a row its requester asked me to keep; +> I am declining to queue it against territory their own §6 already owns. + + --- ## §F Alpha channel = the rung-level STORAGE. It is not written today.