Four dock-demo journeys were red on dev at assertions no PR had touched. #17576 grouped them for ownership while insisting they share no mechanism. They don't — each row got its own diagnosis, and the four verdicts are genuinely different: two fixed, one escalated to a product ticket, one disqualified as an instrument.

Resolves #17576 Refs #17578

Deltas

Two spec files. No product source is touched by this PR — the one product defect found is escalated, not patched here.

Row 1 — DemoBKeyboardDetachNL.spec.mjs: fixed, a synchronization bug in the spec.

expect(popup.url()).toContain('popout') reported Received string: "". Not a wrong URL — an empty one. windowOpen creates the vessel before the tear-out navigates it, so waitForLoadState('domcontentloaded') resolves on the initial blank document. Waiting for the URL instead shows the vessel reaches it in full:

…/index.html?popout=workbench&hostId=neo-container-1
  &vesselFlow=tear-out&vesselGrant=88c30acd-…&vesselGeneration=1&vesselAdmission=1

So the product was never at fault. waitForURL(/popout/) asserts the same invariant with the right synchronization — a vessel that never reaches its popout URL still fails, loudly, with the final URL in the message. Event-based, so it stays inside the fixed-sleep lint's contract.

Row 3 — DemoATourNL.spec.mjs: fixed, the wrong instrument.

maxRailTabs is a high-water mark over an rAF loop, asserted .toBe(3) against a steady-state resident count. Observed 5 — and 5 is genuinely in the DOM. Keyed on component id rather than the edge class an earlier census collapsed:

neo-button-4 "Preview"  14x50  rail neo-dashboard-dock-rail-2
neo-button-5 "Terminal" 14x53  rail neo-dashboard-dock-rail-2
neo-button-7 "Preview"  14x50  rail neo-dashboard-dock-rail-3
neo-button-8 "Terminal" 14x53  rail neo-dashboard-dock-rail-3
neo-button-9 "Logs"     14x34  rail neo-dashboard-dock-rail-3

Two rail instances, both connected, both painted — the outgoing 2-item rail beside its 3-item replacement. A rail whose item set changes is re-projected rather than grown, so a handover frame is structural.

A peak cannot tell a handover from a leak. Duration can: over 703 frames, {0:514, 1:4, 2:1, 3:181, 5:3}. The over-count holds 3 frames (~50 ms); the tucked plateau holds 181, with a 30-frame tail of exactly 3 before rollback. Nothing leaks — the outgoing rail is torn down.

The census becomes per-cardinality frame counts and the invariant splits in two: the tucked trio must hold (a plateau, not a blip), and any over-count must stay an order of magnitude rarer than that plateau. The second assertion is a leak guard the peak-only form never had — a rail that is never destroyed sustains its over-count for as long as the tucked state lasts.

AC Evidence

Row 2: reclassified, not fixed — the assertion is right and the product is broken

The pane never reaches the popup because the transfer never happens. Neo.ai.client.TourRunner aborts at scene s3 step 2, and logs why:

{"applied":false,
 "errors":["remote target did not expose a settled semantic preview"],
 "sceneId":"s3","stepIndex":2,"type":"cross-window"}

running: false, log frozen at 20 of 28 beats — sampled for 20 s and again for 90 s; permanent, not pacing. Sampling every live window plus its Neo.worker.Manager.windowId:

The target (09220ba7, vesselFlow=workspace-target, equal to crossWindowTargetWindowId) reports zero hits at every sample. Recovering the debug payload the runner discards isolates the seam: the target zone answers its own acceptsRemoteDrag(300, 267) with true inside its own 600×520 rect, both windows share one coordinator sort group, and Neo.manager.DragCoordinator still reports activeTargetZone: null, candidateCount: 0. Geometry, registration and source readiness are all correct; the coordinator simply never engages a zone that accepts the pointer.

Deliberately not patched here — it is engine drag-coordinator work with its own blast radius, and #17576 explicitly permits reclassification. Re-pointing the assertion at the tear-out vessel would have ratified the defect.

Row 4: verdict — the goldens are not authoritative on this host

Three independent facts, all measured, not inherited:

1. No CI gate. No workflow references playwright.config.e2e or test-e2e. Every golden is local-only; no shared host ever validates them.
2. Foreign provenance. All 26 goldens are keyed chromium-darwin and were authored on another maintainer's machine (bfbdfdadc0, 2026-07-16). The platform key matches this host; the machine does not.
3. 4/4 drift on a pristine tree. This branch touches neither the visual spec, its goldens, nor any dashboard source.

The first run showed 1 failed / 1 passed, which reads like an isolated regression — it isn't. All four goldens live in one test and Playwright fail-fast stops at the first; the passing test takes no screenshot. Exactly one golden was compared and three were never evaluated. Forcing all four to run:

drag-pair-default-dark   688 px  (ratio 0.01)
drag-pair-signal-dark    877 px  (ratio 0.01)
drag-pair-signal-light   779 px  (ratio 0.01)
drag-pair-default-light  592 px  (ratio 0.01)

All four, both preview languages × both themes, at a uniform sub-1 % ratio.

The uniformity alone does not prove host causality — a global CSS or product change could move four scenes similarly, and that reading has to be excluded rather than assumed. What excludes it here is the conjunction of the three facts above: this branch changes no rendered source and no golden, every comparison fails against goldens cut on another machine, and the suite has no shared-host gate at all. That conjunction disqualifies this host as an adjudicator; it does not invalidate the goldens globally, and nothing here should be read as a claim about their correctness on the machine that owns them.

So: no product diagnosis may be attributed to row 4 from this host, which is what the AC asked for. Re-baselining is a decision for whichever host owns the goldens, not a side effect of this PR.

Test Evidence

Evidence: both fixed specs, run together on this branch —

NEO_E2E_PORT=8120 npx playwright test agentos/DemoBKeyboardDetachNL dashboard/DemoATourNL \
  -c test/playwright/playwright.config.e2e.mjs --workers=1
→ 4 passed (11.6s)

Row 1 is 3/3 including the popup-origin RETURN leg that already passed; row 3 is 1/1 with railFrames {0:513, 1:4, 2:1, 3:180, 5:3} — plateau 180, over-count 3, bound 18.

AC-4 control — both new assertions mutated, both redden:

The second arm is precisely the shape of a permanent rail leak — a sustained over-count — and it fails closed. Green here is not "the assertions stopped running".

Post-Merge Validation

• Rows 1 and 3 stay green on dev; the dock-journey residual is rows 2 and 4 only.
• Row 2 is tracked on #17578 and reddens this same journey until the coordinator engages the accepting zone. It needs no re-triage from scratch on the next dock PR — that re-triage cost is what #17576 existed to end.
• Row 4 needs no post-merge action here. Re-baselining belongs to the golden's owning host, and until then the visual suite stays a local-only instrument.

Authored by @neo-opus-grace (Claude Opus 5, Claude Code)

Origin Session ID: 1b0d28eb-3461-40b6-bb35-88d6bf09ec94