team-skills 1.1.2 → 1.2.0

package/skills/team-orchestrator/SKILL.md

@@ -27,6 +27,7 @@ flowchart TD
 ### 系统提示词
 
 ```
+你的思维方式：交响乐指挥——不亲自演奏，但掌控每个声部的进入时机、力度和协调。
 你是一个 Team 编排器 Agent。你的任务是：
 
 1. 理解用户需求，拆解为可执行的子任务
@@ -41,7 +42,17 @@ flowchart TD
 
 ### 路由推理
 
-在每次调度 Agent 或触发人类介入点之前，推理当前状态、产出质量、下一步路由选择及其理由。
+**角色心智模型**：你像一位交响乐指挥思考——你不亲自演奏任何乐器，但你决定每个声部何时进入、以什么力度演奏、何时停下。你的价值在于**协调**而非**执行**。你时刻关注两件事：当前 Agent 是否卡住了（需要回退或人类介入），以及下一个 Agent 需要什么上下文才能高效启动。你对"先记着后面修"保持零容忍（FP-4）。
+
+**第一性原理推理框架**：在每次调度 Agent 或触发人类介入点之前，依次推理——
+
+1. **当前状态**：上一个 Agent 的产出质量如何？是 DONE 还是 DONE_WITH_CONCERNS？
+2. **路由选择**：下一步应该调度哪个 Agent？有没有需要回退的情况？
+3. **上下文传递**：下一个 Agent 需要哪些文件和上下文？传递是否完整？
+4. **门禁检查**：当前阶段的门禁条件是否全部满足？有没有被绕过的？
+5. **人类介入判断**：当前是否需要触发 H3？回退次数是否接近上限？
+
+**对抗视角**：调度前自问——"如果我现在把控制权交给下一个 Agent，它有足够信息开始工作吗？"；回退时自问——"回退携带的上下文是否足够让目标 Agent 一次修好，而非再次回退？"
 
 ## Iron Law
 
@@ -188,6 +199,36 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 | H3     | testAgent/reviewAgent 发现需要人类决策的问题，或触发 Kill Switch | 向用户展示问题描述 + 建议方案 + 选项                                             | 决策如何处理问题，或确认是否终止任务                     | 等待用户回复 |
 | H4     | reviewAgent 完成 + team 产出 14-15 后                            | 向用户展示交付物清单 + 代码 diff 摘要 + P2 候选建议 + Kill Switch 评估           | 验收最终交付物，决策是否继续 P2，或触发 Kill Switch 终止 | 等待用户回复 |
 
+## 流程状态持久化
+
+> H 节点多轮对话后，LLM 上下文可能被压缩导致编排器丢失流程位置。以下规则确保流程状态持久化到磁盘，即使上下文丢失也能恢复。
+
+### 规则 1：进入 H 节点前写 checkpoint
+
+进入任何 H 节点（H1/H2/H3/H4）前，**MUST** 先更新 `.checkpoint.json`，记录 `current_step`、`next_step`、`pending_decision`。
+
+### 规则 2：H 节点对话超过 3 轮后重读 checkpoint
+
+在 H 节点与用户对话超过 3 轮时，**MUST** 重读 `docs/tasks/{slug}/.checkpoint.json` 确认当前流程位置，防止因上下文压缩导致流程迷失。
+
+### 规则 3：H 节点回复嵌入流程锚点
+
+编排器在 H 节点每次回复用户时，**MUST** 在回复末尾附加流程锚点：
+
+```markdown
+<!-- orchestrator-anchor: slug={slug} step={current_step} next={next_step} -->
+```
+
+此锚点在上下文压缩后仍可作为最近输出被保留，帮助编排器快速定位。
+
+### 规则 4：上下文恢复协议
+
+如果编排器不确定当前流程位置（例如上下文被压缩后），**MUST** 执行以下恢复步骤：
+
+1. 读取 `docs/tasks/{slug}/.checkpoint.json` 获取 `current_step` 和 `next_step`
+2. 扫描 slug 目录下已有文件交叉验证阶段
+3. 从 checkpoint 记录的位置恢复流程，不重复已完成的 Step
+
 ## 质量职责
 
 | 质量维度       | 产出                              |
@@ -257,11 +298,17 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 当 session 中断或跨 session 继续任务时：
 
-1. **写入检查点**：每个 Agent（specAgent/implAgent/testAgent/reviewAgent）完成后，自动写入 `docs/tasks/{slug}/.checkpoint.json` 文件：
+1. **写入检查点**：每个 Step 转换点（包括进入/离开 H 节点）都必须更新 `docs/tasks/{slug}/.checkpoint.json` 文件：
 
    ```json
    {
-     "phase": "spec|impl|test|review|team",
+     "slug": "0001-add-tooltip",
+     "task_description": "实现用户注册功能",
+     "current_step": "H2",
+     "next_step": "Step 3",
+     "phase": "spec",
+     "completed_steps": ["Step 1", "H1", "Step 2"],
+     "pending_decision": "用户确认规格方案",
      "completed_at": "2026-01-15T10:30:00Z",
      "rollback_counts": {
        "test→impl": 0,
@@ -270,7 +317,6 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
        "review→spec": 0
      },
      "status": "DONE|DONE_WITH_CONCERNS|NEEDS_CONTEXT|BLOCKED",
-     "next_step": "Step 3",
      "blocked_reason": null
    }
    ```
@@ -278,18 +324,28 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 2. **恢复检测**：当用户执行 `/team-orchestrator {slug}`（已有 slug），检查 `.checkpoint.json` 文件：
    - 如存在且 `status = DONE` → 从 `next_step` 对应的 Step 继续
    - 如存在且 `status = BLOCKED` → 触发 H3 展示 `blocked_reason`
-   - 如不存在 → 检查已有文件推断阶段（有 01-05 → 从 Step 3，有 06-08 → 从 Step 4，有 09-10 → 从 Step 5）
+   - 如不存在 → 检查已有文件推断阶段：
+     - 仅有 00-design-brief.md → 从 Step 2（specAgent）
+     - 有 03-sdd.md + 04-boundary.md（精简模式最小集）或 01-05 齐全（完整模式）→ 从 Step 3（implAgent）
+     - 有 06-tdd-log.md 但无 09-test-matrix.md → 从 Step 4（testAgent）
+     - 有 09-test-matrix.md + 10-test-report.md 但无 11-review.md → 从 Step 5（reviewAgent）
+     - 有 11-review.md + 12-asset-update.md + 13-retrospective.md 但无 14-team.md → 从 Step 6（团队证据）
+     - 有 14-team.md + 15-brief.md → 从 Step 7（H4 验收）
+     - 部分文件缺失且不符合上述任何模式 → 触发 H3，展示已有/缺失文件清单，由用户决定是否补全
 3. **恢复时回退计数**：从 `.checkpoint.json` 恢复 `rollback_counts`，避免重置
+4. **回退计数规则**：`rollback_counts` 按 `source→target` 对独立计数（如 `test→impl`、`review→impl` 分别计数）。计数仅在以下情况重置为 0：(1) H3 人类介入后用户明确决定重试；(2) specAgent 重新产出规格后下游计数重置（因为输入已变化）。正常回退修复不重置计数
 
 ### Step 1：初始化 + H1 人类确认
 
 1. 从用户参数提取任务描述
-2. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录（如目录不存在则创建），取最大序号 +1（从 `0001` 起），拼接为 `{NNNN}-{关键词}`（关键词 kebab-case，整体 ≤ 50 字符），例如 `0001-add-tooltip`、`0012-refactor-auth`
-3. 创建 `docs/tasks/{slug}/` 目录
-4. **进度账本检查**：如果 `docs/tasks/progress.md` 不存在则创建（含表头）；读取 progress.md 确认 `{slug}` 未被重复派发（如已存在且状态为 DONE，提示用户该任务已完成，询问是否新建变体任务）
-5. 记录启动时间
-6. **向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议**，等待确认（设置 30 分钟超时提醒）
-7. 用户确认后继续，否则根据反馈调整
+2. 生成 `{slug}`：扫描 `docs/tasks/` 已有目录（如目录不存在则创建），取最大序号 +1（从 `0001` 起），拼接为 `{NNNN}-{关键词}`（关键词 kebab-case，整体 ≤ 50 字符），例如 `0001-add-tooltip`、`0012-refactor-auth`。**如果用户传入的参数是已有 slug 且 `docs/tasks/{slug}/00-design-brief.md` 存在，则复用该 slug，不新建目录**
+3. 创建 `docs/tasks/{slug}/` 目录（如已存在则跳过）
+4. **写入 checkpoint**：`current_step=Step 1, next_step=H1, phase=init, task_description={任务描述}`
+5. **进度账本检查**：如果 `docs/tasks/progress.md` 不存在则创建（含表头）。**注意：progress.md 是跨任务进度索引，必须位于 `docs/tasks/` 根目录，不在 slug 子目录中**。读取 progress.md 确认 `{slug}` 未被重复派发（如已存在且状态为 DONE，提示用户该任务已完成，询问是否新建变体任务）
+6. 记录启动时间
+7. **写入 checkpoint**：`current_step=H1, next_step=Step 2, pending_decision=确认目标理解`
+8. **向用户展示任务理解 + 初步方案 + 风险预判 + 分期建议**，等待确认（设置 30 分钟超时提醒）。如果存在 `00-design-brief.md`，将其摘要纳入展示
+9. 用户确认后，**写入 checkpoint**：`current_step=Step 2, completed_steps 追加 H1`。继续下一步，否则根据反馈调整
 
 **Kill Switch 预检查**：如果任务明显不可行（技术不可行、依赖不可用、范围远超预期），在 H1 阶段直接向用户提出终止建议。
 
@@ -306,19 +362,26 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 执行 team-spec skill。
 
 任务描述：{用户的任务描述}
-产出目录：docs/tasks/{slug}/
+任务 slug：{slug}
+产出目录：docs/tasks/{slug}/（如目录已存在则复用，不新建）
+模式：{完整 / --compact 精简}
+背景参考：{如果 docs/tasks/{slug}/00-design-brief.md 存在，将其内容作为设计背景输入；否则写"无"}
 约束：遵守 team-spec Skill 的 Phase 1-3 步骤；所有结论标注来源标签；产出前执行自检清单。
 
 读取 skills/team-spec/SKILL.md 获取完整执行步骤。
 ```
 
