Task Workflow
Every task in FlightDesk moves through the same pipeline: Backlog → Ready → Plan → Plan review → Build → Waiting → QA → Merge → Done, with an optional Release phase after the merge on projects that stage their releases (merged work waits there until a person ships the release; continuous projects record every merge as its own release). The phases are the same on every project. What a project chooses is where a person is needed — whether the plan is reviewed before Build, whether the pull request is reviewed before Merge, whether someone confirms the release — and whether FlightDesk dispatches an agent at each step or the phase simply follows GitHub.
Underneath the phase, a coding task also carries a run status. Most of its transitions happen automatically — FlightDesk listens to GitHub webhooks and the CLI to detect what's happening in real time — and on a project FlightDesk does not drive, the phase follows it.
The Phases
| Phase | What it means | |---|---| | Backlog | Asked for, not yet accepted. Work from an intake source lands here. | | Ready | Accepted and specified enough to start. | | Plan | A plan is being written. On an orchestrated project this dispatches a planning turn. | | Plan review | A person reads the plan and approves it. Skipped when the plan gate is automatic. | | Build | The work is being built. On an orchestrated project this dispatches a build turn. | | Waiting | Parked on something outside the work: CI, a review, a question, a dependency. | | QA | The pull request is open, CI is green, the agent says it is done — a person looks, on the preview, against the test plan. Skipped when the QA gate is automatic. | | Merge | The work is being landed. On an orchestrated project this dispatches a merge turn. | | Release | Merged, waiting for the release it was collected into to ship. Only on a staged project. | | Done | Shipped. |
Nothing moves backwards on its own. A person can move work between any two phases by hand — that is the escape hatch, and it is deliberately unrestricted — with one exception: a project that requires a plan will not let unplanned work jump from Backlog or Ready to Build.
What a Project Chooses
Five settings, under Project Settings → Orchestration. There is no per-project or per-organization status editor and no custom workflow builder: the phases above are the same everywhere.
| Setting | Options | Default | |---|---|---| | FlightDesk dispatches agents on this project | on / off | off | | Plan review | A person approves the plan before Build / A finished plan goes straight to Build | a person | | QA | A person checks the work on the preview before Merge / Green CI is enough; merge dispatches on its own | a person | | Releases | Staged: merged work waits at Release until a person ships the release / Continuous: every merge is its own release; merged means Done | continuous | | Every task needs a plan before work starts | on / off | off |
A gate set to automatic is not a phase that passes quickly — it is a phase the work never enters. With plan review automatic, a finished plan goes straight to Build.
Where a Turn's Outcome Lands the Work
On an orchestrated project, each agent turn reports an outcome, and that outcome decides the phase:
| Reported | From | Lands at |
|---|---|---|
| done | Plan | Plan review, or Build if that gate is automatic |
| done | Build or Waiting | QA, or Merge if that gate is automatic |
| waiting | anywhere before Merge | Waiting |
| failed or blocked | anywhere | nowhere — the work stays put and is flagged |
A human approval at a gate moves the work on: Plan review → Build, QA → Merge, Release → Done. A merge lands the work on Release on a staged project, or Done on a continuous one — and the merge webhook, not the turn that performed it, is what records it.
Run Status: the Secondary Concept
Underneath the phase, a coding task also carries a run status — what GitHub and QA have observed: PENDING, DISPATCHED, IN_PROGRESS, BRANCH_CREATED, PR_OPEN, PREVIEW_STARTING, PREVIEW_READY, REVIEW_RUNNING, REVIEW_DONE, QA_READY, QA_CHANGES_REQUESTED, QA_APPROVED, MERGED, ARCHIVED. Most of it is set for you: FlightDesk listens to GitHub webhooks and to the CLI.
Run status is not a second workflow. It matters in two places:
- On a project FlightDesk does not drive, nothing else moves the phase, so the phase follows the run status mechanically. A pull request opening puts the task in Build; review checks running put it in Waiting; a QA-ready or reviewed pull request puts it in QA; QA approval puts it in Merge; the merge puts it in Done. That is why a project you never configured still appears on the board in the same phases as everything else.
- As a filter.
flightdesk task list --status PR_OPENfilters on run status, not phase.
On an orchestrated project the phase is owned by the pipeline, and the run status is just the observation record.
Archived Tasks
Tasks can be archived at any point to keep your task list clean. Archived tasks are not deleted — they're still searchable and their full timeline is preserved. You can unarchive a task if work needs to resume.
Timeline
Every task has a timeline of events: phase and status changes, check results, preview events, questions and their answers, comments, and context updates. The timeline is append-only and provides a full audit trail of what happened and when.
See Also
- Pipeline and Gates — who a gate pages, how questions are routed, and what the task flags mean
- Agents and Orchestration — turning orchestration on, and handing locally built work over
- Initiatives and Releases — grouping work, and what shipped together