W15: workflow improvements — EXPRESS fast-path, audit→fix closed loop, metadata self-check (W15.1-W15.3)

- W15.1 (杨帆): Add EXPRESS fast-path to §11 state machine (T17/T18, E1-E6 conditions, escalation safety valve) - W15.2 (王测): Add §14 audit→fix closed loop — findings-registry.md, severity-driven auto-triage, CRITICAL blocking rule - W15.3 (胡桐): Create scripts/check_agents_metadata.py (5-check: YAML parse, rating range, group/member refs, duplicate IDs) - Fix YAML orphan bugs in 3 profiles: devops-hu, engineer-sun, security-cao (perf_log entries outside array) - Pre-fill findings-registry.md with 10 historical findings from W11.1/W11.7 audits Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-27 18:19:37 +08:00
parent 102cd3e141
commit 0e41c8c6f6
8 changed files with 629 additions and 17 deletions
--- a/agents/WORKFLOW.md
+++ b/agents/WORKFLOW.md
@@ -144,7 +144,7 @@
                    | PROPOSE  |
                    +----+-----+
                         |
-              simple     |     complex
+    simple / EXPRESS    |     complex
           +-------------+--------------+
           |                            |
           |                            v
@@ -183,6 +183,7 @@

 - 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
@@ -192,6 +193,23 @@

 - ANY --CEO abort--&gt; ABORT

+### 11.2.1 EXPRESS 快跳路径
+
+快跳（EXPRESS）是将 PROPOSE&rarr;VOTE&rarr;OPTIMIZE&rarr;INTEGRATE 压缩为 PROPOSE&rarr;EXECUTE 的合法短路径。快跳适用条件为以下 **全部 6 条** 同时满足：
+
+| # | 条件 | 验证方式 |
+|---|------|----------|
+| 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 |
+
+满足全部 E1-E6 &rarr; CEO 可声明 EXPRESS 快跳，任务直接进入 EXECUTE（跳过 VOTE / OPTIMIZE / INTEGRATE），对应转换规则 **T17**。
+
+**EXPRESS 升级**：若执行者在 EXECUTE 阶段发现任务实际超出 EXPRESS 条件（E1-E5 任一条不再成立），须立即报告 CEO。CEO 核实后移除 `[EXPRESS]` 标签并替换为 `[ESCALATED]`，任务从 EXECUTE 退回 VOTE 走完整治理路径，对应转换规则 **T18**。
+
 ### 11.3 转换条件表

 | # | 从 | 到 | 触发条件 | 决策者 |
@@ -212,6 +230,8 @@
 | T14 | INSPECT | ROLLBACK | 验收发现不可逆副作用：文件错误删除或覆盖 / 二进制损坏 / .git 目录状态异常 | CEO |
 | T15 | INSPECT | ABORT | CEO 判定继续修复成本 &gt; 重新执行成本（需改 &gt;5 个文件且涉及多个执行者重新协调） | CEO |
 | T16 | ANY | ABORT | 用户明确指令中止 OR 触发安全红线（凭证泄露、未加密敏感数据落盘） | CEO |
+| T17 | PROPOSE | EXECUTE | EXPRESS 快跳：同时满足 E1-E6（见 &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 状态进入/退出动作

@@ -344,4 +364,122 @@
 1. 在 WORKFLOW.md §7 记录：中止原因、时间、影响范围
 2. 决定改动处置：保留（`git stash`）或丢弃（`git checkout`）
 3. 本波 W 编号标记为 ABORTED，下一波使用新编号
-4. 相关执行者 profile.md performance_log 仍追加条目（rating: 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
+
+### 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 |
+
+### 14.6 审计人职责
+
+提交审计报告时，审计人必须同时完成以下动作：
+
+1. 在审计报告末尾新增 "## Findings Summary" 小节，列出所有发现的 ID、Severity、Title（与 registry 格式一致）
+2. 将 severity ≥ MEDIUM 的发现录入 `findings-registry.md` Open 分区，状态 OPEN
+3. LOW 发现同样录入（保持完整记录），但可在 triage 时直接标记为 backlog
+
+审计人完成登记后通知 CEO 或 QA 组长进行 triage。
+
+### 14.7 关联文档
+
+- [findings-registry.md](audits/findings-registry.md) — 发现注册表（单一事实来源）
+- [PROMPT_TEMPLATE.md](PROMPT_TEMPLATE.md) — 子代理 prompt 模板（修复任务使用标准模板，Fixes 行添加到交付清单）