Ask an agent working a Develosaur board why a task is at the top of the list, and it can answer with a reason, not a guess. That is only possible because there is no scoring formula deciding the order in the first place.
Four layers, in a fixed order
The ranked list is explicit ordering plus hard constraints, four layers deep, and every entry reports which one placed it there:
- Doing — anything IN-PROGRESS, at the very top, in pinned order.
- Overdue — past-deadline work, deepest-overdue first. This is a fact pulled from the calendar, not an opinion about importance.
- Pinned — the small, manually curated head. This is the only layer where work from unrelated branches can interleave; everything else respects the tree.
- Derived — everything left, walked depth-first over the tree in the same order the tree view itself shows, honoring sibling order.
A task pinned this morning outranks an entire untouched branch, because pinning is the one deliberate override. A task nobody touched just sits where its place in the tree puts it, ahead of its own later siblings and nothing else. An overdue task from a branch nobody is thinking about still jumps above ordinary derived work, because a missed deadline is a fact the list surfaces whether or not anyone asked it to.
One constraint holds regardless of layer: a blocked task never outranks its own blocker. Finishing the thing in the way is always the actual next step, even if the blocked task looks more urgent.
Three ways to move something, chosen by what you mean
- "I am working on this right now" — start it. This is the only sanctioned way into the doing layer, and it pins automatically.
- "One of the next few things, regardless of which branch it's on" — pin it, or reorder the pinned set. This is cross-branch interleaving, the one case worth agreeing on with whoever owns the board, since it reaches outside normal tree order.
- "Before its siblings, within its own branch" — move it ahead of them. This never needs anyone's sign-off; the derived tail just follows the new order automatically.
Pinning is a contiguous, small list by design, kept that way by the tool that manages it rather than by hand. Unpinning is not the same as deprioritizing: a node that drops off the pinned head falls back to wherever the tree already puts it, not to the bottom. Completing a task unpins it for the same reason a finished task should not keep occupying a slot at the top.
The objective is the coarse dial, the pinned head is the fine one
A tree with hundreds of tasks does not know what anyone is actually focused on this week unless something tells it. Declaring an objective names a branch, and the derived layer starts ordering everything under that branch before anything outside it, still in ordinary tree order, with no manual pinning involved. The pinned head still sits above it, so the sharpest priorities can still cut across branches even while the objective narrows the rest of the list to one area of work.
Every ranked entry under an active objective carries a reason line: which layer it came from, which objective it sits under, and which blocker, if any, is still in front of it. Nothing on the list requires trusting a black box; the reason is printed next to the task.
The board tells you when the list is untrustworthy
A pinned head can go stale the same way a to-do list on a whiteboard does. Develosaur surfaces this rather than hiding it: the current state of the head reports how many things are pinned, when it was last curated, and whether the active objective is still open, and says plainly when the head is empty or old enough to have been set for a different week. An agent reading a stale head is expected to say so before picking work off it, and to propose a new head or objective rather than quietly re-ranking things on its own. Only once you have actually named the goal does acting on it stop being a proposal and start being the expected next step.
That loop, propose unless directed, execute once directed, is what keeps the ranked list yours even when several agents are reading it unattended. It pairs with how those agents avoid colliding once they act on it, covered in Several agents, one plan. More on how the rest of the board's mechanics fit together is on the how-it-works page, and more of these are on the blog.