dev-playbooks-cn 2.5.3 → 2.6.0

package/skills/devbooks-convergence-audit/references//346/224/266/346/225/233/346/200/247/345/256/241/350/256/241/347/273/206/345/210/231.md

@@ -0,0 +1,384 @@
+# 收敛性审计细则
+
+## 核心原则：反迷惑设计
+
+> 黄金法则：证据 > 声明。永远不要相信文档中的任何断言，必须通过可验证的证据确认。
+
+### AI 容易被迷惑的场景（必须防范）
+
+| 迷惑场景 | AI 错误行为 | 正确行为 |
+|----------|-------------|----------|
+| 文档写 `Status: Done` | 相信已完成 | 验证：测试是否真的全绿？证据是否存在？ |
+| AC 矩阵全部 `[x]` | 相信全覆盖 | 验证：每个 AC 对应的测试文件是否存在且通过？ |
+| 文档写"测试通过" | 相信通过 | 验证：实际运行测试或检查 CI 日志时间戳 |
+| `evidence/` 目录存在 | 相信有证据 | 验证：目录非空？内容是否为有效测试日志？ |
+| tasks.md 全部 `[x]` | 相信已实现 | 验证：对应代码文件是否存在且有实质内容？ |
+| 提交信息说"修复了" | 相信已修复 | 验证：相关测试是否从红变绿？ |
+
+### 反迷惑三原则
+
+```
+1. 声明存疑（Distrust Declarations）
+   - 任何文档中的"完成/通过/覆盖"声明都是待验证的假设
+   - 默认立场：声明可能是错误的、过时的、或乐观的
+
+2. 证据优先（Evidence First）
+   - 代码/测试结果是唯一真理
+   - 日志时间戳必须晚于最后一次代码修改
+   - 空目录/空文件 = 无证据
+
+3. 交叉验证（Cross Validation）
+   - 声明 vs 证据：检查是否一致
+   - 代码 vs 测试：检查是否匹配
+   - 多个文档：检查是否矛盾
+```
+
+---
+
+## 验证检查清单（逐项执行）
+
+### 检查 1：Status 字段真实性验证
+
+文档声明：`verification.md` 中 `Status: Done` 或 `Status: Verified`
+
+验证步骤：
+```bash
+# 1. 检查 verification.md 是否存在
+[[ -f "verification.md" ]] || echo "❌ verification.md 不存在"
+
+# 2. 检查 evidence/green-final/ 是否有内容
+if [[ -z "$(ls -A evidence/green-final/ 2>/dev/null)" ]]; then
+  echo "❌ Status 声称完成，但 evidence/green-final/ 为空"
+fi
+
+# 3. 检查证据时间戳是否晚于代码最后修改
+code_mtime=$(stat -f %m src/ 2>/dev/null || stat -c %Y src/)
+evidence_mtime=$(stat -f %m evidence/green-final/* 2>/dev/null | sort -n | tail -1)
+if [[ $evidence_mtime -lt $code_mtime ]]; then
+  echo "❌ 证据时间早于代码修改，证据可能过时"
+fi
+```
+
+迷惑检测：
+- ⚠️ Status=Done 但 evidence/ 为空 → 假完成
+- ⚠️ Status=Done 但证据时间戳过旧 → 过时证据
+- ⚠️ Status=Done 但测试实际运行失败 → 虚假状态
+
+---
+
+### 检查 2：AC 覆盖矩阵真实性验证
+
+文档声明：AC 矩阵中 `[x]` 表示已覆盖
+
+验证步骤：
+```bash
+# 1. 提取所有声称已覆盖的 AC
+grep -E '^\| AC-[0-9]+.*\[x\]' verification.md | while read line; do
+  ac_id=$(echo "$line" | grep -oE 'AC-[0-9]+')
+  test_id=$(echo "$line" | grep -oE 'T-[0-9]+')
+
+  # 2. 验证对应测试是否存在
+  if ! grep -rq "$test_id\|$ac_id" tests/; then
+    echo "❌ $ac_id 声称已覆盖，但找不到对应测试"
+  fi
+done
+
+# 3. 实际运行测试验证（最可靠）
+npm test 2>&1 | tee /tmp/test-output.log
+if grep -q "FAIL\|Error\|failed" /tmp/test-output.log; then
+  echo "❌ AC 声称全覆盖，但测试实际有失败"
+fi
+```
+
+迷惑检测：
+- ⚠️ AC 打勾但对应测试文件不存在 → 虚假覆盖
+- ⚠️ AC 打勾但测试实际失败 → 假绿
+- ⚠️ AC 打勾但测试内容为空/占位符 → 占位符测试
+
+---
+
+### 检查 3：tasks.md 完成度真实性验证
+
+文档声明：tasks.md 中 `[x]` 表示已完成
+
+验证步骤：
+```bash
+# 1. 提取所有声称已完成的任务
+grep -E '^\- \[x\]' tasks.md | while read line; do
+  # 2. 提取任务描述中的关键词（函数名/文件名/功能）
+  keywords=$(echo "$line" | grep -oE '[A-Za-z]+[A-Za-z0-9]*' | head -5)
+
+  # 3. 验证代码中是否有对应实现
+  for kw in $keywords; do
+    if ! grep -rq "$kw" src/; then
+      echo "⚠️ 任务声称完成，但代码中找不到关键词: $kw"
+    fi
+  done
+done
+
+# 4. 检查是否有"骨架代码"（只有函数签名没有实现）
+grep -rE 'throw new Error\(.*not implemented|TODO|FIXME|pass$|\.\.\.}' src/ && \
+  echo "⚠️ 发现未实现的占位符代码"
+```
+
+迷惑检测：
+- ⚠️ 任务打勾但代码不存在 → 虚假完成
+- ⚠️ 任务打勾但代码是占位符 → 骨架代码
+- ⚠️ 任务打勾但功能不可调用 → 死代码
+
+---
+
+### 检查 4：证据有效性验证
+
+文档声明：`evidence/` 目录包含测试证据
+
+验证步骤：
+```bash
+# 1. 检查目录是否存在且非空
+if [[ ! -d "evidence" ]] || [[ -z "$(ls -A evidence/)" ]]; then
+  echo "❌ evidence/ 不存在或为空"
+  exit 1
+fi
+
+# 2. 检查证据文件是否有实质内容
+for f in evidence/**/*; do
+  if [[ -f "$f" ]]; then
+    lines=$(wc -l < "$f")
+    if [[ $lines -lt 5 ]]; then
+      echo "⚠️ 证据文件内容过少: $f ($lines 行)"
+    fi
+
+    # 3. 检查是否为有效测试日志（包含测试框架输出特征）
+    if ! grep -qE 'PASS|FAIL|✓|✗|passed|failed|test|spec' "$f"; then
+      echo "⚠️ 证据文件不像测试日志: $f"
+    fi
+  fi
+done
+
+# 4. 检查 red-baseline 证据是否真的是红色（有失败）
+if [[ -d "evidence/red-baseline" ]]; then
+  if ! grep -rqE 'FAIL|Error|✗|failed' evidence/red-baseline/; then
+    echo "❌ red-baseline 声称是红色，但没有失败记录"
+  fi
+fi
+
+# 5. 检查 green-final 证据是否真的是绿色（全通过）
+if [[ -d "evidence/green-final" ]]; then
+  if grep -rqE 'FAIL|Error|✗|failed' evidence/green-final/; then
+    echo "❌ green-final 声称是绿色，但包含失败记录"
+  fi
+fi
+```
+
+迷惑检测：
+- ⚠️ evidence/ 存在但内容为空 → 空证据
+- ⚠️ 证据文件太小（< 5 行）→ 占位符证据
+- ⚠️ red-baseline 没有失败记录 → 伪造红色
+- ⚠️ green-final 包含失败记录 → 伪造绿色
+
+---
+
+### 检查 5：Git 历史交叉验证
+
+原理：Git 历史不会撒谎，用它来验证文档声明
+
+验证步骤：
+```bash
+# 1. 检查声称完成的变更是否有对应的代码提交
+change_id="xxx"
+commits=$(git log --oneline --all --grep="$change_id" | wc -l)
+if [[ $commits -eq 0 ]]; then
+  echo "❌ 变更 $change_id 声称完成，但 git 历史中没有相关提交"
+fi
+
+# 2. 检查测试文件是否在代码之后添加（TDD 违规检测）
+for test_file in tests/**/*.test.*; do
+  test_added=$(git log --format=%at --follow -- "$test_file" | tail -1)
+  # 找到对应的源文件
+  src_file=$(echo "$test_file" | sed 's/tests/src/' | sed 's/.test//')
+  if [[ -f "$src_file" ]]; then
+    src_added=$(git log --format=%at --follow -- "$src_file" | tail -1)
+    if [[ $test_added -gt $src_added ]]; then
+      echo "⚠️ 测试后于代码添加（非 TDD）: $test_file"
+    fi
+  fi
+done
+
+# 3. 检查是否有"一次性大提交"（可能是绕过流程）
+git log --oneline -20 | while read line; do
+  commit=$(echo "$line" | cut -d' ' -f1)
+  files_changed=$(git show --stat "$commit" | grep -E '[0-9]+ file' | grep -oE '[0-9]+' | head -1)
+  if [[ $files_changed -gt 20 ]]; then
+    echo "⚠️ 大提交检测: $commit 修改了 $files_changed 个文件，可能绕过增量验证"
+  fi
+done
+```
+
+迷惑检测：
+- ⚠️ 声称完成但无 git 提交 → 虚假变更
+- ⚠️ 测试后于代码添加 → 事后补测试
+- ⚠️ 大量文件一次提交 → 绕过增量验证
+
+---
+
+### 检查 6：实时测试运行验证（最可靠）
+
+原理：不信任任何日志，实际运行测试
+
+验证步骤：
+```bash
+# 1. 运行完整测试
+echo "=== 实时测试验证 ==="
+npm test 2>&1 | tee /tmp/live-test.log
+
+# 2. 检查结果
+if grep -qE 'FAIL|Error|failed' /tmp/live-test.log; then
+  echo "❌ 实时测试失败，文档声明不可信"
+  grep -E 'FAIL|Error|failed' /tmp/live-test.log
+else
+  echo "✅ 实时测试通过"
+fi
+
+# 3. 对比实时结果与证据文件
+if [[ -f "evidence/green-final/latest.log" ]]; then
+  live_pass=$(grep -c 'PASS|✓|passed' /tmp/live-test.log)
+  evidence_pass=$(grep -c 'PASS|✓|passed' evidence/green-final/latest.log)
+  if [[ $live_pass -ne $evidence_pass ]]; then
+    echo "⚠️ 实时通过数 ($live_pass) ≠ 证据通过数 ($evidence_pass)"
+  fi
+fi
+```
+
+迷惑检测：
+- ⚠️ 证据说绿色但实时运行失败 → 过时证据/假绿
+- ⚠️ 实时通过数与证据不符 → 证据伪造/环境差异
+
+---
+
+## 综合评分算法
+
+### 可信度评分（0-100）
+
+```python
+def calculate_trustworthiness(checks):
+    score = 100
+
+    # 严重问题（每个 -20 分）
+    critical = [
+        "证据为空",
+        "实时测试失败",
+        "Status 声称完成但测试失败",
+        "green-final 包含失败记录"
+    ]
+
+    # 警告问题（每个 -10 分）
+    warnings = [
+        "证据时间戳过旧",
+        "AC 对应测试不存在",
+        "占位符代码",
+        "大提交检测"
+    ]
+
+    # 轻微问题（每个 -5 分）
+    minor = [
+        "测试后于代码添加",
+        "证据文件过小"
+    ]
+
+    for issue in checks.critical_issues:
+        score -= 20
+    for issue in checks.warnings:
+        score -= 10
+    for issue in checks.minor_issues:
+        score -= 5
+
+    return max(0, score)
+```
+
+### 收敛性判定
+
+| 可信度 | 判定 | 建议 |
+|--------|------|------|
+| 90-100 | ✅ 可信收敛 | 继续当前流程 |
+| 70-89 | ⚠️ 部分可信 | 需要补充验证 |
+| 50-69 | 🟠 存疑 | 需要返工部分环节 |
+| < 50 | 🔴 不可信 | 西西弗斯困境，需要全面审查 |
+
+---
+
+## 输出格式
+
+```markdown
+# DevBooks 收敛性审计报告（反迷惑版）
+
+## 审计原则
+本报告采用"证据优先、声明存疑"原则，所有结论基于可验证证据，而非文档声明。
+
+## 声明 vs 证据对比
+
+| 检查项 | 文档声明 | 实际验证 | 结论 |
+|--------|----------|----------|------|
+| Status | Done | 测试实际失败 | ❌ 假完成 |
+| AC 覆盖 | 5/5 已打勾 | 2 个 AC 无对应测试 | ❌ 虚假覆盖 |
+| 测试状态 | 全绿 | 实时运行 3 个失败 | ❌ 过时证据 |
+| tasks.md | 10/10 完成 | 3 个任务代码不存在 | ❌ 虚假完成 |
+| evidence/ | 存在 | 目录非空，内容有效 | ✅ 有效 |
+
+## 可信度评分
+
+**总分**：45/100 🔴 不可信
+
+**扣分明细**：
+- -20：Status=Done 但实时测试失败
+- -20：AC 声称全覆盖但 2 个无测试
+- -10：tasks.md 3 个任务无代码
+- -5：证据时间戳早于代码修改
+
+## 迷惑检测结果
+
+### 🔴 检测到的假完成
+1. `change-auth`：Status=Done，但 `npm test` 失败 3 个
+2. `fix-cache`：AC-003 打勾，但 `tests/cache.test.ts` 不存在
+
+### 🟡 可疑项
+1. `refactor-api`：evidence/green-final/ 时间戳早于最后代码提交 2 天
+2. `feature-login`：tasks.md 全部打勾，但 `src/login.ts` 包含 TODO
+
+## 真实状态判定
+
+| 变更包 | 声明状态 | 真实状态 | 差距 |
+|--------|----------|----------|------|
+| change-auth | Done | 测试失败 | 🔴 严重 |
+| fix-cache | Verified | 覆盖不全 | 🟠 中等 |
+| refactor-api | Ready | 证据过时 | 🟡 轻微 |
+
+## 建议行动
+
+### 立即行动
+1. 将 `change-auth` 状态回退到 `In Progress`
+2. 为 `fix-cache` 的 AC-003 补充测试
+
+### 短期改进
+1. 建立证据时效性检查（证据必须晚于代码）
+2. AC 打勾前强制运行对应测试
+
+### 流程改进
+1. 禁止手动修改 Status，只能通过脚本验证后自动更新
+2. CI 集成收敛性检查，阻止假完成合入
+```
+
+---
+
+## 完成状态
+
+**状态**：✅ AUDIT_COMPLETED
+
+**核心发现**：
+- 文档声明可信度：X%
+- 检测到的假完成：N 个
+- 需要返工的变更：M 个
+
+**下一步**：
+- 假完成 → 立即回退状态，重新验证
+- 存疑项 → 补充证据或重新运行测试
+- 可信项 → 继续当前流程

