Pause, resume, abort

Pausing is durable - the run state is persisted, so killing Vibestrate’s process and restarting it preserves the pause.

Pause

vibe pause <runId>

The orchestrator polls between stages. When it sees the pause flag, it transitions the run to paused and remembers the status it was about to enter. Nothing is interrupted mid-stage - pauses always land cleanly at a boundary.

Resume

vibe resume <runId>

Clears the pause flag. The orchestrator picks the run back up from the status recorded in pausedAtStatus.

Cancel a pause request before it fires

If you ran vibe pause and then changed your mind before the next stage boundary, vibe resume cancels the pending pause without ever transitioning to paused.

Abort

vibe abort <runId>

Marks the run as aborted. The worktree is preserved on disk - you can still cd into it to read the partial work. To clean up the worktree:

cd your-project
git worktree remove ../.vibestrate-worktrees/<runId>-<slug>
git branch -D vibestrate/<runId>-<slug>

Policy-gated pauses are different

If policies.requireApprovalAtStages lists a stage, the run automatically pauses at the boundary into that stage with status waiting_for_approval. The fix is vibe approvals decide, not vibe resume:

vibe approvals list <runId>
vibe approvals decide <runId> <approvalId> --approve   # or --reject

When to abort vs let it block

• The run is doing something you don’t want it doing → abort.
• The reviewer is doing something useful but stuck on something you’d rather decide yourself → abort, fix the cause (clarify the task, add a skill, adjust the rules), run again.
• The run blocked itself (blocked) because the reviewer or verifier raised a real concern → don’t abort. Read the findings, decide, restart with the lesson encoded in the task or a skill.