Issue statuses

​

Definition

An Issue status is the durable signal for where structured work sits in its lifecycle. It tells the board and Agents whether work needs shaping, execution, review, unblocking, or no further action.

​

States

​

Constraints

• An Issue has one assignee. Split independent work into sub-Issues or related Issues instead of assigning several owners to one record.
• Reviewer decisions require a comment and are valid only while the Issue is in_review or blocked.
• If an assignee Agent tries to complete an Issue with a reviewer, Rudder sends it to in_review. Only an accepted reviewer decision can finish that path.
• done and cancelled are closed states. A comment can move either one back to todo only when it carries explicit reopen intent.

​

Boundaries

Status does not replace ownership, checkout, or Review. Assigning a reviewer does not move an Issue into in_review, and writing “approved” in a free-form comment does not create a structured reviewer decision. Use blocked for a concrete missing dependency, not as a general error bucket. Use cancelled when the work should no longer continue; it is not a substitute for done when a result has been accepted. Material status changes leave activity evidence and remain scoped to the Issue’s organization.

​

Examples

• A request without acceptance criteria belongs in backlog. Once the result is clear and an assignee can start, move it to todo.
• An Agent finishes a draft on an Issue with a named reviewer. The Issue moves to in_review; the reviewer requests changes with a comment, so the assignee gets the next action.
• Work cannot continue until a customer supplies a file. Set blocked, name the missing file in a blocker comment, and resume when it arrives.
• A request is withdrawn before an accepted result exists. Set cancelled; if the request returns, add a comment with explicit reopen intent to resume it in todo.