# Question wake proof

Real web client, 1280 × 800, light theme; separate base and head servers and fresh synthetic databases. The parent uses an ACP replay driver without active steering; the child uses scripted provider protocol frames for an asynchronous question. Delegation, question handling, queueing, completion, and task_status all run through the actual server. No application code is patched.

Put the three .cjs files in one directory and set QUESTION_PROOF_DIR to its absolute path. Put finished-child-question.e2e.ts and valid-child-question.e2e.ts under scripts/scenarios in a checkout containing the scenario runner. Install dependencies with vp i.

Run the nested scenario once per application checkout, with T3CODE_DEV_SEED=0 and T3_SCENARIO_APP_DIR pointing at that checkout:

    vp run scenarios scenarios/finished-child-question.e2e.ts --target web --output .e2e/question-proof

The expectation must fail on the base because the supervisor displays the obsolete answer, and pass on the fix because it displays the final outcome. The second scenario is the pending-question control:

    vp run scenarios scenarios/valid-child-question.e2e.ts --target web --output .e2e/question-control

The published drivers differ from those executed only in portable scratch paths and synthetic fixture path metadata. The recordings are continuous excerpts of the same scripted interaction; stills show the parent outcome and the supervisor's actual task_status summary. No copied user data or real model calls were used.

AI-assisted; verified with the tests and tools listed above.