Context
Sibling to #17564, which owns the equivalent set for the Workstation witnesses. This one owns the dock-demo journeys.
Surfaced while discharging @neo-gpt-emmy's RA-2 on PR #17562 (#16322, the dockdemo relocation). That review's standard is the reason this ticket exists: "the same test failing at different assertions cannot be called byte-identical or zero-regression evidence." Applying it required measuring the relocation branch against a detached origin/dev worktree rather than against memory — and that measurement showed four journeys already red on dev, at assertions the relocation does not touch.
Without a durable owner, four permanently-red journeys become background noise that every future dock PR has to re-triage from scratch.
The Problem
Eight relocation journeys were run on origin/dev and on the relocation branch. Both trees: 12 passed / 4 failed, the same four specs, and diff over the sorted failure messages is empty.
The four, enumerated by failed invariant rather than by name — each needs its own diagnosis and none of them share a mechanism:
| # |
journey |
failed invariant |
observed |
| 1 |
e2e/agentos/DemoBKeyboardDetachNL.spec.mjs:31 |
the detach announcement must name the popup surface |
expect(received).toContain(expected), expected substring "popout" — the announcement/URL does not carry it. The file's other two tests pass, including the harder popup-origin RETURN at :122, so the detach grammar itself works and only this announcement assertion is red |
| 2 |
e2e/agentos/DemoBPerspectivesNL.spec.mjs:53 |
"the real popup hosts the live workbench pane" |
the reparented pane is not found in the popup — the shared-heap handover assertion, not the perspective switching around it |
| 3 |
e2e/dashboard/DemoATourNL.spec.mjs:26 |
"the tucked window must render real DockRail tab buttons" |
maxRailTabs: **5**, expected 3. The scene tucks three residents; five rail tabs are observed, so this is an over-count, not an absence — the rail renders, it renders too many |
| 4 |
e2e/dashboard/PreviewLanguageDragPairNL.spec.mjs:135 |
visual golden |
toHaveScreenshot — 688 pixels, ratio 0.01. A sub-1% delta on a platform-specific golden; see the instrument caveat below |
The Architectural Reality
Rows 1–3 are behavioural assertions against live cross-window and rail state; they are real questions about the product, not harness artifacts.
Row 4 is a different class and should not be triaged with the other three. The visual suite is a local-harness, platform-specific instrument — #17518 recorded 8/8 goldens failing on an unmodified tree. A 0.01 ratio on a machine that is not the golden's origin host is exactly what that caveat predicts. Deciding whether row 4 is a product defect requires first deciding whether the golden is authoritative on this host at all.
The Fix
Diagnose each row independently. They are grouped here for ownership, not because they share a cause — a single "fix the dock e2e" commit would be the wrong shape.
Suggested order, cheapest signal first: row 3 (a deterministic over-count, fully observable from one run's OBSERVED payload), then row 1 (a string assertion with an obvious candidate surface), then row 2 (genuine cross-window state), and row 4 only after the golden's authority on the running host is settled.
Acceptance Criteria
Out of Scope
- The relocation itself (#16322 / PR #17562). It is measured to add nothing to this set; that measurement is the reason this ticket can exist separately.
- The Workstation witnesses (#17564) — same shape, different specs, already owned.
- Retiring any of these journeys. They assert real product invariants; the red is the finding, not the nuisance.
Avoided Traps
- Fixing them as a batch. Four different mechanisms; a single commit that turns the set green would hide which invariant was actually restored and which assertion was merely weakened.
- Blaming the relocation. Measured on both trees at assertion level; the messages are byte-identical. Attributing them to the newest PR is the cheapest wrong answer.
- Treating row 4 like rows 1–3. A platform-specific golden and a live cross-window invariant fail for unrelated reasons; triaging them together produces a wrong verdict on at least one.
Related
#16322 / PR #17562 (the measurement that surfaced this set) · #17564 (the Workstation sibling) · #17518 (the visual-suite instrument caveat governing row 4)
Retrieval Hint: dock demo e2e pre-existing red DemoBKeyboardDetach DemoBPerspectives DemoATour PreviewLanguageDragPair assertion-level baseline
Origin Session ID: cb3eb9c7-875a-4eac-a716-02878fa535c5
Context
Sibling to #17564, which owns the equivalent set for the Workstation witnesses. This one owns the dock-demo journeys.
Surfaced while discharging @neo-gpt-emmy's RA-2 on PR #17562 (#16322, the dockdemo relocation). That review's standard is the reason this ticket exists: "the same test failing at different assertions cannot be called byte-identical or zero-regression evidence." Applying it required measuring the relocation branch against a detached
origin/devworktree rather than against memory — and that measurement showed four journeys already red ondev, at assertions the relocation does not touch.Without a durable owner, four permanently-red journeys become background noise that every future dock PR has to re-triage from scratch.
The Problem
Eight relocation journeys were run on
origin/devand on the relocation branch. Both trees: 12 passed / 4 failed, the same four specs, anddiffover the sorted failure messages is empty.The four, enumerated by failed invariant rather than by name — each needs its own diagnosis and none of them share a mechanism:
e2e/agentos/DemoBKeyboardDetachNL.spec.mjs:31expect(received).toContain(expected), expected substring"popout"— the announcement/URL does not carry it. The file's other two tests pass, including the harder popup-origin RETURN at:122, so the detach grammar itself works and only this announcement assertion is rede2e/agentos/DemoBPerspectivesNL.spec.mjs:53e2e/dashboard/DemoATourNL.spec.mjs:26maxRailTabs: **5**, expected3. The scene tucks three residents; five rail tabs are observed, so this is an over-count, not an absence — the rail renders, it renders too manye2e/dashboard/PreviewLanguageDragPairNL.spec.mjs:135toHaveScreenshot— 688 pixels, ratio 0.01. A sub-1% delta on a platform-specific golden; see the instrument caveat belowThe Architectural Reality
Rows 1–3 are behavioural assertions against live cross-window and rail state; they are real questions about the product, not harness artifacts.
Row 4 is a different class and should not be triaged with the other three. The visual suite is a local-harness, platform-specific instrument —
#17518recorded 8/8 goldens failing on an unmodified tree. A 0.01 ratio on a machine that is not the golden's origin host is exactly what that caveat predicts. Deciding whether row 4 is a product defect requires first deciding whether the golden is authoritative on this host at all.The Fix
Diagnose each row independently. They are grouped here for ownership, not because they share a cause — a single "fix the dock e2e" commit would be the wrong shape.
Suggested order, cheapest signal first: row 3 (a deterministic over-count, fully observable from one run's
OBSERVEDpayload), then row 1 (a string assertion with an obvious candidate surface), then row 2 (genuine cross-window state), and row 4 only after the golden's authority on the running host is settled.Acceptance Criteria
test-e2eover the eight dock journeys is green ondev, or the residual set is smaller and each survivor names its own owner.Out of Scope
Avoided Traps
Related
#16322 / PR #17562 (the measurement that surfaced this set) · #17564 (the Workstation sibling) · #17518 (the visual-suite instrument caveat governing row 4)
Retrieval Hint:
dock demo e2e pre-existing red DemoBKeyboardDetach DemoBPerspectives DemoATour PreviewLanguageDragPair assertion-level baselineOrigin Session ID: cb3eb9c7-875a-4eac-a716-02878fa535c5