Documentation fix for the snapshot safety net introduced in v0.3.0. No behavior change to the review itself.
The snapshot does not cover untracked files
git stash create snapshots tracked modifications only, so a fix to a file git has never seen sits outside the safety net. That mostly lines up with the threat it guards against - git checkout -- . cannot destroy untracked files either, so the protected set and the exposed set match. Two cases fall through, and neither was written down:
git clean -fddeletes untracked files with no recovery path. It was already on the ban list; now the reason is stated.- A fix that creates a new file is untracked and unprotected. Keeping edits inside the review scope should make this rare, but when it happens the summary has to say so rather than implying coverage.
Recovery pointed at the wrong snapshot
The integrity check still told you to recover from the step 0 snapshot. That one is taken before any fix exists, so it cannot restore them - it restores the state without them, which is what the clobber already produced. Recovery now uses the newest post-fix SHA, with git checkout <sha> -- <path>.