feat(fusion): the orchestrator plans and reviews, the workers do the work - #391
Open
plombeer31 wants to merge 3 commits into
Open
feat(fusion): the orchestrator plans and reviews, the workers do the work#391plombeer31 wants to merge 3 commits into
plombeer31 wants to merge 3 commits into
Conversation
…work Fusion's split has been advice since the mode shipped, and a capable cloud model handed a catalog of forty tools reads the twelve files itself and never fans anything out. A QA run showed exactly that: nine steps, twelve os.fs.read calls, zero delegations, every completion on the cloud model. So the first mutation of a fusion turn is now refused until the turn has delegated once. Read, plan, split, delegate — then the gate opens, because two things genuinely belong to the orchestrator afterwards: integration, which is a write, and anything a worker handed up because it needed approval, which workers cannot request. A refusal rather than a hidden descriptor: removing tools mid-turn rewrites the stable prefix and drops the session's KV cache, while a refusal costs one tool result and reads as an instruction. Same trade plan mode makes, and the same one fusion.delegate already makes for a worker that calls it. Read-only tools, the fan-out itself and the terminal verbs are never gated — planning is reading, and vetoing reply would veto the turn's exit. The guidance is rewritten around the loop it now enforces: plan in the open with the parts sized, one task per part in one call, briefs that stand alone, read every reply against its brief, merge yourself, and send rework back out instead of quietly absorbing it. Same prefix budget as before (1344 of 1400 bytes). A worker's own turn is never gated: the flag is per turn and skips ephemeral ones, so the hands the mode exists to free stay free.
A first live run on a cheap auto-routed model read the files, replied 'no edits were needed', and changed nothing. Stopping after the plan is the cheapest way to satisfy 'plan in the open', so the line now says the delegation belongs to the same turn.
The loop built the per-turn fusion context and handed it to the step executor, which builds the batch context and forwards `isPlanMode` — and nothing else. The gate was live, unit-tested and never consulted: a driven run in fusion mode wrote all four files itself with zero refusals and zero workers. Forwarded the three fields the same way `isPlanMode` travels, together so a context can never carry the flag without the ledger behind it.
This was referenced Sep 10, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fusion's division of labour has been advice since the mode shipped, and a capable cloud model handed a catalog of forty tools reads the twelve files itself and never fans anything out. A QA run on v0.5.6 showed exactly that: nine steps, twelve
os.fs.readcalls, zero delegations, every completion on the cloud model — with the orangefusionchip on screen the whole time.The gate
The first mutation of a fusion turn is refused until the turn has delegated once. Read, plan, split, delegate — then the gate opens, because two things genuinely belong to the orchestrator afterwards: integration, which is a write, and anything a worker handed up because it needed approval, which workers cannot request.
plan-mode.tsmakes, and the same onefusion.delegatealready makes for a worker that calls it.replywould veto the turn's exit.The loop, in the guidance
Rewritten around what the gate now enforces: plan in the open and delegate in the same turn, parts sized so a big one gets its own worker and small ones share, one task per part in one call, briefs that stand alone, read every reply against its brief, merge yourself, and send rework back out —
failed,needs_orchestrator, or anything you want refactored — instead of quietly absorbing it. Same prefix budget as before: 1397 of 1400 bytes.The "delegate in the same turn" clause is not decoration: the first live run of this branch, on a cheap auto-routed model, read the files and replied "no edits were needed" without touching anything. Stopping after the plan is the cheapest way to satisfy "plan in the open".
Verified
npx tsc --noEmitclean; new unit tests for the gate (7) and executor-level tests (5, including that a held-back call's slot is filled with the refusal rather than dropped, that reads pass through while planning, that the same call dispatches once the turn has delegated, and that nothing is gated outside fusion);src/promptandsrc/agentsuites green.