feat(rewind): git working-tree checkpoints before Bash commands

[oratis]

Summary

Extends checkpoint/rewind (docs/DEVELOPMENT_PLAN.md §3.15.9) to cover Bash file mutations. Edit/Write snapshot a known file path; a shell command's targets aren't known ahead of time, so for Bash we capture a git working-tree checkpoint instead — the right tool for snapshotting an arbitrary set of changes.

How it works

• captureGitCheckpoint({cwd, reason, seq}) records a commit-ish — git stash create (captures the current tracked working-tree state without touching anything), or HEAD when the tree is clean. No-op (returns null) outside a git work tree or in a repo with no commits.
• Snapshot gains kind: 'file' | 'git' + gitRef. restoreSnapshot() branches:
  • git → git checkout <ref> -- <files changed since the checkpoint>, reverting exactly the tracked files the command touched.
  • file → blob write (unchanged).
  • Returns the restored path list.
• agent.ts: before executing a Bash tool (with an active session), capture a pre-Bash checkpoint. Cheap — a stash-create ref + one manifest line, no blob copy.
• /rewind: help text mentions Bash checkpoints; code/both report the reverted file count.

Limitation (documented in code + commit)

Untracked files a command creates aren't captured by the checkpoint, so rewinding won't remove them. Tracked-file modifications/deletions are reverted.

Tests

+4 in snapshots.test.ts, all against a real temp git repo:

• Clean-tree checkpoint → simulate a Bash rewrite → restore reverts the file.
• Captures the uncommitted pre-command state (a prior dirty edit) via git stash create, not just HEAD — restoring returns the dirty-before-Bash content.
• Non-git directory → null.
• Git snapshot round-trips through the manifest (listSnapshots).

Core suite 588 green; CLI 78; full repo green via pre-commit.

🤖 Generated with Claude Code