team-skills 1.3.9 → 1.5.0

package/CHANGELOG.md

@@ -7,6 +7,53 @@
 
 ## [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
+
+### 新增
+
+- `team-range` 开发者命令：逐文件遍历项目文件执行用户指定操作，修改后重检直到干净再处理下一个
+
+### 变更
+
+- CLAUDE.md §2.2 引用规范更新：新增 `**REF**` 关键词统一外部规则引用格式，新增内联引用反引号格式规范
+- README 对齐 CLAUDE.md 命名规范：Agent 类名 → Skill 名称、H1-H4 → 正式介入点名称（CONFIRM_GOAL/CONFIRM_SPEC/ASK_HUMAN/HUMAN_ACCEPT）、Mermaid 核心架构图节点标签同步更新
+- `team-refine` 打磨顺序调整
+
+### 修复
+
+- 29 个文件全量一致性修复：22 处 Skill 名称反引号统一、4 处角色命名统一（"Agent" → "Skill"）、5 处模板章节编号修正
+- README 事实修正：SDD 章节数 7→9、设计原则数 20→21、refine 维度数修正、开发者命令表补齐 `/team-range`
+
 ## [1.3.9] - 2026-06-27
 
 ### 新增

package/README.md

@@ -38,7 +38,7 @@
 
 ```
 传统方式：用户 → AI（一句话）→ 代码（随机产出）
-Team Skills：用户 → H1确认 → SDD规格 → H2确认 → TDD实现 → 测试 → Review → H4验收
+Team Skills：用户 → CONFIRM_GOAL → SDD 规格 → CONFIRM_SPEC → TDD 实现 → 测试 → Review → HUMAN_ACCEPT
 ```
 
 每个环节有明确的输入/输出标准，AI 不是"猜需求"，而是**执行规格**。
@@ -46,8 +46,8 @@ Team Skills：用户 → H1确认 → SDD规格 → H2确认 → TDD实现 →
 ### 🔄 有向图回退，不是线性流水线
 
 ```
-testAgent 发现 bug ──→ 自动回退 implAgent
-reviewAgent 发现 spec 遗漏 ──→ 自动回退 specAgent
+team-test 发现 bug ──→ 自动回退 team-impl
+team-review 发现 spec 遗漏 ──→ 自动回退 team-spec
 同一阶段回退 ≤ 2 次，超过触发人类介入
 ```
 
@@ -63,7 +63,7 @@ reviewAgent 发现 spec 遗漏 ──→ 自动回退 specAgent
 ### 📝 规则沉淀，不是"每次从零"
 
 - **三层规则体系**：项目级 → 模块级 → 任务级，冲突按优先级覆盖
-- **消费方契约**：每条规则含触发条件 + 可执行指令 + 示例，下游 Agent 可直接执行
+- **消费方契约**：每条规则含触发条件 + 可执行指令 + 示例，下游 Skill 可直接执行
 
 ### 📊 量化评估，不是"凭感觉"
 
