Depth and control

Three choices shape every Forge run, and they're independent of each other. Workflow says what kind of outcome you're delivering. Depth says how much preparation and staffing the work earns. Control says when Forge pauses for you. None of them changes the boundary you asked for.

LaunchCopy Anchor Link

Before Forge dispatches a specialist or makes a substantive edit to artifacts or source, it reads enough of your request, the supplied artifacts, the current state, and the target harness to choose, then shows you a short bullet list:

• Workflow: Project, Issue, Bug, or Work
• Depth: Quick or Full
• Control: Guided or Auto
• Agents: the selected role names
• Boundary: the requested final phase or deliverable, and publication limits
• Sequence: the phases to perform and the accepted artifacts to reuse
• Gates: pending approvals, existing approvals, and decisions outside authority
• Workspace: the selected repository and the actual branch or worktree

Only the selected values appear, like Workflow: Issue and Depth: Full, with no subtypes and no "recommended" hedging bolted on. After the bullets comes one short paragraph explaining the choices: the effort and complexity evidence, what's still uncertain, what each specialist is responsible for, who starts next, and what you can override. Roles are listed before anyone is spawned, and actual host agent IDs are recorded afterwards.

Launch is an opening step rather than a sixth phase. On resume, Forge reuses the choices you already accepted instead of running the ceremony again, and routine follow-ups inside the accepted assignment don't relaunch.

Quick or FullCopy Anchor Link

Depth follows effort, complexity, uncertainty, and risk. It's not a proxy for ticket size.

Quick is ready intent, brief Engineer plan notes, implementation, local checks, Reviewer judgment, and repair. It's the build/check/fix loop rather than a waiver of preparation or proof, so Acceptance still runs when you ask for it and Ship still needs authorization. Quick fits when the outcome is clear, effort and complexity are low, the accepted design and contracts already cover the work, and you know what proof will settle it. One ticket, a handful of files, or somebody being in a hurry doesn't establish any of those conditions. A bounded guidance or documentation change with no new executable mechanism normally starts Quick.

Full does the Spec shaping, design and contract work, Plan, Build with Review, and Acceptance the work actually needs, up to your requested boundary. It fits substantial effort, real uncertainty, interacting behavior, or risk. A single Issue can require Full, and several coordinated outcomes normally do. Full doesn't dispatch specialists it has no use for.

Your current request can be the ready Issue if it states the outcome, boundaries, and observable completion. When those are missing, the initial depth choice is provisional. After Launch, PM creates or completes the Issue, with Engineer supplying technical judgment on effort, complexity, and proof. That can happen at Quick depth and on technical tasks too. Forge reuses adequate existing estimates and won't introduce a scoring system or a separate estimation document.

Your depth selection wins. If Quick can't cover a requirement Forge can actually demonstrate, it names the missing design, contract, or proof and comes back to you for a depth or scope decision, including under Auto unless you delegated depth changes explicitly. It won't silently enlarge the team or drop required work.

Guided or AutoCopy Anchor Link

Guided is the default. Forge presents Launch and stops so you can accept or edit the workflow, depth, team, and control. Accepting a Launch you've been shown satisfies that gate, and it approves the plan of attack rather than any Spec or Plan text you haven't read yet.

Auto needs an explicit instruction for this run, something like "full auto" or "run autonomously through Acceptance". Forge shows Launch, then proceeds through the ordinary Launch, Spec, and Plan gates inside that grant, recording the exercised delegated authority and the instruction that granted it. "Build this", "deliver this", urgency, and silence don't select Auto.

Auto removes ordinary pauses, and that's all it removes. Independent boundary checks, Review, and Acceptance still run. Accepted intent, host permissions, protected-Spec rules, and publication restrictions all still hold. Conflicts, new scope, unresolved consequential choices, and anything outside the grant come back to you. Auto is never authority to apply protected standing Spec bytes without the exact approval those require, and a delegated grant is never recorded as human approval of unseen text.

Mode changes govern subsequent work. Auto for Spec doesn't schedule Build.

The Spec and Plan gatesCopy Anchor Link

These are the two places Guided delivery stops on its own.

The Spec gate. When Forge authors a new or materially revised Spec, it presents the exact reviewable draft and stops with your approval as the next action. It won't start Plan, delegate downstream work, edit production code, or infer that you approved. After you approve, it records the human source and the approved revision, runs the Spec boundary review, and continues only if that review preserves the meaning you approved. A boundary review can't make a new human decision, so a consequential revision comes straight back to the gate.

The Plan gate. When Forge authors a consequential Plan, it presents the exact Plan and stops before Build, with the same rules about recording, boundary review, and consequential revisions returning to the gate.

An existing accepted Spec, ticket, or Plan satisfies its gate once its identity, approval, and relevance are recorded. An explicit direct Build or fix request over a bounded accepted outcome supplies Build authority by itself, and brief faithful tactical notes inside that authority don't manufacture a second gate or a planning team. It still returns to you if the implementation turns out to need changed meaning or an unresolved consequential strategy.

Under Auto, the same authoring and boundary-review jobs run without the ordinary pauses, inside the cited grant.

A worked LaunchCopy Anchor Link

For an accepted, genuinely small Issue:

• Workflow: Issue
• Depth: Quick
• Control: Guided
• Agents: Engineer, Reviewer
• Boundary: Build
• Sequence: Spec (reuse) → Plan (brief notes) → Build (including Review)
• Gates: Launch approval; new intent or consequential strategy changes
• Workspace: the selected repository and actual worktree branch

The Issue defines the change and its acceptance criteria. Effort and complexity are low, the accepted design suffices, and a focused check proves the change. Engineer starts with brief notes and builds, then Reviewer checks the result separately. You can change depth, team, or control before it starts, and Acceptance and Ship stay outside this request.