kld-sdd 2.6.8 → 2.6.9

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kld-sdd",
-  "version": "2.6.8",
+  "version": "2.6.9",
   "description": "KLD SDD OpenSpec 项目初始化工具 - 一键部署 SDD skills",
   "main": "index.js",
   "bin": {

package/skywalk-sdd/context-client.cjs

@@ -5,6 +5,7 @@ const fs = require('fs');
 const http = require('http');
 const https = require('https');
 const { URL } = require('url');
+const path = require('path');
 
 function parseArgs(argv) {
   const args = {};
@@ -71,10 +72,16 @@ function requestJson(url, payload, token, timeoutMs) {
             reject(new Error(`knowledge base returned invalid JSON (HTTP ${response.statusCode})`));
             return;
           }
-          if (response.statusCode >= 400 || parsed?.code !== 0) {
+          if (response.statusCode >= 400) {
             reject(new Error(parsed?.message || `knowledge base HTTP ${response.statusCode}`));
             return;
           }
+          // code 字段仅当存在且不为 0 时才视为业务错误（health/ingest 等管理 API 返回 code，
+          // 但 resolve/search 等 context API 直接返回 data，不包含 code 字段）
+          if (parsed?.code != null && parsed.code !== 0) {
+            reject(new Error(parsed?.message || `knowledge base error code ${parsed.code}`));
+            return;
+          }
           resolve(parsed.data);
         });
       },
