Fleet server rides the standard boot — the cockpit is live-by-default (W2 boot seam, #13015 census)

Context

The W2 live-wiring census (on the #13015 epic, 2026-07-16) found the seed→live wiring SHIPPED end to end — bridge install unconditional at app boot, fail-closed routing matrices spec-pinned, control round-trip product-wired — with exactly ONE seam missing: devFleetServer.mjs starts only via the manual npm run ai:fleet-server. Every ordinary boot therefore lands on honestly-labelled JSON seeds with dead controls: the lived "FM is not functional" experience is one missing process, not missing wiring.

The Problem

The SSOT critical path's clause 03 ("live wiring: the cockpit reads the fleet-services spine live") and clause 04 ("spawn one agent from the UI") are BOTH gated on a server no boot starts. The operator's §04 PoC falsifier — start an agent from the UI instead of a terminal — currently requires knowing to run a second terminal command first, which is the exact failure mode the release gate's "without hand-editing config" clause names.

The Architectural Reality

• apps/agentos/app.mjs already calls installFleetBridge() unconditionally (fetch transport → http://127.0.0.1:8083/fleet); the browser side needs zero changes.
• ai/services/fleet/devFleetServer.mjs is the Option-B dev-server transport host; the Electron shell (Option A) installs an in-process equivalent — this leaf targets the DEV boot path only.
• Candidate shapes (the implementing leaf decides with evidence): (a) the standard dev-server boot (npm run server-start / the harness launch path) supervises the fleet server as a sibling process; (b) a compound npm script; (c) the orchestrator/daemon family adopts it as a supervised child. Shape (a) or (c) must handle the port-in-use case honestly (a second checkout must not fight over :8083 — the #15221/#15225 per-process port discipline applies).
• Fail-closed stays intact either way: if the server dies mid-session, the existing degraded/stale routing already covers it.

Acceptance Criteria

• A standard boot path (documented as THE way to run the cockpit) brings up the fleet server without a separate manual command; the cockpit reads live data on first paint of a fresh boot.
• Port collision handling: a second checkout/boot does not fight over the endpoint (per-process derivation or honest refusal with a named reason — never a silent seed fallback that looks like the cold state).
• The operable-cold path stays reachable and honest: booting WITHOUT the server (explicitly, or on server death) keeps the fail-closed seed/stale behavior.
• learn/ run-the-cockpit documentation names the one boot command.
• Evidence: a boot-integration witness (spawn the standard boot, assert the cockpit reaches live adapter state without manual server start).

Out of Scope

The operable-cold BANNER (the cockpit stating "fleet server offline" — the census's leaf 2, filed separately) · the Electron in-process bridge (Option A, its own arc) · wake/throttle feed consumption (#15273 + the #15280 arc).

Related

Epic #13015 (parent) · the W2 census comment (2026-07-16) · #14230 (the download-and-run cornerstone this unlocks FM-side) · #15221/#15225 (port discipline precedent) · D#15249 (the wave's design record).

Sweeps: latest-open checked 2026-07-16T16:52Z (latest #15278) — no equivalent; the census IS the prior-art pass. A2A herd-window clean.

Origin Session ID: 5bbd6fb6-07d8-4f7e-b3ba-cccb66eddcf3 Retrieval Hint: "fleet server standard boot live-by-default cockpit W2 seam"