dev-playbooks-cn 4.0.4 → 4.0.5

package/docs/SSOT/344/270/216Spec/350/276/271/347/225/214/350/257/264/346/230/216.md

@@ -0,0 +1,115 @@
+# SSOT 与 Spec 边界说明
+
+本文档明确 DevBooks 中 SSOT（Single Source of Truth）和 Spec（Specification）的职责边界。
+
+## 核心区别
+
+| 维度 | SSOT | Spec |
+|------|------|------|
+| **抽象层次** | 需求层（What） | 设计层（How） |
+| **粒度** | 项目级 | 模块级 |
+| **内容** | 系统必须做什么 | 模块如何工作 |
+| **来源** | 业务/产品/合规/架构约束 | 技术设计决策 |
+| **变更频率** | 低（里程碑级） | 中（功能级） |
+
+## 内容示例
+
+### SSOT 示例
+
+```markdown
+# R-001: API 错误格式标准化
+- severity: must
+- 所有对外 API 必须返回标准错误格式
+- 错误响应必须包含 code、message、details 字段
+```
+
+### Spec 示例
+
+```markdown
+# ErrorResponse Spec
+
+## Schema
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| code | string | Y | 错误码，格式 `E-{MODULE}-{NUMBER}` |
+| message | string | Y | 人类可读错误信息 |
+| details | object | N | 附加上下文 |
+
+## 行为
+- 4xx 错误：code 以 `E-CLIENT-` 开头
+- 5xx 错误：code 以 `E-SERVER-` 开头
+```
+
+## 目录结构
+
+```
+dev-playbooks/
+├── ssot/                        # 【需求层】项目级真理源
+│   ├── SSOT.md                  # 人类可读的需求/约束文档
+│   ├── requirements.index.yaml  # 机读索引（稳定 ID → 锚点）
+│   └── requirements.ledger.yaml # 派生进度（可丢弃可重建）
+│
+├── specs/                       # 【设计层】模块级行为规格
+│   ├── _meta/                   # 元数据（画像/术语表）
+│   ├── architecture/            # 架构约束
+│   └── <capability>/spec.md     # 模块规格
+│
+└── changes/                     # 变更历史
+    └── <change-id>/
+        ├── proposal.md          # upstream_claims 引用 SSOT
+        └── specs/               # spec delta（归档后合并到 specs/）
+```
+
+## 追溯链条
+
+```
+SSOT.md (R-001: API 错误格式标准化)
+    ↓ 索引
+requirements.index.yaml (R-001 → anchor → statement)
+    ↓ 引用
+changes/<id>/proposal.md (upstream_claims: [R-001])
+    ↓ 设计
+changes/<id>/specs/error-handling/spec.md (ErrorResponse 设计)
+    ↓ 归档
+specs/error-handling/spec.md (真理)
+```
+
+## Skill 职责划分
+
+### SSOT 相关
+
+| Skill | 职责 | 触发时机 |
+|-------|------|----------|
+| `brownfield-bootstrap` | **创建** SSOT 骨架 | 存量项目初始化 |
+| `ssot-maintainer` | **维护** SSOT（增删改） | SSOT 内容变更 |
+
+### Spec 相关
+
+| Skill | 职责 | 触发时机 |
+|-------|------|----------|
+| `brownfield-bootstrap` | **创建** 基线 Spec | 存量项目初始化 |
+| `spec-contract` | **定义** 模块行为规格 | 变更包设计阶段 |
+| `design-doc` | **设计** 架构与约束 | 变更包设计阶段 |
+
+## 常见问题
+
+### Q: 什么时候写 SSOT，什么时候写 Spec？
+
+- **写 SSOT**：当你在定义"系统必须满足的约束"时
+  - 例：合规要求、SLA 承诺、API 兼容性保证
+- **写 Spec**：当你在设计"具体模块如何实现"时
+  - 例：接口签名、数据模型、状态机
+
+### Q: SSOT 和 Spec 可以只保留一个吗？
+
+不能。它们是不同抽象层次：
+- SSOT 是"输入"（需求来源）
+- Spec 是"输出"（设计决策）
+
+一个需求（SSOT）可能影响多个模块的 Spec。
+
+### Q: 变更包的 upstream_claims 引用什么？
+
+引用 SSOT 中的需求 ID（如 `R-001`），不引用 Spec。
+
+Spec 是变更包的"产出"，不是"输入"。