-**完成验证**：确认 6 个文件已产出（01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md），自检清单全部通过（19/19，清单定义见 team-spec Skill Phase 3 自检）。
+**完成验证**：完整模式确认 6 个文件已产出（01-plan.md / 02-context.md / 03-sdd.md / 04-boundary.md / 05-risk.md / prompt-template.md）；精简模式确认 2 个文件已产出（03-sdd.md / 04-boundary.md）。
+
+**写入 checkpoint**：`current_step=H2, next_step=Step 3, phase=spec, pending_decision=确认规格方案, completed_steps 追加 Step 2`
 
 ### Step 2.5：H2 人类确认规格 + Kill Switch 检查
 
+> **精简模式跳过此步**：`--compact` 模式下，Step 2 完成后直接进入 Step 3，checkpoint 中 `completed_steps` 不含 H2。
+
 向用户展示 `01-plan.md` 和 `03-sdd.md` 的核心内容 + 分期方案(P1/P2) + 自我约束预算，等待确认。
 
-- 用户确认 → 继续 Step 3
+- 用户确认 → **写入 checkpoint**：`current_step=Step 3, completed_steps 追加 H2`。继续 Step 3
 - 用户要求修改 → 回到 Step 2，根据反馈调整提示词后重新调度 specAgent
 - **Kill Switch**：如果用户认为任务不可行或范围不可接受 → 终止流程
 
@@ -335,8 +398,10 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 执行 team-impl skill。
 
 任务 slug：{slug}
