Context
neomjs/neo-agent-institution#211 lets the packaged Fleet Manager shell attach to a plane from its own first-run config. Today a Finder double-click boots in own-mode, and only a launcher script that exports NEO_FLEET_PLANE_BASE and NEO_FLEET_PLANE_BEARER attaches it. The fix needs two renderer capabilities: the cockpit must learn whether a plane is configured, and it must ask main to attach one. ADR-0034 §2.3's falsifier sends that change here first: "any leaf needing a renderer capability the preload cannot express through a named, allowlisted intent amends THIS section first".
The Problem
The preload exposes brainHealth, fleetRequest and shellVersion. None can express "is a plane configured" or "attach this plane". fleetRequest is the wrong home: plane configuration is the shell's boot input, not a fleet wire verb, and §2.3.7 already keeps whole-shell concerns off FleetControlBridge.
The Architectural Reality
- ADR 0038 §2.1 and §2.5.1 already decide custody. The client connection profile (endpoint plus the client's encrypted credential) lives client-side, with Electron main as the packaged custodian; the Body gets a session capability and never the credential. Row 2 is the "client connection broker": typed requests, zero credential-read capability.
apps/agentos/fleet/connectionProfiles.mjs names the electron-main custodian shape, and the harness's promptFleetCredential already collects credentials in main custody.- §2.3.7 (
brainHealth, #16051) is the precedent for amending this section with one named affordance.
The Fix
Add §2.3 item 8, plane attach, with two named affordances:
planeStatus() → {packaged, configured, planeBase, attached}: pull-shaped plain data.attachPlane({planeBase}) → {ok, reason, relaunching}: main validates the base, captures the PAT in the existing main-custody prompt, checks it with one authenticated request against the plane, stores it encrypted by safeStorage as the ADR 0038 profile, and relaunches.
Both handlers validate the sender per §2.3.4, and neither reply carries credential bytes. The item records that the env seam feeding the shell's own fleet child is transitional until neomjs/neo-agent-institution#17. The ADR 0038 seam-table row is unchanged, because this adds no new ADR.
Acceptance Criteria
Out of Scope
- The implementation (neomjs/neo-agent-institution#211, which merges after this).
- Credential rotation, and a "forget this plane" affordance.
Related
neomjs/neo-agent-institution#211 · neomjs/neo-agent-institution#17 (the demotion that retires the transitional seam) · #16051 (§2.3.7, the precedent) · ADR 0038
Live latest-open sweep: the latest 20 open neo issues at 2026-09-25T16:11:32Z; no equivalent. Searches for ADR 0034 and for plane-attach preload work found no open equivalent.
A2A in-flight sweep: no claim on ADR-0034 in the last hour.
MC sweep: "ADR 0034 section 2.3 amendment … client connection broker" found no prior decision.
Own-assignment sweep: none of my open neo tickets touches ADR-0034.
Origin Session ID: 0f80515e-7682-4313-8101-b926da48c55c
Context
neomjs/neo-agent-institution#211 lets the packaged Fleet Manager shell attach to a plane from its own first-run config. Today a Finder double-click boots in own-mode, and only a launcher script that exports
NEO_FLEET_PLANE_BASEandNEO_FLEET_PLANE_BEARERattaches it. The fix needs two renderer capabilities: the cockpit must learn whether a plane is configured, and it must ask main to attach one. ADR-0034 §2.3's falsifier sends that change here first: "any leaf needing a renderer capability the preload cannot express through a named, allowlisted intent amends THIS section first".The Problem
The preload exposes
brainHealth,fleetRequestandshellVersion. None can express "is a plane configured" or "attach this plane".fleetRequestis the wrong home: plane configuration is the shell's boot input, not a fleet wire verb, and §2.3.7 already keeps whole-shell concerns offFleetControlBridge.The Architectural Reality
apps/agentos/fleet/connectionProfiles.mjsnames theelectron-maincustodian shape, and the harness'spromptFleetCredentialalready collects credentials in main custody.brainHealth, #16051) is the precedent for amending this section with one named affordance.The Fix
Add §2.3 item 8, plane attach, with two named affordances:
planeStatus()→{packaged, configured, planeBase, attached}: pull-shaped plain data.attachPlane({planeBase})→{ok, reason, relaunching}: main validates the base, captures the PAT in the existing main-custody prompt, checks it with one authenticated request against the plane, stores it encrypted bysafeStorageas the ADR 0038 profile, and relaunches.Both handlers validate the sender per §2.3.4, and neither reply carries credential bytes. The item records that the env seam feeding the shell's own fleet child is transitional until neomjs/neo-agent-institution#17. The ADR 0038 seam-table row is unchanged, because this adds no new ADR.
Acceptance Criteria
Out of Scope
Related
neomjs/neo-agent-institution#211 · neomjs/neo-agent-institution#17 (the demotion that retires the transitional seam) · #16051 (§2.3.7, the precedent) · ADR 0038
Live latest-open sweep: the latest 20 open neo issues at 2026-09-25T16:11:32Z; no equivalent. Searches for ADR 0034 and for plane-attach preload work found no open equivalent. A2A in-flight sweep: no claim on ADR-0034 in the last hour. MC sweep: "ADR 0034 section 2.3 amendment … client connection broker" found no prior decision. Own-assignment sweep: none of my open neo tickets touches ADR-0034.
Origin Session ID: 0f80515e-7682-4313-8101-b926da48c55c