dispatch-worklisted

# Dispatch The practitioner has asked for work to be carried out by someone other than you. You brief one bounded worker from the authority the work already has; it authors a working tree and returns its result. A deterministic wrapper turns that tree into the draft pull request this convention returns — the worker opens none. Its exploration never reaches this conversation. A worker is a means, not a gate. You may carry out authorised work yourself: research it, design it, write the code. Reach for a worker when isolation, a particular model or harness, elapsed time, or keeping this context clean is worth the briefing. Either way the result goes to `evaluate-work` before the practitioner is asked to accept it — working directly changes no evaluation rule. ## The bounded task is the authority the work already has A dispatch carries an outcome, a boundary, constraints and proof. Where those live depends on what the work is, and you take them from exactly one place, mechanically: - **Live work with no item** — the outcome and boundary the practitioner established in this collaboration. Write them into the briefing, since there is no file for the worker to read. Do not create an item so the dispatch has one: an item exists because they admitted it (`capture-work`). - **An item running no phases** — its brief has no Phases section, so `.remit/<slug>/brief.md` and the authoritative content it links to are the whole of it. That brief is the worker's task and its limit.