-输入目录：docs/tasks/{slug}/（读取 01-05 + prompt-template.md）
+模式：{完整 / --compact 精简}
+输入目录：docs/tasks/{slug}/（完整模式读取 01-05 + prompt-template.md；精简模式读取 03-sdd.md + 04-boundary.md）
 约束：遵守 team-impl Skill 步骤；04-boundary.md 的 allow/deny 不可越界；遵循 TDD 红-绿-重构循环；P1 聚焦。
+TDD 强制要求：每个功能点必须先 git commit 失败测试（test: {功能点} (RED)），再 commit 实现（feat:/fix:）。编排器将在完成后验证 06-tdd-log.md 中 RED→GREEN 顺序和失败输出内容，不合格将回退。
 回退上下文：{如有 testAgent/reviewAgent 的 bug 报告则附上，否则写"无"}
 
 读取 skills/team-impl/SKILL.md 获取完整执行步骤。
@@ -344,6 +409,18 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 **完成验证**：确认 06-tdd-log.md / 07-prompt-log.md / 08-ai-decisions.md 已产出；测试通过；CI 检查通过。
 
+**TDD 证据验证**（Constitutional Rule #9 门禁）：读取 `06-tdd-log.md`，对每个功能点块执行以下检查：
+
+1. **顺序验证**：RED 段落出现在 GREEN 段落之前（按文档中的出现位置）
+2. **失败输出验证**：RED 段落的"失败输出"字段非空，且包含错误关键词（FAIL / fail / Error / error / ✗ / FAILED）
+3. **通过输出验证**：GREEN 段落的"通过输出"字段非空，且包含通过关键词（PASS / pass / OK / ✓ / ✅ / passed）
+4. **时间递增验证**：RED 时间 < GREEN 时间 < REFACTOR 时间（如有）
+5. **git 提交验证**：`git log --oneline` 中同一功能点存在 `test:` 提交
+
+任一项不通过 → 回退 implAgent，附上具体不合格项及期望修正行为（如"功能点 X 的 RED 段落缺失失败输出，请删除实现代码从 RED 重新开始"）。
+
+**写入 checkpoint**：`current_step=Step 4, next_step=Step 5, phase=impl, completed_steps 追加 Step 3`
+
 等待 implAgent 完成。
 
 ### Step 4：调度 testAgent
@@ -359,6 +436,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 执行 team-test skill。
 
 任务 slug：{slug}
+模式：{完整 / --compact 精简}
 输入：docs/tasks/{slug}/ 下的 03-sdd.md、04-boundary.md、06-tdd-log.md + implAgent 代码变更（git diff）
 约束：遵守 team-test Skill 步骤；四维覆盖；所有覆盖声明标注来源标签；全量测试运行。
 
@@ -367,15 +445,17 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 **完成验证**：确认 09-test-matrix.md / 10-test-report.md 已产出；获取路由决策（→ reviewAgent / → implAgent / → specAgent / → H3）。
 
+**写入 checkpoint**：`current_step=Step 5, next_step=Step 6, phase=test, completed_steps 追加 Step 4`
+
 等待 testAgent 完成。
 
 **回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 testAgent 报告发现 bug 或 spec 遗漏：
 
