The plane assertion cannot detect the hazard its own rationale names

Context

assertPlaneCoherence (ai/planeConfig.mjs:165) is the boot-time plane guard for all three Tier-1 consumers. Measured 2026-08-08: it passes on a process rooted in the wrong checkout, which is the hazard its callers' rationale explicitly names.

Surfaced while implementing #16582, where the host-edge case is one instance. This ticket owns the general defect, because it is not host-edge specific — it affects every caller.

The Problem

assertOrchestratorPlane's JSDoc (ai/daemons/orchestrator/daemon.mjs) states the harm:

"A server booted onto the wrong plane returns wrong answers and someone notices; a scheduler booted onto the wrong plane mutates the wrong durable store on a timer, and the first evidence is data that should not be there."

Booted onto the wrong plane is exactly the shape that passes. Run inline with a stubbed realpathFn:

THROWS  planeId "pilot",  dataRoot = SERVED,  canonical = SERVED   <- positive control: the clause works
PASS    planeId canonical, dataRoot = ORPHAN, canonical = ORPHAN   <- what the daemon actually passes
PASS    planeId canonical, dataRoot = ORPHAN, canonical = SERVED   <- the TRUE served root injected
PASS    planeId "host-edge", roots DIVERGE                         <- divergence, at any identity

Clause 3 requires realpath(dataRoot) === realpath(canonicalDataRoot) — a collision test, for an isolated overlay that resolves the durable root. The wrong-checkout hazard is divergence, and planeId !== canonicalPlaneId short-circuits before the roots are compared. No injection fixes it: row 3 supplies the correct served root and still passes.

To be precise about what is and is not overclaimed. Clause 1's own wording is accurate — "a non-canonical plane must not resolve the canonical durable root" is exactly what it does. The gap is between that clause and the rationale above it, which promises protection against booting onto the wrong plane generally. A reader takes the rationale; the clause delivers something narrower.

Why it cannot fire — the canonical root is self-derived

ai/daemons/orchestrator/daemon.mjs:52
const REPO_ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '../../../');

canonicalDataRoot is computed from the module's own location. A process loaded from the wrong checkout therefore computes a "canonical" root that matches its own perfectly, and the assertion confirms the process agrees with itself. The guard is structurally incapable of the comparison it exists to make — a cannot-FAIL defect, not a tuning problem.

It has already fired in the field, and the symptom is recorded

@neo-gpt observed a shell-launched Memory Core reporting healthcheck.plane.dataRoot = /Users/Shared/codex/neomjs/neo/.neo-ai-data — an orphan checkout. BaseServer.mjs:668 runs this same assertion at that server's boot. It did not fire because it could not. That observation is recorded on #16582 with no mechanism attached; this is the mechanism.

The Architectural Reality

Three callers inherit the blindness, each on a write path:

walSnapshotClone is the honest one: it uses the clause for exactly what the clause tests, and its own comment (:151) already notes a case "which planeConfig.assertPlaneCoherence cannot detect: its overlay clause only …". The limitation was known at one call site and did not propagate to the other two.

The Fix

The bound requires a served root — a fact about which plane is authoritative — and that cannot be derived from the process's own location by construction. Two honest directions, and this ticket does not presume which:

1. Make it detectable. Supply the served root as external context (the shape the recovery-knob registry already uses for runtime-resolved bounds) and add a divergence clause beside the collision clause.
2. Make it honest. If no external served-root fact is available at boot, the rationale and the callers' comments must stop implying coverage they do not provide, and the residual exposure must be named where a reader meets it.

Doing neither is the current state and is the worst of the three, because three write-path callers presently read as protected.

Acceptance Criteria

• A spec asserts the wrong-checkout shape explicitly — the four rows above, with the collision case retained as the positive control so a future change cannot make the guard vacuous without failing.
• Either a divergence clause exists and fires on a diverging root, or the rationale at every caller states plainly that wrong-checkout boot is out of the clause's reach. Not silence.
• walSnapshotClone.mjs:151's existing limitation note is reconciled with whatever lands, so the knowledge lives in one place rather than at one of three call sites.
• If direction 1 is taken, the served-root fact is externally supplied, never derived from import.meta.url — a self-derived canonical is the defect, so a fix that re-derives it reproduces the defect.
• The recorded live symptom (#16582's shell-launched Memory Core on the codex checkout) is cited as the specimen rather than a hypothetical.

Out of Scope

• #16582 — the host-edge instance and its barrel-blocked capability split. This ticket is the general assertion; that one is a specific process's graph handle.
• The barrel / eager-singleton question — D#16652.
• #16604 — the integration-parity suite's naming. Adjacent (both concern plane isolation) and different: that is a CI-suite discoverability question, this is a runtime guard's reach.
• Choosing between direction 1 and 2. Both are honest; the choice depends on whether a served-root fact exists at boot, which is the first thing the implementer should measure.

Avoided Traps

• Claiming the clause is wrong. It is not — it does exactly what its own wording says. The defect is the distance between the clause and the rationale a reader relies on, and a ticket that attacked the clause would break the overlay protection that works.
• "Add a positive control" as the fix. That is the cannot-FAIL remedy, and this is a cannot-FAIL defect at the clause level rather than the test level — a control on a guard that cannot reach its subject only proves the guard runs.
• Re-deriving canonical more carefully. Any derivation from the process's own location reproduces the defect exactly; the input has to come from outside the process.
• Assuming the host-edge fix covers it. #16582 addresses one profile; the recorded live symptom is a different caller on a different checkout.

Related

#16582 (the host-edge instance and the recorded symptom) · #16636 (the same served-root-is-not-config-resolvable problem, on the knob bound) · #16604 (adjacent, plane isolation in CI) · D#16652.

Live latest-open sweep: latest 20 open issues checked at 2026-08-08T07:11:44Z; no equivalent found. A2A in-flight claim sweep at the same time: active claims are #16535/#16659 (@neo-opus-grace) and #16604/#16629 (@neo-opus-ada); none overlap.

Origin Session ID: 4141258c-36d3-4788-b0c2-ab3ebe0867be

Retrieval Hint: query_raw_memories("assertPlaneCoherence collision clause cannot detect divergence, canonicalDataRoot derived from import.meta.url self-agreeing")

Retrieval Hint: the discriminating probe is injecting the TRUE served root as canonicalDataRoot — it still passes, which proves no caller can fix this by supplying a better argument.