tddlisted

# TDD Red, green, refactor — in vertical slices, against behavior. As the worker skill it owns the issue transitions `/triage` never makes: `in-progress` when work starts, `done` when it's verified. ## Picking up the work When the task cites an issue (an `ISSUE_xxxx` ID or a GitHub `#n`), resolve it through the configured backend (`[tool.patdhlk-skills]` in `ubproject.toml`): - **sphinx-needs**: fresh needs.json (ADR_0006) → the issue's body, its `implements` links, and those requirements' shall-statements. The reqs are the acceptance criteria. - **github**: `gh issue view` → body, plus the need IDs from its `Implements:` line, resolved against needs.json the same way. Set the issue `in-progress` before the first test (local: edit `:status:` + strict gate; github: swap the state label). No cited issue → work from the conversation; the loop below is unchanged. ## The loop — per slice Slice the work vertically: each slice is one behavior a user (or caller) can observe end to end — never "the models, then the handlers, then the UI". 1. **RED** — write one test for the next behavior. Run it. Watch it fail, and fail *for the right reason* (asserting the missing behavior, not a typo). A test you never saw fail proves nothing. 2. **GREEN** — write the minimum code that passes. Resist building ahead of the test. Run the whole suite, not just the new test. 3. **REFACTOR** — with everything green: remove duplication, name things after the domain (the glossary'