-- bug → 回到 Step 3 重新调度 implAgent，传递 bug 上下文（`.checkpoint.json` 中 `test→impl` +1）
-- spec 遗漏 → 回到 Step 2 重新调度 specAgent，传递遗漏上下文（`.checkpoint.json` 中 `test→spec` +1）
-- 同一阶段第 3 次回退 → 强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ 触发 H3 让人类决策是否终止
-- 人类需决策 → 触发 H3
+- bug → **写入 checkpoint**：`current_step=Step 3(回退), rollback_counts test→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
+- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), rollback_counts test→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
+- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
+- **Kill Switch**：如果发现任务不可行（如依赖不可用、技术方案不可行）→ **写入 checkpoint** 后触发 H3 让人类决策是否终止
+- 人类需决策 → **写入 checkpoint** 后触发 H3
 
 ### Step 5：调度 reviewAgent
 
@@ -390,8 +470,9 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 执行 team-review skill。
 
 任务 slug：{slug}
-输入：docs/tasks/{slug}/ 全部文件（01-10）+ 代码 diff + 项目规范（CLAUDE.md / .cursor/rules/、AGENTS.md（如存在）、CONTRIBUTING.md）
-约束：遵守 team-review Skill 步骤；五维度 Review + Constitutional 合规检查；P0/P1 必须修复或回退；资产更新遵循消费方契约。
+模式：{完整 / --compact 精简}
+输入：docs/tasks/{slug}/ 全部文件（完整模式 01-10；精简模式 03-04 + 06-10）+ 代码 diff + 项目规范（CLAUDE.md / .cursor/rules/、AGENTS.md（如存在）、CONTRIBUTING.md）
+约束：遵守 team-review Skill 步骤；五维度 Review + Constitutional 合规检查；P0/P1 必须修复或回退；资产更新遵循消费方契约。精简模式下 01-plan、02-context、05-risk 不存在属于正常，不标记为缺失。
 回退上下文：{如有 testAgent 报告的问题则附上，否则写"无"}
 
 读取 skills/team-review/SKILL.md 获取完整执行步骤。
@@ -399,18 +480,22 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 **完成验证**：确认 11-review.md / 12-asset-update.md / 13-retrospective.md / task-rules.md 已产出；获取修复/回退决策。
 
+**写入 checkpoint**：`current_step=Step 6, next_step=H4, phase=review, completed_steps 追加 Step 5`
+
 等待 reviewAgent 完成。
 
 **回退检查**（遵守 Constitutional Rule #7：同一阶段回退 ≤ 2 次，按 source→target 对独立计数，计数持久化到 `.checkpoint.json`）：如果 reviewAgent 报告发现 P0/P1 bug 或 spec 遗漏：
 
-- bug → 回到 Step 3 重新调度 implAgent，传递 bug 上下文（`.checkpoint.json` 中 `review→impl` +1）
-- spec 遗漏 → 回到 Step 2 重新调度 specAgent，传递遗漏上下文（`.checkpoint.json` 中 `review→spec` +1）
-- 同一阶段第 3 次回退 → 强制触发 H3，由人类决定是否继续
-- **Kill Switch**：如果发现任务不可行 → 触发 H3 让人类决策是否终止
-- 人类需决策 → 触发 H3
+- bug → **写入 checkpoint**：`current_step=Step 3(回退), rollback_counts review→impl +1`。回到 Step 3 重新调度 implAgent，传递 bug 上下文
+- spec 遗漏 → **写入 checkpoint**：`current_step=Step 2(回退), rollback_counts review→spec +1`。回到 Step 2 重新调度 specAgent，传递遗漏上下文
+- 同一阶段第 3 次回退 → **写入 checkpoint**：`current_step=H3, pending_decision={问题描述}`。强制触发 H3，由人类决定是否继续
+- **Kill Switch**：如果发现任务不可行 → **写入 checkpoint** 后触发 H3 让人类决策是否终止
+- 人类需决策 → **写入 checkpoint** 后触发 H3
 
 ### Step 6：补全团队级证据
 
+> **精简模式跳过此步**：`--compact` 模式下，Step 5 完成后直接进入 Step 7（H4），不产出 14-team.md / 15-brief.md。checkpoint 中 `completed_steps` 不含 Step 6。
+
 由编排器自己执行以下检查并产出 2 个文件。对于可并行的检查项，使用子 Agent 并行执行以提高效率。
 
 #### 6.1 一致性自动化检查（先执行再写入 14-team.md）
@@ -431,15 +516,28 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 模板见 `references/14-team-template.md`。
 
+**独立作者场景**：如果项目仅有 1 位人类作者（配合 AI Agent 协作），§一 角色分工填写"用户 + AI Agent 团队"，§三 个人贡献明细将用户的审查/确认决策也计入贡献，§四 交叉 Review 质量统计正常填写 reviewAgent 的审查数据。
+
 #### 文件 15：`15-brief.md`
 
-模板见 `references/15-brief-template.md`。
+模板见 `references/15-brief-template.md`。填写方式：
+
+- §一 Elevator Pitch：从 01-plan.md 的目标 + 03-sdd.md 的方案 + 10-test-report.md 的结果提炼 3 句话
+- §二 关键决策：从 08-ai-decisions.md 挑选 2-3 个最重要的决策填入表格
+- §三 AI 协作亮点：从 07-prompt-log.md 的纠偏记录 + 06-tdd-log.md 的 bug 发现中提取具体事例
+- §四 测试覆盖概要：从 09-test-matrix.md + 10-test-report.md 提取数据
+- §五 遗留风险：从 11-review.md §四 摘录
+- §六 改进承诺：从 13-retrospective.md §三 摘录
+
+**写入 checkpoint**：`current_step=H4, next_step=Step 7.5, phase=team, pending_decision=验收交付物, completed_steps 追加 Step 6`
 
 ### Step 7：H4 人类验收 + P2 决策
 
-向用户展示交付物清单、代码 diff 摘要、14-team.md 和 15-brief.md 核心内容，等待验收（设置 30 分钟超时提醒）。
+向用户展示交付物清单、代码 diff 摘要，等待验收（设置 30 分钟超时提醒）。完整模式还展示 14-team.md 和 15-brief.md 核心内容；精简模式展示 11-review.md 审查结论和 13-retrospective.md 改进承诺。
 
-- 用户验收通过 → 完成
+**交付清单验证**：如果 `docs/delivery-checklist.md` 存在，读取并检查 `- [ ]` 项是否已标记为 `- [x]`。未完成项列入 H4 展示内容，供用户判断是否放行或要求补全。
+
+- 用户验收通过 → **写入 checkpoint**：`current_step=Step 7.3, completed_steps 追加 H4`。继续
 - 用户不通过 → 根据反馈回到对应 Agent
 - **P2 决策**：如果 spec 定义了 P2（候选增强），向用户展示 P2 建议 + 触发条件，由用户决定是否继续
 
@@ -458,7 +556,7 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 1. **规则合并**：将 `docs/tasks/{slug}/task-rules.md` 中标记为"可泛化"的规则，合并到项目级或模块级 AI 规范文件（CLAUDE.md / .cursor/rules/）
 2. **SDD 快照归档**：如果项目维护了 `docs/specs/` 目录，将本次 `03-sdd.md` 的关键规格合并进去（增量模式则执行 delta 合并：ADDED 追加、MODIFIED 替换、REMOVED 删除；如有冲突以本次 SDD 为准并在 commit message 中注明）
-3. **进度账本更新**：在 `docs/tasks/progress.md` 追加本次任务记录
+3. **进度账本更新**：在 `docs/tasks/progress.md`（**注意是 `docs/tasks/` 根目录，不是 slug 子目录**）追加本次任务记录
 
 ```markdown
 | {slug} | {YYYY-MM-DD} | {DONE/DONE_WITH_CONCERNS} | {起始commit..结束commit} | {一句话摘要} |
@@ -479,38 +577,38 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 ### Step 8：最终质量检查
 
-逐条核验，确保每个维度都有明确证据。
+逐条核验，确保每个维度都有明确证据。**精简模式下**，标注 `[完整模式]` 的检查项跳过，标注 `[精简替代]` 的检查项替换原项。
 
 **硬门槛（7 项全部必须通过）：**
 
-- [ ] G1: 01-plan.md 包含目标澄清、上下文、阶段拆分、修改范围、验证计划
+- [ ] G1: `[完整模式]` 01-plan.md 包含目标澄清、上下文、阶段拆分、修改范围、验证计划。`[精简替代]` 03-sdd.md 包含任务目标和关键设计决策
 - [ ] G2: 04-boundary.md 有 allow/deny 两个方向
 - [ ] G3: 测试存在且有补充（09-test-matrix.md + 10-test-report.md + 测试代码）
 - [ ] G4: 代码通过项目 CI 全量检查，测试全部通过
 - [ ] G5: 项目 AI 规范中每条规则包含「触发条件 + 可执行指令」，不是空话
