Board Column Flow

Overview

The board has more columns than the PM acts in. Knowing which columns belong to the human, the architect, and QA keeps you from moving a task through a gate that isn't yours.

The columns

Two spines — a given task only passes through the columns its type needs:

task / bug:  backlog → todo → in_progress → code_review → ready_for_qa
             → in_qa → pm_uat → human_uat → done → released

analiz:      backlog → todo → in_progress → analiz_review → done → released

need_revision ← any gate that rejects (code_review, in_qa, pm_uat, human_uat, analiz_review)
              → back to in_progress' owner, then forward again from where it left

blocked ← parked here automatically while any blocked_by task is open
        → released automatically when the last one lands

task_type: "technical" (no user-facing behaviour) skips pm_uat — QA routes it straight to human_uat. need_revision is not a stage in the line — it is where every gate sends work back, and the PM is not dispatched there: act on a need_revision task only if the stakeholder raises it in chat. done → released is release-engineer's step, not yours.

Who owns each gate

Column	Owner	PM action?
backlog	PM	Yes — create tasks here by default; stakeholder prioritizes
todo	assignee agent (auto)	Move approved tasks here to start them
in_progress	developer	No
analiz_review	human	No — the human approves the architect's plan (→ done) or rejects it (→ need_revision)
code_review	system-architect	No — architect advances to ready_for_qa or need_revision
ready_for_qa	QA (queue — QA takes it into in_qa)	No
in_qa	QA (testing in progress)	No
need_revision	developer / architect	Not dispatched here; act only if the stakeholder asks in chat
pm_uat	PM	Yes — verify against AC by walking each flow yourself in the browser or on a device; QA's evidence is a cross-check, not a substitute (see pm-uat-review). Skipped for task_type: "technical".
human_uat	stakeholder	No — stakeholder reviews
done / released	—	Terminal; released per project convention, by release-engineer

PM action points (only these)

• backlog: create tasks here; the stakeholder reviews/prioritizes before agents pick them up.
• todo: move approved tasks here to trigger the assignee.
• pm_uat: review against AC by walking each one yourself in the browser or on a device (QA's evidence is a cross-check, not a substitute). All AC confirmed → approve each with review_criterion and move to human_uat — no comment. Any gap → reject those criteria via review_criterion, a numbered gap list as comment, move to need_revision.

Everything else (analiz_review, code_review, QA columns, human_uat) is another actor's gate — don't move tasks through them.

Common Mistakes

• Moving an analiz task out of analiz_review — that's the human's approval gate.
• Advancing a task in code_review — that's the architect's.
• Approving in pm_uat by reading code, or on QA's evidence alone, instead of walking the flow yourself.
• Acting on a need_revision task uninvited — you are not dispatched there.

Red Flags

• You moved a task through a column not in the PM action-points list.
• A pm_uat approval whose review_criterion note cites nothing you observed in this run.

Board mechanics

• Claiming a task and moving it between columns takes seconds and announces what you are doing; it produces nothing by itself. Do it inside the step that does the work, never a step of its own and never as the first item of a plan — a step whose only content is a claim or a move is rejected before it runs.
• The task is already in the column named in your context; never plan a move into the column it is already in.
• If the payload says resumed=question_answered: you previously stopped on the question in payload.question and the human replied in payload.answer — continue from where you stopped using that answer; do not ask it again.