Working the board

A board is where work waits. Each item carries a markdown description — the
workspec — and that description is the work record, not a file somewhere in a
repository.

Items move through the stage column.

The stages

Parked sits off to the side rather than at the end. It is deliberate
deferral — work you are keeping but not addressing. Parked items sort below
Done and hide behind the same "hide finished" control, and they remember the
stage they were parked from.

Parking, and coming back

Resuming a parked item restores the stage it left. It also posts a warning, on
purpose: a plan written weeks ago describes a codebase that has moved. Treat a
resumed item as unplanned and scope it again before building. Automated
scoping and building both skip parked items for the same reason.

Filing good items

The workspec is read by an agent that has none of your context. That changes
what a good description looks like:

• Say what is wrong or wanted, not how to fix it. The plan comes later, from
  someone who has read the code.
• Name files and symbols if you already know them. It saves a search.
• Include how you would know it worked. An item with no observable outcome
  cannot be closed honestly.

Naming things

Boards and items have numeric ids, and those ids are internal keys. When you or
an agent reports work, the human name belongs alongside the id — item
#586 "An agent cannot see what it deployed", not #586. An id on its own
makes the reader go look it up.

Not everything needs an item

Small, single-session changes — a typo, a one-file fix, a config tweak — are
better done than tracked. Same discipline, tests and commits; no workspec, no
stage flips. Keep the board for work worth following.