Progress Board

Progress Board

The user should never have to ask "how's it going". A persistent, counted board in your responses gives ambient awareness at zero interaction cost.

The board shape

N tasks (A done, B in progress, C open)
◼ <concrete deliverable>          # in progress
◻ <concrete deliverable>          # open
…

• Counts up top: N tasks (A done, B in progress, C open). The delta from last turn is the real signal.
• Glyphs: ◼ in progress · ◻ open · ☑ done. Pick one set and stick with it.
• Collapse the tail: … +K pending when the board would exceed ~6 visible lines.

Naming rule — deliverables, not verbs

Bad (ambiguous "done"):

• Look at the data pipeline
• Fix routing

Good (unambiguous "done"):

• Build packages/data-ingest data-collection pipeline (OSS stack + fallbacks)
• Wire /v1/runs + /v1/data-ingest routers into api

A task is done when the named artifact exists and behaves as the parenthetical constrains it. If you can't phrase the task as a noun + scope + (constraint), the task isn't well-defined yet — refine before adding it to the board.

When to show the board

• At the end of a turn where you started or finished a task.
• When the user asks "what's the status" (then keep showing it on subsequent turns).
• When you're about to switch lanes — the board makes the switch legible.

When NOT to show the board

• Single-step tasks — a board for one item is noise.
• Pure conversational turns with no task progress.
• After every single trivial sub-step — the board tracks user-visible tasks, not internal ticks.

Update discipline

• Move a task to done only when the artifact exists and you've verified it (smoke-import passed, test green, file written, command succeeded). Not when you've "finished thinking about it".
• in progress rule: one active foreground ◼ at a time. A second ◼ is allowed only when it represents a backgrounded long-running operation (a multi-minute build, a long test run, a deploy) that you've parked while doing other work. Two active foreground ◼ means you're context-switching — pick one. When the background op finishes, immediately mark it done or re-foreground it; don't leave a stale ◼.
• If a task grows a sub-board, split it into its own task rather than nesting.

Phased variant — for a large feature

When a single task is large enough that "done" is far away, break it into numbered phases, each with a concrete deliverable, in dependency order, with the last phase explicitly the verify+report gate:

Phase 1: <investigation/audit> → <fixed doc path>
Phase 2: <design (shared vs local)>
Phase 3: <build shared primitive + primary wiring + sibling passes>
Phase 4: Verify, task done, readiness report

Rules:

• Numbered phases — the unit is a phase, not a sub-step.
• Each phase has a named deliverable, often a file path (docs/reviews/ui-ux-engagement-audit.md). A phase without a deliverable isn't a phase; it's a sub-step.
• Dependency order — audit → design → build → verify. A reviewer can read top-to-bottom and the story makes sense.
• The last phase is the gate — "Verify, task done, readiness report". The validate gate is built into the plan, not an afterthought.
• One ◼ per phase at a time (with the backgrounded-op exception above).

Use the phased board for features spanning multiple phases; use the flat board for ordinary multi-task work.