@@ -156,7 +156,7 @@ npx team-skills@latest update
 /team-orchestrator 实现用户登录功能
 ```
 
-编排器自动完成：H1 确认目标 → specAgent 产出 SDD → H2 确认规格 → implAgent TDD 实现 → testAgent 四维测试 → reviewAgent 五维审查 → 分支完成处理 → H4 验收交付
+编排器自动完成：CONFIRM_GOAL 确认目标 → `team-spec` 产出 SDD → CONFIRM_SPEC 确认规格 → `team-impl` TDD 实现 → `team-test` 四维测试 → `team-review` 五维审查 → 分支完成处理 → HUMAN_ACCEPT 验收交付
 
 简单任务可用精简模式：
 
@@ -193,46 +193,46 @@ flowchart TD
     classDef kill fill:#ffebee,stroke:#c62828,stroke-width:2px,stroke-dasharray: 5 5,color:#b71c1c;
 
     START(("用户提出需求"))
-    H1["H1: 人类确认目标理解<br/>← 人类介入点 #1"]:::human
+    CG["CONFIRM_GOAL<br/>人类确认目标理解"]:::human
     BRANCH["创建功能分支<br/>{slug} 分支"]:::git
-    SPEC["specAgent — 规格制定<br/>产出 01-05 + prompt-template<br/>Socratic 提问 → SDD 规格"]:::agent
-    H2["H2: 人类确认规格方案<br/>← 人类介入点 #2"]:::human
-    IMPL["implAgent — TDD 实现<br/>红-绿-重构循环<br/>增量提交 + 决策记录"]:::agent
-    TEST["testAgent — 四维测试<br/>功能/边界/异常/代码分支"]:::agent
-    REVIEW["reviewAgent — 五维审查<br/>资产沉淀 + 复盘"]:::agent
+    SPEC["team-spec — 规格制定<br/>产出 01-05 + prompt-template<br/>Socratic 提问 → SDD 规格"]:::agent
+    CS["CONFIRM_SPEC<br/>人类确认规格方案"]:::human
+    IMPL["team-impl — TDD 实现<br/>红-绿-重构循环<br/>增量提交 + 决策记录"]:::agent
+    TEST["team-test — 四维测试<br/>功能/边界/异常/代码分支"]:::agent
+    REVIEW["team-review — 五维审查<br/>资产沉淀 + 复盘"]:::agent
     FINISH["team-finish — 分支完成<br/>merge / PR / keep"]:::git
-    H4["H4: 人类验收交付物<br/>← 人类介入点 #4"]:::human
-    H3("H3: 人类介入 #3<br/>阻塞 / 决策 / Kill Switch"):::human
+    HA["HUMAN_ACCEPT<br/>人类验收交付物"]:::human
+    AH("ASK_HUMAN<br/>阻塞 / 决策 / Kill Switch"):::human
 
-    START --> H1
-    H1 -->|确认| BRANCH
-    H1 -->|不确认| START
+    START --> CG
+    CG -->|确认| BRANCH
+    CG -->|不确认| START
 
     BRANCH --> SPEC
-    SPEC --> H2
-    H2 -->|确认| IMPL
-    H2 -->|不确认| SPEC
-    H2 -.->|Kill Switch| H3
+    SPEC --> CS
+    CS -->|确认| IMPL
+    CS -->|不确认| SPEC
+    CS -.->|Kill Switch| AH
 
     IMPL --> TEST
 
     TEST -->|全部通过| REVIEW
     TEST -->|发现 bug| IMPL
     TEST -->|spec 遗漏| SPEC
-    TEST -.->|不可行| H3
+    TEST -.->|不可行| AH
 
     REVIEW -->|无问题| FINISH
     REVIEW -->|P0/P1| IMPL
     REVIEW -->|spec 遗漏| SPEC
-    REVIEW -.->|不可行| H3
+    REVIEW -.->|不可行| AH
 
-    FINISH --> H4
-    H4 -->|验收通过| DONE(("完成 ✅"))
-    H4 -->|不通过| IMPL
+    FINISH --> HA
+    HA -->|验收通过| DONE(("完成 ✅"))
+    HA -->|不通过| IMPL
 ```
 
-> H3 可在**任何阶段**触发，包括：发现任务不可行（Kill Switch）、回退超限、或需要人类决策的复杂问题。
-> 功能分支在 H1 确认后自动创建，在 Review 通过后由 team-finish 处理（merge/PR/keep/discard）。
+> ASK_HUMAN 可在**任何阶段**触发，包括：发现任务不可行（Kill Switch）、回退超限、或需要人类决策的复杂问题。
+> 功能分支在 CONFIRM_GOAL 确认后自动创建，在 Review 通过后由 `team-finish` 处理（merge/PR/keep/discard）。
 
 ---
 
@@ -310,7 +310,7 @@ docs/
 │   │   ├── 00-design-brief.md      #   设计概要（team-brainstorm 产出，可选）
 │   │   ├── 01-plan.md              #   任务规划（目标 + 分期 + 预算）
 │   │   ├── 02-context.md           #   上下文选择（术语 + 引用 + 排除）
-│   │   ├── 03-sdd.md              #   SDD 规格（七部分完整）
+│   │   ├── 03-sdd.md              #   SDD 规格（九章节完整）
 │   │   ├── 04-boundary.md          #   修改边界（allow + deny）
 │   │   ├── 05-risk.md              #   风险 + 验证计划
 │   │   ├── prompt-template.md      #   AI 任务提示词模板