package/package.json

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

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

@@ -1,6 +1,6 @@
 ---
 name: devbooks-brownfield-bootstrap
-description: devbooks-brownfield-bootstrap：存量项目初始化：在当前真理目录为空时生成项目画像、术语表、基线规格与最小验证锚点，避免"边补 specs 边改行为"。用户说"存量初始化/基线 specs/项目画像/建立 glossary/把老项目接入上下文协议"等时使用。
+description: devbooks-brownfield-bootstrap：存量项目初始化：在当前真理目录为空时生成项目画像、术语表、SSOT、基线规格与最小验证锚点，避免"边补 specs 边改行为"。用户说"存量初始化/基线 specs/项目画像/建立 glossary/初始化 SSOT/把老项目接入上下文协议"等时使用。
 recommended_experts: ["System Architect", "Technical Writer"]
 allowed-tools:
   - Glob
@@ -27,6 +27,29 @@ allowed-tools:
 ### 扩展层（可选）
 适用：需要与外部系统或可选工具协同时补充。
 
+## 与 ssot-maintainer 的职责边界
+
+| Skill | 职责 | 类比 |
+|-------|------|------|
+| **brownfield-bootstrap** | **创建** SSOT/Spec 骨架（从无到有） | `git init` |
+| **ssot-maintainer** | **维护** SSOT（增删改已有条目） | `git commit` |
+
+**关键区分**：
+- 本 Skill 负责**初始化**：当 `ssot/` 目录不存在或为空时，生成骨架
+- `ssot-maintainer` 负责**维护**：当 SSOT 已存在后，处理 delta、同步索引、刷新 ledger
+- 初始化完成后，后续 SSOT 变更应使用 `ssot-maintainer`
+
+## SSOT 与 Spec 的区别
+
+| 维度 | SSOT | Spec |
+|------|------|------|
+| **抽象层次** | 需求层（What） | 设计层（How） |
+| **粒度** | 项目级 | 模块级 |
+| **位置** | `<devbooks-root>/ssot/` | `<truth-root>/` |
+| **内容** | 系统必须做什么 | 模块如何工作 |
+
+详见 `docs/SSOT与Spec边界说明.md`
+
 ## 推荐 MCP 能力类型
 - 代码检索（code-search）
 - 引用追踪（reference-tracking）
@@ -34,8 +57,8 @@ allowed-tools:
 
 ## 前置：配置发现（协议无关）
 
-- `<truth-root>`：当前真理目录根
-- `<change-root>`：变更包目录根
+- `<truth-root>`：当前真理目录根（通常是 `dev-playbooks/specs/`）
+- `<change-root>`：变更包目录根（通常是 `dev-playbooks/changes/`）
 - `<devbooks-root>`：DevBooks 管理目录（通常是 `dev-playbooks/`）
 
 执行前**必须**按以下顺序查找配置（找到后停止）：
@@ -55,7 +78,7 @@ allowed-tools:
 
 存量项目初始化包含以下职责：
 
-### 1. 基础配置文件初始化（新增）
+### 1. 基础配置文件初始化
 
 在 `<devbooks-root>/`（通常是 `dev-playbooks/`）下检查并创建：
 
@@ -84,19 +107,39 @@ allowed-tools:
 | 文档维护元数据 | `_meta/docs-maintenance.md` | 文档风格与维护配置 |
 | 领域概念 | `_meta/key-concepts.md` | 基于代码语义的概念提取（可选） |
 
-### 2.5 项目级 SSOT（当无上游 SSOT 时必须创建）
+### 3. 项目级 SSOT 初始化（核心职责）
+
+在 `<devbooks-root>/ssot/` 下生成 SSOT 骨架：
+
+| 产物 | 路径 | 说明 |
+|------|------|------|
+| SSOT 文档 | `ssot/SSOT.md` | 人类可读的需求/约束文档 |
+| 需求索引 | `ssot/requirements.index.yaml` | 机读索引（稳定 ID → 锚点 → statement） |
+
+**生成策略：骨架优先 + 渐进补全**
+
+1. **核心契约提取**（AI 主导）
+   - 扫描 API 定义（OpenAPI/GraphQL/RPC）
+   - 扫描数据模型（Schema/Entity）
+   - 扫描配置约束（env vars/feature flags）
+   - 扫描关键业务规则（从代码注释/测试用例推断）
 
