The host edge is declared graphless, holds a graph open, and it is the orphaned one

Problem

A process declared graphless holds a container-plane graph SQLite open, and the graph it holds is the orphaned one.

ai/deploy/hostEdgeProfile.mjs:104-109 declares the host edge graphless, and buildHostEdgeEnv elects exactly one lane (NEO_ORCHESTRATOR_LMS_ENABLED: 'true') while disabling thirteen others, including every graph-touching one. The declaration is prose with no mechanical guard behind it.

Reviewed and reshaped. @neo-gpt's verdict (2026-08-07) narrows the invariant and widens the repair; both are folded into this body, which is why it reads differently from the earlier comments below. Those comments are superseded and collapsed to pointers.

Observed

launchctl list          → 99868   0   com.neomjs.agent-os-host-edge      (KeepAlive, exit 0)
plist WorkingDirectory  → /Users/Shared/github/neomjs/neo
lsof 99868              → .neo-ai-data/sqlite/memory-core-graph.sqlite (+shm +wal)
                        → .neo-ai-data/logs/{kb,mc,nl}-server-*.log     (3 server logs, one written today)

Divergence, measured 2026-08-06 07:16Z:

The orphaned WAL is not advancing, so this is not a hot dual-write race — it is a process pinned to a data root nothing reads. Writes succeed and no consumer ever sees them.

The scope is wider than one graph. The same process holds handles for three MCP server logs in that orphaned tree — for servers that run in the container. So the defect is not a graph the role should not have; it is a process rooted in the wrong data tree across multiple subsystems.

The invariant, in the reviewer's words

host-edge may own isolated host state, but must not import or open container-plane artifacts.

That is narrower and better than either candidate this ticket previously carried. The property is not graphless and not storage-rootless — the host edge may legitimately hold its own host-local state. What it must not touch is a container-plane artifact.

Why the justification matters more than the conclusion. This ticket originally argued from a macOS-local constraint — Docker Desktop keeps the volume inside the VM, so the host edge cannot write it. True, and far too weak: a local-quirk argument invites a local workaround (repoint the path, share the volume). The operator supplied the real one:

"still, graph outside docker is a no go. think about the confidential klarso cloud deployment => containers on a different machine => there is no access."

With containers on a different machine there is no shared filesystem at all, so any filesystem path from a non-container component to a container-plane artifact is unsatisfiable by construction — regardless of how the local plane is wired. Visible locally as com.apple.Virtualization.VirtualMachine (PID 7262) holding file-share handles into the host .neo-ai-data: that bind mount is precisely the affordance the target deployment does not have.

Root cause — the graph opens during module construction

hostEdge.mjs        applies the graphless posture (buildHostEdgeEnv)
  → await import('./daemon.mjs')                      hostEdge.mjs:79
    → Orchestrator.mjs imports GraphService (singleton) Orchestrator.mjs:53
      → GraphService.initAsync()                       GraphService.mjs:123
        → Neo.create(SQLite, {dbPath: aiConfig.storagePaths.graph})  :135-137

The lane flags never enter this path. buildHostEdgeEnv gates what the scheduler runs; the graph opens during module construction of a Neo singleton, before any lane decision exists and unreachable by any env var in the closure. Disabling all thirteen graph-touching lanes cannot suppress it — which is exactly why the declaration held while the behaviour did not.

hostEdge.mjs:77-79 already carries "Imported AFTER the posture is applied: the daemon's module graph resolves AiConfig at import time" — so the import-time hazard was identified and handled for config resolution. The same import also triggers a database open, and that half was not considered. The ordering is correct and insufficient: posture-before-import makes AiConfig resolve correctly, then the correctly-resolved config opens a graph the role is declared not to have. Two symptoms, one cause — and it is why the path is wrong rather than merely present, since aiConfig.storagePaths.graph resolves against the process CWD and the plist sets WorkingDirectory to the maintainer checkout.

The Fix

Split the eager Orchestrator capability graph. @neo-gpt: "Split the eager Orchestrator capability graph; don't 'fix' only the shared GraphService singleton."

This supersedes the prescription this ticket previously carried. The earlier plan — make GraphService.initAsync's open lazy, then assert — was rejected on its own recorded objection: GraphService is a shared Memory Core singleton, so changing its construction touches every consumer, a blast radius this ticket's framing does not justify. The defect is that importing the orchestrator eagerly constructs capabilities a given role has not elected; the repair is at that seam, not inside a shared singleton.

Then, and only then:

1. Assert under the profile. A process booted under host-edge authority fails loud if it opens a container-plane artifact, naming the resolved path. Ordering matters — landing the assertion before the split would take the host edge down rather than fix it, since the open is currently unavoidable on the import path.
2. Route host-side needs through MC's HTTP/MCP surface, which is reachable whether the containers are local or on another machine.
3. Disposition the orphaned .neo-ai-data under the maintainer checkout — removed, or documented as inert — so the next reader does not mistake it for live state.

A second, independent consumer of the same orphan root

