Verified end-to-end on the current head (6b8275818 — fix(core): harden swarm worker execution). Ran three scenarios against glm-5.1 with --core-tools swarm --output-format stream-json:

1. wait_all smoke (per PR description, 3 tasks × "Return exactly: X", max_concurrency=2)

• CLI init event: tools: ["agent","swarm","skill","ask_user_question","exit_plan_mode"] → swarm registered.
• tool_use input carried the full tasks array built at runtime (no predefined subagent config).
• Aggregated tool_result: Success: 3 / Failed: 0, num_turns: 2, ~18s total.

2. first_success early termination (max_concurrency=1, 3 tasks)

| one   | success     | one |
| two   | not_started |     |
| three | not_started |     |

Confirms shouldStopLaunching in runFirstSuccess blocks queued workers from launching after the first success, and that the aggregator correctly distinguishes not_started from cancelled.

3. per-worker timeout (timeout_seconds=1, prompts that force >1s output)

| slow-a | cancelled | Worker timed out after 1 seconds. |
| slow-b | cancelled | Worker timed out after 1 seconds. |

Confirms the setTimeout-driven abort in executeTask routes to status: 'cancelled' with the documented error message.

The two review comments from the earlier /review pass are addressed in 6b8275818:

• Scheduler no longer marks swarm as concurrency-safe; new should execute multiple swarm tools sequentially test locks in the behavior.
• Workers default-disallow ask_user_question via DEFAULT_WORKER_DISALLOWED_TOOLS, with coverage in swarm.test.ts.

The CodeQL "incomplete string escaping" alert is also resolved by switching escapeMarkdownTableCell to the | HTML entity (with a direct test assertion).

Unit tests pass locally: swarm.test.ts 6/6, coreToolScheduler.test.ts 66/66.

One non-blocking observation for follow-up: createWorkerConfig uses Object.create(this.config) to shadow a single method (swarm.ts:499-506). It works today but relies on prototype-chain impersonation — if Config ever adopts #private fields or this-sensitive caching, this path would need revisiting. A short comment documenting the invariant would help future readers.

LGTM.

Opening a discussion on how we handle larger community contributions going forward — using this PR as a concrete example, not to critique it specifically.

My main concern is design scrutiny. This PR adds ~900 lines introducing a new top-level core tool that overlaps meaningfully with our existing agent tool, and it landed without any design discussion on the linked issue or elsewhere. Questions I'd have expected us to resolve first:

• Should swarm be a separate tool, or a mode of agent? What's the long-term story for having both?
• How does it interact with the scheduler, nested agents, and tool filtering as a coherent system — not just "does the new tool work in isolation"?
• What's the contract we're committing to for users? New tool surfaces are hard to remove once shipped.

These are the kinds of questions a design doc or an issue thread surfaces naturally, and that an automated /review pass can't. I'd like us to adopt a convention: for community PRs that introduce a new tool or touch shared infrastructure, we align on the design first — on the issue, in a short doc, or in the PR description before implementation — and require at least one human review before merge.

Curious what others think. Not asking to revisit this PR; just want us to be deliberate about how new surfaces enter the codebase.

Thanks for raising this. I agree with the concern.

I initially treated the linked issue as a detailed feature proposal because it included pain points, requirements, examples, and acceptance criteria. In hindsight, I understand that this was not the same as explicit design alignment from maintainers, especially for a new top- level tool touching shared execution infrastructure.

I apologize for the extra review and discussion burden this created. As an external contributor, I am still learning the project’s expectations around larger design changes, and I appreciate guidance on the right process.

I also agree that for future changes introducing new tools or touching shared infrastructure, it would be helpful to have explicit human design alignment before merge, in addition to automated review.

Since this PR has already been merged, I am happy to help with whichever follow-up path maintainers prefer: revert/remove the tool and discuss the design first, gate it as experimental, reshape it as an agent mode, or add a design rationale documenting the intended boundary and user contract.

@wenshao 老师，原则上，我们不合并任何没有演示视频，没有产完整 E2E 测试的 PR ，同时也不能完全依赖 gpt-5.4 的review 能力，swarm agents 和 agent team 息息相关，是非常重要的能力，原则上也不接受社区 PR

@wenshao @reidliu41 我建议 revert 该 PR