kld-sdd 2.6.21 → 2.7.8

package/templates/skills/kld-sdd/opsx-kb-ingest/SKILL.md

@@ -7,6 +7,8 @@ description: >-
   Use when ingesting new or updated knowledge archives into the ontology KB.
 ---
 
+> **执行方式**：先读 [交互与执行契约](../opsx-propose/interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 # 本体知识库 · 入库
 
 只负责**入库**（zip 上传 + 文件夹上传）。鉴权只用 **API Key**（`Authorization: Bearer sk_sdd_…`），**禁止**走手机号登录。
@@ -182,82 +184,18 @@ node skywalk-sdd/kb-sync-identity.cjs \
   --skip-kb-verify
 ```
 
-脚本自动完成：
-- **Phase 0**: 读取 KB 配置（kb-state.json + project-identity.json）→ KB API 健康检查 → KB resolve 验证实体当前 version-id
-- **结构实体同步**: 扫描 `ontology-identities.json` 中结构实体（Artifact + DocumentSection）的 content_hash 变化，为变更实体生成新 version-id（predecessor=KB验证的 version-id）
-- **业务实体同步**: 基于结构实体同步的 DocumentSection 变化结果，只为 content_hash 真正变化的业务实体生成新 version-id 并更新 markdown 身份块。未变化的 `added` 实体保持原样，不会被无端 version-bump
-- **同步报告**: 输出哪些实体被同步、哪些跳过、predecessor 来源（local/KB）
-
-> **✅ 内容驱动安全保证**：默认模式下，脚本通过 Part 1 的 DocumentSection content_hash 比较结果驱动 Part 2 的业务实体筛选。只有 `delta-state=added` **且** 对应 DocumentSection content_hash 真正变化的实体才会被转为 `modified`。未变化的 `added` 实体保持原样，不会造成版本污染。
->
-> **⚠️ 精准模式** (`--anchors`): 当用户明确知道改了哪些实体时使用。脚本信任用户指定，即使 Part 1 未检测到 content_hash 变化也会同步（适用于身份元数据变更等非内容性修改场景）。
-
-> **Phase 0 说明**：脚本默认会查询 KB 获取实体的当前 version-id 作为 predecessor。如果本地 version-id 与 KB 不一致（如 git 恢复后），脚本会自动使用 KB 的 version-id 作为 predecessor 并输出警告。如果 KB 不可达，脚本会降级为本地模式（使用本地 version-id）并输出警告。使用 `--skip-kb-verify` 可强制跳过所有 KB 操作。
-
-> ⛔ **禁止**跳过同步直接 `kb-upload.cjs --folder`：被修改的实体 version-id 未变 + content_hash 变了 → KB 报 `VERSION_IDENTITY_CONFLICT`。
->
-> ⛔ **禁止**删除整个 `ontology/` + `artifacts/` 缓存来绕过冲突：会导致所有实体被重新计算 hash 和 version-id，造成不必要的版本扩散。应使用 `kb-sync-identity.cjs` 精准同步。
-
-**方式 B：手动同步（脚本不可用时 fallback）**
-
-1. **识别被修改的实体**——Agent 知道自己改了哪些内容。例如：修改了 AC-USER-CRUD-007 的默认分页大小，则只需处理该实体。若修改了 spec.md 的多处内容，列出所有受影响的实体 anchor（如 STMT-xxx、AC-xxx、CON-xxx）。
-
-> ⚠️ **不要忘记结构实体**：修改了 .md 文件后，该文件的 Artifact 实体（文档级）也需要同步。结构实体存储在 `ontology/ontology-identities.json` 中，需更新其 `version_id` 字段。
-
-2. **对每个被修改的实体，查 KB → 生成新 version-id → 更新身份块**
-
-2a. 查询 KB 获取该实体的当前 version-id：
-
-```bash
-# 示例：查询 AC-USER-CRUD-007（external-id 为场景键）
-node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" \
-  --mode=resolve \
-  --external-system=requirement-mgmt \
-  --external-object-type=scenario \
-  --external-id="REQ-US-2026-001:SCN-user-crud-007" \
-  --space-id="$ENGINEERING_KB_SPACE_ID" \
-  --kb-id="$ENGINEERING_KB_KB_ID"
-```
-
-KB 返回 `candidates[]`，每项含 `entityId` 和 `entityVersionId`（完整 UUID，`id.cjs` 自动归一化为 8-hex）。
+脚本先读取当前正文和身份登记，再查询目标 KB 的当前版本与内容哈希，完成全部检查后才写文件：
 
-> 没有 `external-ref` 的实体（如 STMT、CON）可用 `--entity-id=<spec.md中的entity-id>` + `--entity-type=<SpecificationStatement|Constraint>` 查询。
-
-2b. 生成新 version-id：
-
-```bash
-# AC-USER-CRUD-007，KB 返回 entityId=e248ba63, entityVersionId=be5581d9
-node "$(cat .sdd-spec-root)/skywalk-sdd/log.cjs" semantic-identity \
-  --delta-state=modified \
-  --entity-id=e248ba63 \
-  --predecessor-version=be5581d9
-# → 输出新的 version_id（如 3f8a1c2b）
-```
-
-2c. 更新 spec.md / proposal.md 中该实体的身份块：
-
-```markdown
-##### 场景：[AC-USER-CRUD-007] 默认分页查询
-- **entity-id**: e248ba63          ← 不变（复用 KB 的 entityId）
-- **version-id**: 3f8a1c2b         ← 改为步骤 2b 生成的新 version-id
-- **delta-state**: modified         ← 从 added 改为 modified
-- **predecessor-version**: be5581d9  ← 新增：KB 返回的 entityVersionId
-- **external-ref**: requirement-mgmt:scenario:REQ-US-2026-001:SCN-user-crud-007
-```
-
-3. **未修改的实体保持原样不动**——它们 version-id + content_hash 都没变 → KB 自动幂等跳过。不需要改为 `unchanged` 或 `modified`。
-
-4. **先校验再上传**：
-
-```bash
-# 先校验（含语义校验，确认 modified 实体身份块正确）
-node skywalk-sdd/kb-upload.cjs --validate-only --folder=<变更目录路径>
-
-# 校验通过后上传
-node skywalk-sdd/kb-upload.cjs --folder=<变更目录路径>
-```
+- 正文未变保留版本；正文改变且基线匹配时生成新版本；未发布草稿继续沿用自身版本。
+- 本地基线落后时报 `STALE_BASE_VERSION`，先比较、合并正文，不自动把最新 version-id 填成 predecessor。
+- `--anchors` 仅筛选业务锚点，不绕过内容哈希和基线检查；结构实体也参与核对。
+- 默认在线同步失败只终止这次同步，本地编写/检查/测试仍可继续。`--skip-kb-verify` 仅为显式本地维护模式，报告 `baselineVerified:false`，不能证明可发布。
+- `--dry-run` 不改 Markdown 和身份登记；`--validate-only` 可能刷新工作态，不能当作无写入预览。
+- 身份由工具维护，不让用户手工填写 UUID；脚本不可用时先保留正文和待同步事项，修复工具后再同步，不手动篡改版本链。
+- 已发布内容修改后，先同步所有受影响文件，再上传。禁止删除 ontology/artifacts 或重建身份以绕过冲突。
+- 完整 UUID 保留原值，旧短 ID 继续兼容；不得截断真实 UUID。
 
-> ⛔ **禁止**跳过步骤 1-3 直接 `kb-upload.cjs --folder`：被修改的实体 version-id 未变 + content_hash 变了 → KB 报 `VERSION_IDENTITY_CONFLICT`（错误消息含 anchorId / name / versionId，据此定位是哪个实体）。
+上传回执需分别检查事实保存、`publication_status` 和索引状态。HTTP 200 不是成功证明；多 KB 时明确本次 `--space-id` 与 `--kb-id`，不自动广播。
 
 **其他影响入库的因素**：
 

package/templates/skills/kld-sdd/opsx-ontology-query/SKILL.md

@@ -19,6 +19,8 @@ allowed-tools:
   - Edit
 ---
 
+> **执行方式**：先读 [交互与执行契约](../opsx-propose/interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 # 本体知识库 · 查询
 
 只负责**查**。鉴权只用 **API Key**（`Authorization: Bearer sk_sdd_…`），**禁止**走手机号登录。
@@ -39,15 +41,15 @@ SDD 流程：Propose → Spec → Design → Task → Check → Apply → Archiv
 - 当前变更内部一致性 → **本地文件 + semantic-check**，不查 KB
 - 只有 Archive → kb-ingest 后，当前变更才进入 KB（Phase 3 验证）
 
-## Session 启动（每次用本 Skill 必做）
+## Session 启动（同一连续任务复用）
 
 > **📡 共享状态**：本技能与 `opsx-kb-ingest`、`kb-upload` **共用同一份 KB 配置**（`kb-state.json`，位于 spec 仓根目录）。KB 配置（API Key + Space/KB 选择 + project-identity.json）由 `opsx-kb-config` 统一负责。
 
 ```
 Task Progress:
 - [ ] 1. 读 kb-state.json（spec 仓根目录）
-- [ ] 2. 无 apiKey 或无 targets → 提示用户运行 /opsx-kb-config 配置知识库
-- [ ] 3. 有配置 → 按意图查询（可对多个 KB 逐个查询）
+- [ ] 2. 无 apiKey 或无 targets → 记录未配置，本地工作继续；用户明确要配置时才进入 /opsx-kb-config
+- [ ] 3. 有唯一或已明确选择的目标 → 按意图查询；多个目标未明确时先澄清本次查询范围，不默认选第一个
 - [ ] 4. 按模板输出；无命中不编造
 ```
 
@@ -75,7 +77,7 @@ Task Progress:
 
 - Continuity（只要身份）→ 优先 `entities/resolve`
 - Spec 复用 → `context/match-requirement`，带 external 与/或 `entityId`
-- **KB 可用时禁止**扫描消费方本地 `archive/` 目录当跨迭代继承源；entity-id 必须来自 KB resolve by canonicalKey。KB degraded 时 archive 可作为降级手段（标注 `source: archive(degraded)`），历史有效规格以 KB current 为准
+- **KB 可用时禁止**扫描消费方本地 `archive/` 目录当跨迭代继承源；entity-id 必须来自 KB resolve by canonicalKey。KB degraded 时 archive 仅作背景参考，不自动继承身份；保留已有草稿基线，发布前再在线核对
 
 命中时关注：`resolution=LINK_EXISTING` 且 `inheritanceAllowed=true`（可继承 n）；`removedBindingCount`（已失效绑定 m）；`matchType=HISTORICAL_ONLY` 表示仅有失效绑定，不可继承。
 
@@ -103,7 +105,7 @@ scenario:    ^[A-Z0-9_-]+:SCN-[a-z0-9]+(-[a-z0-9]+)*-[0-9]{3}$
 
 ### 命中
 1. **{displayName}**（{entityType}）@ {kbName}
-   - id / version / matchType / externalRefs（归一化形态）…
+   - 业务锚点 / 来源 / 匹配依据；完整身份保留在机器响应中
    - 若外部键命中：可继承 n / 已失效绑定 m
 ```
 

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

@@ -68,7 +68,7 @@ POST {base}/entities/resolve
 ### 集成点
 
 - opsx-propose §6.5：写入 proposal frontmatter `continuity` 字段
-- 禁止扫本地 `archive/` 抄 UUID（KB 可用时）；KB degraded 时 archive 作为降级手段，标注 `source: archive(degraded)`
+- 本地 archive 仅作背景参考，不能据此宣称已验证 KB current；离线保留已有草稿身份和真实前驱，发布前在线解析，不从相似标题自动继承 ID。
 
 > **Agent 行为指导**：响应中的 `clarificationQuestions` 是 AI 生成的澄清问题，Agent 应直接用 `ask_user` 呈现给用户，不要自行回答。
 > `supportEvidence` / `oppositionEvidence` 可作为决策依据向用户展示。
@@ -235,7 +235,7 @@ POST {base}/context/match-requirement
 ### 集成点
 
 - opsx-spec §3：Continuity=iteration 时必须带 `entityId` + external
-- 禁止从本地 `archive/` 抄 UUID 当跨迭代继承源（KB 可用时）；KB degraded 时 archive 作为降级手段，标注 `source: archive(degraded)`
+- 本地 archive 仅作背景参考，不能据此宣称已验证 KB current；离线保留已有草稿身份和真实前驱，发布前在线解析，不从相似标题自动继承 ID。
 
 > **Agent 行为指导**：消费 `specGenerationContext` 判断复用率——`reusableStatements` > 50% 走迭代修改，< 20% 走全新建。
 > `warnings` 和 `clarificationQuestions` 应呈现给用户，不要忽略。

package/templates/skills/kld-sdd/opsx-ontology-query/reference.md

@@ -131,7 +131,7 @@ curl -sS -X POST "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/entities/resol
 > - `supportEvidence` / `oppositionEvidence`：支持/反对决议的证据列表，Agent 可向用户展示
 > - `clarificationQuestions`：AI 生成的澄清问题，Agent 可用 `ask_user` 呈现给用户
 
-**KB 可用时禁止**用本地 `archive/` 目录当跨迭代继承源，entity-id 必须来自 KB resolve by canonicalKey。KB degraded 时 archive 可作为降级手段（标注 `source: archive(degraded)`）。
+- 本地 archive 仅作背景参考，不能据此宣称已验证 KB current；离线保留已有草稿身份和真实前驱，发布前在线解析，不从相似标题自动继承 ID。
 
 ## 按功能号圈能力（FEAT query）
 

package/templates/skills/kld-sdd/opsx-propose/SKILL.md

@@ -15,22 +15,23 @@ allowed-tools:
   - Edit
 ---
 
+> **执行方式**：先读 [交互与执行契约](./interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 你是一个 SDD（Specification-Driven Development）业务意图文档专家。激活本技能后，你将引导用户创建符合质量红线标准的 **proposal.md** 文档。
 
-> **硬依赖**：本技能 Continuity 步骤依赖同级已部署的 **`opsx-ontology-query`**。启动 Continuity 前必须先 `Read` 该技能的 `SKILL.md`，并按其中流程准备 `kb-state.json`（spec 仓根目录，API Key + targets，与 `opsx-kb-ingest` 共用）。若项目 skills 目录中不存在 `opsx-ontology-query/`，停止 Continuity，提示用户重新执行 `kld-sdd-init`；**禁止**用本地 `archive/` 冒充查询。
+> **KB 查询依赖**：需要查询时加载 `opsx-ontology-query`；缺失或不可用只跳过远程查询，记录待核对基线后继续本地工作。
 >
-> **📡 KB 就绪检查**：§6.5 在进入编号入场前会检测 KB 配置状态。若未配置，会**主动询问**用户选择「配置」或「跳过」，不再静默降级。
+> **KB 使用**：有复用需要时查询一次；未配置或断连按交互契约继续，不在每个阶段询问配置。
 
 > **⚠️ 阶段边界约束**
 >
 > 当前处于 **Propose（规划）阶段**：
 > - ✅ **允许**：创建/编辑 proposal.md 文档、读取代码/文档作为上下文分析
 > - ❌ **禁止**：创建/修改任何代码文件、执行代码生成、运行测试
-> - ⛔ **单阶段原则**：完成 proposal.md 后**必须立即停止**，等待用户主动触发下一阶段
+> - **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 >
 > 即使用户提供了代码作为上下文，也只用于理解需求背景，**不执行任何代码操作**。
 > 代码实现请引导用户使用 `/opsx-apply` 命令。
-> **完成本阶段后，绝对禁止自动继续执行 spec/design/task 等后续阶段。**
 > 阶段边界自检见 `./checklist.md`「阶段边界⛔」。
 
 > **🖥️ 跨平台执行规则**
@@ -208,17 +209,8 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/ontology/cli.cjs" external-key --validat
    - 编号格式：大写字母 + 数字 + 连字符(-) + 下划线(_)，1~50 字符；例 KLERP-001、REQ-FI-2024-001、1010000。
    - 不合规 → **拒绝进入 resolve**，告知「编号格式不合规（仅允许大写字母、数字、连字符、下划线）」；Agent 不得猜测、补位、改写。
    - 用户明确说「没有外部需求号」→ 走 `numbering-waiver.reason`（必填理由）；`requirement-refs` 必须为空；提示本轮不种桥。
-3. **先加载依赖技能**：确认 `${AGENT_SKILL_DIR}/opsx-kb-config/SKILL.md` 存在并 Read。KB 配置（API Key + Space/KB 选择 + project-identity.json）由 `opsx-kb-config` 统一负责，`kb-state.json`（spec 仓根目录）与 `opsx-ontology-query`、`opsx-kb-ingest` 共用。未安装则停止本步。
-   - **KB 就绪检查**：运行 `node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" --check-only`，若 `"available": false`，使用 **AskUserQuestion** 询问用户：
-     > "📡 **知识库未配置**
-     >
-     > 知识库可以帮你追踪能力版本，避免重复定义。现在要配置吗？
-     > - A. **现在配置** — 运行 /opsx-kb-config，配置后可复用已有能力
-     > - B. **暂不配置，先继续** — 用本地归档数据代替（精度有限，后续入库可能需修正）
-     > - C. **取消** — 终止本次操作"
-     - **选 A** → 引导运行 `/opsx-kb-config`，配置完成后继续步骤 4。
-     - **选 B** → 在 proposal.md frontmatter 标注 `kb-status: degraded(by-user-choice)`，走降级路径（扫描归档 `ontology-identities.json` 匹配已有能力；归档为空则全部按新增处理）。
-     - **选 C** → 终止 propose。
+3. 若本轮需要 KB 复用且尚未降级，加载查询技能并使用已有 `kb-state.json`。无需先做独立 readiness 请求；查询本身即可发现连接问题。未配置、缺少查询技能、断连或无权限时，记录 `kb-status: degraded` 和原因，跳过步骤 4—6 的远程操作，继续本地编写，不开启配置问答。用户主动要求配置时再加载 `opsx-kb-config`。
+
 4. 验号通过后才 resolve：
 ```bash
 node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" --mode=resolve \
@@ -233,43 +225,23 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" --mode=resolve \
 6. 按 KB 结果确认 Continuity：`iteration` / `similar-reference` / `new`；勾选本次涉及的 CAP。
 7. 写入 proposal frontmatter：`requirement-refs`（含 `feature-id`）/ `numbering-waiver` + `continuity`。**禁止**写本地 archive 文件夹名作为 `base-archive`。
 8. CAP 级「同 key + 同锚点、不同 entity_id」当场问 A/B/C；决议写入 `ontology/continuity-resolution.json` 的 `capabilities[]`。
-9. KB 不可用 → `degraded` 继续，**禁止**扫本地 `archive/` 抄 UUID。用户选择跳过 KB 时走降级路径：
-   - 扫描 `openspec/changes/archive/*/ontology/ontology-identities.json` 匹配 canonicalKey
-   - 降级路径的所有 entity-id 来源在 sdd-output.md 知识库使用表中标注 `source: archive(degraded)`，与 `source: KB current` 明确区分。
-   - ⚠️ **降级风险**：归档中的版本号可能已过时（归档后该能力可能在 KB 中有更新版本）。降级路径取到的 predecessor-version 不保证是 KB 最新版本，入库时可能触发 `VERSION_CONFLICT`，需手动修正。
+9. KB 不可用时，保留当前草稿已有身份和真实前驱，记录 `kb-status: degraded`。本地归档可作背景参考，不能仅凭相似标题复制身份并宣称已验证 KB current。已知迭代而身份未确认时先完成正文，登记待确认项，发布前在线解析；不把“查询失败”当作“确认新增”。
 10. **不得**在本阶段生成 STMT/AC/场景或裁决场景身份；**不得**铸/改 REQ/FEAT 号。
 
-**完整流程示例（路径 A — KB 驱动）**：
-```
-# 对每个能力域按 canonicalKey 查 KB
-resolve(canonicalKey=CAP-ACCOUNT-LOCKOUT) → RELATED_ONLY (reviewRequired)
-  → candidates[0]: entity-id=90c49a72, version=d6787d6e (来自 KB current)
-  → 用户确认复用 → modified, predecessor=d6787d6e
-resolve(canonicalKey=CAP-PHONE-LOGIN) → RELATED_ONLY (reviewRequired)
-  → candidates[0]: entity-id=xxx, version=yyy (来自 KB current)
-  → 用户确认复用 → modified, predecessor=yyy
-resolve(canonicalKey=CAP-USER-REGISTRATION) → CREATE_NEW
-  → KB 中无此 canonicalKey
-  → added, 新 CAP-USER-REGISTRATION
-```
+**示例**：已有明确实体身份 → 在线核对当前版本 → 保留真实继承关系；仅相似候选 → 参考内容，不自动继承；断连 → 继续本地草稿，远程身份待确认。
 
-**完整流程示例（路径 B — archive 降级）**：
-```
-# 扫描归档（仅 KB degraded 时）
-Read openspec/changes/archive/*/proposal.md 的能力分解章节
-Read openspec/changes/archive/*/ontology/ontology-identities.json
-
-# 匹配结果示例：
-# "账号锁定从内存迁到DB" → 匹配归档 CAP-ACCOUNT-LOCKOUT (entity-id: 3d18c60e, version: 29e7f242)
-#   → modified, 复用 entity-id=3d18c60e, predecessor=29e7f242
-#   → ⚠️ source: archive(degraded)
-# "新增用户注册 API" → 无匹配
-#   → added, 新 CAP-USER-REGISTRATION
-```
+### 6.8 【自动规模判定】选择最小适用的文档形态
 
-### 7. 【交互引导】文档拆分模式选择
+先读取用户需求、已知依赖和已有文档。当前 git diff 仅作辅助，需求尚未实现时不能把空 diff 当作“小需求”的证明。
 
-**❗ 必须主动询问用户，不得默认选择**。Full / Simple / Auto 三种模式的目录结构、适用场景与 AskUserQuestion 文案见 `./reference.md`「§7 文档拆分模式选择」。根据用户选择设置 `mode: full | simple`（Auto 按能力域数量判断），记录到 proposal.md 的 YAML frontmatter。
+- 已有变更沿用原 `mode` 和目录，不自动迁移。
+- 新变更只有一个清晰能力域，优先 `simple`；多个独立能力域或需要分别维护的协作契约，采用 `full`。
+- 新接口、新表、文件数和行数是风险线索，不单独决定文档拆分。风险通过相关设计和验证处理。
+- 写入 `mode: simple | full`，在摘要中说明一句理由；不单独询问内部模式。
+
+### 7. 文档形态记录
+
+记录上述自动选择，尊重用户明确指定。详细目录说明见 `./reference.md`「§7 文档拆分模式选择」。历史文档未设置 mode 时仍按原 Full 兼容规则读取。
 
 ### 7.5 自动判断变更类型
 
@@ -286,9 +258,11 @@ Read openspec/changes/archive/*/ontology/ontology-identities.json
 
 类型原话、判断顺序和边界见 `./reference.md`「§7.5 变更类型自动分类」。
 
-### 8. 【交互引导】测试策略选择
+### 8. 【自动选择】测试策略
+
+沿用团队或当前变更已有策略。新变更中的复杂业务规则、状态转换、缺陷复现优先 `tdd`；一般实现采用 `impl-first` 并完成相关测试；仅正文说明或无运行行为变化时才用 `none`，仍验证格式或构建等实际受影响内容。写入 `test-strategy: tdd | impl-first | none` 并说明理由，不发起独立选择题。用户明确要求时调整；自动选择不能记录为 `user_decision`。
 
-**❗ 必须主动询问用户，不得默认选择**。TDD / Impl-First / None 三种策略的 DAG 结构、适用场景与 AskUserQuestion 文案见 `./reference.md`「§8 测试策略选择」。根据用户选择设置 `test-strategy: tdd | impl-first | none`，记录到 proposal.md 的 YAML frontmatter。
+详细语义见 `./reference.md`「§8 测试策略选择」。
 
 ### 9. 创建 proposal.md
 
@@ -300,28 +274,9 @@ Read openspec/changes/archive/*/ontology/ontology-identities.json
 
 > 写入文档前逐项确认，完整 8 项自检清单见 `./reference.md`「§10 质量红线自检清单」。如有任意一项未满足，重新生成对应章节，直至全部通过。
 
-### 11. 确认文档并输出结果
-
-生成文档后，向用户展示概要：
-> "已生成 proposal.md 草案，概要如下：
-> - 变更名称：[name]
-> - 核心目标：[一句话总结]
-> - 影响模块：[模块列表]
-> - 能力域：[capability 列表]
->
-> 请确认：
-> - A. 确认无误，继续创建 specs
-> - B. 需要修改 [具体章节]
-> - C. 补充更多信息"
-
-根据用户反馈：
-- 选择 A：保存文档，提示下一步
-- 选择 B/C：根据反馈修改文档
+### 11. 展示业务摘要并按授权继续
 
-最终输出：
-- 文档路径
-- 内容摘要
-- 下一步提示："运行 `/opsx-spec` 创建技术契约文档 (specs/<capability>/spec.md)"
+展示目标、范围、验收要点、自动选择及文档路径。只有业务口径未定、实际范围变化时集中询问；已有连续处理授权则加载 spec 技能继续。只请求 proposal 时在此结束，不额外问一次“是否批量推进”。
 
 ---
 
@@ -348,9 +303,9 @@ Read openspec/changes/archive/*/ontology/ontology-identities.json
 - `context` 和 `rules` 是约束条件，**不得出现在生成的文档中**。
 - proposal.md 聚焦【Why】，不写技术实现细节（留给 design.md），不写 API 细节（留给 specs）。
 - **Capabilities 章节是关键**：决定后续 specs 文件夹结构。
-- 文档写入后验证文件确实存在；每次生成都提供文档摘要，等待用户确认后再继续。
-- **⛔ 阶段边界**：本阶段禁止执行任何代码创建/修改操作。若用户要求处理代码，回复：「当前处于 Propose 阶段，代码操作请在完成文档后使用 `/opsx-apply` 执行。」
-- **⛔ 单阶段原则**：完成 proposal.md 后必须立即停止。仅提示用户下一步可运行 `/opsx-spec`，绝对禁止自动执行 spec/design/task 等后续阶段。每个阶段必须由用户主动触发。
+- 文档写入后验证文件确实存在；提供业务差异摘要；已有授权则继续，只有新增业务歧义或范围变化才询问。
+- **⛔ 阶段边界**：本阶段禁止执行任何代码创建/修改操作。已授权实现时，在前置文档和 check 完成后加载 apply 继续。
+- **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 - **⛔ Frontmatter 规范（L7）**：YAML frontmatter 中禁止写 `#` 注释（YAML 注释在 frontmatter 中可能导致解析问题）。如需说明，在 frontmatter 之前或之后用正文描述。
 - **⛔ change-type 必采**：frontmatter 必须含 `change-type`、`change-type-source`、`change-type-confidence`、`change-type-reason`；Agent 自动判断，不为内部分类单独打断用户。
 

package/templates/skills/kld-sdd/opsx-propose/checklist.md

@@ -13,10 +13,10 @@ description: opsx-propose 的阶段强制检查点与自检清单。仅在执行
 
 - [ ] ✅ 允许：创建/编辑 proposal.md 文档、读取代码/文档作为上下文分析
 - [ ] ❌ 禁止：创建/修改任何代码文件、执行代码生成、运行测试
-- [ ] ⛔ 单阶段原则：完成 proposal.md 后必须立即停止，等待用户主动触发下一阶段
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 - [ ] 即使用户提供代码作为上下文，只用于理解需求背景，不执行任何代码操作
 - [ ] 代码实现引导用户使用 `/opsx-apply`
-- [ ] ⛔ 完成本阶段后绝对禁止自动继续执行 spec/design/task 等后续阶段
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 
 ---
 
@@ -25,8 +25,8 @@ description: opsx-propose 的阶段强制检查点与自检清单。仅在执行
 - [ ] 是否有明确的问题描述？
 - [ ] 是否有可衡量的目标？
 - [ ] 是否涉及具体模块？
-- [ ] 是否有时间/资源约束？
-- [ ] 发现缺失时主动询问用户补充（"我发现以下信息还不够清晰，请补充..."）
+- [ ] 若用户提出时间/资源约束，是否已准确记录？没有约束无需专门追问。
+- [ ] 先读取已有上下文，只对影响业务范围或验收的缺失事实集中询问；可推断的内部参数由 Agent 处理。
 
 ---
 
@@ -43,7 +43,7 @@ description: opsx-propose 的阶段强制检查点与自检清单。仅在执行
 - [ ] 文档写入后验证文件确实存在
 - [ ] proposal.md 写入后已运行 `semantic-reconcile`，`openspec/changes/<变更名称>/artifacts/proposal.ontology.json` 已存在
 - [ ] 工作态 JSON 为 `canonical=false`、`review_status=draft`，实体能够通过 `source.file/source.anchor_id/source.content_hash` 展开到 proposal.md 原文
-- [ ] 每次生成都提供文档摘要，等待用户确认后再继续
-- [ ] ⛔ **阶段边界**：本阶段禁止执行任何代码创建/修改操作；用户要求处理代码时回复「当前处于 Propose 阶段，代码操作请在完成文档后使用 `/opsx-apply` 执行。」
-- [ ] ⛔ **单阶段原则**：完成 proposal.md 后必须立即停止；仅提示用户下一步可运行 `/opsx-spec`，绝对禁止自动执行 spec/design/task 等后续阶段。每个阶段必须由用户主动触发。
-- [ ] ⛔ **CAP 身份复用**：KB 可用时按 canonicalKey 逐个 resolve 获取 entity-id（路径 A），KB degraded 时扫描归档 `ontology-identities.json`（路径 B，标注 `source: archive(degraded)`）；修改既有能力已复用历史 entity-id 并设置 predecessor-version，新增能力已调用 `semantic-identity --delta-state=added`；禁止不经判定直接对所有能力调 `--delta-state=added`。
+- [ ] 提供业务差异摘要；已有授权则继续，只有新增业务歧义或范围变化才询问
+- [ ] 本阶段只产出文档；已授权实现时，文档和 check 完成后加载 apply 技能继续，不能跳过前置检查。
+- [ ] **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
+- [ ] CAP 身份：在线继承有明确解析依据；离线保留已有草稿身份和真实基线，归档仅作背景参考。已知迭代但身份待核对时记录待确认项，不因连接失败重建旧对象。

package/templates/skills/kld-sdd/opsx-propose/interaction-policy.md

@@ -0,0 +1,28 @@
+# SDD 交互与执行契约
+
+本文件统一各阶段的交互方式；各阶段仍执行自己的解析、检查和证据记录。用户的明确范围与团队显式配置优先。
+
+## 用户决定结果，Agent 管理过程
+
+- 用户只要求一个阶段（例如“只写 Spec”或单独调用 `/opsx-spec`）时，完成该阶段即停。
+- 用户已要求“完成这个需求”“实现并验证”或连续处理时，在授权范围内加载下一阶段技能并继续，Simple / Full 均适用，不反复索要阶段口令。要求“完善文档”不授权实现代码。
+- 连续推进仍按依赖完成文档、check、apply 和测试；check 未通过不得冒充通过。归档、入库、合并、推送、部署按用户授权分别判断，不能从“实现”推导为已授权发布。
+- 只在业务目标或验收口径存在实质歧义、多个身份无法判定、真实冲突或新增外部副作用需要授权时询问。先读取用户提供的材料与现有代码，集中提出缺失事实，不把 mode、UUID、内部枚举当作业务问题。
+- 自动选择文档形态和测试策略并简短说明理由；沿用已有变更的设置，不因这次默认规则重排存量目录。
+- 只展示业务差异、必要决策、验证结果和剩余问题。遥测、身份分配、结构化 JSON 由工具和 Agent 维护，不让用户手填，不把自动推断伪记为用户确认。
+
+## 本地工作可以独立进行
+
+- KB 是历史参考和发布基线服务。编写、设计、任务、实现、测试、本地归档可在离线状态继续；本地格式、语义和质量检查照常执行。
+- 有实际查询需要时直接查询，不在每个阶段先发一次 `--check-only`。同一连续任务复用已取得的上下文；发生失败后，本轮后续可选查询默认跳过，只简短提示一次。用户重试、配置/目标变化或准备发布时重新检查。
+- 未配置、断连、无权限、未安装查询技能时，记录真实原因与 `kb-status: degraded`，进入本地工作，不反复问“配置还是继续”。读取旧的 `degraded(by-user-choice)` 时继续尊重用户跳过意愿。
+- 显式离线可调用 `context-client.cjs --offline`。这只跳过远程查询，不代表验证过远程基线；`--strict` 用于明确要求在线检查的调用。
+- 本地原文和归档可以作为背景参考。已有草稿身份和前驱保持不变；只有标题/内容相似时，不从归档复制 ID 来宣称已获 KB 当前身份。已知迭代但远程身份未确认时，先写业务内容，登记待确认事项，发布前再解析，不能为绕过断网而重建旧对象身份。
+- 发布前调用在线身份同步和服务端入库校验。旧基线先比较并合并正文；不得只改 predecessor。离线、权限不足、目标不明确或版本冲突只影响相应远程操作，不作“已发布”报告。
+
+## 身份与任务的呈现
+
+- 对人用业务标题、`CAP-* / STMT-* / AC-*` 锚点和来源链接；完整 entity/version/predecessor ID 留在机器需要的元数据中。短前缀仅作显示，不能用于身份判定或截断写回。
+- 当前 Markdown 身份块和归档格式继续兼容；本规则不声称已经把业务身份迁移到 sidecar。新 ID 由工具生成，旧 ID 不批量改写。
+- 任务按可验证的行为或交付单元组织，保留依赖和验收，避免按每五分钟、每个字段或每次命令机械拆分。规模以实际风险和依赖判断，不能用估计的工时冒充质量证明。
+- 默认聚焦当前 Capability；确有跨能力依赖时允许读取相关契约，注明依赖来源，避免全量加载或混写其他能力。多仓各自保留 Git 提交事实，共享 Spec 的关联由工具处理。

package/templates/skills/kld-sdd/opsx-propose/reference.md

@@ -18,35 +18,14 @@ description: opsx-propose 的详细模板：telemetry 命令、文档拆分模
 
 ## §7 文档拆分模式选择
 
-**❗ 必须主动询问用户，不得默认选择**
-
-分析需求中的能力域数量后，使用 **AskUserQuestion** 工具向用户询问：
-
-> "📋 **检测到需求包含以下能力域：**
-> - [能力域列表]
->
-> 🤔 **请选择文档拆分模式：**
->
-> **A) 完整模式 (Full)** - 每个能力域独立文档
->    - 目录结构：`specs/<capability>/spec.md`, `specs/<capability>/design.md`, `specs/<capability>/tasks.md`
->    - 适合：大需求、多人协作、需要精细管控
->
-> **B) 简化模式 (Simple)** - 单一文档
->    - 目录结构：`spec.md`, `design.md`, `tasks.md`（合并所有能力域）
->    - 适合：小需求、单人快速迭代
->
-> **C) 自动判断** - 根据能力域数量自动选择
->    - 单个能力域 → Simple 模式
->    - 多个能力域 → Full 模式"
-
-根据用户选择：
-- 选择 A：设置 `mode: full`
-- 选择 B：设置 `mode: simple`
-- 选择 C：根据能力域数量自动判断并设置
-
-**将用户选择记录到 proposal.md 的 YAML frontmatter 中。**
+Agent 根据能力边界自动判断，无需单独询问。已有 mode 和用户明确选择优先。
 
