kld-sdd 2.6.7 → 2.6.9

package/templates/skills/kld-sdd/opsx-ontology-query/phase-3-postchange.md

@@ -0,0 +1,223 @@
+# Phase 3 · 变更后验证（Post-change Verification）
+
+> **触发时机**：opsx-archive 完成 KB 入库后
+> **加载方式**：opsx-archive §5.5 入库成功后 `Read` 本文件执行验证
+> **前置条件**：archive zip 已成功上传到 KB，job 状态为 succeeded
+>
+> ✅ **数据边界**：这是 SDD 流程中**唯一**能从 KB 查到当前变更数据的阶段。
+> Archive → kb-ingest 完成后，当前变更的实体已入库并成为 current 版本。
+> 本阶段所有 KB 查询都是验证**刚入库的当前变更**是否正确。
+
+---
+
+## §1 版本变更生效验证
+
+### 场景
+
+入库后验证 modified 实体的新版本是否正确成为 current。
+
+### API
+
+```
+GET {base}/entities/{entityId}/current-version
+```
+
+### 示例
+
+验证 CAP-USER-LOGIN 的新版本是否生效：
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/current-version"
+```
+
+### 验证清单
+
+| 字段 | 期望值 | 来源 |
+|------|--------|------|
+| `entityVersionId` | 新版本 UUID | archive package 中声明的 version-id |
+| `deltaState` | `modified` | proposal/spec 中的 delta-state |
+| `predecessorVersionId` | 旧版本 UUID | archive package 中的 predecessor-version |
+| `generationRole` | `current`（本次变更 authored） | 工具链设置 / KB 推导 |
+
+> **`generationRole` 值说明**：由 `kld-sdd` 工具链（`effective-graph.cjs`）在打包 archive 时设置，三个合法值：
+> - `current` — 本次变更作者编写的事实（added/modified/removed）
+> - `inherited` — 从上一次已确认 archive 继承的事实（unchanged）
+> - `produced` — 系统自动生成的事实（如 change record）
+>
+> IngestionService 优先使用 archive 包提供的值；若缺失则从 `deltaState` 推导（`unchanged→inherited`、`added/modified/removed→current`），推导逻辑与工具链词表一致。
+| `reviewStatus` | `confirmed` | 入库后自动确认 |
+| `changeId` | 当前变更 ID | archive package 中的 change-id |
+
+### 决策逻辑
+
+| 检查结果 | 状态 | 动作 |
+|----------|------|------|
+| 所有字段匹配 | ✅ 生效 | 记录验证通过 |
+| entityVersionId 不匹配 | ❌ 未生效 | 检查入库 job 是否成功、predecessor 是否正确 |
+| generationRole 不是 `current` 或 `inherited` | ❌ 异常 | 检查是否有版本冲突 |
+
+---
+
+## §2 历史 AC 保留验证
+
+### 场景
+
+入库后验证未修改的历史 AC 是否仍然出现在父 STMT 的 ontology-view 中。
+
+### API
+
+```
+GET {base}/entities/{stmtEntityId}/ontology-view
+```
+
+### 示例
+
+验证 STMT-USER-LOGIN-001 的 AC 列表：
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/89bbf6a6-0000-0000-0000-000000000000/ontology-view"
+```
+
+### 验证步骤
+
+1. 提取 `relations` 中 `relationType=verifiedBy && direction=outbound` 的邻居列表
+2. 按来源分类：
+   - `changeId = 旧变更` → 历史 AC（应保留）
+   - `changeId = 当前变更` → 新增/修改 AC
+3. 确认历史 AC 数量 ≥ 入库前数量
+4. 确认新增 AC 已出现
+
+### 验证清单
+
+| 检查项 | 期望 | 机制 |
+|--------|------|------|
+| 历史 AC 仍在列表中 | ✅ 保留 | AC 未被修改 → v1 仍 current → 关系保留 |
+| 新增 AC 已出现 | ✅ 加入 | 新 AC 入库 → statement_id 指向 STMT → inferred 关系生成 |
+| 历史 AC 版本未变 | v1, added, predecessor=null | lineage 确认只有 1 个版本 |
+| AC 的 changeId 正确 | 旧 AC = 旧变更 / 新 AC = 新变更 | 来源可追溯 |
+
+### 决策逻辑
+
+| 检查结果 | 状态 | 动作 |
+|----------|------|------|
+| 历史 AC 全部保留 + 新 AC 已加入 | ✅ 正常 | 验证通过 |
+| 历史 AC 丢失 | ❌ 异常 | 检查 archive package 是否误标 modified/removed |
+| 新 AC 未出现 | ❌ 异常 | 检查 AC 的 statement_id 是否正确指向 STMT |
+
+---
+
+## §3 关系完整性验证
+
+### 场景
+
+入库后验证关键关系（contains / verifiedBy / realizes / covers）是否正确建立。
+
+### API
+
+```
+GET {base}/entities/{entityId}/ontology-view
+```
+
+### 验证矩阵
+
+对以下实体类型分别检查：
+
+| 实体类型 | 检查关系 | direction | 期望邻居 |
+|----------|----------|-----------|----------|
+| Change | `contains` | outbound | 下属 Capability |
+| Capability | `contains` | outbound | 下属 STMT |
+| Capability | `contains` | inbound | 所属 Change |
+| STMT | `verifiedBy` | outbound | 下属 AC |
+| DES | `realizes` | outbound | 上游 STMT |
+| TASK | `covers` / `implements` | outbound | 上游 STMT / DES |
+| STMT | `sourcedFrom` | outbound | DocumentSection |
+| Entity | `declares` | inbound | Artifact |
+
+### 示例
+
+```bash
+# 验证 CAP-USER-LOGIN 的 contains 关系
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/ontology-view" | \
+  jq '.data.relations[] | select(.relationType=="contains")'
+```
+
+### 决策逻辑
+
+| 检查结果 | 状态 | 动作 |
+|----------|------|------|
+| 所有关键关系存在 | ✅ 完整 | 验证通过 |
+| 缺少 contains → STMT | ❌ 断链 | 检查 spec.md 的 capability-id 引用 |
+| 缺少 verifiedBy → AC | ❌ 断链 | 检查 AC 的 statement_id 属性 |
+| 缺少 realizes → STMT | ❌ 断链 | 检查 design.md 的 realizes 引用 |
+| 缺少 covers/implements | ⚠️ 警告 | 检查 tasks.md 的 covers/implements 引用 |
+
+---
+
+## §4 版本谱系验证
+
+### 场景
+
+验证实体的版本链完整性（v1 → v2 → ... 前后衔接）。
+
+### API
+
+```
+GET {base}/entities/{entityId}/lineage
+```
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/lineage"
+```
+
+### 验证清单
+
+| 检查项 | 期望 |
+|--------|------|
+| 版本数 ≥ 2（modified 实体） | v1(added) → v2(modified) |
+| v2.predecessorVersionId == v1.entityVersionId | 链式衔接 |
+| v1.deltaState == added, v2.deltaState == modified | 状态正确 |
+| 最后一个版本 generationRole == `current` 或 `inherited` | 当前版本正确 |
+| 每个版本的 changeId 存在且不同 | 来源可追溯 |
+
+### 决策逻辑
+
+| 检查结果 | 状态 | 动作 |
+|----------|------|------|
+| 链式完整 + current 正确 | ✅ 正常 | 验证通过 |
+| predecessorVersionId 断裂 | ❌ 异常 | 检查 archive 的 predecessor-version 声明 |
+| 最后版本非 changed | ❌ 异常 | 检查是否有后续入库覆盖 |
+
+---
+
+## §5 版本冲突检测
+
+### 场景
+
+入库时如果 predecessorVersionId 与 KB 当前版本不匹配，会标记为 conflicting。
+
+### 检查方式
+
+入库 job 响应中检查：
+
+| 字段 | 正常 | 冲突 |
+|------|------|------|
+| `errorCode` | 无 | `VERSION_CONFLICT` / `EXTERNAL_REF_CONFLICT` / `EXTERNAL_REFERENCE_FORMAT_INVALID` / `SCOPE_MISMATCH` / `FEATURE_UNBOUND` |
+| job status | `succeeded` | `failed`（整包回滚） |
+
+### 冲突处理
+
+| 冲突类型 | 原因 | 修正方式 |
+|----------|------|----------|
+| `VERSION_CONFLICT` | predecessor 不匹配当前 version | 回 spec 获取正确 predecessor，重新 archive |
+| `EXTERNAL_REF_CONFLICT` | 同 external key 绑定不同 entity_id | 回 propose/spec 确认身份决议 |
+| `EXTERNAL_REFERENCE_FORMAT_INVALID` | 编号归一化后不合文法（含 requirement.`feature_id`） | 回需求管理系统换发合规编号，禁止手改硬闯 |
+| `EXTERNAL_REFERENCE_SCOPE_MISMATCH` | 场景键 REQ 前缀不在同包 requirement 集合 | 回 spec 修正 external-ref 中 SCN 的 REQ 前缀 |
+| `EXTERNAL_REFERENCE_FEATURE_UNBOUND` | feature 绑定与 requirement.`feature_id` 无法配对 | 回 propose/archive 修正线缆字段，确认 FEAT 号存在 |
+
+> **禁止**在 KB 内现场改绑或解绑。必须回 SDD 流程修正后重新入库。

package/templates/skills/kld-sdd/opsx-ontology-query/phase-4-explore.md

@@ -0,0 +1,240 @@
+# Phase 4 · 跨迭代探索（Cross-iteration Exploration）
+
+> **触发时机**：开发者手动查询 / Agent 按需加载
+> **加载方式**：任意阶段可 `Read` 本文件
+> **前置条件**：`.local/state.json` 已完成 Session 启动
+
+---
+
+## §1 版本谱系追踪（Lineage）
+
+### 场景
+
+查看某实体的完整变更历史，理解它经历了哪些变更、每次变更改了什么。
+
+### API
+
+```
+GET {base}/entities/{entityId}/lineage
+```
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/lineage"
+```
+
+### 响应解读
+
+返回按时间排序的版本数组，每版包含：
+
+| 字段 | 含义 |
+|------|------|
+| `entityVersionId` | 该版本的 UUID |
+| `predecessorVersionId` | 前序版本 UUID（v1 为 null） |
+| `deltaState` | added / modified / removed |
+| `changeId` | 来源变更 ID |
+| `attributes` | 该版本的属性快照 |
+| `source` | 来源文件（file / line / change_id / archive_id） |
+| `createdAt` | 入库时间 |
+
+### 使用场景
+
+- **变更审计**：追溯某需求从创建到当前的完整路径
+- **回溯根因**：理解某属性何时被修改、由哪次变更引入
+- **差异对比**：对比 v1 和 v2 的 attributes 变化
+
+---
+
+## §2 语义检索（Semantic Search）
+
+### 场景
+
+用自然语言查找相关工程事实，不依赖精确锚点。
+
+### API
+
+```
+POST {base}/context/search
+```
+
+### 请求
+
+```json
+{
+  "query": "用户登录认证流程",
+  "entityTypes": [],
+  "limit": 15
+}
+```
+
+### 检索通道
+
+| 通道 | 说明 | matchType |
+|------|------|-----------|
+| 精确 | 锚点 / canonicalKey 完全匹配 | `exact` |
+| 结构 | entityType + 属性结构匹配 | `structural` |
+| 全文 | PostgreSQL FTS 关键词匹配 | `fulltext` |
+| 向量 | pgvector 语义相似 | `vector` |
+| 图谱 | AGE 关系扩展邻居 | `graph` |
+
+### 响应解读
+
+```json
+{
+  "degraded": false,
+  "degradationReasons": [],
+  "results": [
+    {
+      "matchType": "exact",
+      "entityId": "e89287e8-0000-0000-0000-000000000000",
+      "entityType": "Capability",
+      "displayName": "user-login",
+      "anchorId": "CAP-USER-LOGIN",
+      "scoreExplanation": {
+        "method": "rrf",
+        "ranks_by_channel": { "exact": 1, "fulltext": 1, "vector": 19 }
+      }
+    }
+  ]
+}
+```
+
+### 降级处理
+
+| `degraded` | `degradationReasons` | 影响 |
+|------------|----------------------|------|
+| `false` | `[]` | 全通道可用 |
+| `true` | `["vector_unavailable"]` | 向量通道缺失，精确/全文仍可用 |
+| `true` | `["age_unavailable"]` | 图谱扩展缺失 |
+
+> 降级不阻塞查询，精确/结构/全文通道始终可用。
+
+---
+
+## §3 原文溯源（Disclosure）
+
+### 场景
+
+从实体回到源文档，查看该实体在 spec.md / design.md / tasks.md 中的原文上下文。
+
+### API
+
+```
+POST {base}/context/disclosures
+```
+
+### 请求
+
+```json
+{
+  "anchorId": "STMT-USER-LOGIN-001",
+  "sourceLevel": "preview"
+}
+```
+
+### sourceLevel 选项
+
+| sourceLevel | 返回内容 | 适用场景 |
+|-------|----------|----------|
+| `preview` | 锚点附近几行 | 快速确认实体内容 |
+| `section` | 包含子节的完整章节 | 理解实体及其下属 AC/CON |
+| `document` | 整个源文档 | 全面上下文 |
+
+### 使用场景
+
+- **代码审查**：查看 STMT 的原始规格定义
+- **需求对齐**：对比 AC 场景与实际实现行为
+- **文档生成**：提取原文片段生成技术文档
+
+---
+
+## §4 知识图谱导航（Ontology View）
+
+### 场景
+
+浏览某实体的一跳关系结构，理解其在本体中的位置。
+
+### API
+
+```
+GET {base}/entities/{entityId}/ontology-view
+```
+
+### 响应结构
+
+```json
+{
+  "focus": { "entityId": "...", "canonicalKey": "CAP-USER-LOGIN", ... },
+  "attributes": [ { "key": "description", "value": "..." } ],
+  "businessStructure": {
+    "changes": [...],
+    "capabilities": [...],
+    "statements": [...],
+    "tasks": [...],
+    "designElements": [...],
+    "acceptanceCriteria": [...]
+  },
+  "relations": [
+    { "relationType": "contains", "direction": "outbound", "neighbor": {...} },
+    { "relationType": "verifiedBy", "direction": "outbound", "neighbor": {...} }
+  ],
+  "evidence": {
+    "artifacts": [...],
+    "documentSections": [...],
+    "source": { "file": "proposal.md", "line": 66 }
+  }
+}
+```
+
+### 使用场景
+
+- **影响评估**：从 Capability 出发看下游 STMT → AC → DES → TASK
+- **覆盖分析**：从 STMT 出发看 verifiedBy → AC 列表
+- **溯源链**：从任意实体出发看 sourcedFrom → DocumentSection → Artifact
+
+---
+
+## §5 多跳影响分析（Impact）
+
+### 场景
+
+评估变更的级联影响，超出直接关联。
+
+### API
+
+```
+GET {base}/entities/{entityId}/impact
+```
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/impact"
+```
+
+### 响应解读
+
+```json
+{
+  "anchorEntityId": "e89287e8-0000-0000-0000-000000000000",
+  "maxDepth": 4,
+  "nodes": [
+    { "entityId": "...", "entityVersionId": "...", "entityType": "Capability", "displayName": "user-login", "depth": 0 },
+    { "entityId": "...", "entityVersionId": "...", "entityType": "SpecificationStatement", "displayName": "用户登录认证", "depth": 1 },
+    { "entityId": "...", "entityVersionId": "...", "entityType": "AcceptanceCriterion", "displayName": "正确凭证登录成功", "depth": 2 }
+  ],
+  "edges": [
+    { "relationType": "contains", "fromEntityId": "cap-id", "toEntityId": "stmt-id", "assertionType": "asserted" },
+    { "relationType": "verifiedBy", "fromEntityId": "stmt-id", "toEntityId": "ac-id", "assertionType": "inferred" }
+  ]
+}
+```
+
+### 使用场景
+
+- **变更前评估**：修改某 Capability 会波及哪些下游
+- **回归测试范围**：确定受影响的 AC 需要回归验证
+- **架构决策**：理解实体间的依赖深度

package/templates/skills/kld-sdd/opsx-ontology-query/phase-5-governance.md

@@ -0,0 +1,232 @@
+# Phase 5 · 治理与监控（Governance & Monitoring）
+
+> **触发时机**：治理流程 / 定期巡检 / opsx-check 深度验证
+> **加载方式**：治理角色按需 `Read` 本文件
+> **前置条件**：`.local/state.json` 已完成 Session 启动
+>
+> ✅ conformance / drift API **已实现**，但需要先通过 `POST /evidence-ingestions` 入库代码证据后才有数据。
+> 无 evidence 时返回 `{"integrationStatus":"not_integrated","reports":[]}`，Agent 遇到此状态应提示用户"需先入库 evidence"，不当作错误。
+
+---
+
+## §1 覆盖率仪表盘（Coverage Dashboard）
+
+### 场景
+
+全局监控规格覆盖完整性，按 gapType 分类统计缺失项。
+
+### API
+
+```
+GET {base}/coverage
+```
+
+> KB 级别 API，路径含 kbId。
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/coverage"
+```
+
+### 响应解读
+
+```json
+{
+  "gaps": [
+    {
+      "entityId": "xxx-0000-0000-0000-000000000000",
+      "entityType": "SpecificationStatement",
+      "displayName": "某规格声明",
+      "gapType": "missing_acceptance_criterion"
+    }
+  ]
+}
+```
+
+### 统计维度
+
+| gapType | 实体类型 | 含义 | 建议 |
+|---------|----------|------|------|
+| `missing_acceptance_criterion` | STMT | 无验收场景 | 补充 AC |
+| `missing_specification_statement` | DES | 无规格依据 | 补充 realizes 或创建 STMT |
+| `missing_upstream_trace` | TASK | 无上游追溯 | 补充 covers/implements |
+
+### 使用场景
+
+- **定期巡检**：每周/每迭代检查全局覆盖率
+- **质量门禁**：归档前覆盖率必须达标
+- **技术债识别**：长期 missing 的实体标记为技术债
+
+> **Agent 行为指导**：遇到 `integrationStatus: "not_integrated"` 时，提示用户"需先通过 `POST /evidence-ingestions` 入库代码证据"，不当作"无数据"或错误处理。
+
+---
+
+## §2 一致性检查（Conformance）
+
+### 场景
+
+验证代码实现与规格定义的一致性，对比 KB 规格事实与实现证据。
+
+### API
+
+```
+GET {base}/conformance
+```
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/conformance"
+```
+
+### 检查维度
+
+| 维度 | 含义 | 数据源 |
+|------|------|--------|
+| 规格断言 vs 代码实现 | STMT/AC 是否在代码中实现 | semantic facts vs implementation_evidence |
+| 规格覆盖 vs 实际行为 | AC 场景是否被测试覆盖 | AC vs test evidence |
+
+### 使用场景
+
+- **发布前验证**：确认实现与规格一致
+- **回归检测**：代码变更后检查是否仍符合规格
+- **审计报告**：生成一致性报告供评审
+
+---
+
+## §3 漂移检测（Drift）
+
+### 场景
+
+检测实现偏离规格的程度，识别"规格说 A 但代码做 B"的情况。
+
+### API
+
+```
+GET {base}/drift
+```
+
+### 示例
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/drift"
+```
+
+### 漂移类型
+
+| 类型 | 含义 | 严重度 |
+|------|------|--------|
+| 规格未实现 | STMT/AC 无对应代码 | 高 |
+| 实现无规格 | 代码无对应 STMT/AC | 中 |
+| 行为不一致 | 代码行为与 AC 描述不符 | 高 |
+| 规格过期 | 代码已变更但规格未更新 | 中 |
+
+### 使用场景
+
+- **迭代回顾**：识别本迭代引入的漂移
+- **技术债管理**：长期漂移项纳入技术债看板
+- **重构决策**：高漂移区域优先重构
+
+> **Agent 行为指导**：同 §2，遇到 `integrationStatus: "not_integrated"` 时提示用户需先入库 evidence。
+
+---
+
+## §4 关系候选审批（Relation Candidate Review）
+
+### 场景
+
+`suggested` 关系（AI 推荐但未确认）需要人工审批后才能进入正式本体。
+
+### API
+
+```
+GET  {base}/relation-candidates
+POST {base}/relation-candidates/{candidateId}/review
+```
+
+> 审批通过/拒绝都走同一个 `/review` 端点，用 body 中的 `decision` 区分。
+
+### 示例
+
+```bash
+# 列出待审批候选（可按 status 过滤）
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/relation-candidates?status=pending"
+
+# 审批通过
+curl -sS -X POST -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/relation-candidates/{candidateId}/review" \
+  -d '{"decision":"accept","reason":"关系正确，确认批准"}'
+
+# 拒绝
+curl -sS -X POST -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/relation-candidates/{candidateId}/review" \
+  -d '{"decision":"reject","reason":"证据不足"}'
+```
+
+### 候选字段
+
+| 字段 | 含义 |
+|------|------|
+| `candidateId` | 候选 UUID |
+| `relationType` | 推荐的关系类型 |
+| `fromEntityId` / `fromName` | 源实体 |
+| `toEntityId` / `toName` | 目标实体 |
+| `confidence` | 置信度（0-1） |
+| `supportEvidence` / `oppositionEvidence` | 支持/反对证据 |
+| `status` | pending / accepted / rejected |
+
+### 审批请求
+
+```json
+{ "decision": "accept | reject", "reason": "string" }
+```
+
+### 审批决策
+
+| confidence | support vs opposition | 建议 |
+|------------|----------------------|------|
+| > 0.8 | support >> opposition | accept |
+| 0.5-0.8 | 有争议 | 人工审查后决定 |
+| < 0.5 | opposition >> support | reject |
+
+### 使用场景
+
+- **日常治理**：定期审批待确认关系
+- **本体质量提升**：高置信度候选批量批准
+- **误报过滤**：低置信度候选拒绝并反馈
+
+---
+
+## §5 变更统计与趋势（Change Analytics）
+
+### 场景
+
+查看 KB 中所有变更的统计信息，分析迭代趋势。
+
+### API
+
+```
+GET {base}/changes
+GET {base}/changes/{changeId}
+```
+
+### 分析维度
+
+| 维度 | 指标 | 用途 |
+|------|------|------|
+| 变更频率 | 每迭代变更数 | 评估迭代节奏 |
+| 变更类型分布 | added / modified / removed 比例 | 评估系统成熟度 |
+| 实体增长率 | 每迭代新增实体数 | 评估规格膨胀 |
+| 覆盖率趋势 | 各 gapType 随时间变化 | 评估质量改进 |
+| 冲突频率 | VERSION_CONFLICT / EXTERNAL_REF_CONFLICT / EXTERNAL_REFERENCE_FORMAT_INVALID / SCOPE_MISMATCH / FEATURE_UNBOUND 次数 | 评估 Continuity 与编号体系流程成熟度 |
+
+### 使用场景
+
+- **迭代报告**：每迭代生成本体变更统计
+- **成熟度评估**：评估团队的 SDD 流程成熟度
+- **容量规划**：预测 KB 增长趋势