@@ -369,7 +369,7 @@ Team Skills 融合了业界多个 AI 协作框架的精华：
 | **OpenSpec** (Fission AI) | Delta Spec 增量规格、RFC 2119 + Given/When/Then |
 | **Karpathy Skills** | 过度抽象防御、死代码清理、困惑管理 |
 | **Agent-Style** | 5 条 LLM 输出质量约束 |
-| **独创** | 有向图回退、质量追溯矩阵、消费方契约、H1-H4 人类介入点、100 分制量化评估、Skill Spec Language（20 条设计原则） |
+| **独创** | 有向图回退、质量追溯矩阵、消费方契约、CONFIRM_GOAL-HUMAN_ACCEPT 人类介入点、100 分制量化评估、Skill Spec Language（21 条设计原则） |
 
 ---
 
@@ -392,7 +392,7 @@ npm run setup      # 安装 Skills 到全局目录
 
 ### Skill 编写规范
 
-编写或修改 Skill 时，请参考 `CLAUDE.md` §2.8（Skill Spec：格式约定 + 关键词参考 + 设计原则）。
+编写或修改 Skill 时，请参考 `CLAUDE.md` §2.7（Skill Spec：格式约定 + 关键词参考 + 设计原则）。
 
 ### 开发者斜杠命令（Claude Code）
 
@@ -400,7 +400,8 @@ npm run setup      # 安装 Skills 到全局目录
 
 | 命令 | 说明 | 参数 |
 |------|------|------|
-| `/team-refine` | 对抗审计（10 维度）+ 执行质量打磨（5 维度），按编排流程顺序逐 Skill 精炼到收敛 | 轮次数，默认 5 |
+| `/team-refine` | 改进飞轮：规范 ↔ SKILL.md 双向对抗审计（15 维度）+ LLM 执行质量打磨，逐轮收敛 | 轮次数，默认 5 |
+| `/team-range` | 逐文件遍历：对项目文件逐个执行指定操作，修改后重检直到干净 | `--scope skills\|rules\|commands\|all\|<glob>` + 操作描述 |
 | `/team-release` | 版本发布：更新 package.json + CHANGELOG，运行 install/format/lint/cli-test | `patch` / `minor` / `major` / `x.y.z` |
 
 ### CI 流程

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "team-skills",
-  "version": "1.3.9",
+  "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          ← 仅本任务适用
 ```
@@ -28,7 +28,7 @@
   - ❌ 错误：{坏的做法}
 ```
 
-不满足三要素的规则视为"空口号"，team-review **MUST** 补全或删除。
+不满足三要素的规则视为"空口号"，`team-review` **MUST** 补全或删除。
 
 ### 1.3 资产维护机制
 
@@ -45,14 +45,14 @@
 
 | 内容类别    | 定义位置                                                                  |
 | ----------- | ------------------------------------------------------------------------- |
-| 业务术语    | team-spec `02-context.md` 模板（术语表）                                  |
-| 系统架构    | orchestrator 有向图流程图 + team-spec `03-sdd.md` §四 数据流              |
-| 代码结构    | `_team-rules/task-lifecycle.md` §1（17 文件目录结构）                     |
-| 接口约定    | 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 实例）                       |
-| 交付要求    | orchestrator Step 8 完整性检查                                            |
+| 业务术语    | `team-spec` `02-context.md` 模板（术语表）                                |
+| 系统架构    | `team-orchestrator` 有向图流程图 + `team-spec` `03-sdd.md` §四 数据流     |
+| 代码结构    | `_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 实例）+ `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

@@ -7,7 +7,7 @@
 ### 1.1 规格先于代码
 
 - 任何功能实现必须有对应的 SDD（Software Design Document）作为输入
-- SDD 是 team-impl 和 team-test 的唯一规格来源——不依赖口头约定或聊天记录
+- SDD 是 `team-impl` 和 `team-test` 的唯一规格来源——不依赖口头约定或聊天记录
 - 修改类任务使用 Delta Spec（ADDED/MODIFIED/REMOVED），新建类任务使用完整 SDD
 
 ### 1.2 SDD 九章节质量标准
