@fenglimg/fabric-cli 2.2.0 → 2.3.0-rc.1

package/templates/skills/fabric-store/SKILL.md

@@ -1,44 +1,29 @@
 ---
 name: fabric-store
-description: 知识 store 运维门面 — 创建 / 挂载 / 绑定 / 列出 / 切换写目标。CLI `fabric store …` 做事，本 skill 按用户意图选命令。NOT for git-managing 用户自己的产品仓。Triggers 创建 store/挂载 store/绑定知识库/store 列表/切换写库/set up knowledge store.
+description: store 运维 thin shim — 把「创建/挂载/绑定/列出/切换写库/迁移」意图路由到 `fabric store …` CLI。CLI 是引擎与安全门;本 skill 只指路。Triggers store 运维/挂载 store/绑定知识库.
 ---
 
-# fabric-store — 知识 store 运维
+# fabric-store — store 运维 thin shim
 
-每个「知识 store」操作的对话入口。CLI (`fabric store …`) 是引擎；本 skill 按用户意图挑命令。*store* 是 `~/.fabric/stores/<uuid>/` 下的平行 git 仓 —— 与用户的产品仓不同。同步 (pull+push) 见姊妹 skill `fabric-sync`。
-
-## When to use
-
-- 「创建团队 store」「建个人知识 store」
-- 「挂载团队 store」「这个项目要绑团队 store」
-- 「列出挂了哪些 store?」「我的共享决策写到哪个 store?」
-
-## When NOT to use
-
-- git 同步用户自己的产品仓 (那是普通 `git`)。
-- 同步知识 store (pull/push 冲突解决) → 用 `fabric-sync` skill。
-- 写知识条目 → 用 `fabric-archive` / `fabric-review`。
+「知识 store」操作的意图路由层:CLI (`fabric store …`) 是引擎(做事 + 守破坏性操作的 confirm 门),本 skill 只把意图映射到命令。*store* 是 `~/.fabric/stores/<uuid>/` 下的平行 git 仓,与用户产品仓无关;同步见 `fabric-sync`,写条目见 `fabric-archive`/`fabric-review`。
 
 ## 意图 → 命令映射
 
 | 意图 | 命令 |
 |---|---|
 | 创建全新本地 store | `fabric store create --alias <a> [--remote <url>]` |
-| 挂载已存在的磁盘 store | `fabric store add --uuid <u> --alias <a> [--remote <url>]` |
+| 挂载已存在的磁盘 store | `fabric store mount --uuid <u> --alias <a> [--remote <url>]` |
 | 本项目声明需要某 store | `fabric store bind <alias-or-uuid>` |
 | 列出挂载的 store | `fabric store list` |
-| 设置非 personal scope 的写目标 | `fabric store switch-write <alias>` |
+| 设置默认写库 | `fabric store switch-write <alias>` |
+| 给某 scope 单独路由写库 | `fabric store switch-write <alias> --scope <semantic_scope>` |
 | 解释某 alias 如何解析 | `fabric store explain <alias>` |
+| 迁移知识条目坐标(改 scope / 提升 / 补全) | `fabric store migrate {scope,promote,backfill}`(破坏性 → CLI 跑 confirm 门,`--dry-run` 预览) |
 | 同步 (pull+push) | 见 `fabric-sync` skill |
 
-## Precondition
-
-已 `fabric install --global` (存在 `~/.fabric` + 全局 store registry)。无全局配置 → 提示先 `fabric install --global`，停止。
-
-## Constraints
+## 红线(其余安全由 CLI 兜)
 
-- `store remove` 是 *detach ≠ delete*：从 registry 卸载但 MUST 保留磁盘 git 树。
-- `store add` MUST 拒绝磁盘无 store 树的 uuid (无「幽灵挂载」) —— 先 clone (`fabric install --global --url <remote>`) 或 `store create`。
-- 知识条目写在各 store 的 `knowledge/` 下；本 skill 只管 store 生命周期,不写条目。
-- Personal-scope 写永远落在隐式 personal store，与 active write store 无关。
-- Hook/skill NEVER 直接解析 store 或执行 store 内文件 (S65 RCE 防线：store 是数据-only)；所有 store 状态 MUST 经 CLI JSON 输出获取。
+- `store remove` = detach ≠ delete:卸 registry,保留磁盘 git 树。
+- `store mount` 拒绝幽灵挂载(磁盘无 store 树的 uuid)。
+- 破坏性 `store migrate *` MUST 经 CLI 本身的 confirm-before-mutate 门(确定性来自 CLI 不靠本 skill 厚度);本 skill 不自行改 store `knowledge/` 或 counters(派生态)。
+- Hook/skill NEVER 直接解析或执行 store 内文件(S65:store 是数据-only);store 状态一律经 CLI JSON 输出取。

package/templates/skills/fabric-sync/SKILL.md

@@ -1,46 +1,27 @@
 ---
 name: fabric-sync
