# Plan lifecycle

The five states a plan moves through, what moves it, and why you cannot set them freely.



A plan has a status, and it moves through five of them in order.

| Status       | What it means                                                         |
| ------------ | --------------------------------------------------------------------- |
| **Planning** | Being written. The conversation is live and Specs are still changing. |
| **Ready**    | You are happy with it. Nothing is pushed yet.                         |
| **Pushed**   | It has landed in your issue tracker at least once.                    |
| **Building** | Your team is working on it downstream.                                |
| **Done**     | Finished.                                                             |

## The transitions are managed [#the-transitions-are-managed]

You cannot jump a plan to any state you like. The order is enforced, which keeps the status
meaningful: a plan marked Building really has been pushed somewhere.

Two behaviours worth knowing:

* **Pushing moves the plan for you.** A plan in Planning or Ready becomes Pushed when you push it.
  You do not have to set it yourself.
* **Pushing never moves a plan backwards.** Re-pushing a plan that is already Building leaves it
  Building. A later push is an update, not a restart.

## Sub-plans have their own status [#sub-plans-have-their-own-status]

Each sub-plan moves independently. A parent plan sitting at Building can have one sub-plan already
Done and another still in Planning, and that is the normal shape of real work.

There is no automatic roll-up. A parent does not flip to Done because its children are; someone
decides that.

## What status does not do [#what-status-does-not-do]

Status does not gate anything. A plan in Planning can be pushed, and a plan in Done can still be
edited. It is a signal to your team about where the work stands, not a permission system.

For who can see and change a plan, see [Sharing a plan](/docs/sharing-a-plan).