/sprint-planner

name: sprint-planner
description: Use to convert the backlog into a runnable sprint with parallel ticket assignment and dependency tracking. Used primarily by the tech-manager. Triggers on "plan the sprint", "what does the pod do next", or as part of /app-build.

Sprint planner

Convert `docs/11-backlog.md` + `docs/22-impl-spec-*.md` into `docs/30-sprint-plan.md` and `docs/31-board.md`.

Procedure

1. **Read** the backlog and impl specs. Note ticket dependencies — if APP-002 needs APP-001's auth module, that's a dependency.

2. **Sprint goal** — one sentence at the top of `docs/30-sprint-plan.md`.

3. **Capacity** — default 3 developer agents (iOS, Android, optional Backend), 1 code-reviewer, 1 qa-engineer, 1 ux-architect, 1 product-designer. Tune to project scope.

4. **Assign for parallelism** — group tickets so each developer has independent work to start with. Stack dependent work behind it.

   Track A (ios-developer)  : APP-001 → APP-004 → APP-007
   Track B (android-dev)    : APP-002 → APP-005 → APP-008
   Track C (backend-dev)    : APP-003 → APP-006
   Continuous: code-reviewer, qa-engineer, ux-architect + product-designer (early)

5. **Board — create tickets through the CLI. Never hand-write the table.**

`docs/31-board.md` is a **generated view**. The source of truth is the append-only event log `docs/31-board-events.jsonl`, and `scripts/board.mjs` is its only writer. A ticket is created by:

   node "${CLAUDE_PLUGIN_ROOT}/scripts/board.mjs" add APP-001 \
     --title "Core todo store" --feature F-001 --owner android-developer \
     --depends APP-000 --estimate M --spec "prd#F-001 + arch§3" \
     --acceptance "Given the list, When I submit non-empty text, Then it appears at the top" \
     --notes "touches: data/TodoRepository.kt"

Each `add` appends a `created` event and re-renders the Markdown board with the same columns as before — `ID | Feature | Title | Owner | Reviewer | Status | Cycles | Depends on | Estimate | Spec | Acceptance | Notes`. Editing a cell by hand does nothing: the next render overwrites it, and no rule reads it back. `Reviewer` and `Cycles` are **derived**, not typed — the drift between a hand-edited `Cycles` cell and the ledger was a live defect, and derived-on-read cannot disagree with itself.

Field meanings are unchanged: `--feature` traces acceptance back to the PRD, `--spec` is a short anchor (`prd#F-001 + arch§3`) so devs don't grep, `--acceptance` is the Given/When/Then, `--notes` is free text only.

**`--estimate` also drives how much process the ticket carries** — see `process-tiering`. An XS/S ticket doesn't need the same ceremony an L/XL one does; if the track isn't the default (M/"standard"), say so explicitly in `--notes` (e.g. `"track: floor"`) so `tech-lead` and `code-reviewer` don't have to re-derive it.

6. **The event log — `docs/31-board-events.jsonl`, one JSON object per line, append-only.**

   {"ts":"2026-07-29T10:06:00Z","ticket":"APP-001","event":"review_requested",
    "by":"android-developer","detail":"-> code-reviewer","provenance":"cli"}

| Field | Meaning | |---|---| | `ts` | ISO timestamp, or `null` when a `migrate` could not reconstruct one | | `ticket` | the ticket ID; an event on a ticket with no `created` is refused | | `event` | one of the vocabulary below | | `by` | the role that did it — this is what makes self-review detectable | | `detail` | free text; an object on `created` (the ticket fields) and on `assigned` (`{to}`) | | `provenance` | `cli` for anything the tool appended, `inferred` for anything `migrate` reconstructed |

**Events:** `created · claimed · assigned · done_reported · verified · verified_static · rejected · review_requested · started · approved · changes · merged · qa_passed · qa_failed · blocked · unblocked · closed`

`verified_static` is the lane for work that is inspectable but not runnable (verify-done exit 2). Omitting it from this list is how DR4-002 stayed the documented rule: it unlocks review on a ticket whose toolchain is broken, refuses `closed`, and holds the release gate.

The state machine, enforced **before** the append — an illegal transition exits 1 and names what is legal from here, so these states are unrepresentable rather than detectable afterwards:

   todo --claimed--> in_progress --done_reported--> (verify) --review_requested--> review
                                                                                    |
                       done <--closed-- qa <--merged-- (merge gate) <--approved-----+

| Rule | The anomaly it makes impossible | |---|---| | `review_requested` needs a preceding `verified` | a `DONE` nobody checked reaching review | | `approved` must be `by` ≠ the owner | `self_review` | | `merged` needs an `approved` by a non-owner | `done_without_review` | | the 3rd `changes` is refused and forces `blocked` | `cycle_cap_breached`, and the column/ledger drift | | `claimed` is refused while a dependency has no `merged` | `stranded` — the silent one | | `blocked` recomputes readiness for dependents | dependents stranded by a mid-round block | | any event on an unknown ticket is refused | `malformed_row` |

Mutations during the sprint:

   board.mjs move APP-001 claimed --by android-developer
   board.mjs move APP-001 done_reported --by android-developer
   board.mjs move APP-001 verified --by verification-engineer --detail "verify-done.sh green"
   board.mjs move APP-001 review_requested --by android-developer --detail "-> code-reviewer"
   board.mjs move APP-001 changes --by code-reviewer --detail "docs/53-reviews/APP-NNN-cycle-N.md"
   board.mjs move APP-001 approved --by code-reviewer
   board.mjs move APP-001 merged --by tech-manager
   board.mjs show [APP-001] [--json]      # derived state + self-metrics
   board.mjs render