Context

People and coding agents share task lists (General and one per site). Some work has an order: a migration before the deploy that needs it. An agent working through a list has no way to know that, and claims whatever is free. Moving tasks between lists, added at the same time, means a task and the one it waits for can end up apart.

Decision

A task holds after, the ids of tasks in the same list to finish first (at most 20), stored as after_ids in the tasks table (migration 0009). Short Leash refuses a task waiting for itself, for a task that isn't in the list, or for one that already waits for it, however indirectly.

While any task in after is open, an agent's claim is refused with what it waits for (task_claim, leash task claim). People aren't stopped: the app says After "…" and still lets you tick it off. Deleting a task removes it from what others wait for. Moving a task to another list drops what it waits for and what waits for it in the old list, and the app says so before you save.

Consequences

Agents follow the order without reading notes; tasks_list shows after.
No links across lists: a site's task can't wait for a General one. That keeps ids meaningful (they're per list) and moves simple, at the cost of ordering work across projects by hand.
Ticking off out of order is allowed for people, so a list can say a task is done while one it waited for isn't.