@@ -17,14 +17,14 @@
 | 章节          | 内容                                                       | 消费方                       |
 | ------------- | ---------------------------------------------------------- | ---------------------------- |
 | §一 背景与动机    | 为什么做、痛点、用户场景                                   | 所有 Agent                   |
-| §二 业务规则      | RFC 2119 强度标记（MUST/SHOULD/MAY）+ Given/When/Then 场景 | team-test → 直接映射测试用例 |
-| §三 关键设计决策  | 选择方案 + 拒绝方案 + 拒绝理由                             | team-review → 审查决策合理性 |
-| §四 数据流总览    | ASCII 架构图                                               | team-impl → 理解调用链路     |
-| §五 输入规格 | 参数类型、约束、默认值、示例                               | team-impl + team-test        |
-| §六 输出规格 | 场景、HTTP 状态、输出结构、示例                            | team-impl + team-test        |
-| §七 边界条件      | 空值、极值、并发、格式异常                                 | team-test → 边界测试         |
-| §八 异常场景      | 错误码、错误消息、HTTP 状态                                | team-test → 异常测试         |
-| §九 验收 Checklist | 验收条件、验证方式、预期结果                               | team-review → 验收检查       |
+| §二 业务规则      | RFC 2119 强度标记（MUST/SHOULD/MAY）+ Given/When/Then 场景 | `team-test` → 直接映射测试用例 |
+| §三 关键设计决策  | 选择方案 + 拒绝方案 + 拒绝理由                             | `team-review` → 审查决策合理性 |
+| §四 数据流总览    | ASCII 架构图                                               | `team-impl` → 理解调用链路     |
+| §五 输入规格 | 参数类型、约束、默认值、示例                               | `team-impl` + `team-test`        |
+| §六 输出规格 | 场景、HTTP 状态、输出结构、示例                            | `team-impl` + `team-test`        |
+| §七 边界条件      | 空值、极值、并发、兼容性变更、格式异常                     | `team-test` → 边界测试         |
+| §八 异常场景      | 错误码、错误消息、HTTP 状态                                | `team-test` → 异常测试         |
+| §九 验收 Checklist | 验收条件、验证方式、预期结果                               | `team-review` → 验收检查       |
 
 ### 1.3 规格驱动的验证链
 
@@ -72,10 +72,10 @@ COMMIT: git commit（每个功能点一次，不攒多个功能点）
 
 | 发现者      | 问题类型         | 回退目标           |
 | ----------- | ---------------- | ------------------ |
-| team-test   | 实现 bug         | → team-impl        |
-| team-test   | SDD 未定义的场景 | → team-spec        |
-| team-review | P0/P1 实现 bug   | → team-impl        |
-| team-review | spec 遗漏        | → team-spec        |
+| `team-test`   | 实现 bug         | → `team-impl`        |
+| `team-test`   | SDD 未定义的场景 | → `team-spec`        |
+| `team-review` | P0/P1 实现 bug   | → `team-impl`        |
+| `team-review` | spec 遗漏        | → `team-spec`        |
 | 任何 Agent  | 任务不可行       | → Kill Switch → ASK_HUMAN |
 
 ### 3.2 回退携带上下文

package/skills/_team-rules/task-lifecycle.md

@@ -56,7 +56,7 @@ docs/tasks/{NNNN}-{keyword}/
 | 介入点 | 时机             | 目的                               |
 | ------ | ---------------- | ---------------------------------- |
 | CONFIRM_GOAL     | 编排器初始化后   | 确认目标理解 + 方案方向            |
-| CONFIRM_SPEC     | team-spec 产出后 | 确认规格方案 + 分期策略            |
+| CONFIRM_SPEC     | `team-spec` 产出后 | 确认规格方案 + 分期策略            |
 | ASK_HUMAN     | 发现阻塞/需决策  | 人类决策（Kill Switch / 方案选择） |
 | HUMAN_ACCEPT     | 全部完成后       | 验收交付物 + P2 决策               |
 

package/skills/_team-rules/verification-protocol.md

