# Clone recovery evidence

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

## Environment

Two detached worktrees, each installed with `vp i` and run with `T3CODE_DEV_SEED=0 vp run dev`. Fresh worktree databases; no production data. Base: d756fed7aaac06134bc68cbe0047e6f14b0e9aa2. Head: ed1bd554b87a73e5fc7d4768fbb99eb8d1cf187e. Both recordings use Chromium on Linux, light theme, CSS viewport 1280x800. Captured at device scale 2 and encoded at 1280x800 with a 64-pixel environment caption. The input path and environment label are visibly redacted. No behavior or error text is replaced. Both recordings show the recovery interaction after restart.

## Synthetic remote

Under a caller-selected scratch directory, create `remotes/demo`, `git init` it, and commit one empty commit named `Synthetic repository`. Serve it with:

```sh
git daemon --reuseaddr --export-all --base-path="$SCRATCH/remotes" --listen=127.0.0.1 --port=19419 "$SCRATCH/remotes"
```

`git://127.0.0.1:19419/missing` does not exist; `git://127.0.0.1:19419/demo` is accessible. This removes network and account variability while using real Git.

## Identical sequence on each commit

`driver.mjs` takes CHECKOUT, server ORIGIN, DESTINATION and a mode. Run it from the checkout using Node supplied by `vp`.

1. Run `node driver.mjs "$CHECKOUT" "$ORIGIN" "$DESTINATION" seed`. Through the real server's authenticated WebSocket RPC, this starts a clone of the nonexistent remote, waits for its failed progress event, and retains its empty destination and project. It sets the title to `Preserved project`, pins it, disables auto-pull, selects local thread workspaces, and adds a `Verify` project script.
2. Stop the dev server and restart it with `T3CODE_DEV_SEED=0 vp run dev`. Reuse that worktree's state. The server ports stay the same.
3. Run the driver with mode `decorate`. It creates `Keep this thread` through the real RPC without running an agent turn. Thread creation is done after restart because the failed-clone tracker guards thread creation before restart. The transcript confirms an empty destination and no tracked clones.
4. Pair the web browser, open `Keep this thread`, and collapse thread details. Record the `ui-driver.json` interaction: Add project > Git URL > the accessible remote > the exact same destination > Enter. Paths differ only in the enclosing side-specific scratch directory.
5. Run the driver with mode `inspect`. Compare the project ID, thread ID, title, pinned timestamp, auto-pull, workspace mode and script with the pre-clone snapshot. Inspect real Git in the head destination.

## Observed

Base: the app shows `Clone failed` / `Failed to create clone project.` The destination stays empty and the clone tracker stays empty.

Head: the app opens a new-thread draft under the existing `Preserved project`; its original `Keep this thread` remains in the sidebar. The real server reports clone phase `done` under the original project ID, and real Git reports the synthetic repository's commit. Sampled settings and both original IDs are unchanged.

The runtime transcript contains actual driver output and explicitly labeled UI observations. Identifiers and timestamps differ across fresh databases by design. A preliminary unrelated failed clone was omitted from the head transcript's clone-list arrays; the scenario project and its output are unchanged.

## Not demonstrated

Cancelled-clone recovery, concurrent clone conflicts, nonempty destination rejection, and recovery through mobile, desktop, command palette shortcuts or prompt links were not exercised. This evidence covers failed-clone recovery through the web Add project flow and its real server. Other project settings beyond those listed above were not sampled. The initial failed clone was seeded through RPC rather than filmed in the UI; recordings cover the recovery interaction after restart.