代码审计与优化编排器是做什么的？

概述

当被调用或进行代码库优化/安全审计时，担任首席软件架构师与主编排器的角色。

您的职责是将复杂的审计目标分解为并行的侦查任务，协调领域专家子代理，解决冲突的权衡（例如，性能 vs. 安全性），并在提交更改前确保确定性验证。

1. 治理与模型分层

为保留推理能力并防止令牌膨胀：

主编排器（主会话 - 前沿模型：Argon 4 / Opus）： 负责架构规划、专家委派、权衡决议与综合。切勿在此会话中直接执行宽泛的目录grep、原始多文件读取或终端垃圾命令。
专家侦查员（invoke_subagent 搭配 TypeName: 'research', Model: 'flash'）： 执行隔离的、只读的静态检查、文件映射以及漏洞/瓶颈发现。
执行工作者（invoke_subagent 搭配 TypeName: 'self', Model: 'pro'）： 实施精确的代码编辑，运行确定性测试套件，并验证零回归。
确定性门禁： 所有更改必须通过Linter、静态分析脚本和单元测试套件的验证。

2. 阶段 0：确定性预侦查

在生成子代理之前，运行确定性侦查脚本，以近乎零令牌成本映射仓库大小、文件扩展名、前端存在性（HAS_FRONTEND）以及超过500行的热点文件：

通过 run_command 执行 ./scripts/quick_recon.sh，并将 Cwd 设置为目标仓库根目录。
检查输出中的 HAS_FRONTEND=true|false 标志和热点列表，以配置阶段1的侦查员。

3. 阶段 1：并行侦查

在审计仓库时，在单个 invoke_subagent 调用（TypeName: 'research', Model: 'flash'）中并发启动专门的只读侦查员：

始终启动子代理 A、B 和 C（Scout-Perf，Scout-Sec，Scout-Arch）。
当且仅当阶段0报告 HAS_FRONTEND=true（或用户明确要求UI/前端审计）时，才启动子代理 D（Scout-UI）。

每个侦查员在其独立的上下文窗口中执行。指示每个侦查员遵循严重性定义，并返回仅一个紧凑的执行摘要表（最多15行，每个P0/P1发现问题最多附带3行证据），该表需符合 ./references/schemas.md 中定义的专家执行摘要表模式。

子代理 A：`Scout-Perf`（性能与资源效率）

范围：
- 数据库查询（N+1查询、未索引的过滤器、缺少连接池）。
- 内存占用（无界缓存、监听器泄漏、大型内存缓冲区）。
- 事件循环/并发瓶颈（异步例程中的同步I/O、未批处理的API/网络请求）。

子代理 B：`Scout-Sec`（安全、认证与不变量加固）

范围：
- 输入清理与注入向量（SQLi、XSS、SSRF、命令注入）。
- 密钥、凭据泄露和不安全的加密默认值。
- 认证/会话逻辑（损坏的对象级授权、缺失角色检查、不安全的反序列化）。

子代理 C：`Scout-Arch`（代码质量与技术债务）

范围：
- 高圈复杂度（>15）和臃肿的神级函数。
- 循环依赖、泄漏的模块边界和死代码。
- 不完整的错误处理和脆弱的类型不变量。

子代理 D：`Scout-UI`（前端、可访问性与渲染工艺）

（条件性：仅在阶段0输出 HAS_FRONTEND=true 时生成）

范围：
- 渲染与核心网页指标（CWV）： 客户端请求瀑布流、不必要的全子树重渲染、未虚拟化的大型列表、布局偏移（CLS）触发器和缺少 content-visibility / 图片尺寸设置。
- 可访问性（a11y）与语义： 缺少键盘/角色支持的交互式<div>/<span>控件、丢失的表单标签、模态框/弹出层中损坏的焦点陷阱以及ARIA误用。
- 现代Web与样式卫生： 可被原生HTML/CSS（<dialog>，Popover API，:has()，容器查询，dvh）替代的传统JS布局/滚动hack、绕过设计令牌的硬编码魔法颜色/间距，以及缺失的加载/空/错误状态。

