dispatch-weightlisted

# Dispatch weight You classify **the change that is about to be made**, on **one dispatch**, for **one specialist**. You do not classify the ticket, and you never set anybody's `model:`. The reasoning behind this rule — why step count and not token price sets the bill — is [`docs/shared/07-the-flows.md`](../../../docs/shared/07-the-flows.md), *Model escalation*. This file is the rule itself, so that every dispatch site runs the same one. --- ## The unit is a dispatch, not a ticket A track is dispatched more than once: the first pass, a re-pass for every `REQUEST CHANGES`, a drift fix after an alignment gate, a QA bounce-back weeks later. **Each of those is its own classification**, made from what that dispatch has to do — not inherited from the last one. A weight written once on a plan and reused is the common failure. It covers the first pass and silently misses every re-dispatch, and the re-dispatch after a failed review is the one that most needed it. --- ## The output One line, wherever the dispatching agent will read it: ``` weight: light | heavy — <the criterion that fired, in one clause> ``` The reason is not decoration. It is what makes the thresholds auditable later, and a weight nobody can audit drifts. Name the criterion, not the feeling: *"3 callers on a changed signature"*, never *"this looks tricky"*. --- ## Classify `heavy` when the dispatch - touches **more files than your threshold** — `<FILE-COUNT-THRESHOLD>`, - spans **more than one repo**, -