dev-playbooks-cn 1.2.7 → 1.3.0

package/package.json

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

package/skills/_shared/references/spec-/347/273/223/346/236/204/346/250/241/346/235/277.md

@@ -0,0 +1,161 @@
+# Spec 结构模板
+
+> 本模板定义了 Spec 真理文件的标准结构，确保 Spec 可被验证、可被追溯、可被测试生成。
+
+## 文件位置
+
+```
+<truth-root>/specs/<capability>/spec.md
+```
+
+## 标准结构
+
+```markdown
+---
+# 元信息（必填）
+capability: <能力名称>
+owner: @<负责人>
+last_verified: YYYY-MM-DD
+last_referenced_by: <最后引用的 change-id>
+health: active | stale | deprecated
+freshness_check: monthly | quarterly | on-change
+---
+
+# <Capability 名称> 规格
+
+## Glossary（术语表）
+
+> 本能力专属术语，与 `<truth-root>/_meta/glossary.md` 保持一致。
+
+| 术语 | 定义 | 约束 |
+|------|------|------|
+| Order | 订单实体 | 必须有至少一个 OrderItem |
+| OrderItem | 订单项 | qty > 0, price >= 0 |
+
+## Invariants（不变量）
+
+> 必须始终成立的约束，违反即为系统 Bug。
+
+| ID | 描述 | 验证方式 |
+|----|------|----------|
+| INV-001 | 订单总额 = SUM(item.price * item.qty) | A（自动测试） |
+| INV-002 | 库存数量 >= 0 | A（自动测试） |
+| INV-003 | 已发货订单不可取消 | A（状态机测试） |
+
+## Contracts（契约）
+
+### Preconditions（前置条件）
+
+| ID | 操作 | 条件 | 违反时行为 |
+|----|------|------|-----------|
+| PRE-001 | 创建订单 | user.isAuthenticated | 返回 401 |
+| PRE-002 | 支付订单 | order.status == 'pending' | 返回 400 |
+
+### Postconditions（后置条件）
+
+| ID | 操作 | 保证 |
+|----|------|------|
+| POST-001 | 创建订单成功 | 生成唯一 order.id |
+| POST-002 | 支付成功 | inventory.decreased(qty) |
+
+## State Machine（状态机）
+
+> 如果本能力涉及状态流转，必须定义状态机。
+
+### 状态集
+
+```
+States: {Created, Paid, Shipped, Done, Cancelled}
+```
+
+### 转换规则
+
+| 当前状态 | 动作 | 目标状态 | 条件 |
+|----------|------|----------|------|
+| Created | pay | Paid | payment.success |
+| Created | cancel | Cancelled | - |
+| Paid | ship | Shipped | inventory.reserved |
+| Paid | refund | Cancelled | - |
+| Shipped | deliver | Done | - |
+
+### 禁止转换
+
+| 当前状态 | 动作 | 原因 |
+|----------|------|------|
+| Shipped | cancel | 违反 INV-003 |
+| Done | * | 终态，不可转出 |
+| Cancelled | * | 终态，不可转出 |
+
+## Requirements（需求）
+
+### REQ-001: <需求标题>
+
+**描述**：<一句话描述>
+
+**SHALL/SHOULD/MAY**：
+- 系统 **SHALL** ...
+- 系统 **SHOULD** ...
+
+**Trace**：AC-001（来自 design.md）
+
+#### Scenario: <场景名>
+
+- **GIVEN** 用户已登录且购物车非空
+- **WHEN** 用户点击"提交订单"
+- **THEN** 系统创建订单并返回订单 ID
+
+**数据实例**（边界条件）：
+
+| 输入 | 预期输出 | 说明 |
+|------|----------|------|
+| qty=1, price=100 | total=100 | 正常值 |
+| qty=0 | 拒绝 | 边界-零值 |
+| qty=-1 | 拒绝 | 边界-负值 |
+
+---
+
+## 变更历史
+
+| 日期 | 变更包 | 变更内容 |
+|------|--------|----------|
+| 2024-01-16 | 20240116-1030-add-cancel | 新增取消订单场景 |
+```
+
+## 使用指南
+
+### 1. 谁来写 Spec？
+
+- **spec-contract skill**：负责创建/更新 spec delta
+- **archiver skill**：负责将 spec delta 合并到 truth-root
+
+### 2. 谁来读 Spec？
+
+| Skill | 读取目的 |
+|-------|----------|
+| design-doc | 检查设计是否与现有 Spec 冲突，引用 REQ-xxx |
+| test-owner | 从契约/状态机生成测试 |
+| impact-analysis | 识别受影响的 Spec |
+| code-review | 检查术语一致性 |
+| archiver | 更新元信息，建立引用链 |
+
+### 3. 测试生成映射
+
+| Spec 元素 | 生成的测试类型 |
+|-----------|---------------|
+| INV-xxx | 不变量测试 |
+| PRE-xxx | 前置条件测试（满足+违反） |
+| POST-xxx | 后置条件测试 |
+| State Transition | 状态转换测试 |
+| Forbidden Transition | 禁止转换测试 |
+| Data Instance Table | 参数化测试用例 |
+
+### 4. 健康度检测
+
+Spec 文件的 `health` 字段由 entropy-monitor 自动检测：
+
+| 条件 | health 状态 |
+|------|-------------|
+| last_verified < 90 天 | `active` |
+| last_verified > 90 天 | `stale`（需要 review） |
+| 明确标记废弃 | `deprecated` |
+| last_referenced_by 为空超过 6 个月 | 建议删除 |

