A test that could corrupt the repo it was testing

To prove version syncing works, it wrote 999.888.777 into seven tracked files and relied on an exit trap to put them back. Press the button to see what the working tree looked like during that window, and what any other session or commit would have read.

The live working tree, mid-run

Why a trap is not enough

kill -9 does not run EXIT traps. Neither does a full disk, an OOM kill, or a crashed shell. The old test wrote the live package.json and then depended on getting to run again to undo it. Any interruption in that window left the repository holding a fake version with nothing to warn anyone.

And the window was shared. Several Claude sessions against one clone is normal in this repo. Anyone reading, building, or committing during the run saw 999.888.777. That is what made npm test unsafe to run at all while someone else was working, which is what blocked reproducing #3263.

The fix removes the window instead of shrinking it. The round-trip now happens in a throwaway copy of the tracked files, so there is nothing to restore. The trap deletes a temp directory and that is all it does.

Proven, not asserted

checkresult
test passes17 / 17
break sync_versions on purposeexit 1, catches it
kill -9 mid-run, live package.jsonstill 9.7.0
kill -9 mid-run, sentinel in treenowhere
copy sourceworking tree, not HEAD

The copy comes from git ls-files, not git archive HEAD, on purpose. Copying from HEAD would test the committed stamp-counts.sh and tell a developer their uncommitted change passed when it never ran, which is the same success-shaped-nothing failure this repo has been clearing all week.

tests/unit/test-sync-versions.sh· sandbox build ~6s, 6472 files· unblocks #3263