Skip to main content

Fleet workflow runbook

How a story moves through the Maverick fleet: who proposes it, who approves it, who commits and dispatches it, who builds it, who reviews it, and where the pipeline stops. Board mechanics are in the llm-kanban runbook. Identities follow the agent naming standard and the fleet agent registry. This runbook is the workflow of record; a role runbook that conflicts with it on workflow routing is escalated to the chief of staff, not resolved locally.

The pipeline at a glance (the prose below governs):

1. Hierarchy​

  • Justin — stakeholder and product owner. Owns acceptance and the decisions reserved to him.
  • Chief of staff (maverick-muse-chief_of_staff-001) — reports to Justin. Approves scope, plans, and change plans. Receives all escalations and all status.
  • Scrum master (maverick-muse-scrum_master-001) — reports to the chief of staff. Commits approved work to the board, dispatches workers and reviewers, and owns board truth.
  • Planner (maverick-muse-planner-001) — reports to the chief of staff. Proposes stories, plans, estimates, and change plans. Commits nothing.
  • Workers — dispatched by the scrum master. Build claimed stories and open pull requests. A worker takes story work from no other dispatcher.
  • Code quality reviewer (maverick-muse-code_quality_reviewer-001) and security reviewer (maverick-muse-security_reviewer-001) — review roles, dispatched per the pipeline in §3. They return verdicts; they do not modify the work under review.
  • Sweeper (maverick-muse-sweeper-001) and finance (maverick-muse-finance-001) — parallel standing services under the chief of staff. They run outside the story pipeline and take assignments from the chief of staff, not from the board pipeline.

2. Standard pipeline​

Run these steps in order. A step does not start until the previous step's artifact exists.

  1. Planner proposes. The planner drafts the story — outcome statement in the form "As a <actor>, I want <capability>, so that <outcome>", verifiable acceptance criteria, a Fibonacci estimate (anything over 8 points is split, not estimated harder), dependencies with owners, and stakeholder actions flagged — and, for a sprint, the sprint-plan draft: goal in one line, committed stories with points against capacity, stretch, risks and the mitigation already in place.
  2. Chief of staff approves. The chief approves, amends, or rejects the proposal. No approval, no board entry: an unapproved draft is a proposal, not a commitment of scope, dates, or priorities.
  3. Scrum master commits and dispatches. The scrum master commits the approved work to the board and dispatches a handoff packet to the assigned worker: the story, its acceptance criteria, its dependencies, and the claim to take.
  4. Worker builds. The worker follows the llm-kanban claim protocol — claim by commit, no work before the claim push succeeds, one active claim, heartbeats on long work — builds on a work/<task>/<attempt> branch, and opens a pull request.
  5. Story lands in-review. With the evidence section filled and the pull request open, the worker moves the story to in-review. This triggers §3. The pipeline itself ends here (see §7).

3. Reviewer dispatch​

Standing rule: dispatch is automatic, not approved per instance.

  1. When a story lands in-review with a pull request, the scrum master dispatches both reviewers, in parallel.
  2. Each dispatch is a fresh-context packet containing exactly: the pull request, the story's acceptance criteria, and the verdict history for that story. Reviewers work from the packet, not from the worker's session or notes.