----
+| 形态 | 目录 | 默认用途 |
+|---|---|---|
+| Simple | 根目录 spec.md / design.md / tasks.md | 单一能力域 |
+| Full | specs/<capability>/ 下分别维护三份文档 | 多能力域或需要独立协作的契约 |
+
+新接口、新表和代码行数不自动增加人工确认。未设置 mode 的存量文档仍按 Full 读取，不自动迁移。
 
 ## §7.5 变更类型自动分类
 
@@ -79,26 +58,13 @@ Agent 应在 proposal 正文或完成摘要中展示中文分类及理由，但
 
 ## §8 测试策略选择
 
-**❗ 必须主动询问用户，不得默认选择**
-
-三种策略：
-- A) TDD（红绿重构循环）：每个行为点先写失败测试再写最少代码，任务量 3-5 倍
-- B) Impl-First（代码先行）：先实现再补测试验证
-- C) None（仅实现）：不生成测试任务
-
-使用 **AskUserQuestion** 工具向用户询问（A/B/C 三选一）。
+沿用团队/当前变更配置；新变更自动选择并说明理由，不单独询问内部枚举。
 
-根据用户选择：
-- 选择 A：设置 `test-strategy: tdd`
-- 选择 B：设置 `test-strategy: impl-first`
-- 选择 C：设置 `test-strategy: none`
+- `tdd`：复杂业务行为、状态转换或需要稳定复现的缺陷。保留真实 RED→GREEN 证据。
+- `impl-first`：一般实现，配套相关测试与构建验证。
+- `none`：仅文档等不改变运行行为的变更；保留实际适用的验证，不能借此跳过业务测试。
 
