pulsareon/dstalk
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
master
dstalk/agents/WORKFLOW.md
XiuChengWu f010af6c07
Some checks failed
CI / Determine matrix (push) Has been cancelled
Details
CI / ${{ matrix.os }} / ${{ matrix.build_type }} (push) Has been cancelled
Details
W15: conflict resolution — E7 CRITICAL gate, T11/T18 audit refs, §5 metadata check, PROMPT_TEMPLATE Fixes (W15.4-W15.9) 
- W15.4 (杨帆): §11/§14 cross-reference audit — PASS-WITH-NOTES, 3 fixes needed
- W15.5 (王测): §14 internal consistency — PASS-WITH-NOTES, 4 fixes needed
- W15.6 (胡桐): self-check script + YAML verification — PASS
- W15.7 (杨帆): Add E7 (no OPEN CRITICAL) to EXPRESS conditions, update T11 to include §14.4 A1-A4, add T18 finding status in §14.5
- W15.8 (王测): Fix findings-registry Close Date, add historical finding time-limit rule, add legacy audit Findings Summary note, add Fixes annotation to PROMPT_TEMPLATE
- W15.9 (胡桐): Fix false-positive warning in check_agents_metadata.py (skip audits/ dir), add metadata check to §5

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 18:33:02 +08:00

