From 179e6c67a1e54c5faff4f38ffa5e005bbf14f05b Mon Sep 17 00:00:00 2001 From: Claude Date: Thu, 28 May 2026 08:38:51 +0000 Subject: [PATCH] =?UTF-8?q?docs(board):=20OQ-MBX-7..14=20=E2=80=94=20#418?= =?UTF-8?q?=20follow-up=20findings=20catalogue?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Parallel-session FINDINGS/INPUT review of PR #418's `bindspace-singleton-to-mailbox-soa-v1` plan. Standalone catalogue at `.claude/board/oq-catalog-mbx.md`, mirroring `sprint-log-13/oq-catalog.md` shape; numbering continues the plan's §8 (OQ-1..4) into OQ-MBX-7..14. Each entry is framed as a question for the owning sessions (plan-author session and D-MBX-1..6 worker sessions), with three valid resolutions (covered-elsewhere / real-gap-queue-as-D-MBX-7+ / wrong-framing-because). Survey gate run before authorship: open-PR overlap clean (only #261 draft), prior-art grep per OQ cited inline. Highest-value finding is OQ-MBX-8 — `crates/cognitive-shader-driver/REFACTOR_NOTES.md:129` states the disk-write path is unbuilt and `driver.rs:458` records the in-RAM top-k row, so plan §2.5's "`persisted_row` is a pointer to the same SoA row" is forward-looking; row-identity semantics under Lance versioning/compaction need to be pinned before D-MBX-4 picks a type. Out of scope (deferred): Libet wall-clock budget — already explicitly rejected by `.claude/surreal/cognitive-substrate.md:49-51`; and cross-server baton replication. TD-RESONANCEDTO-DUP-1 severity re-rate closed before authorship (verified P3 is correct; separate modules, no crate-root collision). Docs only; no source touched, no plan-doc edited, no STATUS_BOARD modification. https://claude.ai/code/session_018FqA8TfgRBHy8zF92kx4TW --- .claude/board/oq-catalog-mbx.md | 304 ++++++++++++++++++++++++++++++++ 1 file changed, 304 insertions(+) create mode 100644 .claude/board/oq-catalog-mbx.md diff --git a/.claude/board/oq-catalog-mbx.md b/.claude/board/oq-catalog-mbx.md new file mode 100644 index 00000000..835cf5d5 --- /dev/null +++ b/.claude/board/oq-catalog-mbx.md @@ -0,0 +1,304 @@ +# OQ Catalogue — `bindspace-singleton-to-mailbox-soa-v1` follow-up (PR #418) + +**Status:** FINDINGS / INPUT — parallel-session review of PR #418's plan +(`.claude/plans/bindspace-singleton-to-mailbox-soa-v1.md`) and supporting board +entries (`E-MAILBOX-IS-BINDSPACE`, `E-RUBICON-RACTOR`). Each entry is a +**question** for the owning sessions (the plan-author session for plan-§ updates; +the D-MBX-1..6 worker sessions for impl detail); answers route via this file or +the relevant board entry. **No code is proposed and no plan-doc is edited by this +PR.** + +**Authored:** 2026-05-27, branch `claude/418-followup-findings`. Survey gate run +before authorship: open-PR overlap (clean — only #261 draft blackboard); +prior-art grep across `origin/main` for each candidate question (results +cited inline below); **Libet wall-clock budget framing explicitly rejected from +scope** because `.claude/surreal/cognitive-substrate.md:49-51` already rules +*"The numbers are operational, not Libet's 550/200 ms… Keep the phase structure; +reject the neuro-numerology."* + +**Convention:** Mirrors `.claude/board/sprint-log-13/oq-catalog.md` shape. +`OQ-MBX-N` numbering continues the plan's own §8 (`OQ-1..4` inline) so that +plan-§8 and this file form one logical catalogue. Three valid resolutions per +entry, each useful as calibration: **(a)** "covered in `$foo.md` / `$session_id`" +→ close & cross-ref; **(b)** "real gap → queue as `D-MBX-7+` / plan §X update"; +**(c)** "wrong framing because `$reason`" → close with the reason. + +**Out of scope (deferred to separate proposals):** +- Libet wall-clock budget — contradicts `.claude/surreal/cognitive-substrate.md:49-51`. +- Cross-server baton replication — additive design, separate conversation + (the existing `.claude/plans/multi-server-cognition-expansion-v1.md` is the + starting point). + +--- + +## Index + +| # | Topic | Severity | Owner / Blocks | +|---|---|---|---| +| `OQ-MBX-7` | `#[repr(C)]` byte-pin on `MailboxSoA` itself? | P0 | plan §2 / D-MBX-1 | +| `OQ-MBX-8` | `persisted_row: u32` semantics under Lance versioning / compaction | P0 | plan §2.5 / D-MBX-4 | +| `OQ-MBX-9` | `ThinkingStyleI4_32D` placement in `MailboxSoA` | P1 | plan §3 / D-MBX-1 | +| `OQ-MBX-10` | Sea-star concurrency model post-S3 (`Send`, container, access) | P1 | plan §6 / D-MBX-3 | +| `OQ-MBX-11` | Mailbox-level eviction at the 64k–256k thought ceiling | P1 | plan §2.7 / D-MBX-3 | +| `OQ-MBX-12` | S1 dual-path discipline + field-isolation-matrix tests | P1 | plan §6 / D-MBX-1..2 | +| `OQ-MBX-13` | BE-endianness policy for the LE contract | P2 | plan §2.5 | +| `OQ-MBX-14` | Baton `u16` ↔ HHTL cascade-address encoding relationship? | P3 | PP-15 audit input | + +--- + +## OQ-MBX-7 — `#[repr(C)]` byte-pin on `MailboxSoA` itself? + +**Question.** Plan §2.5 asserts THE little-endian contract is "one SoA layout +end-to-end, same bytes hot→disk, no re-encode at any boundary." How is the byte +layout of `MailboxSoA` *enforced* — via `#[repr(C)]` on the container plus +per-column type pins, via inheritance from `SoaContainerHeader`-style +descriptors, or via some other mechanism the plan doesn't surface? + +**Why it matters.** The "same bytes hot→disk" claim is a hard invariant: any +field reordering, padding shift, or alignment surprise breaks `persisted_row` +(OQ-MBX-8) and the GoBD tombstone-witness audit trail. Today the pattern is +established for the *primitives* — `SoaContainerHeader` ships as LE +`#[repr(C)]` in ndarray (commit `547824bc`, per `.claude/board/AGENT_LOG.md:186`), +`RungState` is a 16-B `#[repr(C)]` Pod +(`.claude/board/INTEGRATION_PLANS.md:148`), `OntologyDelta` is 32-B `#[repr(C)]` +(`.claude/plans/bindspace-columns-v1.md:262`), and `EPIPHANIES.md:257` already +treats `SoaContainerHeader` + `SoaColumns` as the LE-contract realisation of +`CANONICAL_DIMENSION_ALLOCATION.md`. But plan §2 defines `MailboxSoA` as a +*container* of `[CausalEdge64; N]` / `[QualiaI4_16D; N]` / `[MetaWord; N]` / +`[u16; N]` arrays plus accumulator scalars, and the migration map in §3 does not +pin the container's `repr` or assert its `size_of`. + +**Cross-ref / prior art.** `.claude/board/EPIPHANIES.md:257` +(dimension-allocation-IS-LE-contract); +`.claude/plans/cognitive-substrate-convergence-v3.md:578` +(`I-FEATURE-GATE-FIELD-ISOLATION` candidate iron rule — every v2-style layout +change requires field-isolation-matrix tests at the bit boundary; promotes +naturally to enforcement of the pin on every layout-bearing struct); +`.claude/specs/pr-ce64-mb-3-bindspace-efgh.md:102` (`#[repr(C)]` already specced +for bindspace columns). + +**Blocks.** Plan §2.5 grounding; D-MBX-1 column-addition shape. + +--- + +## OQ-MBX-8 — `persisted_row: u32` semantics under Lance versioning / compaction + +**Question.** Plan §2.5 says *"`ShaderCrystal.persisted_row` is a pointer to the +same SoA row laid down in Lance, not a serialized copy in a different shape."* +What does the `u32` actually denote under Lance's versioned/compacting storage +model — a Lance `_rowid`, a (fragment-id, fragment-offset) pair, a stable +RecordBatch row key, or something else? What happens to the value when a Lance +compaction rewrites the fragment, when the dataset rolls a new version, or when +the row is rewritten by an MVCC update? + +**Why it matters.** This is the load-bearing finding of the survey, because the +write path **isn't built yet**: +`crates/cognitive-shader-driver/REFACTOR_NOTES.md:129` says verbatim +*"BindSpace is in-memory only. `EmitMode::Persist` sets `persisted_row` in the +crystal but doesn't write to disk."* — and indeed +`crates/cognitive-shader-driver/src/driver.rs:458` does +`EmitMode::Persist => Some(resonance_dto.top_k[0].row)`, i.e. records the +in-RAM top-k row index rather than a Lance row identity. The §2.5 "pointer to +the same SoA row" claim is therefore forward-looking; D-MBX-4 (death → SPO-G +quad + Lance tombstone-witness) is the deliverable that has to make it true, +and the version/compaction semantics need to be pinned **before** that +deliverable picks a row-identity type, or the tombstone-witness back-pointer +will silently break across the first compaction. + +**Cross-ref / prior art.** Lance versioning is extensively discussed at the +*session* level (`.claude/SESSION_LANCE_ECOSYSTEM_INVENTORY.md:50-56`, +`.claude/adr/0001-archetype-transcode-stack.md:62-113`, +`.claude/FINAL_STACK.md:41-86`, `.claude/VISION_ORCHESTRATED_THINKING.md:35-179`), +all treating Lance's MVCC + time-travel as the persistence model — but **none** +pin what the `u32` row identity means under that model. The plan's hot/cold +view (§2.7) and tombstone-witness invariant (`E-LADDER-SERVES-MAILBOX` §6) +both depend on the answer. + +**Blocks.** Plan §2.5 / §2.7 grounding; D-MBX-4 row-identity type; D-MBX-6 +hot/cold transparent-view contract. + +--- + +## OQ-MBX-9 — `ThinkingStyleI4_32D` placement in `MailboxSoA` + +**Question.** `ThinkingStyleI4_32D` (i4 × 33 = 3 Pearl + 9 Rung + 5 Σ + 8 Ops + 4 +Presence + 4 Meta, riding the shipped ndarray i4-32 unpack) is a fully designed +basis (`EPIPHANIES.md:234..287`, resolved out of `E-I4-META-1` / +`.claude/knowledge/atom-basis-inventory.md`). Plan §3's column migration map +does not mention it. Is it (a) an owned per-row SoA column +(`[ThinkingStyleI4_32D; N]` at ~16 B/row), (b) a dispatch-time projection of +`MetaWord` (already in §3), or (c) only a p64-bridge parameter (so it never +materialises as a mailbox column)? + +**Why it matters.** Parallel to OQ-2 (temporal/expert fold) but for a type the +plan didn't flag. If (a), the hot footprint goes from ~6 KB/thought (§2.7) to +~6 KB + 16 B/thought — negligible for the 64k–256k ceiling but still a budget +line. If (b), the projection algorithm needs to be specified (which `MetaWord` +bits encode the 33 lanes? Or is it a separate read off `meta` + `edges`?). If +(c), `MailboxSoA` never holds it and the call sites that need a style read it +fresh from p64-bridge each cycle. + +**Cross-ref / prior art.** `.claude/board/EPIPHANIES.md:234, 253, 271, 287, 293, +392` (`ThinkingStyleI4_32D` basis decision); +`.claude/knowledge/atom-basis-inventory.md:3-54` (lanes-as-atoms, i4×33 = the +contract); `.claude/plans/rung-ladder-grounding-v1.md:94` (RungLevel = R1-R9 +dim-group of `ThinkingStyleI4_32D`); `crates/p64-bridge/src/lib.rs` +(`ThinkingStyle → layer_mask + combine + contra` — already shipped, no +re-encode). + +**Blocks.** Plan §3 migration map; D-MBX-1 column-addition shape. + +--- + +## OQ-MBX-10 — Sea-star concurrency model post-S3 + +**Question.** Plan §6 step S3 says *"`ShaderDriver` holds a sea-star of +mailboxes (kill the 4096 singleton in `serve.rs`)."* What is the *shape* of the +container — `Vec`, `HashMap`, a pool with +slot reuse, a sharded set keyed by `w_slot`? Is `MailboxSoA` `Send`/`Sync` +today (and if not, what's the access discipline — a per-mailbox actor in the +ractor outer-swarm, or driver-thread-pinned)? What's the supervisor's failure +model when one mailbox in the sea-star panics? + +**Why it matters.** S3 is the deliverable where the singleton actually dies; +the container shape and the access discipline determine the whole sea-star +runtime contract (ractor child set, supervision tree depth, par-tile mapping). +`E-CE64-MB-4`'s ownership guarantee is per-mailbox; the cross-mailbox layer +needs its own specification. + +**Cross-ref / prior art.** `.claude/specs/pr-ce64-mb-1-par-tile-crate.md` +(par-tile `Mailbox` apex — InMemory / Tokio / SupabaseSubMailbox backings; +gate D-CE64-MB-1-impl); `D-PERSONA-5` (ractor outer-swarm runtime); plan §5 +lifecycle ("spawn → think → emit → die → tombstone") implies the actor model +but does not commit on the container/scheduler. + +**Blocks.** D-MBX-3 (driver-singleton kill); D-MBX-4 (death → tombstone path +needs a "from where" answer). + +--- + +## OQ-MBX-11 — Mailbox-level eviction at the 64k–256k thought ceiling + +**Question.** Plan §2.7 pins a hot-tier ceiling of **~64k–256k thoughts** +(~6 KB/thought ≈ 300–600 MB at 64k). What signal reclaims a mailbox when the +ceiling is approached — global LRU on mailbox last-touch, supervisor +back-pressure from a working-set sensor, ractor mailbox idle-timeout, an +energy-decay threshold (`MailboxSoA.energy` integrated below floor for K +cycles)? Slot-level LRU on `AttentionMask` slots +(`pr-ce64-mb-5-mailbox-soa-attentionmask.md §2.2`) handles *within-mailbox* +slot reuse, not *between-mailbox* reclaim — those are different layers. + +**Why it matters.** Without a named eviction signal, the sea-star can't be +sized — it either over-allocates (OOM at the ceiling) or starves +(over-eager reclaim that thrashes warm mailboxes). The §2.7 ceiling is a +capacity *claim*; this OQ asks for the *policy* that enforces it. + +**Cross-ref / prior art.** `pr-ce64-mb-5-mailbox-soa-attentionmask.md §2.2` +(slot-level LRU — wrong layer); `E-LADDER-SERVES-MAILBOX` §5 (ghost-tier +preemptible to zero — the *capability*, but not the *trigger*); D-CSV-7 +(MailboxSoA accumulator, shipped — has `energy` and `last_emission_cycle` that +could feed a decay signal). + +**Blocks.** D-MBX-3 supervisor wiring; D-MBX-6 hot/cold spill discipline. + +--- + +## OQ-MBX-12 — S1 dual-path discipline + field-isolation-matrix tests + +**Question.** Plan §6 says S1–S4 run with both paths live behind the +`mailbox-thoughtspace` feature, with the v1 `Arc` accessors +*"feature-gated to a documented no-op with a migration pointer — never silently +change semantics."* During S1, when does a non-feature-gated caller (e.g. the +`engine_bridge` per-row read/write surface on the legacy path) get a +no-op-vs-route-through-mailbox answer? What test artefact gates each of S1, S2, +S3 — specifically, where is the **field-isolation-matrix test** required by +`I-FEATURE-GATE-FIELD-ISOLATION` (candidate iron rule, CSV-v3:578) queued? + +**Why it matters.** `.claude/board/sprint-log-11/meta-review-opus.md:133` records +that codex catches the v1-API-under-v2 anti-pattern repeatedly (4 instances in +PR #383 alone) — *"backward-compat shims for layout-breaking feature flags +require systematic test coverage of the bit boundary."* This migration is +load-bearingly that pattern (S1 adds columns under a feature; S2 routes through +them; S5 deletes the old carrier). Without the field-isolation matrix on the +critical bit boundaries (`MetaWord`, `CausalEdge64` v2 reclaimed bits per +`I-LEGACY-API-FEATURE-GATED`), the migration will hit the same codex catches. + +**Cross-ref / prior art.** `.claude/plans/cognitive-substrate-convergence-v3.md:406,578` +(I-FEATURE-GATE-FIELD-ISOLATION candidate); +`.claude/board/sprint-log-11/meta-review-opus.md:133` (the 4-instance evidence +trail); plan §7 invariant #5 (I-SUBSTRATE-MARKOV preserved); plan §6 S1–S4 +gating ladder. + +**Blocks.** D-MBX-1 acceptance criteria; D-MBX-2 acceptance criteria. + +--- + +## OQ-MBX-13 — BE-endianness policy for the LE contract + +**Question.** The LE-contract framing (plan §2.5; `E-CONTRACT-NO-SERIALIZE`) +assumes a little-endian host throughout the vertical (shader-driver → +`lance-graph-contract` → Lance storage). What is the policy on big-endian +targets — panic at startup, transparent byteswap at the I/O membrane, +feature-gate the LE contract behind `cfg(target_endian = "little")`, or declare +BE explicitly unsupported? + +**Why it matters.** Lance's on-disk format is LE; cross-architecture is mostly +theoretical for the current deploy targets, but a stated policy is cheaper now +than a surprise CI failure on a future aarch64-BE / s390x experiment. Also +relevant if the multi-server cognition plan +(`.claude/plans/multi-server-cognition-expansion-v1.md` §4 "deterministic +apply") ever crosses arch boundaries in the Raft log. + +**Cross-ref / prior art.** `.claude/plans/multi-server-cognition-expansion-v1.md` +§4 (deterministic apply across machines = precondition for replication); +`E-CONTRACT-NO-SERIALIZE` (compile-time handshake, no membrane serialize — +implicitly LE). + +**Blocks.** Plan §2.5 wording precision; LE-contract crate-level docs. + +--- + +## OQ-MBX-14 — Baton `u16` ↔ HHTL cascade-address encoding relationship? + +**Question.** The LE baton is `(u16 target, CausalEdge64)` (per `E-BATON-1`, +plan §7 invariant #2). HHTL is discussed as a 4-nibble cascade-level encoding +in transcripts (`SESSION_*`, `IDEA_JOURNAL_*`). Is the baton's `u16` target +meant to encode (or be derivable from) the HHTL cascade-address scheme — so +that "where the baton lands" carries cascade-level information — or is the +`u16` strictly a target *row index* into the receiving mailbox with no HHTL +structure? + +**Why it matters.** PP-15 (`baton-handoff-auditor`, +`EPIPHANIES.md:466,498`) is the meta-review savant whose remit covers exactly +this seam; getting the question in writing before PP-15's first scheduled pass +on #418 means PP-15 has the question, not the rediscovery, on input. Either +answer is fine — *"no, baton `u16` is a flat row index, cascade addressing +lives elsewhere"* is a valid closure. + +**Cross-ref / prior art.** `crates/lance-graph-contract/src/collapse_gate.rs` +(`CollapseGateEmission` / `push_baton` / `wire_cost_bytes`); +`.claude/board/EPIPHANIES.md:466,498` (PP-15 baton-handoff-auditor scope); +HHTL discussion across `.claude/SESSION_LANCE_ECOSYSTEM_INVENTORY.md`, +`.claude/IDEA_JOURNAL_2026_04_29_FUTURE_PILLARS.md`, etc. + +**Blocks.** Nothing in the immediate D-MBX-1..6 critical path; PP-15 audit +input. + +--- + +## Resolved / not-filed (survey closed these before authorship) + +- **TD-RESONANCEDTO-DUP-1 severity re-rate** — verified P3 is correct. + `crates/thinking-engine/src/dto.rs:59` and + `crates/thinking-engine/src/awareness_dto.rs:21` define `ResonanceDto` in + **separate modules** (`pub mod dto;` + `pub mod awareness_dto;` in + `lib.rs:17,32`), so there is no crate-root name collision and the crate + compiles fine. All 6 consumers (`bf16_engine.rs`, `composite_engine.rs`, + `dual_engine.rs`, `engine.rs`, `f32_engine.rs`, `signed_engine.rs`) import + only `crate::dto::ResonanceDto`; nobody currently imports the + `awareness_dto::` variant by name, so even cross-import confusion is latent + rather than active. P3 (cosmetic type-dup) stands; folding into D-MBX-2 per + the existing TD entry remains the right disposition. + +- **Libet wall-clock budget** — closed before authorship per + `.claude/surreal/cognitive-substrate.md:49-51`; see preamble.