@@ -19,7 +19,7 @@
 
 ```
 
-违反此协议的声明视为无效，team-review MUST 标记为 P0。
+违反此协议的声明视为无效，`team-review` MUST 标记为 P0。
 
 ## 结构化证据格式
 

package/skills/team-brainstorm/SKILL.md

@@ -92,7 +92,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 > TRAP：你会倾向于接受用户的初始框架，不质疑其前提假设。
 > 用户说"我需要一个缓存层"——但也许问题根源是查询太慢，缓存只是用户想到的第一个方案。
 
-> 一次最多 3 个问题，优先用选项形式降低用户认知负担（First Principle #1）。
+> 一次最多 3 个问题，优先用选项形式降低用户认知负担 `_team-rules/first-principles.md: First Principle #1`。
 
 向用户展示最多 3 个关键问题，等待用户一次回复：
 
@@ -137,7 +137,7 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ### Phase 4：展示设计
 
-> 逐段确认而非一次倾倒，每段确认后再展示下一段。目标是让用户在每个维度上做出知情决策，而非被信息量压垮后草率同意（First Principle #1）。
+> 逐段确认而非一次倾倒，每段确认后再展示下一段。目标是让用户在每个维度上做出知情决策，而非被信息量压垮后草率同意 `_team-rules/first-principles.md: First Principle #1`。
 
 逐段展示设计，每段后等待用户确认：
 
@@ -242,11 +242,14 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ## CONSTITUTIONAL_RULES
 
-引用 `_team-rules/constitutional-rules.md`。brainstorm 阶段尤其注意：
+**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 
-- **Rule #1 人类介入是一等公民**：每个方案设计决策必须等待用户确认，不可擅自决定（First Principle #1）
-- **Rule #5 分期交付优先**：方案设计时主动考虑分期交付（First Principle #3）
-- **Rule #4 Kill Switch**：如果探索阶段发现需求不可行，立即暂停而非继续设计（First Principle #1 + First Principle #3）
+brainstorm 阶段尤其注意：
+
+- **Rule #1 人类介入是一等公民**：每个方案设计决策必须等待用户确认，不可擅自决定 `_team-rules/first-principles.md: First Principle #1`
+- **Rule #5 分期交付优先**：方案设计时主动考虑分期交付 `_team-rules/first-principles.md: First Principle #3`
+- **Rule #4 Kill Switch**：如果探索阶段发现需求不可行，立即暂停而非继续设计 `_team-rules/first-principles.md: First Principle #1 + First Principle #3`
 
 ## SELF_CHECK
 
@@ -264,6 +267,8 @@ NO IMPLEMENTATION WITHOUT USER APPROVED DESIGN FIRST
 
 ## COMPLETION
 
+**REF** `_team-rules/four-state-protocol.md` — 四态完成状态
+
 **MATCH** `result`：
 
 - 用户确认设计 + `00-design-brief.md` 已写入 → **DONE**

package/skills/team-debug/SKILL.md

@@ -16,7 +16,7 @@ description: Use when encountering any bug, test failure, or unexpected behavior
 
 ### 推理检查点
 
-> 每次修复必须能解释"为什么之前坏了"。"应该能修好"是无效声明（First Principle #4）。95% 的"找不到根因"是调查不充分。
+> 每次修复必须能解释"为什么之前坏了"。"应该能修好"是无效声明 `_team-rules/first-principles.md: First Principle #4`。95% 的"找不到根因"是调查不充分。
 
 **推理框架**：
 
@@ -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**，提交以下信息：
@@ -174,7 +174,7 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 ## STOP_SIGNALS
 
 - **跳过**根因调查直接写修复代码
-- **同时**修改多个变量，无法隔离有效改动
+- **修改**多个变量同时进行，无法隔离有效改动
 - **继续**尝试 3 次修复失败后仍不触发 `ASK_HUMAN`
 - **绕过**调查流程（"先快速修一下，后面再查根因"）
 
@@ -204,12 +204,16 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## CONSTITUTIONAL_RULES
 
-引用 `_team-rules/constitutional-rules.md`。调试阶段尤其注意：
+**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
+**REF** `_team-rules/verification-protocol.md` — 5 步验证协议
 
