✅ Verification report — local runtime A/B (Linux)

I verified this PR by building the actual post-merge tree (origin/main + this branch — GitHub reports MERGEABLE, git merge-tree is clean) and running a real BEFORE/AFTER comparison, not just the unit suites. The last-turn /rewind gap described in the PR is real, and this change closes it. No PR-introduced regressions found; the security hardening in resolveBackupPath is a welcome bonus.

Environment: Linux, Node v22.22.2. BEFORE = origin/main; AFTER = merge of origin/main + this branch. Both arms run the same cli build; only the four core source files differ, so the delta is exactly this PR.

1. Claimed suites + typecheck (AFTER / merged tree)

(The full npm run build emits the usual TS5055 … would overwrite input noise from the project-reference dist in an ephemeral worktree — environmental, not from this PR. The per-package tsc --noEmit typecheck is clean on both touched packages.)

2. Revert-proof — the tests pin the new behavior

Reverting only the 4 source files to origin/main (keeping this PR's tests) makes exactly 9 tests fail (549 pass), all on the behavioral core of the change:

fileHistoryService.test.ts
  × trackEdit > records the updated latest snapshot after tracking a file
  × trackEdit > does not record duplicate tracking for the same file
  × trackEdit > records again when a second file is tracked in the same snapshot
  × trackEdit > swallows recorder errors after tracking a file
  × trackEdit > heals a failed entry on the next trackEdit attempt
  × restoreFromSnapshots > records failed markers when restored backup files are missing
  × restoreFromSnapshots > does not restore backup files that escape the session directory
config.test.ts
  × wires file history snapshot updates to chat recording
  × startNewSession > flushes the outgoing chat recording service when switching sessions

The reverted source also fails to even typecheck the new tests (TS2554: Expected 3 arguments, but got 4 — the new onSnapshotUpdated recorder arg). The new client.test.ts / chatRecordingService.test.ts cases pass on both arms, which is consistent with the diff: client.ts is a comment-only change (the makeSnapshot + turn-boundary record already existed on main), and the recordFileHistorySnapshot refactor is behavior-preserving.

3. Service-level A/B on the shipped artifact

Imported the built core/dist/.../fileHistoryService.js and ran makeSnapshot('p1') → trackEdit(file) against a real file, then simulated resume (serialize → last-wins-by-promptId → restoreFromSnapshots → rewind('p1')):

The turn-boundary snapshot (what client.ts records right after makeSnapshot) is empty on both arms — so BEFORE the fix the only persisted record for that turn carries no backup, and a resume can't rewind the edit.

4. Real TUI E2E (tmux) — the headline

Drove the real qwen TUI in tmux against a scripted mock provider that performs a genuine read_file → write_file tool chain (--yolo), so the app actually edits a.txt. One prompt, then a clean /quit (no second prompt) — i.e. the exact "session exits after an edit but before the next makeSnapshot" scenario. Inspecting the persisted session JSONL:

AFTER  →  file_history_snapshot records: 2
  fhs#0 promptId=…########0 files=[]                          ← turn-boundary (empty)
  fhs#1 promptId=…########0 files=[a.txt: backup=SET / v1]    ← trackEdit-recorded (THE FIX)

BEFORE →  file_history_snapshot records: 1
  fhs#0 promptId=…########0 files=[]                          ← only the empty record; backup lost

Same single edit, same clean exit — AFTER persists the pre-edit backup immediately (so resume + last-turn /rewind works), BEFORE persists only the empty snapshot. This matches the service-level A/B exactly.

Notes (non-blocking)

• Append semantics: records are appended through an async write chain; a graceful exit flushes them (verified). The fix queues the backup record immediately on trackEdit, closing the gap for normal exits; it does not make individual appends synchronous, so a hard SIGKILL landing between "queued" and "written" remains best-effort — acceptable and an inherent property of the append model, not a regression.
• Bonus hardening: resolveBackupPath now rejects a backupFileName that escapes the session backup dir (path-traversal guard), covered by the new "does not restore backup files that escape the session directory" test. Good addition.
• Scope: I exercised the GeminiClient/TUI path (TTY → file checkpointing enabled). The daemon/ACP path (Session.ts) drives makeSnapshot directly and was not separately E2E'd here, but its makeSnapshot('p1') call site mirrors the same pattern and the 125 ACP Session.test.ts cases pass.

Verdict: LGTM. The fix is correct, tested, regression-free on the merge result, and the BEFORE/AFTER behavior is exactly as described.

_{Verified on Linux with a real TUI + mock-provider tool-edit E2E and built-artifact A/B; complements the author's macOS run.}