team-skills 1.4.0 → 1.5.0

package/CHANGELOG.md

@@ -7,6 +7,36 @@
 
 ## [Unreleased]
 
+## [1.5.0] - 2026-06-28
+
+### 新增
+
+- team-spec: `01-plan.md` 骨架新增"容量与成本预估"章节（数据量级/QPS/API 成本/存储增长）
+- team-spec: `03-sdd.md` §八 异常场景后新增并发和兼容性 SIGNAL 提示
+- team-spec: Phase 3 自检新增容量成本检查项
+- team-test: 功能覆盖维度补充跨模块/跨服务集成路径端到端测试要求
+- team-test: 新增 E2E/集成测试遗漏 TRAP
+- team-impl: RED 阶段新增集成测试遗漏 TRAP
+- team-review: 正确性维度新增向后兼容性检查（API 签名、数据格式、配置项破坏性变更）
+- team-review: 性能维度新增并发安全、数据量级评估、成本影响评估
+- team-orchestrator: 精简模式等效证据映射表（D2 五项 + G1/G6/G7 硬门槛映射）
+- team-debug: Phase 4 补充 `debug-report.md` WRITE 指令，QUALITY 表同步更新
+- ai-collaboration-standards: 三层体系项目级新增 AGENTS.md，§1.4 Review 标准和交付要求新增 checklist 文件引用
+- spec-driven-workflow: §七 边界条件新增"兼容性变更"
+
+### 变更
+
+- team-score: D3 TDD 流程正确分值 5→8（对齐 L2 workshop 标准），移除 D4 评委自定(3)，D3 总分 27→30，D4 总分 13→10，总分保持 100
+- team-orchestrator: Step 8 D3/D4 分值标注同步（27→30, 13→10）
+- team-orchestrator: 精简模式 D2.2/D2.3/D2.5 从"跳过"改为等效证据 ASSERT 检查
+- team-security: 一级红线标识 RL-1~6 → RED_LINE_1~6，二级红线 HR-1~4 → HIGH_RISK_1~4（遵循"缩写即缺陷"命名规范）
+- 消费方引用格式统一：`（红线 RL-N）` → ``（`team-security: RED_LINE_N`）``（team-review/team-spec/team-impl/team-finish）
+
+### 修复
+
+- team-review: 复盘模板§编号对齐（§二.5→§三, §三→§四，与 13-retrospective-template.md 一致）
+- ai-collaboration-standards: §1.4 代码结构引用计数修正（"17 文件"→"任务目录结构"）
+
 ## [1.4.0] - 2026-06-27
 
 ### 新增

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "team-skills",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "AI Agent Skills framework — Spec-Driven development with directed-graph rollback and quality gates",
   "type": "module",
   "bin": {

package/skills/_team-rules/ai-collaboration-standards.md

@@ -7,7 +7,7 @@
 ### 1.1 三层规则体系
 
 ```
-项目级 CLAUDE.md / .cursor/rules/    ← 全局规则，所有任务继承
+项目级 CLAUDE.md / .cursor/rules/ / AGENTS.md    ← 全局规则 + 架构说明，所有任务继承
   └─ 模块级 {module}/CLAUDE.md        ← 模块特有规则
       └─ 任务级 task-rules.md          ← 仅本任务适用
 ```
@@ -47,12 +47,12 @@
 | ----------- | ------------------------------------------------------------------------- |
 | 业务术语    | `team-spec` `02-context.md` 模板（术语表）                                |
 | 系统架构    | `team-orchestrator` 有向图流程图 + `team-spec` `03-sdd.md` §四 数据流     |
-| 代码结构    | `_team-rules/task-lifecycle.md` §1（17 文件目录结构）                     |
+| 代码结构    | `_team-rules/task-lifecycle.md` §1（任务目录结构）                        |
 | 接口约定    | `team-spec` `02-context.md`（接口约束表）+ `03-sdd.md` §五/§六           |
 | 编码规范    | `_team-rules/spec-driven-workflow.md` §2 TDD + 本文件 §2.3 输出质量约束 + `team-impl` 各阶段禁止项 |
 | 测试要求    | `_team-rules/verification-protocol.md` + `team-test` 四维测试矩阵        |
-| Review 标准 | `team-review` 五维度审查 + 严重级别校准（P0-P3 实例）                     |
-| 交付要求    | `team-orchestrator` Step 8 完整性检查                                     |
+| Review 标准 | `team-review` 五维度审查 + 严重级别校准（P0-P3 实例）+ `docs/review-checklist.md`（由 `team-review` 产出并维护） |
+| 交付要求    | `team-orchestrator` Step 8 完整性检查 + `docs/delivery-checklist.md`（由 `team-review` 产出并维护）                  |
 
 ## §2 Prompt 工程规范
 

package/skills/_team-rules/spec-driven-workflow.md

@@ -22,7 +22,7 @@
 | §四 数据流总览    | ASCII 架构图                                               | `team-impl` → 理解调用链路     |
 | §五 输入规格 | 参数类型、约束、默认值、示例                               | `team-impl` + `team-test`        |
 | §六 输出规格 | 场景、HTTP 状态、输出结构、示例                            | `team-impl` + `team-test`        |
-| §七 边界条件      | 空值、极值、并发、格式异常                                 | `team-test` → 边界测试         |
+| §七 边界条件      | 空值、极值、并发、兼容性变更、格式异常                     | `team-test` → 边界测试         |
 | §八 异常场景      | 错误码、错误消息、HTTP 状态                                | `team-test` → 异常测试         |
 | §九 验收 Checklist | 验收条件、验证方式、预期结果                               | `team-review` → 验收检查       |
 

package/skills/team-debug/SKILL.md

@@ -41,7 +41,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 | 质量维度 | 产出文件 |
 | -------- | -------- |
-| 根因调查记录 | 调试日志（对话中） |
+| 根因调查记录 | 调试日志（对话中）；编排模式另写 `debug-report.md` |
 | 假设验证记录 | 调试日志（对话中） |
 | 修复验证 | 测试通过确认 |
 
@@ -125,7 +125,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 > SIGNAL：修复通过但不同测试失败 → 修复停留在症状层面，根因仍在。回到 Phase 1 重新调查。
 
-4. **IF** 编排模式（任务目录存在）→ **WRITE** 修复循环到 `06-tdd-log.md` + 决策到 `08-ai-decisions.md`
+4. **IF** 编排模式（任务目录存在）→ **WRITE** 修复循环到 `06-tdd-log.md` + 决策到 `08-ai-decisions.md` + 调试报告到 `debug-report.md`（按 OUTPUT_TEMPLATE 骨架填充）
 5. 修复成功 → 退出 `REPEAT`，进入自检门禁
 
 - *REPEAT_EXHAUSTED* → **BLOCKED**，触发 **ASK_HUMAN**，提交以下信息：

package/skills/team-finish/SKILL.md

@@ -81,7 +81,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 > 推送前最后一道安全防线。凭证泄露一旦进入远程仓库，撤回成本极高。
 
-**EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|token|password|passwd|credential)\s*[:=]' .` — 推送前凭证扫描（RL-2）
+**EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|token|password|passwd|credential)\s*[:=]' .` — 推送前凭证扫描（`team-security: RED_LINE_2`）
 
 - **IF** `exit_code == 0` → 逐条排除占位符/测试值/注释 → 真实凭证 → **BLOCKED**，**WRITE**（对话中）凭证位置，要求修复后重新验证
 - **ELSE** → **GOTO** Step 2

