Run several delegations as one task graph

[Seungpyo1007]

Adds a layer above single delegation: a task graph.

Until now a delegation ran one at a time. There was no place to say "run A and B together, and when both finish hand their results to C" — the manager had to delegate, wait for the round to come back, read the results, and delegate again.

The engine

src/engine/orchestra.ts contains no Promise, no timer, and no await. It is a state machine the caller drives: ask what may start (ready), say it started (start), say it finished (settle). Every race is therefore reproducible in a test where no time passes, and the directory's import-zero rule holds.

The point of the layer is refusing to lose work:

• When a dependency breaks, everything waiting on it is closed with a reason, immediately. Direct cause (dep-failed) and knocked-over-next (dep-skipped) are distinguished, so one failure blocking twenty tasks still reports one cause rather than twenty.
• A task that ran but returned nothing is kept apart from one that succeeded. Dependents still proceed, but the report does not call it done, and the empty result is passed downstream as an explicit blank rather than dropped from the list — dropping it reads to the next agent as "that task never existed".
• A delegation that timed out is a failure. Letting dependents run on an answer that never arrived is worse than blocking them.
• A graph that does not hold together starts nothing. Half-running it and discovering the cycle afterwards cannot be undone. The cycle error carries the ids caught in the loop; an unknown dependency carries its name.

The tool

delegate_graph takes {id, agent, task, needs} entries. Results from earlier tasks are appended to the seed prompt of later ones automatically.

Two policy limits are relaxed inside a graph and one is not. Per-turn count and the duplicate-target ban existed to bound a model delegating without a plan; a graph is that plan, validated before it runs and visible on screen, so graph size (12) replaces them. Concurrency stays capped — that one is file locks and billing, not taste.

startDelegation returned only a rendered string, so a graph could not tell success from refusal. It now returns the outcome alongside the text, and refusals become failed outcomes that close dependents with a reason.

Found while probing the running app

Two tasks for the same agent ran concurrently (peak=2). Choosing a batch and dispatching it were separate loops, so an agent was marked busy too late and two tasks for it passed side by side within one batch. Overlapping makes the layer below refuse with agent-busy, and that refusal spreads as a failure — killing tasks whose only problem was ordering.

Unit tests cannot see this: Orchestra deliberately leaves concurrency to its caller, so a caller's mistake is invisible to Orchestra's own tests. Reproduced in the running app, fixed, re-confirmed.

Also

PlanResult uses a string discriminant rather than ok: boolean — the root tsconfig is strict:false, where a boolean union does not narrow and r.error fails to compile. policy.ts documents the same trap for PolicyDecision.

The orch dictionary is read by the model, not shown on screen. A missing key would send the raw key name as the result, and the manager would summarize that to the user — failure that does not look like failure. A test pins the keys, all four languages, and matching placeholders.

Verification

• 38 new unit tests (1171 total, up from 1133); typecheck clean under both tsconfigs.
• 14/14 in a CDP probe against the running app: fan-out then merge, results carried forward, concurrency cap, same-agent avoidance, failure cascade with reasons, cycle and unknown-dependency refusal, size cap, empty list, and no raw dictionary keys reaching the model.

The panel

Tool cards alone did not show what was waiting on what — five cards sit side by side, and a graph where one task killed the rest looks identical to one that was simply ordered that way.

planTasks now returns the waves Kahn's algorithm builds anyway rather than discarding them; order alone cannot express "run these three together, then this one".

The panel uses its own icon set rather than the plan panel's. Not-yet-run (○) and never-will-run (⊘) must not look alike, and ran-but-returned-nothing (◌) must not look like done. A blocked row carries what blocked it, inline — greyed out on its own, waiting and blocked read the same.

Starting a graph switches the left panel to the workflow tab. Opening a project leaves it on the tree, so without this the screen says nothing at all while several agents run. The demo path already does this for the same reason.

Five probe checks failed during this work and all five were the probe's fault, not the code's: the left panel was on the tree tab, and the selector matched the card's header rather than the card (the header also begins with the panel's label). Printing state.graph directly showed the wiring was correct and only the path to the screen was wrong.

Probe now at 18/18, including the tab switch — the probe no longer clicks the tab itself.