-**将用户选择记录到 proposal.md 的 YAML frontmatter 中。**
-
-> 完整策略定义见 tdd-core/SKILL.md §5
-> 交互引导文案见 tdd-rules/rules/tdd-strategy-selection.md
-
----
+用户可纠正；自动判断不是用户决策，不能伪记为 `user_decision`。
 
 ## §10 质量红线自检清单
 

package/templates/skills/kld-sdd/opsx-spec/SKILL.md

@@ -15,22 +15,23 @@ allowed-tools:
   - Edit
 ---
 
+> **执行方式**：先读 [交互与执行契约](../opsx-propose/interaction-policy.md)；同一会话已读则复用。用户已授权连续处理时按范围推进，不重复索要阶段口令；只请求单阶段时完成即停。
+
 你是一个 SDD（Specification-Driven Development）技术契约专家。激活本技能后，你将引导用户为每个 Capability 创建 **spec.md** 文档。
 
-> **硬依赖**：场景身份 / Spec 复用依赖同级已部署的 **`opsx-ontology-query`**。进入知识库上下文步骤前必须先 `Read` 该技能的 `SKILL.md` 并完成其 Session 启动（API Key + targets → `kb-state.json`，spec 仓根目录）。缺失则停止复用查询，提示重新 `kld-sdd-init`；**KB 可用时禁止**从本地 `archive/` 抄 UUID，entity-id 必须来自 KB resolve by canonicalKey。
+> **KB 查询依赖**：需要复用时加载 `opsx-ontology-query`；缺失只跳过查询，不阻断正文编写。远程继承以在线解析结果为准。
 >
