Bug: /feature flow dispatches code-analyzer and architect in parallel; should be sequential #3

New issue

Closed

opened 2026-08-23 10:05:40 +00:00 by MillasAgent · 0 comments

MillasAgent commented

2026-08-23 10:05:40 +00:00

Owner

Summary

When /feature is invoked, the orchestrator (workspace/opencode/agents/orchestrator.md) dispatches code-analyzer (step 5) and architect (step 6) in parallel, in the same turn, without sharing context. This violates the architect's input contract (workspace/opencode/agents/architect.md line 31): An optional prior report from code-analyzer.

Reproduction

Invoke /feature <description> with any feature description.
Observe the orchestrator's task dispatch log: both code-analyzer and architect are dispatched in the same assistant turn with Task(...) calls in parallel.
The architect's prompt does not include the code-analyzer's output.

Expected

code-analyzer runs first; its output is appended to the architect prompt as input. Then architect runs.

Where the bug is

Two contributing factors:

agents/orchestrator.md steps 5-6 (lines 83-84) are listed as a numbered sequence with no explicit dependency language:
```
5. Invoke `code-analyzer` over the scope.
6. Invoke `architect` to produce an implementation plan: ...
```
The orchestrator can reasonably interpret numbered list items as parallelizable.
agents/orchestrator.md §"Universal rules" rule 3 (line 37) only mandates "in parallel" for reviewers:

"When two reviewers run in parallel, they must run as independent Task calls in the same turn. Do not pass the output of one to the other."
There is no analogous rule for non-reviewer dependencies. Rule 3 specifically targets the double-blind review and does not generalize.
agents/architect.md line 31 declares An optional prior report from code-analyzer as an input — but the orchestrator treated this dependency as ignorable. Either the orchestrator should have dispatched sequentially and passed the report, or architect's body should not have advertised the optional input if it isn't actually plumbed through.

Suggested fix

Either:

A. Make the dependency explicit in the orchestrator's workflow prose — change step 6 to: "Pass the code-analyzer's report to the architect, then invoke architect with that report as input."
B. Add a universal rule for non-reviewer dispatch: "If a subagent's body declares an optional prior report from another subagent, the orchestrator MUST dispatch the report's source first and append the report to the dependent agent's prompt."
C. Both.

I recommend C: (B) generalizes to other flows. /bugfix has a similar pattern at step 5: code-analyzer + architect collaborate to isolate the actual cause — vague about whether the dispatch is sequential. /code-review and /deep-analyze have the same shape (analyzer, then architect). All four flows need the same plumbing.

Evidence from this run

Branch feat/spec-installer (in progress, not yet pushed). The orchestrator's task trace for /feature spec_installer.md showed two Task(...) dispatches in the same assistant turn:

Task(subagent_type="code-analyzer", description="Analyze bundle for installer feature")
Task(subagent_type="architect", description="Architect installer feature plan")

Both fired in the same response. The user intervened to cancel the code-analyzer task and asked for this issue. This has come up more than once in past sessions — the user's words were "No es la primera vez que te lo explico."

Severity

Medium — wrong-order dispatch means the architect's plan may be uninformed by the analyzer's findings (current bundle structure, complexity, duplications, smells). The architect falls back to reading the code itself when no report is provided, which works but is wasteful and may miss things. Worst case: a plan that proposes changes incompatible with existing patterns the analyzer would have flagged.

## Summary When `/feature` is invoked, the orchestrator (`workspace/opencode/agents/orchestrator.md`) dispatches `code-analyzer` (step 5) and `architect` (step 6) **in parallel, in the same turn**, without sharing context. This violates the architect's input contract (`workspace/opencode/agents/architect.md` line 31): `An optional prior report from code-analyzer.` ## Reproduction 1. Invoke `/feature <description>` with any feature description. 2. Observe the orchestrator's task dispatch log: both `code-analyzer` and `architect` are dispatched in the same assistant turn with `Task(...)` calls in parallel. 3. The architect's prompt does not include the code-analyzer's output. ## Expected `code-analyzer` runs first; its output is appended to the `architect` prompt as input. Then `architect` runs. ## Where the bug is Two contributing factors: 1. `agents/orchestrator.md` steps 5-6 (lines 83-84) are listed as a numbered sequence with no explicit dependency language: ``` 5. Invoke `code-analyzer` over the scope. 6. Invoke `architect` to produce an implementation plan: ... ``` The orchestrator can reasonably interpret numbered list items as parallelizable. 2. `agents/orchestrator.md` §"Universal rules" rule 3 (line 37) only mandates "in parallel" for reviewers: > "When two reviewers run in parallel, they must run as independent Task calls in the same turn. Do not pass the output of one to the other." There is no analogous rule for non-reviewer dependencies. Rule 3 specifically targets the double-blind review and does not generalize. 3. `agents/architect.md` line 31 declares `An optional prior report from code-analyzer` as an input — but the orchestrator treated this dependency as ignorable. Either the orchestrator should have dispatched sequentially and passed the report, or architect's body should not have advertised the optional input if it isn't actually plumbed through. ## Suggested fix Either: - **A. Make the dependency explicit in the orchestrator's workflow prose** — change step 6 to: "Pass the code-analyzer's report to the architect, then invoke `architect` with that report as input." - **B. Add a universal rule** for non-reviewer dispatch: "If a subagent's body declares an optional prior report from another subagent, the orchestrator MUST dispatch the report's source first and append the report to the dependent agent's prompt." - **C. Both.** I recommend **C**: (B) generalizes to other flows. `/bugfix` has a similar pattern at step 5: `code-analyzer + architect collaborate to isolate the actual cause` — vague about whether the dispatch is sequential. `/code-review` and `/deep-analyze` have the same shape (analyzer, then architect). All four flows need the same plumbing. ## Evidence from this run Branch `feat/spec-installer` (in progress, not yet pushed). The orchestrator's task trace for `/feature spec_installer.md` showed two `Task(...)` dispatches in the same assistant turn: - `Task(subagent_type="code-analyzer", description="Analyze bundle for installer feature")` - `Task(subagent_type="architect", description="Architect installer feature plan")` Both fired in the same response. The user intervened to cancel the code-analyzer task and asked for this issue. This has come up more than once in past sessions — the user's words were "No es la primera vez que te lo explico." ## Severity Medium — wrong-order dispatch means the architect's plan may be uninformed by the analyzer's findings (current bundle structure, complexity, duplications, smells). The architect falls back to reading the code itself when no report is provided, which works but is wasteful and may miss things. Worst case: a plan that proposes changes incompatible with existing patterns the analyzer would have flagged.

MillasAgent referenced this issue

2026-08-23 12:31:02 +00:00

curl | bash fails: BASH_SOURCE[0] unset when piped from stdin #5

MillasAgent referenced this issue from a commit

2026-09-04 11:26:48 +00:00

chore(release): bump to 0.3.1 + document orchestrator dispatch fix

MillasAgent referenced this issue from a commit

2026-09-04 11:28:19 +00:00

fix(orchestrator): sequentialize code-analyzer→architect dispatch per Issue #3

MillasAgent referenced this issue from a pull request that will close it,

2026-09-04 11:30:50 +00:00

fix(orchestrator): sequentialize code-analyzer→architect dispatch per Issue #3 #8