package/skills/team-impl/SKILL.md

@@ -126,6 +126,8 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 
 > TRAP：只写 Happy Path 测试就急着进 GREEN。SDD §七（边界条件）和 §八（异常场景）的测试必须在 RED 阶段一起写，不是"以后再补"。
 
+> TRAP：仅写单元测试而遗漏集成测试——如果 SDD §四 数据流涉及跨模块调用，RED 阶段应包含跨模块集成测试，否则单元测试全绿但集成路径未验证。
+
 3. **EXEC** 项目测试命令 → **ASSERT** `exit_code != 0`（尚无实现，测试必须失败）
 
 > SIGNAL：`output CONTAINS "0 tests found"` → 测试文件路径或命名不符合项目 test pattern，先检查 glob 配置再下结论。
@@ -142,20 +144,28 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
    - 时间：{YYYY-MM-DD HH:MM}
    ```
 
-5. **EXEC** `git commit -m "test: {功能点} (RED)"`
-   - **ASSERT** `exit_code == 0`（commit 失败 → 检查 pre-commit hook 输出，修复后重试）
+5. **EXEC** `git add {测试文件路径}` — 仅暂存测试文件
+   - **ASSERT** `git diff --cached --name-only` 仅包含测试文件，不含生产代码
+   - **IF** 暂存区包含非测试文件 → `git reset HEAD {非测试文件}` 移出暂存区
+6. **EXEC** `git commit -m "test: {功能点} (RED)"` → **ASSERT** `exit_code == 0`
+   - commit 失败 → 检查 pre-commit hook 输出，修复后重试
+
+> TRAP：你会倾向于在 RED 阶段"顺手"写几行实现代码。RED commit 是 TDD 顺序的**不可篡改证据**——一旦 commit 中混入生产代码，整个 TDD 证据链失效。编排器会通过 `git show --stat` 验证每个 RED commit 仅包含测试文件。
 
 **GATE** RED 完成检查（全部通过才放行）：
 
 - [ ] **ASSERT** `06-tdd-log.md CONTAINS "RED 记录"`
-- [ ] **ASSERT** `git log CONTAINS "RED commit"`
+- [ ] **ASSERT** `git log CONTAINS "test: ... (RED)" commit`
+- [ ] **ASSERT** `git show --stat HEAD` 仅包含测试文件变更（不含生产代码）
 - [ ] 我是否因为"应该没问题"跳过了 SDD §七/§八 中某个边界条件或异常场景的测试？
 
 #### 循环 2：绿（Green）— 写实现
 
 > TRAP：你会倾向于在 GREEN 阶段写"正确且优雅"的代码。抑制这个冲动——GREEN 只需让当前测试通过的最小代码量。三行重复优于过早抽象，优雅留给 REFACTOR。
 
-1. **WRITE** 最少代码让测试通过
+1. **EXEC** `git diff --name-only` → **ASSERT** 工作区无生产代码变更（仅允许 `06-tdd-log.md` 等文档变更）
+   - **IF** 发现已存在实现代码文件 → 违反 TDD 纪律（先写实现后写测试）→ 删除实现代码 → **GOTO** 循环 1 重新开始
+2. **WRITE** 最少代码让测试通过
 2. **EXEC** 项目测试命令 → **ASSERT** `exit_code == 0`
    - **IF** `exit_code == 0` → **WRITE** `06-tdd-log.md` GREEN 记录
    - **IF** `exit_code != 0` → 修改实现（非测试）→ 重新执行步骤 1-2
@@ -186,7 +196,7 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 3. **WRITE** `06-tdd-log.md` REFACTOR 记录
 4. **EXEC** `git commit -m "refactor: {功能点}"` → **ASSERT** `exit_code == 0`
 
-**提交纪律**（Constitutional Rule #9）：每个功能点的 RED → GREEN → REFACTOR 各自独立 commit（`test:` → `feat:/fix:` → `refactor:`）。RED commit 必须在写实现代码之前完成。编排器通过 `git log` 验证时序。违反 → 删除实现，从 RED 重新开始。
+**提交纪律**（Constitutional Rule #9）：每个功能点的 RED → GREEN → REFACTOR 各自独立 commit（`test:` → `feat:/fix:` → `refactor:`）。RED commit **仅包含测试文件**，不得混入任何生产代码——git history 是 TDD 顺序的不可篡改证据。编排器通过 `git show --stat` 验证每个 RED commit 的文件列表。违反 → 删除实现，从 RED 重新开始。
 
 #### Bug 修复验证模式
 
@@ -360,8 +370,8 @@ NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 - [ ] **EXEC** 项目测试命令 → **ASSERT** `failures == 0`
 - [ ] **EXEC** 项目 lint 命令 → **ASSERT** `exit_code == 0`
 - [ ] **EXEC** `git diff --name-only` → **ASSERT** `未修改 04-boundary.md deny 文件`
-- [ ] **EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|password|passwd|credential)\s*[:=]' .` → **ASSERT** 无真实凭证硬编码（RL-2，排除占位符/测试值/注释）
-- [ ] **IF** 代码调用外部 AI 服务 → **ASSERT** `输入数据已脱敏或确认为非敏感`（RL-1）
+- [ ] **EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|password|passwd|credential)\s*[:=]' .` → **ASSERT** 无真实凭证硬编码（`team-security: RED_LINE_2`，排除占位符/测试值/注释）
+- [ ] **IF** 代码调用外部 AI 服务 → **ASSERT** `输入数据已脱敏或确认为非敏感`（`team-security: RED_LINE_1`）
 - [ ] **ASSERT** `实际消耗 <= 01-plan.md 自我约束预算`
 - [ ] **ASSERT** `所有困惑已显式记录于 06-tdd-log.md 审计段落`
 - [ ] **ASSERT** `无占位符残留（{N}、{slug} 等已被实际值替换）`

package/skills/team-orchestrator/SKILL.md

@@ -269,6 +269,18 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
 | 团队证据 14-15 | ✅ | ❌ |
 | 归档合并 | ✅ | ✅ |
 
