Context
PR #17663 (the wake dialog gate) closes #17629 with its AC-2 real-harness arm declared as an honest L2 residual: the red-first fixture pair proves the gate logic at the adapter seam via injected probe states, but no arm drives a real pending interactive dialog on a live Claude Code seat shape. Round-1 review (RA-2) correctly required that residual to live somewhere verifiable rather than inline on the PR — and the first owner named (#13652) is epic-labeled, so it has no AC slot to carry it. This leaf is that verifiable home.
Live latest-open sweep: checked latest 20 open issues at 2026-08-24T00:1xZ; no equivalent fixture ticket found. A2A in-flight sweep (all read-states, ~60 min window): no competing claim on this scope.
The Problem
The gate's fail-open/defer contract is proven against scripted accessibility responses. What is not yet proven end-to-end: a genuine AskUserQuestion-class dialog rendered by a live Claude Code seat, a wake arriving mid-prompt, and the operator's eventual answer surviving intact with the wake delivered afterward. Until that run exists, the gate's real-world behavior under actual AX-tree shapes (Electron version drift, dialog markup changes) is reasoned rather than measured.
The Architectural Reality
- The injector is ours; the prompt rendering is upstream. The fixture must therefore control a real seat's dialog state without patching the harness.
- The probe keys on
role of focused element of window 1 vs the {AXTextArea, AXTextField} composer set — Electron AX trees expose these roles today, and the coupling is exactly what this fixture exists to detect early.
- The receiver-side park/bound machinery is already covered at L2 and out of scope here; this leaf only feeds it a live dialog state.
The Fix
A repeatable rig (scripted, not manual) that: opens a Claude-shape seat session, raises a structured interactive prompt, sends a signed wake targeting that seat through the receiver, and asserts (a) pre-gate behavior reproduces (envelope consumed as answer) on a gate-disabled control, and (b) post-gate the wake defers, the operator's answer is the one recorded, and delivery completes after the dialog resolves. Rig lands beside the existing wake fixtures; harness-version coupling documented with the adapterConfig.dialogProbe escape hatch as the documented off-switch.
Acceptance Criteria
Out of Scope
- API-class transport vulnerability measurement (opencode-server/kimi-server) — separate follow-up
- Non-Claude seat shapes
- Receiver park/bound semantics (covered at L2 by #17663)
Avoided Traps
- Marker-only detection with no live arm: the exact silent-regression class the round-1 review flagged; this leaf is its antidote.
- Driving a peer's live seat: the rig uses its own disposable seat instance.
Related
Parent: #13652 · Gate PR: #17663 · Closes-out the residual declared there · Sibling invariant: #17231
Origin Session ID: b644277f-7fcf-4079-a363-a7f9099a4566
Retrieval Hint: query_raw_memories("wake dialog gate real-harness fixture AskUserQuestion AX focused role defer")
Context
PR #17663 (the wake dialog gate) closes #17629 with its AC-2 real-harness arm declared as an honest L2 residual: the red-first fixture pair proves the gate logic at the adapter seam via injected probe states, but no arm drives a real pending interactive dialog on a live Claude Code seat shape. Round-1 review (RA-2) correctly required that residual to live somewhere verifiable rather than inline on the PR — and the first owner named (
#13652) is epic-labeled, so it has no AC slot to carry it. This leaf is that verifiable home.Live latest-open sweep: checked latest 20 open issues at 2026-08-24T00:1xZ; no equivalent fixture ticket found. A2A in-flight sweep (all read-states, ~60 min window): no competing claim on this scope.
The Problem
The gate's fail-open/defer contract is proven against scripted accessibility responses. What is not yet proven end-to-end: a genuine
AskUserQuestion-class dialog rendered by a live Claude Code seat, a wake arriving mid-prompt, and the operator's eventual answer surviving intact with the wake delivered afterward. Until that run exists, the gate's real-world behavior under actual AX-tree shapes (Electron version drift, dialog markup changes) is reasoned rather than measured.The Architectural Reality
role of focused element of window 1vs the{AXTextArea, AXTextField}composer set — Electron AX trees expose these roles today, and the coupling is exactly what this fixture exists to detect early.The Fix
A repeatable rig (scripted, not manual) that: opens a Claude-shape seat session, raises a structured interactive prompt, sends a signed wake targeting that seat through the receiver, and asserts (a) pre-gate behavior reproduces (envelope consumed as answer) on a gate-disabled control, and (b) post-gate the wake defers, the operator's answer is the one recorded, and delivery completes after the dialog resolves. Rig lands beside the existing wake fixtures; harness-version coupling documented with the
adapterConfig.dialogProbeescape hatch as the documented off-switch.Acceptance Criteria
Out of Scope
Avoided Traps
Related
Parent: #13652 · Gate PR: #17663 · Closes-out the residual declared there · Sibling invariant: #17231
Origin Session ID: b644277f-7fcf-4079-a363-a7f9099a4566
Retrieval Hint:
query_raw_memories("wake dialog gate real-harness fixture AskUserQuestion AX focused role defer")