-description: 多 store git 同步辅助 — 遍历挂载的知识 store, pull --rebase + push, AI 辅助解冲突。Triggers 同步知识库/sync stores/fabric-sync/解决 store 冲突/rebase 冲突.
+description: 多 store git 同步 thin shim — 路由到 `fabric sync` 引擎,仅 rebase 冲突时由 AI 辅助决断。Triggers 同步知识库/sync stores.
 ---
 
-# fabric-sync
+# fabric-sync — store 同步 thin shim
 
-跨多个挂载知识 store 的 git 同步辅助 (v2.1, S46)。CLI `fabric sync` 是事务/状态机引擎；本 skill 是它的 AI 辅助外层：遍历 store、解释每个 store 的同步结果、在 rebase 冲突时辅助用户决断 continue/abort。
+跨挂载知识 store 的 git 同步意图路由。CLI `fabric sync` 是事务/状态机引擎(遍历 store、rebase、push、persist session);本 skill 只在**冲突**时补上 AI 决断辅助 —— 其余全交 CLI。
 
-## Precondition
+## 意图 → 命令映射
 
-- 已 `fabric install --global` (存在 `~/.fabric` + 全局 store registry)。无全局配置 → 提示先装，停止。
-- 本 skill 不直接读 `~/.fabric` store 树；所有 store 状态经 `fabric sync` / `fabric store list` / `fabric scope-explain` 的 JSON 输出获取 (hook/skill 不自解析 store)。
+| 意图 | 命令 |
+|---|---|
+| 同步所有挂载 store | `fabric sync`(逐 store 报 `synced` / `offline`(defer,不报错) / `conflict`) |
+| 冲突解决后继续 | `fabric sync --continue` |
+| 放弃该 store 的本次同步 | `fabric sync --abort` |
+| 列出挂载的 store | `fabric store list`(见 `fabric-store`) |
 
-## Phase 0 — Enumerate stores
+## 唯一需 AI 的一步 — 冲突辅助(仅 `conflict` 时)
 
