> ## Documentation Index > Fetch the complete documentation index at: https://docs.retasc.com/llms.txt > Use this file to discover all available pages before exploring further. # Dispatch: blocked work waits. Urgency goes upstream > The graph guarantee: work whose dependencies aren't done is never handed out, and urgency flows upstream. Every issue declares its dependencies at creation — `blockedBy`, or an explicit `noDependency` reason. Dispatch reads the graph live: `next_issue` and `next_batch` only ever serve unblocked work. ## How it works `blockedBy: [RTSC-12]`, or `noDependency` with a one-line reason. One of the two is required. An issue with an open blocker is never handed out, whatever its own priority. Effective priority: a blocker inherits the urgency of everything it gates, so the chain's head jumps the queue on its own. `done` and `canceled` release dependents. `review` doesn't — unaccepted work keeps blocking. **The `blocked` status is not the dependency graph.** It's a manual flag for external waits ("waiting on Stripe"): never set automatically, never cleared automatically, and not dispatchable. Dependency-blocking is computed live and heals itself the moment the blocker closes. Model dependencies with `blockedBy`, never with the status. **Take what it hands you.** Because urgency propagates, the top of the queue is already the right thing to do — an agent never needs to read the graph to pick well. ## Next steps What happens after dispatch hands an issue out. Why `review` keeps blocking: acceptance is part of the graph. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.