shafthq / kanban

Kanban task flow

Use when work has more than one deliverable, more than one ticket, or any
delegate. Flow beats busyness: finish before starting.

Board

Keep one board per task as JSON (models corrupt JSON less than prose) in the
session state directory, never in tracked files:

{"wip": {"doing": 1, "review": 2},
 "cards": [{"id": "T1", "title": "...", "column": "ready",
            "acceptance": ["..."], "proof": "command that proves it",
            "evidence": null, "pr": null}]}

Columns: backlog -> ready -> doing -> review -> done.

• ready requires acceptance criteria and a proof command. No criteria, no pull.
• doing WIP 1 writer per repository: one card being edited at a time.
• review WIP 2: at two cards waiting for review or CI, pull nothing new.
• done only when the Definition of Done holds.

Pull rule

Every session, turn, and wake starts by draining right to left: open PRs and
review (red or ACTION_REQUIRED checks, behind base, conflicts, review
comments, auto-merge off), then doing, then shipped bugs or red default
branch. Pull a new ready card only when nothing downstream is actionable, and
only while review has capacity; waiting on CI counts as idle. Never leave a
started card to start another. Never push work forward. Group related cards
into the fewest safe pull requests. Avoid PRs that depend on other open PRs;
land them in order and merge base once before the final push.

Definition of Done

A card is done when all hold:

1. Every acceptance criterion is met and its proof command output is attached.
2. Tests for new behavior were red first, then green.
3. One fresh-context review is clean; a second round only for blocker findings.

4. Required checks are green on the exact head after one blocking wait per push
   (gh pr checks --watch --fail-fast or gh run watch); retry once, then stop
   and report. Never re-verify what already passed.

5. Every finding raised while working is closed (see below), including
   static-analysis and code-quality review threads (fix or reply, then resolve)
   before the PR counts as ready.

6. Merged or handed off as instructed; worktree cleaned.

7. After any CE harness change merges, every agent and delegate reloads the
   latest harness from main before continuing. After each completed delivery
   run python3 .chaos-engine/tool.py maintain (fast-forward with local edits
   kept, reinstall, doctor, stale-store refresh, reload).

8. Ship to-deliver items in the fewest pull requests; group related issues.

Check items 2 and 4 plus labels and links with python3 .chaos-engine/tool.py dod <PR> ([`dod.py`](../../dod.py))
(table; exit 1 names each gap).

Findings policy

Every finding ends as exactly one of:

• fixed in the current delivery, or

• filed as an issue, allowed only when it is both outside the task's scope
  and not critical, blocker, or high severity.

Nothing stays only in chat, a report, or a local file. The final report lists
each finding as fixed (with PR) or filed (with issue).

Waste checklist

Before each pull, drop anything that is partially done work, extra process,
extra features, task switching, waiting, handoffs without context, or defects
passed downstream (Poppendieck's seven wastes).

Status

Every status report is a Markdown table, one row per card
(ID | Issue(s) | PR | Status | Proof or blocker), then Risks. Never prose or
bullet lists. No separate status rituals. Report only rows that changed since
the last report; say nothing when nothing changed.