probes: canonical temporal identity and the old-path change set

.claude/board/STATUS_BOARD.md

@@ -21,6 +21,10 @@ identity) is real and probe-gated.
 | D-GTM-0n / P3 | **Ternlog chaining amortization** (`ndarray/examples/ternlog_amortization_probe.rs`, re-run `--release` 2026-09-06): does chaining pay on THIS mask shape? Pre-registered pass criterion = per-constraint cost flat in K, with a **K=1 control** (nothing to chain ⇒ no win) | **GREEN, bounded.** `T3/T1` bottoms at **0.50** by K=8; T3 total flat in K (57.6 ns @ K=4 → 54.1 ns @ K=32, 16× more constraints). K=1 control reads **1.03** as it must. Two bounds ride with the number and may not be dropped when it is cited: the win is **L2-residency-contingent** (bandwidth `138→15 GB/s` past L2, ratio back to 1.03 at a 512 KiB mask), and mask loses to sparse below **0.1%** active. **Does NOT retire the standing caveat** — 2× on one of three passes still cannot account for 5×. Gates Stage-3 SPEED claims only; the shape/correctness case never depended on it |
 | D-ALPHA-1b | **`AlphaMask::zip` release-mode length guard** (`lance-graph-contract/src/alpha.rs`): the only guard was `debug_assert_eq!`, compiled out in release, so mismatched-length operands produced a mask claiming `self.len` addresses over the SHORTER operand's word count — `count`/`is_empty` under-report silently, `contains`/`materialize_ordinals` panic at a distance | **Fixed** — promoted to `assert_eq!`. Defect reproduced in release BEFORE the fix (the `should_panic` falsifier reported "test did not panic as expected"); two-sided falsifiers both disable-verified. No API change, no external callers. Stage 1b of `.claude/temporal/09-plan.md`, now DONE |
 | D-LNC-7 | **One-WAL ruling**: `LanceCycleWriter`'s watermark WAL vs lance MemWAL — `applied_through` ≡ index catch-up position; two under one commit = two truths. Plan recommends keep-ours until D-LNC-3, then re-decide | **Operator decision** |