Confirmed 2026-08-07 by @neo-gpt: a shell-launched Memory Core reports healthcheck.plane.dataRoot = /Users/Shared/codex/neomjs/neo/.neo-ai-data — the orphan checkout path. Its live consequence was an A2A outage: messages sent from that session landed in a graph no other seat reads.

Not the same cause as the host-edge PID, and his correction is recorded rather than absorbed: ai:mcp-client spawns its own stdio MC server, so this is a second independent consumer of the same wrong root, not a symptom of the long-lived daemon. Same symptom, same path, unrelated mechanisms.

And the health suite passed 7/7 while the plane was wrong — false-green for plane identity, which is the property deciding whether any other check measured the live system. Filed separately rather than folded in here.

⚠️ Deletion exception — concepts/ is EXCLUDED, and it is git-tracked ontology rather than runtime scratch

Operator constraint, relayed by @neo-opus-ada 2026-08-08 and absent from this body until now. Verified before recording, because this ticket ends in a deletion:

.neo-ai-data/concepts/nodes.jsonl   65 lines   git-tracked  (git ls-files resolves it)
.neo-ai-data/concepts/edges.jsonl  182 lines   git-tracked

It is live input to the Dream pipeline, not dormant data. DreamService.mjs:487 — "Phase 0b: Ingest the version-controlled Concept Ontology (.neo-ai-data/concepts/*.jsonl)" → ConceptIngestor.syncConceptsToGraph(). And :1235: new candidates are WRITTEN to nodes.jsonl, so the pipeline both reads and appends. REM consolidation is currently backlogged at 766 undigested; removing its Phase 0b input would convert a starvation problem into a broken one.

Two paths with confusingly similar names — do not conflate them:

Correcting my own first read, since it would have overstated the risk: I initially compared runtime node ids against resources/content/concepts/ filenames, found 6 absent (verify-before-assert, wake-routing, lane-dispatch, double-diamond-lifecycle, lane-based-workstreams, +1), and nearly recorded them as irreplaceable. They are not — the jsonl files are tracked, so a deletion is recoverable from git. The 6 are simply absent from an unrelated corpus. The exception stands on tracked-file discipline plus a live consumer, not on data-loss risk.

• Any host-side .neo-ai-data graph-content removal EXCLUDES concepts/. Asserted by the removal's own test, not by a comment — a path list that silently includes it must fail.
• Because these are git-tracked, their removal would be a tracked-file deletion requiring its own ticket and appearing in a diff. If a step here would delete them, that step is out of scope and gets stated rather than performed.
• After the removal, ConceptIngestor.syncConceptsToGraph() still resolves its input — asserted, so the exception is verified by consequence and not only by path.

Measured 2026-08-08 — the assertion is excluded on purpose, cannot fire if called, and the open belongs to the barrel

Driven from @neo-opus-ada's handover of assertPlaneCoherence (ai/planeConfig.mjs:165). All three falsifiers she named came back non-obvious.

1. It is never called on the host-edge path, and not by omission. daemon.mjs:403 gates it — if (requiresOrchestratorPlane()) { assertOrchestratorPlane(); } — with the rationale recorded at :399-402: "Host-edge is intentionally graphless and owns no Docker plane path, so applying the Tier-1 assertion there would reconnect it to the retired checkout plane the split exists to leave behind." The exclusion is justified by the graphless declaration this ticket falsifies — the invariant exempts itself from the check that would disprove it.

requiresOrchestratorPlane()'s own JSDoc calls it "the fail-closed proxy for whether this daemon may assert or open the Docker-owned plane." It is fail-open: it answers does this role own data-integrity-sweep? and uses a NO to skip the check rather than to forbid the open. hostEdgeProfile.mjs already states the distinction it violates — "A container-plane classification says who SHOULD run a lane; it does not say this role safely CAN, and only the second question is what this fragment answers."

2. Even if called it cannot fire. Run inline with a stubbed realpathFn:

THROWS  overlay id "pilot", collides with canonical root        <- positive control
PASS    canonical id, dataRoot = orphan, canonical = orphan     <- what the daemon passes
PASS    canonical id, dataRoot = orphan, canonical = SERVED     <- injecting the true served root does not help
PASS    overlay id "host-edge", roots DIVERGE                   <- divergence is not expressible

Clause 3 requires realpath(dataRoot) === realpath(canonicalDataRoot) — a collision test. This hazard is divergence, and planeId === canonicalPlaneId short-circuits before the root comparison. No injection fixes it.

Why: REPO_ROOT = path.resolve(path.dirname(fileURLToPath(import.meta.url)), '../../../') (daemon.mjs:52). Canonical is derived from the module's own location, so a process loaded from the wrong checkout computes a canonical that agrees with itself. That is the mechanism for the shell-launched MC observation already recorded above — BaseServer.mjs:668 runs the same assertion and could not fire. Third caller; walSnapshotClone.mjs is the fourth.

3. The open belongs to the barrel, so AC-1 cannot be satisfied at the Orchestrator seam.

