AdaWorldAPI · AdaWorldAPI · Sep 3, 2026 · Sep 3, 2026 · Sep 3, 2026 · Sep 3, 2026
diff --git 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-<FAMILY>-<n>` 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 <symbol> 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
@@ -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
@@ -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.