# Reproduction and capture notes

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

This is a manual real-app comparison, not a test result. Each commit ran its own server and web build with an independent fresh database and T3CODE_DEV_SEED=0. Chromium viewport: 1280x800, DPR 2, light theme. No database rows or provider events were fabricated.

The generic replay provider cannot reproduce native active-steer rejection: its capabilities use interrupt/restart. Instead, relay.cjs transparently forwards a real provider's app-server protocol and controls transport timing. It holds the first turn/completed notification until a new turn/steer arrives, flushes completion, then forwards that unchanged steer after release-steer is created. The real provider rejects it with “no active turn to steer”. The server's normal recovery creates the queued run. The driver immediately stops the thread to hold that queue for inspection. The original first prompt is never requeued.

Place driver.mjs and executable relay.cjs together outside the checkout. Supply ROOT, an isolated HOME_DIR, the running app ORIGIN, a new RUN_DIR, and an available EVIDENCE_MODEL through the environment. The public relay copy replaces the private executable path with a PATH lookup; otherwise it preserves the captured relay behavior.

    EVIDENCE_MODEL=<available-model> node driver.mjs "$ROOT" "$HOME_DIR" "$ORIGIN" "$RUN_DIR" stage

Use a distinct RUN_DIR basename for every fixture in one server. stage creates a synthetic git project and temporary Evidence provider through the real server, starts the first turn, sends the distinct steer, and captures thread-read, full projection, bounded HTTP snapshot and shell response. Private raw responses contain operational metadata and must not be published. runtime-evidence.json is an allowlisted extraction of the actual responses.

## Startup failure

1. On each commit, stage the same fixture using RUN_DIR basename run-failure3.
2. In Settings > Providers, select the newly created Evidence provider, Delete instance, Confirm.
3. Open the staged thread. Its first delivered prompt and FIRST_TURN_COMPLETE reply remain intact; the new instruction appears in the queue.
4. Record clicking Send now, waiting for Queued provider could not start, reloading the same thread, and waiting for the bounded snapshot to finish syncing.
5. Dismiss the floating error banner and capture the timeline. On the base the failed run's retained user item remains pending and its prompt is hidden. On the head it becomes failed and its prompt appears exactly once immediately above the failure.
6. Capture runtime state with driver mode failure.

The failure videos include the live transition and reload. They are cropped to the same 656x550 transcript region at CSS x304,y52 to exclude environment details and the composer. Their differing idle durations reflect browser tooling time. The still pairs were taken more than 500 ms apart and their exported regions have zero pixel differences. The final images are the second member of each pair.

## Successful start

On each side, independently stage a fresh run-success2 fixture, retain its provider configuration, open the thread and click Send now. The recordings show the new prompt leaving the queue and appearing once during the run and after completion. Capture final state with driver mode success. Both builds show the prompt once after successful delivery; the head also restores it correctly from a snapshot which had omitted the pending retained item. The real provider's final wording differs between runs; that wording is not the assertion.

## Inherited history and counts

On each side, independently stage run-fork2. Use mode later to submit a distinct later turn through the same real message.dispatch command used by agent/MCP callers (creationSource mcp); this leaves the held queue in place. Wait for LATER_TURN_COMPLETE, then use mode fork to fork at latest_stable. Mode source-final captures the stable source afterward.

The source contains two completed runs with a never-started held queued run between them. SQLite read-only inspection confirms its retained input is pending, queued_turn, with null providerTurnId, startedAt and completedAt. The base's inherited thread-read includes that undelivered instruction, and shell visibleItemCount is 10. The head preserves both delivered exchanges, excludes the held instruction, and reports 9. The web renderer already hides pending bubbles on both sides, so this difference is documented by the real server capture rather than a misleading screenshot.

## Migration

On each fresh database, read sqlite_master and run EXPLAIN QUERY PLAN for the queued-input predicate. The base lacks the partial index. The head creates orchestration_v2_projection_turn_items_queued_input_idx and SQLite selects it. This demonstrates installation and query selection, not a performance benchmark.