docs(plan): SoA value-tenant migration — Phase-1 harvest + v2 operator-locked sequencing#611
Conversation
…board hygiene Phase-1 of soa-value-tenant-migration-v1 (the brief, #610): the §4 inventory filled by read (canonical_node.rs / class_view.rs / cascade_key.rs in full, plus two mapping subagents). Two findings: - (A) the canonical NodeRow.value 480 B slab and the parallel MailboxSoA are two disjoint SoA worlds (only entity_type == class_id shared; 6/10 slab tenants have no live producer) — reconciling them is the real near-term migration. - (B) homogeneity does not close over the slab (8 KEEP, 2 DEFER, 1 homogenize-to- facet) — the §8.5 honest outcome; it closes as the operator's one contained 16 B facet facet_classid(4) | helix-place(6) | cam-pq(6) (identity / search / schema; the 6 B canonical CAM-PQ, not the 16 B turbovec). Qualia i4-16D and the future thinking-style i4-32D are DEFERRED for a bigger substrate-validation pass. Corrections folded in: the q2 new_v2 blocker is closed (API landed, gated); the §8.1/§5 "no new ValueSchema variant" reframe (Codex-P2 on #610) superseded in the INTEGRATION_PLANS index. Board hygiene (same commit): AGENT_LOG cont.43; EPIPHANIES E-TWO-SOA-WORLDS + E-HOMOGENEITY-CLOSES-AS-CONTAINED-FACET; INTEGRATION_PLANS prepend. Doc-only, zero code. Claude-Session: https://claude.ai/code/session_01TANd15SECEb1Gm4cpaRVD9
…uencing ONE migration, TWO ordered phases — Phase 1 identity→V3 (key-side), Phase 2 V3-shaped value tenants (value-side). Identity-first is forced: OGAR #128's envelope parser resolves tail_variant (key shape) upstream of value_schema. §2.1 reusable pattern (cross-session + OGAR #128 converged): extend the ONE ReadMode with a third field tail_variant resolved by classid_read_mode() — never a public new_v3. Symmetric spine mint_for(.tail_variant) ~ to_node_row(.value_schema). L1 DEFAULT.tail_variant=V1, L2 keep value_schema=Full POC-flip separable, L3 mechanism lands now. Parity fuse is structural-against-canon (OGAR #128 doc-only). §2.2 P-C classid lock (operator-ratified): generation marker = flip leading nibble 0→1 on the current classid; OGAR 0xDDCC domain map kept as-is. OSINT 0x0007→0x1007, FMA 0x0008→0x1008 (kept; canon Anatomy 0x0A realign deferred as domain-debt), CPIC 0x0C→0x0D Genetics→0x100D (forced: 0x0C is Automation). guid-v3-tail-gated. Phase 2 = the harvest; the §5 body stays gated on the two 5+3 panels. - .claude/plans/soa-value-tenant-migration-v2.md (sequencing + §2.1 pattern + §2.2 P-C lock) - .claude/board/INTEGRATION_PLANS.md (prepend, board hygiene) Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
📝 WalkthroughWalkthroughThe PR adds markdown records for the SoA value-tenant migration harvest, a filled 10-tenant inventory, a two-phase identity-first sequencing plan, and updated board logs that capture the same findings and plan notes. ChangesSoA value-tenant migration docs
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85a4a456cf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | OSINT | `0x0007` | **`0x1007`** | `0x07` OSINT | canon ✓, kept as-is | | ||
| | FMA | `0x0008` | **`0x1008`** | `0x08` OCR | **kept as-is** (jungle-avoidant). Canon home is `0x0A` Anatomy — firewall-split from `0x09` Health PHI (lib.rs:1078-1086) — so the realign to `0x100A` is **deferred domain-debt**; flip this one row if/when realigned. | | ||
| | CPIC | `0x000C → 0x000D` | **`0x100D`** | `0x0D` Genetics (new) | the **one forced move**: `0x0C` is Automation (HIRO/MARS), so CPIC's current `0x0C` collides — Genetics mints into the next free slot, then gen-marks. | |
There was a problem hiding this comment.
Preserve canonical 0xDDCC ids for V3 classids
If Phase 1 is implemented from this table, the V3 IDs will route to the wrong domains: the current contract has OSINT at NodeGuid::CLASSID_OSINT = 0x0000_0700 and FMA at 0x0000_0A01 (crates/lance-graph-contract/src/canonical_node.rs:54-65), and classid_concept_domain routes on the low-u16 0xDDCC bytes (ogar_codebook.rs:102-111). Replacing those with 0x1007/0x1008 changes the domain byte instead of preserving it, and 0x0D is currently HR in the contract, not Genetics, so the planned entries would not hit the intended codebooks/read modes.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/board/EPIPHANIES.md:
- Around line 5-8: The board entry contains invalid inline-code spacing that
triggers markdownlint MD038. Update the affected Markdown in EPIPHANIES.md to
remove the extra spaces around backticked text in the long status line,
especially the `facet_classid(4) | helix-place(6 B / 48-bit Signed360 = ... )`
section, so all inline code spans are tight and lint-clean.
In @.claude/board/INTEGRATION_PLANS.md:
- Around line 1-4: The sequencing summary currently collapses legacy zero-prefix
classids into a single V2 bucket, which conflicts with the V1/V2 split described
in the plan. Update the board note in INTEGRATION_PLANS.md so the “zero-prefix”
case is clearly separated from the already-minted V2 tails, and make the Phase 1
identity→V3 wording explicit about preserving V1 versus V2 classids. Use the
existing terms in this note such as “operator-locked,” “coexist-by-classid,”
“new_v2,” and “guid-v2-tail” to keep the distinction unambiguous.
In @.claude/plans/soa-value-tenant-migration-v1-harvest.md:
- Around line 130-135: Recompute the summary in the plan so it matches only the
rows in this inventory and does not include the future i4-32D validation item.
Update the Net tally near the section with the KEEP/DEFER/homogenize breakdown
so the counts align with the 10-row table and the totals are self-consistent.
- Around line 50-56: Update the “Live-producer reality” tenant inventory so it
matches the rest of the plan: the producer-less set listed in the paragraph is
missing Qualia and currently disagrees with the §4 table and later recap. Edit
the tenant names in this section (and the related recap at the referenced
locations if needed) using the same inventory terminology as the migration_class
discussion, keeping the deferred tenants explicitly marked as deferred.
In @.claude/plans/soa-value-tenant-migration-v2.md:
- Around line 63-143: The plan currently reads as if `ReadMode.tail_variant`
already exists in `canonical_node.rs`, but the codebase only has `value_schema`
and `edge_codec` today. Update the target-state section around the `ReadMode`
example to clearly mark `tail_variant` as a proposed extension, and adjust the
“Three locks” language so references like `ReadMode::DEFAULT.tail_variant` are
framed as future additions rather than existing constants. Use the `ReadMode`
struct and `ReadMode::DEFAULT` mentions to locate and rewrite the affected text.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: a55dc7e5-d2e6-4cd1-ab20-0214bd74e0d3
📒 Files selected for processing (5)
.claude/board/AGENT_LOG.md.claude/board/EPIPHANIES.md.claude/board/INTEGRATION_PLANS.md.claude/plans/soa-value-tenant-migration-v1-harvest.md.claude/plans/soa-value-tenant-migration-v2.md
| ## 2026-06-25 — E-HOMOGENEITY-CLOSES-AS-CONTAINED-FACET — §8 homogeneity doesn't close over the slab; it closes as the operator's one 16 B place⊕search facet | ||
|
|
||
| **Status:** FINDING `[H]` (operator-proposed 2026-06-25, harvest-grounded; gated F-1 + F-code; pending §6 sign-off). Applying §3's gates to the actual 10 tenants: 9/10 are irreducibly heterogeneous (identity Fingerprint / scalars Energy·Plasticity·EntityType / bitfield Meta / fixed-vector Qualia / already-PQ Turbovec / cursor Kanban / deferred edges) → **KEEP** — except Qualia (i4-16D) and the operator-named future thinking-style (i4-32D), which **DEFER** for a bigger substrate-validation pass (i4 faithfulness — Cronbach/ICC/Spearman vs ground truth, `I-NOISE-FLOOR-JIRAK`); only HelixResidue (structure) matches the facet shape. So §8's homogeneous-value-slab reduces — per its own §8.5 fallback, NOT a failure — to "**classid is a schema pointer**", which is SHIPPED (`ReadMode`/`ValueSchema`/`ClassView`; `ocr.rs:105` end-to-end). **The closure exists as ONE contained special case** (operator): `facet = facet_classid(4) | helix-place(6 B / 48-bit Signed360 = `ValueTenant::HelixResidue`) | cam-pq(6 B / 48-bit canonical CAM-PQ) = 16 B` — fuses identity (frozen ruler, ICC→1.0) ⊥ search (CAM-PQ) ⊥ schema (facet_classid), codec-selected by facet_classid (the §3/§8.1 provision → a `classid → ClassView` reading, **no `ValueSchema` variant**, layout-preserving, no #500). **I-VSA-IDENTITIES-clean by construction:** helix∥CAM-PQ in disjoint byte ranges ([0:6],[6:12]), concatenated never XOR-bundled. **Precise design point:** the facet wants the 6 B canonical CAM-PQ, NOT today's 16 B `TurbovecResidue` (turbovec 32×4-bit) — a width decision for the §6 panels. This is the §8.1 facet made concrete with a *place⊕search* codec instead of a `part_of:is_a` tile. Detail: `soa-value-tenant-migration-v1-harvest.md` §1 Finding B. | ||
|
|
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Trim the inline-code spacing here.
markdownlint is already flagging MD038 on this entry; please normalize the backticked text so the board file stays lint-clean.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 7-7: Spaces inside code span elements
(MD038, no-space-in-code)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/board/EPIPHANIES.md around lines 5 - 8, The board entry contains
invalid inline-code spacing that triggers markdownlint MD038. Update the
affected Markdown in EPIPHANIES.md to remove the extra spaces around backticked
text in the long status line, especially the `facet_classid(4) | helix-place(6 B
/ 48-bit Signed360 = ... )` section, so all inline code spans are tight and
lint-clean.
Source: Linters/SAST tools
| ## 2026-06-25 — soa-value-tenant-migration v2 SEQUENCING (operator-locked; identity→V3, then V3-tenants) | ||
|
|
||
| Plan: `.claude/plans/soa-value-tenant-migration-v2.md`. **Operator-locked ordering** for the migration the v1 BRIEF opened + the v1-HARVEST inventoried: **ONE migration, TWO ordered phases — Phase 1 identity→V3 (key-side), Phase 2 V3-shaped value tenants (value-side).** Identity-first is **forced, not chosen**: OGAR #128's envelope parser resolves `tail_variant` (key shape) UPSTREAM of `value_schema` (tenant shape), so the tenants cannot be shaped to a V3 geometry the key does not yet express (the key is the coordinate system; tenants are read *through* it; the Phase-2 `helix-place‖CAM-PQ` facet is a *reflection* of the V3 part_of/is_a key). **Phase 1** = OGAR-registry + envelope-parser wiring: `0x1007` leading-`1` prefix → V3 `tail_variant`, **coexist-by-classid** (legacy zero-prefix stays V2 via `new_v2`/`guid-v2-tail`; RESERVE-DON'T-RECLAIM ⇒ zero V2-corpus re-mint, layout-preserving), grade `[H]` gate **F-update**. **Phase 2** = the harvest (contained facet + 8 KEEP + 2 DEFER, F-1/F-code; the §5 body still gated on the two 5+3 panels). **Payoffs:** identity-first migrates the one shared `entity_type≡class_id` anchor to V3 *before* the A↔B reconciliation (Phase 2 reconciles in V3 coords, no redo), and dissolves the harvest's scope question (harvest = the Phase-2 input). **Watch:** Phase 1's substance IS the OGAR casing-miss gap (harvest §6.1) — the corrective `/home/user/{OGAR,MedCare-rs}` sweep gates Phase-1 start, not optional polish. Doc-only. On `claude/serene-mayer-1a09he` (rides with the harvest to main). | ||
|
|
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Don't collapse V1 and V2 into one "zero-prefix" bucket.
The sequencing doc distinguishes the V1 default from the existing V2 tails, but this summary says legacy zero-prefix classids "stay V2" as a single group. That misstates the operator-lock and will confuse future readers about which classids remain V1 versus already-minted V2. Please split the summary so the board note preserves the V1/V2 split.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/board/INTEGRATION_PLANS.md around lines 1 - 4, The sequencing
summary currently collapses legacy zero-prefix classids into a single V2 bucket,
which conflicts with the V1/V2 split described in the plan. Update the board
note in INTEGRATION_PLANS.md so the “zero-prefix” case is clearly separated from
the already-minted V2 tails, and make the Phase 1 identity→V3 wording explicit
about preserving V1 versus V2 classids. Use the existing terms in this note such
as “operator-locked,” “coexist-by-classid,” “new_v2,” and “guid-v2-tail” to keep
the distinction unambiguous.
| **Live-producer reality (decisive for migration_class):** only **4 of 10** slab | ||
| tenants have a live (non-test) slab producer — **Energy, EntityType, Kanban, | ||
| Fingerprint**. The other **6 — Meta, MaterializedEdges, HelixResidue, | ||
| TurbovecResidue, Plasticity** — exist only as schema-membership tests (`ocr.rs`) | ||
| or as parallel-`MailboxSoA` mirrors; `MaterializedEdges`/`HelixResidue`/ | ||
| `TurbovecResidue` are explicitly **deferred**. A producer-less tenant migrates | ||
| very differently from an actively-written one. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Fix the tenant list to match the inventory.
Qualia is missing from the “other 6” set, so this paragraph disagrees with both the §4 table and the later recap. Please align the named producer-less tenants before treating this as the closed inventory.
🛠️ Suggested correction
- The other 6 — Meta, MaterializedEdges, HelixResidue, TurbovecResidue, Plasticity —
+ The other 6 — Meta, Qualia, MaterializedEdges, HelixResidue, TurbovecResidue, Plasticity —Also applies to: 238-240
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/soa-value-tenant-migration-v1-harvest.md around lines 50 - 56,
Update the “Live-producer reality” tenant inventory so it matches the rest of
the plan: the producer-less set listed in the paragraph is missing Qualia and
currently disagrees with the §4 table and later recap. Edit the tenant names in
this section (and the related recap at the referenced locations if needed) using
the same inventory terminology as the migration_class discussion, keeping the
deferred tenants explicitly marked as deferred.
| **Net:** **8 KEEP, 2 DEFER (Qualia i4-16D + the future thinking-style i4-32D), 1 homogenize-to-facet (HelixResidue, into the contained 16 B | ||
| place⊕search facet with a 6 B CAM-PQ).** This IS the honest §8.5 outcome: | ||
| homogeneity does not close over the slab; it closes as the operator's one | ||
| contained facet for the cold place⊕search (Compressed / FMA-anatomy) workload, | ||
| while the hot heterogeneous tenants stay `KEEP` (the Cognitive/Full presets) and the | ||
| i4-quantized cognitive vectors (Qualia, thinking-style) **DEFER** (§2a). |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Recompute the net tally.
8 KEEP + 2 DEFER + 1 homogenize-to-facet cannot describe a 10-row table, and the count also leaks in the future i4-32D validation item that is not part of this inventory. Please recalculate the summary from the rows above so the handoff stays self-consistent.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/soa-value-tenant-migration-v1-harvest.md around lines 130 -
135, Recompute the summary in the plan so it matches only the rows in this
inventory and does not include the future i4-32D validation item. Update the Net
tally near the section with the KEEP/DEFER/homogenize breakdown so the counts
align with the 10-row table and the totals are self-consistent.
| ### 2.1 The reusable pattern — extend the one `ReadMode`, never a public `new_v3` | ||
|
|
||
| P-A's mechanism **must BE Phase-2's mechanism, not merely enable it.** Both sides | ||
| hang off the **single** `classid → ReadMode` dispatch (`canonical_node.rs:912` | ||
| `classid_read_mode`), whose doc-invariant (:810) is "consumers and OGAR read the | ||
| identical schema." `ReadMode` (:815) already carries the value reading; identity | ||
| is a **third field on the same struct**, resolved by the same lookup — mirroring | ||
| OGAR #128's `classid → {tail_variant, value_schema, edge_codec}`: | ||
|
|
||
| ```rust | ||
| pub struct ReadMode { | ||
| pub tail_variant: TailVariant, // P-A adds — which KEY shape (resolved first, per #128's parse order) | ||
| pub value_schema: ValueSchema, // Phase 2 — which tenants (already shipped) | ||
| pub edge_codec: EdgeCodecFlavor, // edges (already shipped) | ||
| } | ||
| ``` | ||
|
|
||
| **The symmetric spine** (the test that it serves Phase 2): | ||
|
|
||
| | side | call | shapes | | ||
| |---|---|---| | ||
| | key (Phase 1) | `mint_for(classid_read_mode(c).tail_variant, …)` | the address | | ||
| | value (Phase 2) | `to_node_row(classid_read_mode(c).value_schema, …)` | the tenants | | ||
|
|
||
| Same `classid_read_mode(c)`, sibling fields. Consumers **mint by classid**, never | ||
| hardcode v1/v2/v3 — exactly as they later shape tenants by classid. Migrating a | ||
| class's **identity** to V3 = flip `tail_variant` on its `ReadMode` const; later | ||
| migrating its **tenants** = flip `value_schema` on the *same* const. Two | ||
| field-flips on one registry entry; no consumer rewrite either time. | ||
|
|
||
| **Litmus (guardrail):** anything that is **not** `classid_read_mode(c).<field>` — | ||
| a consumer `if classid_is_v3 {…}`, or a public `new_v3` consumers call directly — | ||
| is the *layer-not-column* anti-pattern and will not serve Phase 2. Reject it. | ||
|
|
||
| **Three locks (cross-session grounding, 2026-06-25):** | ||
| - **L1 — `ReadMode::DEFAULT.tail_variant = V1`** (the zero-fallback const at :833). | ||
| Every un-minted classid stays V1 → **zero re-mint of the V1/V2 corpus** | ||
| (RESERVE-DON'T-RECLAIM). V3 is opt-in per-classid via `BUILTIN_READ_MODES` | ||
| (:891), never the default. | ||
| - **L2 — keep the POC-`Full` flip separable.** `ReadMode::DEFAULT.value_schema` | ||
| is still the unreverted `Full` POC (:825-833, guarded by the revert test). | ||
| Adding `tail_variant` and flipping `value_schema → Bootstrap` are **two | ||
| independent field migrations on one struct** — document the canonical target | ||
| triple `{V1, Bootstrap, CoarseOnly}`, do not entangle them. | ||
| - **L3 — mechanism is NOT blocked on the classid lock (P-C).** Extending | ||
| `ReadMode` + the `TailVariant` enum + the `mint_for` carrier + the | ||
| `guid-v3-tail` gate are additive / default-V1 / feature-gated → they land | ||
| **now**, non-breaking. Only the per-consumer `classid → tail_variant: V3` | ||
| **entries** (the `0x1007` placement) need the P-C operator-lock. | ||
|
|
||
| **Parity fuse — structural-against-canon, NOT runtime-vs-struct.** OGAR #128 | ||
| (`E-CLASSID-ENVELOPE-PARSER` / `D-ENVPARSE`, merged, **doc-only**) pins the target | ||
| verbatim — *"the registry entry must gain the `tail_variant` (V2/V3) axis beside | ||
| `ReadMode {value_schema, edge_codec}`"* — but `tail_variant` is **to-wire on | ||
| OGAR's side too** (the pieces #128 lists as CODED — `classid_read_mode` / | ||
| `BUILTIN_READ_MODES` / `ClassView` / `new_v2` / `cascade_key`-V3 — carry none). So | ||
| the fuse asserts the contract `ReadMode`'s field set **== the three canon axes** | ||
| `{tail_variant, value_schema, edge_codec}` (a compile-time *structural* guard | ||
| against the canon), **not** a runtime comparison against a live OGAR struct — that | ||
| is the shape the codebook `COUNT_FUSE` has only because its `ogar_vocab` | ||
| counterpart already exists. It upgrades to the runtime form once OGAR codes its | ||
| registry's `tail_variant`. | ||
|
|
||
| ### 2.2 P-C classid lock (operator-ratified 2026-06-25) | ||
|
|
||
| **Generation marker = flip the leading nibble `0 → 1`** on the *current* classid | ||
| (#128's "exact u32 placement" pinned to the high nibble; versioning in the | ||
| schema-pointer, never a GUID-tail nibble). OGAR's canonical `0xDDCC` domain map | ||
| (`ogar-vocab/src/lib.rs:1062-1086`) is **kept as-is**. The three V3 consumers: | ||
|
|
||
| | consumer | base classid | V3 (gen-marked) | OGAR domain | note | | ||
| |---|---|---|---|---| | ||
| | OSINT | `0x0007` | **`0x1007`** | `0x07` OSINT | canon ✓, kept as-is | | ||
| | FMA | `0x0008` | **`0x1008`** | `0x08` OCR | **kept as-is** (jungle-avoidant). Canon home is `0x0A` Anatomy — firewall-split from `0x09` Health PHI (lib.rs:1078-1086) — so the realign to `0x100A` is **deferred domain-debt**; flip this one row if/when realigned. | | ||
| | CPIC | `0x000C → 0x000D` | **`0x100D`** | `0x0D` Genetics (new) | the **one forced move**: `0x0C` is Automation (HIRO/MARS), so CPIC's current `0x0C` collides — Genetics mints into the next free slot, then gen-marks. | | ||
|
|
||
| `ReadMode::DEFAULT.tail_variant = V1` (L1) keeps every other classid legacy; these | ||
| are the only `BUILTIN_READ_MODES` V3 entries, each `guid-v3-tail`-gated. The | ||
| Genetics-domain mint (OGAR + contract) and CPIC's `0x0C → 0x0D` move ride with the | ||
| P-A mechanism, not this doc. | ||
|
|
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
rg -nP --type=rs 'struct ReadMode|tail_variant|classid_read_mode|BUILTIN_READ_MODES' .Repository: AdaWorldAPI/lance-graph
Length of output: 188
Update the plan to distinguish current code state from the proposed tail_variant extension.
canonical_node.rs defines ReadMode with only value_schema and edge_codec. The snippet at lines 73–79 presents tail_variant as an existing field in the struct without marking it as a proposed change.
Please revise the target-state section to clarify that tail_variant is unimplemented:
- Label the code block (lines 73–79) as "Proposed Extension" or similar.
- Ensure references in the "Three locks" section (e.g.,
ReadMode::DEFAULT.tail_variant) are phrased as future actions rather than existing constants.
Example Wording
- pub struct ReadMode {
+ // Proposed Target: Extend ReadMode with tail_variant
+ // Note: Current canonical_node.rs:815 contains only value_schema and edge_codec.
+ pub struct ReadMode {
pub tail_variant: TailVariant, // TO BE ADDED
pub value_schema: ValueSchema,
pub edge_codec: EdgeCodecFlavor,
}🧰 Tools
🪛 LanguageTool
[grammar] ~99-~99: Ensure spelling is correct
Context: ...lback const at :833). Every un-minted classid stays V1 → **zero re-mint of the V1/V2 ...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~100-~100: Ensure spelling is correct
Context: ...RESERVE-DON'T-RECLAIM). V3 is opt-in per-classid via BUILTIN_READ_MODES (:891), neve...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~139-~139: Ensure spelling is correct
Context: ...il_variant = V1(L1) keeps every other classid legacy; these are the onlyBUILTIN_REA...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.claude/plans/soa-value-tenant-migration-v2.md around lines 63 - 143, The
plan currently reads as if `ReadMode.tail_variant` already exists in
`canonical_node.rs`, but the codebase only has `value_schema` and `edge_codec`
today. Update the target-state section around the `ReadMode` example to clearly
mark `tail_variant` as a proposed extension, and adjust the “Three locks”
language so references like `ReadMode::DEFAULT.tail_variant` are framed as
future additions rather than existing constants. Use the `ReadMode` struct and
`ReadMode::DEFAULT` mentions to locate and rewrite the affected text.
Codex P1 — §2.2 corrected to the high-u16 generation-marker scheme. The classid u32 is [custom hi : canon lo] and classid_concept_domain routes on the LOW u16, so the marker goes in the HIGH (custom) half, preserving the canon 0xDDCC low u16: OSINT 0x0000_0700 -> 0x1000_0700 (wired in #612). The earlier 0x1007 low-half form is rejected (0x1007 as u16 >> 8 = 0x10 -> Unassigned). FMA is 0x0A01 (Anatomy, already realigned); Genetics domain TBD (0x0D is HR in the contract). CodeRabbit major — §2.1: mark ReadMode.tail_variant as the P-A (#612) addition, not a pre-existing field (the live struct has only value_schema + edge_codec). CodeRabbit minor — replace every 0x1007 reference (§2 Phase-1, §2.1 L3, INTEGRATION_PLANS) with the high-u16 scheme; split V1/V2 in the board note (legacy zero-prefix keeps its current tail — V1 default or V2 new_v2-minted). Deferred to the harvest's owning session (commit 4a2f9ba): the missing-Qualia + net-tally consistency fixes and the EPIPHANIES MD038 lint. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
docs(plan): correct §2.2 classid gen-marker to high-u16 (post-#611 follow-up)
What
Two doc-only commits for the SoA value-tenant migration (no code):
Phase-1 harvest (
-v1-harvest.md,4a2f9ba7) — the filled §4 inventory (10 tenants, read-not-grep with a provenance ledger), Finding A (the canonicalNodeRow.valueslab and the parallelMailboxSoAare two disjoint SoA worlds; onlyentity_type≡class_idshared; 6/10 tenants producer-less), Finding B (homogeneity does NOT close over the slab — 8 KEEP + 2 DEFER + 1 facet — it closes as the operator's ONE contained 16-bytefacet_classid|helix|CAM-PQfacet).v2 operator-locked sequencing (
-v2.md+INTEGRATION_PLANSprepend,85a4a456) — ONE migration, TWO ordered phases: Phase 1 identity→V3 (key-side), Phase 2 V3-shaped value tenants (value-side). Identity-first is forced by OGAR feat: Phase 3 BF16 wiring + φ-spiral reconstruction theory #128's envelope-parser resolution order (tail_variantresolves upstream ofvalue_schema).ReadModewith a third fieldtail_variantresolved by the sameclassid_read_mode()— never a publicnew_v3. Symmetric spinemint_for(.tail_variant)~to_node_row(.value_schema). Three locks (L1DEFAULT.tail_variant=V1, L2 keep thevalue_schema=FullPOC-flip separable, L3 mechanism lands now). Parity fuse is structural-against-canon (OGAR feat: Phase 3 BF16 wiring + φ-spiral reconstruction theory #128 is doc-only).0→1; OGAR's0xDDCCmap kept as-is → OSINT0x1007, FMA0x1008(canon Anatomy0x0Arealign deferred as domain-debt), CPIC/Genetics0x100D(0x0Cis Automation).Why
Phase-2 (the harvest's value-tenant migration) can only be shaped to a V3 geometry once the key already expresses it — so the address migrates first, and it migrates through the same
classid → ReadModedispatch the value side already uses. The §5 per-tenant migration body stays gated on the two independent 5+3 panels.Doc-only, additive. The P-A mechanism (the
ReadModeextension §2.1 describes) lands as a separate code PR.Carries the harvest commit
4a2f9ba7from the parallel session so the inventory + the sequencing ride tomaintogether.🤖 Generated with Claude Code
https://claude.ai/code/session_01TzqvDqbFRzyx17EkLKBoZF
Generated by Claude Code
Summary by CodeRabbit