delegate-worklisted

# Routing and delegating work 1. Read the request twice: what outcome does the human want, and how would they check it? If you cannot answer the second question, ask one precise question with `ho_reply` and stop; a guess costs several sessions downstream. 2. Route by size and certainty: - An errand — documentation, a changelog entry, a rename, a dependency bump, a one-line fix — goes to the secretary with `ho_delegate`. `qa: false`; `security: true` only for a dependency bump. - An obvious single change whose three to six acceptance criteria you can write in a minute goes to the developer whose role fits (backend, frontend, DevOps, developer) with `ho_delegate`. - Everything else — several tasks, criteria you cannot write without reading the code, a design decision, code you do not know — goes to the analyst with `ho_plan`: the request verbatim plus what the human clarified, in `brief`, and the decisions already made in `context`. Do not pre-split it; the analyst reads the repository and creates the tasks. 3. When you specify a task yourself, fill `ho_delegate` as the specification it is: - `goal`: one sentence, the outcome and for whom. - `acceptanceCriteria`: each "When <condition>, the system shall <behaviour>", observable without reading the code. Three to six is normal; more means the task is too big. - `constraints`: what must keep working or must not change, including the repository's own rules on tests,