dev-playbooks-cn 1.3.0 → 1.5.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "dev-playbooks-cn",
-  "version": "1.3.0",
+  "version": "1.5.0",
   "description": "AI-driven spec-based development workflow",
   "keywords": [
     "devbooks",

package/skills/devbooks-coder/SKILL.md

@@ -14,16 +14,27 @@ allowed-tools:
 
 ## 工作流位置感知（Workflow Position Awareness）
 
-> **核心原则**：Coder 在 Test Owner 阶段 1 之后执行，完成后交给 Test Owner 阶段 2 验证。
+> **核心原则**：Coder 在 Test Owner 阶段 1 之后执行，通过**模式标签**（而非会话隔离）实现思维清晰。
 
 ### 我在整体工作流中的位置
 
 ```
-proposal → design → test-owner(阶段1) → [Coder] → test-owner(阶段2) → code-review → archive
-                                            ↓
-                                    实现代码、让测试变绿
+proposal → design → [TEST-OWNER] → [CODER] → [TEST-OWNER] → code-review → archive
+                                      ↓              ↓
+                               实现+快轨测试    证据审计+打勾
+                              (@smoke/@critical)  (不重跑@full)
 ```
 
+### AI 时代个人开发优化
+
+> **重要变更**：本协议针对 AI 编程 + 个人开发场景优化，**去掉了"单独会话"的硬性要求**。
+
+| 旧设计 | 新设计 | 原因 |
+|--------|--------|------|
+| Test Owner 和 Coder 必须单独会话 | 同一会话，用 `[TEST-OWNER]` / `[CODER]` 模式标签切换 | 减少上下文重建成本 |
+| Coder 跑完整测试等待结果 | Coder 跑快轨（`@smoke`/`@critical`），`@full` 异步触发 | 快速迭代 |
+| 完成后直接交给 Test Owner | 完成后状态为 `Implementation Done`，等 @full 通过 | 异步不阻塞，归档同步 |
+
 ### Coder 的职责边界
 
 | 允许 | 禁止 |
@@ -31,18 +42,60 @@ proposal → design → test-owner(阶段1) → [Coder] → test-owner(阶段2)
 | 修改 `src/**` 代码 | ❌ 修改 `tests/**` |
 | 勾选 `tasks.md` 任务项 | ❌ 修改 `verification.md` |
 | 记录偏离到 `deviation-log.md` | ❌ 勾选 AC 覆盖矩阵 |
-| 运行测试验证 | ❌ 设置 verification.md Status |
+| 运行快轨测试（`@smoke`/`@critical`） | ❌ 设置 verification.md Status 为 Verified/Done |
+| 触发 `@full` 测试（CI/后台） | ❌ 等待 @full 完成（可以开始下一个变更） |
 
 ### Coder 完成后的流程
 
-1. **任务完成**：tasks.md 全部 `[x]`
-2. **测试全绿**：运行 `npm test` 确认通过
-3. **交付 Test Owner**：通知 Test Owner 进入阶段 2 验证
-4. **等待验证结果**：
-   - Test Owner 确认全绿 → 进入 Code Review
-   - Test Owner 发现问题 → Coder 修复
+1. **快轨测试绿**：`@smoke` + `@critical` 通过
+2. **触发 @full**：提交代码，CI 开始异步运行 @full 测试
+3. **状态变更**：设置变更状态为 `Implementation Done`
+4. **可以开始下一个变更**（不阻塞）
+5. **等待 @full 结果**：
+   - @full 通过 → Test Owner 进入阶段 2 审计证据
+   - @full 失败 → Coder 修复
+
+**关键提醒**：
+- Coder 完成后，状态是 `Implementation Done`，**不是直接进入 Code Review**
+- 开发迭代是异步的（可以开始下一个变更），但归档是同步的（必须等 @full 通过）
+
+---
+
+## 测试分层与运行策略（关键！）
+
+> **核心原则**：Coder 只运行快轨测试，@full 测试异步触发，不阻塞开发迭代。
+
+### 测试分层标签
+
+| 标签 | 用途 | Coder 何时运行 | 预期耗时 |
+|------|------|----------------|----------|
+| `@smoke` | 快速反馈，核心路径 | 每次代码修改后 | 秒级 |
+| `@critical` | 关键功能验证 | 准备提交前 | 分钟级 |
+| `@full` | 完整验收测试 | **不运行**，触发 CI 异步执行 | 可以慢 |
 
-**关键提醒**：Coder 完成后，**不是直接进入 Code Review**，而是先让 Test Owner 验证并打勾。
+### Coder 的测试运行策略
+
+```bash
+# 开发过程中：频繁运行 @smoke
+npm test -- --grep "@smoke"
+
+# 准备提交前：运行 @critical
+npm test -- --grep "@smoke|@critical"
+
+# 提交后：CI 自动运行 @full（Coder 不等待）
+git push  # 触发 CI
+# → Coder 可以开始下一个任务
+```
+
+### 异步与同步的边界
+
+| 动作 | 阻塞/异步 | 说明 |
+|------|-----------|------|
+| `@smoke` 测试 | 同步 | 每次修改后立即运行 |
+| `@critical` 测试 | 同步 | 提交前必须通过 |
+| `@full` 测试 | **异步** | CI 后台运行，不阻塞 Coder |
+| 开始下一个变更 | **不阻塞** | Coder 可以立即开始 |
+| 归档 | **阻塞** | 必须等 @full 通过 |
 
 ---
 
@@ -319,26 +372,29 @@ fi
 
 | 状态码 | 状态 | 判定条件 | 下一步 |
 |:------:|------|----------|--------|
-| ✅ | COMPLETED | 所有任务完成，无偏离 | `devbooks-code-review` |
-| ⚠️ | COMPLETED_WITH_DEVIATION | 任务完成，deviation-log 有未回写记录 | `devbooks-design-backport` |
-| 🔄 | HANDOFF | 发现测试问题需要修改 | `devbooks-test-owner` |
+| ✅ | IMPLEMENTATION_DONE | 快轨测试绿，@full 已触发，无偏离 | 切换到 `[TEST-OWNER]` 等待 @full |
+| ⚠️ | IMPLEMENTATION_DONE_WITH_DEVIATION | 快轨绿，deviation-log 有未回写记录 | `devbooks-design-backport` |
+| 🔄 | HANDOFF | 发现测试问题需要修改 | 切换到 `[TEST-OWNER]` 模式修复测试 |
 | ❌ | BLOCKED | 需要外部输入/决策 | 记录断点，等待用户 |
-| 💥 | FAILED | 闸门未通过 | 修复后重试 |
+| 💥 | FAILED | 快轨测试未通过 | 修复后重试 |
 
 ### 状态判定流程
 
 ```
 1. 检查 deviation-log.md 是否有 "| ❌" 记录
-   → 有：COMPLETED_WITH_DEVIATION
+   → 有：IMPLEMENTATION_DONE_WITH_DEVIATION
 
 2. 检查是否需要修改 tests/
-   → 是：HANDOFF to test-owner
+   → 是：HANDOFF to [TEST-OWNER] 模式
+
+3. 检查快轨测试（@smoke + @critical）是否全部通过
+   → 否：FAILED
 
-3. 检查 tasks.md 是否全部完成
-   → 否：BLOCKED 或 FAILED
+4. 检查 tasks.md 是否全部完成
+   → 否：BLOCKED 或继续实现
 
-4. 以上都通过
-   → COMPLETED
+5. 以上都通过，触发 @full
+   → IMPLEMENTATION_DONE
 ```
 
 ### 路由输出模板（必须使用）
@@ -348,37 +404,41 @@ fi
 ```markdown
 ## 完成状态
 
-**状态**：✅ COMPLETED / ⚠️ COMPLETED_WITH_DEVIATION / 🔄 HANDOFF / ❌ BLOCKED / 💥 FAILED
+**状态**：✅ IMPLEMENTATION_DONE / ⚠️ ... / 🔄 HANDOFF / ❌ BLOCKED / 💥 FAILED
 
 **任务进度**：X/Y 已完成
 
+**快轨测试**：@smoke ✅ / @critical ✅
+
+**@full 测试**：已触发（CI 异步运行中）
+
 **偏离记录**：有 N 条待回写 / 无
 
 ## 下一步
 
-**推荐**：`devbooks-xxx skill`
+**推荐**：切换到 `[TEST-OWNER]` 模式等待 @full / `devbooks-xxx skill`
 
 **原因**：[具体原因]
 
-### 如何调用
-运行 devbooks-xxx skill 处理变更 <change-id>
+**注意**：可以开始下一个变更，不需要等待 @full 完成
 ```
 
 ### 具体路由规则
 
 | 我的状态 | 下一步 | 原因 |
 |----------|--------|------|
-| COMPLETED | `devbooks-test-owner`（阶段 2 验证） | 任务完成，需要 Test Owner 验证并打勾 |
-| COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再让 Test Owner 验证 |
-| HANDOFF (测试问题) | `devbooks-test-owner` | Coder 不能修改测试 |
+| IMPLEMENTATION_DONE | 切换到 `[TEST-OWNER]` 模式（等 @full） | 快轨绿，等 @full 通过后审计证据 |
+| IMPLEMENTATION_DONE_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计 |
+| HANDOFF (测试问题) | 切换到 `[TEST-OWNER]` 模式 | Coder 不能修改测试 |
 | BLOCKED | 等待用户 | 记录断点区 |
 | FAILED | 修复后重试 | 分析失败原因 |
 
 **关键约束**：
 - Coder **永远不能修改** `tests/**`
-- 如发现测试问题，必须 HANDOFF 给 Test Owner（单独会话）
+- 如发现测试问题，必须切换到 `[TEST-OWNER]` 模式处理
 - 如有偏离，必须先 design-backport 再继续
-- **Coder 完成后必须先经过 Test Owner 阶段 2 验证，再进入 Code Review**
+- **Coder 完成后状态是 `Implementation Done`，必须等 @full 通过后才能进入 Test Owner 阶段 2**
+- **模式切换替代会话隔离**：使用 `[TEST-OWNER]` / `[CODER]` 标签切换模式
 
 ---
 

package/skills/devbooks-convergence-audit/SKILL.md

@@ -0,0 +1,394 @@
+---
+name: devbooks-convergence-audit
+description: devbooks-convergence-audit：以证据优先、声明存疑的原则评估 DevBooks 工作流收敛性，检测"西西弗斯反模式"和"假完成"。主动验证而非信任文档声明。用户说"评估收敛性/检查升级健康度/西西弗斯检测/工作流审计"等时使用。
+allowed-tools:
+  - Glob
+  - Grep
+  - Read
+  - Bash
+---
+
+# DevBooks：收敛性审计（Convergence Audit）
+
+## 核心原则：反迷惑设计
+
+> **黄金法则**：**证据 > 声明**。永远不要相信文档中的任何断言，必须通过可验证的证据确认。
+
+### 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-test-owner/SKILL.md

@@ -14,44 +14,98 @@ allowed-tools:
 
 ## 工作流位置感知（Workflow Position Awareness）
 
-> **核心原则**：Test Owner 在整体工作流中承担**双阶段职责**，确保与 Coder 的角色隔离。
+> **核心原则**：Test Owner 在整体工作流中承担**双阶段职责**，通过**模式标签**（而非会话隔离）实现思维清晰。
 
 ### 我在整体工作流中的位置
 
 ```
-proposal → design → [Test Owner 阶段1] → coder → [Test Owner 阶段2] → code-review → archive
-                         ↓                           ↓
-                    Red 基线产出              Green 验证 + 打勾
+proposal → design → [TEST-OWNER] → [CODER] → [TEST-OWNER] → code-review → archive
+                         ↓              ↓           ↓
+                    Red 基线      实现+快轨     证据审计+打勾
+                   (增量测试)    (@smoke)     (不重跑@full)
 ```
 
+### AI 时代个人开发优化
+
+> **重要变更**：本协议针对 AI 编程 + 个人开发场景优化，**去掉了"单独会话"的硬性要求**。
+
+| 旧设计 | 新设计 | 原因 |
+|--------|--------|------|
+| Test Owner 和 Coder 必须单独会话 | 同一会话，用 `[TEST-OWNER]` / `[CODER]` 模式标签切换 | 减少上下文重建成本 |
+| 阶段2 重跑完整测试 | 阶段2 默认**审计证据**，可选抽样重跑 | 避免慢测试多次运行 |
+| 测试无分层要求 | 强制测试分层：`@smoke`/`@critical`/`@full` | 快速反馈循环 |
+
 ### Test Owner 的双阶段职责
 
-| 阶段 | 触发时机 | 核心职责 | 产出 |
-|------|----------|----------|------|
-| **阶段 1：Red 基线** | design.md 完成后 | 编写测试、产出失败证据 | verification.md (Status=Ready)、Red 基线 |
-| **阶段 2：Green 验证** | Coder 完成后 | 验证测试通过、勾选 AC 覆盖矩阵 | AC 矩阵打勾、Status 保持 Ready（等 Reviewer 设 Done） |
+| 阶段 | 触发时机 | 核心职责 | 测试运行方式 | 产出 |
+|------|----------|----------|--------------|------|
+| **阶段 1：Red 基线** | design.md 完成后 | 编写测试、产出失败证据 | 只跑**增量测试**（新写的/P0） | verification.md (Status=Ready)、Red 基线 |
+| **阶段 2：Green 验证** | Coder 完成 + @full 通过后 | **审计证据**、勾选 AC 覆盖矩阵 | 默认不重跑，可选抽样 | AC 矩阵打勾、Status=Verified |
 
 ### 阶段 2 详细职责（关键！）
 
 当用户说"Coder 完成了，请验证"或类似请求时，Test Owner 进入**阶段 2**：
 
-1. **运行全部测试**：执行 `npm test` 或项目测试命令
-2. **验证 Green 状态**：确认所有测试通过
-3. **勾选 AC 覆盖矩阵**：在 verification.md 的 AC 覆盖矩阵中将 `[ ]` 改为 `[x]`
-4. **收集 Green 证据**：保存到 `evidence/green-final/`
-5. **输出验证报告**：总结测试结果和覆盖情况
+1. **检查前置条件**：确认 @full 测试已通过（查看 CI 结果或 `evidence/green-final/`）
+2. **审计证据**（默认模式）：
+   - 检查 `evidence/green-final/` 目录下的测试日志
+   - 验证 commit hash 与当前代码一致
+   - 确认测试覆盖了所有 AC
+3. **可选抽样重跑**：对高风险 AC 或有疑问的测试进行抽样验证
+4. **勾选 AC 覆盖矩阵**：在 verification.md 的 AC 覆盖矩阵中将 `[ ]` 改为 `[x]`
+5. **设置状态为 Verified**：表示测试验证通过，等待 Code Review
 
 ### AC 覆盖矩阵复选框权限（重要！）
 
 | 复选框位置 | 谁可以勾选 | 勾选时机 |
 |------------|-----------|----------|
-| AC 覆盖矩阵中的 `[ ]` | **Test Owner** | 阶段 2 验证 Green 状态后 |
+| AC 覆盖矩阵中的 `[ ]` | **Test Owner** | 阶段 2 审计证据确认后 |
+| Status 字段 `Verified` | **Test Owner** | 阶段 2 完成后 |
 | Status 字段 `Done` | Reviewer | Code Review 通过后 |
 
 **禁止**：Coder 不能勾选 AC 覆盖矩阵，不能修改 verification.md。
 
 ---
 
+## 测试分层与运行策略（关键！）
+
+> **核心原则**：测试分层是解决"慢测试阻塞开发"问题的关键。
+
+### 测试分层标签（必须使用）
+
+| 标签 | 用途 | 谁运行 | 预期耗时 | 何时运行 |
+|------|------|--------|----------|----------|
+| `@smoke` | 快速反馈，核心路径 | Coder 频繁运行 | 秒级 | 每次代码修改后 |
+| `@critical` | 关键功能验证 | Coder 提交前运行 | 分钟级 | 准备提交时 |
+| `@full` | 完整验收测试 | CI 异步运行 | 可以慢（小时级） | 后台/CI |
+
+### 各阶段测试运行策略
+
+| 阶段 | 运行什么 | 目的 | 阻塞/异步 |
+|------|----------|------|-----------|
+| **Test Owner 阶段1** | 只跑**新写的测试** | 确认 Red 状态 | 同步（但只是增量） |
+| **Coder 开发中** | `@smoke` | 快速反馈循环 | 同步 |
+| **Coder 提交前** | `@critical` | 关键路径验证 | 同步 |
+| **Coder 完成时** | `@full`（触发 CI） | 完整验收 | **异步**（不阻塞开发） |
+| **Test Owner 阶段2** | **不运行**（审计证据） | 独立验证 | N/A |
+
+### 异步与同步的边界（关键！）
+
+```
+✅ 异步的：开发迭代（Coder 完成后可以开始下一个变更，不等 @full）
+❌ 同步的：归档门禁（归档必须等 @full 通过）
+
+时间线示例：
+T1: Coder 完成实现，触发 @full 异步测试 → 状态 = Implementation Done
+T2: Coder 可以开始下一个变更（不阻塞）
+T3: @full 测试通过 → 状态 = 可进入阶段2
+T4: Test Owner 审计证据 + 打勾 → 状态 = Verified
+T5: Code Review → 状态 = Done
+T6: 归档（此时 @full 一定已通过）
+```
+
+---
+
 ## 前置：配置发现（协议无关）
 
 - `<truth-root>`：当前真理目录根
@@ -86,10 +140,15 @@ Test Owner 必须产出结构化的 `verification.md`，同时作为测试计划
 |------|------|-----------|
 | `Draft` | 初始状态 | 自动生成 |
 | `Ready` | 测试计划就绪 | **Test Owner** |
+| `Implementation Done` | 实现完成，等待 @full 测试 | **Coder** |
+| `Verified` | @full 通过 + 证据审计完成 | **Test Owner** |
 | `Done` | Review 通过 | Reviewer（禁止 Test Owner/Coder） |
-| `Archived` | 已归档 | Spec Gardener |
+| `Archived` | 已归档 | Archiver |
 
-**约束**：Test Owner 完成测试计划后，应将 Status 设为 `Ready`。
+**关键约束**：
+- `Verified` 状态要求 @full 测试必须已通过
+- 只有 `Verified` 或 `Done` 状态的变更才能归档
+- Test Owner 完成测试计划后设 `Ready`，完成证据审计后设 `Verified`
 
 ```markdown
 # 验证计划：<change-id>
@@ -385,14 +444,14 @@ Test Owner 有两个阶段，完成状态因阶段而异：
 
 | 当前阶段 | 如何判断 | 完成后下一步 |
 |----------|----------|--------------|
-| **阶段 1** | verification.md 不存在或 Red 基线未产出 | → Coder |
-| **阶段 2** | 用户说"验证/打勾"且 Coder 已完成 | → Code Review |
+| **阶段 1** | verification.md 不存在或 Red 基线未产出 | → `[CODER]` 模式 |
+| **阶段 2** | 用户说"验证/打勾"且 @full 测试已通过 | → Code Review |
 
 ### 阶段 1 完成状态分类（MECE）
 
 | 状态码 | 状态 | 判定条件 | 下一步 |
 |:------:|------|----------|--------|
-| ✅ | PHASE1_COMPLETED | Red 基线产出，无偏离 | `devbooks-coder`（单独会话） |
+| ✅ | PHASE1_COMPLETED | Red 基线产出，无偏离 | 切换到 `[CODER]` 模式 |
 | ⚠️ | PHASE1_COMPLETED_WITH_DEVIATION | Red 基线产出，deviation-log 有未回写记录 | `devbooks-design-backport` |
 | ❌ | BLOCKED | 需要外部输入/决策 | 记录断点，等待用户 |
 | 💥 | FAILED | 测试框架问题等 | 修复后重试 |
@@ -401,8 +460,9 @@ Test Owner 有两个阶段，完成状态因阶段而异：
 
 | 状态码 | 状态 | 判定条件 | 下一步 |
 |:------:|------|----------|--------|
-| ✅ | PHASE2_VERIFIED | 测试全绿，AC 矩阵已打勾 | `devbooks-code-review` |
-| ❌ | PHASE2_FAILED | 测试未通过 | 通知 Coder 修复，或 HANDOFF |
+| ✅ | PHASE2_VERIFIED | 证据审计通过，AC 矩阵已打勾 | `devbooks-code-review` |
+| ⏳ | PHASE2_WAITING | @full 测试仍在运行 | 等待 CI 完成 |
+| ❌ | PHASE2_FAILED | @full 测试未通过 | 通知 Coder 修复 |
 | 🔄 | PHASE2_HANDOFF | 发现测试本身有问题 | 修复测试后重新验证 |
 
 ### 阶段判定流程
@@ -421,11 +481,13 @@ Test Owner 有两个阶段，完成状态因阶段而异：
    c. 以上都通过 → PHASE1_COMPLETED
 
 3. 阶段 2 状态判定：
-   a. 运行测试，检查是否全绿
+   a. 检查 @full 测试是否已完成
+      → 否：PHASE2_WAITING
+   b. 检查 @full 测试是否通过
       → 否：PHASE2_FAILED
-   b. 检查测试本身是否有问题
+   c. 检查测试本身是否有问题
       → 是：PHASE2_HANDOFF
-   c. 全绿且无问题 → PHASE2_VERIFIED
+   d. 审计证据，确认覆盖 → PHASE2_VERIFIED
 ```
 
 ### 路由输出模板（必须使用）
@@ -437,11 +499,13 @@ Test Owner 有两个阶段，完成状态因阶段而异：
 
 **阶段**：阶段 1（Red 基线）/ 阶段 2（Green 验证）
 
-**状态**：✅ PHASE1_COMPLETED / ✅ PHASE2_VERIFIED / ⚠️ ... / ❌ ... / 💥 ...
+**状态**：✅ PHASE1_COMPLETED / ✅ PHASE2_VERIFIED / ⏳ PHASE2_WAITING / ...
 
 **Red 基线**：已产出 / 未完成（仅阶段 1）
 
-**Green 验证**：全绿 / 有失败（仅阶段 2）
+**@full 测试**：已通过 / 运行中 / 失败（仅阶段 2）
+
+**证据审计**：已完成 / 待审计（仅阶段 2）
 
 **AC 矩阵**：已打勾 N/M / 未打勾（仅阶段 2）
 
@@ -449,31 +513,29 @@ Test Owner 有两个阶段，完成状态因阶段而异：
 
 ## 下一步
 
-**推荐**：`devbooks-xxx skill`
+**推荐**：切换到 `[CODER]` 模式 / `devbooks-xxx skill`
 
 **原因**：[具体原因]
-
-### 如何调用
-运行 devbooks-xxx skill 处理变更 <change-id>
 ```
 
 ### 具体路由规则
 
 | 我的状态 | 下一步 | 原因 |
 |----------|--------|------|
-| PHASE1_COMPLETED | `devbooks-coder`（单独会话） | Red 基线已产出，Coder 实现以变绿 |
+| PHASE1_COMPLETED | 切换到 `[CODER]` 模式 | Red 基线已产出，Coder 实现以变绿 |
 | PHASE1_COMPLETED_WITH_DEVIATION | `devbooks-design-backport` | 先回写设计，再交给 Coder |
-| PHASE2_VERIFIED | `devbooks-code-review` | 测试全绿，可以进入代码评审 |
-| PHASE2_FAILED | 通知 Coder | 测试未通过，需要 Coder 修复 |
+| PHASE2_VERIFIED | `devbooks-code-review` | 证据审计通过，可以进入代码评审 |
+| PHASE2_WAITING | 等待 CI | @full 测试仍在运行 |
+| PHASE2_FAILED | 通知 Coder 修复 | 测试未通过，需要 Coder 修复 |
 | PHASE2_HANDOFF | 修复测试 | 测试本身有问题，Test Owner 修复 |
 | BLOCKED | 等待用户 | 记录断点区 |
 | FAILED | 修复后重试 | 分析失败原因 |
 
 **关键约束**：
-- **角色隔离**：Coder 必须在**单独的会话/实例**中工作
-- Test Owner 和 Coder 不能共享同一会话上下文
+- **模式切换替代会话隔离**：使用 `[TEST-OWNER]` / `[CODER]` 标签切换模式
 - 如有偏离，必须先 design-backport 再交给 Coder
 - **阶段 2 的 AC 矩阵打勾只能由 Test Owner 执行**
+- **阶段 2 必须等 @full 测试通过后才能打勾**
 
 ---