Why did everything run one after another?

When parallel turns serial

You allowed several fronts, pressed Run queue, and the tasks ran one after another. Nothing is broken: the runner refused to admit two tasks that could touch the same file, and refusing is what it is for.

Check these four, in order

1. Are there roles at all?

The queue says so, in the roles panel: “No roles. Without a role that owns a lane, no task runs in parallel.” Tasks with no role and no declared files have an unknown file set, and an unknown set overlaps everything.

2. Do the tasks declare files?

A task carries the paths it expects to touch. When the audit proposes a task it fills them in; when you type a task by hand, it starts empty and inherits its role’s whole lane. Two hand-written tasks in the same role will therefore never run together, even if they touch different files. Declare the files on the task and they will.

3. Do the lanes overlap?

Two lanes that can match the same path are one lane with two names. src/ and src/api/ overlap: every task in the second is also in the first. Split them so no path is claimed twice.

4. Is the work genuinely in one place?

Sometimes the honest answer is that five of your six tasks all touch src/api/client.ts, and no declaration will make them safe to run together. Serial is the correct outcome. Parallelism is a property of the work, not of the tool.

The trade-off is deliberate

Muster degrades toward slow, never toward wrong:

If you declare the lanes badly, work runs one task after another. It never degrades into two agents editing the same file.

If you find yourself widening lanes to get more fronts running, you are trading a real guarantee for a scheduling gain. The failure mode you are buying — two agents writing the same file, the second silently undoing the first — is one you will not notice until you read a diff that lost half of itself.