The step model

Each step has:

• Step name and Order. Order numbers must be unique and positive. A delivery starts at the lowest order.
• Performed by: Agent role, or Human gate. Requires a human to approve also makes a step wait for a person.
• Assignment (for Implement, Review and Custom): Fixed role (pick the Agent role), or Auto-route by task (the Plan step chooses the discipline per task).
• Action (what the step does):
  • Plan: the Engineering Lead turns the brief into a plan and decides which discipline the work needs. If the work spans disciplines, it can split it into sub-tasks. If nobody on the team has the needed skill, it asks a person.
  • Implement: an engineer codes on a branch and opens a PR (one per repo changed).
  • Review: a code review. Passing goes on; finding problems sends it back (on-failure). Auto-routed review uses the same discipline that implemented, or the Code Reviewer if nothing was routed.
  • QA: the QA engineer tests the change. Issues send it back.
  • Merge gate: a human step released when the delivery's PRs are merged.
  • Done: closes the delivery and moves its Jira issue to Done.
  • Custom: whatever you write in What should they do? (required for an agent step). The engineer says when it's done, doesn't apply (skip) or is blocked.
  • Full-lifecycle actions: Spec (Product Analyst: epic, stories, acceptance criteria), Architecture (Architect: decides whether a design doc/ADR is needed; skips if not), CI / quality (passes straight on if CI is green, waits if CI is running, sends the DevOps engineer to triage if red, and has DevOps check if there's no CI result), Security (Security Engineer; skips when there's no security surface), Docs (Technical Writer opens a docs PR; never blocks), Release prep (DevOps: release notes, version, deploy plan), Deploy (DevOps, with an Environment such as staging or production), Verify (SRE checks health after a deploy, with an Environment), Report (Delivery Manager writes a stakeholder report; never blocks), Sign-off (a human approval).
  • Write it to the repo as (Spec and Architecture, optional): a path such as docs/prd.md. The engineer opens a pull request with the document (merging it is the sign-off), publishes a copy to Confluence or Notion if connected, and every later step on the delivery is told to read it. Every step is also told what earlier steps reported.
  • Plan as stories (Plan): the lead writes each piece as a story (user story, acceptance criteria, tasks, dev notes citing the planning documents). Two or more stories become sub-tasks, each built, reviewed and tested on its own. One story goes to its engineer as part of the task.
  • Passed with concerns: a checking step (review, QA, security, CI, or a custom check) can pass with reservations. The delivery waits for a person with the concerns: Passed accepts or waives them (recorded under your name), Send back returns the work.
• Who gets the work (auto-routed Implement only): Backend work, Frontend work and Work spanning both. By default backend and frontend work go to the specialists, and spanning work is split between them. You can give any of these to the Fullstack engineer. If whoever you pick isn't hired, the other one takes it. If no specialist is hired for a kind of work, a hired fullstack engineer covers it. If nobody who can do it is hired, the step waits for a person.
• Who does this step / Backup (human steps) and Default engineer (AI steps).
• Routing: On success → (a step, or Complete pipeline), On failure → (a step, or Block & stop; on a human step, Block & stop still sends a send-back to the latest Implement before it), and On skip → for Architecture, Security and Custom steps (Same as on-success by default).
• Post progress to: Slack and/or Jira for this step. The portal's activity feed always records everything regardless.