acceptance-criteria-gwt

# Acceptance Criteria (Given/When/Then) ## Overview Acceptance criteria are the contract QA tests the product against and the PM verifies at UAT. If a criterion isn't executable, it can't be verified — and unverifiable criteria are where defects hide. **Core principle:** Every criterion is an observable behavior QA can execute with a command or a click path. No aspirational adjectives. ## The shape `Given [precondition], When [action], Then [measurable result].` ## Where they go Criteria live in the board task's own `acceptance_criteria` field — an array of strings, one criterion per item, passed to `create_board_task` (or `update_board_task` to replace the whole list). Each item becomes a checkbox the implementer ticks with `set_criterion_completed`, and that QA (in ready_for_qa/in_qa) and you (in pm_uat) then rule on independently with `review_criterion`. The tick is the implementer's claim; the verdict is the proof, and only reviewers can record one — QA and PM do not hold `set_criterion_completed`. Never write them into `description`. A criteria block pasted as markdown leaves the task's checklist empty: nothing to tick, nothing the move guard can check, and the prose copy goes stale the moment the real criteria are edited. ## Never a criterion: board actions A criterion states what the finished WORK is, never what the board does around it. These are not criteria and the tools drop them: | Not a criterion | Why | Write instead | |---|---|---| | "Task moved to r...