# What each stage means

Every stage on the Factory line, what Warden does in it, what it waits for, and the exact statuses you will see on an item.

An item's stage is worked out from real state: the decisions made on it, its plan or spec, its build chat and git. This page goes through the line left to right. The quoted statuses are the exact words on the item.

## Ideas

Where work enters. An idea is a title and a description, like a ticket. It arrives from the Warden inbox (**+ New idea**), a tracker source, or an automation, and the tile shows **From:** with its source.

| Status | Meaning |
|---|---|
| *Queued for triage* | Triage will pick it up next. Model jobs run one at a time. |
| *Triage is analysing it* | The planner is reading the idea and the repo. |
| *Waiting for triage* | Automatic triage is off for this project: press **Run triage**. |
| *Triage failed: retry* | The model call failed. Nothing retries by itself; press **Run triage**. |

## Triage

A read-only planner (it can read the repo, never change it) answers, for each idea:

- **Verdict**: accept, needs more information, reject, or duplicate.
- **Lane** and **confidence**, **size** (XS, S, M, L), the **shape** it needs (none, a plan or a spec), a suggested **assurance level** (L0 to L4), the **kind** (feature, bug, chore), plus risks and open questions.

What happens next depends on how the lane is picked (see [Lanes and gates](factory-lanes#how-a-lane-is-picked)):

- A **one-file change** (a short ask that names exactly one existing file and isn't risky) skips triage and goes to the lightest lane.
- A **confident accept** takes triage's lane with no person needed. You get 20 seconds' grace: *Building in Ns: change the lane to stop it*.
- An **unsure or rejected** idea waits for you: *Triage done: your call* or *Needs more information*. Open it and choose **Accept as ‹lane›**, **Needs info**, **Reject**, or **Run triage** again.

Rejected ideas leave the line as *Rejected at triage*.

## Shape

The work is written down before any code: a **plan** for the Standard lane, a **spec** for the Assured lane, nothing for Express. The planner drafts it; a person approves it in **Planning**.

- **A plan** is a versioned document (v1, v2…) you can edit, comment on and approve.
- **A spec** has phases: **Requirements** (what and why, written as testable behaviour), **Design** (how, with the invariants that must always hold) and **Tasks**. Which phases are needed depends on the level: tasks only at L1; requirements and tasks at L2; all three at L3 and L4. Each phase is drafted and approved in turn.

| Status | Meaning |
|---|---|
| *Drafting the plan* | The planner is writing it. **Stop and redraft** lets you redirect it. |
| *Plan waiting for your approval* | Read it in Planning and approve it (or ask for changes). |
| *Requirements waiting for your approval* | Same, for the spec's current phase (Requirements, Design or Tasks). |
| *Spec draft failed: retry* | Press **Draft** to try again. |

See [Specs and plans](specs-and-plans).

## Build

An agent builds the change in its own git worktree, so your checkout is untouched. There are two ways to build, set per lane:

- **Sandboxed run** (Express): a throwaway worktree, a kernel sandbox, and a network proxy that is the only way out. Nobody is asked anything: an action that would need your yes goes ahead only if its effect stays inside the sandbox. Anything that would reach outside (a push, a deploy, a write outside the run) is held for your review, never run. See [Automated runs](automated-runs).
- **Chat in a worktree** (Standard, Assured): a normal Warden chat you can open, watch and steer. A plan is built with `/implement-plan`; a spec is built phase by phase, a new chat per phase.

| Status | Meaning |
|---|---|
| *Ready to build* | Press **Start build** (lanes that start by themselves don't wait here). |
| *Agent is building* | Open the chat to watch or steer it. |
| *The agent needs you* | The agent asked a question or an action needs your yes. |
| *Sandboxed run needs review* | An unattended run held an action that would escape the sandbox. Approving replays it in a chat you watch. |
| *Build started, no commits yet* | The chat is running but hasn't committed. |
| *N of M phases built: next phase ready* | A spec build between phases. **Start the next phase** carries on. |
| *Held by policy: …* | A rule stopped the build from starting. See [gates](factory-lanes#gates-your-rules-at-every-step). |

### Custom steps

Your own stages, added with **+ Add a step**: a skill, a workflow, a command, an agent prompt, or an adversarial review. A step can run by itself or wait for a person to run it, block the line (required) or just report (advisory), and apply only to some lanes. A step placed after Main waits for the merge.

## Review

Two checks can run here, depending on the lane:

1. **Review against the original ask** (on for Assured, and for any lane from L2): a fresh, read-only reviewer that never saw the build chat compares the change with the original ask and the approved plan or spec, and marks each requirement met or not. Gaps go back to the build chat automatically, up to two rounds.
2. **The lane's review**: by the **policy engine** (Express: Warden runs the assurance checks up to the lane's level, then asks your rules whether this change may proceed unattended) or by **a person** (Standard, Assured: **Approve the change**, with **Review the change** for the guided walkthrough and **Verify** for the assurance checks).

| Status | Meaning |
|---|---|
| *Policy is reviewing the change* | Express: checks are running. |
| *Ready for your review* | A person's review is waiting. |
| *PR #n open* | The change is in a pull request. |

See [Review, pull requests and merge](factory-review).

## Main

The change reaches your default branch: merged locally, or through a pull request. An item counts as merged when the default branch contains its branch head or its pull request is merged. A squash merge done on GitHub is detected too.

| Status | Meaning |
|---|---|
| *Ready to merge* | Press **Merge**. |
| *Merging when policy allows* | An automatic merge is waiting for your rules to allow it. |
| *Opening a pull request* | The lane delivers through a PR. |
| *Merge PR #n* | The PR is ready; a person merges it. The Factory never merges a PR by itself. |
| *Merge failed: see why* | For example a conflict, or the checkout is on another branch. |

After a merge, Warden removes the worktree and tidies the branch.

## Staging and Production

Environments are **observed, never driven**: the Factory never deploys. For each environment you define **Shipped when**:

| Rule | The change has shipped when… |
|---|---|
| **A branch contains it** | `origin/<branch>` (else the local branch) contains the commit. |
| **A matching tag contains it** | A tag matching your pattern contains the commit. |
| **A GitHub deployment succeeded** | The latest successful GitHub deployment for that environment contains it, optionally filtered by ref or workflow. |
| **Not defined yet** | The stage is skipped and the tile offers **Define**. |

The tile shows what is **Now on** the environment and how many commits are waiting **To ship**. A local merge doesn't push, so a change only reaches Staging once main reaches the remote.

## Shipped

Every stage that applies to the item is done. Shipped items stay visible for 14 days.

## When something goes wrong

- **Every automatic action runs at most once per item per commit.** A failure stays on the item (*…failed: retry*) until a person retries it. It clears when the branch moves or a later decision supersedes it.
- **Every item has a chat.** Double-click the row, or press **Chat** in the item's drawer, to talk to the agent about it.
- **Other controls** in the drawer: **Change lane** (until the build starts), **Send back to the agent**, **Move to review as it is**, **Park** and **Unpark**, **Remove**, and **Remove and clean up** (also deletes the worktree and branch).