Plan

Plan translates accepted intent into the smallest useful implementation approach. It never creates product requirements, and it stays an explicitly accounted phase even when its output is a single concise note.

You can call it directly. Full-lifecycle setup isn't a prerequisite, and Forge applies or reuses the Launch, depth, and workflow choices only for the boundary you asked for.

Who owns itCopy Anchor Link

The Engineer owns technical strategy, decomposition, and constraints. Product Manager owns product scope and observable outcome criteria when those need authoring; technical tasks stay with Engineer. A precise engineering Plan over a ready Issue needs no new PM pass, and product authorship here doesn't add another approval gate.

Your current request can be the ready Issue when the outcome, boundaries, and observable completion are clear. Otherwise PM prepares it first, then Engineer assesses the technical effort and proof, at either depth.

What it producesCopy Anchor Link

Plan can live as notes on the Issue or as spec/plan.md in the loop. It doesn't have to be a separate document, and for a small Issue the right answer is often the proposed route, the existing machinery to reuse, the proof, and the material risk, recorded on the Issue itself. Sub-Issues get created only when they improve ownership, coordination, or reviewability.

A useful Plan covers:

• accepted outcomes, constraints, preserved behavior, and non-goals;
• the current flow and the machinery worth reusing;
• the approach, material seams, dependencies, integration order, and one-way doors;
• each outcome's acceptance and proof;
• bug hypotheses and the cheapest distinguishing observations, when applicable;
• the actual open decisions and explicit stopping conditions.

Issue criteria stay observable and behavioral obligations map to scenario IDs. "Implement component X" is not acceptance criteria.

Forge avoids speculative architecture, fixed agent counts, file-by-file instructions, and Spec prose copied into the Plan. Builders own reversible tactics, so the Plan doesn't try to pre-decide them.

Preservation scopeCopy Anchor Link

For changes that can affect existing behavior, the Plan carries a compact record of signals, affected obligations, selected checks, and gaps. It starts from changed package ownership, APIs, events, shared types, persistence, shared foundations, deleted or renamed files, test expectation changes, and authority edits, then expands from those paths when exported contracts or actual semantics reach further consumers. The Builder proposes this scope; it's neither a path-only pass nor a full-product replay.

Saving itCopy Anchor Link

Even a one-paragraph Plan uses managed identity and validation. A plain Markdown file or a hand-written .forge path doesn't satisfy the contract. For a new loop:

forge init <loop> --repo <repo> --title <title>
forge docs create plan .forge/loops/<loop>/spec/plan.md --repo <repo> --title <title>
forge docs validate .forge/loops/<loop>/spec/plan.md --repo <repo>

Skip initialization when resuming, and update an existing managed record rather than creating a duplicate. Scaffold with the CLI, edit the body with normal file tools while preserving the generated frontmatter and the descriptive # heading, then validate.

An already-approved ticket is source authority to link, not a reason to install a canonical decision or bootstrap a knowledge base. Only a new human decision earns a decision entry, and an empty decision file isn't one.

What proof it needsCopy Anchor Link

Before handoff, Forge inspects the saved result once: the artifact exists and validates, the proposed proof can actually distinguish the intended change, and the index and log pointers match what the tools really returned. Code checks are scoped to code or tests so they don't end up counting the ticket or the Plan itself. Safe discovery and precondition checks are fine, and an expected pre-change failure is different from an unusable command. Forge does not implement the change to validate the Plan.

If a save fails, it repairs the cause and verifies the result while the tools are still available, rather than ending with a promise to retry. Dependent success entries get written only after the operation succeeds. Structural validation proves structure; it doesn't prove the Plan is sound or delivered.

Where it stopsCopy Anchor Link

Plan stops before Build. In Guided, a newly consequential Plan is presented and approved before its boundary review, and Forge won't dispatch Build or edit production code while that approval is pending. Existing approval can be reused when it covers the same strategy. Under Auto, the same jobs run inside the explicit grant, and the delegated authority is recorded as delegated rather than as your approval.

Independent Plan review checks faithful coverage, technical soundness, proportionality, and a usable handoff, without adding requirements of its own.

Before a coordinated Build, Forge shows the actual Worker ownership, the sequencing, and the integrating Engineer.

What it doesn't authorizeCopy Anchor Link

Plan doesn't authorize Build. It can't invent product requirements from code, plans, or logs, and if the implementation would need a semantic change, that decision goes back to you before any dependent work. Following your host's authorized checkpoint policy doesn't establish Acceptance or Ship either. A direct Plan request stops at the result and records Build as pending, including under Auto.