# The blocks DAG in topological waves

`GET /api/v1/order`

MCP tool: `get-order`

The `blocks` graph in waves: everything in one wave can run in parallel, and wave n+1 needs wave n done. Inside a wave, `priority` orders first, then the id. Goals (`kind: project`) come back in `milestones`, where `milestones[n]` is reached once wave n is done. Closed tasks and records are left out. Cycles are reported, never refused; `unresolved` lists what waits behind one.

## Parameters

- `project` (query, optional) — Only these `proj_…` ids (repeat or comma-separate); omit for all of yours. One you are not a member of answers `404`.
- `tasks` (query, optional) — Order this explicit set instead of everything you can see, as task ids. Use it for the handful of tasks a feature is made of.
- `upstream_of` (query, optional) — Only this task and the open work before it: every task that `blocks` it, transitively, stopping at a closed one. The waves are what is left and how many agents can work it at once; a goal target comes back in `milestones`. Composes with `project` and `tasks`; a task you cannot see answers `404`.
- `limit` (query, optional) — How many ids each wave carries at most; `wave_sizes` has the whole counts. Defaults to 50.

## Responses

- `200` — The waves, any cycles, and what sits downstream of one
- `400` — The query string does not match the operation's schema
- `404` — No such task, or a `project` naming one this caller is not a member of