+**精简模式等效证据映射**（team-score 评分时使用相同映射）：
+
+| 评分项 | 完整模式证据 | 精简模式等效证据 |
+| ------ | ----------- | --------------- |
+| D2.1 目标澄清 | `01-plan.md` §一 | `03-sdd.md` §一 背景与动机 |
+| D2.2 上下文选择 | `02-context.md` | `04-boundary.md` 引用文件列表 |
+| D2.3 任务拆分 | `01-plan.md` §二 分期 | `03-sdd.md` 分期说明或阶段划分 |
+| D2.5 验证与风险 | `05-risk.md` | `03-sdd.md` §三 设计决策 + `11-review.md` §四 剩余风险 |
+| G1 任务规划 | `01-plan.md` 全文 | `03-sdd.md` 含目标和设计决策 |
+| G6 风险说明 | `05-risk.md` + `11-review.md` | `11-review.md` §四 |
+| G7 关键决策 | `08-ai-decisions.md` + `15-brief.md` | `08-ai-decisions.md` |
+
 ## INPUT
 
 | 来源 | 必需 | 说明 |
@@ -330,7 +342,7 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
 
 **MATCH** `checkpoint.status`：
 
-- `IN_PROGRESS` → 从 `next_step` 对应的 Step 继续
+- `IN_PROGRESS` → 从 `current_step` 对应的 Step 继续
 - `DONE` || `DONE_WITH_CONCERNS` → 提示用户"该任务已完成"，询问是否新建变体任务
 - `BLOCKED` → 触发 **ASK_HUMAN** 展示 `blocked_reason`
 - `NEEDS_CONTEXT` → 展示缺失信息，请求用户补充
@@ -439,6 +451,8 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
   - (b) 由编排器手动编写规格，但承诺补全 01-05 规划文档
   - (c) 终止任务
 
+**WRITE** checkpoint：`current_step=Step 2, phase=spec-dispatching, status=IN_PROGRESS`
+
 **ROUTE** `team-spec`
 
 调用方式取决于工具能力：
@@ -508,6 +522,8 @@ NO AGENT DISPATCH WITHOUT CONFIRM_GOAL HUMAN CONFIRMATION FIRST
   - (c) 终止任务
 - **IF** 用户选择 (b) → 编排器执行实现，但**必须**在进入 Step 4 前产出 06-08
 
+**WRITE** checkpoint：`current_step=Step 3, phase=impl-dispatching, status=IN_PROGRESS`
+
 **ROUTE** `team-impl`
 
 调用方式取决于工具能力：
@@ -553,11 +569,16 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 3. **ASSERT** `GREEN.通过输出` NOT_EMPTY && `GREEN.通过输出` CONTAINS `PASS|pass|OK|✓|✅|passed`
 4. **ASSERT** `RED.时间 <= GREEN.时间` && `GREEN.时间 <= REFACTOR.时间`
 5. **EXEC** `git log --oneline` → **ASSERT** `exit_code == 0` && `test: 提交数 >= 功能点数`
+6. **FOR** `red_commit` **IN** `test: ... (RED) commits`：**EXEC** `git show --stat {red_commit}` → **ASSERT** 仅包含测试文件变更，不含生产代码
 
 任一项不通过 → **ROLLBACK** team-impl，附具体不合格项及期望修正行为。
 
+**WRITE**（对话中）team-impl 产出摘要：代码变更文件列表 + TDD 循环数 + 测试通过状态。
+
 **WRITE** checkpoint：`current_step=Step 4, next_step=Step 5, phase=impl, completed_steps 追加 Step 3`
 
+→ **GOTO** Step 4
+
 ### Step 4：调度 team-test
 
 > 测试审计是独立于实现的质量验证。编排器必须完整传递 team-test 的路由决策（回退 team-impl/回退 team-spec），不可自行过滤或降级。
@@ -569,6 +590,8 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - CHECK `team-test` skill 是否存在
 - **IF** 不可用 → **ASK_HUMAN**，展示选项：(a) 安装后继续 (b) 编排器手动执行但承诺补全 09-10 (c) 终止
 
+**WRITE** checkpoint：`current_step=Step 4, phase=test-dispatching, status=IN_PROGRESS`
+
 **ROUTE** `team-test`
 
 调用方式取决于工具能力：
@@ -597,6 +620,8 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 **READ** `10-test-report.md` 中 team-test 路由决策（→ team-review / → team-impl / → team-spec / → **ASK_HUMAN**）
 
+**WRITE**（对话中）team-test 产出摘要：测试矩阵覆盖率 + 新增/修改测试数 + 路由决策（继续/回退）。
+
 **WRITE** checkpoint：`current_step=Step 5, next_step=Step 6, phase=test, completed_steps 追加 Step 4`
 
 **回退检查**（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
@@ -610,9 +635,9 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - `同一对第 3 次回退` → **WRITE** checkpoint：`status=BLOCKED` → 强制 **ASK_HUMAN**
 - `Kill Switch`（任务不可行）→ **WRITE** checkpoint：`status=BLOCKED` → **ASK_HUMAN**
 - `人类需决策` → **WRITE** checkpoint：`status=BLOCKED` → **ASK_HUMAN**
-- *DEFAULT* → 记录问题，继续下一步
+- *DEFAULT* → 记录问题 → **GOTO** Step 5
 
-**ELSE** → 测试全部通过，继续下一步
+**ELSE** → 测试全部通过 → **GOTO** Step 5
 
 > SIGNAL：同一 `source→target` 对回退达到 2 次时，第 3 次不是"再试一次"——是系统性问题（SDD 不完整、架构不适配等），必须触发 `ASK_HUMAN` 让用户介入。
 
@@ -627,6 +652,8 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - CHECK `team-review` skill 是否存在
 - **IF** 不可用 → **ASK_HUMAN**，展示选项：(a) 安装后继续 (b) 编排器手动执行但承诺补全 11-13 + task-rules (c) 终止
 
+**WRITE** checkpoint：`current_step=Step 5, phase=review-dispatching, status=IN_PROGRESS`
+
 **ROUTE** `team-review`
 
 调用方式取决于工具能力：
@@ -656,6 +683,8 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 
 **READ** `11-review.md` 中 team-review 修复/回退决策
 
+**WRITE**（对话中）team-review 产出摘要：五维度审查结论 + P0/P1 问题数 + 路由决策（继续/回退）。**IF** `status == DONE_WITH_CONCERNS` → 完整展示 concerns 给用户。
+
 **WRITE** checkpoint：`current_step=Step 6, next_step=Step 7, phase=review, completed_steps 追加 Step 5`
 
 **回退检查**（Constitutional Rule #7：同一 source→target 对回退 ≤ 2 次）：
@@ -669,9 +698,9 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - `同一对第 3 次回退` → **WRITE** checkpoint：`status=BLOCKED` → 强制 **ASK_HUMAN**
 - `Kill Switch` → **WRITE** checkpoint：`status=BLOCKED` → **ASK_HUMAN**
 - `人类需决策` → **WRITE** checkpoint：`status=BLOCKED` → **ASK_HUMAN**
-- *DEFAULT* → 记录问题，继续下一步
+- *DEFAULT* → 记录问题 → **GOTO** Step 6
 
