Lifecycle Diagram

Gemba Flow tracks work as beads — items in the local bd tracker whose state is computed from bead fields and labels, never from a column anyone moves. This page has two parts: the computed-state flow that governs a bead’s lifecycle, and the slash-command map that shows which commands belong to each delivery phase.

Bead computed-state flow

A bead moves through five states. State transitions happen via bd commands, label writes, and the worker’s git operations — not by dragging cards.

open ──(grooming completes DoR)──▶ ready* ──(bd update --claim)──▶ claimed
                                                                        │
                                                        PR opened: in-review + pr:N
                                                                        │
                                                      verified merge ──▶ closed (provenance reason)

* ready is computed, not a column. bd ready returns open + unblocked beads; that output is the outcome of grooming, never a target to optimize against.

Icebox state: a bead set to deferred exits the active flow and is excluded from bd ready until explicitly re-opened.

State definitions

open — filed and visible in the backlog. Not yet ready for work: may be missing a clear description, acceptance criteria, effort estimate, or dependency wiring.

ready (computed) — bd ready surfaces a bead here when: status is open, all dependencies are closed or absent, and grooming has completed Definition-of-Ready. Grooming completes DoR — it does not “move the ticket.” bd ready is mechanical, not editorial; consumers always filter --type=task (beads docs: grooming note in BEADS-CONVENTIONS.md).

claimed — a worker has taken atomic ownership: bd update <id> --claim. Only the claiming worker mutates the bead from this point. If a claim fails, the bead was already taken; select the next one.

in-review — the PR is open. The worker applies two labels after gh pr create: in-review and pr:<N>. The PR-open event is the operative signal; the label pair is the persistent source of truth (not a column, not a board state). Full conventions: BEADS-CONVENTIONS.md § Branches and PRs.

closed — issued only after gh pr view <N> --json state,mergedAt confirms the merge. A provenance reason accompanies every close. Workers never bd close; the orchestrator or human path closes after verified merge.

deferred (icebox) — a bead that is explicitly parked. Excluded from bd ready. Re-opening moves it back to open for the next grooming pass.

What changed in v1.6.0

Prior to v1.6.0, Gemba Flow used a GitHub Projects board with literal columns (Backlog, Ready, In Progress, In Review, Done). The board was the source of truth; agents moved cards. From v1.6.0 forward:

• The tracker is bd (beads). State lives in a local Dolt database; the board is a read-only HTML projection regenerated by hooks.
• Ready is computed by bd ready, not a column to move things into.
• Grooming completes Definition-of-Ready; it no longer mutates board state.
• gh project commands, the project PAT scope, and Closes #N PR citations are all retired. See the v1.6.0 release notes  for migration guidance.

For the full label vocabulary, branch/PR conventions, and mechanical-hygiene rules, see docs/BEADS-CONVENTIONS.md in the upstream repository.

Slash-command delivery phases

A Gemba Flow delivery cycle also maps onto six phases. The diagram below shows which slash command belongs to each phase. Read it left-to-right; phases execute in order, though Reflect (Phase 6) can happen after any phase when a session ends, and the Groom phase (Phase 3) recurs whenever bd ready drains below one or two tasks.

Phase callouts

The dashed arrow from Reflect back to Groom represents the recurring cadence: after each session the backlog is re-prioritized, bd ready is re-evaluated, and the next cycle begins.

See the Cheat Sheet for invocation syntax and a full per-command reference.