-> **📡 KB 就绪检查**：§2.5 在进入上下文加载前会检测 KB 配置状态。若未配置，会**主动询问**用户选择「配置」或「跳过」，不再静默降级。
+> **KB 使用**：按共享交互契约复用本轮上下文，不重复询问配置。
 
 > **⚠️ 阶段边界约束**
 >
 > 当前处于 **Spec（契约）阶段**：
 > - ✅ **允许**：创建/编辑 spec.md 文档、读取代码/文档作为上下文分析
 > - ❌ **禁止**：创建/修改任何代码文件、执行代码生成、运行测试
-> - ⛔ **单阶段原则**：完成 spec.md 后**必须立即停止**，等待用户主动触发下一阶段
+> - **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 >
 > 即使用户提供了代码作为上下文，也只用于分析现有实现，**不执行任何代码操作**。
 > 代码实现将在 `/opsx-apply` 阶段进行。
-> **完成本阶段后，绝对禁止自动继续执行 design/task 等后续阶段。**
 > 阶段边界自检见 `./checklist.md`「阶段边界⛔」。
 
 > **🖥️ 跨平台执行规则**
@@ -97,48 +98,13 @@ openspec list
 ```
 若变更不存在，引导用户先运行 `/opsx-propose <name>`。
 
-### 2. 【交互引导】确认 Capability
-
-读取 `proposal.md` 中定义的 Capabilities 列表：
-
-使用 **AskUserQuestion** 让用户选择要编写规格的 Capability：
-> "📋 **proposal.md 中定义的能力域：**
-> - A. `user-auth` - 用户认证
-> - B. `data-export` - 数据导出
-> - C. 全部（按顺序逐个创建）
->
-> 请选择要为哪个 Capability 创建 spec.md："
-
-### 2.5 【KB 就绪检查】检测并配置知识库连接
+### 2. 确定本次 Capability 范围
 
-在进入上下文加载之前，检测 Engineering KB 的连接状态。**不得静默降级**。
+从用户请求和 proposal 读取范围。只有一个 Capability 或用户已要求全部处理时自动选中；多个能力域且本次范围不明确时才询问。
 
-1. 检查 proposal.md frontmatter 中 `kb-status` 字段：
-   - 若 `kb-status: degraded(by-user-choice)` → KB 已在 propose 阶段由用户明确跳过，本阶段同样跳过 KB 查询，直接进入 §3（仅加载本地上下文）。
-   - 若未标记 → 继续检查。
-2. 运行 KB 就绪检查（程序化检测，自动搜索多 IDE 目录，消除路径歧义）：
-   ```bash
-   node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" --check-only
-   ```
-   - 输出 `"available": true` → KB 已配置
-   - 输出 `"available": false` → KB 未配置
+### 2.5 KB 上下文状态
 
-> **注意**：KB 就绪检查（`--check-only`）与 KB 上下文查询（`match-requirement`）是两个独立步骤。即使 Continuity=new 无需上下文查询，**仍需执行 `--check-only`** 确认 KB 可用性，以便在 sdd-output.md 中记录 KB 状态。
-
-3. **若已配置** → 直接进入 §3。
-4. **若未配置** → 使用 **AskUserQuestion** 询问：
-
-   > "📡 **知识库未配置**
-   >
-   > 知识库可以帮你验证场景身份、复用已有 Spec 和检索历史验收标准。现在要配置吗？
-   >
-   > - A. **现在配置** — 运行 /opsx-kb-config
-   > - B. **暂不配置，先继续** — 仅用本地数据（精度有限）
-   > - C. **取消** — 终止本次操作"
-
-   - **选 A** → 引导运行 `/opsx-kb-config`，配置完成后进入 §3。
-   - **选 B** → 在 spec.md frontmatter 标注 `kb-status: degraded(by-user-choice)`，进入 §3（仅本地上下文）。
-   - **选 C** → 终止 spec。
+复用本轮已取得的 KB 上下文。有新的复用问题时直接执行 §3 查询，不在各阶段重复 `--check-only`。本轮已降级或用户明确离线时，记录 `kb-status: degraded` 和原因，仅加载本地上下文。未配置、断连和无权限不能被当作“确认没有历史身份”，也不触发配置问答。
 
 ### 3. 【上下文加载】识别并读取用户提供的文件
 
@@ -148,7 +114,7 @@ openspec list
 
 **【默认尝试】工程 Spec 知识库上下文（场景身份主战场）**：
 
-1. **先加载依赖技能**：确认 `${AGENT_SKILL_DIR}/opsx-ontology-query/SKILL.md` 存在并 Read；按该技能完成 API Key / targets（`kb-state.json`，spec 仓根目录，与 `opsx-kb-ingest` 共用）。未安装则停止本步。
+1. **先加载依赖技能**：确认 `${AGENT_SKILL_DIR}/opsx-ontology-query/SKILL.md` 存在并 Read；使用已有 API Key / target（`kb-state.json`）；未配置或未安装仅跳过远程查询，继续正文编写。
 2. 读取 proposal Continuity。对**当前 Capability** 各调一次（「全部」= 循环 N 次，不是一次大查询）——优先走 **`opsx-ontology-query`** 的 `match-requirement`；薄封装仅作参数拼装：
 
 ```bash