package/skills/_shared/references//351/200/232/347/224/250/345/256/210/351/227/250/345/215/217/350/256/256.md

@@ -39,9 +39,9 @@
 | 规格增量 | `<change-root>/<change-id>/specs/` | `./specs/` |
 | 追溯文档 | `<change-root>/<change-id>/verification.md` | `./verification.md` |
 
-### DevBooks 2.0 默认路径
+### Dev-Playbooks 默认路径
 
-当使用 DevBooks 2.0 协议时：
+当使用 Dev-Playbooks 协议时：
 - `<change-root>` = `dev-playbooks/changes`
 - `<truth-root>` = `dev-playbooks/specs`
 

package/skills/devbooks-archiver/SKILL.md

@@ -49,7 +49,7 @@ proposal → design → test-owner(P1) → coder → test-owner(P2) → code-rev
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 
@@ -120,6 +120,32 @@ proposal → design → test-owner(P1) → coder → test-owner(P2) → code-rev
 | `<change-root>/<change-id>/specs/**` | `<truth-root>/specs/**` | 增量合并 |
 | `<change-root>/<change-id>/contracts/**` | `<truth-root>/contracts/**` | 版本化合并 |
 
+**Spec 元信息更新**（合并时必须执行）：
+
+在合并 spec 到 truth-root 时，必须更新以下元信息：
+
+```yaml
+# 在每个被合并/引用的 spec 文件头部更新
+---
+last_referenced_by: <change-id>           # 最后引用此 spec 的变更包
+last_verified: <归档日期>                  # 最后验证日期
+health: active                            # 健康状态：active | stale | deprecated
+---
+```
+
+**元信息更新规则**：
+
+| 场景 | 更新行为 |
+|------|----------|
+| 新增 Spec | 创建完整元信息头 |
+| 修改已有 Spec | 更新 `last_referenced_by` 和 `last_verified` |
+| Spec 被设计文档引用但未修改 | 仅更新 `last_referenced_by` |
+| 标记为废弃 | 设置 `health: deprecated` |
+
+**建立引用追溯链**：
+
+归档时，archiver 会自动扫描 design.md 中声明的 "受影响的 Spec"（Affected Specs），并更新这些 Spec 的 `last_referenced_by` 字段，即使它们没有被直接修改。这建立了从 Spec 到变更包的反向追溯链。
+
 ### 第 4 步：架构合并
 
 > **设计决策**：C4 架构变更通过 design.md 的 Architecture Impact 章节记录，由 Archiver 在归档时合并到真理。

