# Stop evidence

Both recordings: Linux, Chrome 151, real web development client, 1440×900 CSS pixels, dark theme. Each server ran from a separate, unmodified commit checkout, with its own fresh database and `T3CODE_DEV_SEED=0 vp run dev`. Dependencies were installed separately with `vp i`.

Before: d756fed7aaac06134bc68cbe0047e6f14b0e9aa2
After: 240f3678ecfe39c3506ceeccf22ebf4526f2c689

## Synthetic fault injection

The original lost provider terminal event cannot be caused on demand. After each server completed startup recovery, run `node seed.mjs CHECKOUT` with the same seed script. It validates and persists synthetic domain events through the production EventSink service, including the event log and projections; it does not edit SQLite rows directly or patch application code. Reload the client afterward because the fixture process cannot publish to another process's in-memory event stream. Do not restart the server after seeding: startup recovery would cancel the synthetic native workers before the interaction.

The fixture contains a completed parent run, a completed delegated child run with a final answer, a running native-subagent record linked to the completed child run but no live native subagent turn item, and a nested native thread with running records/root nodes. No provider process runs during this reproduction. Replay's showcase selection is synthetic metadata only.

## Browser preparation

Use an isolated agent-browser session with system Chrome and `--args --no-sandbox`. Pair each origin through its app's pairing screen; never put credentials in a recording. Set viewport with `set viewport 1440 900`, and theme with `set media dark`.

For both origins, the built-in client setting `threadDetailsItems` was:

```json
{"environment":false,"openIn":false,"scripts":false,"branch":false,"gitActions":false,"changes":false,"servers":false,"automations":false,"lineage":true}
```

Other relevant settings: `panelAnimationDurationMs: 0`, `timestampFormat: "locale"`. Reload the parent after setting them. Hiding workspace controls keeps machine details out of the captures; no recording was redacted.

## Same interaction on each side

Run `python3 record.py SESSION before OUTPUT_ROOT` or `python3 record.py SESSION after OUTPUT_ROOT`, starting on the seeded parent thread. Each invocation creates a new timestamped output directory.

1. Show the parent task still Running, under Working in the sidebar, and Lineage showing one running child.
2. Open the child and read its completed final answer while its native worker remains active.
3. Return to the parent and press Stop on the delegated child's Lineage row.
4. Observe for six seconds.

Base keeps the task Running, parent under Working/Waiting, and Lineage at one running child. Head shows the completed task with the child's final answer, removes the waiting indicator and Working shelf entry, and moves the child into Previous agents. This checkout calls the relationship panel “Lineage”; it is the delegated Agents row described in the report.

`runtime-observation.txt` is an additional read-only status/command-receipt capture from each running server's synthetic database after the recorded interaction. The recordings are the primary evidence. No tests were used as evidence.

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