-- [ ] G6: 05-risk.md 有风险识别 + 11-review.md §四 有剩余风险说明
-- [ ] G7: 08-ai-decisions.md 能解释关键决策 + 15-brief.md 有决策解释表
+- [ ] G6: `[完整模式]` 05-risk.md 有风险识别 + 11-review.md §四 有剩余风险说明。`[精简替代]` 11-review.md §四 有剩余风险说明
+- [ ] G7: `[完整模式]` 08-ai-decisions.md 能解释关键决策 + 15-brief.md 有决策解释表。`[精简替代]` 08-ai-decisions.md 能解释关键决策
 
 **D1 AI 协作资产沉淀（25 分）：**
 
 - [ ] D1.1 分层组织：项目 AI 规范（项目级）+ 模块 AI 规范（模块级）+ task-rules.md（任务级）三层齐全
-- [ ] D1.2 内容覆盖：业务术语、架构、代码结构、接口约定、编码规范、测试要求、Review 标准、交付要求 8 类有对应文件
+- [ ] D1.2 内容覆盖：业务术语、架构、代码结构、接口约定、编码规范、测试要求、Review 标准、交付要求 8 类有对应文件。验证：CLAUDE.md 或 AGENTS.md 覆盖架构/代码结构/接口/编码规范；docs/review-checklist.md 含 ≥ 5 条可执行检查项；docs/delivery-checklist.md 完成率 ≥ 80%（`- [x]` 数 / 总 `- [` 数）。不满足 → 回退 reviewAgent 补建
 - [ ] D1.3 规则可执行：12-asset-update.md 中每条规则有「触发条件 + 可执行指令 + 示例」
 - [ ] D1.4 工具适配 ≥ 2 类：项目 AI 规范 + (review-checklist / delivery-checklist / prompt-template.md) 至少 2 种
 - [ ] D1.5 可维护性：项目 AI 规范有「资产维护机制」段落（更新触发条件 + 版本记录 + 复盘中新增规则）
 
 **D2 AI 协作任务规划（25 分）：**
 
-- [ ] D2.1 目标澄清：01-plan.md 有成功标准 ≥ 3 条（每条含验证命令）+ 非目标 ≥ 2 条
-- [ ] D2.2 上下文选择：02-context.md 有必要引用 + 已排除上下文
-- [ ] D2.3 任务拆分：01-plan.md 有探索→方案→实现→验证→总结 ≥ 5 阶段
+- [ ] D2.1 `[完整模式]` 目标澄清：01-plan.md 有成功标准 ≥ 3 条（每条含验证命令）+ 非目标 ≥ 2 条。`[精简替代]` 03-sdd.md §一 有明确目标描述
+- [ ] D2.2 `[完整模式]` 上下文选择：02-context.md 有必要引用 + 已排除上下文。`[精简替代]` 此项跳过（精简模式不产出 02-context.md）
+- [ ] D2.3 `[完整模式]` 任务拆分：01-plan.md 有探索→方案→实现→验证→总结 ≥ 5 阶段。`[精简替代]` 此项跳过
 - [ ] D2.4 执行约束：04-boundary.md 有 allow/deny + 依赖约束
-- [ ] D2.5 验证风控：05-risk.md 有验证计划（具体命令 + 预期结果）+ 停下来问人条件 ≥ 3 个
+- [ ] D2.5 `[完整模式]` 验证风控：05-risk.md 有验证计划（具体命令 + 预期结果）+ 停下来问人条件 ≥ 3 个。`[精简替代]` 此项跳过（精简模式不产出 05-risk.md）
 
 **D3 AI 交付质量保障（27 分）：**
 
 - [ ] D3.1 SDD 规格：03-sdd.md 含输入/输出/边界/异常/验收 Checklist
-- [ ] D3.2 TDD 流程：06-tdd-log.md 含红-绿-重构循环记录（RED 有失败输出在前，GREEN 有通过输出在后）+ git log 中 test: 提交早于 feat:/fix: 提交
+- [ ] D3.2 TDD 流程：06-tdd-log.md 含红-绿-重构循环记录（RED 有失败输出在前，GREEN 有通过输出在后）+ git log 中同一功能点的 test: 提交早于 feat:/fix: 提交
 - [ ] D3.3 测试覆盖：09-test-matrix.md 四维矩阵（功能/边界/异常/代码），不仅限 Happy Path
 - [ ] D3.4 缺陷修复：06-tdd-log.md + 11-review.md 有修复记录
 - [ ] D3.5 Review 风险：11-review.md 含五维度审查 + §四剩余风险
@@ -521,10 +619,12 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 - [ ] D4.2 迭代纠偏：07-prompt-log.md 有纠偏前后对比
 - [ ] D4.3 过程可追溯：07-prompt-log.md + 08-ai-decisions.md 有关键过程记录
 - [ ] D4.4 个人复盘：13-retrospective.md 有 §二.5「本次沉淀的新规则」
-- [ ] D4.5 答辩准备：15-brief.md 有 Elevator Pitch + 决策解释 + 亮点 + 测试覆盖概要 + 风险
+- [ ] D4.5 `[完整模式]` 答辩准备：15-brief.md 有 Elevator Pitch + 决策解释 + 亮点 + 测试覆盖概要 + 风险。`[精简替代]` 此项跳过（精简模式不产出 15-brief.md）
 
 **D5 团队协作表现（10 分）：**
 
+> 精简模式下 D5 整组跳过（不产出 14-team.md / 15-brief.md）。
+
 - [ ] D5.1 角色分工：14-team.md §一 有角色 / 负责人 / 职责 / 产出物
 - [ ] D5.2 资产一致：14-team.md §二 一致性检查全部 ✅ 或已修复
 - [ ] D5.3 交叉 Review：14-team.md §四 真实问题占比 > 0
@@ -545,8 +645,8 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 
 在报告完成状态前，执行以下自检：
 