package/skills/devbooks-brownfield-bootstrap/SKILL.md

@@ -20,7 +20,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **创建 DevBooks 目录结构并初始化基础配置**
 

package/skills/devbooks-code-review/SKILL.md

@@ -45,7 +45,7 @@ proposal → design → test-owner(阶段1) → coder → test-owner(阶段2)
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-code-review/references//344/273/243/347/240/201/350/257/204/345/256/241/346/217/220/347/244/272/350/257/215.md

@@ -13,6 +13,10 @@
 - 统一语言表（如存在）：`<truth-root>/_meta/glossary.md`
 - 高 ROI 坑库（如存在）：`<truth-root>/engineering/pitfalls.md`
 
+**必须读取的 Spec 真理**（评审前强制检查）：
+- `<truth-root>/specs/**`：现有规格文件
+- 目的：验证代码命名/结构是否与 Spec 中定义的术语和契约一致
+
 硬约束（必须遵守）：
 1) 只输出审查意见与修改建议；不直接改 tests/ 或设计文档。
 2) 不讨论业务逻辑正确性（由测试/规格裁判）；只讨论可维护性与工程质量。
@@ -64,6 +68,12 @@
 - 是否存在同一概念在不同模块中使用不同命名？（如 User/Account/Member 混用）
 - Entity 与 ValueObject 的区分是否正确？（Entity 有 ID，VO 无 ID 且不可变）
 
+**Spec 真理术语对照**（必须检查）：
+- 代码中的命名是否与 `<truth-root>/specs/` 中定义的术语一致？
+- 状态名/枚举值是否与 Spec 中的状态机定义一致？
+- 方法名是否反映 Spec 中的动作/转换？（如 `cancel()` 对应 `order --[cancel]--> cancelled`）
+- 若发现命名不一致，标记为"术语漂移风险"并建议统一
+
 ---
 
 ## Invariant 保护（必须检查）

package/skills/devbooks-coder/SKILL.md