-**ELSE** → 审查全部通过，继续下一步
+**ELSE** → 审查全部通过 → **GOTO** Step 6
 
 ### Step 6：补全团队级证据
 
@@ -904,12 +933,12 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 **D2 AI 协作任务规划（25 分）：**
 
 - [ ] D2.1 `[完整模式]` **ASSERT** `01-plan.md 有成功标准 >= 3 条` && `非目标 >= 2 条`。`[精简替代]` **ASSERT** `03-sdd.md §一 有明确目标`
-- [ ] D2.2 `[完整模式]` **ASSERT** `02-context.md 有必要引用 + 已排除上下文`。`[精简替代]` 跳过
-- [ ] D2.3 `[完整模式]` **ASSERT** `01-plan.md 有 >= 5 阶段拆分`。`[精简替代]` 跳过
+- [ ] D2.2 `[完整模式]` **ASSERT** `02-context.md 有必要引用 + 已排除上下文`。`[精简替代]` **ASSERT** `04-boundary.md 有引用文件列表`
+- [ ] D2.3 `[完整模式]` **ASSERT** `01-plan.md 有 >= 5 阶段拆分`。`[精简替代]` **ASSERT** `03-sdd.md 有分期说明或阶段划分`
 - [ ] D2.4 **ASSERT** `04-boundary.md 有 allow/deny + 依赖约束`
-- [ ] D2.5 `[完整模式]` **ASSERT** `05-risk.md 有验证计划` && `停下来问人条件 >= 3 个`。`[精简替代]` 跳过
+- [ ] D2.5 `[完整模式]` **ASSERT** `05-risk.md 有验证计划` && `停下来问人条件 >= 3 个`。`[精简替代]` **ASSERT** `03-sdd.md §三 有风险相关设计决策` || `11-review.md §四 有剩余风险说明`
 
-**D3 AI 交付质量保障（27 分）：**
+**D3 AI 交付质量保障（30 分）：**
 
 - [ ] D3.1 **ASSERT** `03-sdd.md 含输入/输出/边界/异常/验收 Checklist`
 - [ ] D3.2 **READ** `06-tdd-log.md` → **ASSERT** `RED 失败输出在前` && `GREEN 通过输出在后` && `git log 中 test: 提交早于 feat:/fix:`
@@ -917,7 +946,7 @@ TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功
 - [ ] D3.4 **ASSERT** `06-tdd-log.md 有修复记录` && `11-review.md 有修复记录`
 - [ ] D3.5 **ASSERT** `11-review.md 含五维度审查` && `§四 剩余风险 EXISTS`
 
-**D4 AI 使用过程与复盘（13 分）：**
+**D4 AI 使用过程与复盘（10 分）：**
 
 - [ ] D4.1 **ASSERT** `07-prompt-log.md 每条含五要素`
 - [ ] D4.2 **ASSERT** `07-prompt-log.md 每条含效果记录`；**IF** 存在偏离 → **ASSERT** `有纠偏前后对比`

package/skills/team-review/SKILL.md

@@ -106,9 +106,9 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 
 | 维度         | 检查内容                                                       |
 | ------------ | -------------------------------------------------------------- |
-| **正确性**   | 逻辑是否正确？边界条件是否处理？异常路径是否覆盖？             |
+| **正确性**   | 逻辑是否正确？边界条件是否处理？异常路径是否覆盖？向后兼容性是否保持（API 签名、数据格式、配置项的破坏性变更）？ |
 | **可维护性** | 命名是否清晰？函数是否过长？是否有重复代码？是否遵循项目约定？ |
-| **性能**     | 是否有不必要的循环？是否有内存泄漏风险？是否有不必要的渲染？   |
+| **性能**     | 是否有不必要的循环？是否有内存泄漏风险？是否有不必要的渲染？并发安全（竞态条件、死锁、资源争用）？数据量级评估（大表扫描、批量操作）？成本影响评估（外部 API 调用频次、存储增长）？ |
 | **安全**     | 注入风险？凭证泄露？权限检查遗漏？外部 AI 数据脱敏？高风险操作 HITL？ |
 | **测试覆盖** | 测试是否覆盖了所有边界？测试命名是否清晰？测试是否可重复？     |
 
@@ -116,16 +116,16 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 
 #### 安全硬检查（安全维度强制执行，不可仅靠人眼）
 
-1. **EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|token|password|passwd|credential)\s*[:=]' .` — 凭证泄露扫描（RL-2）
+1. **EXEC** `grep -rn -E '(AK|SK|access[_-]?key|secret[_-]?key|api[_-]?key|token|password|passwd|credential)\s*[:=]' .` — 凭证泄露扫描（`team-security: RED_LINE_2`）
    - **IF** `exit_code == 0` → 逐条排除占位符/测试值/注释 → 真实凭证 → **P0 安全漏洞**
    - **ELSE** → 记录"凭证扫描通过"
 
 2. **IF** 项目配置了 SAST/SCA 工具（`npm audit` / `safety check` / `cargo audit` / `gosec` / `semgrep`）→ **EXEC** 对应扫描命令 → **IF** `exit_code != 0` → 高危 → **P1**，中低危 → **P2**
    **ELSE** → 标注"项目未配置 SAST/SCA，仅人工安全审查"
 
-3. **IF** 代码涉及高风险操作（资金划转 / 权限变更 / 数据删除 / 对外发布）→ **ASSERT** `人工确认机制已实现`（RL-3） — 未实现 → **P0 安全漏洞**
+3. **IF** 代码涉及高风险操作（资金划转 / 权限变更 / 数据删除 / 对外发布）→ **ASSERT** `人工确认机制已实现`（`team-security: RED_LINE_3`） — 未实现 → **P0 安全漏洞**
 
-4. **IF** 代码调用外部 AI 服务 → **ASSERT** `输入数据已脱敏或确认为非敏感`（RL-1） — 敏感数据直接输入 → **P0 安全漏洞**
+4. **IF** 代码调用外部 AI 服务 → **ASSERT** `输入数据已脱敏或确认为非敏感`（`team-security: RED_LINE_1`） — 敏感数据直接输入 → **P0 安全漏洞**
 
 ### Phase 1.5：Constitutional 合规检查
 
@@ -363,13 +363,13 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK FIRST
 
 1. **本次任务回顾**：做得好的 + 可以改进的 + 意外发现（具体事例，不是泛泛而谈）
 2. **AI 协作经验**：提示词优化经验 + 团队协作改进建议
-3. **新规则沉淀**（§二.5）：列出可固化规则，注明写入位置。**固化门槛**：同类问题出现 ≥ 2 次（模式），或可在未来导致 P0/P1（严重性）。一次性 P2/P3 仅记录到 task-rules.md
+3. **新规则沉淀**（§三）：列出可固化规则，注明写入位置。**固化门槛**：同类问题出现 ≥ 2 次（模式），或可在未来导致 P0/P1（严重性）。一次性 P2/P3 仅记录到 task-rules.md
    - **FOR** `new_rule`：
      1. **WRITE** 追加到目标文件（项目 AI 规范 / 模块 AI 规范 / task-rules.md）
      2. **WRITE** 变更记录到 `12-asset-update.md`
