Planning

/ivar-plan <feature-name>

Planning turns a discovery brief into an approved Plan that a provider can execute. It needs a feature session — IVAR_FEATURE set — and a feature that already exists. Start a fresh cycle with ivar plan create <feature>.

Three artifacts, three gates — but gates are optional by absence

Requirements → [approve] → Analysis → [approve] → Plan → [approve] → Execution

Each phase stops and waits. The agent writes the artifact, shows it to you, and records approval only after you say yes. An approved Plan authorizes execution; there is no separate graph or execution approval.

A gate exists only once its artifact does. An artifact that was never written is not a gate — so a change small enough to skip Requirements and Analysis can carry a plan.md alone through to execution. The moment either missing artifact is written, it blocks plan approve and voids an approval already granted, until it too is approved.

They live committed under the hall and are projected into the view directory at plans/<feature>/, so edits there land in the hall's committed copy.

The reference system

Three namespaces. Each is declared in exactly one place and cited everywhere else — that is what makes an approved plan checkable rather than merely agreed.

Real examples from this site's own feature: R-QUICKSTART-PAGE, R-SHARED-COMPONENT, N-VOICE, N-MOBILE, and OP-DOCS-CONFIG.

Phase 1 — Requirements

Functional requirements have stable R-* ids; non-functional requirements and norms use N-*; constraints capture fixed boundaries. The ids are the contract: everything downstream cites them, and renaming one silently orphans every citation.

Phase 2 — Analysis

Read the relations in HALL.md first — select the ones involving potentially affected repos, follow only the linked topics, and record what is relevant in analysis.md. This checkpoint never edits HALL.md; /ivar-relations is the only writer of that region.

Then, with approved requirements as context, record affected modules (repo, path, impact level), trade-offs between approaches, risks and mitigations, and a recommendation.

Phase 3 — Plan

The plan is the REASONS canvas:

## Operation details makes the work executable and reviewable. Give each operation its own stable marker and say what it changes, how it is verified, and what proves it complete:

## Operation details

**OP-API-CONTRACT** — Define the request and response types for `POST
/checkout`, including the `410` a closed cart answers with.

- `touches`: src/api/checkout.rs
- `tests`: a closed cart answers `410`; an open one answers `200`
- `doneWhen`: the contract compiles and both tests pass

**OP-API-HANDLER** — Implement the handler against that contract, rejecting a
cart the session does not own before any pricing runs.

- `dependsOn`: OP-API-CONTRACT
- `tests`: a foreign cart is rejected before pricing; an owned cart prices once
- `doneWhen`: a foreign cart can no longer reach the pricer

The Plan describes outcomes, dependencies, safeguards, and evidence. It does not prescribe a persisted subagent graph, provider targeting, or filesystem ownership split. The provider coordinating execution chooses its native subagents and keeps that transient coordination in its own context.

What happens next

Run /ivar-execute from the feature session. It starts a Run Receipt, then the active provider decomposes the approved Plan and coordinates its own native subagents. Ivar records the authorization, lifecycle, and evidence; it does not schedule or inspect those subagents.