Detail vessel dies silently when its boot exceeds the connect window

Context

Found twice live today (2026-07-21, two separate Chrome profiles on this host) during the #15631 capture sessions: FleetCockpit.popOutAgentDetail() reports success (detached: true, the vessel window really opens) — and seconds later the detail silently re-docks with the vessel gone. The cause is detailVesselConnectWindowMs: on a loaded machine the widget childapp's heap-join exceeds the bounded connect window, the admission machine takes its failed-timeout edge, and reattachAgentDetail() rolls back automatically.

Live latest-open sweep: checked the live tracker (created-desc, 12 latest) at 2026-07-21T18:50Z; no equivalent. KB ticket sweep: no equivalent (the term is novel). A2A in-flight: none.

The Problem

The bounded connect window is a correct admission guard (a vessel that never joins the heap MUST roll back — the Boolean grammar demands it). But its calibration assumes the widget page boots fast. On real seats — a loaded host, a cold profile partition, a busy SharedWorker — the vessel's boot+connect legitimately takes longer than the window. The result is a silent false failure: popOutAgentDetail returns detached: true (the window opened), the timeout fires, and the whole cycle unwinds with no surfaced error. A scripted drive (or a user) sees a pop-out that "flaps" open and dies.

Live reproduction shape (twice, independently): detailVesselState cycles opening → (connect timeout) → reattaching → docked; the vessel window closes within ~2–5s of birth; widening detailVesselConnectWindowMs to 20000 makes the same pop-out survive and complete → connected → windowed (verified live on the same seat, minutes apart).

The Architectural Reality

• apps/agentos/view/fleet/FleetCockpit.mjs popOutAgentDetail() — the detachedDetail.connectTimer admission guard (detailVesselConnectWindowMs, failed-timeout edge → reattachAgentDetail()).
• The widget childapp (apps/agentos/childapps/widget/) boots a full Neo app + SharedWorker join per vessel — its cold-start is the variable the default window can't absorb.
• Sibling calibration precedent: the Memory Core healthcheck's embed-write canary was raised 5s→30s for cold embedders in #14182 — same "cold-provider beats the default timeout" class, resolved by widening for the cold case.

The Fix

Make the admission window honest about cold boots instead of silently flapping. Options (implementer's call, simplest first):

1. Widen the default with an explicit cold-boot rationale (the #14182 class fix), or
2. Make the window adaptive: extend once when the vessel page signals boot-progress (a heartbeat from the childapp), keeping the bound for a genuinely dead connect, and/or
3. Surface the rollback observably — a failed-timeout edge should be distinguishable from a user-initiated reattach in the cockpit's state/log surface, so a silent flap is never mistaken for a successful pop-out.

Acceptance Criteria

• A pop-out on a loaded/cold seat survives its legitimate boot time (no silent connect-timeout rollback within a documented, justified bound).
• A genuinely dead connect still rolls back within the bound (the admission guard's purpose is preserved).
• The failed-timeout edge is observable (state or log), not silent.
• Unit coverage for the timeout-vs-legit-boot distinction (stubbed connect timing).

Out of Scope

• The widget childapp's own boot-time optimization (separate performance question).
• The vessel-death reintegration gap (#15635 — sibling, not this).

Related

#15635 (vessel-death stranding — the other vessel-lifecycle edge) · #14182 (canary widening precedent) · #15631 (the capture lane that exposed it, twice)

Origin Session ID: 557fd3c7-7307-499b-9c35-d07fe1c2efcd

Retrieval Hint: detailVesselConnectWindowMs connect timeout silent flap cold boot vessel admission FleetCockpit popOutAgentDetail failed-timeout