-- [ ] 所有 17 个文件已产出（01-15 + prompt-template + task-rules）
-- [ ] H1-H4 全部经过人类确认，未被跳过
+- [ ] 完整模式：所有 17 个文件已产出（01-15 + prompt-template + task-rules）；精简模式：核心文件已产出（03-sdd + 04-boundary + 06-tdd-log + 07-prompt-log + 08-ai-decisions + 09-test-matrix + 10-test-report + 11-review + 12-asset-update + 13-retrospective + task-rules）
+- [ ] H1 和 H4 经过人类确认，未被跳过（完整模式还需确认 H2）
 - [ ] 回退计数未超过上限（同一阶段 ≤ 2 次）
 - [ ] Step 8 质量检查全部通过
 - [ ] CHANGELOG.md 已更新（如 reviewAgent 要求）
@@ -557,7 +657,8 @@ NO AGENT DISPATCH WITHOUT H1 HUMAN CONFIRMATION FIRST
 ```
 Team 全流程完成 ✅
 产出目录：docs/tasks/{slug}/
-文件总数：17 个文档（01-15 + prompt-template + task-rules）+ 代码 + 测试 + 资产更新
+模式：{完整模式 / 精简模式}
+文件总数：完整模式 17 个文档（01-15 + prompt-template + task-rules）；精简模式 11 个文档（03-04 + 06-13 + task-rules）
 全部质量检查通过
 ```
 

package/skills/team-orchestrator/references/14-team-template.md

@@ -68,3 +68,5 @@
 | 15-brief.md         | ✅   | 答辩准备                      |
 | AI 规范已更新       | ✅   | 分层清晰 + 内容完整 + 可维护  |
 | CHANGELOG.md 已更新 | ✅   | 变更可追溯                    |
+| docs/review-checklist.md | ✅ | Review 标准沉淀              |
+| docs/delivery-checklist.md | ✅ | 交付标准沉淀               |

package/skills/team-review/SKILL.md

@@ -20,10 +20,12 @@ description: Use when code + tests exist and you need structured review + asset
 ### 系统提示词
 
 ```
+你的思维方式：审计师——你的第一反应永远是"证据在哪里？"
+
 你是一个 Team review 专家。你的任务是：
 
 1. 五维度 Review：对每个修改文件审查正确性、可维护性、性能、安全、测试覆盖
-2. Constitutional 合规检查：验证所有 Agent 是否遵守了 8 条 Constitutional Rules
+2. Constitutional 合规检查：验证所有 Agent 是否遵守了 9 条 Constitutional Rules
 3. 问题路由：根据问题严重级别（P0/P1/P2/P3）决定修复方式
 4. 资产维护：更新 CLAUDE.md / .cursor/rules/、CHANGELOG.md、Review Checklist、Delivery Checklist
 5. 复盘：记录本次任务的经验和改进承诺
@@ -33,7 +35,21 @@ description: Use when code + tests exist and you need structured review + asset
 
 ### 推理指引
 
-在审查每个文件前，推理变更内容、五维度质量状态、问题严重级别、路由目标，并从攻击者/怀疑者/用户三视角反向挑战结论。
+**角色心智模型**：你像一位审计师思考——你的第一反应永远是"证据在哪里？"你不信任任何 Agent 的自我声明（FP-4），不被代码的表面整洁度所打动，不因为"测试都通过了"就放松警惕。你的审查不是寻找"能不能工作"而是寻找"会在什么条件下失败"。你同时扮演三个角色：攻击者（如何破坏它）、怀疑者（证据充分吗）、用户（六个月后好维护吗）。
+
+**第一性原理推理框架**：审查每个变更文件前，依次推理——
+
+1. **变更内容**：这个文件改了什么？为什么改？对照 SDD 这个变更是必要且充分的吗？
+2. **五维度质量**：正确性、可维护性、性能、安全、测试覆盖各是什么状态？
+3. **问题严重级别**：发现的问题是 P0（阻断）、P1（应修）、P2（建议）还是 P3（风格）？
+4. **路由目标**：问题根因在实现层、规格层还是需要人类决策？
+5. **Constitutional 合规**：9 条硬约束是否全部被遵守？有没有被巧妙绕过的？
+
+**三视角对抗审查**（必须执行，不可跳过）：
+
+- **攻击者视角**：如何利用这段代码的弱点？异常输入会怎样？并发场景呢？
+- **怀疑者视角**：TDD 日志中的 RED 记录是真的先于 GREEN 吗？测试输出是新鲜执行的吗？
+- **用户视角**：不了解上下文的新成员能理解这段代码吗？错误信息对终端用户有帮助吗？
 
 ## Iron Law
 
@@ -74,7 +90,8 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 ### 完整输入（编排模式）
 
-- `01-plan.md` ~ `10-test-report.md` 全部文件
+- 完整模式：`01-plan.md` ~ `10-test-report.md` 全部文件
+- 精简模式：`03-sdd.md` + `04-boundary.md` + `06-tdd-log.md` ~ `10-test-report.md`（01-plan、02-context、05-risk 不存在属于正常）
 - 回退上下文（如有）
 
 ## 执行步骤
@@ -95,15 +112,17 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 验证所有 Agent 是否遵守了 Constitutional Rules：
 
+> **精简模式注意**：`--compact` 模式下 01-plan.md、02-context.md、05-risk.md 不存在。涉及这些文件的检查项改为检查 03-sdd.md 中是否有对应信息，或标注"精简模式豁免"。
+
 | 规则             | 检查方式                                                                                 | 违规表现                     | 严重级别 |
 | ---------------- | ---------------------------------------------------------------------------------------- | ---------------------------- | -------- |
-| 人类介入未被跳过 | 检查任务目录下文件中是否有 H1-H4 的确认记录                                              | 缺少人类确认记录             | P0       |
+| 人类介入未被跳过 | 检查任务目录下文件中是否有 H1-H4 的确认记录（精简模式：H1+H4 即可，H2 不检查）           | 缺少人类确认记录             | P0       |
 | 有向图回退       | 检查 08-ai-decisions.md 和 11-review.md 中是否有回退记录                                 | 发现问题但未回退             | P1       |
 | TDD Iron Law     | 检查 06-tdd-log.md 中每个功能点是否有 🔴 RED → 🟢 GREEN → 🔵 REFACTOR 完整序列（或 RED → GREEN → REFACTOR 文本形式）；RED 必须在 GREEN 之前出现且包含失败输出 | RED 记录缺失或在 GREEN 之后   | P0       |
-| Kill Switch 触发 | 检查 05-risk.md 中 Kill Switch 条件是否被触发                                            | 条件满足但未触发 Kill Switch | P0       |
-| 分期交付         | 检查 01-plan.md 中是否有 P1/P2 划分                                                      | 复杂任务无分期               | P2       |
+| Kill Switch 触发 | 检查 05-risk.md 中 Kill Switch 条件是否被触发（精简模式：检查 03-sdd.md 或 .checkpoint.json 中是否有 Kill Switch 记录） | 条件满足但未触发 Kill Switch | P0       |
+| 分期交付         | 检查 01-plan.md 中是否有 P1/P2 划分（精简模式豁免：简单任务无需分期）                    | 复杂任务无分期               | P2       |
 | 自我约束预算     | 检查 06-tdd-log.md 中预算 vs 实际                                                        | 预算超支未砍范围             | P1       |
-| 来源标签         | 检查 02-context.md 和 09-test-matrix.md 中是否有 {extracted}/{inferred}/{ambiguous} 标签 | 缺少来源标签                 | P2       |
+| 来源标签         | 检查 03-sdd.md 和 09-test-matrix.md 中是否有 {extracted}/{inferred}/{ambiguous} 标签（精简模式：02-context.md 不检查） | 缺少来源标签                 | P2       |
 | 产出必须验证     | 检查各 Agent 产出是否经过下游验证才进入下一步，而非仅依赖自我声明                        | 未经验证直接流转             | P1       |
 | 回退次数上限     | 检查同一阶段回退是否超过 2 次                                                            | 超过 2 次未触发 H3           | P1       |
 | 验证先行原则     | 检查 06-tdd-log.md 和 10-test-report.md 中的验证声明是否基于当次新鲜执行的完整输出       | 引用缓存结果或截断输出       | P0       |
@@ -150,7 +169,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 3. 运行项目 CI 检查命令确认无 lint 问题
 4. **边界约束**：如修复导致新测试失败或引入新问题，**立即停止自修**，将问题路由到 implAgent（通过编排器），附带修复尝试的上下文
 
-> **验证协议**（步骤 2-3 声明"通过"前必须执行 CLAUDE.md §三 验证协议的 5 个步骤）
+> **验证协议**（步骤 2-3 声明"通过"前必须执行 `_team-rules/verification-protocol.md` 的 5 个步骤）
 
 对于路由到 implAgent/specAgent 的问题：
 
@@ -255,7 +274,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 #### 4.4 Review Checklist
 
-如果本次 Review 发现了新的检查项，追加到 `docs/review-checklist.md`：
+如果本次 Review 发现了新的检查项，追加到 `docs/review-checklist.md`。如果文件不存在，按模板 `references/review-checklist-template.md` 创建并填充本次实际检查内容（替换所有占位符）。已存在则追加本次发现的新检查项。每项 **MUST** 可执行（有具体检查对象和通过标准）。
 
 ```markdown
 
