# File a milestone and see what still stands before it

**Name the goal, point the work at it, and "what is left before we get there" is a query rather than a list somebody keeps up to date.**

A goal is not work, and a tracker that models it as a container makes you pay for the difference twice: the epic sits in the backlog looking startable, and its progress is whatever somebody last dragged. A milestone here is a node like any other, of kind `project`, with one thing true of it — it carries no work, so nothing offers it as the next thing to do. Everything it waits on says so with the same `blocks` edge every other dependency uses, which means "what is still open before the launch" is the same question as "what is blocking this", asked of one node. Priority rides beside it for the tie a graph cannot break on its own: inside one wave every piece is equally startable, so the only thing left to sort on is what somebody asserted. `very_high` is the most important, and a piece nobody ruled on carries no priority rather than a level it never earned.

Driven by a person and an agent. Every step below is a step in
`packages/server/tests/e2e`, run against a listening server on every pull
request; the calls under each one are what that run executed.

The same flow is playable at https://flow.ttoss.dev/docs/examples/file-a-milestone.

## 1. Ana points her agent at the repository she works in

- `POST /api/v1/projects` → `201`

## 2. She files the launch itself as a milestone, not as work

- `POST /api/v1/tasks/batch` → `200`
- `GET /api/v1/tasks/task_80jygzzc0s` → `200`

## 3. Three pieces point at it, and the one that cannot slip says so with a priority

- `POST /api/v1/tasks/batch` → `200`
- `POST /api/v1/tasks/batch` → `200`
- `POST /api/v1/tasks/batch` → `200`

## 4. The milestone answers what is still open before it, by name

- `GET /api/v1/tasks/task_80jygzzc0s` → `200`

## 5. Asked what is next, the queue answers one piece: the one that cannot slip

- `GET /api/v1/next?tag=launch` → `200`

## 6. Asked for the whole queue, it offers the three pieces, the one that cannot slip first

- `GET /api/v1/next?tag=launch&limit=10` → `200`

## 7. The order keeps the goal out of the wave it would be picked up from

- `GET /api/v1/order` → `200`

## 8. A piece that turns out to be urgent is restated, and the queue reorders itself

- `PATCH /api/v1/tasks/task_eymxs4rgb0` → `200`
- `GET /api/v1/next?tag=launch&limit=10` → `200`

## 9. Finishing the last piece reaches the goal, and says so

- `PATCH /api/v1/tasks/task_pyj8w4ne9a` → `200`
- `PATCH /api/v1/tasks/task_k20dvpxsgp` → `200`
- `PATCH /api/v1/tasks/task_eymxs4rgb0` → `200`
- `GET /api/v1/tasks/task_80jygzzc0s` → `200`
- `GET /api/v1/next?tag=launch` → `200`