-为解决“SSOT 巨大且频繁变动时，无法判定哪些已交付/未交付”的问题，本 Skill 在缺少上游 SSOT 时必须先落盘**最小可寻址 SSOT 包**（不复制长文档，只写索引与可裁判条目）：
+2. **置信度标记**
+   - 每条 requirement 标记 `confidence: low|medium|high`
+   - AI 生成默认为 `medium`
+   - 人类确认后升级为 `high`
 
-| 产物 | 路径（相对 `<truth-root>`） | 说明 |
-|------|---------------------------|------|
-| Project SSOT | `ssot/SSOT.md` | 人类可读的系统级真相骨架（需求/契约/运行约束/开放问题） |
-| Requirements Set（机读） | `ssot/requirements.index.yaml` | 稳定 ID → 锚点 → statement；供 `upstream_claims` 与归档裁判使用 |
-| Requirements Ledger（派生缓存） | `ssot/requirements.ledger.yaml` | 进度视图，可丢弃可重建；由脚本从归档变更包派生 |
+3. **最小可行 SSOT**
+   - 初始目标：5-15 条核心需求
+   - 不追求完整，追求可寻址
+   - 后续通过 `ssot-maintainer` 渐进补全
 
-若项目已存在上游 SSOT（例如独立 `SSOT docs/`），该 Skill 不复制原文，而是在 `ssot/SSOT.md` 中写入指针/链接，并以 `requirements.index.yaml` 建立稳定 ID 与锚点索引。
+**上游 SSOT 处理**：
+- 若项目已存在上游 SSOT（例如独立 `SSOT docs/`）
+- 本 Skill 不复制原文，而是在 `ssot/SSOT.md` 中写入指针/链接
+- 并以 `requirements.index.yaml` 建立稳定 ID 与锚点索引
 
-### 3. 架构分析产物
+### 4. 架构分析产物
 
 在 `<truth-root>/architecture/` 下生成：
 
@@ -109,7 +152,7 @@ allowed-tools:
 
 > **设计决策**：C4 架构地图现在由 brownfield-bootstrap 在初始化时生成，后续架构变更通过 design.md 的 Architecture Impact 章节记录，由 archiver 在归档时合并。
 
-### 4. 基线变更包
+### 5. 基线变更包（可选）
 
 在 `<change-root>/<baseline-id>/` 下生成：
 

package/skills/devbooks-delivery-workflow/scripts/ssot-scaffold.sh

@@ -5,16 +5,16 @@ usage() {
   cat <<'EOF' >&2
 usage: ssot-scaffold.sh [options]
 
-Scaffold a minimal Project SSOT pack under truth_root when upstream SSOT is absent.
+Scaffold a minimal Project SSOT pack under devbooks_root when upstream SSOT is absent.
 
 Creates (default):
-  <truth-root>/ssot/SSOT.md
-  <truth-root>/ssot/requirements.index.yaml
+  <devbooks-root>/ssot/SSOT.md
+  <devbooks-root>/ssot/requirements.index.yaml
 
 Options:
   --project-root <dir>    Project root directory (default: pwd)
-  --truth-root <dir>      Truth root directory (default: specs)
-  --ssot-dir <dir>        SSOT dir under truth_root (default: ssot)
+  --devbooks-root <dir>   DevBooks root directory (default: dev-playbooks)
+  --ssot-dir <dir>        SSOT dir under devbooks_root (default: ssot)
   --set-id <id>           requirements.index set_id (default: derived from project dir)
   --source-ref <ref>      requirements.index source_ref (default: truth://<ssot-dir>/SSOT.md)
   --force                 Overwrite existing files
@@ -24,6 +24,7 @@ Notes:
 - This script is intentionally deterministic and does not "discover" external SSOT.
   Use it when your project does not have an upstream SSOT, or you want an internal pointer file.
 - requirements.index.yaml schema_version is fixed to 1.0.0 (required by upstream_claims checks).
+- For full SSOT initialization with AI-assisted content extraction, use brownfield-bootstrap skill.
 EOF
 }
 
@@ -34,7 +35,7 @@ die_usage() {
 }
 
 project_root="${DEVBOOKS_PROJECT_ROOT:-$(pwd)}"
-truth_root="${DEVBOOKS_TRUTH_ROOT:-specs}"
+devbooks_root="${DEVBOOKS_ROOT:-dev-playbooks}"
 ssot_dir="ssot"
 set_id=""
 source_ref=""
@@ -50,8 +51,8 @@ while [[ $# -gt 0 ]]; do
       project_root="${2:-}"
       shift 2
       ;;
-    --truth-root)
-      truth_root="${2:-}"
+    --devbooks-root|--truth-root)
+      devbooks_root="${2:-}"
       shift 2
       ;;
     --ssot-dir)