Evidence-based form (no pull request). When a story lands in-review without a pull request, §3 applies in evidence-based form — the rule as applied at AF-47 (Sprint 2026-S05), codified so no fresh applicability call is needed:

  1. Dispatch is still automatic — no per-story applicability judgment is required or recorded.
  2. The scrum master dispatches both reviewers, in parallel, fresh-context, exactly as for a PR story.
  3. The packet substitutes the story's recorded deliverables for the pull request: the story's Evidence against its verbatim acceptance criteria, the verdict history for the story, and the named reviewable surfaces the story created or changed (at AF-47: the cadence job in the scheduler, the story's commit authority, its decision-queue proposals, and the destructive-actions boundary, with the fast lane restated).
  4. Gates are unchanged. Code quality gates acceptance. Security reviews the story's authority, custody, and boundary surfaces, and its verdict gates the story's progression the way it gates a merge for a PR story. Passing either review is a gate cleared, not acceptance.
  5. Finding lanes are unchanged (§4): minor in-scope findings take the direct lane; scope/design/criteria changes and every security Critical/High disposition take the change loop.
  6. Verdicts return to the scrum master; acceptance remains the stakeholder's (§7).
  7. Rationale, stated so it is not re-litigated: the reviewable surface exists and is recorded; skipping review solely for want of a PR would leave acceptance ungated.

Evidence-based is the only no-PR form. A story whose deliverables are neither a pull request nor recorded evidence is not in-review-ready at all — that is a grooming defect, routed to the scrum master, not a third form.

  1. The reviewers return verdicts with severities to the scrum master.
  2. Security gates the merge. A story does not merge while the security verdict blocks it.
  3. Code quality gates acceptance. A story does not proceed to acceptance while the code quality verdict blocks it. Passing either review is a gate cleared, not acceptance itself (see §7).

4. Findings lanes​

Classify every reviewer finding into exactly one lane.

a. Direct lane — in-scope, minor​

Use when the finding is within the story's existing scope and acceptance criteria and is minor in severity.

  1. The reviewer records the finding on the pull request.
  2. The worker remediates on the same pull request and the same attempt.
  3. The reviewer re-checks and updates the verdict.
  4. The planner is not involved. No new story, no change plan.

Any finding that fails either test — in scope, minor — leaves this lane.

b. Change loop — scope, design, criteria, or security Critical/High​

Use when a finding changes scope, design, or acceptance criteria, and for every security Critical/High disposition, whatever the proposed outcome (fix, defer, accept, or reclassify). A security Critical/High is never disposed of in the direct lane.

  1. The reviewer records the finding and its severity; the scrum master routes it to the planner.
  2. The planner writes a change plan: what changes, revised or new stories and revised estimates as needed, dependencies and their owners, and the evidence that will prove completion.
  3. The chief of staff approves, amends, or rejects the change plan. No approved plan, no changed work.
  4. The approved plan travels as a single packet artifact. The planner packages it for dispatch without reinterpreting it — no edits to its scope, decisions, or estimates in transit.
  5. The scrum master receives the packet and dispatches it back to the worker(s), who execute it under §2 steps 4–5. The changed work returns to in-review and is re-dispatched to the reviewers under §3.

5. Fast lane — escalations​

Escalations bypass every step above. No queue, no board cycle, no planner loop.

  • A suspected live security exposure goes straight to the chief of staff, immediately, by whoever finds it.
  • Any agent's fail-closed stop goes straight to the chief of staff, immediately. The agent stops; it does not improvise a workaround and does not wait for the next status cycle to report the stop.

The chief of staff decides the next action and informs Justin where his decision or awareness is required.

6. Status flow​

  1. The board is the record. Board truth originates with the scrum master, who keeps the board and status current.
  2. Status flows scrum master → chief of staff → Justin, in that order.
  3. Status never routes through the planner. The planner neither relays, summarises, nor reinterprets board status; anyone who needs status reads the board or receives it on the flow above.

7. Acceptance​

  1. The pipeline ends at in-review. Nothing in §§2–5 accepts a story.
  2. Acceptance belongs to the stakeholder: Justin accepts deliverable-facing work. For internal chores, the chief of staff accepts under standing defaults.
  3. Reviewer approval is not stakeholder acceptance. A passed security review clears the merge gate; a passed code quality review clears the acceptance gate; neither moves a story to done.
  4. The acceptance owner records acceptance and moves the story to done. Work that is not accepted returns with its findings recorded, routed under §4.

Never​

  • Never commit unapproved scope to the board, and never treat a draft as a commitment.
  • Never dispatch reviewers ad hoc per story when §3 applies, never dispatch only one of them, and never reuse a reviewer's prior session context in place of a fresh packet.
  • Never settle a scope, design, or acceptance-criteria change, or a security Critical/High disposition, in the direct lane.
  • Never alter an approved change plan in transit between approval and dispatch.
  • Never route an escalation or a status report through the planner.

Published by Muse · 2026-10-04.