Arm the plane-bearer alias teeth on the host dev journey (NEO_MCP_HEALTHCHECK_TOKEN_FILE host-side)
Follow-up to #17286 (dormancy recorded here, surfacing in @neo-opus-vega's APPROVED review of PR #17287). The assert variant now guards the dev entry's plane credential, but its alias teeth are host-side dormant: nothing on the host launch path exports NEO_MCP_HEALTHCHECK_TOKEN_FILE, so the admission-token comparison skips and the assert behaves like the bare resolver on the stock dev journey.
Context
fleet.admissionTokenFile binds NEO_MCP_HEALTHCHECK_TOKEN_FILE. Every setting in the tree is a Compose file with a container path (docker-compose.yml:618, local-agent-os.yml:15, parity-capture.yml:58/90, dev.yml:125); the bootstrap/healthcheck PAT is provisioned at deploy time as a file-backed Compose secret. Meanwhile the host-side diagnostics (ai/scripts/diagnostics/mcpHealthcheck.mjs, fleetHealthcheck.mjs) already accept the same env var / --bearer-token-file as a HOST path — so a host-readable reference to the token is an established pattern, not a new custody class in principle.
The Problem
The credential-class ledger's alias refusal (a plane bearer that IS the deployment's admission token fails boot) is proven in Compose profiles and dormant on the exact journey where aliasing is most plausible by hand: the operator's host dev journey targeting the containerized plane (#17276's cockpit:live / ai:fleet-server). A deployment copied together carelessly — same token exported into both roles on the host — boots clean today on that journey while production would refuse it.
The Fix (investigation first, then the smallest honest wiring)
- Answer the custody question: does a host-readable copy or reference of the admission token legitimately exist post-provisioning (the deploy reads it from somewhere —
ai/deploy env handling)? If the design answer is the host must never hold it, record that as the disposition and close — dormancy then becomes a documented design property, not a gap.
- If provisionable: the dev launch path (the
cockpit:live composition and/or the standalone ai:fleet-server journey) exports NEO_MCP_HEALTHCHECK_TOKEN_FILE pointing at the host-readable copy when — and only when — the journey targets a containerized plane. No copying the secret into a new location; the export names the existing custody home. The assert then self-arms with zero code change (assertFleetPlaneBearerClass already reads the leaf).
- Witness: a host boot with the file exported + an aliased plane bearer fails with the named ledger refusal; with distinct credentials, boots plane-side.
Decision Record impact
aligned-with ADR 0019 (the leaf already exists and binds the env var; this is consumption, not new config) · may cite ADR 0038 §2.5.1 (the S6 credential ledger) for the custody ruling.
Acceptance Criteria
Out of Scope
Changing the Compose-side provisioning (already correct) · the viewer-MC-authorization credential chain (separate class) · any new secret materialization on the host without a recorded custody decision.
Related
#17286 (the dormant guard) · PR #17287 (its arming) · #17276 / PR #17277 (the host journey) · Vega's dormancy analysis (PR #17287 review) · ai/services/fleet/fleetServer.mjs (assertFleetPlaneBearerClass).
Live latest-open sweep: latest 20 open checked 2026-08-17T09:10Z, no equivalent; A2A herd-window sweep clean.
Origin Session ID: 0c5a1cf3-093b-4e9d-a7ba-74137e4d4f23
Retrieval Hint: query_raw_memories("admissionTokenFile host-side dormant alias teeth NEO_MCP_HEALTHCHECK_TOKEN_FILE dev journey")
Arm the plane-bearer alias teeth on the host dev journey (
NEO_MCP_HEALTHCHECK_TOKEN_FILEhost-side)Follow-up to #17286 (dormancy recorded here, surfacing in @neo-opus-vega's APPROVED review of PR #17287). The assert variant now guards the dev entry's plane credential, but its alias teeth are host-side dormant: nothing on the host launch path exports
NEO_MCP_HEALTHCHECK_TOKEN_FILE, so the admission-token comparison skips and the assert behaves like the bare resolver on the stock dev journey.Context
fleet.admissionTokenFilebindsNEO_MCP_HEALTHCHECK_TOKEN_FILE. Every setting in the tree is a Compose file with a container path (docker-compose.yml:618,local-agent-os.yml:15,parity-capture.yml:58/90,dev.yml:125); the bootstrap/healthcheck PAT is provisioned at deploy time as a file-backed Compose secret. Meanwhile the host-side diagnostics (ai/scripts/diagnostics/mcpHealthcheck.mjs,fleetHealthcheck.mjs) already accept the same env var /--bearer-token-fileas a HOST path — so a host-readable reference to the token is an established pattern, not a new custody class in principle.The Problem
The credential-class ledger's alias refusal (a plane bearer that IS the deployment's admission token fails boot) is proven in Compose profiles and dormant on the exact journey where aliasing is most plausible by hand: the operator's host dev journey targeting the containerized plane (#17276's
cockpit:live/ai:fleet-server). A deployment copied together carelessly — same token exported into both roles on the host — boots clean today on that journey while production would refuse it.The Fix (investigation first, then the smallest honest wiring)
ai/deployenv handling)? If the design answer is the host must never hold it, record that as the disposition and close — dormancy then becomes a documented design property, not a gap.cockpit:livecomposition and/or the standaloneai:fleet-serverjourney) exportsNEO_MCP_HEALTHCHECK_TOKEN_FILEpointing at the host-readable copy when — and only when — the journey targets a containerized plane. No copying the secret into a new location; the export names the existing custody home. The assert then self-arms with zero code change (assertFleetPlaneBearerClassalready reads the leaf).Decision Record impact
aligned-with ADR 0019(the leaf already exists and binds the env var; this is consumption, not new config) · may cite ADR 0038 §2.5.1 (the S6 credential ledger) for the custody ruling.Acceptance Criteria
~/.neo-ai/secrets/mcp-auth-tokenIS the Compose secret source (docker-compose.local-agent-os.yml), not a copy.If design-dormant: the disposition is written into— N/A by the AC-1 ruling (provisionable branch taken); the doc's live-plane section still documents the arming + standalone-journey export.learn/agentos/RunningTheFleetCockpit.md's live-plane section and this ticket closes asnot_planned-with-record.Out of Scope
Changing the Compose-side provisioning (already correct) · the viewer-MC-authorization credential chain (separate class) · any new secret materialization on the host without a recorded custody decision.
Related
#17286 (the dormant guard) · PR #17287 (its arming) · #17276 / PR #17277 (the host journey) · Vega's dormancy analysis (PR #17287 review) ·
ai/services/fleet/fleetServer.mjs(assertFleetPlaneBearerClass).Live latest-open sweep: latest 20 open checked 2026-08-17T09:10Z, no equivalent; A2A herd-window sweep clean.
Origin Session ID: 0c5a1cf3-093b-4e9d-a7ba-74137e4d4f23
Retrieval Hint:
query_raw_memories("admissionTokenFile host-side dormant alias teeth NEO_MCP_HEALTHCHECK_TOKEN_FILE dev journey")