Execution

/ivar-execute <plan-path> [--mode goal|default]

Execution starts an auditable Run Receipt for an approved Plan. The active provider coordinates decomposition, scheduling, monitoring, and synthesis with its native subagent mechanism. Ivar owns the lifecycle, approval boundary, and filesystem evidence; it neither launches headless provider processes nor stores provider conversation or subagent identifiers.

Before it will run

• A feature session — IVAR_FEATURE and IVAR_SESSION_ID both set, and $IVAR_SESSION_PATH/state.json readable.
• The feature exists in the hall.
• Every planning gate passed: Requirements, Analysis, and Plan approved.
• No other non-terminal Run Receipt holds the feature's run lock.
• No promoted repo has already been successfully integrated.

Start a run

The coordinator invokes the lifecycle command before doing implementation:

ivar feature execute start <feature> --plan <path>

Start validates the approved Plan and captures its fingerprint, the coordinator session and provider, and an immutable baseline of every promoted worktree. That receipt is the record against which the run is later finished. It is not a task board: the provider reads the Plan, chooses native subtasks, runs only independent non-conflicting tasks concurrently, and keeps its scheduling reasoning in its own context.

Execution modes

ivar feature execute start accepts --mode <default|goal>:

ivar feature execute start <feature> --plan <path> --mode goal

• default (default on new runs): The coordinator executes wave by wave, pausing for human approval at every wave checkpoint, validation failure, and review barrier finding.
• goal: Autonomous loop running from Wave 1 through execute finish. The coordinator automatically runs validation, applies fixes up to caps (max 3 validation fix attempts per wave, max 3 review-fix rounds), and finishes the run before stopping ahead of delivery or integration.

Claude Code /goal prompt

When executing under Claude Code in goal mode, the coordinator prints a ready-to-paste /goal prompt:

/goal Run `ivar feature execute status <feature>` and quote its output: the run is `succeeded` or `failed`, and every wave in plan.md has a `wave <n>:` checkpoint. Both the Standards review and the Spec review report no findings, or 3 review-fix rounds ran and the remaining findings are in the finish report's follow_ups. No wave took more than 3 validation-fix attempts; anything still failing after the third is listed under Deferred validation failures. `ivar feature deliver` and `ivar feature integrate` were not run. Stop there and hand delivery to the human.

Stop before delivery

Goal mode deliberately stops after recording execute finish (outcome succeeded or failed), leaving ivar feature integrate and /ivar-deliver under human control.

Run states

Check the current receipt or durable history at any time:

ivar feature execute status <feature>
ivar feature execute status <feature> --history

History remains after a terminal run is replaced, so it is safe to understand what happened before beginning the next run.

Finish with evidence

When the coordinator has completed work, it writes a temporary structured report with a summary, at least one task result, and at least one verification result. It may also record provider-neutral agent roles, deviations, blockers, and follow-ups. Then it finishes the receipt:

ivar feature execute finish <feature> --plan <path> --report-json <path> --outcome succeeded

failed and blocked are also valid outcomes. A blocked finish preserves the checkpoint and its blocker so the same logical run can be resumed after a human responds. Ivar compares the final worktree state with the immutable baseline, including inherited dirty files and committed changes, so a commit cannot hide what changed during the run.

Recovery and logical resume

Reconnect to the feature session, inspect the receipt, then choose the recovery path its state requires:

ivar feature execute start <feature> --plan <path>

Running ivar feature execute start reattaches a coordinator to a blocked run after its blocker is resolved. The provider may change: a Run begun in Claude Code can resume in OpenCode, and vice versa. That is a logical resume recorded as ordered Ivar session/provider lineage, not a resumed provider transcript.

If a run was non-terminal, running start again ends the non-terminal receipt as interrupted and begins a fresh receipt against the currently approved Plan. Terminal receipts release the lock and are archived before a new run begins.

Plan divergence and revision

If the Plan fingerprint no longer matches at finish, Ivar records the receipt as diverged rather than accepting the submitted outcome. Review and approve the revised Plan, then explicitly accept it:

ivar feature execute accept-revision <feature> --plan <path>

Accepting a revision records the old and new fingerprints and moves the receipt to blocked. Resume explicitly when you are ready to continue; accepting a revision never silently restarts work.

Scope changes

A provider may discover work outside the approved Plan. When it is isolatable, the coordinator creates a child Feature, records the deviation or follow-up in the report, and excludes that implementation from the current Run. The approved Plan remains the boundary for this receipt.

Existing execution state

The first receipt-aware operation imports any older execution state as a legacy-import receipt and preserves the original data as archive evidence. A terminal legacy record keeps its outcome; an unfinished one becomes interrupted, never a claim that old tasks can be resumed. You can inspect the import through normal receipt status and history commands, then start a new provider-native run when appropriate.

Closing a feature

A feature cannot be closed while a Run Receipt is active, blocked, or diverged. Finish, restart, or resolve the receipt first. Once it is terminal, close preserves receipt history as a durable lifecycle fact; deleting a feature removes its local feature directory only when the normal deletion safeguards permit it.