Review completed. 3 suggestions posted.

Comment augment review to trigger a new review at any time.

Actionable comments posted: 1

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/automator/engine.py`:
- Around line 759-763: The pause notice for preserve failures is using
rollback-off recovery wording even when rollback_on_failure is enabled, so
update the messaging in _pause_for_manual_recovery to be parameterized by the
failure reason passed from _preserve_attempt_commits. Make the preserve_failed
path describe that this attempt produced commits that could not be parked on a
recovery ref, and ensure the operator guidance matches the actual state instead
of telling them to just enable rollback_on_failure. Add or adjust a test for the
preserve_failed case to assert the notice text mentions the commits and is
accurate.

Reviewed this end-to-end — it's a solid, correct safety fix and the direction is right. The ordering is correct (_preserve_attempt_commits runs before _safe_reset, so the recovery ref is created at the attempt tip before the branch is moved to baseline), the plain-rollback-pauses vs. re-drive-proceeds split matches the pause-free re-drive contract, and I confirmed the core mechanic locally on git 2.54: a git branch ref keeps the commits reachable through git reset --hard <baseline> + git gc --prune=now and recoverable by name. No cross-platform concern either — it's all _git subprocess calls with /-delimited ref names and pure-Python slug sanitization, so Linux/macOS/Windows behave identically.

One follow-up worth addressing (non-blocking):

attempt-preserve/* refs accumulate with no lifecycle

Every auto-rollback that had committed work leaves a permanent attempt-preserve/<run_id>-<sha> branch, and nothing ever removes it. In a long-lived project with scm.rollback_on_failure on, these grow unbounded — cluttering git branch output and eventually adding overhead to ref-walking operations.

Scoping the risk: there's no git push anywhere in src/automator (in-place mode never pushes; worktree mode merges locally), so these refs are local-only — this is repo clutter, not a remote-leak. That keeps the severity low, but the unbounded growth is still worth capping.

Suggested resolution, mirroring the retention patterns already in the codebase (runs.prune_sessions / keep_n, and the delete_branch / keep_failed config style in ScmPolicy):

1. Bounded-retention prune. Keep the N most-recent attempt-preserve/* refs and delete the tail — a natural place is run start, alongside runs.prune_sessions:

   git for-each-ref --sort=-committerdate \
     --format='%(refname:short)' refs/heads/attempt-preserve/
   # keep the first N; `git branch -D` the rest
   

   Sort by committerdate so the most recently preserved work is the last thing pruned, and default N to a safely non-zero value so an aggressive default can't defeat the safety net.
2. Expose it as an ScmPolicy field to match the existing config surface (e.g. preserve_keep: int = 20) — operators who want zero clutter can lower it, those who want maximum safety can raise it.
3. (Optional) a bmad-auto maintenance subcommand to list/prune attempt-preserve/* on demand.

Two minor notes

• _preserve_attempt_commits wraps preserve_commits in try/except verify.GitError but not the leading commits_above call, so a bad baseline there would propagate out of the rollback. It mirrors today's behavior (the base git reset --hard already fails on a bad baseline, and baseline is trusted — captured at attempt start), so it's fine as-is; just flagging the asymmetry in case you'd prefer a uniform failure surface.
• Consider a CHANGELOG entry if that's the convention here (I realize it's often curated at release time via the release driver).

Nice work overall — the fail-safe preserve_failed wording that names the at-risk commits instead of the misleading "just reset --hard" instruction is a particularly good touch.