-- **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码（First Principle #2）
-- **Rule #3 产出必须验证**：修复完成后必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤（First Principle #4）
-- **Rule #7 回退次数上限**：3 次修复失败必须触发 `ASK_HUMAN`，不可无限重试（First Principle #1）
-- **Rule #2 有向图回退**：调试发现根源在 spec 歧义/遗漏 → `ROLLBACK` team-spec（First Principle #4）
+调试阶段尤其注意：
+
+- **Rule #9 TDD 顺序不可逆**：修复 bug 必须先写失败的回归测试再写修复代码 `_team-rules/first-principles.md: First Principle #2`
+- **Rule #3 产出必须验证**：修复完成后必须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤` `_team-rules/first-principles.md: First Principle #4`
+- **Rule #7 回退次数上限**：3 次修复失败必须触发 `ASK_HUMAN`，不可无限重试 `_team-rules/first-principles.md: First Principle #1`
+- **Rule #2 有向图回退**：调试发现根源在 spec 歧义/遗漏 → `ROLLBACK` `team-spec` `_team-rules/first-principles.md: First Principle #4`
 
 ## SELF_CHECK
 
@@ -227,6 +231,8 @@ NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
 
 ## COMPLETION
 
+**REF** `_team-rules/four-state-protocol.md` — 四态完成状态
+
 **MATCH** `result`：
 
 - 根因确定 + 修复验证通过 → **DONE**

package/skills/team-feedback/SKILL.md

@@ -128,7 +128,7 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 ### Phase 4：实施
 
-> 逐项实施、逐项测试。批量实施后再测试 = 出问题时无法定位是哪项修改引入的（First Principle #2）。全部单项通过后再跑全量测试确认无交叉回归。
+> 逐项实施、逐项测试。批量实施后再测试 = 出问题时无法定位是哪项修改引入的 `_team-rules/first-principles.md: First Principle #2`。全部单项通过后再跑全量测试确认无交叉回归。
 
 > TRAP：你会倾向于修改实现去匹配反馈，而不检查反馈是否与 SDD 一致。
 > 实施前先确认：这项修改是让代码更接近 SDD，还是偏离 SDD？偏离 → 先路由 team-spec。
@@ -161,7 +161,7 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
    |--------|------|------|----------|----------|----------|
    | {feedback_desc} | {reviewer} | 接受 / 推回 / 部分接受 | {evidence} | {change_desc} | ✅/❌ `{test_output}` |
 
-**验证协议**（步骤 3-4 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+**验证协议**：步骤 3-4 声明"通过"前必须执行 `_team-rules/verification-protocol.md: 验证执行步骤`
 
 ## 禁止回应
 
@@ -215,16 +215,19 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 - **实施**反馈建议前没有验证技术正确性
 - **回应**"你说得太对了""好主意"等表演性同意
-- **批量**实施多项反馈而不逐项测试
+- **跳过**逐项测试而批量实施多项反馈
 - **忽略**外部反馈与代码库现实的冲突而不推回
 
 ## CONSTITUTIONAL_RULES
 
-引用 `_team-rules/constitutional-rules.md`。反馈处理阶段尤其注意：
+**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 
-- **Rule #9 TDD 顺序不可逆**：每项修改必须单独测试，不可批量实施后再测试（First Principle #2）
-- **Rule #2 有向图回退**：反馈揭示 spec 遗漏 → 回退 team-spec，不可擅自决定（First Principle #4）
-- **Rule #1 人类介入是一等公民**：反馈揭示架构问题 → 触发 `ASK_HUMAN`（First Principle #1）
+反馈处理阶段尤其注意：
+
+- **Rule #9 TDD 顺序不可逆**：每项修改必须单独测试，不可批量实施后再测试 `_team-rules/first-principles.md: First Principle #2`
+- **Rule #2 有向图回退**：反馈揭示 spec 遗漏 → 回退 `team-spec`，不可擅自决定 `_team-rules/first-principles.md: First Principle #4`
+- **Rule #1 人类介入是一等公民**：反馈揭示架构问题 → 触发 `ASK_HUMAN` `_team-rules/first-principles.md: First Principle #1`
 
 ## SELF_CHECK
 
