contract + ontology: complete the classid → ClassView resolution (UNICHAR adapter, keystone, OGAR→ontology wiring)

.claude/board/EPIPHANIES.md

@@ -7,6 +7,13 @@
 **Honest scope.** The curated-only manifest resolves a *small* set today — most curated models inherit *uncurated* mixins (`mail.activity.mixin`, `sequence.mixin`), so few overrides have both ends present. Not fabricated: the resolver is total and the breadth grows as mixins are curated OR the SPO manifest is supplied. This is the same Curated-leg / Extracted-leg convergence the structural correction established, now for the derived relation.
 
 **Wishlist status:** all six items are now home-correct — P0/P1/P1b/P2/P3 as typed-Core facts + Extracted-leg breadth (#523/#526/#527/#530/#532), and `virtually_overrides` as this computed ClassView relation. None of them is a standalone flat-ndjson harvest predicate; the predicate-bolt-on cadence is fully retired. Cross-ref: `mro.rs` module doc; E-ODOO-CORE-FIRST-STRUCTURAL; the #531 `RegistryClassView` (the contract-side ClassView this resolution feeds).
+## 2026-06-18 — E-OGAR-ONTOLOGY-WIRED-1 — the OGAR→ontology link is closed: NodeGuid → ClassView now resolves (audit found the gap, this lays the join)
+
+**Status:** FINDING (in-crate, tested). The OGAR→lance-graph-ontology audit this session found `NiblePath::from_guid_prefix` (the canon GUID→NiblePath fold) and `OntologyRegistry`'s `entity_type ↔ NiblePath` bijection BOTH built with **ZERO callers** — the two halves of the bridge forged, never chained. `OntologyRegistry::class_id_for_guid(&NodeGuid) -> Option<ClassId>` lays the join: `from_guid_prefix(guid)? → entity_type_of(path)`. A node row carrying a `classid` now resolves its ontology class (`entity_type`/`ClassId`), which `RegistryClassView` already turns into the class shape (fields/labels/template/DOLCE).
+
+**Aligned with E-ODOO-CORE-FIRST-STRUCTURAL (below).** That entry says structural facts belong in the *typed OGAR Core*, not bolted-on SPO predicates. This wiring is the Core-side resolution it implies — the GUID→ClassView path makes the typed Core reachable. It adds NO predicate and NO new type, just a method composing two existing surfaces.
+
+**Consistency invariant pinned.** The audit flagged a latent hazard: `from_guid_prefix` *derives* a path from the GUID's low-u16 classid; `register_class_path` *stores* an externally-supplied path — nothing guaranteed they coincide. The round-trip test (`class_id_for_guid_wires_ogar_guid_to_classview`) pins it: `register_class_path(t, from_guid_prefix(guid))` ⟹ `class_id_for_guid(guid) == Some(t)`; zero-fallback (unbound GUID → None); lossy fold refused upstream (high classid u16 → None, no silent collision). With this, all three "classid → X" axes are reachable from a GUID: read-mode (`classid_read_mode`, via ocr.rs), methods (`codegen_manifest::methods_for`, via the unicharset keystone E-CPP-KEYSTONE-1), and now ontology-shape. Branch work.
 
 ## 2026-06-18 — E-ODOO-CORE-FIRST-STRUCTURAL — structural Odoo facts belong in the typed OGAR Core, NOT the SPO harvest; the predicate-bolt-on cadence was drift
 
@@ -56,6 +63,13 @@ Two code objects share the term **"witness arc"** but operate on **different val
 **Why they must NOT be welded under a `WitnessArcEvaluator` trait:** (a) no inner-product/transform structure exists over opaque identity tuples — superposing them is the register-loss `I-VSA-IDENTITIES` forbids; (b) a trait with one math impl in an *excluded* crate and zero call-sites is AP6 speculative generality; (c) the AGI-as-glove doctrine bars a new trait/bridge ("new capability = new column, not a new layer"); (d) the trait would force the **zero-dep** contract crate to gain a `perturbation-sim` dependency / `f64` field semantics (baton CATCH-CRITICAL, dep-direction inversion). The genuine relationship is a **pipeline seam** (W-slot arc *addresses*, numeric column *evaluates*) — a consumer-side free function over a borrowed `&[f64]` column, never a unifying trait.
 
 **Secondary correction (truth-architect + brutally-honest-tester):** the `witness.rs` doc overclaimed per-arc cost as `q·O(N)`; as implemented `witness_from_spectrum` re-transforms each arc (`O(N log N)`), so the honest total is `O(N log N) + q·O(N log N)`, narrowing to `q·O(N)` only for precomputed/structured arc spectra. The amortized quantity is the **field** transform, not the arc dot. Doc-string corrected; no measured speed claim is made. Cross-references added in both files; seam recorded as `TD-WITNESS-EVAL-WIRING-1`, wiring gated as D-MBX-A3 (on D-MBX-A2 + OQ-11.2 + a §0 dep-direction ruling).
+## 2026-06-18 — E-CPP-KEYSTONE-1 — the core-first transcode is proven END-TO-END: classid → ClassView → content store → adapter dispatches with no Core gap
+
+**Status:** FINDING (in-contract, tested). `lance_graph_contract::unicharset_adapter::invoke_unicharset` wires the proven `UniCharSet` adapter (E-CPP-PARITY-1, 112/112) through the OGAR Core's three movable parts — completing steps 2–3 of `PROBE-OGAR-ADAPTER-UNICHARSET` (the doctrine's falsifier), which step 1 (E-CPP-PARITY-1) and the generalization (E-CPP-PARITY-2, UNICHAR) had left as "mechanical wiring, conjectured."
+
+**What the keystone proves.** The doctrine claimed the OGAR Core makes the transcode clean: identity = classid, composition = `classid → ClassView` (the harvested `has_function` manifest), state = classid-keyed content-store tier, invocation = thin DO-in/DO-out. The keystone is the first place all three meet: `invoke_unicharset` gates on `methods_for(registry, classid)` (composition), resolves `UniCharSetStore::unicharset(classid)` (content tier), and routes to the proven leaf — and the `NULL`→space byte-parity edge survives the whole dispatch path. **The iron guard held with zero strain:** no adapter-state-leak (the adapter holds nothing; the bijection rides the content tier), no Core gap (no new tenant / ClassView capability needed), no parallel object model. The doctrine's central worry ("the adapter needs state the Core can't carry") is now refuted not just for the leaf (parity) but for the composed dispatch.
+
+**Consequence.** Core-first transcode is no longer "proven for one leaf's bytes" — it is proven END-TO-END for the unicharset class: a classid composes its adapters via the manifest, dispatch reaches them through the content tier, output is byte-faithful. The remaining transcode is repetition of a validated pattern (each new leaf = its own one-`diff` parity + a manifest entry), not new architecture. The composition gate also yields the zero-fallback for free (an unconfigured classid composes nothing → a typed refusal, never a panic). Contract module `D-UNICHARSET-KEYSTONE`. Branch work, not yet a PR.
 
 ## 2026-06-17 — E-ODOO-SPO-INHERITS-VALKIND — spo_enrich extended with inherits_from (P1b/ruff#19) + validation_kind (P2/ruff#21); corpus regen pending Odoo source
 