-4. **改进承诺**（§三）：具体行动 + 预期效果
+4. **改进承诺**（§四）：具体行动 + 预期效果
 
-**ASSERT** `新规则沉淀段落 EXISTS` — §二.5 是质量检查 D4.4 的关键证据。"发现规则但未写入目标文件"视为未完成
+**ASSERT** `新规则沉淀段落 EXISTS` — §三 是质量检查 D4.4 的关键证据。"发现规则但未写入目标文件"视为未完成
 
 ## OUTPUT_TEMPLATE
 

package/skills/team-score/SKILL.md

@@ -128,17 +128,17 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 执行约束       | 5    | 明确哪些文件可改，哪些不能改；明确依赖、接口、数据结构、兼容性约束 | 边界说明、修改文件清单             |
 | 验证与风险控制 | 5    | 每一步有可检查完成标准；能识别什么时候该让 AI 停下来问人           | 验证计划、风险项、停下来问人条件   |
 
-### 三、AI 交付质量保障（27 分）
+### 三、AI 交付质量保障（30 分）
 
 | 二级验收项        | 分值 | 验收标准                                                             | 需检查的证据                           |
 | ----------------- | ---- | -------------------------------------------------------------------- | -------------------------------------- |
 | SDD 规格清晰      | 5    | 业务规则结构化（输入/输出/边界条件/异常场景）；关键设计决策有选择理由和拒绝理由 | SDD 规格说明                           |
-| TDD 流程正确      | 5    | 先写测试再写实现（git log 提交顺序可验证）；测试在修复前失败、修复后通过        | 测试提交记录、失败/通过截图或代码 diff |
+| TDD 流程正确      | 8    | 先写测试再写实现（git log 提交顺序可验证）；测试在修复前失败、修复后通过。证据链：(1) `test:` commit 时间戳早于 `feat:`/`fix:` commit (2) 06-tdd-log.md RED 记录含 FAIL 输出 (3) GREEN 记录含 PASS 输出且时间戳晚于 RED | 测试提交记录、06-tdd-log.md RED/GREEN 时间戳对、失败/通过截图或代码 diff |
 | 测试覆盖充分      | 7    | 正向路径(2) + 边界条件(2) + 异常场景(2) + 回归测试(1)；仅 happy path ≤ 2 分 | 测试用例列表、代码 diff、改动测试结果  |
 | 缺陷修复正确      | 5    | 修复符合业务规则；没有引入新的硬编码或副作用；没有破坏已有功能。零缺陷场景（全流程无 bug）：检查代码质量而非修复记录——测试一次通过 + Review 无 P0/P1 = 满分 | 代码 diff、改动测试结果                |
 | Review 与风险识别 | 5    | 能识别脆弱性、数据、安全、性能、兼容性问题；说明剩余风险和未覆盖部分 | Review 记录、风险识别记录              |
 
-### 四、AI 使用过程与复盘（13 分）
+### 四、AI 使用过程与复盘（10 分）
 
 | 二级验收项     | 分值 | 验收标准                                                   | 需检查的证据          |
 | -------------- | ---- | ---------------------------------------------------------- | --------------------- |
@@ -146,7 +146,6 @@ NO SCORE WITHOUT EVIDENCE FIRST
 | 能迭代纠偏     | 3    | AI 输出偏离时，能指出问题并调整提示；不是复制粘贴结果      | AI 对话摘要、纠偏记录 |
 | 过程可追溯     | 2    | 保留关键 AI 对话摘要；能说明为什么采纳或拒绝 AI 建议       | AI 协作过程记录       |
 | 个人复盘有效   | 2    | 每位成员能总结本次沉淀的新规则，并说明下次如何提升协作质量 | 个人复盘文档          |
-| (评委自定)     | 3    | 评委根据答辩表现酌情加分。评估维度：技术决策解释清晰度、trade-off 理解深度、遗留风险坦诚程度。无答辩环节时此项不评分，D4 得分 = 其他 4 项实得分 ÷ 10 × 13 | 答辩现场 / 书面答辩 |
 
 ### 五、团队协作表现（10 分）
 
@@ -276,7 +275,7 @@ NO SCORE WITHOUT EVIDENCE FIRST
 
 > SIGNAL：得分 >= 80% 但交付物清单有缺失项 → 评分标准与交付标准不一致。降分或补充说明。
 
-**FOR** `验收项`（5 个维度，共 24 项）：
+**FOR** `验收项`（5 个维度，共 23 项）：
 
 1. **ASSERT** `该项证据来源 != 空` → 找不到证据 = 0 分，记录"未找到：`{搜索过的路径}`"
 2. 根据验收标准给出得分（0 ~ 满分），附带具体文件路径和内容片段
@@ -301,8 +300,8 @@ NO SCORE WITHOUT EVIDENCE FIRST
 - **40%**: 有意识但执行不足
 - **0分**: 完全缺失
 
-> GOOD：`D3.2 TDD 流程：3/5。证据：06-tdd-log.md 第 12-45 行记录了 3 个功能点的 RED→GREEN 循环，时间戳顺序正确（RED 14:02 → GREEN 14:18）。但 git log 显示第 4 个功能点 feat: 提交早于 test: 提交，TDD 顺序违反。扣 2 分。`
-> BAD：`D3.2 TDD 流程：3/5。基本遵循了 TDD 流程，有些地方可以改进。`
+> GOOD：`D3.2 TDD 流程：5/8。证据：06-tdd-log.md 第 12-45 行记录了 3 个功能点的 RED→GREEN 循环，时间戳顺序正确（RED 14:02 → GREEN 14:18）。但 git log 显示第 4 个功能点 feat: 提交早于 test: 提交，TDD 顺序违反。扣 3 分。`
+> BAD：`D3.2 TDD 流程：5/8。基本遵循了 TDD 流程，有些地方可以改进。`
 
 > GOOD：`D1.3 规则可执行：0/5。未找到。已搜索路径：CLAUDE.md（不存在）、.cursorrules（不存在）、docs/ai/（目录不存在）、README.md（无 AI 规则章节）。`
 > BAD：`D1.3 规则可执行：2/5。项目有一定的规范意识。`
@@ -338,10 +337,10 @@ NO SCORE WITHOUT EVIDENCE FIRST
 ### 二、AI 协作任务规划（得分/25）
 ...
 
-### 三、AI 交付质量保障（得分/27）
+### 三、AI 交付质量保障（得分/30）
 ...
 
-### 四、AI 使用过程与复盘（得分/13）
+### 四、AI 使用过程与复盘（得分/10）
 ...
 
 ### 五、团队协作表现（得分/10）
@@ -411,8 +410,8 @@ NO SCORE WITHOUT EVIDENCE FIRST
 |------|------|---------|---------|
 | D1 AI 协作资产 | {n}/25 | {evidence} | {suggestion} |
 | D2 任务规划 | {n}/25 | {evidence} | {suggestion} |