@@ -234,22 +200,9 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" \
 
 > 写入文档前逐项确认，完整 7 项自检清单见 `./checklist.md`「§7 质量红线自检」。自检完成后**必须**输出结构化自检报告（模板见 `./reference.md`「§7 质量自检报告模板」），未通过项自动修复后重新输出，直至全部 ✅。
 
-### 8. 确认文档并输出结果
-
-生成文档后，向用户展示概要：
-> "已生成 spec.md，概要如下：
-> - Capability：[name]
-> - 需求项数量：[N]
-> - 场景数量：[M]
->
-> 请确认：
-> - A. 确认无误，继续下一个 Capability 的 spec / 进入 design
-> - B. 需要修改
-> - C. 补充更多信息"
+### 8. 展示可审阅的业务差异
 
-最终输出：
-- 文档路径
-- 下一步提示："运行 `/opsx-design <name> <capability>` 创建技术设计文档"
+展示新增/修改的规则、验收条件、来源和未决问题，完整 UUID 不放在面向用户的摘要中。已授权连续处理时完成范围内 Capability 后加载 design；单阶段请求在此结束。只在业务歧义或真实身份冲突时询问，不再追加“批量推进”选择题。
 
 ---
 
@@ -259,7 +212,7 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" \
 - 新需求、场景和约束分别使用 `STMT-*`、`AC-*`、`CON-*`；分配规则是同前缀同 Capability 当前最大序号 + 1。
 - 修改已有实体必须复用原 ID；删除实体只写 removal 语义，不得把编号分配给新实体。
 - `added` 必须调用 `semantic-identity --delta-state=added` 生成新的实体 UUID 和版本 UUID；禁止通过复制另一需求的 UUID 创建新实体。
