# dstalk 团队工作流（CEO 多代理协作模式） > 本文档供 CEO（主会话）和所有员工子代理参考。新会话恢复 CEO 模式时**第一件事**就是读这里。 ## 1. 编制与并行度 - **团队规模 = CPU 物理核数（dstalk = 16 人）**：1 CEO + 3 架构师 + 5 工程师 + 3 QA + 2 DevOps + 1 设计师 + 1 作家 + 1 安全 - 每个员工有 `agents//profile.md`：含 personality / background / strengths / weaknesses / performance_log - 单波并行子代理数：**6–9 路**（工作中员工占总人数 50–150%，即 8–24 路）。超过会上下文炸；少于 4 路浪费 CPU - 子代理调度：`Agent` 工具 + `subagent_type: general-purpose` + `run_in_background: true`，让通知机制驱动，**不要 poll** ## 2. 6 阶段协作流程 每个 Wave 都按这个流程： 1. **propose（提案）** — CEO 把需求拆成 N 个候选任务（`W.` 编号，如 W2.1、W9.4） 2. **vote（投票）** — 派 3–4 个子代理读代码独立评估、投票同意/反对/优化 3. **optimize（优化）** — 被反对的提案，提案方根据反对意见迭代 4. **integrate（整合）** — CEO 汇总成统一可执行计划 5. **execute（执行）** — 派对应专长的员工子代理实施 6. **CEO inspect（验收）** — `cmake --build build --config Release` + `ctest -R smoke`，0 error + 100% pass 才算过 简单任务可跳 2-4 直接 propose→execute→inspect。**有架构争议**的必须走完 6 阶段。 ## 3. 两级管理 - **第一级（CEO，最优先）**：CEO 决策优先于一切小组自治；CEO 验收是最终关卡 - **第二级（小组自治）**：`agents/groups/grp-*.md` 定义工作小组，组内事务自决 - 冲突时 **CEO > group lead > 个人** ## 4. 任务分发禁忌（每个 Agent prompt 必带） 派子代理时**必须显式列出**： - **可读的文件**（白名单） - **禁止碰的文件/目录**（防止与 in-flight 子代理冲突，例如 W7 改 smoke_test 时其他人禁碰 tests/） - **验证步骤**（cmake --build + ctest） - **报告格式 + 字数上限**（200–300 字典型） - **profile.md 更新要求**（每个任务必须追加 performance_log） 不写禁忌 → 多个子代理同时改同一个文件 → 冲突回滚 → 时间浪费。 ## 5. CEO 自查与验收节奏 - **每波结束**：跑一次完整 `cmake --build build --config Release` + `ctest -R smoke` - **预存 bug**：发现编译错时先 `git stash` 试 master 是否干净——区分"子代理引入"和"预存 bug"。预存 bug CEO 自己改不甩锅 - **stale obj 问题**：clang-cl 增量构建偶尔不识别源文件修改（lsp_plugin/tools_plugin 踩过坑），症状是编译报告的行号源码内容与磁盘不符。解法：`rm -f build/**/.cpp.obj` 强制重编 - **元数据完整性**：每波开始前运行 `python scripts/check_agents_metadata.py` 验证 agents/ 元数据完整性（YAML / rating / 引用一致性），0 error 才能进入执行阶段 - **CEO 验收通过后立刻 commit + push**（用户硬规则："别忘了每次通过ceo验收的提交git并推送"） ## 6. 关键技术约束（已踩坑，全员必读） | 约束 | 由来 | 文档 | |------|------|------| | 跨 DLL 堆纪律：插件不得用 `std::malloc/std::free`，必须 `host->alloc/host->free/host->strdup` | 陈风 W2.1 | `docs/reference/plugin-abi.md` | | Boost.JSON header-only：每个使用 `` 的翻译单元必须 `#include ` | 王测 W7 | (代码内 include) | | C ABI + atomic 回调：跨 DLL 函数指针必须 `std::atomic` + `memory_order_acquire/release` | 林深 W1.1 | `docs/reference/plugin-abi.md` §6 | | api_key 安全清零：on_shutdown 必须 `volatile char*` 写零循环 + clear | 曹武 W2.2 | `docs/explanation/security-logging.md` | | CRT：`/MD` 动态 CRT（`CMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL`） | 胡桐 W3 | (build 配置) | | `initialize_all` 容错：单插件失败不阻断其他插件，返回失败计数 | 黄岭 W9.8 | `dstalk-core/src/plugin_loader.cpp` | ## 7. Wave 编号与历史 进入项目时**第一件事**：读 `agents/*/profile.md` 的 `performance_log`，从最大 W 号继续下一波。 **已完成的高水位**（截至 2026-05-27）：W1.1、W2.1、W2.2、W3、W4、W5.1、W6.1、W7、W8.1、W9.1、W9.3、W9.4、W9.6、W9.8。Wave 6 还有 W9.10 in-flight。 下一个新提案应从 **W10.x** 开始。 ## 8. 用户消息模式识别（CEO 行为指南） | 用户说 | CEO 行动 | |--------|----------| | "团队不能闲着" / "去开会安排工作" | 立刻派下一波，**不要解释 / 不要问"派什么"**——基于 profile.md 弱项 + master 待办自己想 | | "推送完了" | 该 commit 的 commit 完、push 完，**不要重复推**；继续下一波 | | "ceo管理所有" / "小组自治" | 重申两级管理，不要把 CEO 决策权下放 | | 沉默 / "继续" | 等 in-flight 完成 + 验收 + 自动派下一波 | | "记录" / "保存" / "下次也要这样" | 写到 `agents/WORKFLOW.md`（公共）+ CEO 私有 memory（双轨） | ## 9. 子代理 prompt 模板（复制即用） ``` 你扮演 dstalk 团队成员 <姓名> () — <角色>。读 `agents//profile.md` 了解你的人设。 **W. 任务**：<一句话目标> **背景**：<2-4 句，说明为什么做这个、依赖什么前置工作> 请读： - <文件 1> - <文件 2> - ... **交付**： 1. <可执行步骤 1> 2. <可执行步骤 2> **禁忌**： - 不要碰 <某目录>（in-flight 中） - 不要 <某行为>（与设计原则冲突） 实现完成后必须 cmake --build build --config Release 验证 0 error，并跑 ctest -R smoke 验证 100% pass。 完成后更新 `agents//profile.md` performance_log 追加 W. 项。 **报告格式**（不超过 N 字）： 1. 改的代码行号 + 关键 diff 2. 测试输出最后几行 3. profile.md 已更新 ``` > **本节模板已迁移到 [agents/PROMPT_TEMPLATE.md](PROMPT_TEMPLATE.md)**，本处保留备份。 ## 10. 关联文档 - [README.md](README.md) — 团队花名册 + 公司宗旨 - [groups/](groups/) — 工作小组定义 - [../docs/reference/plugin-abi.md](../docs/reference/plugin-abi.md) — Plugin ABI 契约 - [../docs/explanation/architecture.md](../docs/explanation/architecture.md) — 架构哲学 - [../docs/explanation/plugin-lifecycle.md](../docs/explanation/plugin-lifecycle.md) — 插件生命周期 - [../docs/explanation/security-logging.md](../docs/explanation/security-logging.md) — 日志安全审计 ## 11. 协作状态机（强制规则） 状态机定义每个 Wave 从提案到交付（或终止）的合法路径。所有状态转换必须满足明确条件，不存在"CEO 感觉可以就过"的模糊转换。 ### 11.1 状态定义 | 状态 | 类型 | 含义 | |------|------|------| | PROPOSE | 活跃 | CEO 拆解需求为候选任务，编号 W<n>.<m> | | VOTE | 活跃 | 3-4 名子代理独立评估提案，投票同意/反对/否决 | | OPTIMIZE | 活跃 | 被否决的提案根据反对意见逐条修改 | | INTEGRATE | 活跃 | CEO 汇总投票结果为统一可执行计划 | | EXECUTE | 活跃 | 指派专长员工实施，每人有明确文件白名单和禁忌清单 | | INSPECT | 活跃 | CEO 运行完整验收清单（§12），逐项核对 | | SUCCESS | 终止 | Wave 完成，git commit + git push | | ABORT | 终止 | CEO 判定任务不再可行，丢弃本 Wave | | ROLLBACK | 终止 | 不可恢复错误，回退触发改动后重新决策 | ### 11.2 状态转换图 ``` +----------+ | PROPOSE | +----+-----+ | simple / EXPRESS | complex +-------------+--------------+ | | | v | +----------+ | | VOTE | | +----+-----+ | | | +-------------+-------------+ | | >50% reject | pass | | v v | | +----------+ +-----------+ | | | OPTIMIZE | | INTEGRATE | | | +----------+ +-----+-----+ | | | | | v | | +----------+ | +--------------------->| EXECUTE |<-------+ +----+-----+ | +----------+----------+ | done | fatal | v v | +----------+ +----------+ | | INSPECT | | ROLLBACK | | +----+-----+ +----------+ | | +---------+---------+ | pass | fail | v v | +----------+ +-------+ | | SUCCESS | | FAIL | | +----------+ +-------+ | ``` 回边（图中未画以避免杂乱，均以文字列出）： - OPTIMIZE --re-vote--> VOTE - OPTIMIZE --fundamental rewrite--> PROPOSE - EXECUTE --EXPRESS escalation--> VOTE - INSPECT fail --fixable--> EXECUTE - INSPECT fail --design--> OPTIMIZE - INSPECT fail --fatal--> ROLLBACK - INSPECT fail --abandon--> ABORT 全局出口（任意状态）： - ANY --CEO abort--> ABORT ### 11.2.1 EXPRESS 快跳路径 快跳（EXPRESS）是将 PROPOSE→VOTE→OPTIMIZE→INTEGRATE 压缩为 PROPOSE→EXECUTE 的合法短路径。快跳适用条件为以下 **全部 7 条** 同时满足： | # | 条件 | 验证方式 | |---|------|----------| | E1 | 改动源文件 ≤ 2 个（不含 profile.md） | `git diff --stat HEAD` 统计 changed files | | E2 | 不改动 `dstalk-core/include/` 下的任何公共头文件 | `git diff --name-only HEAD` 与 include/ 交集为空 | | E3 | 不改动 CMakeLists.txt / cmake/ 目录 / CMakePresets.json | `git diff --name-only HEAD` 与构建文件交集为空 | | E4 | 不新增公共 API 面：无新 `dstalk_` 前缀函数声明、无新插件接口结构体 | diff 中公共头文件无新增函数声明 | | E5 | 不涉及跨模块依赖变更：改动文件涉及 ≤ 2 个顶层目录（如 `dstalk-core/`、单个 `plugins//`） | `git diff --dirstat HEAD` 目录数 ≤ 2 | | E6 | CEO 在 WORKFLOW.md §7 任务条目中显式标注 `[EXPRESS]` | 人工核对 §7 | | E7 | 无 OPEN 状态的 CRITICAL 发现（见 §14.3 CRITICAL 阻塞规则） | `grep "CRITICAL.*OPEN" agents/audits/findings-registry.md` 输出为空 | 满足全部 E1-E7 → CEO 可声明 EXPRESS 快跳，任务直接进入 EXECUTE（跳过 VOTE / OPTIMIZE / INTEGRATE），对应转换规则 **T17**。 **EXPRESS 升级**：若执行者在 EXECUTE 阶段发现任务实际超出 EXPRESS 条件（E1-E5 任一条不再成立），须立即报告 CEO。CEO 核实后移除 `[EXPRESS]` 标签并替换为 `[ESCALATED]`，任务从 EXECUTE 退回 VOTE 走完整治理路径，对应转换规则 **T18**。 ### 11.3 转换条件表 | # | 从 | 到 | 触发条件 | 决策者 | |---|----|----|----------|--------| | T1 | PROPOSE | VOTE | 任务涉及跨模块改动 OR 涉及架构决策 OR 涉及新增公共 API OR CEO 指定需评审 | CEO | | T2 | PROPOSE | EXECUTE | 单文件改动 AND 不涉及公共头文件 AND 不涉及 CMakeLists.txt AND CEO 判定为简单任务 | CEO | | T3 | VOTE | OPTIMIZE | (反对票数 / 总票数) > 0.5 OR 任一投票者给出"否决"并附具体技术理由 | 自动（计票） | | T4 | VOTE | INTEGRATE | 所有投票者标记"同意" OR (反对票 ≤ 50% AND 无否决票) | 自动（计票） | | T5 | OPTIMIZE | VOTE | 提案方完成修改，提交修订版提案申请重新投票 | 提案方 | | T6 | OPTIMIZE | PROPOSE | 修改范围超出原提案 50%，实质成为新提案 | CEO | | T7 | INTEGRATE | EXECUTE | CEO 输出统一执行计划（任务-执行者映射 + 文件白名单 + 禁止触碰清单 + 验证步骤） | CEO | | T8 | EXECUTE | INSPECT | 所有指派的执行者子代理均已返回 done 报告（含 cmake build 0 error + ctest 100% pass 自述） | 自动（全员 done） | | T9 | EXECUTE | ROLLBACK | 任一执行者报告以下任一情况且 CEO 判定不可原地修复：段错误 / ABI 破坏 / CMake 无法 configure / 数据文件损坏 | CEO | | T10 | EXECUTE | ABORT | CEO 判定需求不再成立 OR 外部依赖不可用 | CEO | | T11 | INSPECT | SUCCESS | §12 验收清单 + §14.4 A1-A4 全部通过：cmake configure 0 error AND cmake build 0 error 0 warning(改动文件) AND ctest 100% pass AND 测试目标数 ≥ 上一波 AND profile.md 已更新 AND 无未跟踪临时文件 AND git diff 无无关改动 | CEO | | T12 | INSPECT | EXECUTE | 验收失败但满足全部：根因可定位到具体文件+行号 AND ≤2 个文件 AND ≤30 行改动 AND 不需重新设计 | CEO | | T13 | INSPECT | OPTIMIZE | 验收暴露以下任一设计问题：接口不兼容（编译通过但运行时错）/ 性能偏差 >50% / 架构假设被证伪（如单线程假设在多线程场景崩溃） | CEO | | T14 | INSPECT | ROLLBACK | 验收发现不可逆副作用：文件错误删除或覆盖 / 二进制损坏 / .git 目录状态异常 | CEO | | T15 | INSPECT | ABORT | CEO 判定继续修复成本 > 重新执行成本（需改 >5 个文件且涉及多个执行者重新协调） | CEO | | T16 | ANY | ABORT | 用户明确指令中止 OR 触发安全红线（凭证泄露、未加密敏感数据落盘） | CEO | | T17 | PROPOSE | EXECUTE | EXPRESS 快跳：同时满足 E1-E7（见 §11.2.1 EXPRESS 条件表）AND CEO 在 §7 任务条目标注 `[EXPRESS]` | CEO | | T18 | EXECUTE | VOTE | EXPRESS 升级：执行者报告任务实际范围超出 EXPRESS 条件（E1-E5 任一条不再成立）AND CEO 核实后将 `[EXPRESS]` 改为 `[ESCALATED]` | CEO | ### 11.4 状态进入/退出动作 | 状态 | 进入动作 | 退出动作 | |------|----------|----------| | PROPOSE | CEO 在 WORKFLOW.md §7 登记 W<n> 编号 | 提案内容归档到 agents/ 目录 | | VOTE | CEO 派 3-4 路 vote 子代理，prompt 含提案全文和评审标准 | 计票结果写入 WORKFLOW.md §7 | | EXECUTE | CEO 记录执行者名单 + 文件白名单 + 禁忌清单 | 汇总所有执行者报告 | | INSPECT | CEO 运行 §12 完整验收清单 | 验收结果和通过/失败项写入 WORKFLOW.md §7 | | SUCCESS | CEO 执行 git commit + git push | — | | ROLLBACK | 执行 §13.6 ROLLBACK 协议 6 步 | 回退原因和影响文件写入 WORKFLOW.md §7 | | ABORT | 记录中止原因和时间 | 本波 W 编号标记 ABORTED，写入 WORKFLOW.md §7 | ## 12. 验收清单（CEO inspect 硬指标） 以下全部为强制检查项，**缺一不可**。CEO 在 INSPECT 状态必须逐项核对，任一未通过即判定 inspect 失败。 ### 12.1 构建检查 | # | 检查项 | 命令/方法 | 通过标准 | |---|--------|-----------|----------| | B1 | cmake configure | `cmake --preset release 2>&1` | exit code = 0，stderr 无 "error:" | | B2 | cmake build | `cmake --build build --config Release 2>&1` | exit code = 0，stderr 无 "error:" | | B3 | 编译警告 | B2 输出中每个 warning 所在文件与 `git diff --name-only HEAD` 比对 | 本次改动文件产生 **0 warning**；非改动文件的预存 warning 不阻塞验收但需记录在案 | ### 12.2 测试检查 | # | 检查项 | 命令/方法 | 通过标准 | |---|--------|-----------|----------| | T1 | ctest 全量 | `ctest --test-dir build --output-on-failure` | 100% tests passed, 0 tests failed | | T2 | 测试数量 | `ctest -N --test-dir build` 统计测试目标数 | 测试目标数 ≥ 上一波记录值（覆盖不减少） | | T3 | smoke 专项 | `ctest -R smoke --test-dir build` | 100% passed（smoke 是回归底线，不可失败） | ### 12.3 交付物检查 | # | 检查项 | 命令/方法 | 通过标准 | |---|--------|-----------|----------| | D1 | profile 更新 | 逐个检查本波每个执行者的 `agents/<id>/profile.md` | 每个执行者 performance_log 含本波 W 编号条目 | | D2 | 无临时文件 | `git status --short` | 无 .tmp / .swp / *~ / .DS_Store / build/ 目录下的未跟踪文件 | | D3 | diff 纯净性 | `git diff HEAD` 逐文件审核 | 改动仅涉及任务相关文件，无意外修改；任何疑问 diff 块需执行者解释 | | D4 | 子代理自述 | 检查每个执行者子代理返回的最终消息 | 含 "cmake build 0 error" + "ctest 100% pass" 自述 | ### 12.4 验收结论映射 | 失败项组合 | 严重级别 | 回退目标 | |------------|----------|----------| | 仅 B1/B2/B3 失败 | 执行错误 | INSPECT → EXECUTE（修复构建） | | 仅 T1/T2/T3 失败 | 执行错误 | INSPECT → EXECUTE（修复测试） | | 仅 D1/D2/D3/D4 失败 | 流程错误 | INSPECT → EXECUTE（补文档/清理文件） | | B类 + T类 同时失败 | 设计错误 | INSPECT → OPTIMIZE | | 失败涉及 >2 个执行者 | 设计错误 | INSPECT → OPTIMIZE | | 全部通过 | — | INSPECT → SUCCESS | ## 13. 失败回退路径（强制处理协议） 以下协议覆盖所有阶段的失败场景。每个场景的处理步骤为**强制规则**，不存在"CEO 视情况灵活处理"的模糊空间。 ### 13.1 PROPOSE 阶段失败 - **症状**：CEO 无法将需求拆解为可执行任务（需求模糊 / 范围过大 / 与现有架构冲突） - **处理**：CEO 直接重写提案。缩小范围或拆分为多个 Wave。本 Wave 不进入 VOTE。 - **重试上限**：最多重写 2 次。第 3 次仍不可行 → ABORT，记录原因到 WORKFLOW.md §7。 - **责任人**：CEO ### 13.2 VOTE 阶段否决 - **症状**：>50% 投票者反对 OR 任一投票者给出技术否决 - **处理步骤**： 1. CEO 汇总所有反对票的具体理由，归档到 WORKFLOW.md §7 2. 进入 OPTIMIZE，由原提案方根据反对意见逐条修改 3. 修改完成后重新进入 VOTE 4. **连续 2 轮 VOTE 均被否决** → 回到 PROPOSE，CEO 重新出提案（原方案方向放弃） 5. **连续 3 轮 PROPOSE→VOTE→OPTIMIZE 循环仍无共识** → ABORT，CEO 判定该需求当前不可执行 - **责任人**：提案方（第 1 轮修改）+ CEO（第 2 轮起裁决） ### 13.3 OPTIMIZE 阶段僵局 - **症状**：提案方无法在合理范围内满足反对意见 OR 修改导致方案退化 - **处理**： 1. 修改范围 > 原提案 50% → 回到 PROPOSE（作为新提案，重新编号） 2. 反对意见本身有争议 → CEO 仲裁，判定反对是否成立 3. CEO 判定无法调和 → ABORT，CEO 另起替代方案 - **责任人**：CEO ### 13.4 EXECUTE 阶段失败 - **症状**：执行者子代理返回失败（编译错误 / 测试失败 / 无法完成任务） **分级处理表**： | 失败级别 | 条件 | 处理 | 责任人 | |----------|------|------|--------| | L1 轻微 | 单执行者失败，根因明确，修复 ≤30 行 | CEO 在原 prompt 追加修复指令，同一执行者重试（仅 1 次） | 原执行者 | | L2 中等 | L1 重试仍失败 OR 失败涉及 >2 个文件 | CEO 换人执行（选同专长其他员工）OR CEO 亲自修复 | CEO | | L3 严重 | 多执行者同时失败 OR 构建系统破坏 OR ABI 破坏 | 进入 ROLLBACK：`git checkout -- <触发文件>` + CEO 判定是否缩小范围重新 EXECUTE | CEO | | L4 致命 | 数据损坏 / 无法定位的段错误 / 安全漏洞暴露 | 进入 ROLLBACK + 指派 security-cao 安全审计 | CEO + security-cao | ### 13.5 INSPECT 阶段失败 **处理协议（按步骤强制执行，不可跳过）**： 1. **先回退触发改动**：`git checkout -- <验收失败的源文件>`，确保仓库回到可构建状态 2. **验证回退成功**：`cmake --build build --config Release` 必须 0 error 3. **定位根因**：确认失败属于执行错误（execution error）还是设计错误（design error） 4. **按分级表处理**： | 失败类型 | 判定标准 | 回退目标 | 后续动作 | |----------|----------|----------|----------| | E1 执行错误 | 编译警告/错误可定位到具体行，修复不涉及接口变更 | EXECUTE | 原执行者修复（1 次机会），CEO 复核 | | E2 执行错误（重复） | 同一执行者同类错误第 2 次出现 | EXECUTE | 换人执行（同专长其他员工） | | D1 设计错误 | 接口不兼容 / 架构假设错误 / 需改公共头文件 | OPTIMIZE | 提案方重新设计，走完整 VOTE→INTEGRATE→EXECUTE | | D2 设计错误（严重） | 需回退 >3 个文件 OR 涉及 ABI 变更 | ROLLBACK | 回退后 CEO 重新 PROPOSE，缩小任务范围 | | F1 致命 | 数据损坏 / 安全漏洞 / .git 异常 | ROLLBACK | 回退 + security-cao 审计 + CEO 决定是否 ABORT | ### 13.6 ROLLBACK 协议（强制步骤） 当触发 ROLLBACK 时，按以下步骤强制执行，**不可跳过任何一步**： 1. `git status` → 记录当前所有改动文件列表 2. `git checkout -- <触发失败的所有文件>` → 回退触发改动的文件 3. `cmake --build build --config Release` → 确认回退后构建 0 error 4. `ctest -R smoke --test-dir build` → 确认回退后测试 100% pass 5. 在 WORKFLOW.md §7 记录：回退原因、触发文件列表、决策（重做 / 缩小范围 / 放弃） 6. CEO 根据 §13.5 分级表选择后续路径（重新 EXECUTE / 重新 PROPOSE / ABORT） ### 13.7 ABORT 协议（强制步骤） 当触发 ABORT 时，按以下步骤强制执行： 1. 在 WORKFLOW.md §7 记录：中止原因、时间、影响范围 2. 决定改动处置：保留（`git stash`）或丢弃（`git checkout`） 3. 本波 W 编号标记为 ABORTED，下一波使用新编号 4. 相关执行者 profile.md performance_log 仍追加条目（rating: aborted），保留参与记录 ## 14. 审计→修复闭环机制 审计（audit）产出的发现必须转化为可跟踪、可执行、可验收的修复任务。不允许审计报告写完即归档、发现问题无人跟进。 核心闭环：**Audit report → Finding registration → Severity triage → Fix task (Wave) → CEO verify → Close** ### 14.1 发现登记格式 所有审计发现统一登记在 `agents/audits/findings-registry.md`，分为 Open Findings 和 Closed Findings 两个分区。每条发现包含以下字段： | 字段 | 说明 | 示例 | |------|------|------| | ID | `F-<源Wave>-<序号>`，全局唯一 | F-11.7-1 | | Severity | CRITICAL / HIGH / MEDIUM / LOW | CRITICAL | | Source | 审计报告文件名（相对于 agents/audits/） | W11.7-destructive-test.md | | Title | 一句话描述，含关键行号和症状 | `/clear` reports [OK] even when session unavailable — main.cpp:168-172 | | Status | 见 §14.2 状态定义 | OPEN | | Assigned To | 负责修复的员工 agent-id（OPEN 状态为空） | architect-huang | | Fix Wave | 修复所在的 Wave 编号（FIXED 后填写） | W16.1 | | Verified By | 验收人 agent-id（VERIFIED 后填写） | qa-wang | 发现数量超过 20 条时，qa-wang 负责将 Closed 分区中超过 30 天的条目归档到 `agents/audits/findings-archive.md`。 ### 14.2 发现状态生命周期 | 状态 | 类型 | 含义 | 进入条件 | 退出条件 | |------|------|------|----------|----------| | OPEN | 活跃 | 发现已登记，待 triage | 审计报告提交后，由审计人或 QA 组长录入 registry | CEO/QA 组长完成 triage 并指定执行者 | | ASSIGNED | 活跃 | 已指派修复人，等待执行 | Triage 完成 + CEO 在 PROPOSE 阶段创建对应修复 W 任务 | 执行者提交修复 + 自述 cmake 0 error + ctest 100% pass | | FIXED | 活跃 | 修复已提交，等待验证 | 执行者完成修复并更新 registry 状态 | CEO INSPECT 通过（§12）OR QA 组长验证通过 | | VERIFIED | 活跃 | 修复已验证，即将关闭 | INSPECT 全部通过 OR 回归测试覆盖通过 | 自动进入 CLOSED | | CLOSED | 终止 | 已关闭 | VERIFIED 后自动关闭 | — | | WONTFIX | 终止 | 决定不修复 | CEO 明确判定不修复（附理由） | — | | BLOCKED | 活跃 | 被阻塞 | 依赖的其他发现未修复 OR 外部条件不满足 | 阻塞解除后回到 ASSIGNED | 状态转换图： ``` OPEN ──→ ASSIGNED ──→ FIXED ──→ VERIFIED ──→ CLOSED │ │ │ │ │ │ │ │ ↓ ↓ ↓ ↓ WONTFIX BLOCKED REOPEN REOPEN (回到 (回到 ASSIGNED) ASSIGNED) ``` 回边定义： - FIXED → ASSIGNED (REOPEN)：CEO INSPECT 发现修复不完整或引入新回归，退回执行者 - VERIFIED → ASSIGNED (REOPEN)：后续回归测试暴露本发现的修复引入了新问题 - ASSIGNED → BLOCKED → ASSIGNED：执行者发现依赖未满足，申请阻塞；依赖解除后恢复 - OPEN → WONTFIX：CEO 判定（如：修复成本远超收益 / 已被后续重构覆盖 / 非 bug 是设计取舍） 全局出口： - ANY → WONTFIX：CEO 在任意状态可强制关闭（需附理由写入 registry Change Log） ### 14.3 自动转化规则 从审计发现到修复任务的转化由严重级别驱动： | Severity | 转化规则 | 时限 | 触发者 | |----------|----------|------|--------| | CRITICAL | 下一波 PROPOSE 阶段 MUST 创建对应修复任务（W 编号），优先级最高，阻塞其他任务排期 | 当前 Wave + 1 | CEO | | HIGH | 2 个 Wave 内 MUST 安排修复任务 | 当前 Wave + 2 | CEO / QA 组长 | | MEDIUM | 每波 PROPOSE 阶段评估，可合并到其他同文件/同模块任务中附带修复 | 不限，但每 5 个 Wave 至少回顾一次 backlog | QA 组长 triage | | LOW | 进入 backlog，在相关源文件被其他任务改动时附带修复（opportunistic fix） | 不限 | 执行者自行判断 | CRITICAL 阻塞规则： - 如果进入 EXECUTE 阶段时仍有 OPEN 状态的 CRITICAL 发现，CEO 必须明确决策：(a) 本波优先修 CRITICAL，或 (b) 标记 WONTFIX（附理由），或 (c) 降级为 HIGH（附降级理由） - 不允许带着 OPEN CRITICAL 发现进入 SUCCESS **历史发现时限计算**：对于在本机制建立之前已存在的审计发现（如 F-11.x 系列），时限从 findings-registry.md 初始化日期（2026-05-27）开始计算，而非从原始审计日期计算。即 F-11.1-1 (HIGH) 的修复期限为 2026-05-27 + 2 Wave = W17 前。 ### 14.4 CEO 审查协议（新增验收项） 在 §12 验收清单基础上，INSPECT 阶段追加以下检查项： | # | 检查项 | 命令/方法 | 通过标准 | |---|--------|-----------|----------| | A1 | 发现登记完整性 | 检查本波新增审计报告：逐一核对 severity ≥ MEDIUM 的发现是否已录入 findings-registry.md | 无遗漏 | | A2 | CRITICAL 发现清零 | `grep "CRITICAL.*OPEN" agents/audits/findings-registry.md` | 输出为空（所有 CRITICAL 已修复或 WONTFIX） | | A3 | 修复关联标注 | 检查本波 EXECUTE 子代理报告 | 每个修复任务标注了对应的 Finding ID（格式：`Fixes: F--`） | | A4 | 状态同步 | 逐一核对 registry 中本波涉及的发现状态与实际修复结果一致 | FIXED 状态发现的 cmake + ctest 已通过 | 验收结论扩展： | 失败项 | 处理 | |--------|------| | A1 失败 | 补充录入 → 重新检查 | | A2 失败 | INSPECT → EXECUTE（优先修复 CRITICAL） | | A3 失败 | 补标注 → 重新检查 | | A4 失败 | 状态回退到 ASSIGNED → EXECUTE | ### 14.5 与 §11 状态机的集成点 | §11 状态 | §14 动作 | 责任人 | |----------|----------|--------| | PROPOSE | 1. 读取 findings-registry.md Open 分区 2. 将 CRITICAL/HIGH OPEN 发现转为候选 W 任务 3. 评估 MEDIUM backlog | CEO | | EXECUTE | 1. 子代理 prompt 中标注 `Fixes: F--` 2. 修复完成后更新 registry 中该发现状态为 FIXED | 执行者 | | INSPECT | 1. 执行 §14.4 A1-A4 检查 2. 通过的发现 FIXED → VERIFIED → CLOSED 3. 失败的发现退回 ASSIGNED（REOPEN） | CEO | | SUCCESS | 1. 本波 CLOSED 的发现从 Open 分区移到 Closed 分区 2. 记录关闭日期和 Fix Wave | CEO | | ABORT | 本波 ASSIGNED 的发现回退到 OPEN（修复未发生） | CEO | | (T18) | 本波 ASSIGNED 的 finding 保留 ASSIGNED 状态，不回退 OPEN（升级不是中止） | CEO | ### 14.6 审计人职责 提交审计报告时，审计人必须同时完成以下动作： 1. 在审计报告末尾新增 "## Findings Summary" 小节，列出所有发现的 ID、Severity、Title（与 registry 格式一致） 2. 将 severity ≥ MEDIUM 的发现录入 `findings-registry.md` Open 分区，状态 OPEN 3. LOW 发现同样录入（保持完整记录），但可在 triage 时直接标记为 backlog 审计人完成登记后通知 CEO 或 QA 组长进行 triage。 **存量审计报告**：`agents/audits/` 中已有的审计报告（W11.1-W13.6）缺少 Findings Summary 小节。QA 组长应在每个存量报告被引用时补充该小节，优先级为 MEDIUM，不阻塞当前工作。 ### 14.7 关联文档 - [findings-registry.md](audits/findings-registry.md) — 发现注册表（单一事实来源） - [PROMPT_TEMPLATE.md](PROMPT_TEMPLATE.md) — 子代理 prompt 模板（修复任务使用标准模板，Fixes 行添加到交付清单）