+| D-TEMPORAL-1 | **Canonical witness identity probe** (`crates/lance-graph/tests/canonical_witness_identity_probe.rs`): does canonical address identity survive the A-store round trip on lance 11? `NodeGuid → NodeRow → NodeRowPacket::as_le_bytes → cycle commit → drop writer → reopen → scan_image`. Minted through `mint_for(classid_read_mode(c).tail_variant, …)`, never a hardcoded constructor | **GREEN, both rails.** V3 (`CLASSID_OSINT_V3`): payload bytes byte-exact across two cycles and a reopen; `payload[0..16] == G.as_bytes()`; value slab survived (so equality is not a zero-match); each cycle minted exactly `base+1`; head recovered at V2 after restart. V1 legacy control (`CLASSID_OSINT`) round-trips too. **Scope:** proves byte and address fidelity of the store; does NOT prove production reachability — `LanceCycleWriter` still has zero non-test callers (see D-MW-P2) |
+| D-TEMPORAL-1a | **Pinned false-green: the V1 accessor on a V3 key.** 256 V3 addresses varying only in `leaf` → 256 distinct 16-byte keys, 256 distinct `to_hex_v2()`, but **1** distinct `identity()`. Byte fidelity does not imply address fidelity | **Pinned as a positive assertion.** Also pins the second half, which is not a defect: `local_key_v2` yields **1** across the same set BY CONSTRUCTION — `leaf` is the 4th HHTL routing tier (bytes 10..12), part of the addressing prefix, deliberately outside the basin-local key (bytes 12..16). So "use the V3 accessor" is two choices, not one, and the wrong V3 one fails like the V1 one. Do not update the numbers if the assertion breaks — re-audit the call sites |
+| D-V3-MINT-1 | **V3 mint reachability** (`crates/lance-graph-contract/tests/v3_mint_reachability_probe.rs`): `mint_for`'s V2/V3 arm is gated on `guid-v2-tail`, which is NOT in `default`; the registry's V3 entries are gated on `guid-v3-tail`, which is. Two different features, so premise and conclusion can come apart — is a V3-registered classid silently minted into the deprecated V1 layout? | **GREEN — no defect.** `guid-v3-tail = ["guid-v2-tail"]` (`Cargo.toml:69`), so the implication holds. Measured, not inferred: `tail_variant=V3 guid-v3-tail=true guid-v2-tail=true leaf_is_live=true`, key bytes show the V2/V3 carving with `leaf` live at byte 10. Discriminator is `leaf` (the V3 arm feeds it to `new_v2`; the V1 fallback discards it), so the probe stays valid if the feature graph is ever flattened |
+| D-TEMPORAL-2 | **Old-path tripartite change set** (`crates/lance-graph/tests/test_e_old_diff_tripartite.rs`): can store B's snapshot comparison produce `inserted / updated / removed` without any lance delta API? `V1={A,B,D}`, `V2={A,B',C}` | **GREEN.** `inserted={C}` and `updated={B}` from `GraphDiff`; `removed={D}` DERIVED from the same two seal maps `diff()` already materialises (`versioned.rs:550-554`) before discarding the difference — so the missing `removed_nodes` field is an **API omission, not information loss**. Seal gate two-sided AND isolated: the `Staunen` arm runs on a THIRD version `V3={A,B'}` whose only change is dropping `C` — on `V1→V2` that assertion was CONFOUNDED, because `graph_seal_check` returns on its FIRST divergence while walking `to_seals`, so `B`'s update or `C`'s insert trips it before the removal branch (`versioned.rs:632-637`) runs at all, and it would have passed with removal detection deleted (caught by a CodeRabbit finding on #1209). Self-compare ⇒ `Wisdom`. Sharper blind spot now pinned: for a PURE removal `GraphDiff` is entirely empty and its own `seal_status` reads `Wisdom`, contradicting `graph_seal_check`'s `Staunen` on the same version pair. Anti-vacuity: unchanged `A` appears in neither set. Blind spot pinned — if a `removed_nodes` field lands, the assertion must be re-pinned deliberately. **Consequence: historical snapshot comparison is the correctness ORACLE; native lance delta is an optional accelerator, never the architecture** |
 
 ## bindspace-mailbox-soa-wiring-v1 (D-ids minted 2026-09-05 with the plan)
 

.claude/board/SUPERSESSION-INDEX.md

@@ -53,7 +53,7 @@ coverage instead.
 | `StepMask` | BLOCKED | — | 3 | 9 | 4 |
 | `commit_to_l4` | BLOCKED | — | 2 | 2 | 0 |
 | `dispatch_busdto` | BLOCKED | — | 3 | 8 | 5 |
-| `persist_cycle` | BLOCKED | — | 10 | 8 | 5 |
+| `persist_cycle` | BLOCKED | — | 11 | 8 | 5 |
 | `CognitiveMarkers` | REPURPOSE | `Commit` | 1 | 0 | 0 |
 | `DominoCascade` | REPURPOSE | `Commit` | 7 | 1 | 0 |
 | `GateDecision` | REPURPOSE | — | 25 | 27 | 24 |

crates/lance-graph-contract/tests/v3_mint_reachability_probe.rs

@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: Apache-2.0
+
+//! D-V3-MINT-1 — is the V3 tail actually reachable through `mint_for` in the
+//! build configuration production uses?
+//!
+//! `mint_for`'s doc justifies its V1 fallback arm as dead code: *"With the
+//! feature off no classid registers a V2/V3 `tail_variant` (`classid_read_mode`
+//! returns V1), so the fallback arm is dead — it exists purely so the crate
+//! compiles `--no-default-features`."*
+//!
+//! That justification is checkable. The registry's V3 entries are gated on
+//! `guid-v3-tail` (default ON); `mint_for`'s V3 arm is gated on `guid-v2-tail`
+//! (default OFF). Those are two different features, so the premise and the
+//! conclusion can come apart.
+//!
+//! The discriminator is `leaf`: the V3 arm feeds it to `new_v2`, the V1
+//! fallback discards it (`let _ = leaf;`). Two mints differing only in `leaf`
+//! are therefore byte-equal iff the fallback ran.
+
+use lance_graph_contract::canonical_node::{classid_read_mode, NodeGuid, TailVariant};
+
+/// The PREMISE half of `mint_for`'s dead-code claim: does a classid actually
+/// register a V2/V3 tail variant in this build?
+#[test]
+fn a_v3_registered_classid_resolves_to_the_v3_tail_variant() {
+    let m = classid_read_mode(NodeGuid::CLASSID_OSINT_V3);
+    #[cfg(feature = "guid-v3-tail")]
+    assert_eq!(
+        m.tail_variant,
+        TailVariant::V3,
+        "CLASSID_OSINT_V3 must register the V3 tail when guid-v3-tail is on"
+    );
+    #[cfg(not(feature = "guid-v3-tail"))]
+    assert_eq!(m.tail_variant, TailVariant::V1);
+}
+
+/// The CONCLUSION half: given a classid that registers V3, does `mint_for`
+/// reach the V3 arm — or silently fall back to the deprecated V1 layout?
+///
+/// `leaf` is the discriminator, because the V3 arm forwards it to `new_v2`
+/// while the V1 fallback discards it. That keeps this probe meaningful even if
+/// the feature graph is later flattened.
+#[test]
+fn minting_through_the_registered_tail_variant_honours_leaf() {
+    let c = NodeGuid::CLASSID_OSINT_V3;
+    let tv = classid_read_mode(c).tail_variant;
+
+    // The canonical consumer incantation, verbatim from mint_for's doc.
+    let a = NodeGuid::mint_for(tv, c, 0x1111, 0x2222, 0x3333, 0x00AA, 0x0001, 0x0002);
+    let b = NodeGuid::mint_for(tv, c, 0x1111, 0x2222, 0x3333, 0x00BB, 0x0001, 0x0002);
+
+    let leaf_is_live = a.as_bytes() != b.as_bytes();
+
+    eprintln!(
+        "tail_variant={tv:?} guid-v3-tail={} guid-v2-tail={} leaf_is_live={leaf_is_live}\n  a={:02x?}\n  b={:02x?}",
+        cfg!(feature = "guid-v3-tail"),
+        cfg!(feature = "guid-v2-tail"),
+        a.as_bytes(),
+        b.as_bytes(),
+    );
+
+    if tv == TailVariant::V3 {
+        assert!(
+            leaf_is_live,
+            "classid {c:#010x} registers TailVariant::V3, but mint_for produced a \
+             leaf-insensitive key — the V1 fallback arm ran. A V3 class is being \
+             minted into the deprecated V1 layout, silently."
+        );
+    }
+}