Lifecycle of an issue
This is the whole system on one page: a raw issue driven to a reviewed PR by a single comment. Every row is something you can actually see in the issue tracker — a comment, a label, a branch, or a PR.
Setup: issue #42 — “Add dark mode toggle” — with a two-sentence body. You comment /execute.
The timeline
Section titled “The timeline”| # | Actor | What happens | What you see |
|---|---|---|---|
| 1 | You | Comment on #42 | /execute |
| 2 | Security gate | Authorizes you before any feedback | (nothing — denied users get only a denial message) |
| 3 | Engineer | Claims the comment (issue isn’t a Task and has no Tactics:done) | 👀 on your comment; status comment posted |
| 4 | Engineer | Definition of Ready fails — no Design:done — delegates | Status edited: 🔁 not ready — delegated; Architect dispatched with chain engineer+execute |
| 5 | Architect | Designs (or revises) in the issue body; classifies Feature/Bug | Design:draft → issue body now holds the design → Design:done, label Feature; status ✅; you’re assigned |
| 6 | Architect | Continues the chain | Engineer dispatched with chain execute |
| 7 | Engineer | DoR passes now; plans | Tactics:crafting; task issues #43–#45 created, sub-issue-linked; waves + ## Progress appear in the tactical zone; Tactics:done; status ✅ |
| 8 | Engineer | Continues the chain | Maestro dispatched |
| 9 | Maestro | Creates pipeline branch + draft PR; dispatches wave 1 | Branch feature/42-add-dark-mode-toggle; draft PR; Work:orchestrating; comment: 🌊 Wave 1 of 2 dispatched |
| 10 | Developer ×N | Each implements a task in parallel | Per task: Work:coding → task branch → PR fixes #43 → auto-merged → task closed, Work:done |
| 11 | GitHub | Each merge into feature/* re-triggers the Maestro | Checkboxes tick in ## Progress; 🌊 Wave 2 dispatched when wave 1 completes |
| 12 | Maestro | All waves done — assembles the final PR | PR marked ready with Closes #43 #44 #45 #42 + a Work Log; reviewers = issue assignees; Work:done; comment: 🎉 All waves complete! |
| 13 | You | Review and merge the final PR | Everything closes via the Closes references |
Total comments from you: one.
Where state lives
Section titled “Where state lives”There is no hidden state — everything the pipeline knows is in your tracker and repo:
| State | Where it lives |
|---|---|
| The design | Issue body, above <!-- autoducks:tactical:begin --> |
| The plan (waves, progress) | Issue body, inside the tactical zone |
| Stage progress | Labels |
| Which tasks are done | Merged PRs into the pipeline branch (fixes #N) |
| Who owns the next action | The issue assignee (set at every stage completion) |
| Run history | The status comments, each linking its workflow run |
Because of this, an interrupted pipeline resumes by re-issuing the same comment — agents recompute everything from visible state, and idempotency guards make re-runs safe.
Variations
Section titled “Variations”- Bug instead of feature: the Architect labels it
Bug; the pipeline branch becomesfix/42-…. Nothing else changes. - Single-task plan: the Engineer skips child issues; the Maestro dispatches the Developer on #42 itself.
- You review between stages: run
/architect,engineer,executeseparately — the cascade only fills in stages you skipped. - The Engineer has questions: it posts them and stops the chain; answer in comments and re-run.