-- `modified/removed` 必须从 **KB**（resolve by canonicalKey / match-requirement）取得历史 `entity-id` 和直接前序 `version-id`，调用 `semantic-identity --delta-state=<modified|removed> --entity-id=<UUID> --predecessor-version=<UUID>`；实体 UUID 复用，版本 UUID 新建。KB degraded 时可从 archive `ontology-identities.json` 只读（标注 `source: archive(degraded)`），但 **KB 可用时禁止**把本地 archive 当跨迭代继承权威。
+- `modified/removed` 保留已明确的 `entity-id` 和真实 `predecessor-version`；在线解析当前版本后由工具分配版本。离线可以继续正文，未确认的远程身份登记为待核对，发布前解决；不能从相似归档复制 UUID 或把最新版本编号直接当作实际编辑基线。
 - AC 必须嵌套在所属 STMT 下；CON 必须通过 `**constrains**` 显式引用 STMT。
 - 对 `reuseMode=REFERENCE` 的历史候选必须创建新的实体身份；禁止因为内容相似而复用历史 `entity-id`。
 - 对 `reuseMode=INHERIT` 的历史事实，必须使用返回的实体与版本来源完成 unchanged/modified 身份参数校验。
@@ -277,7 +230,7 @@ node "$(cat .sdd-spec-root)/skywalk-sdd/context-client.cjs" \
 - **需求项格式必须正确**：`####` 需求项、`#####` 场景；每个需求项必须有清晰的验收标准。
 - 技术契约必须可执行、无歧义。
 - **⛔ 阶段边界**：禁止执行任何代码创建/修改操作。
-- **⛔ 单阶段原则**：完成 spec.md 后必须立即停止。仅提示用户下一步可运行 `/opsx-design`，绝对禁止自动执行 design/task 等后续阶段。每个阶段必须由用户主动触发。
+- **执行范围**：单阶段请求完成即停；已授权连续处理则按交互契约加载下一阶段，check 通过后方可进入 apply，不能超出授权范围。
 
 ---