implementation-task-spec

# Implementation Task Spec ## Overview An implementation task is a self-contained unit of work for one developer role. The recurring failures are bundling two layers into one task and vague, untestable acceptance criteria. **Core principle:** One task = one role = one deliverable. ## create_board_task fields | Field | Value | |-------|-------| | type | `task` (or `bug` for defects) | | column | `backlog` by default (stakeholder reviews before start); `todo` only if told to start immediately | | assignee | one responsible developer role — REQUIRED: pass `assignee: "<role>"` (e.g. `backend-developer`) so that agent is dispatched. An unassigned task sits idle. Use `list_team` for valid names. | | title | action-object ("Add task export endpoint", "Fix checkout price rounding") | | description | PRODUCT only: user story ("As [persona], I want [capability], so that [outcome]") + context + out-of-scope + analiz reference if any | | technical_description | TECHNICAL only: endpoints/files/schema touched, approach, constraints, interfaces consumed and produced. BEFORE filling it, verify every file and endpoint name against the actual repository: `get_repo_tree` for the layout, `codebase_search`/`grep_code` for the handler/route/symbol you are naming. Never write a path or endpoint you did not see — an invented path sends the developer to a file that does not exist. | | acceptance_criteria | array of strings, one observable Given/When/Then per item, incl. error cases (see acceptan...