fix(cli): a replay puts back exactly the tree it found — nothing lost, nothing added (#128) * fix(cli): a replay puts back exactly the tree it found — nothing lost, nothing added The default replay restores the recorded tree over the working tree and promises "your files are restored when the replay ends". Where the two trees disagree about what exists, the put-back kept neither half: - Nothing lost. The safety copy is an ordinary snapshot and honours .gitignore; the restore writes every file the recording holds. A settings.json the recording tracked and the workspace ignores now was overwritten with the recorded bytes and never put back. Measured with the built CLI: "MY LOCAL SETTINGS, NOT IN GIT" came out of `orca replay` as the recording's defaults, with no copy in git or in orca. - Nothing added. A snapshot restore writes files and removes none, so a directory the operator had deleted and committed the deletion of (legacy/old-config.env) came back and stayed as untracked files. Before anything destructive, `assertOverwritable` lists the files the recorded tree holds that the copy does not. One present on disk means the restore would destroy it: the replay refuses, as `assertResettable` already does for a delete, and names --worktree. The absent ones, and the directories made for them, are removed after a successful put-back — orca wrote them, and nothing of the operator's was at those paths. `FsCapture.files(tree)` lists a tree's blobs for this, via `ls-tree`. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): and what the replayed agent writes, not only what the restore does The put-back now answered for the files the restore writes, which are the recording's first tree. An exact replay also makes the recorded agent do what it did, and its writes are in the later checkpoints. With the built CLI: a run whose agent created auth.ts, replayed after the operator had removed it, left `?? auth.ts` behind. `assertOverwritable` takes every tree the run recorded. A file the agent will write that is on disk and not in the copy refuses the replay, as the restore's own do; one that is absent is removed after the put-back. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): a file standing where the recording had a directory is in the way too Found reviewing this branch before its review landed. The recording had cfg/app.json; the operator's tree has an ignored *file* named cfg. The restore deletes that file to make the directory, and the copy never held it. With the built CLI, on this branch's previous head: `orca replay` exited 0 and cfg came back as an empty directory — the file gone. The check had read the path's lstat error as "nothing there". That error does not say: POSIX answers ENOTDIR for a path under a file, and Windows answers ENOENT, exactly as for a path under nothing at all. So each absent path now has its ancestors asked, top down: a missing one means nothing is in the way, and one that exists and is not a directory is the file the restore would destroy — refused unless the copy holds it. The refusal now names what would be overwritten ("would overwrite cfg: …"), which reads right for both a path and a file standing in its way. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): a link git walks into is a directory, and the removal walks no other The previous commit judged every directory on the way to a recorded path by `lstat`, which calls a Windows junction a link — while git walks into a junction as a directory, holds its contents in the copy as ordinary files, and writes through it on restore. With the built CLI: a file deleted from under a junctioned `data/` refused the whole replay ("would overwrite data"), where the previous head had replayed exactly. My regression. - Directories on the way are asked first, then the path, the way checkout writes. One that git walked into when it took the copy counts as a directory; any other file or link in the way is what the restore destroys, refused unless the copy holds it. - One the copy holds is left to the put-back, which writes it back and clears the directory the restore made in its place — so nothing under it is queued for removal. - The removal itself passes only through real directories and links git walked into, asked at removal time: a link can have appeared on the way since, and `rm` follows it. The new test holds trivially on POSIX, where git records a symlink as itself, and fails on Windows against both the previous head (the false refusal) and main (b.csv written back through the junction and left). Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): take away only what the recording wrote, known by its bytes orcacode-review, on this branch: the list of files to take away is made before the replayed agent runs and acted on after it — minutes later with a real harness — and it names exactly the paths no copy holds. `rm` of whatever stood there then deleted anything written at those paths in the meantime: the operator's own new file, a watcher's output, a replay that went its own way. Nothing anywhere could bring those bytes back. Each file now carries the blob ids of every version the recording holds for its path (`FsCapture.files` reports them), and goes only while what stands there hashes to one of them — what the restore wrote, or what the recorded agent wrote after it. Anything else stays, and `replay.left_in_place` names it. An exact replay writes exactly those bytes, so every end-to-end case removes what it did before. The removal moves into `removeIntroduced`, exported for the unit test that pins it: a file holding recorded bytes and the directory made for it go; a file someone else wrote at a recorded path, and a directory with something unlisted in it, stay, and the first is named. Without the check the test fails on the second file. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): the removal judges the file that goes, and walks only links that were links orcacode-review on 928d10f, two P1s, both real: - `walked` was every directory git walked into — on POSIX, every ordinary directory holding a tracked file — and the removal let `rm` pass through a *link* at any of those paths. A real directory swapped for a link after the copy was taken therefore still counted, and the removal could follow it out of the workspace to a file whose bytes happened to be the recording's. The removal is now handed only the paths on the way that were links when the copy was taken (and that git walked into); the classification still treats every directory git walked into as one. The same guard now covers the directories removed after the files. - Hash, then `rm`, looked the path up twice: a writer replacing the file in between had its bytes removed unjudged. The file is renamed aside first — atomic — so what is hashed is what is removed; one that does not match goes back with a hard link, which refuses to replace anything that has taken the path meanwhile, and otherwise stays beside it under the name it was set aside as, named in `replay.left_in_place`. Tests, both red on the logic they replace: a file written at the path while it is being judged survives (the test reaches that moment through an optional `judging` hook nothing in orca passes); and with a real copy taken over a real `data/`, swapping `data` for a link to an outside directory holding the recorded bytes leaves that outside file alone. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): a file set aside for judging always goes back if it is not taken Two exits from `takeIfRecorded` could leave a file under the name it was set aside as, found reviewing 4c67b42 before its review landed: - a read error while hashing (permission denied, say) threw out of the removal after the rename — now it counts as "cannot show orca wrote this", and the file goes back like any other that does not match; - putting back a symbolic link with `link` follows it on some platforms (macOS), leaving a copy of what it points at in place of the link — a link now goes back by the checked rename instead. Neither can be made to happen on this Windows machine, so neither has a test of its own; the existing ones still cover the matching, the mismatched put-back and the race. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): every way back creates only if absent orcacode-review on f9f0f11: `putBack` was atomic for a regular file (a hard link, which fails on EEXIST) and check-then-rename for everything else — every symbolic link, and a file on a filesystem without hard links. On POSIX `rename` replaces its destination, so a write landing between the check and the rename was destroyed: the very write the set-aside exists to keep. Low odds, as the review said, and the right consequence to call P1. Now each way back is a create-only-if-absent primitive: a file: link(aside, target) EEXIST -> stays aside no hard links: copyFile(aside, target, COPYFILE_EXCL) EEXIST -> stays aside a link: symlink(readlink(aside), target) EEXIST -> stays aside (a junction on Windows when it leads to a directory) and `replay.left_in_place` now says why a file can be kept without claiming it was rewritten: written since by something else, or in use. Tests for the two ways back this machine can reach: a newcomer that takes the path while the original is judged keeps it, and the original stays beside it, named in set_aside; a junction goes back as a junction. Both pass on f9f0f11 as well — the race was in a window between two calls that no test can land in without a seam placed there, and this code has no such window left to place one in. Co-Authored-By: Claude Opus 5.5 (1M context) * fix(cli): a walked link is walked only while it points where it pointed orcacode-review on a19b1bf: the removal was handed the links it may pass through — ones git walked into, that were links when the copy was taken — and checked at removal time only that each was still a link. The replayed agent runs for minutes in between; a junction re-pointed at another directory in that time is another link, and following it reached a directory orca was never given, where a file with a recorded version's bytes would go. `walked` now keeps each link's target as `readlink` gave it then, and the removal passes through a link only while `readlink` still gives the same. New test (Windows only — only Windows walks into a link; git records a POSIX symlink as itself): a real copy taken over a junctioned data/, the junction re-pointed at a second directory holding the recorded bytes, and that second directory's file survives. Red on a19b1bf. Co-Authored-By: Claude Opus 5.5 (1M context) * test(cli): pin that a held file where the recording had a directory comes back orcacode-review on 975e9cf reported that the put-back cannot write a file back over the directory the restore made in its place — that `checkout-index -f` skips it and exits 0 — and proposed refusing such a replay. It does not reproduce. The same read-tree + checkout-index -a -f sequence on git 2.43.0 (Linux, WSL) and 2.55.0 (Windows) removes the directory, writes the file back and exits 0; and the scenario as described — a tracked `cfg` with an uncommitted edit, a recording that had `cfg/app.json` — replays exactly through the built CLI with the edit intact (`git status`: ` M cfg`). No change to the logic. This pins the behaviour instead, so CI's own git answers the question on every run: the test fails if the put-back ever stops bringing the file back, and it fails under the proposed refusal, which would turn a replay that works into one refused with a message ("the copy does not hold them") that is not true of it. Co-Authored-By: Claude Opus 5.5 (1M context) --------- Co-authored-by: Claude Opus 5.5 (1M context)