-| D3 交付质量 | {n}/27 | {evidence} | {suggestion} |
-| D4 过程复盘 | {n}/13 | {evidence} | {suggestion} |
+| D3 交付质量 | {n}/30 | {evidence} | {suggestion} |
+| D4 过程复盘 | {n}/10 | {evidence} | {suggestion} |
 | D5 团队协作 | {n}/10 | {evidence} | {suggestion} |
 ```
 

package/skills/team-security/SKILL.md

@@ -178,9 +178,9 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 > 以下 6 条红线绝对禁止，不受业务需求、紧急程度或管理层级影响。
 
-**FOR** `red_line` **IN** [`RL-1`, `RL-2`, `RL-3`, `RL-4`, `RL-5`, `RL-6`]：
+**FOR** `red_line` **IN** [`RED_LINE_1`, `RED_LINE_2`, `RED_LINE_3`, `RED_LINE_4`, `RED_LINE_5`, `RED_LINE_6`]：
 
-#### RL-1：敏感数据输入外部 AI
+#### RED_LINE_1：敏感数据输入外部 AI
 
 1. **EXEC** `grep -rn -E '(api\.openai|api\.anthropic|api\.google|generativelanguage|azure\.com/openai|外部AI|external[_-]?ai|third[_-]?party)' .` — 检测外部 AI 服务调用
    - **IF** `exit_code == 0` → 发现外部 AI 调用 → 检查输入数据
@@ -189,9 +189,9 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
    - 个人信息（客户数据、员工信息）→ **违规**
    - 商业秘密 → **违规**
    - 核心仓库代码 → **违规**
-   - 违规 → 标记 `RL-1 VIOLATION`，继续检查下一条红线
+   - 违规 → 标记 `RED_LINE_1 VIOLATION`，继续检查下一条红线
 
-#### RL-2：凭证泄露
+#### RED_LINE_2：凭证泄露
 
 > SIGNAL：`grep` 命中硬编码凭证 → 立即 P0，不等其他检查完成。凭证一旦入库（即使后续 commit 删除），git history 中永久存在。
 
@@ -202,9 +202,9 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
    - 硬编码真实 AK/SK/Token/API Key/密码 → **违规**
    - 凭证通过 Prompt 输入 AI → **违规**
    - 账号外借/共享 → **违规**
-   - 违规 → 标记 `RL-2 VIOLATION`，继续检查下一条红线
+   - 违规 → 标记 `RED_LINE_2 VIOLATION`，继续检查下一条红线
 
-#### RL-3：AI 直接执行高风险操作
+#### RED_LINE_3：AI 直接执行高风险操作
 
 > TRAP："内部 API 不需要授权检查"是最常见的安全假设错误。内部 ≠ 可信——横向移动攻击正是利用这一点。
 
@@ -216,32 +216,32 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
    - 数据删除 → **ASSERT** `人工确认记录 EXISTS`
    - 对外发布 → **ASSERT** `人工确认记录 EXISTS`
    - *DEFAULT* → 继续下一项
-3. **IF** 任一高风险操作无人工确认 → 标记 `RL-3 VIOLATION`，继续检查下一条红线
+3. **IF** 任一高风险操作无人工确认 → 标记 `RED_LINE_3 VIOLATION`，继续检查下一条红线
 
-#### RL-4：未审批接入外部 AI 或 API
+#### RED_LINE_4：未审批接入外部 AI 或 API
 
 1. **READ** 项目依赖（`package.json` / `go.mod` / `requirements.txt` / `pom.xml`）+ 代码中的外部服务调用
 2. **EXEC** `grep -rn -E '(import|require|from)\s.*(openai|anthropic|google\.generativeai|azure.*openai|cohere|mistral|replicate)' .` — 检测外部 AI SDK 引入
    - **IF** `exit_code == 0` → 检查是否经过审批
 3. **ASSERT** `外部 AI 服务已审批`
-   - 未经审批的外部 AI 接入 → 标记 `RL-4 VIOLATION`，继续检查下一条红线
+   - 未经审批的外部 AI 接入 → 标记 `RED_LINE_4 VIOLATION`，继续检查下一条红线
 
-#### RL-5：使用公司数据训练外部模型
+#### RED_LINE_5：使用公司数据训练外部模型
 
 1. **READ** 代码中的模型训练/微调逻辑
 2. **EXEC** `grep -rn -E '(fine[_-]?tun|train|finetune|lora|qlora|sft)\b' .` — 检测训练相关代码
    - **IF** `exit_code == 0` → 检查数据来源和模型目标
 3. **ASSERT** `公司数据未用于训练外部模型`
-   - 公司数据输出到第三方训练平台 → 标记 `RL-5 VIOLATION`，继续检查下一条红线
+   - 公司数据输出到第三方训练平台 → 标记 `RED_LINE_5 VIOLATION`，继续检查下一条红线
 
-#### RL-6：滥用公司 AI 资源
+#### RED_LINE_6：滥用公司 AI 资源
 
 1. **READ** AI 资源使用记录/代码逻辑
 2. **ASSERT** `AI 资源用于工作职责范围内`
-   - 与工作无关的用途 → 标记 `RL-6 VIOLATION`
-   - 未授权的商业经营/外部服务/数据处理 → 标记 `RL-6 VIOLATION`
+   - 与工作无关的用途 → 标记 `RED_LINE_6 VIOLATION`
+   - 未授权的商业经营/外部服务/数据处理 → 标记 `RED_LINE_6 VIOLATION`
 
-**IF** 存在任何 `RL-* VIOLATION` → **GOTO** Phase 7（携带全部违规记录）
+**IF** 存在任何 `RED_LINE_* VIOLATION` → **GOTO** Phase 7（携带全部违规记录）
 
 ### Phase 3：二级红线检查（高风险限制）
 
@@ -251,49 +251,49 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 > 以下 4 条为高风险操作，必须满足控制条件后方可执行。
 
-**FOR** `high_risk` **IN** [`HR-1`, `HR-2`, `HR-3`, `HR-4`]：
+**FOR** `high_risk` **IN** [`HIGH_RISK_1`, `HIGH_RISK_2`, `HIGH_RISK_3`, `HIGH_RISK_4`]：
 
-#### HR-1：AI 自动化执行
+#### HIGH_RISK_1：AI 自动化执行
 
 **IF** 存在 AI 自动化执行逻辑：
 
 - **ASSERT** `人机协同控制机制 已配置`
 - **ASSERT** `关键执行节点有人工确认`
-- 未满足 → 标记 `HR-1 NON_COMPLIANT`
+- 未满足 → 标记 `HIGH_RISK_1 NON_COMPLIANT`
 
-**ELSE**：标注 `HR-1 N/A`
+**ELSE**：标注 `HIGH_RISK_1 N/A`
 
-#### HR-2：Agent 多系统调用
+#### HIGH_RISK_2：Agent 多系统调用
 
 **IF** 存在 Agent 跨系统调用：
 
 - **ASSERT** `安全评估 已完成`
 - **ASSERT** `系统间调用权限边界 已明确`
 - **ASSERT** `审计监控（日志记录） 已纳入`
-- 未满足 → 标记 `HR-2 NON_COMPLIANT`
+- 未满足 → 标记 `HIGH_RISK_2 NON_COMPLIANT`
 
-**ELSE**：标注 `HR-2 N/A`
+**ELSE**：标注 `HIGH_RISK_2 N/A`
 
-#### HR-3：Workflow 自动决策
+#### HIGH_RISK_3：Workflow 自动决策
 
 **IF** 存在 Workflow 自动决策逻辑：
 
 - **ASSERT** `决策阈值 已定义`
 - **ASSERT** `回退机制 已配置`
 - **ASSERT** `决策结果 可追溯、可复核`
-- 未满足 → 标记 `HR-3 NON_COMPLIANT`
+- 未满足 → 标记 `HIGH_RISK_3 NON_COMPLIANT`
 
-**ELSE**：标注 `HR-3 N/A`
+**ELSE**：标注 `HIGH_RISK_3 N/A`
 
-#### HR-4：AI 辅助决策（影响业务结果）
+#### HIGH_RISK_4：AI 辅助决策（影响业务结果）
 
 **IF** 存在 AI 辅助决策影响业务：
 
 - **ASSERT** `AI 建议角色定位 已明确`
 - **ASSERT** `最终决策由授权人员做出并确认`
-- 未满足 → 标记 `HR-4 NON_COMPLIANT`
+- 未满足 → 标记 `HIGH_RISK_4 NON_COMPLIANT`
 
-**ELSE**：标注 `HR-4 N/A`
+**ELSE**：标注 `HIGH_RISK_4 N/A`
 
 ### Phase 4：分场景安全控制检查
 
@@ -428,21 +428,21 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 | 编号 | 红线 | 状态 | 说明 |
 | ---- | ---- | ---- | ---- |
-| RL-1 | 敏感数据输入外部 AI | ✅ 合规 / ❌ 违规 / N/A | {detail} |
-| RL-2 | 凭证泄露 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
-| RL-3 | AI 直接执行高风险操作 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
-| RL-4 | 未审批接入外部 AI 或 API | ✅ 合规 / ❌ 违规 / N/A | {detail} |
-| RL-5 | 使用公司数据训练外部模型 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
-| RL-6 | 滥用公司 AI 资源 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_1 | 敏感数据输入外部 AI | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_2 | 凭证泄露 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_3 | AI 直接执行高风险操作 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_4 | 未审批接入外部 AI 或 API | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_5 | 使用公司数据训练外部模型 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
+| RED_LINE_6 | 滥用公司 AI 资源 | ✅ 合规 / ❌ 违规 / N/A | {detail} |
 
 ## 三、二级红线检查结果
 
 | 编号 | 行为类型 | 状态 | 控制条件满足情况 |
 | ---- | -------- | ---- | ---------------- |
-| HR-1 | AI 自动化执行 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
-| HR-2 | Agent 多系统调用 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
-| HR-3 | Workflow 自动决策 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
-| HR-4 | AI 辅助决策 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
+| HIGH_RISK_1 | AI 自动化执行 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
+| HIGH_RISK_2 | Agent 多系统调用 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
+| HIGH_RISK_3 | Workflow 自动决策 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
+| HIGH_RISK_4 | AI 辅助决策 | ✅ 合规 / ⚠️ 不合规 / N/A | {detail} |
 
 ## 四、分场景安全控制
 
@@ -465,8 +465,8 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 | 优先级 | 问题 | 红线编号 | 整改要求 | 责任方 | 期限 |
 | ------ | ---- | -------- | -------- | ------ | ---- |
-| P0 | {issue} | RL-{N} | {action} | {owner} | 立即 |
-| P1 | {issue} | HR-{N} | {action} | {owner} | {date} |
+| P0 | {issue} | RED_LINE_{N} | {action} | {owner} | 立即 |
+| P1 | {issue} | HIGH_RISK_{N} | {action} | {owner} | {date} |
 
 ## 七、审计结论
 
@@ -483,8 +483,8 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 - **人机协同要求**：{从 Phase 5 提取的必须插入人工确认的操作列表}
 ```
 
