kld-sdd 2.6.7 → 2.6.9

package/templates/skills/kld-sdd/opsx-ontology-query/phase-1-prechange.md

@@ -0,0 +1,276 @@
+# Phase 1 · 变更前评估（Pre-change Assessment）
+
+> **触发时机**：opsx-propose 创建变更前 / opsx-spec 生成规格前
+> **加载方式**：SDD skill 在对应阶段 `Read` 本文件
+> **前置条件**：`.local/state.json` 已完成 Session 启动（apiKey + targets 就绪）
+>
+> ⚠️ **数据边界**：当前变更尚未入库，KB 中只有历史变更数据。
+> 本阶段 KB 查询的目的：**用历史上下文辅助当前变更的决策**（身份决议、影响预评、历史 AC 查询、Spec 复用）。
+> KB 返回的是上一次入库的状态，不是当前变更的状态。
+
+---
+
+## §1 需求连续性检查（Continuity）
+
+> **已有集成**：opsx-propose §6.5 已调用。此处为完整参考。
+
+### 场景
+
+判断新需求是全新需求还是历史需求的延续，确定是否可继承历史 UUID。
+
+### API
+
+```
+POST {base}/entities/resolve
+```
+
+### 请求
+
+```json
+{
+  "externalSystem": "requirement-mgmt",
+  "externalObjectType": "requirement",
+  "externalId": "REQ-FI-2024-001",
+  "entityType": "Capability"
+}
+```
+
+> **编号文法**：`externalId` 必须符合 `REQ-{DOMAIN}-{YEAR}-{SEQ}` 格式（如 `REQ-FI-2024-001`）。
+> 查询前先归一化：trim → REQ/FEAT 段大写。完整文法见 `SKILL.md` → 编号文法速查。
+
+### 决策逻辑
+
+| 响应字段 | 值 | 含义 | SDD 动作 |
+|----------|-----|------|----------|
+| `resolution` | `LINK_EXISTING` | 命中可继承绑定 | `inheritanceAllowed=true` → 复用 entity-id，写 `delta-state=modified` |
+| `removedBindingCount` | > 0 | 存在历史失效绑定 | 仅提示，不影响 inheritance 判定 |
+| `matchType` | `HISTORICAL_ONLY` | 仅有失效绑定，`inheritanceAllowed=false` | 不可继承，新开身份 |
+| `resolution` | `CREATE_NEW` | 无匹配 | 全新需求，`delta-state=added` |
+| — | `SIMILAR_REQUIREMENT` | 名称/结构相似 | 仅候选，需人确认 |
+| — | `NEEDS_CONFIRM` | 需人确认 | ask_user A/B/C |
+
+### 按功能号圈能力（FEAT scoping）
+
+同一 `/entities/resolve` 接口，`externalObjectType:"feature"` 可查询某 FEAT 下已有能力清单，辅助 propose 阶段勾选本次 CAP 范围：
+
+```json
+{
+  "externalSystem": "requirement-mgmt",
+  "externalObjectType": "feature",
+  "externalId": "FEAT-FI-012",
+  "entityType": "Capability"
+}
+```
+
+响应 `candidates` 列出存活/失效能力，`removedBindingCount` 为已失效绑定数。
+> 此查询只作范围参考，不改变 Continuity 判定优先级。
+
+### 集成点
+
+- opsx-propose §6.5：写入 proposal frontmatter `continuity` 字段
+- 禁止扫本地 `archive/` 抄 UUID（KB 可用时）；KB degraded 时 archive 作为降级手段，标注 `source: archive(degraded)`
+
+> **Agent 行为指导**：响应中的 `clarificationQuestions` 是 AI 生成的澄清问题，Agent 应直接用 `ask_user` 呈现给用户，不要自行回答。
+> `supportEvidence` / `oppositionEvidence` 可作为决策依据向用户展示。
+
+---
+
+## §2 影响范围分析（Impact Analysis）
+
+> **新增场景**：opsx-propose 在能力分解前评估修改影响。
+
+### 场景
+
+用户要修改某个 Capability 或 STMT，需知道波及哪些下游实体（AC/DES/TASK）。
+
+### API（一跳结构）
+
+```
+GET {base}/entities/{entityId}/ontology-view
+```
+
+### API（多跳影响）
+
+```
+GET {base}/entities/{entityId}/impact
+```
+
+### 示例
+
+查询 CAP-USER-LOGIN（e89287e8）的影响：
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/e89287e8-0000-0000-0000-000000000000/impact"
+```
+
+### 响应解读
+
+- `anchorEntityId`：锚点实体 ID
+- `maxDepth`：最大影响深度（≤4 跳）
+- `nodes`：受影响实体列表（含 entityId / entityType / displayName / depth）
+- `edges`：影响路径（fromEntityId → toEntityId / relationType）
+
+### 决策逻辑
+
+| 影响范围 | 风险等级 | 建议 |
+|----------|----------|------|
+| 仅 1 跳（直接子节点） | 低 | 正常进行 |
+| 2 跳（STMT → AC/DES） | 中 | 确认受影响 AC 是否需要修改 |
+| 3-4 跳（到 TASK） | 高 | 先与用户确认影响范围再继续 |
+
+### 集成点
+
+- opsx-propose §3（能力分解）：在列出 modified Capability 前，查询影响范围写入 proposal §4 影响范围
+- opsx-propose §6.5：Continuity 结果结合影响范围，判断 iteration vs new
+
+---
+
+## §3 历史覆盖场景查询（Historical AC Coverage）
+
+> **新增场景**：opsx-spec 生成规格前，查询当前 STMT 已有哪些 AC。
+
+### 场景
+
+为已有 STMT 追加新场景时，需知道历史 AC 列表，避免遗漏或重复。
+
+### API
+
+```
+GET {base}/entities/{stmtEntityId}/ontology-view
+```
+
+### 示例
+
+查询 STMT-USER-LOGIN-001（89bbf6a6）的 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"
+```
+
+### 响应解读
+
+从 `relations` 数组提取 `relationType=verifiedBy && direction=outbound` 的邻居：
+
+```json
+{
+  "relationType": "verifiedBy",
+  "direction": "outbound",
+  "neighbor": {
+    "entityId": "c9f6a0e8-0000-0000-0000-000000000000",
+    "canonicalKey": "AC-USER-LOGIN-001",
+    "displayName": "正确凭证登录成功",
+    "changeId": "CHG-ADD-USER-LOGIN"
+  }
+}
+```
+
+### 决策逻辑
+
+> ⚠️ **数据边界**：KB 中只有已入库的历史变更数据。当前变更的 AC 尚未入库，不会出现在查询结果中。以下决策基于"KB 返回的全部是历史 AC"这一前提。
+
+| 发现 | 含义 | SDD 动作 |
+|------|------|----------|
+| AC 来自旧变更（changeId ≠ 当前） | 历史保留场景 | 新场景编号从 `max+1` 开始，不重复；SCN 格式 `:SCN-{slug}-{NNN}`（见 `SKILL.md` → 编号文法速查） |
+| 无 AC | 全新 STMT 或历史无场景 | 正常创建首个 AC |
+| AC 的 statement_id 指向当前 STMT | 关系正确 | 确认新 AC 也写 statement_id |
+| STMT 在 KB 中不存在 | 全新 STMT（added） | 无历史 AC 可查，直接创建 |
+
+### 关键机制
+
+- `verifiedBy` 是 inferred 关系（rule_id=nested-acceptance-scenario），由 AC 的 `statement_id` 属性推导
+- 历史 AC 未被修改时，其 v1 仍是 current，关系自动保留
+- ontology-view 只显示每个实体的 current version
+
+### 集成点
+
+- opsx-spec §3：在 match-requirement 之后，对 modified STMT 查询历史 AC
+- opsx-spec §6：生成新 AC 时确认编号不与历史冲突
+
+---
+
+## §4 Spec 复用评估（Spec Reuse）
+
+> **已有集成**：opsx-spec §3 已调用。此处为完整参考。
+
+### 场景
+
+查找是否有可复用的历史规格（statements / ACs / constraints / designElements / tasks）。
+
+### API
+
+```
+POST {base}/context/match-requirement
+```
+
+### 请求
+
+```json
+{
+  "query": "用户登录认证",
+  "targetStage": "spec",
+  "entityId": "e89287e8-0000-0000-0000-000000000000",
+  "externalSystem": "requirement-mgmt",
+  "externalObjectType": "requirement",
+  "externalId": "REQ-FI-2024-001"
+}
+```
+
+### 决策逻辑
+
+| `reuseMode` | 含义 | SDD 动作 |
+|-------------|------|----------|
+| `INHERIT` | 确定性命中，可继承 UUID | unchanged 写继承引用；modified 复用 entity-id + predecessor |
+| `REFERENCE` | 仅候选，不能自动复用 | 只参考内容，新开身份 |
+| — | 无命中 | 全新建 |
+
+### 响应消费
+
+- `reuseBundles[].statements` → 优先消费，写入 spec 的 STMT
+- `reuseBundles[].acceptanceCriteria` → 参考场景定义
+- `reuseBundles[].designElements` → 仅理解上下文，不能写成 Spec 的 How
+- 实体上的 `externalRefs` → 写入场景 `external-ref`
+
+### 集成点
+
+- opsx-spec §3：Continuity=iteration 时必须带 `entityId` + external
+- 禁止从本地 `archive/` 抄 UUID 当跨迭代继承源（KB 可用时）；KB degraded 时 archive 作为降级手段，标注 `source: archive(degraded)`
+
+> **Agent 行为指导**：消费 `specGenerationContext` 判断复用率——`reusableStatements` > 50% 走迭代修改，< 20% 走全新建。
+> `warnings` 和 `clarificationQuestions` 应呈现给用户，不要忽略。
+
+---
+
+## §5 约束冲突检测（Constraint Conflict）
+
+> **新增场景**：opsx-spec 新增 Constraint 时检查冲突。
+
+### 场景
+
+新增约束时，检查 KB 中是否已有语义矛盾的约束。
+
+### API
+
+```
+POST {base}/context/search
+```
+
+### 请求
+
+```json
+{
+  "query": "密码最小长度限制",
+  "entityTypes": ["Constraint"],
+  "limit": 10
+}
+```
+
+### 决策逻辑
+
+- 返回结果中若存在与新增约束语义矛盾的 Constraint → 标记 warning，提示用户确认
+- 无冲突或无命中 → 正常创建
+
+### 集成点
+
+- opsx-spec §6：创建 CON-* 前可选调用

