Context
Measured 2026-09-25 on the film-stage display (external, 3360×1890, pin 2632,100,1320,920) in the take's capture mode (no viewport emulation) at the head of PR for #19220 (vessels born 320×240 outer / 320×173 inner): the film's second-window beat still fails with target vessel did not reach one parked semantic + rendered claim. The driver's snapshot at the failed step: claimCount 1, winnerStableId workstation-vessel:metrics, converted false, engaged false, parkReceipt null — the target claims the pointer, the conversion never proposes. Receipts: test-results/dock-wow-demo/glitch-probe/2026-09-25/capture-mode/fix-head/; the same beat is green under the tour's emulated 1280×800 viewport, ten runs today.
Geometry at the last frame: target outer top 1148, dragged source outer top 1286, both 320×240 outer with a 67 px title bar. The pointer (aimed at the target's inner centre) sits 15 px below the source's outer top, inside its title bar; the source's content starts 52 px below the pointer.
The Problem
Observation: the dragged vessel follows the pointer with its outer origin at pointer minus the grab offset (15 px, the grab inside the tab), while its content starts one title bar lower. Under emulation a popup's metrics carry no title bar (outer equals inner), so the same follow lands the pointer inside the content; on a real window it lands in the chrome. Inference: VesselConversion measures inner rects — overlap divided by the smaller extent per axis, min(rx, ry), entry at 0.55. With both inner rects 173 tall and offset 138 px, the y overlap is 35 px, 0.20; the outer rects would overlap 0.43. So a real window converts only when the user drags much deeper into the target than the film, or a person, expects — the vessel the user holds is one title bar lower than the pane they grabbed.
The Architectural Reality
src/main/addon/DragDrop.mjs (~:548 and :598): the window follows screenX − offsetX, screenY − offsetY through moveTo, which speaks the outer frame; the offset is measured from the dragged element's rect in the source window (:666).apps/workstation/view/VesselWorkspace.mjs#openTearOutVessel (~:1131): the birth top is the proxy's screen y (proxy y + the main window's chrome + screenTop), used as the popup's outer top; the popup's own chrome is unknown before birth.src/dashboard/dock/window/VesselConversion.mjs#sample: inner rects, axisRatio over the smaller extent, composeRatios = min(rx, ry).apps/workstation/tour/NativeGestureDriver.mjs#executeCrossWindowDockStep: the pointer goes to the target's inner centre and waits for remoteSnapshot.ready.Main#windowOpen after #19220: the popup's total size is the request; the content is the request minus the platform's title bar.
The Fix
Restated 2026-09-25 ~20:50Z after the operator's manual test: dragging a native popup over another popup or the main app works; tearing a tab out and dragging its born popup over another popup does not — no drop-zone highlighting, no re-integration. That is the human witness for what the capture-mode receipts showed all day, and it points at the metric's plane, not at the placement.
Design authority: ADR 0029 §2.8.6 — the vessel's placement stays: "resumes physical pointer-follow at the live logical drag origin", the frame rides the pointer's corner so the drop targets around the pointer stay uncovered. The park it proposes is the target-cover park, whose "admission reads the source's live outer extent and the target's live inner extent; creation-time dimensions and equal-size assumptions are not authority". The conversion metric itself (VesselConversion: overlap over the smaller extent per axis, min(rx, ry), entry 0.55 / revert 0.35) is not changed.
The mechanism: VesselWorkspace#resolveVesselConversionSourceRect sampled the dragged vessel's inner rect while the pointer rides its frame corner. On a real window a title bar's height (67 px on macOS Chrome) sits between the pointer and the sampled rect, so for two equal 320×240 windows the y-overlap reaches 0.55 only with the pointer in the target's top ~26 px of content, and nothing highlights before that. Under viewport emulation a popup's outer and inner rects coincide, so the tour never showed it (receipts at the driver's inner-centre aim: 0.20 in capture mode, 0.56 emulated).
The change: the source rect for conversion sampling is the frame — outer, inner when a child publishes none — the plane the park admission already reads against the target's inner extent. The reachable band becomes the target's upper half of content by hand, and the film driver's unchanged centre aim converts. One method and its JSDoc; no threshold, no placement, no driver change.
Acceptance Criteria
Out of Scope
The vessel's placement (the frame rides the pointer, by design) and the conversion thresholds; the born size (#19220, merged); the z-order of a parked vessel (#19186); the film's screenplay, pacing and voice.
Related
#15252 (the film epic, parent), #19220 (the size, found on the same beat), #19186, the docking design record's multi-window amendment.
Live latest-open sweep: checked the latest 20 open issues at 2026-09-25T14:14:35Z; no equivalent. A2A in-flight sweep (the 12 most recent messages, all read states) at 14:14Z: no claim on it. Memory Core sweep: my own receipts on #19220 today; no earlier record. Own-assignment sweep: #19220, #19186, #19101, #15252 — none covers it.
Retrieval Hint: query_raw_memories("dragged vessel content one title bar below the pointer conversion never proposes capture mode")
Origin Session ID: 4c0a5550-17ba-4752-9852-846afa537c86
Context
Measured 2026-09-25 on the film-stage display (external, 3360×1890, pin 2632,100,1320,920) in the take's capture mode (no viewport emulation) at the head of PR for #19220 (vessels born 320×240 outer / 320×173 inner): the film's second-window beat still fails with
target vessel did not reach one parked semantic + rendered claim. The driver's snapshot at the failed step:claimCount 1, winnerStableId workstation-vessel:metrics, converted false, engaged false, parkReceipt null— the target claims the pointer, the conversion never proposes. Receipts:test-results/dock-wow-demo/glitch-probe/2026-09-25/capture-mode/fix-head/; the same beat is green under the tour's emulated 1280×800 viewport, ten runs today.Geometry at the last frame: target outer top 1148, dragged source outer top 1286, both 320×240 outer with a 67 px title bar. The pointer (aimed at the target's inner centre) sits 15 px below the source's outer top, inside its title bar; the source's content starts 52 px below the pointer.
The Problem
Observation: the dragged vessel follows the pointer with its outer origin at pointer minus the grab offset (15 px, the grab inside the tab), while its content starts one title bar lower. Under emulation a popup's metrics carry no title bar (outer equals inner), so the same follow lands the pointer inside the content; on a real window it lands in the chrome. Inference:
VesselConversionmeasures inner rects — overlap divided by the smaller extent per axis,min(rx, ry), entry at 0.55. With both inner rects 173 tall and offset 138 px, the y overlap is 35 px, 0.20; the outer rects would overlap 0.43. So a real window converts only when the user drags much deeper into the target than the film, or a person, expects — the vessel the user holds is one title bar lower than the pane they grabbed.The Architectural Reality
src/main/addon/DragDrop.mjs(~:548 and:598): the window follows:666).screenX − offsetX,screenY − offsetYthroughmoveTo, which speaks the outer frame; the offset is measured from the dragged element's rect in the source window (apps/workstation/view/VesselWorkspace.mjs#openTearOutVessel(~:1131): the birthtopis the proxy's screen y (proxy y + the main window's chrome +screenTop), used as the popup's outer top; the popup's own chrome is unknown before birth.src/dashboard/dock/window/VesselConversion.mjs#sample: inner rects,axisRatioover the smaller extent,composeRatios = min(rx, ry).apps/workstation/tour/NativeGestureDriver.mjs#executeCrossWindowDockStep: the pointer goes to the target's inner centre and waits forremoteSnapshot.ready.Main#windowOpenafter #19220: the popup's total size is the request; the content is the request minus the platform's title bar.The Fix
Restated 2026-09-25 ~20:50Z after the operator's manual test: dragging a native popup over another popup or the main app works; tearing a tab out and dragging its born popup over another popup does not — no drop-zone highlighting, no re-integration. That is the human witness for what the capture-mode receipts showed all day, and it points at the metric's plane, not at the placement.
Design authority: ADR 0029 §2.8.6 — the vessel's placement stays: "resumes physical pointer-follow at the live logical drag origin", the frame rides the pointer's corner so the drop targets around the pointer stay uncovered. The park it proposes is the target-cover park, whose "admission reads the source's live outer extent and the target's live inner extent; creation-time dimensions and equal-size assumptions are not authority". The conversion metric itself (
VesselConversion: overlap over the smaller extent per axis,min(rx, ry), entry 0.55 / revert 0.35) is not changed.The mechanism:
VesselWorkspace#resolveVesselConversionSourceRectsampled the dragged vessel's inner rect while the pointer rides its frame corner. On a real window a title bar's height (67 px on macOS Chrome) sits between the pointer and the sampled rect, so for two equal 320×240 windows the y-overlap reaches 0.55 only with the pointer in the target's top ~26 px of content, and nothing highlights before that. Under viewport emulation a popup's outer and inner rects coincide, so the tour never showed it (receipts at the driver's inner-centre aim: 0.20 in capture mode, 0.56 emulated).The change: the source rect for conversion sampling is the frame — outer, inner when a child publishes none — the plane the park admission already reads against the target's inner extent. The reachable band becomes the target's upper half of content by hand, and the film driver's unchanged centre aim converts. One method and its JSDoc; no threshold, no placement, no driver change.
Acceptance Criteria
dev, green with the fix.converted true, a park receipt withparked true, the A+B adoption applied, the film completing.Out of Scope
The vessel's placement (the frame rides the pointer, by design) and the conversion thresholds; the born size (
#19220, merged); the z-order of a parked vessel (#19186); the film's screenplay, pacing and voice.Related
#15252 (the film epic, parent), #19220 (the size, found on the same beat), #19186, the docking design record's multi-window amendment.
Live latest-open sweep: checked the latest 20 open issues at 2026-09-25T14:14:35Z; no equivalent. A2A in-flight sweep (the 12 most recent messages, all read states) at 14:14Z: no claim on it. Memory Core sweep: my own receipts on #19220 today; no earlier record. Own-assignment sweep: #19220, #19186, #19101, #15252 — none covers it.
Retrieval Hint:
query_raw_memories("dragged vessel content one title bar below the pointer conversion never proposes capture mode")Origin Session ID: 4c0a5550-17ba-4752-9852-846afa537c86