@@ -149,8 +156,57 @@ function buildPayload(args, mode) {
 }
 
 async function retrieveContext(args = parseArgs(process.argv), env = process.env) {
-  const spaceId = args['space-id'] || env.ENGINEERING_KB_SPACE_ID || '';
-  const kbId = args['kb-id'] || env.ENGINEERING_KB_KB_ID || '';
+  // 优先从共享 state 文件读取配置（与 opsx-ontology-query / opsx-kb-ingest 共用）
+  // 搜索多个可能的 IDE skills 目录（.codebuddy / .claude / .cursor 等）
+  let stateConfig = {};
+  const stateFile = args['state-file'] || env.SDD_KB_STATE_FILE;
+  const candidatePaths = [];
+  if (stateFile) candidatePaths.push(stateFile);
+  // 从 skywalk-sdd 目录向上查找 skills/.shared/kb-state.json
+  const ideDirs = ['.codebuddy', '.claude', '.cursor', '.vscode'];
+  for (const ide of ideDirs) {
+    candidatePaths.push(path.join(__dirname, '..', ide, 'skills', '.shared', 'kb-state.json'));
+  }
+  // 也检查 skywalk-sdd 同级的 .shared
+  candidatePaths.push(path.join(__dirname, '.shared', 'kb-state.json'));
+  for (const p of candidatePaths) {
+    try {
+      if (fs.existsSync(p)) {
+        stateConfig = JSON.parse(fs.readFileSync(p, 'utf8'));
+        break;
+      }
+    } catch (_) { /* try next */ }
+  }
+
+  const apiBase = args['api-base'] || stateConfig.api || env.ENGINEERING_KB_API || 'http://localhost:8090/api';
+  const token = args.token || stateConfig.apiKey || env.ENGINEERING_KB_TOKEN || '';
+  const spaceId = args['space-id'] || env.ENGINEERING_KB_SPACE_ID ||
+    (stateConfig.targets && stateConfig.targets.length > 0 ? stateConfig.targets[0].spaceId : '');
+  const kbId = args['kb-id'] || env.ENGINEERING_KB_KB_ID ||
+    (stateConfig.targets && stateConfig.targets.length > 0 ? stateConfig.targets[0].kbId : '');
+
+  // --check-only: 只检查 KB 配置是否就绪，不发起 API 请求
+  // 用于 SDD 各阶段（propose/spec/design/task/check）统一检测 KB 可用性，消除相对路径歧义
+  if (args['check-only']) {
+    const missing = [];
+    if (!token) missing.push('apiKey');
+    if (!spaceId) missing.push('spaceId');
+    if (!kbId) missing.push('kbId');
+    if (missing.length > 0) {
+      return {
+        available: false,
+        reason: 'engineering_kb_not_configured',
+        missing,
+        hint: 'Run opsx-ontology-query Session startup to configure .shared/kb-state.json',
+      };
+    }
+    return {
+      available: true,
+      api: apiBase,
+      targets: stateConfig.targets || [],
+    };
+  }
+
   if (!spaceId || !kbId) {
     return {
       available: false,
@@ -162,8 +218,6 @@ async function retrieveContext(args = parseArgs(process.argv), env = process.env
   }
 
   const mode = String(args.mode || 'match').trim().toLowerCase() === 'resolve' ? 'resolve' : 'match';
-  const apiBase = args['api-base'] || env.ENGINEERING_KB_API || 'http://localhost:8090/api';
-  const token = args.token || env.ENGINEERING_KB_TOKEN || '';
   const timeoutMs = Number(args.timeout || env.ENGINEERING_KB_TIMEOUT_MS || 30000);
   const payload = buildPayload(args, mode);
   const data = await requestJson(

package/templates/skills/kld-sdd/openspec-sync-specs/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: openspec-sync-specs
+description: Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.
+allowed-tools: Bash(openspec:*)
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.6.0"
+---
+
+Sync delta specs from a change to main specs.
+
+This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
+
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have delta specs (under `specs/` directory).
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Resolve change context**
+
+   Run:
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+
+3. **Find delta specs**
+
+   Use `artifactPaths.specs.existingOutputPaths` from the status JSON as the list of delta spec files.
+
+   Each delta spec file contains sections like:
+   - `## ADDED Requirements` - New requirements to add
+   - `## MODIFIED Requirements` - Changes to existing requirements
+   - `## REMOVED Requirements` - Requirements to remove
+   - `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
+
+   If no delta specs found, inform user and stop.
+
+4. **For each delta spec, apply changes to main specs**
+
+   For each repo-local capability delta spec path returned by the CLI:
+
+   a. **Read the delta spec** to understand the intended changes
+
+   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
+
+   c. **Apply changes intelligently**:
+
+      **ADDED Requirements:**
+      - If requirement doesn't exist in main spec → add it
+      - If requirement already exists → update it to match (treat as implicit MODIFIED)
+
+      **MODIFIED Requirements:**
+      - Find the requirement in main spec
+      - Apply the changes - this can be:
+        - Adding new scenarios (don't need to copy existing ones)
+        - Modifying existing scenarios
+        - Changing the requirement description
+      - Preserve scenarios/content not mentioned in the delta
+
+      **REMOVED Requirements:**
+      - Remove the entire requirement block from main spec
+
+      **RENAMED Requirements:**
+      - Find the FROM requirement, rename to TO
+
+   d. **Create new main spec** if capability doesn't exist yet:
+      - Create `openspec/specs/<capability>/spec.md`
+      - Add Purpose section (can be brief, mark as TBD)
+      - Add Requirements section with the ADDED requirements
+
+5. **Show summary**
+
+   After applying all changes, summarize:
+   - Which capabilities were updated
+   - What changes were made (requirements added/modified/removed/renamed)
+
+**Delta Spec Format Reference**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: Old Name`
+- TO: `### Requirement: New Name`
+```
+
+**Key Principle: Intelligent Merging**
+
+Unlike programmatic merging, you can apply **partial updates**:
+- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
+- The delta represents *intent*, not a wholesale replacement
+- Use your judgment to merge changes sensibly
+
+**Output On Success**
+
+```
+## Specs Synced: <change-name>
+
+Updated main specs:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Main specs are now updated. The change remains active - archive when implementation is complete.
+```
+
+**Guardrails**
+- Read both delta and main specs before making changes
+- Preserve existing content not mentioned in delta
+- If something is unclear, ask for clarification
+- Show what you're changing as you go
+- The operation should be idempotent - running twice should give same result

package/templates/skills/kld-sdd/openspec-update-change/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: openspec-update-change
+description: Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.
+allowed-tools: Bash(openspec:*)
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.6.0"
+---
+
+Revise a change's existing planning artifacts and keep them coherent. Never edit code.
+
+**Store selection:** If the user names a store (a store is a standalone OpenSpec repo registered on this machine) or the work lives in one, run `openspec store list --json` to discover registered store ids, then pass `--store <id>` on the commands that read or write specs and changes (`new change`, `status`, `instructions`, `list`, `show`, `validate`, `archive`, `doctor`, `context`). Other commands do not take the flag. Hints printed by commands already carry the flag; keep it on follow-ups. Without a store, commands act on the nearest local `openspec/` root.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to update.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from `schema` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from `lastModified` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to update.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Get the change's artifacts**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand current state. The response includes:
+   - `schemaName`: The workflow schema being used (e.g., "spec-driven")
+   - `artifacts`: Array of artifacts with their status ("done", "ready", "blocked")
+   - `isComplete`: Boolean indicating if all artifacts are complete
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
+
+   The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
+
+   The files to edit are `artifactPaths.<id>.existingOutputPaths` - the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. `specs/**/*.md`). Do NOT write to `resolvedOutputPath`: for a glob artifact it is still the glob pattern, not a real file.
+
+3. **Understand the request**
+   - If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
+   - If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
+
+4. **Read and reconcile**
+   - Read the artifact(s) the request touches and the change's other existing artifacts.
+   - Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
+   - Note everything that is now inconsistent, missing, or contradictory.
+   - Revise only files that already exist (`existingOutputPaths`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to `/opsx:continue` to create them.
+   - If the change is already coherent, say so and make no edits.
+
+5. **Confirm and apply, one artifact at a time**
+   - Show each proposed revision and why. Write only after the user confirms.
+   - If the user rejects a revision, do not write it - leave that artifact unchanged.
+   - When a substantial rewrite is needed, get that artifact's rules and template first:
+     ```bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     ```
+
+6. **Point to the next step (guidance only - NEVER act on it)**
+   - Artifacts still missing -> suggest `/opsx:continue` to create them.
+   - Change already implemented (tasks checked off / already applied) -> the code may no longer match the revised plan; suggest `/opsx:apply` to carry the delta into code.
+   - Everything done and implemented -> suggest `/opsx:archive`.
+
+**Output**
+
+After each invocation, show:
+- Which artifacts were revised (and which proposed revisions were rejected)
+- Anything deferred to `/opsx:continue` (not-yet-created artifacts or files)
+- Where the change stands and the recommended next command
+
+**Guardrails**
+- Planning artifacts only - NEVER edit implementation code. If the revised plan implies code changes, stop and point to `/opsx:apply`.
+- Use the artifact ids and paths reported by `openspec status`; never branch on hardcoded artifact names.
+- Edit only the concrete files in `existingOutputPaths`; never write to a glob `resolvedOutputPath`.
+- Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is `/opsx:continue`'s job.
+- Confirm every edit with the user before writing.
+- If the request changes the change's *intent* rather than refining it, recommend starting fresh with `/opsx:new` (the "Update vs. Start Fresh" heuristic).

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

@@ -17,7 +17,7 @@ allowed-tools:
 
 你是一个 SDD（Specification-Driven Development）变更归档专家。激活本技能后，你要安全地结束变更生命周期：真实归档文档、同步正式 specs、记录 archive telemetry，并生成最终中文度量报告。
 
-> **硬依赖（收尾入库）**：zip 生成后的上传依赖同级已部署的 **`opsx-kb-ingest`**。进入 §5.5 前必须先 `Read` 该技能的 `SKILL.md` 并完成其 Session 启动。缺失则提示用户重新 `kld-sdd-init`，**不要**自造另一套入库协议。
+> **硬依赖（收尾入库）**：zip 生成后的上传依赖同级已部署的 **`opsx-kb-ingest`**。进入 §5.5 前必须先 `Read` 该技能的 `SKILL.md` 并完成其 Session 启动。入库成功后，`Read` `opsx-ontology-query/phase-3-postchange.md` 验证版本生效、AC 保留、关系完整性。缺失则提示用户重新 `kld-sdd-init`，**不要**自造另一套入库协议。
 
 > **跨平台执行规则**
 > - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。

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

@@ -3,7 +3,8 @@ name: opsx-check
 description: "质量检查技能 - 验证文档完整性、一致性、算法正确性及可执行性"
 argument-hint: "[change-name] [上下文文件...]"
 license: MIT
-compatibility: Requires openspec CLI.
+compatibility: Requires openspec CLI; depends on opsx-ontology-query for external-key validation and baseline checks.
+  depends-on: opsx-ontology-query
 metadata:
   author: sdd-team
   version: "3.0"
@@ -25,6 +26,10 @@ allowed-tools:
 > 即使检查发现代码相关问题，也只记录在检查报告中，**不自动修复代码**。
 > 代码修复将在 `/opsx-apply` 阶段进行。
 
+> **KB 上下文**：check 阶段需验证外部键格式（REQ/FEAT/SCN 文法）、SCN REQ 前缀一致性和历史覆盖率基线。进入相关步骤前先 `Read` `opsx-ontology-query/phase-2-during.md` §3-5，并按 `SKILL.md` → Session 启动准备 API Key + targets。
+>
+> **📡 KB 就绪检查**：§2.6 在进入 KB 相关检查前会检测 KB 配置状态。若未配置，会**主动询问**用户选择「配置」或「跳过」，KB 相关检查项降级为仅本地验证。
+
 
 > **🖥️ 跨平台执行规则**
 > - 先确认当前终端工作目录是项目根目录；若不是，先 `cd` 到项目根目录。
@@ -106,6 +111,34 @@ node skywalk-sdd/ontology/cli.cjs diagnose-naming --project=. --mode=code-repo
 
 最终检查报告必须包含「多仓库关联配置」章节（命令输出已按此格式打印）。
 
+### 2.6 【KB 就绪检查】检测并配置知识库连接
+
+在进入 KB 相关检查（外部键验证、coverage 基线）之前，检测 Engineering KB 的连接状态。
+
+1. 检查 proposal.md frontmatter 中 `kb-status` 字段：
+   - 若 `kb-status: degraded(by-user-choice)` → KB 已被用户明确跳过，本阶段 KB 相关检查降级为仅本地验证（external-key 格式校验 + 本地 semantic-check），跳过 KB API 调用。
+   - 若未标记 → 继续检查。
+2. 运行 KB 就绪检查（程序化检测，自动搜索多 IDE 目录，消除路径歧义）：
+   ```bash
+   node skywalk-sdd/context-client.cjs --check-only
+   ```
+   - 输出 `"available": true` → KB 已配置
+   - 输出 `"available": false` → KB 未配置
+3. **若已配置** → 直接进入 §3，正常使用 KB 做 coverage 基线、predecessor 预检。
+4. **若未配置** → 使用 **AskUserQuestion** 询问：
+
+   > "📡 **Engineering KB 未配置**
+   >
+   > KB 可以提供覆盖率基线检查、predecessor 版本预检（防止入库冲突）。是否现在配置？
+   >
+   > - A. **配置 KB**
+   > - B. **跳过 KB**，仅执行本地检查（semantic-check + external-key 格式校验），入库前无 predecessor 预检
+   > - C. **取消操作**"
+
+   - **选 A** → 配置 → 进入 §3。
+   - **选 B** → KB 相关检查项降级：coverage 基线跳过、`current-version` 预检跳过。检查报告中标注 `kb: degraded(by-user-choice)`。
+   - **选 C** → 终止 check。
+
 ### 3. 【上下文加载】识别并读取用户提供的文件
 
 **自动识别上下文文件**：

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

@@ -27,6 +27,15 @@ allowed-tools:
 > **完成本阶段后，绝对禁止自动继续执行 task 等后续阶段。**
 > 阶段边界自检见 `./checklist.md`「阶段边界⛔」。
 
+> **KB 上下文**：设计时可参考历史设计决策。
+> 1. 检查 proposal.md frontmatter `kb-status`：若 `degraded(by-user-choice)` → 跳过 KB，仅用本地上下文。
+> 2. 否则运行 KB 就绪检查：
+> ```bash
+> node skywalk-sdd/context-client.cjs --check-only
+> ```
+> - `"available": true` → 若需查历史设计参考，先 `Read` `opsx-ontology-query/phase-2-during.md` §1
+> - `"available": false` → **KB 不可用不阻塞 design 流程**，仅跳过历史设计参考查询
+
 > **⚠️ 渐进式上下文加载原则**
 >
 > - 本技能针对**单一 Capability** 执行设计（Simple 模式例外，见下方 S1 说明）

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

@@ -13,20 +13,14 @@ description: >-
 
 > 控制台知识库页另有浮动 Ontology Agent（会话登录 + SSE）；本 Skill 仍走 API Key，二者分开。
 
-本地状态文件（含密钥，勿提交）：
-
-```text
-skills/opsx-kb-ingest/.local/state.json
-```
-
-字段说明 → [reference.md](reference.md)。
+> **📡 共享状态**：本技能与 `opsx-ontology-query` **共用同一份 KB 配置**（`../.shared/kb-state.json`）。任一 skill 配置后，另一个自动可用，无需重复输入 API Key。
 
 ## Session 启动（每次用本 Skill 必做）
 
 ```
 Task Progress:
-- [ ] 1. 读 .local/state.json（没有则当空）
-- [ ] 2. 无 apiKey → 向用户索取并写入 state（勿把完整 key 打进聊天摘要）
+- [ ] 1. 读 ../.shared/kb-state.json（没有则当空）
+- [ ] 2. 无 apiKey → 向用户索取并写入共享 state（勿把完整 key 打进聊天摘要）
 - [ ] 3. 无 targets 或用户要重置 → 拉空间/KB 列表，让用户多选后写入
 - [ ] 4. 按意图执行入库操作（上传 / 查状态 / 列表 / 重试）
 - [ ] 5. 按模板输出结果
@@ -36,9 +30,9 @@ Task Progress:
 
 若 `state.apiKey` 为空或无效（401/403）：
 
-1. 请用户提供 API Key（控制台「API 密钥」创建，至少含 `archive:ingest`）。
+1. 请用户提供 API Key（控制台「API 密钥」创建，至少含 `archive:ingest`。建议同时勾选 `context:read`，使 `opsx-ontology-query` 也能复用此 Key）。
 2. 可选：请用户确认 `api`（默认 `http://localhost:8090/api`）与 `tenantKey`（默认 `default`）。
-3. 写入 `.local/state.json`（创建目录若不存在）。
+3. 写入共享 `../.shared/kb-state.json`（创建目录若不存在）。
 4. 用 `GET $API/health` 探活；再用 `GET $API/v1/spaces?tenantKey=…` + Bearer 校验 key。
 
 用户说「换密钥 / 重置 API Key」→ 清空 `apiKey`（可保留 targets），回到本步。
@@ -165,17 +159,18 @@ curl -sS -X POST "$API/v1/spaces/$SPACE_ID/knowledge-bases/$KB_ID/ingestions/$JO
 - 无 `targets` 不得臆造 spaceId/kbId。
 - 上传前确认 zip 包路径存在且为有效 zip 文件。
 - 入库失败时展示 `errorCode` 和 `errorMessage`，不编造原因。
-- 完整 apiKey 只写 state 文件；聊天里最多显示前缀（如 `sk_sdd_****`）。
+- 完整 apiKey 只写共享 state 文件（`../.shared/kb-state.json`）；聊天里最多显示前缀（如 `sk_sdd_****`）。
 - 401/403 时清掉 `apiKey`，请用户重贴；勿循环重试。
+- **共享状态**：state 文件与 `opsx-ontology-query` 共用。如用户此前已通过查询 skill 配置过 KB，本 skill 启动时直接读取已有配置，无需重复询问。
 
 ## 用户口令
 
 | 用户说 | Agent 做 |
 |--------|----------|
-| （首次使用） | 要 key → 选 KB（多选）→ 再操作 |
+| （首次使用） | 要 key → 选 KB（多选）→ 写共享 state → 再操作。此后 `opsx-ontology-query` 也自动可用 |
 | 换密钥 / 重置 API Key | 清 apiKey，重走第 2 步 |
 | 重新选择 / 重置空间或知识库 | 清 targets，重走第 3 步 |
-| 上传 / 入库 | 用当前 targets 中选中的 KB 上传 zip |
+| 上传 / 入库 | 用当前共享 targets 中选中的 KB 上传 zip |
 | 查状态 / 看任务 | 用 jobId 查询任务状态 |
 | 列任务 / 看历史 | 列出最近入库任务 |
 | 重试 | 对失败的 jobId 执行重试 |