492 lines
29 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# dstalk 团队工作流（CEO 多代理协作模式）
> 本文档供 CEO（主会话）和所有员工子代理参考。新会话恢复 CEO 模式时**第一件事**就是读这里。
## 1. 编制与并行度
- **团队规模 = CPU 物理核数（dstalk = 16 人）**：1 CEO + 3 架构师 + 5 工程师 + 3 QA + 2 DevOps + 1 设计师 + 1 作家 + 1 安全
- 每个员工有 `agents/<id>/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<wave>.<seq>` 编号，如 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/**/<file>.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：每个使用 `<boost/json.hpp>` 的翻译单元必须 `#include <boost/json/src.hpp>` | 王测 W7 | (代码内 include) |
| C ABI + atomic 回调：跨 DLL 函数指针必须 `std::atomic<fn_ptr>` + `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 团队成员 <姓名> (<agent-id>) — <角色>。读 `agents/<agent-id>/profile.md` 了解你的人设。
**W<n>.<m> 任务**：<一句话目标>
**背景**：<2-4 句，说明为什么做这个、依赖什么前置工作>
请读：
- <文件 1>
- <文件 2>
- ...
**交付**：
1. <可执行步骤 1>
2. <可执行步骤 2>
**禁忌**：
- 不要碰 <某目录>（in-flight 中）
- 不要 <某行为>（与设计原则冲突）
实现完成后必须 cmake --build build --config Release 验证 0 error，并跑 ctest -R smoke 验证 100% pass。
完成后更新 `agents/<agent-id>/profile.md` performance_log 追加 W<n>.<m> 项。
**报告格式**（不超过 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&lt;n&gt;.&lt;m&gt; |
| 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--&gt; VOTE
- OPTIMIZE --fundamental rewrite--&gt; PROPOSE
- EXECUTE --EXPRESS escalation--&gt; VOTE
- INSPECT fail --fixable--&gt; EXECUTE
- INSPECT fail --design--&gt; OPTIMIZE
- INSPECT fail --fatal--&gt; ROLLBACK
- INSPECT fail --abandon--&gt; ABORT
全局出口（任意状态）：
- ANY --CEO abort--&gt; ABORT
### 11.2.1 EXPRESS 快跳路径
快跳（EXPRESS）是将 PROPOSE&rarr;VOTE&rarr;OPTIMIZE&rarr;INTEGRATE 压缩为 PROPOSE&rarr;EXECUTE 的合法短路径。快跳适用条件为以下 **全部 7 条** 同时满足：
| # | 条件 | 验证方式 |
|---|------|----------|
| E1 | 改动源文件 &le; 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 | 不涉及跨模块依赖变更：改动文件涉及 &le; 2 个顶层目录（如 `dstalk-core/`、单个 `plugins/<name>/`） | `git diff --dirstat HEAD` 目录数 &le; 2 |
| E6 | CEO 在 WORKFLOW.md &sect;7 任务条目中显式标注 `[EXPRESS]` | 人工核对 &sect;7 |
| E7 | 无 OPEN 状态的 CRITICAL 发现（见 §14.3 CRITICAL 阻塞规则） | `grep "CRITICAL.*OPEN" agents/audits/findings-registry.md` 输出为空 |
满足全部 E1-E7 &rarr; 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 | (反对票数 / 总票数) &gt; 0.5 OR 任一投票者给出"否决"并附具体技术理由 | 自动（计票） |
| T4 | VOTE | INTEGRATE | 所有投票者标记"同意" OR (反对票 &le; 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 测试目标数 &ge; 上一波 AND profile.md 已更新 AND 无未跟踪临时文件 AND git diff 无无关改动 | CEO |
| T12 | INSPECT | EXECUTE | 验收失败但满足全部：根因可定位到具体文件+行号 AND &le;2 个文件 AND &le;30 行改动 AND 不需重新设计 | CEO |
| T13 | INSPECT | OPTIMIZE | 验收暴露以下任一设计问题：接口不兼容（编译通过但运行时错）/ 性能偏差 &gt;50% / 架构假设被证伪（如单线程假设在多线程场景崩溃） | CEO |
| T14 | INSPECT | ROLLBACK | 验收发现不可逆副作用：文件错误删除或覆盖 / 二进制损坏 / .git 目录状态异常 | CEO |
| T15 | INSPECT | ABORT | CEO 判定继续修复成本 &gt; 重新执行成本（需改 &gt;5 个文件且涉及多个执行者重新协调） | CEO |
| T16 | ANY | ABORT | 用户明确指令中止 OR 触发安全红线（凭证泄露、未加密敏感数据落盘） | CEO |
| T17 | PROPOSE | EXECUTE | EXPRESS 快跳：同时满足 E1-E7（见 &sect;11.2.1 EXPRESS 条件表）AND CEO 在 &sect;7 任务条目标注 `[EXPRESS]` | CEO |
| T18 | EXECUTE | VOTE | EXPRESS 升级：执行者报告任务实际范围超出 EXPRESS 条件（E1-E5 任一条不再成立）AND CEO 核实后将 `[EXPRESS]` 改为 `[ESCALATED]` | CEO |
### 11.4 状态进入/退出动作
| 状态 | 进入动作 | 退出动作 |
|------|----------|----------|
| PROPOSE | CEO 在 WORKFLOW.md §7 登记 W&lt;n&gt; 编号 | 提案内容归档到 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&gt;&amp;1` | exit code = 0，stderr 无 "error:" |
| B2 | cmake build | `cmake --build build --config Release 2&gt;&amp;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` 统计测试目标数 | 测试目标数 &ge; 上一波记录值（覆盖不减少） |
| T3 | smoke 专项 | `ctest -R smoke --test-dir build` | 100% passed（smoke 是回归底线，不可失败） |
### 12.3 交付物检查
| # | 检查项 | 命令/方法 | 通过标准 |
|---|--------|-----------|----------|
| D1 | profile 更新 | 逐个检查本波每个执行者的 `agents/&lt;id&gt;/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 &rarr; EXECUTE（修复构建） |
| 仅 T1/T2/T3 失败 | 执行错误 | INSPECT &rarr; EXECUTE（修复测试） |
| 仅 D1/D2/D3/D4 失败 | 流程错误 | INSPECT &rarr; EXECUTE（补文档/清理文件） |
| B类 + T类 同时失败 | 设计错误 | INSPECT &rarr; OPTIMIZE |
| 失败涉及 &gt;2 个执行者 | 设计错误 | INSPECT &rarr; OPTIMIZE |
| 全部通过 | — | INSPECT &rarr; SUCCESS |
## 13. 失败回退路径（强制处理协议）
以下协议覆盖所有阶段的失败场景。每个场景的处理步骤为**强制规则**，不存在"CEO 视情况灵活处理"的模糊空间。
### 13.1 PROPOSE 阶段失败
- **症状**：CEO 无法将需求拆解为可执行任务（需求模糊 / 范围过大 / 与现有架构冲突）
- **处理**：CEO 直接重写提案。缩小范围或拆分为多个 Wave。本 Wave 不进入 VOTE。
- **重试上限**：最多重写 2 次。第 3 次仍不可行 &rarr; ABORT，记录原因到 WORKFLOW.md §7。
- **责任人**：CEO
### 13.2 VOTE 阶段否决
- **症状**：&gt;50% 投票者反对 OR 任一投票者给出技术否决
- **处理步骤**：
1. CEO 汇总所有反对票的具体理由，归档到 WORKFLOW.md §7
2. 进入 OPTIMIZE，由原提案方根据反对意见逐条修改
3. 修改完成后重新进入 VOTE
4. **连续 2 轮 VOTE 均被否决** &rarr; 回到 PROPOSE，CEO 重新出提案（原方案方向放弃）
5. **连续 3 轮 PROPOSE&rarr;VOTE&rarr;OPTIMIZE 循环仍无共识** &rarr; ABORT，CEO 判定该需求当前不可执行
- **责任人**：提案方（第 1 轮修改）+ CEO（第 2 轮起裁决）
### 13.3 OPTIMIZE 阶段僵局
- **症状**：提案方无法在合理范围内满足反对意见 OR 修改导致方案退化
- **处理**：
1. 修改范围 &gt; 原提案 50% &rarr; 回到 PROPOSE（作为新提案，重新编号）
2. 反对意见本身有争议 &rarr; CEO 仲裁，判定反对是否成立
3. CEO 判定无法调和 &rarr; ABORT，CEO 另起替代方案
- **责任人**：CEO
### 13.4 EXECUTE 阶段失败
- **症状**：执行者子代理返回失败（编译错误 / 测试失败 / 无法完成任务）
**分级处理表**：
| 失败级别 | 条件 | 处理 | 责任人 |
|----------|------|------|--------|
| L1 轻微 | 单执行者失败，根因明确，修复 &le;30 行 | CEO 在原 prompt 追加修复指令，同一执行者重试（仅 1 次） | 原执行者 |
| L2 中等 | L1 重试仍失败 OR 失败涉及 &gt;2 个文件 | CEO 换人执行（选同专长其他员工）OR CEO 亲自修复 | CEO |
| L3 严重 | 多执行者同时失败 OR 构建系统破坏 OR ABI 破坏 | 进入 ROLLBACK：`git checkout -- &lt;触发文件&gt;` + CEO 判定是否缩小范围重新 EXECUTE | CEO |
| L4 致命 | 数据损坏 / 无法定位的段错误 / 安全漏洞暴露 | 进入 ROLLBACK + 指派 security-cao 安全审计 | CEO + security-cao |
### 13.5 INSPECT 阶段失败
**处理协议（按步骤强制执行，不可跳过）**：
1. **先回退触发改动**：`git checkout -- &lt;验收失败的源文件&gt;`，确保仓库回到可构建状态
2. **验证回退成功**：`cmake --build build --config Release` 必须 0 error
3. **定位根因**：确认失败属于执行错误（execution error）还是设计错误（design error）
4. **按分级表处理**：
| 失败类型 | 判定标准 | 回退目标 | 后续动作 |
|----------|----------|----------|----------|
| E1 执行错误 | 编译警告/错误可定位到具体行，修复不涉及接口变更 | EXECUTE | 原执行者修复（1 次机会），CEO 复核 |
| E2 执行错误（重复） | 同一执行者同类错误第 2 次出现 | EXECUTE | 换人执行（同专长其他员工） |
| D1 设计错误 | 接口不兼容 / 架构假设错误 / 需改公共头文件 | OPTIMIZE | 提案方重新设计，走完整 VOTE&rarr;INTEGRATE&rarr;EXECUTE |
| D2 设计错误（严重） | 需回退 &gt;3 个文件 OR 涉及 ABI 变更 | ROLLBACK | 回退后 CEO 重新 PROPOSE，缩小任务范围 |
| F1 致命 | 数据损坏 / 安全漏洞 / .git 异常 | ROLLBACK | 回退 + security-cao 审计 + CEO 决定是否 ABORT |
### 13.6 ROLLBACK 协议（强制步骤）
当触发 ROLLBACK 时，按以下步骤强制执行，**不可跳过任何一步**：
1. `git status` &rarr; 记录当前所有改动文件列表
2. `git checkout -- &lt;触发失败的所有文件&gt;` &rarr; 回退触发改动的文件
3. `cmake --build build --config Release` &rarr; 确认回退后构建 0 error
4. `ctest -R smoke --test-dir build` &rarr; 确认回退后测试 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-<Wave>-<N>`） |
| 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-<Wave>-<N>` 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 行添加到交付清单）
Reference in New Issue View Git Blame Copy Permalink