-> GOOD：`RL-2 ✅ 合规 — grep 扫描 src/ 和 config/ 共 3 处命中：(1) config/example.env 为占位符 "YOUR_API_KEY"，(2) src/auth.ts:12 从环境变量读取 process.env.SECRET_KEY 未硬编码，(3) tests/mock.ts:5 为测试 mock 值。逐一排查后确认无真实凭证泄露。`
-> BAD：`RL-2 ✅ 合规 — 未发现硬编码凭证。`
+> GOOD：`RED_LINE_2 ✅ 合规 — grep 扫描 src/ 和 config/ 共 3 处命中：(1) config/example.env 为占位符 "YOUR_API_KEY"，(2) src/auth.ts:12 从环境变量读取 process.env.SECRET_KEY 未硬编码，(3) tests/mock.ts:5 为测试 mock 值。逐一排查后确认无真实凭证泄露。`
+> BAD：`RED_LINE_2 ✅ 合规 — 未发现硬编码凭证。`
 > （缺少扫描范围、命中数量、逐条排查过程——无法判断是真合规还是扫描不充分）
 
 ### Phase 7：违规路由与回退
@@ -495,12 +495,12 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 
 **MATCH** `violation_level`：
 
-- `RL-*`（一级红线违规）：
+- `RED_LINE_*`（一级红线违规）：
   1. **WRITE** `docs/security-audit.md` — 写入已完成的检查结果 + 违规详情
   2. **WRITE**（对话中）违规详情：
 
      ```
-     🚨 红线违规：{RL-N} {红线名称}
+     🚨 红线违规：{RED_LINE_N} {红线名称}
      违规行为：{具体行为描述}
      涉及位置：{文件路径:行号}
      证据：{grep/代码片段}
@@ -512,7 +512,7 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
      - 规格层问题（SDD 设计违反安全原则、缺少安全约束）→ **ROLLBACK** team-spec，附：缺失的安全要求 + 建议补充内容
      - 流程/审批问题（未审批接入外部 AI、资源滥用）→ **ASK_HUMAN**：人类立即介入
      - *DEFAULT* → **BLOCKED** + **ASK_HUMAN**
-- `HR-*`（二级红线不合规）：
+- `HIGH_RISK_*`（二级红线不合规）：
   1. **WRITE** 整改建议到 `docs/security-audit.md` §六
   2. **MATCH** `hr_source`：
      - 实现层缺失控制机制 → **ROLLBACK** team-impl，附：需补充的控制机制
@@ -556,7 +556,7 @@ NO AI OPERATIONS WITHOUT RED LINE CHECK FIRST
 - [ ] **ASSERT** `high_risk_checked == 4` — 4 条二级红线全部检查（含 N/A 标注）
 - [ ] **ASSERT** `RL_violation == 0` || `ASK_HUMAN 已触发` — 一级红线违规已触发人类介入
 - [ ] **ASSERT** `docs/security-audit.md EXISTS` && CONTAINS 八个章节（含 §八 安全约束参考）
-- [ ] **EXEC** `grep -cE 'RL-[1-6]|HR-[1-4]' docs/security-audit.md` → **ASSERT** `output >= 10` — 红线编号均已记录
+- [ ] **EXEC** `grep -cE 'RED_LINE_[1-6]|HIGH_RISK_[1-4]' docs/security-audit.md` → **ASSERT** `output >= 10` — 红线编号均已记录
 - [ ] **ASSERT** `整改清单` NOT_EMPTY（如有不合规项）|| `全部合规`
 - [ ] **ASSERT** `无占位符残留（{N}、{slug} 等已被实际值替换）`
 - [ ] **ASSERT** `IRON_LAW 遵守` — 一级红线违规已触发 ASK_HUMAN，未擅自降级

package/skills/team-spec/SKILL.md

@@ -202,6 +202,9 @@ NO CODE WITHOUT SPEC FIRST
 | E{N} | {异常名} | {何时发生} | {code} | {message} | {status} |
 ```
 