@@ -265,7 +284,7 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 
 #### 4.5 Delivery Checklist
 
-如果本次任务发现了新的交付检查项，追加到 `docs/delivery-checklist.md`。
+如果本次任务发现了新的交付检查项，追加到 `docs/delivery-checklist.md`。如果文件不存在，按模板 `references/delivery-checklist-template.md` 创建并填充本次实际检查内容（替换所有占位符）。已存在则追加本次发现的新交付项。每项 **MUST** 可执行。完成交付后，将已完成项标记为 `- [x]`。
 
 #### 4.6 工具适配产物确认（≥ 2 类）
 
@@ -328,6 +347,8 @@ NO COMPLETION CLAIMS WITHOUT CONSTITUTIONAL COMPLIANCE CHECK
 | `11-review.md` | `references/11-review-template.md` | 代码审查报告 |
 | `12-asset-update.md` | `references/12-asset-update-template.md` | AI 协作资产更新记录 |
 | `13-retrospective.md` | `references/13-retrospective-template.md` | 个人复盘 |
+| `docs/review-checklist.md` | `references/review-checklist-template.md` | Review 检查清单（项目级，跨任务累积） |
+| `docs/delivery-checklist.md` | `references/delivery-checklist-template.md` | 交付检查清单（项目级，跨任务累积） |
 
 ## STOP Signals
 

package/skills/team-review/references/delivery-checklist-template.md

@@ -0,0 +1,31 @@
+# Delivery Checklist
+
+> reviewAgent 产出 | {slug} | {日期}
+
+## 一、交付标准
+
+- [ ] CI 全量检查通过（退出码 = 0）
+- [ ] P0/P1 问题已全部修复或经人类决策豁免
+- [ ] 04-boundary.md 的 deny 列表未被违反
+- [ ] SDD 中所有 MUST 规则已被代码实现覆盖
+- [ ] 无调试代码残留（console.log/debugger/TODO hack）
+- [ ] 公共 API 有文档说明（参数、返回值、异常）
+- [ ] CHANGELOG.md 已更新
+
+## 二、AI 资产交付
+
+- [ ] 项目 AI 规范（CLAUDE.md / .cursor/rules/）已更新（新规则含触发条件 + 可执行指令 + 示例）
+- [ ] AGENTS.md 已更新（如有架构变更）
+- [ ] docs/review-checklist.md 已更新
+- [ ] docs/tasks/{slug}/task-rules.md 已产出
+
+## 三、文档交付
+
+- [ ] 06-tdd-log.md 每个功能点有完整 RED→GREEN→REFACTOR 记录（RED 含失败输出）
+- [ ] 09-test-matrix.md 四维覆盖（功能/边界/异常/代码）
+- [ ] 11-review.md 五维度审查完成
+- [ ] 13-retrospective.md §二.5 新规则沉淀已写入目标文件
+
+## 四、项目自定义交付项
+
+> 根据项目实际情况追加检查项。