package/skills/devbooks-delivery-workflow/SKILL.md

@@ -14,228 +14,34 @@ allowed-tools:
 
 # DevBooks：交付验收工作流（完整闭环编排器）
 
-> **定位**：本 Skill 是**纯编排层**，不是执行层。它只负责**调用子 Agent**，绝不自己执行任何变更工作。
-
----
-
-## 🚨 绝对禁令（ABSOLUTE RULES）
-
-> **这些规则没有例外，违反即失败。**
-
-### 禁令 1：禁止主 Agent 直接工作
-
-```
-❌ 禁止：主 Agent 自己写 proposal.md / design.md / tests/ / src/
-❌ 禁止：主 Agent 直接修改任何变更包内容
-❌ 禁止：主 Agent 跳过子 Agent 调用
-
-✅ 必须：所有工作通过 Task 工具调用子 Agent 完成
-✅ 必须：每个阶段都有对应的子 Agent 调用
-✅ 必须：主 Agent 只做编排、等待、验证
-```
-
-### 禁令 2：禁止跳过任何强制阶段
-
-```
-❌ 禁止：跳过 Challenger/Judge 阶段
-❌ 禁止：跳过 Test-Reviewer 阶段
-❌ 禁止：跳过 Code-Review 阶段
-❌ 禁止：跳过 Green-Verify 阶段
-❌ 禁止：未通过 strict 检查就归档
-
-✅ 必须：完整执行 12 个强制阶段
-✅ 必须：每个阶段的子 Agent 返回成功才能继续
-```
-
-### 禁令 3：禁止假完成归档
-
-```
-❌ 禁止：evidence/green-final/ 不存在或为空时归档
-❌ 禁止：verification.md AC 覆盖率 < 100% 时归档
-❌ 禁止：tasks.md 存在未完成任务时归档
-❌ 禁止：change-check.sh --mode strict 失败时归档
-
-✅ 必须：Archiver 子 Agent 先运行检查脚本
-✅ 必须：所有检查通过后才执行归档
-```
-
-### 禁令 4：禁止演示模式（NO DEMO MODE）
-
-```
-❌ 禁止：将工作流当作"演示"或"展示"
-❌ 禁止：输出"演示已完成"、"工作流演示"等措辞
-❌ 禁止：声称完成但实际产物不存在或为空
-❌ 禁止：用"模拟"、"假设"、"如果"代替实际执行
-
-✅ 必须：每个阶段都要产出真实的、可验证的产物
-✅ 必须：产物必须写入文件系统（可通过 ls/cat 验证）
-✅ 必须：使用"执行"、"完成"、"已创建"等真实动作词汇
-✅ 必须：如果无法真实执行，立即停止并告知用户
-```
-
-**检测演示模式的信号**：
-- 使用"演示"、"展示"、"模拟"等词汇
-- 声称完成但没有实际文件写入
-- 提供"选项 A/B"而非执行下一步
-- 输出"后续建议"而非继续执行
-
-### 禁令 5：禁止忽略 REVISE REQUIRED
-
-```
-❌ 禁止：收到 REVISE REQUIRED 后继续下一阶段
-❌ 禁止：收到 REVISE REQUIRED 后声称"已完成"
-❌ 禁止：收到 REVISE REQUIRED 后提供"选项"让用户选择
-❌ 禁止：收到 REJECTED 后继续执行
-
-✅ 必须：Judge 返回 REVISE → 回到阶段 1 重写提案
-✅ 必须：Judge 返回 REJECTED → 停止流程，告知用户
-✅ 必须：Test-Review 返回 REVISE REQUIRED → 回到阶段 7 修复测试
-✅ 必须：Code-Review 返回 REVISE REQUIRED → 回到阶段 8 修复代码
-✅ 必须：修复后重新执行评审阶段，直到通过
-```
-
-### 禁令 6：禁止部分完成前进
-
-```
-❌ 禁止：tasks.md 任务完成率 < 100% 时进入下一阶段
-❌ 禁止：测试覆盖率 < AC 要求时进入下一阶段
-❌ 禁止：存在空壳测试（skip/todo/not_implemented）时进入 Code 阶段
-❌ 禁止：存在未实现函数（raise NotImplementedError）时进入 Review 阶段
-
-✅ 必须：阶段 7 完成时，所有测试必须是真实的、可执行的
-✅ 必须：阶段 8 完成时，tasks.md 所有任务 100% 完成
-✅ 必须：如果发现范围过大，必须拆分变更包，不能部分完成
-```
-
----
-
-## 前置：配置发现
-
-执行前**必须**按以下顺序查找配置：
-1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议
-3. `project.md`（如存在）→ template 协议
-4. 若仍无法确定 → **停止并询问用户**
-
----
-
-## 完整闭环流程（12 个强制阶段）
-
-```
-┌──────────────────────────────────────────────────────────────────────────┐
-│                         强制流程（无可选阶段）                              │
-├──────────────────────────────────────────────────────────────────────────┤
-│                                                                          │
-│  ┌─────────┐   ┌───────────┐   ┌─────────┐   ┌─────────┐                │
-│  │1.Propose│──▶│2.Challenge│──▶│ 3.Judge │──▶│4.Design │                │
-│  └─────────┘   └───────────┘   └─────────┘   └─────────┘                │
-│       │                                            │                     │
-│       │              ┌─────────────────────────────┘                     │
-│       │              ▼                                                   │
-│       │        ┌─────────┐   ┌─────────┐   ┌─────────┐                  │
-│       │        │ 5.Spec  │──▶│ 6.Plan  │──▶│7.Test-R │                  │
-│       │        └─────────┘   └─────────┘   └─────────┘                  │
-│       │                                          │                       │
-│       │              ┌───────────────────────────┘                       │
-│       │              ▼                                                   │
-│       │        ┌─────────┐   ┌──────────┐   ┌──────────┐                │
-│       │        │ 8.Code  │──▶│9.TestRev │──▶│10.CodeRev│                │
-│       │        └─────────┘   └──────────┘   └──────────┘                │
-│       │                                            │                     │
-│       │              ┌─────────────────────────────┘                     │
-│       │              ▼                                                   │
-│       │        ┌───────────┐   ┌─────────┐                              │
-│       └───────▶│11.GreenV  │──▶│12.Archive│                              │
-│                └───────────┘   └─────────┘                              │
-│                                                                          │
-└──────────────────────────────────────────────────────────────────────────┘
-```
-
-### 阶段详解与子 Agent 调用
-
-| # | 阶段 | 子 Agent | Skill | 产物 | 强制 |
-|---|------|----------|-------|------|------|
-| 1 | Propose | `devbooks-proposal-author` | devbooks-proposal-author | proposal.md | ✅ |
-| 2 | Challenge | `devbooks-challenger` | devbooks-proposal-challenger | 质疑意见 | ✅ |
-| 3 | Judge | `devbooks-judge` | devbooks-proposal-judge | Decision Log | ✅ |
-| 4 | Design | `devbooks-designer` | devbooks-design-doc | design.md | ✅ |
-| 5 | Spec | `devbooks-spec-owner` | devbooks-spec-contract | specs/*.md | ✅ |
-| 6 | Plan | `devbooks-planner` | devbooks-implementation-plan | tasks.md | ✅ |
-| 7 | Test-Red | `devbooks-test-owner` | devbooks-test-owner | verification.md + tests/ | ✅ |
-| 8 | Code | `devbooks-coder` | devbooks-coder | src/ 实现 | ✅ |
-| 9 | Test-Review | `devbooks-reviewer` | devbooks-test-reviewer | 测试评审意见 | ✅ |
-| 10 | Code-Review | `devbooks-reviewer` | devbooks-reviewer | 代码评审意见 | ✅ |
-| 11 | Green-Verify | `devbooks-test-owner` | devbooks-test-owner | evidence/green-final/ | ✅ |
-| 12 | Archive | `devbooks-archiver` | devbooks-archiver | 归档到 archive/ | ✅ |
-
----
-
-## 📚 参考文档
-
-### 必读（立即阅读）
-
-1. **子 Agent 调用规范**：`references/子Agent调用规范.md`
-   - 调用格式和示例
-   - 角色隔离约束
-   - 何时阅读：开始编排前
-
-2. **编排逻辑伪代码**：`references/编排逻辑伪代码.md`
-   - 完整的编排逻辑
-   - 12 个阶段的详细实现
-   - 何时阅读：需要理解编排逻辑时
-
-### 按需阅读
-
-3. **闸门检查与错误处理**：`references/闸门检查与错误处理.md`
-   - 阶段闸门检查点
-   - 错误处理流程
-   - 回退执行规则
-   - 何时阅读：遇到错误或需要回退时
-
-4. **交付验收工作流**：`references/交付验收工作流.md`
-   - 完整的工作流说明
-   - 何时阅读：需要详细了解工作流时
-
-5. **变更验证与追溯模板**：`references/变更验证与追溯模板.md`
-   - 验证模板
-   - 何时阅读：需要模板参考时
-
----
-
-## 上下文感知
-
-### 检测流程
-
-1. 检测变更包是否存在
-2. 检测当前阶段（哪些阶段已完成）
-3. 从断点继续执行
-
-### 断点续跑
-
-若变更包已存在部分产物，从最近完成的阶段继续：
-
-```
-检测结果：
-- 变更包：存在
-- 已完成阶段：1-6（proposal, challenge, judge, design, spec, plan）
-- 下一阶段：7（Test-Red）
-- 运行模式：断点续跑
-```
-
----
-
-## MCP 说明
-
-本 Skill 不依赖 MCP 服务，无需运行时检测。
-
----
-
-## 可选检查脚本
-
-脚本位于本 Skill 的 `scripts/` 目录：
-
-- 初始化变更包骨架：`change-scaffold.sh`
-- 一键校验变更包：`change-check.sh`
-- 结构守门决策校验：`guardrail-check.sh`
-- 证据采集：`change-evidence.sh`
-- 进度仪表板：`progress-dashboard.sh`
+## 渐进披露
+### 基础层（必读）
+目标：以主 Agent 纯编排方式完成 12 阶段闭环交付。
+输入：用户目标、配置映射、已有变更包产物与阶段状态。
+输出：子 Agent 调用序列、阶段进度与结果汇总。
+边界：主 Agent 不直接改文件；必须通过 Task 调用子 Agent；遵守角色隔离与闸门规则。
+证据：各阶段产物路径、脚本输出与评审结果记录。
+
+### 进阶层（可选）
+适用：需要禁令细则、阶段表或断点续跑规则时。
+
+### 扩展层（可选）
+适用：需要闸门处理、追溯模板或脚本工具指引时。
+
+## 核心要点
+- 只负责编排，不直接产出提案/设计/测试/代码。
+- 12 阶段强制闭环，任一阶段失败必须回退修复。
+- 先完成配置发现（优先读取 `.devbooks/config.yaml`），再执行子 Agent 调用。
+
+## 参考资料
+- `skills/devbooks-delivery-workflow/references/编排禁令与阶段表.md`：绝对禁令、12 阶段流程与断点续跑。
+- `skills/devbooks-delivery-workflow/references/子Agent调用规范.md`：子 Agent 调用格式与隔离要求。
+- `skills/devbooks-delivery-workflow/references/编排逻辑伪代码.md`：编排主逻辑。
+- `skills/devbooks-delivery-workflow/references/闸门检查与错误处理.md`：闸门检查点与回退策略。
+- `skills/devbooks-delivery-workflow/references/交付验收工作流.md`：完整交付流程说明。
+- `skills/devbooks-delivery-workflow/references/变更验证与追溯模板.md`：验证与追溯模板。
+
+## 推荐 MCP 能力类型
+- 代码检索（code-search）
+- 引用追踪（reference-tracking）
+- 影响分析（impact-analysis）