Problem-solving guide

How to approve and recover AI agent work

Set a deliberate boundary before applying an AI-generated change and preserve a clear recovery path when verification fails.

Problem and general approach

Preview first, inspect the repository, task scope, configured checks, and stop conditions, then approve one complete change set only when the review boundary is clear. If a run stops or patch application fails, preserve the run state, inspect the patch, and use the repository's normal Git or release recovery procedure.

Where ad-hoc workflows fall short

Automatically accepting a model response can apply an unintended multi-file change. A stopped run is not the same as a deployment rollback or proof that no files changed.

When minitok fits

Use minitok for repository changes that need dry-run preview, explicit approval, deterministic checks, bounded repair, and inspectable recovery evidence. It does not provide hunk-level cherry-picking or a universal release rollback.

cd your-repository
minitok migrate
minitok run --dry-run "Refactor authentication and preserve the public API"
minitok status
minitok run "Refactor authentication and preserve the public API" --approval-file .minitok/approval.json
minitok run list
minitok run show <run-id>

If verification fails, inspect .minitok/last-run.patch when present and review .minitok/last-run.json. Apply or revert changes only through a reviewed Git or release procedure.

Alternatives and limits

A protected branch, pull request review, Git revert, backup, or deployment-specific rollback may be the right control. Approval covers one generated change set; it does not replace human review, backups, security controls, or release operations.