Skip to main content

Issue States

See State vs Status for an explanation of the difference between state and status.

States

StateColorTerminalMeaning
NewGrayNoJust created, not yet started
ResearchBlueNoResearch stage running or pending
ImplementPurpleNoImplementation in progress
ReviewAmberNoAwaiting code review
ReworkRedNoReviewer requested changes
DeployGreenNoApproved, awaiting merge/deploy
CompleteTealYesDone — issue is closed

When an issue reaches Complete, isClosed is set to true and a closedAt timestamp is recorded. Issues in a terminal state cannot be transitioned to another state except by reopening (back to Implement).

Valid transitions

The table below covers human-initiated moves in the UI. Signal-driven jumps bypass this table — when a skill emits a flux:signal with hold/already_complete, the orchestrator calls stateOverride() directly and transitions the issue to meta.targetState regardless of whether that transition appears here.

FromToHow
NewResearchPipeline trigger or manual
NewImplementManual (skip research)
ResearchImplementResearch stage passes
ImplementReviewImplement stage passes
ImplementResearchManual
ReviewReworkReview stage fails
ReviewDeployReview stage passes
ReworkReviewRework stage passes
DeployCompleteDeploy stage passes
CompleteImplementManual reopen

Statuses

StatusMeaning
OpenActive, not currently running
QueuedIn the queue, waiting for the daemon to pick it up
RunningA stage is actively executing
BlockedNeeds human intervention (skill emitted blocked verdict or needs_human signal)
CompletedMost recent pipeline run finished

Status is set automatically by the daemon. It is not user-configurable.

Priorities

PriorityWeightMeaning
Critical100Highest urgency
High200
Medium300
Low400Lowest urgency

Lower weight = higher priority in queue ordering. The daemon picks up higher-priority runs first.