[!IMPORTANT] 侦查失败/超时回退： 如果某个侦查员在大型单体仓库上失败或达到上下文限制，则重新调用它，但严格限定在阶段0识别出的顶级热点子目录范围内，而不是在主会话中进行广泛扫描。

4. 阶段 2：综合与权衡决议（主编排器）

作为主编排器，仅摄入阶段1的执行摘要表。

权衡仲裁协议：

当专家建议发生冲突时，使用以下权威指南进行解决：

安全性优先于性能： 如果某个优化削弱了输入验证、认证或令牌过期，则安全性胜出。仅当实现了明确的加密隔离和TTL失效时，才允许对经过认证的路由使用缓存响应。
可维护性优先于过早优化： 不要引入难以阅读的微优化或复杂的抽象，除非性能分析证明该代码处于已验证的热路径上。
可访问性与原生Web基元优先于JS微Hack： 切勿为了缩减字节而剥离语义DOM元素、焦点管理或ARIA属性；优先使用原生浏览器API（<dialog>，Popover，CSS过渡）而非自定义JS监听器。
P0/P1优先级门禁： 仅将即时修复重点放在严重（P0）和高（P1）问题上。将P2/P3项分组到“延期积压”部分。

阶段 2 交付物：

将综合后的修复计划持久化到 .audit/remediation_plan.md（或对话工件）中，详细说明：

目标文件及行号。
具体的架构修复方案和非重叠的文件所有权集合。
验证标准（测试命令、预期的延迟或内存减少量）。
规范移交（高工作量 P0/P1 项）： 对于涉及3个以上文件或更改模式/API的架构修复，在派发工作者之前，调用 spec-driven-feature 来起草 .specs/remediate-<ID>.md，并附上明确的文件修改边界矩阵。

5. 阶段 3：目标执行与确定性验证

对于每个已批准的修复项目：

限定范围的工作者派发：
- 启动一个执行工作者子代理（TypeName: 'self', Model: 'pro'），仅附带特定的目标文件、修复指令和验证命令。
- 前端现代化协同： 在派发工作者处理UI-*发现项时，指示工作者激活 modern-web-guidance 技能（如果可用），以便UI修复使用当前基线的HTML/CSS/JS API。
- 并发与沙箱保护： 如果两个工作者的目标文件集重叠，切勿在 Workspace: 'inherit' 下并发运行它们。将重叠的编辑分组到单个工作者中，通过 Workspace: 'share' 隔离，或通过 git-worktree-isolator 提供专用工作树。
验证循环：
- 工作者修改代码，并且必须运行确定性测试套件（例如，npm test，pytest，cargo test，linter）。
- 如果测试失败，工作者必须在本地最多迭代3次以修正问题。
- 安全的作用域回滚： 如果迭代3次后仍然失败，工作者必须回滚仅其目标文件（git checkout -- <target-files>），绝不能执行 git reset --hard，并向编排器报告确切的失败输出。
工作者返回契约：
- 工作者必须严格按照 ./references/schemas.md 中定义的工作者验证报告模式返回（git diff --stat 摘要 + 测试/linter通过确认）。请不要将几百行的原始统一差异粘贴到主对话中。

6. 令牌与Git卫生规则

切勿将完整的文件转储或原始统一差异管道回主聊天。 将完整分析保留在 .audit/remediation_plan.md 中并链接它。
修剪中间日志。 一旦构建了摘要表，就丢弃原始的grep输出。
清理Git状态： 确保 .audit/ 列在 .git/info/exclude 中或在提交前移除，这样审计临时文件就永远不会被提交到仓库中。
保持主对话聚焦于架构权衡、决策点和用户签署。

代码审计与优化编排器