-`fabric store list` 拿到挂载的 store (alias / uuid / remote)。仅 remote-backed store 参与同步；local-only store 跳过 (无可推/拉)，但提示「local-only — 加 remote 备份」(R5#5)。
+rebase 停在中途时:展示冲突文件的 `<<<<<<<`/`=======`/`>>>>>>>` 段,解释两侧(ours=本地草稿/晋升,theirs=远端协作者)并给合并建议(知识条目通常可并存或取更高 maturity)。**NEVER 擅自丢弃任一侧**;用户拍板后 `--continue`,放弃则 `--abort`。
 
-## Phase 1 — Run sync
+## 红线
 
-执行 `fabric sync`。逐 store 渲染结果 (NOT 聚合成一坨)：
-- `synced` — 干净 rebase + push 完成。
-- `offline` — 网络不可达；本地已提交，push 已 defer (S17 offline-first)，下次 online 重试。**不报错**。
-- `conflict` — rebase 冲突，sync 暂停并持久化 session。进入 Phase 2。
-
-## Phase 2 — AI-assisted conflict resolution (仅冲突时)
-
-冲突 store 的工作区停在 rebase 中途。辅助用户：
-1. 展示冲突文件 (store 知识树 `knowledge/<type>/*.md` 中的 `<<<<<<<`/`=======`/`>>>>>>>` 段)。
-2. 对每个冲突，MUST 解释两侧 (ours = 本地草稿/晋升, theirs = 远端协作者) 并给出**合并建议**（知识条目通常可并存或取更成熟 maturity）。NEVER 擅自丢弃任一侧未经用户确认。
-3. 用户解决后 → `fabric sync --continue` (git rebase --continue + 恢复遍历剩余 store)。
-4. 用户选择放弃该 store → `fabric sync --abort` (git rebase --abort，该 store 留未同步，继续遍历其余)。
-
-## Phase 3 — Settle
-
-所有 store settled (无 pending/conflict) 后：CLI 自动清 session 并重生 `~/.fabric/state/bindings/<id>_resolved.json` 快照 (P3→P4 链)。汇报：已同步 store 数、deferred (offline) store 数、aborted store 数。
-
-## UX i18n Policy
-
-按 `.fabric/fabric-config.json` 的 `fabric_language` 渲染用户可见文案。Protected tokens (`fabric sync`, `--continue`, `--abort`, `git rebase`, store alias, enum) NEVER translate。
-
-## Constraints
-
-- Hook/skill **绝不**直接解析 store 或执行 store 内任何文件 (S65 RCE 防线：store 是数据-only)。
-- 冲突合并建议是辅助，最终由用户拍板；不静默丢弃知识。
-- promotion/CR 经普通 git commit，不跨 store 搬运条目。
+- Hook/skill NEVER 直接解析或执行 store 内文件(S65:store 是数据-only);store 状态 MUST 经 CLI JSON 取。
+- 仅 remote-backed store 参与同步;local-only 跳过并提示加 remote 备份。
+- 冲突合并不静默丢知识;promotion 经普通 git commit,不跨 store 搬运条目。

package/templates/skills/lib/shared-policy.md

@@ -1,7 +1,8 @@
 # Shared skill policy — cross-skill canonical core (rc.37 NEW-13)
 
-> **Single source of truth** for the policy invariants that fabric-archive,
-> fabric-review, and fabric-import all depend on. Each skill's `ref/` keeps
+> **Single source of truth** for the policy invariants that fabric-archive
+> (incl. its source mode) and fabric-review (incl. its retire / relate
+> sub-flows) depend on. Each skill's `ref/` keeps
 > only its skill-specific examples and points here (`../../lib/shared-policy.md`)
 > for the common rules. Edit invariants HERE — never fork them per skill.
 
@@ -10,7 +11,7 @@
 When rendering bilingual (zh-CN ↔ en) output, prose is translated but the
 following classes of token appear **verbatim in both variants**:
 
-- **MCP tool + field names**: `fab_extract_knowledge`, `fab_review`,
+- **MCP tool + field names**: `fab_propose`, `fab_review`, `fab_pending`,
   `fab_recall`, `fab_archive_scan`,
   `relevance_scope`, `relevance_paths`, `source_sessions`, `proposed_reason`,
   `session_context`, `intent_clues`, `tech_stack`, `impact`, `must_read_if`,
@@ -61,9 +62,10 @@ This block is itself a protected token sequence — render `强 team` /
 Skills persist lifecycle via MCP tools (which emit the canonical events) —
 they do NOT hand-write `.fabric/events.jsonl`:
 
-- `fab_extract_knowledge` → `knowledge_proposed` (+ archive-attempt events).
+- `fab_propose` → `knowledge_proposed` (+ archive-attempt events).
 - `fab_review` approve → `knowledge_promote_started` → `knowledge_promoted`.
 - `fab_review` modify-layer → `knowledge_layer_changed` (+ id-redirect).
+- `fab_pending` list/search → read-only browse/search (no events emitted).
 
 Never instruct the user to delete or hand-edit the event ledger; it is the
 append-only audit trail. Counter rollups live in `.fabric/metrics.jsonl`.

package/dist/chunk-27HK6H5Y.js

@@ -1,69 +0,0 @@
-#!/usr/bin/env node
-import {
-  storeGitRemote
-} from "./chunk-QPAW6IYT.js";
-import {
-  loadProjectConfig
-} from "./chunk-QFIVFZRH.js";
-import {
-  loadGlobalConfig,
-  resolveGlobalRoot
-} from "./chunk-FNHDQTPC.js";
-
-// src/lib/unknown-flags.ts
-function warnUnknownFlags(known) {
-  const knownSet = /* @__PURE__ */ new Set([...known, "help", "version"]);
-  const unknown = [];
-  for (const tok of process.argv.slice(2)) {
-    if (!tok.startsWith("--")) continue;
-    const name = tok.slice(2).split("=")[0].replace(/^no-/, "");
-    if (name.length === 0) continue;
-    if (!knownSet.has(name)) unknown.push(tok.split("=")[0]);
-  }
-  if (unknown.length > 0) {
-    process.stderr.write(`[fabric] ignored unknown flag(s): ${unknown.join(", ")}
-`);
-  }
-}
-
-// src/store/info-ops.ts
-function whoami(globalRoot = resolveGlobalRoot()) {
-  const config = loadGlobalConfig(globalRoot);
-  if (config === null) {
-    return null;
-  }
-  return {
-    uid: config.uid,
-    stores: config.stores.map((s) => ({
-      alias: s.alias,
-      mount_name: s.mount_name ?? null,
-      store_uuid: s.store_uuid,
-      // F4: parity with `fabric store list` — local-only reflects the store
-      // repo's TRUE git remote (what sync actually pushes to), not the registry
-      // metadata. A store with a physical `origin` but no registry `remote`
-      // (e.g. the personal store) was misreported as local-only by whoami while
-      // `store list` honestly showed its remote. Both now read the same source.
-      local_only: storeGitRemote(s.alias, globalRoot) === void 0
-    }))
-  };
-}
-function projectStatus(projectRoot, globalRoot = resolveGlobalRoot()) {
-  const global = loadGlobalConfig(globalRoot);
-  const project = loadProjectConfig(projectRoot);
-  return {
-    uid: global?.uid ?? null,
-    mounted: (global?.stores ?? []).map((s) => s.alias),
-    project_id: project?.project_id ?? null,
-    is_fabric_project: project !== null,
-    required: (project?.required_stores ?? []).map((r) => r.id),
-    active_write_store: project?.active_write_store ?? null,
-    default_write_store: project?.default_write_store ?? null,
-    write_routes: project?.write_routes ?? []
-  };
-}
-
-export {
-  warnUnknownFlags,
-  whoami,
-  projectStatus
-};