Header-action pop-outs open at the 480×360 fallback size

Context

I found this while answering RA-2 of Euclid's review of #19596, which asks for exact-head receipts for #19583's AC-5. Four Workstation Neural Link cases pass at 5ccdb192d6^ and fail from 5ccdb192d6 (#19559, merged 2026-10-10 17:00Z) on. I ran them locally on macOS, headless, with NEO_AGENTOS_RUNTIME_ROOT set:

Hosted CI never ran these. Its e2e job sets no NEO_AGENTOS_RUNTIME_ROOT, so it deselects every Brain-gated spec; Euclid's review counted 42 of 144 files selected.

The Problem

Every header-action pop-out opens at the fixed 480×360 fallback instead of the footprint of the pane it leaves. #19559's own commit records the operator's contract for the header pop-out: "the popup's OUTER size equals the widget's".

The Architectural Reality

• HeaderActions#handleDockPopOutAction measures the pane's tabs node (measureDockPaneRect(tabContainer)) and passes the result only as proxyRect (src/dashboard/dock/plugin/HeaderActions.mjs:225–234).
• Before #19559, VesselWorkspace#openTearOutVessel sized from proxyRect. Since #19559, it sizes from sourceRect alone, through Placement.resolveVesselSize (pinned ?? sourceRect ?? fallback), and "a null source reaches the helper's fallback" (#19559's commit).
• TearOut forwards data.sourceRect ?? null (src/dashboard/dock/window/TearOut.mjs:840). The drag path supplies that rect from the sort zone's measurement at drag arming. The header path supplies none.
• Design authority:
  • #19559's commit message, quoted above.
  • #19375's witness ("born at the OUTER size of the tabs node it left").
  • #19450's design: a torn-out window keeps the widget's size, clamped to the screen, with a floor of 320×240.

The Fix

handleDockPopOutAction also passes its measurement as sourceRect. The header path then takes the same sizing route as the drag path: the measured footprint, clamped and floored by resolveVesselSize. The header path measures the tabs node, the footprint #19375 asserts; the drag path measures the card body. Each path keeps its own measurement.

Acceptance Criteria

• The four cases above pass again (local, NEO_AGENTOS_RUNTIME_ROOT set).
• A unit test pins that the header action admits its measured rect as sourceRect. Without the fix it fails.
• The drag path's sizing witnesses from #19559 stay green: DockVesselSize, DockTabSortZone, DockTearOut, and WorkstationHumanPopupOverlapNL.

The evidence is in #19598, merged as 3ec6e0b945 with Emmy's approval:

• The four cases and WorkstationHumanPopupOverlapNL pass 9/9 locally at 7076eff422.
• DockWorkspace.spec › "…carries the measured rect" fails without the fix.
• The full unit suite passes: 4903 tests, 2 skipped.

Out of Scope

• Hosted CI's deselection of Brain-gated specs. I'm recording it as a defect-note.
• WorkstationTabDragLabelOverlapNL's red. It is a pre-existing timing flake in its positive control: 2/10 before #19559, 3/10 on dev.

Related

#19559 · #19450 · #19375 · #19583 (its AC-5 is red at baseline because of this) · #19596

Sweeps:

• Live latest-open sweep: the latest 20 open issues at 06:3xZ, plus searches for "pop-out size", "header action pop-out", "480x360", "OUTER size", "vessel size fallback" and "popout opens at fallback", and open PRs. Hits are #16472 and Institution #12, neither equivalent.
• A2A in-flight sweep: the last 15 messages, all states. No claim.
• MC sweep: "header pop-out window opens at fallback 480x360 instead of the pane's size after tear-out sizing change", 5 results. They show prior intent (Vega's #19375 witness; Grace's #19450 design) and no decision to fix the header pop-out's size.
• Own-assignment sweep: #19583 and #19569 are on the same surface but do not cover this.

Origin Session ID: a6673f82-f995-4e40-83a9-3093d4ecd357 Retrieval Hint: "header action pop-out vessel size fallback 480x360 sourceRect proxyRect #19559 regression"