12vectors / bench docs for 0.2-alpha
bench docs GitHub ↗
ConceptsClaiming a card

Claiming a card

Claiming is moving. Taking a card out of backlog/ or to-do/ towards work is the commitment, so that is where ownership is recorded: the board writes an **Assignee:** <name> line into the header, taken from this checkout's git config user.name — the identity git history already shows, no new concept. The first claim sticks: a card that already names an assignee keeps it when someone else moves it on. Walking a card all the way back to backlog/ clears the line — nobody holds it again.

The assignee is who launches agents on the card and whose judgment the review waits for. It gates exactly one thing — starting work, which another board refuses until you take the card over deliberately (see "State syncs; reactions don't"). Everything else is convention: reading, reviewing and moving are open to anyone, and git history is the audit.

Two consequences worth knowing:

With BOARD_COMMIT_MOVES on, board-made moves also commit themselves: the move and the claim land in one commit touching only that task file, messaged board: <number> → <stage> (<name>), staged by pathspec so unrelated staged work is neither committed nor unstaged (hooks are skipped — this is bookkeeping, not code). Pushing is not part of it: those commits sit on your local main until you push it (or until BOARD_SYNC pushes them — see below), which the PR guard above will tell you about if you forget. The setting is off by default: a single-player board neither writes nor clears the assignee and makes no commits, exactly as before, and tasks/ is committed by hand. The gate governs only whether a move writes the line — an Assignee: added to a file by hand is still read and shown on the card whether the gate is on or off.