+> SIGNAL：§八 异常场景中没有并发相关条目（竞态条件、死锁、重复提交）→ 若系统有并发访问，需补充并发异常场景。
+> SIGNAL：§七/§八 中没有兼容性条目（旧版客户端、旧格式数据、API 版本迁移）→ 若涉及接口变更或数据格式变更，需补充向后兼容场景。
+
 `01-plan.md` 核心骨架：
 
 ```markdown
@@ -221,6 +224,15 @@ NO CODE WITHOUT SPEC FIRST
 |----|------|-----------------|
 | P1 | {最小闭环} | {何时放弃} |
 | P2 | {增强功能} | {何时放弃} |
+
+## 容量与成本预估（如适用）
+
+| 维度 | 当前/预估值 | 约束 |
+|------|-----------|------|
+| 数据量级 | {行数/文档数/日增量} | {上限或增长趋势} |
+| QPS/并发 | {峰值请求量} | {系统承载能力} |
+| 外部 API 成本 | {调用频次 × 单价} | {月度预算上限} |
+| 存储增长 | {月增量} | {存储配额} |
 ```
 
 #### 占位符零容忍
@@ -252,9 +264,9 @@ NO CODE WITHOUT SPEC FIRST
 - [ ] **ASSERT** `来源标签（{extracted}/{inferred}/{ambiguous}）标注数 >= 1`
 - [ ] **ASSERT** `修改类任务用 Delta Spec` || `新建类任务用完整 SDD`
 - [ ] **ASSERT** `"TBD"/"TODO"/"待补充" 匹配数 == 0`
-- [ ] **IF** SDD 涉及外部 AI 服务调用 → **ASSERT** `§五 输入/输出规格中标注数据分类和脱敏策略`（RL-1）
-- [ ] **IF** SDD 涉及高风险操作（资金/权限/数据删除/对外发布）→ **ASSERT** `§二 业务规则中 CONTAINS 人工确认机制设计`（RL-3）
-- [ ] **IF** SDD 引入新的外部 AI 模型/服务 → **ASSERT** `§三 关键设计决策中记录审批状态`（RL-4）
+- [ ] **IF** SDD 涉及外部 AI 服务调用 → **ASSERT** `§五 输入/输出规格中标注数据分类和脱敏策略`（`team-security: RED_LINE_1`）
+- [ ] **IF** SDD 涉及高风险操作（资金/权限/数据删除/对外发布）→ **ASSERT** `§二 业务规则中 CONTAINS 人工确认机制设计`（`team-security: RED_LINE_3`）
+- [ ] **IF** SDD 引入新的外部 AI 模型/服务 → **ASSERT** `§三 关键设计决策中记录审批状态`（`team-security: RED_LINE_4`）
 - [ ] 如果把这份 SDD 交给一个完全不了解项目的开发者，他能否仅凭 SDD 写出实现？哪部分他会困惑？
 - [ ] 我是否因为"显而易见"而跳过了某个边界条件的描述？
 
@@ -266,6 +278,7 @@ NO CODE WITHOUT SPEC FIRST
 | 分期 | P1 最小闭环 + 后续候选 + Kill Switch 条件、阶段拆分 ≥ 5 |
 | 上下文 | 术语表 ≥ 3 个（标注模块）、引用 ≥ 3 文件、排除 ≥ 1 文件 |
 | 风险 | 风险 ≥ 2 条（含缓解措施）、Kill Switch ≥ 2 个、停下来问人 ≥ 3 条 |
+| 容量成本 | 涉及数据存储/外部 API/高并发场景时，容量与成本预估已声明（无相关场景则标注 N/A） |
 | 架构 | SDD 含 ASCII 数据流图 |
 | 工具 | prompt-template.md 独立产出（五要素）、pm-truth-ledger 已追加（`IF` EXISTS） |
 

package/skills/team-test/SKILL.md

@@ -103,13 +103,15 @@ Phase 1 只分析，不写测试代码。
 
 | 维度         | 覆盖要求                                   | 检查方法                              |
 | ------------ | ------------------------------------------ | ------------------------------------- |
-| **功能覆盖** | SDD 中每个输入、输出、业务规则至少一个测试 | 逐条对照 03-sdd.md §五/§六            |
+| **功能覆盖** | SDD 中每个输入、输出、业务规则至少一个测试；跨模块/跨服务集成路径至少一个端到端测试（SDD §四 数据流有跨模块调用时） | 逐条对照 03-sdd.md §五/§六            |
 | **边界覆盖** | SDD §七 每个边界条件至少一个测试           | 逐条对照 03-sdd.md §七                |
 | **异常覆盖** | SDD §八 每个异常场景至少一个测试           | 逐条对照 03-sdd.md §八                |
 | **代码覆盖** | 有覆盖率工具 → 运行报告分支覆盖率；无 → 手动列出 if/else/match/try-catch 分支确认覆盖 | 覆盖率工具 或 逐分支确认 |
 
 矩阵中每个测试用例必须标注覆盖维度（功能/边界/异常/代码），一个用例可覆盖多个维度。
 
+> TRAP：只设计了单元测试而遗漏了集成/E2E 测试——当 SDD §四 数据流涉及跨模块调用或外部服务交互时，功能覆盖维度必须包含端到端集成路径的测试用例。测试矩阵中"功能覆盖"全是单函数级别 → 集成路径可能无测试。
+
 **WRITE** `09-test-matrix.md` 输出骨架：
 
 | 用例 ID | 场景描述 | 期望结果 | 覆盖维度 | SDD 追踪 | 来源标签 | 状态 |