Problem
ai/configBase.mjs:124 — id: leaf(CANONICAL_PLANE_ID, 'NEO_PLANE_ID', 'string', {parse: parsePlaneIdEnv}).
A deployment that sets no NEO_PLANE_ID inherits the canonical local plane id. Observed live: two independent planes — one a remote long-running deployment, one a local dev machine — both answer plane.id = "neo-local-canonical" on both the Memory Core and Knowledge Base healthchecks.
Why this is a safety defect, not a naming nit
Plane id is a safety-assertion input. The lifecycle README prescribes --expected-plane-id neo-local-canonical, and mcpHealthcheck.mjs accepts --expected-plane-id precisely so a caller can prove it is talking to the intended plane.
When two planes share the id, that assertion passes against the wrong target while appearing to prove the right one. Any pipeline step, restore, or destructive-op guard keyed on plane identity is blind. This is the same failure family as #16567: a well-formed pass on the wrong subject.
Not theoretical — cross-plane writes were observed in practice (artifacts from one repository's work sitting in a different plane's store). The shared id is what makes such a mistake undetectable rather than what causes it.
Acceptance criteria
Out of scope
Remediating any specific deployment's config — that is operator work on the deployment side. This ticket is the substrate guard so omission stops being silently valid.
Evidence: L1 — config leaf read plus plane.id observed on two independent planes via mcpHealthcheck.mjs --expected-plane-data-root, 2026-08-06. Negative control confirmed the probe is path-sensitive (a bogus --mcp-path errors rather than answering).
Authored by @neo-opus-vega (Claude Opus 5).
Problem
ai/configBase.mjs:124—id: leaf(CANONICAL_PLANE_ID, 'NEO_PLANE_ID', 'string', {parse: parsePlaneIdEnv}).A deployment that sets no
NEO_PLANE_IDinherits the canonical local plane id. Observed live: two independent planes — one a remote long-running deployment, one a local dev machine — both answerplane.id = "neo-local-canonical"on both the Memory Core and Knowledge Base healthchecks.Why this is a safety defect, not a naming nit
Plane id is a safety-assertion input. The lifecycle README prescribes
--expected-plane-id neo-local-canonical, andmcpHealthcheck.mjsaccepts--expected-plane-idprecisely so a caller can prove it is talking to the intended plane.When two planes share the id, that assertion passes against the wrong target while appearing to prove the right one. Any pipeline step, restore, or destructive-op guard keyed on plane identity is blind. This is the same failure family as #16567: a well-formed pass on the wrong subject.
Not theoretical — cross-plane writes were observed in practice (artifacts from one repository's work sitting in a different plane's store). The shared id is what makes such a mistake undetectable rather than what causes it.
Acceptance criteria
NEO_PLANE_IDis REQUIRED when the deployment mode iscloud(or otherwise non-local): boot fails closed with a message naming the variable, rather than silently inheriting the local canonical id.NEO_PLANE_IDfails; a local-mode config still defaults as today.Out of scope
Remediating any specific deployment's config — that is operator work on the deployment side. This ticket is the substrate guard so omission stops being silently valid.
Evidence: L1 — config leaf read plus
plane.idobserved on two independent planes viamcpHealthcheck.mjs --expected-plane-data-root, 2026-08-06. Negative control confirmed the probe is path-sensitive (a bogus--mcp-patherrors rather than answering).Authored by @neo-opus-vega (Claude Opus 5).