@@ -77,20 +78,20 @@ while [[ $# -gt 0 ]]; do
 done
 
 project_root="${project_root%/}"
-truth_root="${truth_root%/}"
+devbooks_root="${devbooks_root%/}"
 ssot_dir="${ssot_dir%/}"
 
-if [[ -z "$project_root" || -z "$truth_root" || -z "$ssot_dir" ]]; then
+if [[ -z "$project_root" || -z "$devbooks_root" || -z "$ssot_dir" ]]; then
   die_usage "missing required paths"
 fi
 
-if [[ "$truth_root" = /* ]]; then
-  truth_dir="$truth_root"
+if [[ "$devbooks_root" = /* ]]; then
+  devbooks_dir="$devbooks_root"
 else
-  truth_dir="${project_root}/${truth_root}"
+  devbooks_dir="${project_root}/${devbooks_root}"
 fi
 
-ssot_pack_dir="${truth_dir}/${ssot_dir}"
+ssot_pack_dir="${devbooks_dir}/${ssot_dir}"
 
 if [[ -z "$set_id" ]]; then
   base="$(basename "$project_root")"

package/skills/devbooks-ssot-maintainer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: devbooks-ssot-maintainer
-description: devbooks-ssot-maintainer：维护项目 SSOT 的“可寻址索引与派生进度视图”。用于“修改/同步 SSOT（上游或项目内）→ 生成可审计 delta → 同步 requirements.index.yaml →（可选）刷新 requirements.ledger.yaml”。通常由 `/devbooks:delivery` 在 `request_kind=governance` 路由下调用。
+description: devbooks-ssot-maintainer：维护项目 SSOT 的"可寻址索引与派生进度视图"。用于"修改/同步 SSOT（上游或项目内）→ 生成可审计 delta → 同步 requirements.index.yaml →（可选）刷新 requirements.ledger.yaml"。通常由 `/devbooks:delivery` 在 `request_kind=governance` 路由下调用。注意：SSOT 初始化请使用 `brownfield-bootstrap`。
 recommended_experts: ["Technical Writer", "System Architect"]
 allowed-tools:
   - Glob
@@ -15,27 +15,50 @@ allowed-tools:
 
 ## 渐进披露
 ### 基础层（必读）
-目标：把“改 SSOT”从口头叙述升级为**可机读、可审计、可裁判**的闭环：`ssot.delta.yaml → requirements.index.yaml →（可选）requirements.ledger.yaml`。  
-输入：变更包路径、上游/项目内 SSOT 的引用锚点、以及本次变更的 delta。  
+目标：把"改 SSOT"从口头叙述升级为**可机读、可审计、可裁判**的闭环：`ssot.delta.yaml → requirements.index.yaml →（可选）requirements.ledger.yaml`。
+输入：变更包路径、上游/项目内 SSOT 的引用锚点、以及本次变更的 delta。
 输出：
 - `<change-root>/<change-id>/inputs/ssot.delta.yaml`（本次变更的最小机读输入）
-- `<truth-root>/ssot/requirements.index.yaml`（真相：稳定 ID → anchor → statement）
-- `<truth-root>/ssot/requirements.ledger.yaml`（派生缓存：进度视图，可丢弃可重建）
+- `<devbooks-root>/ssot/requirements.index.yaml`（真相：稳定 ID → anchor → statement）
+- `<devbooks-root>/ssot/requirements.ledger.yaml`（派生缓存：进度视图，可丢弃可重建）
 边界：
 - 不通读/不复制上游 SSOT 全库；只维护索引与引用锚点。
 - 不改变 `upstream_claims` 的合同语义。
+- **不负责 SSOT 初始化**（初始化请使用 `brownfield-bootstrap`）。
 证据：脚本输出日志、更新后的索引文件、（可选）ledger 刷新日志。
 
 ### 进阶层（可选）
-适用：需要同时管理“上游 SSOT（外部目录）+ 项目级最小 SSOT 包”时的约束与最佳实践。
+适用：需要同时管理"上游 SSOT（外部目录）+ 项目级最小 SSOT 包"时的约束与最佳实践。
 
 ### 扩展层（可选）
 适用：需要将 SSOT 维护纳入 Knife/Epic 切片（例如 `slices[].ssot_ids`）或更严格治理闸门时。
 
+## 与 brownfield-bootstrap 的职责边界
+
+| Skill | 职责 | 类比 | 触发时机 |
+|-------|------|------|----------|
+| **brownfield-bootstrap** | **创建** SSOT 骨架 | `git init` | `ssot/` 不存在或为空 |
+| **ssot-maintainer** | **维护** SSOT（增删改） | `git commit` | SSOT 已存在，需要变更 |
+
+**关键区分**：
+- 如果 `<devbooks-root>/ssot/` 目录不存在或为空，应先使用 `brownfield-bootstrap` 初始化
+- 本 Skill 只处理**已有 SSOT 的增删改**，不负责从零创建
+
+## SSOT 与 Spec 的区别
+
+| 维度 | SSOT | Spec |
+|------|------|------|
+| **抽象层次** | 需求层（What） | 设计层（How） |
+| **粒度** | 项目级 | 模块级 |
+| **位置** | `<devbooks-root>/ssot/` | `<truth-root>/` |
+| **内容** | 系统必须做什么 | 模块如何工作 |
+
+详见 `docs/SSOT与Spec边界说明.md`
+
 ## 前置：配置发现（协议无关）
 
 执行前必须按以下顺序查找配置（找到后停止）：
-1. `.devbooks/config.yaml`（如存在）→ 解析映射（尤其是 `truth_mapping.ssot_root`）
+1. `.devbooks/config.yaml`（如存在）→ 解析映射（尤其是 `paths.ssot`）
 2. `dev-playbooks/project.md`（如存在）→ Dev-Playbooks 协议
 3. `project.md`（如存在）→ template 协议
 4. 若仍无法确定 → 停止并询问用户
@@ -46,11 +69,12 @@ allowed-tools:
 
 - 若存在上游 SSOT 文档库：在项目 `.devbooks/config.yaml` 配置：
   - `truth_mapping: { ssot_root: "SSOT docs/" }`
-- 若不存在上游 SSOT：确保 `<truth-root>/ssot/SSOT.md` 与 `<truth-root>/ssot/requirements.index.yaml` 存在（可用 `skills/devbooks-delivery-workflow/scripts/ssot-scaffold.sh` 生成骨架）。
+- 若不存在上游 SSOT：确保 `<devbooks-root>/ssot/SSOT.md` 与 `<devbooks-root>/ssot/requirements.index.yaml` 存在
+  - 如果不存在，提示用户先运行 `brownfield-bootstrap` 初始化
 
 ### 2) 修改 SSOT（内容编辑）并产出 delta（机读）
 
-你可以用 AI 讨论“要怎么改”，但最终必须落盘为 delta（禁止只留在聊天里）：
+你可以用 AI 讨论"要怎么改"，但最终必须落盘为 delta（禁止只留在聊天里）：
 
 - 推荐落点：`<change-root>/<change-id>/inputs/ssot.delta.yaml`
 - 约束：`statement` 必须是单行字符串（否则脚本会拒绝执行）
@@ -68,14 +92,14 @@ allowed-tools:
 
 ### 4) （可选）刷新进度账本（派生缓存）
 
-若你需要“已做/未做”的可见性（仪表板/审计），可刷新：
+若你需要"已做/未做"的可见性（仪表板/审计），可刷新：
 - `skills/devbooks-delivery-workflow/scripts/requirements-ledger-derive.sh ...`
 
 注意：ledger 是 derived cache，可删可重建，不能当作 SSOT 采信。
 
 ## 推荐用法（通过 Delivery 统一入口）
 
-当你的诉求是“修改 SSOT/同步索引/更新账本”，建议在 `/devbooks:delivery` 的输入里明确：
+当你的诉求是"修改 SSOT/同步索引/更新账本"，建议在 `/devbooks:delivery` 的输入里明确：
 
 - `request_kind=governance`
 - 变更类型：SSOT maintenance

package/templates/.devbooks/config.yaml

@@ -17,6 +17,7 @@ project: project.md
 
 # 路径配置
 paths:
+  ssot: ssot/
   specs: specs/
   changes: changes/
   scripts: scripts/

package/templates/CLAUDE.md

@@ -11,6 +11,12 @@
 - 提交信息
 - 规格说明
 
+## 核心概念
+
+- **SSOT**（`dev-playbooks/ssot/`）：需求层真理源，定义"系统必须做什么"
+- **Spec**（`dev-playbooks/specs/`）：设计层规格，定义"模块如何工作"
+- 详见 `docs/SSOT与Spec边界说明.md`
+
 ## 工作流
 
 当请求满足以下条件时，始终打开 `@/AGENTS.md`：

package/templates/dev-playbooks/ssot/SSOT.md

@@ -0,0 +1,70 @@
+# SSOT - Single Source of Truth
+
+> 本文档是项目的**需求层真理源**，定义"系统必须做什么"。
+>
+> - 技术设计（"如何实现"）请参见 `specs/` 目录
+> - 机读索引请参见 `requirements.index.yaml`
+
+## 系统边界
+
+<!-- 描述系统与外部世界的边界 -->
+
+### 用户角色
+
+| 角色 | 描述 |
+|------|------|
+| <!-- 角色名 --> | <!-- 角色描述 --> |
+
+### 外部系统
+
+| 系统 | 交互方式 | 说明 |
+|------|----------|------|
+| <!-- 系统名 --> | <!-- API/消息/文件 --> | <!-- 说明 --> |
+
+## 核心需求
+
+<!--
+每条需求格式：
+- id: R-XXX（稳定 ID，不可变）
+- severity: must | should | may
+- statement: 单行描述（必须可机读）
+-->
+
+### R-001: <!-- 需求标题 -->
+
+- **severity**: must
+- **statement**: <!-- 单行需求描述 -->
+
+<!-- 补充说明（可选） -->
+
+## 约束与合规
+
+<!-- 非功能性约束：性能、安全、合规等 -->
+
+### 性能约束
+
+| 指标 | 要求 | 说明 |
+|------|------|------|
+| <!-- 指标名 --> | <!-- 阈值 --> | <!-- 说明 --> |
+
+### 安全约束
+
+<!-- 安全相关的强制要求 -->
+
+### 合规要求
+
+<!-- 法规/标准合规要求 -->
+
+## 开放问题
+
+<!-- 尚未决定的问题，需要后续澄清 -->
+
+| ID | 问题 | 状态 | 决定 |
+|----|------|------|------|
+| Q-001 | <!-- 问题描述 --> | open | - |
+
+---
+
+> **维护说明**：
+> - 修改本文档后，需同步更新 `requirements.index.yaml`
+> - 使用 `ssot-maintainer` skill 或 `ssot-index-sync.sh` 脚本

package/templates/dev-playbooks/ssot/requirements.index.yaml

@@ -0,0 +1,22 @@
+schema_version: 1.0.0
+set_id: PROJECT_ID
+source_ref: truth://ssot/SSOT.md
+
+# Requirements Index
+#
+# 本文件是 SSOT.md 的机读索引，用于：
+# - upstream_claims 验证
+# - 归档裁判
+# - 进度追踪
+#
+# 维护方式：
+# - 手动编辑后运行 ssot-index-sync.sh --validate
+# - 或通过 ssot-maintainer skill 的 delta 机制更新
+
+requirements:
+  # - id: R-001
+  #   severity: must
+  #   anchor: "## R-001"
+  #   statement: "需求描述（单行）"
+  #   confidence: medium  # low | medium | high
+  #   source: ai-inferred  # manual | ai-inferred | imported

package/templates/dev-playbooks/requirements/requirements.index.yaml

@@ -1,9 +0,0 @@
-schema_version: 1.0.0
-set_id: SET_ID
-source_ref: truth://path/to/source.md
-
-requirements:
-  - id: R-001
-    severity: must
-    anchor: ""
-    statement: "Requirement statement (must be machine-auditable)"