Evidence procedure

Both commits ran their own unmodified real server and web client from separate checkouts. Each server created a fresh database with T3CODE_DEV_SEED=0 and an explicit separate home. No database was copied. Before recording, the default empty project was removed. Each main recording starts with exactly the synthetic Fork recovery project and one Stopped source thread. Additional controls were created afterward. The stills revisit those same recorded conversations, with search showing their two threads.

Surface for every capture: Chromium, web client, 1440 x 1000 CSS pixels, light theme, real OpenCode 2.2.7 connected through the supplied HTTP/SSE proxy. Main, source-continuation, and rollback recordings used the shared preview browser. Running and concurrent-start controls used agent-browser at the same CSS viewport. All uploaded video is 1440 x 1000. Runtime metadata regions were hidden with the same CSS on both sides. No conversation content or errors were altered. Videos have no audio. The running and concurrent-start videos append their immediately captured stable final screenshot for three seconds, because screencasting omits idle frames.

Start OpenCode's real server on loopback port 14097 and event-proxy.mjs on 14098. Configure the enabled T3 opencode provider instance to use OpenCode 2's binary and proxy URL, with its server password. Keep credentials private. Start each checkout with T3CODE_DEV_SEED=0 vp run dev --home-dir "$T3_HOME". seed.sh records the same CLI seeding operations with paths and model choice provided through environment variables; repeat once per fresh server. It leaves the initial completed response Ready to fork.

Main comparison, same on both commits:
1. In Stopped source, send: Run the shell command sleep 120, then reply Done. Do not do anything else.
2. Wait for Running sleep, press Stop generation, and wait for Stopped by user.
3. The proxy permanently drops session.execution.interrupted on every connection. Do not replay it.
4. Fork from the earlier Ready to fork. assistant response.
5. In the fork send: Reply with exactly: Fork is working.
6. Base shows Provider turn failed to start and Cannot fork OpenCode session ... while it is still working. Head replies Fork is working.
7. Rename the generated fork to Stopped source fork on both sides so the final names match. Generated names before this action differ because they come from real inference.
8. Without releasing any dropped interruption event, return to Stopped source and send: Reply with exactly: Source is working.
9. Base displays Provider error / Provider turn failed. Its server reports the session already has an active turn. Head replies Source is working. No failed source remains on head.

Rollback control, identical separate synthetic source seeded with Rollback ready.:
1. Send the same sleep prompt, Stop, and permanently drop the interruption event.
2. Click Edit from here on that stopped prompt and Revert and keep changes.
3. Base's first attempt reports that the provider could not roll back; the server says Cannot roll back ... while it is still working. Head removes the stopped turn and restores its prompt to the composer.
4. On head, replace the restored prompt with Reply with exactly: Rollback is working. and send; the reply succeeds.
This comparison concerns the first immediate rollback attempt. A separate base retry much later succeeded; no persistent inability to roll back is claimed.

Native running-source control on both commits:
1. Seed Running source / Control ready., then set holdInterrupt=1 through the proxy control endpoint.
2. Send the sleep prompt, press Stop and wait for the local stop timeout. The actual interrupt request has not reached OpenCode, so the source genuinely remains running.
3. Fork the earlier response and send Reply with exactly: Control fork.
4. Both versions display the native Cannot fork ... while it is still working error. Neither uses context handoff.
5. Query the real OpenCode active endpoint to confirm the source is running. Release the held request and interrupt directly upstream for cleanup, since the original client request may already have timed out.

Concurrent-start control on head:
1. Seed Concurrent source / Race ready., send the sleep prompt, Stop, and drop the interruption event.
2. Fork the earlier response. Set holdActive=1 and submit Reply with exactly: Concurrent fork.
3. The proxy receives the real active response in which this source is absent, then holds its delivery to T3.
4. Start a real new execution directly through OpenCode's prompt endpoint. Its execution.started event reaches T3 before the held idle response is released.
5. Release the idle response. Head refuses the fork. The event ordering exercises the starts-counter safeguard; subsequent retry queries also see the real running source. Interrupt the external execution for cleanup.
The concurrent-start control was captured only on head, because base refuses the stopped source before querying active sessions.

browser-driver.py is the executed automation for running-source and concurrent-start controls and stable screenshots. It expects EVIDENCE_BROWSER (agent-browser executable), EVIDENCE_SESSION (browser session), EVIDENCE_OUTPUT (new run directory), and for race mode the seed JSON, read-only database, origin, environment ID and provider password through the EVIDENCE_* variables shown in its code. Initial main and rollback interactions were driven through shared preview locators using the steps above. event-proxy.mjs is the actual proxy with only its private log destination made configurable. Its log is private: raw upstream responses may contain runtime metadata. runtime-observations.txt includes selected, deduplicated, sanitized observations only.

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