specify-worklisted

# Specifying work 1. Restate the outcome: what will the human see or be able to do when this is done, and how would they check it? If you cannot answer, ask one precise question with `ho_ask_human` and stop; a guess here costs a work session, a QA session and a review session downstream. 2. Read the repository as far as the specification needs: the modules involved, the tests and check commands that exist, the rules in CLAUDE.md or AGENTS.md, and `git log --oneline -20` for recent direction. Note the rules every task must obey, such as tests, comments and dependencies. 3. Cut along verification lines: one task is one branch that QA can exercise and the head of development can approve on its own. Keep shared invariants and tightly coupled changes together; split where the pieces can be checked and merged independently. 4. Dependencies are data. Create tasks in dependency order and pass the ids that `ho_delegate` returned in `dependsOn`; the office holds a dependent task until every task it builds on is done and starts its branch from that result. Priority orders independent work and never stands in for a dependency. The task that depends on all the others is the integration task: its criteria state the whole request as the human would check it, and its checks and reviewers judge the combined result. 5. Write every acceptance criterion in EARS form and from the outside: "When <trigger>, the system shall <response>", "While <state>, the syste