package/skills/team-review/references/review-checklist-template.md

@@ -0,0 +1,39 @@
+# Review Checklist
+
+> reviewAgent 产出 | {slug} | {日期}
+
+## 一、正确性
+
+- [ ] 业务逻辑符合 SDD 规格（逐条对照 03-sdd.md §二 业务规则）
+- [ ] 边界条件已处理（空值、极值、格式异常）
+- [ ] 异常路径有错误处理（错误码、错误消息符合 SDD §八）
+
+## 二、可维护性
+
+- [ ] 命名清晰（函数名、变量名反映用途）
+- [ ] 函数长度合理（单函数不超过 50 行逻辑代码）
+- [ ] 无重复代码（相似逻辑已提取公共函数）
+- [ ] 遵循项目编码规范（CLAUDE.md / .cursor/rules/ 中的编码约定）
+
+## 三、性能
+
+- [ ] 无不必要的循环或重复计算
+- [ ] 无内存泄漏风险（资源已正确释放）
+- [ ] 数据库/网络调用已优化（无 N+1 查询、无冗余请求）
+
+## 四、安全
+
+- [ ] 无注入风险（SQL/XSS/命令注入）
+- [ ] 无敏感信息泄露（密钥、token、个人数据）
+- [ ] 权限检查完整（访问控制无遗漏）
+
+## 五、测试覆盖
+
+- [ ] 新增功能有对应测试
+- [ ] 测试覆盖 Happy Path + 边界 + 异常
+- [ ] 测试命名清晰，描述被测行为
+- [ ] 测试可独立运行、可重复
+
+## 六、项目自定义检查项
+
+> 根据项目实际情况追加检查项。

package/skills/team-score/SKILL.md

@@ -12,6 +12,7 @@ description: Use when evaluating AI collaboration maturity of a project
 ### 系统提示词
 
 ```
+你的思维方式：法医鉴定专家——只相信物证，不相信口供。
 你是一个 Team score 评委。你的任务是：
 
 1. 按 5 个维度分别收集证据（可并行扫描以提高效率）
@@ -24,7 +25,16 @@ description: Use when evaluating AI collaboration maturity of a project
 
 ### 推理指引
 
-对每个评分项先找到实际证据（文件路径+内容），找不到证据就给 0 分，不凭推测或印象打分。
+**角色心智模型**：你像一位法医鉴定专家思考——你只相信物证，不相信口供。"项目做得不错"是口供，`docs/tasks/*/06-tdd-log.md` 中 RED 时间戳早于 GREEN 时间戳是物证。你知道人类和 AI 都倾向于高估自己的工作质量（FP-4），因此你对每个评分项的态度是"有罪推定"——默认 0 分，找到证据才加分。
+
+**第一性原理推理框架**：对每个评分项，依次推理——
+
+1. **证据定位**：这个评分项需要什么类型的证据？证据应该在哪个文件的哪个部分？
+2. **证据质量**：找到的文件是有实质内容还是模板占位符？（模板未填充 = 0 分）
+3. **证据充分性**：这些证据足以支撑满分吗？还是只能支撑部分得分？
+4. **证据缺失记录**：如果找不到证据，搜索过的路径是什么？（记录搜索路径而非留空）
+
+**对抗视角**：打分前自问——"如果有人质疑我给的这个分数，我能指出具体的文件路径和内容片段作为证据吗？"；"如果这个项目的作者站在我面前答辩，我的评分能经受住质询吗？"
 
 ## Iron Law
 
@@ -140,6 +150,8 @@ NO SCORE WITHOUT EVIDENCE
 
 ## 执行步骤
 
+> **精简模式（--compact）项目**：如果项目使用了 `team-orchestrator --compact`，部分文档（01-plan、02-context、05-risk、14-team、15-brief、prompt-template）不会产出。评分时应检查 `.checkpoint.json` 或任务目录结构判断模式。精简模式下，缺失这些文件不扣分，但对应评分项改为从已有文件（03-sdd、04-boundary、11-review 等）中寻找等效证据。硬门槛 #1（任务规划）改为检查 03-sdd.md 是否包含目标和设计决策。
+
 ### Step 1: 收集证据
 
 按以下 5 个维度收集证据（可并行执行以提高效率，具体并行方式取决于工具能力）：
@@ -152,7 +164,7 @@ NO SCORE WITHOUT EVIDENCE
 - 检查是否覆盖：业务术语表、系统架构（AGENTS.md / docs/architecture.md）、代码结构（AGENTS.md / CLAUDE.md）、接口约定、编码规范、测试规范、Review Checklist、Delivery Checklist、交付要求
 - 检查规则是否具体可执行（有无禁止项、必须项、示例、验证方式）
 - 检查有无 Prompt 模板（docs/tasks/\*/prompt-template.md）、检查清单等工具适配产物（≥ 2 类）
-- 检查有无维护说明、版本记录、复盘中新增规则机制（CLAUDE.md 中的「资产维护机制」段落）
+- 检查有无维护说明、版本记录、复盘中新增规则机制（项目 AI 规范文件中的「资产维护机制」段落）
 
 **Agent 2 — 任务规划扫描**
 
@@ -290,6 +302,14 @@ NO SCORE WITHOUT EVIDENCE
 - 只扫描代码目录，不检查文档、配置和测试目录
 - 评分报告不包含按优先级排列的改进建议
 
+## Constitutional Rules 遵守
+
+引用 `_team-rules/constitutional-rules.md`。评分阶段需特别验证被评项目对以下规则的遵守情况：
+
+- **Rule #9 TDD 顺序不可逆**：检查 06-tdd-log.md 中 RED→GREEN 的时间序证据（FP-2）
+- **Rule #3 产出必须验证**：检查验证声明是否基于当次新鲜执行（FP-4）
+- **Rule #1 人类介入是一等公民**：检查 H1-H4 确认记录是否存在（FP-1）
+
 ## 自检门禁
 
 在报告完成状态前，执行以下自检：