package/templates/skills/kld-sdd/opsx-ontology-query/phase-2-during.md

@@ -0,0 +1,354 @@
+# Phase 2 · 变更中辅助（During-change Assistance）
+
+> **触发时机**：opsx-design / opsx-task / opsx-check 阶段
+> **加载方式**：SDD skill 在对应阶段 `Read` 本文件
+> **前置条件**：`.local/state.json` 已完成 Session 启动
+>
+> ⚠️ **数据边界**：当前变更尚未入库（Archive → kb-ingest 之前），KB 中只有历史变更数据。
+> 本阶段所有 KB 查询都是查**历史上下文**，用于辅助决策，不能用于验证当前变更的内部一致性。
+> 当前变更的内部一致性由**本地文件 + semantic-check** 保证。
+
+---
+
+## §1 历史设计参考（Historical Design Reference）
+
+> **新增场景**：opsx-design 创建 DES 前，查询历史设计作为参考。
+
+### 场景
+
+设计阶段，为当前变更的 DesignElement 查找历史设计模式、已有实现关系，辅助新设计决策。
+
+> ⚠️ **不能用于验证当前变更的 DES**：当前变更的 DES 尚未入库，`ontology-view` 只返回历史版本。
+> - 如果 DES 是 `added`（新增）→ KB 中不存在此实体
+> - 如果 DES 是 `modified`（修改）→ KB 返回的是**旧版本**的 realizes 关系，不是当前变更的
+> - 当前变更的 DES realizes 关系应从**本地 design.md** 验证
+
+### API（查询历史 DES 的关系结构）
+
+```
+GET {base}/entities/{historicalDesEntityId}/ontology-view
+```
+
+### 示例
+
+查询历史 DES-USER-LOGIN-001（a5e8b950）的一跳结构作为参考：
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/a5e8b950-0000-0000-0000-000000000000/ontology-view"
+```
+
+### 响应解读
+
+从 `relations` 检查 `relationType=realizes && direction=outbound`：
+
+```json
+{
+  "relationType": "realizes",
+  "direction": "outbound",
+  "neighbor": {
+    "canonicalKey": "STMT-USER-LOGIN-001",
+    "entityId": "89bbf6a6-0000-0000-0000-000000000000"
+  }
+}
+```
+
+### 决策逻辑
+
+| 查询目的 | KB 返回 | SDD 动作 |
+|----------|---------|----------|
+| 了解历史 DES realizes 哪个 STMT | 历史版本关系 | 参考历史模式，新 DES 的 realizes 引用对齐 |
+| 查找类似设计 | context/search DesignElement | 仅参考，不能直接复用 UUID（除非 INHERIT） |
+| 确认上游 STMT 是否存在 | STMT 在 KB 中为 current | 确认 STMT entity-id 可继承 |
+
+### 设计复用检索
+
+用语义搜索查找历史类似设计：
+
+```json
+{
+  "query": "用户凭证存储与密码验证",
+  "entityTypes": ["DesignElement"],
+  "limit": 10
+}
+```
+
+返回的历史 DesignElement 仅作参考，不可直接复用 UUID（除非 INHERIT）。
+
+### 集成点
+
+- opsx-design §5：代码锚点分析后，查 KB 了解历史设计模式
+- opsx-design §6：创建 DES 时参考历史 realizes 引用格式
+- ⚠️ 当前变更 DES 的 realizes 验证 → 走本地 design.md + semantic-check
+
+---
+
+## §2 历史任务追溯参考（Historical Task Traceability）
+
+> **新增场景**：opsx-task 创建 TASK 前，查询历史任务关系作为参考。
+
+### 场景
+
+任务拆解时，查询历史 TASK 的关系结构（covers/implements/verifies），辅助新任务的追溯设计。
+
+> ⚠️ **不能用于验证当前变更的 TASK**：当前变更的 TASK 尚未入库。
+> - 如果 TASK 是 `added` → KB 中不存在
+> - 如果 TASK 是 `modified` → KB 返回旧版本关系
+> - 当前变更 TASK 的 covers/implements 应从**本地 tasks.md** 验证
+
+### API（查询历史 TASK 的关系结构）
+
+```
+GET {base}/entities/{historicalTaskEntityId}/ontology-view
+```
+
+### 示例
+
+查询历史 TASK-USER-LOGIN-003（f5446144）的一跳结构作为参考：
+
+```bash
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/f5446144-0000-0000-0000-000000000000/ontology-view"
+```
+
+### 响应解读
+
+检查 `relations` 中的关系类型：
+
+| relationType | direction | 含义 |
+|--------------|-----------|------|
+| `implements` | outbound → DES | 历史任务实现了某设计元素 |
+| `covers` | outbound → STMT | 历史任务覆盖了某规格声明 |
+| `verifies` | outbound → AC | 历史任务验证了某验收场景 |
+| `dependsOn` | outbound → TASK | 历史任务依赖另一任务 |
+
+### 决策逻辑
+
+| 查询目的 | KB 返回 | SDD 动作 |
+|----------|---------|----------|
+| 了解历史 TASK 的追溯模式 | 历史版本关系 | 参考模式设计新 TASK 的 covers/implements |
+| 确认上游 STMT/DES 是否存在 | 实体在 KB 中为 current | 确认 entity-id 可继承 |
+| 检查历史 TASK 依赖链 | dependsOn 关系 | 参考依赖模式，避免循环 |
+
+### 集成点
+
+- opsx-task §7：创建 TASK 后参考历史追溯模式
+- opsx-task §8：质量自检时参考历史关系格式
+- ⚠️ 当前变更 TASK 的 covers/implements 验证 → 走本地 tasks.md + semantic-check
+
+---
+
+## §3 历史覆盖率基线（Historical Coverage Baseline）
+
+> **新增场景**：opsx-check 阶段，查 KB 覆盖率了解**入库前**的基线状态。
+
+### 场景
+
+检查 KB 中已入库规格的覆盖完整性，识别**历史遗留**的覆盖率缺口。
+
+> ⚠️ **数据边界**：KB coverage 只反映**已入库变更**的覆盖率，不含当前变更。
+> - 当前变更的覆盖率由**本地 semantic-check** 负责（主权威）
+> - KB coverage 的价值在于：发现历史遗留缺口，判断当前变更是否应该顺手修复
+> - 如果当前变更修改了某个有缺口的 STMT，可以顺手补 AC
+
+### API
+
+```
+GET {base}/coverage
+```
+
+> 注：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 分类
+
+| gapType | entityType | 含义 | 严重度 |
+|---------|------------|------|--------|
+| `missing_acceptance_criterion` | SpecificationStatement | STMT 缺少 AC | ❌ 阻断 |
+| `missing_specification_statement` | DesignElement | DES 缺少 realizes | ❌ 阻断 |
+| `missing_upstream_trace` | Task | TASK 缺少 covers/implements | ⚠️ 警告 |
+
+### 决策逻辑
+
+| 检查结果 | 含义 | SDD 动作 |
+|----------|------|----------|
+| gaps 为空 | 历史全覆盖 | 当前变更只需保证自身覆盖率（本地 semantic-check） |
+| 有 gap 且 gap 实体在当前变更范围内 | 历史遗留 + 当前变更涉及 | 顺手修复：在当前变更中补 AC/realizes |
+| 有 gap 但 gap 实体不在当前变更范围 | 纯历史遗留 | 记录为技术债，不阻塞当前变更 |
+| 当前变更自身覆盖率 | **不查 KB** | 走本地 semantic-check（主权威） |
+
+### 集成点
+
+- opsx-check §4：KB 覆盖率作为**历史基线**参考，不作为当前变更的覆盖率权威
+- opsx-check §4.2：本地 semantic-check 是当前变更覆盖率的主权威
+- 禁止用 KB coverage 的 gap 来阻断当前变更（除非 gap 实体在变更范围内）
+
+---
+
+## §4 历史变更统计（Historical Change Inventory）
+
+> **新增场景**：opsx-check / opsx-explore 查询 KB 中的**历史**变更统计。
+
+### 场景
+
+查看 KB 中已入库的变更列表和统计，了解迭代历史和变更模式。
+
+> ⚠️ **数据边界**：KB changes 只含**已入库**的变更。当前变更不在列表中（直到 Archive → kb-ingest）。
+> - 查历史变更趋势 → KB changes ✅
+> - 查当前变更状态 → 本地 `openspec/changes/{change-id}/` ✅
+
+### API
+
+```
+GET {base}/changes
+GET {base}/changes/{changeId}
+```
+
+### 示例
+
+```bash
+# 列出所有已入库变更
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/changes"
+
+# 查看特定历史变更详情
+curl -sS -H "Authorization: Bearer $API_KEY" \
+  "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/changes/CHG-ADD-USER-LOGIN"
+```
+
+### 响应解读
+
+变更列表（`GET /changes`）每项字段（camelCase）：
+
+```json
+{
+  "changeId": "CHG-ADD-USER-LOGIN",
+  "title": "CHG-ADD-USER-LOGIN",
+  "status": "confirmed",
+  "createdAt": "2026-07-23T06:09:46.219924Z",
+  "updatedAt": "2026-07-23T06:09:46.219924Z",
+  "archiveId": "urn:kld:sdd:archive:...",
+  "producer": "kld-sdd@1.0.0",
+  "schemaVersion": "kld-sdd-canonical-facts/v2",
+  "contentHash": "sha256:...",
+  "versionCount": 85,
+  "addedCount": 85,
+  "modifiedCount": 0,
+  "removedCount": 0,
+  "unchangedCount": 0
+}
+```
+
+> 注：`title` 当前等于 `changeId`，非人类可读标题。
+
+变更详情（`GET /changes/{changeId}`）为嵌套结构：
+
+```json
+{
+  "metadata": {
+    "change_id": "CHG-ADD-USER-LOGIN",
+    "title": "CHG-ADD-USER-LOGIN",
+    "status": "confirmed",
+    "updated_at": "2026-07-23T06:09:46.219924Z",
+    "snapshot_id": "uuid",
+    "archive_id": "urn:kld:sdd:archive:...",
+    "producer": "kld-sdd@1.0.0",
+    "schema_version": "kld-sdd-canonical-facts/v2",
+    "content_hash": "sha256:...",
+    "archive_created_at": "2026-07-23T06:09:31.919Z"
+  },
+  "entityVersions": [
+    { "entityId": "...", "entityType": "Capability", "deltaState": "added", "..." : "..." }
+  ]
+}
+```
+
+> ⚠️ `metadata` 内字段为 snake_case，`entityVersions` 内为 camelCase（Java record 序列化）。
+```
+
+### 决策逻辑
+
+| 查询目的 | KB 返回 | SDD 动作 |
+|----------|---------|----------|
+| 了解历史变更频率和类型分布 | 已入库变更列表 | 评估迭代节奏 |
+| 确认上次入库的变更 ID | 最近一次 confirmed 变更 | 作为 predecessor 参考上下文 |
+| 查当前变更状态 | **不查 KB** | 看本地 `openspec/changes/{change-id}/` |
+
+### 集成点
+
+- opsx-check：参考历史变更统计，不作为当前变更的权威
+- opsx-explore：展示 KB 中的历史变更概览
+
+---
+
+## §5 入库前一致性预检（Pre-archive Consistency Check）
+
+> **新增场景**：opsx-check / opsx-archive 在打包归档前，验证 predecessor version 是否与 KB 当前版本匹配。
+
+### 场景
+
+Archive 打包前，对每个 `modified` 实体验证：本地声明的 `predecessor-version-id` 是否等于 KB 中该实体的 `current-version`。如果不匹配，入库时会触发 `VERSION_CONFLICT`，整包回滚。
+
+> 这是**预防性检查**，在入库前发现问题，避免入库后失败再返工。
+
+### 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"
+```
+
+### 验证步骤
+
+1. 从本地 proposal.md / spec.md 中提取每个 modified 实体的 `entity-id` 和 `predecessor-version-id`
+2. 对每个 modified 实体调用 `current-version` API
+3. 对比：
+
+| 本地声明 | KB 返回 | 结果 |
+|----------|---------|------|
+| `predecessor-version-id` == KB `entityVersionId` | ✅ 一致 | 可安全入库 |
+| `predecessor-version-id` ≠ KB `entityVersionId` | ❌ 不一致 | 有其他变更已入库，需更新 predecessor |
+| KB 中无此实体（404） | entity 是 added | 确认 delta-state=added，无需 predecessor |
+
+### 决策逻辑
+
+| 检查结果 | 状态 | 动作 |
+|----------|------|------|
+| 所有 modified 实体的 predecessor 匹配 | ✅ 可入库 | 继续 Archive → kb-ingest |
+| 某 modified 实体 predecessor 不匹配 | ❌ 冲突 | 回 spec 获取 KB 最新 version-id，更新 predecessor，重新打包 |
+| 某 modified 实体在 KB 中不存在 | ⚠️ 异常 | 检查 delta-state 应为 added 而非 modified |
+
+### 集成点
+
+- opsx-check §4：一致性检查中加入 KB predecessor 预检
+- opsx-archive §4：打包前自动预检，失败则阻断打包
+- opsx-archive §5.5：入库后用 Phase 3 验证（双重保障）