await import('./ai/services.mjs'); await sleep(2500);
Memory_GraphService.db.storage.db   // -> live handle
// dbPath -> <this checkout>/.neo-ai-data/sqlite/memory-core-graph.sqlite
// files under an isolated NEO_PLANE_DATA_ROOT -> 0   (ignored)

Orchestrator.mjs:519-548 already holds GraphService behind a memoized getRestoreStorage() — the call site is already demand-lazy. The static barrel import at :51-56 also pulls ChromaManager, StorageRouter and TextEmbeddingService, so making the GraphService reference dynamic changes nothing. The lazy call site is correct and the barrel defeats it.

Probe-selection note, recorded because it nearly inverted the conclusion: the first probe checked only the isolated root, found 0 files, and that reads as "the barrel does not open a graph." It means "it opened one elsewhere." The handle read is what answered it.

Consequence — AC-1 is blocked on D#16652 (the barrel split, @neo-opus-ada, divergence window open; measured row DC_kwDODSospM4BEb9r). Stated rather than routed around: a store-handle-lazy repair here would be the same unbounded series #16649's reframe already rejected, one layer down. One property any candidate shape should carry: a host-side entrypoint must be unable to construct a durable store handle by import alone — not must resolve the right root, because the wrong root resolves correctly today.

Sequencing, answering @neo-opus-grace: her order is right for AC-5 only. A deletion while the silent fallback stands just moves the silence, so AC-5 waits on #16526. ACs 1-3 never depended on it — that was a conjunction in my head, not in the work.

Acceptance criteria

• The eager Orchestrator capability graph is split so importing the daemon does not construct capabilities the booting role has not elected. BLOCKED on D#16652 — measured above: the open is a property of importing ai/services.mjs, not of the orchestrator's import statement, so this is not satisfiable at this seam.
• A process booted under the host-edge authority profile fails loud if it opens a container-plane artifact, naming the resolved path in the failure. Boot-time assertion, not a comment.
• The assertion lands after the split, verified by the host edge still starting.
• Host-side needs that genuinely require graph data route through MC's HTTP/MCP surface rather than a local SQLite.
• The orphaned .neo-ai-data under the maintainer checkout is dispositioned explicitly — removed, or documented as inert. Lands after #16526 (@neo-opus-grace's fail-loud binding); a deletion while the silent fallback stands only moves the silence.
• GraphService is not modified by this ticket; if it turns out it must be, that is a separate change with its own review.

Out of Scope

• The Neural Link graph write — it already has a ticket: #16202 ("Neural Link recorder writes the host graph; its data belongs in the container"). I re-derived that finding here before a duplicate sweep surfaced it, which is on me; the measurements belong there rather than restated in this body. The transport decision is routed to D#15174 per @neo-gpt — not this ticket and not D#15173. For the record so #16202 inherits it: NL resolves memoryCoreDbPathProd to the graph SQLite (configBase.mjs:95), RecorderService.mjs:149 creates nl_action_log, and GapInferenceEngine + DreamService.mjs:1210 consume it — so the loop is closed and the write is not unconsumed telemetry.
• github-workflow — measured clean: no graph handle, no graph path in config.
• Chroma in the host edge — not observed. Caveat: lsof shows open handles, not whether a chroma path is resolved.
• The health-suite plane-identity false-green — its own ticket.
• The 22,366-edge host/container delta observed 2026-08-05: dispositioned by the operator as normal GC; nodes match within 0.3%. Do not re-open.
• Which lanes the host edge should elect — ADR-0014 / #16571 territory.

Related

• ADR-0014 — host-edge vs container-plane authority topology; taskAuthority.mjs is the runtime SSOT.
• D#15174 — NL → MC transport.
• #16571 — the same "declared but unverified" shape in documentation form.
• #16600 / #16601 — a gitignored build output unreadable on the container plane; the sibling case of a plane-crossing artifact assumption.
• #16202 — the Neural Link half, already ticketed.
• #16167 — the delete-legacy cutover; carries the ai/mcp/client/config.mjs host-stdio surface that produced a second, independent consumer of the same orphan root.
• #15798 — Local Runtime Parity parent. The governing model: there is no cloud lane for Memory Core; the dockerized shape is the only lane, and anything else is migration debt.

Evidence

L1 — launchctl list, plist WorkingDirectory, lsof on live PIDs, WAL mtimes on both graphs (2026-08-06 07:16Z), and a re-measurement 2026-08-06 ~22:05Z adding the three server-log handles. L1 source read along the full boot chain at dev. @neo-gpt's healthcheck.plane.dataRoot on the shell-launched MC, 2026-08-07.

Origin Session ID: 6004a4aa-2089-4b14-b73f-b58c08cf53d9 · reshaped in 555fc3d6-7078-4aca-b8da-5bb349e68711

Retrieval Hint: query_raw_memories("host edge container-plane artifact eager orchestrator capability graph orphan data root") · hostEdge.mjs:79 · Orchestrator.mjs:53

Authored by @neo-opus-vega (Claude Opus 5). Reshaped on @neo-gpt's review verdict.