@@ -244,6 +247,8 @@ NO IMPLEMENTATION WITHOUT TECHNICAL VERIFICATION FIRST
 
 ## COMPLETION
 
+**REF** `_team-rules/four-state-protocol.md` — 四态完成状态
+
 **WRITE**（对话中）反馈处理摘要：
 
 ```

package/skills/team-finish/SKILL.md

@@ -18,7 +18,7 @@ description: Use when implementation is complete, all tests pass, and you need t
 
 ### 推理检查点
 
-> 测试未通过 = 不展示合并选项（First Principle #4）。用户未选择 = 不执行操作（First Principle #1）。每步有明确前置条件。
+> 测试未通过 = 不展示合并选项 `_team-rules/first-principles.md: First Principle #4`。用户未选择 = 不执行操作 `_team-rules/first-principles.md: First Principle #1`。每步有明确前置条件。
 
 **推理框架**：
 
@@ -66,7 +66,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 > TRAP：你会倾向于引用上一轮的测试结果来跳过重新执行。Iron Law 不允许——每次进入 finish 都必须重新运行。
 
-**EXEC** 项目测试命令（声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+**EXEC** 项目测试命令 — 声明"通过"前须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤`
 
 **ASSERT** `exit_code == 0` && `failures == 0`
 
@@ -75,13 +75,13 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
   - `orchestrated` → **ROLLBACK** 编排器，向编排器报告：建议路由到 `team-impl`（附上失败输出）
   - *DEFAULT* → **WRITE**（对话中）失败详情，推荐 `team-debug`，修复后 **GOTO** Step 1
 
-> 不可忽略失败继续展示选项（First Principle #4）。
+> 不可忽略失败继续展示选项 `_team-rules/first-principles.md: First Principle #4`。
 
 ### Step 1.5：凭证泄露扫描
 
 > 推送前最后一道安全防线。凭证泄露一旦进入远程仓库，撤回成本极高。
 
-**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
@@ -138,7 +138,7 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
        - **GOTO** 子步骤 4.1
      - **ELSE**：
        - 继续下一步
-  3. **EXEC** 项目测试命令（声明"通过"前须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
+  3. **EXEC** 项目测试命令 — 声明"通过"前须执行验证协议 `_team-rules/verification-protocol.md: 验证执行步骤`
      - **ASSERT** `exit_code == 0` && `failures == 0`
        - 失败 → 记录回归详情 → **BLOCKED**
   4. **EXEC** `git branch -d {branch}`
@@ -279,11 +279,14 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ## CONSTITUTIONAL_RULES
 
-引用 `_team-rules/constitutional-rules.md`。分支完成阶段尤其注意：
+**REF** `_team-rules/constitutional-rules.md` — 9 条 Constitutional Rules
+**REF** `_team-rules/first-principles.md` — 4 条第一性原理（First Principle #1 ~ #4）
 
-- **Rule #1 人类介入是一等公民**：所有分支操作（合并/PR/丢弃）必须等待用户明确选择（First Principle #1）
-- **Rule #8 验证先行**：展示选项前必须通过新鲜测试执行验证（First Principle #4）
-- **Rule #3 产出必须验证**：合并后必须重新运行测试确认无回归（First Principle #4）
+分支完成阶段尤其注意：
+
+- **Rule #1 人类介入是一等公民**：所有分支操作（合并/PR/丢弃）必须等待用户明确选择 `_team-rules/first-principles.md: First Principle #1`
+- **Rule #8 验证先行**：展示选项前必须通过新鲜测试执行验证 `_team-rules/first-principles.md: First Principle #4`
+- **Rule #3 产出必须验证**：合并后必须重新运行测试确认无回归 `_team-rules/first-principles.md: First Principle #4`
 
 ## SELF_CHECK
 
@@ -304,6 +307,8 @@ NO BRANCH COMPLETION WITHOUT TEST VERIFICATION FIRST
 
 ## COMPLETION
 
+**REF** `_team-rules/four-state-protocol.md` — 四态完成状态
+
 **MATCH** `result`：
 
 - `操作成功` → **DONE**