@@ -53,7 +53,7 @@ proposal → design → test-owner(阶段1) → [Coder] → test-owner(阶段2)
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 
@@ -161,7 +161,7 @@ proposal → design → test-owner(阶段1) → [Coder] → test-owner(阶段2)
 
 **正确的路径示例**：
 ```bash
-# DevBooks 2.0 默认路径
+# Dev-Playbooks 默认路径
 dev-playbooks/changes/<change-id>/evidence/green-final/test-$(date +%Y%m%d-%H%M%S).log
 
 # 使用脚本

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

@@ -19,7 +19,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-delivery-workflow/scripts/change-check.sh

@@ -528,7 +528,7 @@ check_spec_deltas() {
 }
 
 # =============================================================================
-# Constitution Check (DevBooks 2.0)
+# Constitution Check (Dev-Playbooks)
 # Verify project constitution is present and valid
 # =============================================================================
 check_constitution() {
@@ -562,7 +562,7 @@ check_constitution() {
 }
 
 # =============================================================================
-# Fitness Check (DevBooks 2.0)
+# Fitness Check (Dev-Playbooks)
 # Verify architecture fitness rules
 # =============================================================================
 check_fitness() {
@@ -1038,9 +1038,9 @@ else
   check_verification
   check_no_tests_changed
   check_implicit_changes
-  # DevBooks 2.0: Constitution check
+  # Dev-Playbooks: Constitution check
   check_constitution               # Constitution validity check (strict mode)
-  # DevBooks 2.0: Fitness check
+  # Dev-Playbooks: Fitness check
   check_fitness                    # Architecture fitness check (apply/archive/strict)
   # New quality gates (harden-devbooks-quality-gates)
   check_evidence_closure       # AC-001: Green evidence required for archive

package/skills/devbooks-design-backport/SKILL.md

@@ -52,7 +52,7 @@ coder 有偏离 → 归档时 archiver 自动检测并回写 → 归档
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-design-doc/SKILL.md

@@ -40,7 +40,7 @@ proposal → [Design Doc] → spec-contract → implementation-plan → test-own
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-design-doc/references//350/256/276/350/256/241/346/226/207/346/241/243/346/217/220/347/244/272/350/257/215.md

@@ -18,6 +18,10 @@
 - 聊天记录
 - 统一语言表（如存在）：`<truth-root>/_meta/glossary.md`
 
+**必须读取的 Spec 真理**（设计前强制检查）：
+- `<truth-root>/specs/**`：现有规格文件（REQ/Invariants/Contracts）
+- 目的：确保本次设计不与现有规格冲突，并显式引用受影响的规格
+
 任务：
 1) 输出设计文档（不是编码计划、不是代码实现）。
 2) 文档必须达到“可驱动验收、可驱动计划拆解”的颗粒度：清晰边界、契约、红线、验收。
@@ -181,9 +185,15 @@ Acceptance Criteria 写法要求：
 - 不输出实现步骤、PR 切分建议、生产代码具体文件路径与函数体代码
 - 不输出可运行伪代码；如必须描述算法，只写 Inputs/Outputs/Invariants/复杂度上限/降级策略
 
-补充要求（用于大型项目的“可追溯性”）：
-- 在文档中显式列出本次变更影响的“能力/模块/对外契约”（仅列名称与边界，不写实现）
-- 若涉及对外接口/API/事件/数据结构：必须在“核心数据与事件契约”章节写清楚版本化策略（schema_version、兼容窗口、迁移/回放原则）
-- 若涉及架构边界变化：在“目标架构”章节增加一个 **C4 Delta（可选）** 小节：说明 C1/C2/C3 哪些元素被新增/修改/移除（不要求画完整图；完整图由架构地图维护）
+补充要求（用于大型项目的"可追溯性"）：
+- 在文档中显式列出本次变更影响的"能力/模块/对外契约"（仅列名称与边界，不写实现）
+- 若涉及对外接口/API/事件/数据结构：必须在"核心数据与事件契约"章节写清楚版本化策略（schema_version、兼容窗口、迁移/回放原则）
+- 若涉及架构边界变化：在"目标架构"章节增加一个 **C4 Delta（可选）** 小节：说明 C1/C2/C3 哪些元素被新增/修改/移除（不要求画完整图；完整图由架构地图维护）
+
+**Spec 真理引用要求**（可追溯性核心）：
+- **必须声明受影响的现有 Spec**：列出本次设计影响的 `<truth-root>/specs/` 下的规格文件
+- **必须引用 REQ/Invariant**：设计中涉及的每个约束必须追溯到 Spec 中的 REQ-xxx 或 INV-xxx
+- **Gap 声明**：如果本次设计无法满足某个现有 REQ，必须显式声明为 Gap 并说明原因
+- **术语一致性**：设计中使用的领域术语必须与 `<truth-root>/_meta/glossary.md` 一致；如需引入新术语，必须在设计文档中声明并建议添加到 glossary
 
 现在开始输出该《设计文档》Markdown，不要输出额外解释。

package/skills/devbooks-docs-sync/SKILL.md

@@ -16,7 +16,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-entropy-monitor/SKILL.md

@@ -19,7 +19,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-impact-analysis/SKILL.md

@@ -17,7 +17,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-impact-analysis/references//345/275/261/345/223/215/345/210/206/346/236/220/346/217/220/347/244/272/350/257/215.md

@@ -17,6 +17,10 @@
 - 当前真理源：`<truth-root>/`
 - 代码库（只读分析）
 
+**必须读取的 Spec 真理**（分析前强制检查）：
+- `<truth-root>/specs/**`：现有规格文件
+- 目的：识别本次变更影响哪些现有 Specs（REQ/Invariants/Contracts）
+
 硬约束（必须遵守）：
 - 先影响分析，后写代码
 - 禁止“装饰性/表层重构”（除非直接降低本次改动风险）
@@ -53,6 +57,19 @@
        - 外部系统/API 变更是否被 ACL 隔离？（外部模型变化不应直接传播到内部模型）
        - 是否存在直接调用外部 API 而未经过适配层的代码？
        - 若新增外部依赖：建议的 ACL 接口定义
+   - **F. 受影响的 Spec 真理**（必须分析）：
+     - 列出本次变更影响的 `<truth-root>/specs/` 下的规格文件
+     - 对每个受影响 Spec，标注影响类型：
+       - `[BREAK]`：破坏现有 REQ/Invariant（需要更新 Spec 或重新设计）
+       - `[EXTEND]`：扩展现有能力（需要新增 REQ/Scenario）
+       - `[DEPRECATE]`：废弃现有能力（需要标记 Spec 为 deprecated）
+     - 输出格式：
+       ```
+       Affected Specs:
+       - [EXTEND] specs/order/spec.md - 新增取消订单场景
+       - [BREAK] specs/payment/spec.md - INV-002 "已支付不可取消" 需要修改
+       - [DEPRECATE] specs/legacy-checkout/spec.md - 整体废弃
+       ```
 4) 兼容性与风险（Compatibility & Risks）
    - Breaking 变化（如有必须显式标注）
    - 迁移/回滚路径

package/skills/devbooks-implementation-plan/SKILL.md

@@ -54,7 +54,7 @@ proposal → design → [Implementation Plan] → test-owner(阶段1) → coder
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-proposal-author/SKILL.md

@@ -18,7 +18,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-proposal-challenger/SKILL.md

@@ -16,7 +16,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-proposal-judge/SKILL.md

@@ -18,7 +18,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-router/SKILL.md

@@ -32,7 +32,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-spec-contract/SKILL.md

@@ -21,7 +21,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 

package/skills/devbooks-spec-contract/references//350/247/204/346/240/274/345/217/230/346/233/264/346/217/220/347/244/272/350/257/215.md

@@ -18,6 +18,10 @@
 - 项目画像（如存在，优先遵循其中的格式约定）：`<truth-root>/_meta/project-profile.md`
 - 统一语言表（如存在）：`<truth-root>/_meta/glossary.md`
 
+**Spec 真理冲突检测**（写入前必须完成）：
+- **必须读取现有 Spec**：在写 spec delta 前，必须读取 `<truth-root>/specs/**` 所有现有规格
+- **目的**：检测新 spec delta 是否与现有 Specs 存在冲突
+
 硬约束（必须遵守）：
 - 你输出的是 **spec delta**，不是设计文档、不是编码计划、不是代码实现
 - 不写实现细节（类名/函数名/具体文件路径/库调用）
@@ -26,6 +30,13 @@
 - 避免重复能力：先搜索/复用/修改已有 capability spec，必要时才新增 capability
 - 统一语言：若 `<truth-root>/_meta/glossary.md` 存在，必须使用其中的术语；禁止发明新词汇
 
+**概念完整性守护**（冲突检测规则）：
+- **术语冲突检测**：新 spec 中的术语是否与现有 spec 使用的术语命名不一致？（如 `Order.status` vs `Order.state`）
+- **规则冲突检测**：新 spec 的规则是否与现有 spec 的规则矛盾？（如"已支付可取消" vs "已支付不可取消"）
+- **边界冲突检测**：新 spec 的职责边界是否与现有 spec 重叠？（如两个 spec 都声称拥有 payment 逻辑）
+- **Invariant 兼容检测**：新 spec 是否破坏现有 spec 声明的 Invariants？
+- **冲突报告**：如检测到冲突，必须在 spec delta 开头声明冲突并建议解决方案；冲突未解决前禁止归档
+
 研讨会（内部步骤，不单独输出）：
 - 在写 spec 前先做“虚拟三剑客研讨会”（业务/开发/测试），把共识与边缘实例融入 Requirement/Scenario；不要单独输出研讨会纪要
 

package/skills/devbooks-test-owner/SKILL.md

@@ -59,7 +59,7 @@ proposal → design → [Test Owner 阶段1] → coder → [Test Owner 阶段2]
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**
 
@@ -205,7 +205,7 @@ Test Owner 必须产出结构化的 `verification.md`，同时作为测试计划
 
 **正确的路径示例**：
 ```bash
-# DevBooks 2.0 默认路径
+# Dev-Playbooks 默认路径
 dev-playbooks/changes/<change-id>/evidence/red-baseline/test-$(date +%Y%m%d-%H%M%S).log
 
 # 使用脚本

package/skills/devbooks-test-owner/references//346/265/213/350/257/225/344/273/243/347/240/201/346/217/220/347/244/272/350/257/215.md

@@ -11,6 +11,10 @@
   - 设计/规格文档
   - 测试驱动/验收方法论（参考：`references/测试驱动.md`）
 
+  **必须读取的 Spec 真理**（测试前强制检查）：
+  - `<truth-root>/specs/**`：现有规格文件
+  - 目的：从 Spec 中的契约（Preconditions/Postconditions/Invariants）和状态机自动生成测试骨架
+
   产物落点（目录约定，协议无关）：
   - 测试计划与追溯文档推荐保存为：`<change-root>/<change-id>/verification.md`
   - 测试代码变更仍落在仓库惯例目录（例如 `tests/`），但追溯矩阵与人工验收清单优先放在本次变更包内（verification.md），避免散落到对外 docs
@@ -57,7 +61,7 @@
   在完成 A 后，开始在仓库中实现测试代码（只写测试，不写业务实现），要求：
 
   【核心理念（必须遵守）】
-  1) **测试=可执行契约（Executable Spec）**：从“设计要求/验收标准/不变量”推导测试，而不是从“现有代码结构”推导测
+  1) **测试=可执行契约（Executable Spec）**：从"设计要求/验收标准/不变量"推导测试，而不是从"现有代码结构"推导测
   试。
   2) **行为优先、实现无关**：优先断言输出行为/数据契约/事件内容/不变量；避免断言私有函数调用次数、内部步骤顺序等实
   现细节。
@@ -65,6 +69,16 @@
   归。
   4) **少而硬（风险驱动）**：优先覆盖最危险的失败模式（隔离、幂等/重放、质量闸门、错误级联阻断、契约漂移）。
 
+  **从 Spec 真理生成契约测试**（必须遵守）：
+  - **Invariants → 不变量测试**：Spec 中每个 `[Invariant]` 或 `INV-xxx` 必须生成对应的不变量测试
+  - **Preconditions → 前置条件测试**：Spec 中每个 `PRE-xxx` 生成两类测试：(1) 满足条件时正常执行 (2) 违反条件时正确拒绝
+  - **Postconditions → 后置条件测试**：Spec 中每个 `POST-xxx` 生成结果验证测试
+  - **State Machine → 状态转换测试**：如 Spec 包含状态机定义，必须生成：
+    - 所有合法转换路径的测试
+    - 所有禁止转换的拒绝测试
+    - 终态不可转出的测试
+  - **REQ 覆盖追溯**：每个测试必须在注释或 verification.md 中标注其覆盖的 REQ-xxx/INV-xxx/PRE-xxx/POST-xxx
+
   **测试覆盖率分级要求**（辩论修订版）：
   > 来源：《重构》辩论修订版——从"一刀切80%"改为"分级要求"
 

package/skills/devbooks-test-reviewer/SKILL.md

@@ -14,7 +14,7 @@ allowed-tools:
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
 1. `.devbooks/config.yaml`（如存在）→ 解析并使用其中的映射
-2. `dev-playbooks/project.md`（如存在）→ DevBooks 2.0 协议，使用默认映射
+2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议，使用默认映射
 3. `project.md`（如存在）→ template 协议，使用默认映射
 4. 若仍无法确定 → **停止并询问用户**