Problem-solving guide

How to approve and recover repository changes

AI coding workflows need clear answers to when a generated change may be applied and what happens when verification or patch application fails.

Safety boundary: normal minitok runs do not require automatic acceptance. --auto-accept bypasses the normal approval prompt and should be used only when intentional.

Preview before approval

cd your-repository
minitok migrate
minitok run --dry-run "Refactor authentication and preserve the public API"
minitok status

Inspect the plan, target repository, configured checks, proposed scope, and stop conditions before a real run.

Use an explicit approval record

minitok run "Refactor authentication and preserve the public API" \
  --approval-file .minitok/approval.json

Approval covers one complete generated change set. File-by-file cherry-picking or hunk-level selection is not currently supported.

Recover from failure

  • Failed verification stops or guides bounded repair according to cycle, token, and time limits.
  • If a run cannot apply its generated change set, inspect the preserved .minitok/last-run.patch and apply it manually only after review.
  • Use minitok run list and minitok run show <run-id> to inspect state; the latest structured evidence is also available at .minitok/last-run.json.
  • A stopped run is not an applied change or a deployment result.

When this helps

Use these boundaries for multi-file changes, project tests, second-person review, or an inspectable change record. A tiny local edit may be faster manually. minitok does not guarantee correctness or replace human review.

Related: verify changes, record evidence, and safe runs. See the source repository.