@@ -78,6 +92,13 @@ Two code objects share the term **"witness arc"** but operate on **different val
 **Regression discipline (the "one NaN less + something to check against"):** three new tests drive the precursor regime (near-zero bridge, fully disconnected graph, degenerate ring) and assert NaN-freedom on every output + sentinel-correctness on fragmentation; one parity test (asymmetric weighted path, genuinely separated `λ₂`) pins that the gate **does not perturb healthy-grid numbers** — it gates ONLY the singular path. 91 → 95 `perturbation-sim` tests, clippy `-D warnings` clean.
 
 **Adjacent (NOT in B1 scope — a different mechanism):** `acflow.rs` (the AC Newton–Raphson power-flow path) carries its own division landmines — `Cx::recip` divides by `|z|²` (NaN on a zero-impedance line `r=x=0`) and the Jacobian partials `dp_dv`/`dq_dv` divide by bus voltage `v[i]` (a divergent NR iteration could drive `v→0`). These are **voltage-collapse**-regime sites, not spectral-fragmentation, and are gated differently (the `solve_linear` partial-pivot `best < 1e-13 → return false` already protects the linear solve, and a non-converged solve returns `converged: false`). Flagged here for a future AC-flow NaN pass; B1 deliberately scoped to the Laplacian-spectral path the task named.
+## 2026-06-17 — E-CPP-PARITY-2 — the transcode generalizes: a SECOND Tesseract adapter (UNICHAR) is byte-identical to libtesseract, and proves why "just use core::str" fails
+
+**Status:** FINDING (in-env; exhaustive on the step table). `lance_graph_contract::unichar::{utf8_step, utf8_to_utf32}` (transcoded from `ccutil/unichar.cpp`) matches the C++ `UNICHAR` libtesseract oracle **268/268 byte-identical** — ALL 256 `utf8_step` lead-byte values (exhaustive, not sampled) plus 12 `utf8_to_utf32` corpus rows. This is the SECOND adapter through the pipeline after `UniCharSet` (E-CPP-PARITY-1), so `PROBE-OGAR-ADAPTER-UNICHARSET` is no longer a single data point — the core-first transcode generalizes across distinct classes (a content-store tier AND a pure codec).
+
+**The sharper finding — why a faithful transcode is mandatory, not optional.** Tesseract's `utf8_step` table maps `0xC0`/`0xC1` (overlong 2-byte leads) to step 2, and `UTF8ToUTF32` decodes the overlong NUL `C0 80` to codepoint `0` (it validates only the lead byte, never re-checks continuations). Rust's native `core::str::from_utf8` REJECTS both as invalid UTF-8. So the "obvious" shortcut — delegate UTF-8 to the standard library — would have DIVERGED from the oracle on real inputs. The behaviour-preservation rule (transcode the algorithm, do not "fix" it) is not pedantry here; it is the difference between byte-parity and silent corruption. The `from_utf8_rejects_what_tesseract_accepts` test pins the gap so a future "simplification" cannot quietly erase it.
+
+**Consequence.** The doctrine falsifier (flipped CONJECTURE→FINDING by E-CPP-PARITY-1) now has a second confirming adapter, with an *exhaustive* proof on its core table. The remaining Tesseract→pure-Rust OCR transcode is leaf-by-leaf adapters, each carrying its own one-`diff` parity check; the method itself is validated. Branch work (not yet a PR); contract module `D-UNICHAR-1`.
 
 ## 2026-06-17 — E-ODOO-EXTRACT-DEEP-READS — the consumer-side recompute-DAG probe surfaces a corpus enrichment ask, not a ClassView gap