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

package/templates/skills/{fabric-import/ref/phase-2-mining.md → fabric-archive/ref/source-mining.md}

@@ -4,16 +4,16 @@
 
 ## Mandatory Scope Rule — Always Broad + Empty Paths (Q-1 Resolution)
 
-**EVERY `fab_extract_knowledge` call issued from this skill MUST set:**
+**EVERY `fab_propose` call issued from this skill MUST set:**
 
 - `relevance_scope = "broad"`
 - `relevance_paths = []`
 
 This is non-negotiable and applies to BOTH Step 2.1 (git mining) AND Step 2.2 (docs mining). No exceptions, no per-candidate override, no Agent judgment.
 
-**Rationale — why fabric-import cannot bind paths from git history:**
+**Rationale — why archive source mode cannot bind paths from git history:**
 
-1. `fabric-import` is LLM-driven (mines git log + docs), not session-driven (no live `edit_paths` signal).
+1. `archive source mode` is LLM-driven (mines git log + docs), not session-driven (no live `edit_paths` signal).
 2. `git diff --stat` lists files touched by a commit, but those files are the commit's **effect surface**, not the **applicability surface** of the underlying observation. A pitfall surfaced by a fix in `packages/server/src/retry.ts` may apply to every retry call-site in the repo, not just that one file.
 3. LLM-inferred `relevance_paths` from historical commit metadata produces false-narrow bindings — `relevance_paths` becomes a lie about applicability. Post-rc.37 A1 the server no longer filters by `relevance_scope`, so false-narrow does NOT hide knowledge from AI recall (every selectable entry is surfaced regardless of scope). The damage is now downstream: doctor lint accounting, future-AI judgment, and any consumer that reads `relevance_paths` literally treats the wrong globs as ground truth. Broad+[] keeps the metadata honest until the user has the real applicability surface in hand to declare narrow.
 4. Doc-mined observations are usually architectural / cross-cutting (a `docs/architecture.md` "Why a monolith?" decision applies to the whole codebase, not just to `docs/`).
@@ -24,16 +24,16 @@ This is non-negotiable and applies to BOTH Step 2.1 (git mining) AND Step 2.2 (d
 - DO NOT derive `relevance_paths` from the path of a mined Markdown file (e.g. do NOT bind a `docs/architecture.md` observation to `["docs/**"]`).
 - DO NOT extract path-shaped tokens from commit subjects / bodies / doc text and lift them into `relevance_paths`.
 - DO NOT classify a candidate as `relevance_scope = "narrow"` under ANY heuristic.
-- DO NOT copy the public-prefix-generalization logic from fabric-archive Phase 3.5 — that logic is valid only when bound to a real-time `edit_paths` signal from an active session, which fabric-import lacks.
+- DO NOT copy the public-prefix-generalization logic from fabric-archive Phase 3.5 — that logic is valid only when bound to a real-time `edit_paths` signal from an active session, which archive source mode lacks.
 
-**Cross-reference — fabric-import vs fabric-archive scope handling:**
+**Cross-reference — archive source mode vs fabric-archive scope handling:**
 
 | Skill            | Scope decision     | Why                                                                   |
 |------------------|--------------------|-----------------------------------------------------------------------|
 | `fabric-archive` | narrow OR broad, case-by-case per Phase 3.5 rules | Has live `edit_paths` from the active session — the actual applicability surface. |
-| `fabric-import`  | ALWAYS broad + `[]` (this skill) | LLM-only, no live session signal; git-history paths are effect-surface, not applicability-surface. |
+| `archive source mode`  | ALWAYS broad + `[]` (this skill) | LLM-only, no live session signal; git-history paths are effect-surface, not applicability-surface. |
 
-`fabric-archive`'s Phase 3.5 scope decision (narrow-vs-broad rules + public-prefix generalization + glob blacklist) is INTENTIONALLY MORE PERMISSIVE than fabric-import because archive has the data to bind safely. fabric-import is the STRICTER case.
+`fabric-archive`'s Phase 3.5 scope decision (narrow-vs-broad rules + public-prefix generalization + glob blacklist) is INTENTIONALLY MORE PERMISSIVE than archive source mode because archive has the data to bind safely. archive source mode is the STRICTER case.
 
 **Post-import narrowing path — deferred to user, via `fab_review.modify`:**
 
@@ -77,16 +77,16 @@ For each commit:
    - `chore(...)`, `test(...)`, `ci(...)` → almost always skip (mechanical; no reusable insight)
 2. Read the commit body. Extract the LLM-judged "core observation" — what would a future engineer want to know about this commit beyond the diff? Aim for 1–2 sentences in zh-CN (project fabric_language; mirror fabric-archive M3 style).
 3. Apply the **Skip Decision Tree** below. If the commit is skip-worthy, record it in `p2_processed_commits[]` with `skipped: true` and move on.
-4. For non-skipped commits, classify type / propose slug / draft summary. Then call `fab_extract_knowledge` with the **mandatory broad + [] scope** (see "Mandatory Scope Rule" above):
+4. For non-skipped commits, classify type / propose slug / draft summary. Then call `fab_propose` with the **mandatory broad + [] scope** (see "Mandatory Scope Rule" above):
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
-  source_sessions: ["fabric-import-<ISO8601-date>"],   // T5: array form; stable per import run
+mcp__fabric__fab_propose({
+  source_sessions: ["fabric-archive-source-<ISO8601-date>"],   // T5: array form; stable per import run
   recent_paths: ["<files touched by this commit, capped at 20>"],   // provenance only, NOT a path-binding signal
   user_messages_summary: "<zh-CN 1-2 sentence summary of the commit's core observation; cite the commit sha as 'src=<sha7>'>",
   type: "decisions" | "pitfalls" | "guidelines" | "models" | "processes",
   slug: "<kebab-case 2-5 words derived from commit subject + body>",
-  relevance_scope: "broad",                                          // MANDATORY — never "narrow" from fabric-import
+  relevance_scope: "broad",                                          // MANDATORY — never "narrow" from archive source mode
   relevance_paths: [],                                               // MANDATORY — never derived from git history
   proposed_reason: "<inferred per Step 2.1.5 — varies>",
   session_context: "Imported from git log analysis. Origin: commit <sha7> (<subject 30 chars>). No live session — see commit body for full context.",
@@ -108,7 +108,7 @@ Note: `recent_paths` carries the touched-file list for **provenance display** on
 
 ## Step 2.1.5 — Proposed Reason Inference (rc.7 T6)
 
-For each non-skipped commit OR doc section, infer `proposed_reason` from prefix + body signal jointly. The 6 reasons below are the full enum accepted by `fab_extract_knowledge` (schema-locked):
+For each non-skipped commit OR doc section, infer `proposed_reason` from prefix + body signal jointly. The 6 reasons below are the full enum accepted by `fab_propose` (schema-locked):
 
 | Source signal | Body cue | Inferred reason |
 |---|---|---|
@@ -148,7 +148,7 @@ For each Markdown file:
    - `LICENSE.md`, `CODE_OF_CONDUCT.md`, `CONTRIBUTING.md` → skip (boilerplate)
    - Files <300 bytes → skip (too thin to extract meaningful observations)
 2. Read the file. Identify candidate observations: section headings that read like decisions ("we chose X over Y"), guidelines ("always do X"), pitfalls ("don't do Y because..."), or process steps ("the deploy procedure is..."). Architecture diagrams in fenced code blocks are strong **model** signals.
-3. For each observation, classify type / propose slug / draft summary. Call `fab_extract_knowledge` with the same shape as Step 2.1 (including the **mandatory `relevance_scope: "broad"` + `relevance_paths: []`**), replacing `recent_paths` with `[<this doc path>]` and citing `src=<doc-relative-path>` in the summary.
+3. For each observation, classify type / propose slug / draft summary. Call `fab_propose` with the same shape as Step 2.1 (including the **mandatory `relevance_scope: "broad"` + `relevance_paths: []`**), replacing `recent_paths` with `[<this doc path>]` and citing `src=<doc-relative-path>` in the summary.
 4. Append to `.fabric/.import-state.json`:
    - `p2_processed_docs[].push({path: <doc path>, observations_proposed: <count>, pending_paths: [...]})`
 5. **Hard cap shared with Step 2.1**: total new pending entries across git + docs is capped at `import_max_pending_per_run` (config-resolved, default 10) per Phase 2 run.
@@ -167,14 +167,14 @@ A candidate signal surfaces (commit body or doc section).
   │    └─ NO  → skip (not classifiable = not yet ripe)
   ├─ Is the slug derivable as 2-5 kebab-case words?
   │    └─ NO  → skip (signal too vague for stable identifier)
-  └─ Else → propose via fab_extract_knowledge
+  └─ Else → propose via fab_propose
 ```
 
 After Step 2.2 completes (or hits the cap), update `.fabric/.import-state.json`: `phase = "P2-done"`, `last_checkpoint_at = <ISO8601 now>`.
 
 ## Dry-Run Mode
 
-When the user invocation carries the verbatim token `--dry-run`, Phase 2 runs WITHOUT calling `fab_extract_knowledge`. Instead it prints a table. v2.0.0-rc.37 NEW-10 dropped the legacy substring fallback on bare `dry-run` / `预览` because those caused false positives on incidental mentions ("preview the table" / "do a dry run later"). UX i18n Policy class 4 — header + column titles bilingualized; row content (slug / commit sha / doc path) NOT translated. Protected tokens `broad`, `relevance_scope`, `relevance_paths` appear verbatim:
+When the user invocation carries the verbatim token `--dry-run`, Phase 2 runs WITHOUT calling `fab_propose`. Instead it prints a table. v2.0.0-rc.37 NEW-10 dropped the legacy substring fallback on bare `dry-run` / `预览` because those caused false positives on incidental mentions ("preview the table" / "do a dry run later"). UX i18n Policy class 4 — header + column titles bilingualized; row content (slug / commit sha / doc path) NOT translated. Protected tokens `broad`, `relevance_scope`, `relevance_paths` appear verbatim:
 
 ### zh-CN variant (`fabric_language === "zh-CN"`)
 
@@ -200,14 +200,14 @@ When the user invocation carries the verbatim token `--dry-run`, Phase 2 runs WI
 | 3 | git 50367b5           | pitfalls  | thundering-herd-no-backoff    | broad+[] | Retries without exponential backoff caused a thundering herd outage. |
 ```
 
-Every dry-run row MUST show `broad+[]` in the Scope column (constant for fabric-import). A row showing anything else is a skill bug — refuse to proceed and surface the violation. Dry-run output is informational only. The state file is NOT written to in dry-run mode (so a real run later starts clean). Phase 3 is also skipped in dry-run.
+Every dry-run row MUST show `broad+[]` in the Scope column (constant for archive source mode). A row showing anything else is a skill bug — refuse to proceed and surface the violation. Dry-run output is informational only. The state file is NOT written to in dry-run mode (so a real run later starts clean). Phase 3 is also skipped in dry-run.
 
 ## Idempotency Note — T5 array form
 
-The server derives `idempotency_key = sha256({source_session, type, slug})` for every `fab_extract_knowledge` call. Re-invoking with the same `(source_session, type, slug)` triple is SAFE: the server appends new evidence to the existing pending file rather than overwriting or producing duplicates — this is why `fabric-import` resume after Ctrl-C / crash never produces duplicate pending entries for already-processed commits.
+The server derives `idempotency_key = sha256({source_session, type, slug})` for every `fab_propose` call. Re-invoking with the same `(source_session, type, slug)` triple is SAFE: the server appends new evidence to the existing pending file rather than overwriting or producing duplicates — this is why `archive source mode` resume after Ctrl-C / crash never produces duplicate pending entries for already-processed commits.
 
-**T5 array-form note (rc.7+)**: when `source_sessions` is passed as an array (rc.7 T5 contract), only `source_sessions[0]` participates in the server-side idempotency hash. Server formula at `packages/server/src/services/extract-knowledge.ts:78` is `sha256(JSON.stringify({source_session: sourceSessions[0], type, slug}))`. Implications for fabric-import:
+**T5 array-form note (rc.7+)**: when `source_sessions` is passed as an array (rc.7 T5 contract), only `source_sessions[0]` participates in the server-side idempotency hash. Server formula at `packages/server/src/services/extract-knowledge.ts:78` is `sha256(JSON.stringify({source_session: sourceSessions[0], type, slug}))`. Implications for archive source mode:
 
-- Every Phase 2 call uses `source_sessions: ["fabric-import-<ISO8601-date>"]` (single-element array, stable per import run). First-element-only rule means re-runs on the same date produce the same idempotency key per `(type, slug)` → resume-safe by construction.
-- If a future enhancement adds a trailing element (e.g. `["fabric-import-<date>", "<commit-sha>"]`), only the first element participates in the hash — the commit-sha tail would NOT change the idempotency key for the same `(type, slug)`. Plan accordingly.
+- Every Phase 2 call uses `source_sessions: ["fabric-archive-source-<ISO8601-date>"]` (single-element array, stable per import run). First-element-only rule means re-runs on the same date produce the same idempotency key per `(type, slug)` → resume-safe by construction.
+- If a future enhancement adds a trailing element (e.g. `["fabric-archive-source-<date>", "<commit-sha>"]`), only the first element participates in the hash — the commit-sha tail would NOT change the idempotency key for the same `(type, slug)`. Plan accordingly.
 - The formula is intentionally stable across the rc.5 → rc.7 migration; adding or removing tail entries does NOT change the idempotency key, preserving rc.5 single-session compat.

package/templates/skills/{fabric-import/ref/output-contract.md → fabric-archive/ref/source-output-contract.md}

@@ -13,7 +13,7 @@ UX i18n Policy class 1 — render either the en variant or the zh-CN variant per
 - Commits scanned: <N>     (skipped: <S> — cosmetic/metadata/baseline-overlap)
 - Docs scanned:    <D>     (skipped: <DS> — README/CHANGELOG/boilerplate)
 - Pending proposed: <P>     (cap_reached: <true|false>)
-- Scope: all <P> proposed entries use relevance_scope=broad, relevance_paths=[] (fabric-import contract).
+- Scope: all <P> proposed entries use relevance_scope=broad, relevance_paths=[] (archive source mode contract).
 
 ## Phase 3 — Dedup
 - Kept (genuinely new):       <K>
@@ -41,7 +41,7 @@ UX i18n Policy class 1 — render either the en variant or the zh-CN variant per
 - 扫描 commit 数: <N>      (跳过: <S> — cosmetic/metadata/与 baseline 重叠)
 - 扫描文档数:    <D>      (跳过: <DS> — README/CHANGELOG/样板文件)
 - 提议 pending:  <P>      (cap_reached: <true|false>)
-- 作用域: 全部 <P> 条提议使用 relevance_scope=broad, relevance_paths=[] (fabric-import 契约)。
+- 作用域: 全部 <P> 条提议使用 relevance_scope=broad, relevance_paths=[] (archive source mode 契约)。
 
 ## Phase 3 — 去重
 - 保留 (新知识):              <K>
@@ -52,7 +52,7 @@ UX i18n Policy class 1 — render either the en variant or the zh-CN variant per
 ## 状态
 - .fabric/.import-state.json phase: <phase>
 - last_checkpoint_at: <ISO8601>
-- 如 phase != complete, 请重新调用 fabric-import 续作。
+- 如 phase != complete, 请重新调用 archive source mode 续作。
 
 ## 下一步
 - 运行 `fabric-review` 审批 <K> 条新 pending。

package/templates/skills/{fabric-import/ref/state-recovery.md → fabric-archive/ref/source-state-recovery.md}

@@ -1,4 +1,4 @@
-# Phase 0 + 0.1 — State Recovery (fabric-import ref-only)
+# Phase 0 + 0.1 — State Recovery (archive source mode ref-only)
 
 > **Loaded on demand.** Only relevant when a prior import crashed mid-phase, leaving `.tmp-*` residue or a torn `.fabric/.import-state.json`. SKILL.md's hot path inline says "scan for .tmp residue + load state" — this file is the full recovery procedure (atomic-write pattern, sweep rules, corruption detection, fallback to fresh import).
 
@@ -46,7 +46,7 @@ On corruption (any condition above):
 1. `Bash: mv .fabric/.import-state.json .fabric/.import-state.json.corrupt-<ISO8601>`
    (preserve the corrupt file for postmortem; do NOT silently overwrite).
 2. Phase 1 restarts from scratch (Phase 1 produces no MCP calls, so re-run
-   is safe — re-querying mounted store canonical titles via `fab_review search`
+   is safe — re-querying mounted store canonical titles via `fab_pending search`
    idempotent; the `p1_baseline_titles` array is regenerated).
 3. DO NOT attempt automatic partial recovery; corrupt state is a signal
    that something serious happened (disk-full, kill -9 mid-write, fs

package/templates/skills/{fabric-import/ref/worked-examples.md → fabric-archive/ref/source-worked-examples.md}

@@ -8,11 +8,11 @@ Source signal: `git log` surfaces commit `50367b5` with subject `feat(server): a
 
 LLM analysis: this is a **pitfall** (a non-obvious trap that wasted time and is repeatable across services). The body itself documents the trap. Slug candidates: `retry-without-backoff-thundering-herd` (5 words, 38 chars — passes 5 rules).
 
-Skill output (note `relevance_scope: "broad"` + `relevance_paths: []` — mandatory for fabric-import):
+Skill output (note `relevance_scope: "broad"` + `relevance_paths: []` — mandatory for archive source mode):
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
-  source_sessions: ["fabric-import-2026-05-10"],
+mcp__fabric__fab_propose({
+  source_sessions: ["fabric-archive-source-2026-05-10"],
   recent_paths: ["packages/server/src/lib/retry.ts"],     // provenance only
   user_messages_summary: "重试无指数退避会在短暂上游故障下放大成雪崩。修正：jittered exponential backoff，30 秒上限。src=50367b5",
   type: "pitfalls",
@@ -29,7 +29,7 @@ Counter-example — DO NOT do this:
 ```ts
 // WRONG — this skill must never produce narrow + paths from git metadata.
 // The retry pitfall applies to every retry site, not just the file touched by 50367b5.
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   // ...
   relevance_scope: "narrow",                                // VIOLATION
   relevance_paths: ["packages/server/src/lib/retry.ts"]     // VIOLATION
@@ -57,8 +57,8 @@ LLM analysis: this is a **decision** (≥2 alternatives weighed — monolith vs
 Skill output (broad+[] mandatory; the doc's own path stays in `recent_paths` for provenance, NOT in `relevance_paths`):
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
-  source_sessions: ["fabric-import-2026-05-10"],
+mcp__fabric__fab_propose({
+  source_sessions: ["fabric-archive-source-2026-05-10"],
   recent_paths: ["docs/architecture.md"],                  // provenance only
   user_messages_summary: "选择单体架构而非微服务：3 人团队无法承担多服务运维成本，且主要性能瓶颈在 DB 吞吐而非应用层水平扩展。src=docs/architecture.md",
   type: "decisions",
@@ -73,7 +73,7 @@ mcp__fabric__fab_extract_knowledge({
 After Example A's pending entry (`retry-without-backoff-thundering-herd`) is proposed, Phase 3 runs:
 
 ```ts
-mcp__fabric__fab_review({
+mcp__fabric__fab_pending({
   action: "search",
   query: "retry backoff thundering herd",
   filters: { type: "pitfalls" }
@@ -105,7 +105,7 @@ Final roll-up to user reflects: 1 proposed, 0 kept, 1 rejected_dup, 0 merged, 0
 
 ## Example D — Post-import narrowing (out-of-band, NOT this skill)
 
-This example documents the legal narrowing path; it is NOT performed by `fabric-import` itself. After Example B's `monolith-over-microservices-small-team` decision is imported (with `relevance_scope=broad`, `relevance_paths=[]`) and later approved into canonical via `fabric-review`, the user decides the decision is actually narrow to the server package's deploy tooling.
+This example documents the legal narrowing path; it is NOT performed by `archive source mode` itself. After Example B's `monolith-over-microservices-small-team` decision is imported (with `relevance_scope=broad`, `relevance_paths=[]`) and later approved into canonical via `fabric-review`, the user decides the decision is actually narrow to the server package's deploy tooling.
 
 The user issues (via `fabric-review`, NOT via this skill):
 
@@ -122,6 +122,6 @@ mcp__fabric__fab_review({
 
 Key invariants of this flow:
 
-- The narrowing decision originates from the **user**, informed by the actual paths they propose — not from `fabric-import` inferring paths from git metadata.
-- The modify call goes through `fab_review`, not `fab_extract_knowledge`, because the entry already exists (post-import or post-approval).
+- The narrowing decision originates from the **user**, informed by the actual paths they propose — not from `archive source mode` inferring paths from git metadata.
+- The modify call goes through `fab_review`, not `fab_propose`, because the entry already exists (post-import or post-approval).
 - If the user later flips the entry's layer from `team` to `personal`, server-side auto-degrades scope back to `broad` and clears `relevance_paths` (see rc.5 C3 acceptance criterion; personal knowledge crosses projects so paths don't generalize). This is the only legal way for `relevance_paths` to be re-cleared.

package/templates/skills/fabric-archive/ref/worked-examples.md

@@ -11,7 +11,7 @@ Session: User and agent debated whether the Stop-hook should be one .cjs script
 Skill output:
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   source_sessions: ["WFS-2026-05-10-rc2"],
   recent_paths: ["templates/claude-hooks/", "packages/cli/src/commands/hooks.ts"],
   user_messages_summary: "User pushed back on three-script proposal; agreed single .cjs because stdout JSON shape is universal across Claude Code and Codex CLI.",
@@ -37,7 +37,7 @@ Session: deepMerge silently replaced the existing `hooks.Stop[]` array in `.clau
 Skill output:
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   source_sessions: ["WFS-2026-05-10-rc2"],
   recent_paths: ["packages/cli/src/config/json.ts"],
   user_messages_summary: "deepMerge default behavior REPLACES arrays. hooks.Stop[] needs an array-append-with-dedupe special case keyed on .command string match.",
@@ -60,7 +60,7 @@ Session: User mentioned across three projects that they prefer 2-space indent in
 Skill output:
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   source_sessions: ["WFS-2026-05-10-rc2"],
   recent_paths: [".editorconfig"],
   user_messages_summary: "Personal indent preference: 2-space TS / 4-space Py. Stable across multiple projects, not project-specific.",

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

@@ -1,7 +1,7 @@
 ---
 name: fabric-review
-description: 审 store-backed pending+canonical knowledge (NOT PR review):approve/reject/modify/revisit/defer。Triggers 审批/驳回/复审/重审/approve/reject/review pending.
-allowed-tools: Read, Glob, Grep, Bash, Edit, mcp__fabric__fab_review
+description: 审 store-backed pending+canonical knowledge (NOT PR review):pending triage + maintain(含 retire 语义淘汰 + relate 关联建边)。Triggers 审批/review pending;淘汰陈旧/deprecate;连接知识/补 related 边.
+allowed-tools: Read, Glob, Grep, Bash, Edit, mcp__fabric__fab_recall, mcp__fabric__fab_pending, mcp__fabric__fab_review
 ---
 
 > **Surface**: Skill (AI-driven, per-entry human-judgment routing). See [`docs/surfaces.md`](https://github.com/fenglimg/fabric/blob/main/docs/surfaces.md).
@@ -25,7 +25,7 @@ This skill is `Infer-not-Ask` for mode and `Ask-when-genuine` for per-item actio
 - Per-item action (approve / reject / modify / defer) IS surfaced via AskUserQuestion — the user must judge
 - Layer-flip target (team vs personal) IS surfaced via AskUserQuestion when modify includes layer change
 
-Required preconditions before any `fab_review` call: `.fabric/` exists; `mcp__fabric__fab_review` MCP tool registered; a write store is resolved for mutations; `.fabric/events.jsonl` exists (tolerate ENOENT — empty ledger normal first-run).
+Required preconditions before any `fab_review` / `fab_pending` call: `.fabric/` exists; `mcp__fabric__fab_review` (write) + `mcp__fabric__fab_pending` (read) MCP tools registered; a write store is resolved for mutations; `.fabric/events.jsonl` exists (tolerate ENOENT — empty ledger normal first-run).
 
 ### Config Load
 
@@ -42,13 +42,13 @@ Missing or unreadable → defaults silently.
 
 ### Store routing (v2.1 multi-store)
 
-Review iterates **per-store** — the read-set may span multiple stores (`fabric scope-explain team` → resolved `readSet.stores`). Pending/backlog is reported per-store (NOT aggregated into one undifferentiated pile); each candidate's provenance store is surfaced in cites as `KB: <store-alias>:<id>`. Promotion (draft → verified/proven) is a normal edit + git commit **inside that store's own repo** — no cross-store move. A `dismissed`/`modify` that flips layer between team and personal still goes through `AskUserQuestion`. Never read `~/.fabric` store trees directly; go through the MCP recall path / `scope-explain`.
+Review iterates **per-store** — the read-set may span multiple stores (`fabric info scope team` → resolved `readSet.stores`). Pending/backlog is reported per-store (NOT aggregated into one undifferentiated pile); each candidate's provenance store is surfaced in cites as `KB: <store-alias>:<id>`. Promotion (draft → verified/proven) is a normal edit + git commit **inside that store's own repo** — no cross-store move. A `dismissed`/`modify` that flips layer between team and personal still goes through `AskUserQuestion`. Never read `~/.fabric` store trees directly; go through the MCP recall path / `fabric info scope`.
 
 `Read ref/cite-contract.md` (v2.2 SK5) for the authoritative cite-contract reference — operator syntax, skip/dismissed reason dictionaries, type routing, audit semantics, backward-compat, and the adjudication ladder (AI-self → multi-LLM cold-eval → non-blocking queue) — sunk out of the bootstrap so cite/governance depth lives here, not in `.fabric/AGENTS.md`.
 
 ### UX i18n Policy
 
-Read `fabric_language` (`zh-CN` / `en` / `zh-CN-hybrid` / `match-existing`); emit user-facing prose in resolved variant. Protected tokens (`fab_review`, `fab_extract_knowledge`, `relevance_scope`, layer/scope enums, `stable_id`, the verbatim `强 team` / `强 personal` / `默认 team` block) NEVER translated. `AskUserQuestion` policy: `header` + `question` translate; `options[]` stay English (routing keys).
+Read `fabric_language` (`zh-CN` / `en` / `zh-CN-hybrid` / `match-existing`); emit user-facing prose in resolved variant. Protected tokens (`fab_review`, `fab_pending`, `fab_propose`, `relevance_scope`, layer/scope enums, `stable_id`, the verbatim `强 team` / `强 personal` / `默认 team` block) NEVER translated. `AskUserQuestion` policy: `header` + `question` translate; `options[]` stay English (routing keys).
 
 `Read ref/i18n-policy.md` for the full 5-class taxonomy + edge cases.
 
@@ -59,7 +59,7 @@ Read `fabric_language` (`zh-CN` / `en` / `zh-CN-hybrid` / `match-existing`); emi
 
 The skill MUST infer one of **2 modes** BEFORE any user-facing output (v2.0.0-rc.37 NEW-12 simplified 4 → 2):
 
-- **`pending`** — triage the write-side backlog returned by `fab_review action="list"` (`pending_path` identifies each store-backed entry): approve / reject / modify / defer per item. The dominant entry point.
+- **`pending`** — triage the write-side backlog returned by `fab_pending action="list"` (`pending_path` identifies each store-backed entry): approve / reject / modify / defer per item via `fab_review`. The dominant entry point.
 - **`maintain`** — sustain the EXISTING canonical KB: browse by topic (search), survey staleness/health, or revisit a specific entry. Merges the legacy `topic` + `health` + `revisit` modes — they are all "operate on already-canonical knowledge", distinct from triaging new drafts.
 
 ### 2-Step Inference Algorithm
@@ -69,11 +69,13 @@ The skill MUST infer one of **2 modes** BEFORE any user-facing output (v2.0.0-rc
 | Keywords (zh-CN + en) | Inferred mode |
 |---|---|
 | "approve", "review pending", "promote", "what's queued", "审核 pending", "通过" | `pending` |
-| "search/find about <topic>", "what's stale", "demote old", "health check", "look at <id>", "revisit KT-…", "关于…的知识", "过期的", "陈旧的", "整理一下", "再看下 <id>", "回顾" | `maintain` |
+| "search/find about <topic>", "what's stale", "demote old", "health check", "look at <id>", "revisit KT-…", "关于…的知识", "过期的", "陈旧的", "整理一下", "再看下 <id>", "回顾" | `maintain` (browse/health/revisit) |
+| "审计知识库", "清理陈旧知识", "知识库瘦身", "淘汰旧决策", "deprecate", "prune stale", "这些旧决策还要吗" | `maintain` → **retire** sub-flow |
+| "连接知识", "找相关条目", "补 related 边", "知识库连通性", "link related", "建知识图谱" | `maintain` → **relate** sub-flow |
 
 A `maintain`-row match → lock `maintain`. A `pending`-row match (or 0/ambiguous) → fall to Step 2.
 
-**Step 2 — Backlog default.** Call `fab_review action="list"` and inspect returned `items[].pending_path`:
+**Step 2 — Backlog default.** Call `fab_pending action="list"` and inspect returned `items[].pending_path`:
 
 - Count ≥ `review_hint_pending_count` (default 10) OR oldest mtime > `review_hint_pending_age_days` (default 7) → `pending` (overflow, same threshold as Stop-hook).
 - Otherwise → default `pending` (most common review entry point).
@@ -91,9 +93,11 @@ Each mode produces user-facing output, then routes per-item or per-batch decisio
   - `fab_review action="modify-layer"` — the dedicated layer-flip path (`changes.layer` required); may reallocate the stable_id + emit an id-redirect.
   - (Legacy `action="modify"` still works — it routes by whether `changes.layer` is present.) See `ref/modify-flow.md`.
 - **`maintain`** — sub-flow inferred from the same keywords:
-  - *browse-by-topic*: extract keywords → `fab_review action="search"` → render top-N (cap `review_topic_result_cap`) → AskUserQuestion only on an action verb.
-  - *health/staleness*: `fab_review action="list"` + tail events → compute stale → render dashboard → per-stale AskUserQuestion `{defer, demote, skip}`.
-  - *revisit*: user referenced a specific id/slug → `Read` canonical file directly OR `fab_review action="list"` with narrow filters → display body + history → AskUserQuestion only if actionable.
+  - *browse-by-topic*: extract keywords → `fab_pending action="search"` → render top-N (cap `review_topic_result_cap`) → AskUserQuestion only on an action verb.
+  - *health/staleness*: `fab_pending action="list"` + tail events → compute stale → render dashboard → per-stale AskUserQuestion `{defer, demote, skip}`.
+  - *revisit*: user referenced a specific id/slug → `Read` canonical file directly OR `fab_pending action="list"` with narrow filters → display body + history → AskUserQuestion only if actionable.
+  - *retire* (W3-C, 吸收原 fabric-audit): 语义淘汰陈旧/孤儿/被取代的 **canonical** 条目。引擎 `fabric doctor`(给 orphan/stale/health 信号);守两条红线 **deprecate-over-delete**(陈旧≠该删,降 maturity / 标 `superseded-by` 保留 rationale)+ **rescue-before-delete**(删前必做独特-rationale 抢救检查)。逐条判三态 still-valid / superseded(deprecate)/ never-valid(rescue 后删空壳),处置经 `fab_review` 写路径落盘。**完整两条红线定义 / 意图→动作映射 / 三态流程 / scope 纠偏 → `Read ref/retire-mode.md`。**
+  - *relate* (W3-C, 吸收原 fabric-connect): **默认不主动建边**,仅用户显式「连一下 / 补 related」时进入。`fab_recall` 拿候选 + 现有 `related` → 按互补/规避/取代/同域/引用链判**高置信**隐藏关联(稀疏优于稠密)→ 落盘**复用 `fab_review` modify 写路径**(零新写面,追加源条目 `related` 数组)。§4 隐私铁律 `KT→KP` FORBIDDEN。**关联类型判据表 / 流程 / 约束 → `Read ref/relate-mode.md`。**
 
 `Read ref/per-mode-flows.md` for full step-by-step procedures, bilingual rendering blocks (en + zh-CN per-item display, AskUserQuestion templates, health dashboard format), and the rc.7 T6 `proposed_reason` + `## Why proposed` + `## Session context` rendering contract.
 
@@ -101,7 +105,7 @@ Each mode produces user-facing output, then routes per-item or per-batch decisio
 
 > Boundary B (locked): "extraction / classification / layer / slug / mode / **semantic dedup** → Skill (LLM); file write / frontmatter / idempotency / counter / layer-flip / atomic promote → MCP (deterministic)"
 
-Semantic check is the LLM's job — the MCP tool does NOT compare meaning. Run during `pending` mode (and on demand during `topic`): for each pending entry, `fab_review action="search"` scoped by `filters.type` → LLM judges semantically against returned canonical entries → surface one of three flags as informational:
+Semantic check is the LLM's job — the MCP tool does NOT compare meaning. Run during `pending` mode (and on demand during `topic`): for each pending entry, `fab_pending action="search"` scoped by `filters.type` → LLM judges semantically against returned canonical entries → surface one of three flags as informational:
 
 - `⚠ Possible duplicate of <stable_id> (overlap: high)` — same essential claim
 - `⚠ Contradicts <stable_id> (overlap: high)` — opposing claims, same scope
@@ -135,7 +139,7 @@ Guideline/model entries surface in the SessionStart **ALWAYS-ACTIVE** sink as a
 - **Title/summary/tags/maturity** → in-place rewrite; stable_id PRESERVED.
 - **Layer change** → ONLY legal stable_id mutation. BEFORE call, AskUserQuestion `{team, personal}` to confirm target (this IS genuine choice). AFTER server returns, surface BOTH `prior_stable_id` and `new_stable_id` in roll-up — downstream agents may cache the prior id.
 
-**Import-origin entries** (`source_sessions[0]` starts with `fabric-import-`) ship with `relevance_scope=broad + relevance_paths=[]` by design; narrowing is fabric-review's responsibility. Render `⚠ Imported (relevance_scope=broad, relevance_paths=[]) — pick 'modify' + say 'narrow to <paths>'` as informational hint. On `modify` of import-origin: extended option list `{narrow scope, edit summary, change layer, change maturity, skip}`; "narrow scope" → free-text follow-up → `changes: { relevance_scope: "narrow", relevance_paths: [<parsed>] }`. Personal layer auto-degrades narrow → broad+[] (server-side), emitting `knowledge_scope_degraded`.
+**Source-mode entries** (`source_sessions[0]` starts with `fabric-archive-source-`) ship with `relevance_scope=broad + relevance_paths=[]` by design; narrowing is fabric-review's responsibility. Render `⚠ Imported (relevance_scope=broad, relevance_paths=[]) — pick 'modify' + say 'narrow to <paths>'` as informational hint. On `modify` of import-origin: extended option list `{narrow scope, edit summary, change layer, change maturity, skip}`; "narrow scope" → free-text follow-up → `changes: { relevance_scope: "narrow", relevance_paths: [<parsed>] }`. Personal layer auto-degrades narrow → broad+[] (server-side), emitting `knowledge_scope_degraded`.
 
 `Read ref/modify-flow.md` for layer-flip server transaction (4-step), modify call shape examples (maturity bump / layer flip), and full narrowing flow with bilingual AskUserQuestion templates.
 
@@ -180,11 +184,11 @@ Pending entry presented for review
 
 - NEVER write a knowledge file directly via Edit/Write/Bash; the only legal mutation path is `mcp__fabric__fab_review`.
 - NEVER call `git mv` from this skill — layer flip and slug rename are server-side transactions.
-- NEVER invent an `action` value — `action` MUST be one of {`list`, `approve`, `reject`, `modify`, `search`, `defer`}.
+- NEVER invent an `action` value — `fab_review action` MUST be one of {`approve`, `reject`, `modify`, `modify-content`, `modify-layer`, `defer`} (write-only); read actions {`list`, `search`} go through the read-only `fab_pending` tool.
 - NEVER batch heterogeneous decisions into a single MCP call. Approve and reject MAY be batched within their own action; modify MUST be one call per entry.
 - NEVER invoke `fab_review action="approve"` without at least one `pending_paths` entry.
 - NEVER infer a layer-flip target — the user MUST choose via AskUserQuestion.
-- MUST preserve protected tokens exactly: `stable_id`, `pending_path`, `layer`, `team`, `personal`, `knowledge_promoted`, `knowledge_layer_changed`, `knowledge_proposed`, `knowledge_scope_degraded`, `fab_review`, `MUST`, `NEVER`, `relevance_scope`, `relevance_paths`, `narrow`, `broad`, `proposed_reason`, `session_context`.
+- MUST preserve protected tokens exactly: `stable_id`, `pending_path`, `layer`, `team`, `personal`, `knowledge_promoted`, `knowledge_layer_changed`, `knowledge_proposed`, `knowledge_scope_degraded`, `fab_review`, `fab_pending`, `MUST`, `NEVER`, `relevance_scope`, `relevance_paths`, `narrow`, `broad`, `proposed_reason`, `session_context`.
 
 ## Output Contract & events.jsonl Constraint (ref-only)
 

package/templates/skills/fabric-review/ref/cite-contract.md

@@ -1,6 +1,6 @@
 # Cite-contract + 裁决阶梯参考 (v2.2 SK5)
 
-> 本文是 cite policy 与裁决(adjudication)的**权威详参**,从 bootstrap (`.fabric/AGENTS.md`) 下沉至此,避免 bootstrap 随治理细节膨胀。bootstrap 只留**可执行 core**(cite 行格式 + 验证义务 + operator 例),完整 enum 词典 / 类型路由 / 稽核 / backward-compat / 裁决阶梯看这里。`fabric doctor --cite-coverage` 的稽核口径以本文为准。
+> 本文是 cite policy 与裁决(adjudication)的**权威详参**,从 bootstrap (`.fabric/AGENTS.md`) 下沉至此,避免 bootstrap 随治理细节膨胀。bootstrap 只留**可执行 core**(cite 行格式 + 验证义务 + operator 例),完整 enum 词典 / 类型路由 / 稽核 / backward-compat / 裁决阶梯看这里。`fabric audit cite` 的稽核口径以本文为准。
 
 ## 1. Cite 行格式 (回顾)
 
@@ -42,7 +42,7 @@ cite 尾段加 contract:`→ <operator> [<operator> ...]`
 
 ## 5. 稽核 + Backward compat
 
-- 稽核:`fabric doctor --cite-coverage [--since=7d] [--client=cc|codex|all]` 输出覆盖率,含 `KB: none` sentinel 拆分。不阻断工作,只记录。
+- 稽核:`fabric audit cite [--since=7d] [--client=cc|codex|all]` 输出覆盖率,含 `KB: none` sentinel 拆分。不阻断工作,只记录。
 - Backward compat:解析器同时接受老 4-state tags(`planned` / `recalled` / `chained-from <id>`),都映射到 `[applied]` 语义;旧 session cite 仍计入 cite-coverage。
 
 ## 6. 裁决阶梯 (adjudication ladder)

package/templates/skills/fabric-review/ref/modify-flow.md

@@ -49,13 +49,25 @@ mcp__fabric__fab_review({
 
 ---
 
+## Promotion Gate — verified → proven (v2.2 C1)
+
+`maturity` promotion to `proven` is the foundational tier and runs a 3-part gate from `processes/maturity-promotion-rubric-v1`. The doctor `knowledge_broad_review_recheck`-adjacent `promotion_candidate` lint only SURFACES candidates (verified entries with `related` in-degree ≥3); the SUFFICIENT judgment lives here in review.
+
+Before issuing `fab_review modify ... { maturity: "proven" }`, satisfy all three:
+
+1. **0 dismiss (NECESSARY — server-enforced).** The server REFUSES the verified→proven modify when the entry carries an unresolved dismissed cite (latest `assistant_turn_observed` verdict for its id is `dismissed`, last-write-wins). You do NOT need to pre-check this — the modify throws with an actionable message. To clear it, the entry must be re-affirmed (a later `applied` cite) or the objection addressed. Do not work around the block; resolving it IS the gate.
+2. **guideline/model summary cold-eval (NECESSARY for those two types).** For `guidelines`/`models`, run the zero-context self-sufficiency judge before promoting: build the batch with `summary-cold-eval.buildColdEvalBatch([{stable_id, summary}])` + `COLD_EVAL_RUBRIC`, hand it to a `maestro delegate` cold judge (body WITHHELD), and only proceed if `self_sufficient=true`. A FAIL means the summary only points at the body — fix the summary (modify) first, then re-judge. (decisions/pitfalls/processes skip this — they are reference, not always-active rules.)
+3. **Foundational affirmation (SUFFICIENT — human).** Surface AskUserQuestion confirming the reviewer judges the entry "foundational / load-bearing", not merely correct. Promotion to proven is a standing-rule claim; the human makes it.
+
+Only after 1–3 hold, call `fab_review action="modify-content" changes={ maturity: "proven" }`. The modify itself stamps `last_review_confirmed_at` (every approve/modify is a review re-confirmation — this also resets the broad review-recheck clock).
+
 ## Narrowing Imported Entries
 
 The fabric-import skill creates pending entries with `relevance_scope=broad` + `relevance_paths=[]` as a deliberate contract — it cannot derive paths from git history. **Narrowing imported entries is fabric-review's responsibility.**
 
 ### Detection
 
-An entry is "import-origin" when `source_sessions[0]` starts with `fabric-import-` (e.g. `fabric-import-2026-05-10`).
+An entry is "import-origin" when `source_sessions[0]` starts with `fabric-archive-source-` (e.g. `fabric-archive-source-2026-05-10`).
 
 ### Pending mode rendering
 

package/templates/skills/fabric-review/ref/per-mode-flows.md

@@ -6,9 +6,9 @@ Full bilingual rendering blocks + step-by-step procedures for the four modes ref
 
 ## Mode: pending — Approve / Reject / Modify Backlog
 
-1. Call `fab_review` with `action: "list"`, no filters (or `filters.layer="both"` if user explicitly mentioned both layers).
+1. Call `fab_pending` with `action: "list"`, no filters (or `filters.layer="both"` if user explicitly mentioned both layers).
 2. Server returns `items[]` (each = `{pending_path, type, layer, maturity, tags?, title?, summary?}`).
-3. Before presenting, perform **Semantic Check** (see `ref/semantic-check.md`) by issuing one or more `action: "search"` calls scoped by `filters.type` to surface possible duplicates / contradictions among already-canonical entries.
+3. Before presenting, perform **Semantic Check** (see `ref/semantic-check.md`) by issuing one or more `fab_pending action="search"` calls scoped by `filters.type` to surface possible duplicates / contradictions among already-canonical entries.
 4. For each pending item, render a per-item block. v2.0.0-rc.7 T6: render `proposed_reason` (frontmatter) + `## Why proposed` line (body, 1-line enum explanation) + first line of `## Session context` so future-self has full context without re-reading the transcript. UX i18n Policy class 1 — roll-up templates; protected tokens (`pending_path`, `layer`, `team`, `decisions`, `proposed_reason`, `Tags`, etc.) appear verbatim in BOTH variants:
 
    **en variant** (`fabric_language === "en"`):
@@ -74,7 +74,7 @@ Full bilingual rendering blocks + step-by-step procedures for the four modes ref
 ## Mode: topic — Search & Surface Findings
 
 1. Extract the topic keyword(s) from the user's message (e.g. "find about deepMerge" → query="deepMerge").
-2. Call `fab_review action="search"` with `query` and any obvious filters (if user said "team-only" → `filters.layer="team"`).
+2. Call `fab_pending action="search"` with `query` and any obvious filters (if user said "team-only" → `filters.layer="team"`).
 3. Server returns `items[]` ranked by relevance — these are entries already in mounted store `knowledge/<type>/` (NOT pending), unless `filters` says otherwise.
 4. Render top-N (cap at `review_topic_result_cap`, config-resolved, default 8) results with title / summary / pending_path.
 5. If the user follow-up indicates intent to act ("approve all", "modify the second one"), pivot into the corresponding pending mode action — the search result already gives the `pending_path` needed for the action.
@@ -84,7 +84,7 @@ Full bilingual rendering blocks + step-by-step procedures for the four modes ref
 
 ## Mode: health — Corpus Health & Stale Detection
 
-1. Call `fab_review action="list"` with `filters.maturity="draft"` (or no filter for full corpus inspection).
+1. Call `fab_pending action="list"` with `filters.maturity="draft"` (or no filter for full corpus inspection).
 2. Tail `.fabric/events.jsonl` for layer_changed / demoted / rejected counts in the trailing 30 days.
 3. Compute stale candidates: pending entries with mtime older than `review_stale_pending_days` (config-resolved, default 14) OR maturity=draft entries with no recent evidence-append events.
 4. Render a corpus dashboard. UX i18n Policy class 1 — roll-up templates; render per `fabric_language`:
@@ -134,7 +134,7 @@ Full bilingual rendering blocks + step-by-step procedures for the four modes ref
 ## Mode: revisit — Specific Entry Deep Dive
 
 1. The user referenced a specific entry (by id `KT-D-7` or by slug `single-cjs-hook`).
-2. Call `fab_review action="list"` with `filters` narrowed by best-guess fields; if the entry is canonical (has stable_id), use the path returned by `fab_review` instead of inventing a store path.
+2. Call `fab_pending action="list"` with `filters` narrowed by best-guess fields; if the entry is canonical (has stable_id), use the path returned by `fab_pending` instead of inventing a store path.
 3. Display the full body (frontmatter + content). Tail the events.jsonl for any history events tagged with this stable_id.
 4. Surface AskUserQuestion `{options: ["approve", "modify", "reject", "skip"]}` only if the entry is still pending; for canonical entries the only mutation path is `modify` (incl. layer flip).
 

package/templates/skills/fabric-review/ref/relate-mode.md

@@ -0,0 +1,33 @@
+# Relate sub-flow — 知识图谱关联 (W3-C: 吸收原 fabric-connect)
+
+`maintain` 模式的 **relate** 子流程:把孤立的 canonical 条目连成图,发现彼此**隐藏关联**(同一决策的正反面、pitfall↔规避它的 guideline、被取代↔取代),回写 frontmatter 的 `related: [<stable_id>...]` 图边(v2.2 H2)。下游 `fab_recall include_related:true` 据此一跳拉回连通知识。
+
+`related` 是**有向引用**(A.related=[B] 表示「读 A 时也该看 B」),按需补反向边。
+
+**默认不主动建边**:仅用户显式说「连一下 / 找相关条目 / 补 related 边 / 知识库连通性」时进入;不在任何 nudge 里主动提议(避免噪声边稀释图价值)。检索时临时拉关联直接 `fab_recall include_related:true`,无需建边。
+
+## 关联类型(提议 related 边的判据)
+
+| 类型 | 例 |
+|---|---|
+| 互补 | decision「用 JWT」 ↔ pitfall「JWT 过期未刷新踩坑」 |
+| 规避 | pitfall「sprite 黑边」 ↔ guideline「premultiplyAlpha 正确设置」 |
+| 取代 | 旧 decision ↔ 取代它的新 decision(配合 deprecated/superseded-by) |
+| 同域 | 同一子系统 / 共 relevance_paths 的条目 |
+| 引用链 | A 的 rationale 依赖 B 的结论 |
+
+## 流程
+
+1. `fab_recall(paths=[...])` 拿候选 + 现有 `related`(读 description.related 看已连状态)。
+2. 对候选两两/成簇判隐藏关联(用上表判据);只提议**高置信**边,不为「话题相邻」乱连。
+3. 每条提议 = `(源 id, 目标 id, 类型, 一句理由)`;按需提议反向边。
+4. 落盘**复用既有 `fab_review` modify 写路径**(零新写面):在源条目 frontmatter 的 `related` inline 数组追加目标 stable_id;`fabric doctor --fix` reconcile 进 agents.meta。
+5. 回报新增/反向边数 + 连通性变化(孤岛减少)。
+
+## Constraints
+
+- 本子流程**只提议 + 经 `fab_review` modify 写路径落盘**;不自行改 store `knowledge/`,不手改 store counters(派生态)。
+- `related` MUST 只填**真实存在的 stable_id**(先 `fab_recall` 验证目标在库);NEVER 编造 / 指向 pending。
+- **稀疏优于稠密**:宁缺毋滥。只连高置信关联;低置信「相邻」不连(信噪比 > 覆盖率)。
+- 反向边按需补,不强制双向(有向语义:A 该带出 B ≠ B 该带出 A)。
+- **§4 隐私铁律**:`KT→KP` FORBIDDEN(team 条目 MUST NOT 指向 personal id);不确定目标是否 personal 时 OMIT 该边。

package/templates/skills/fabric-review/ref/retire-mode.md

@@ -0,0 +1,47 @@
+# Retire sub-flow — 语义淘汰 canonical 条目 (W3-C: 吸收原 fabric-audit)
+
+`maintain` 模式的 **retire** 子流程:把陈旧 / 孤儿 / 被取代的 **已 canonical** 条目按语义淘汰收口 —— 而不是一删了之。引擎是 `fabric doctor`(跑 lint、算 health、给 orphan/stale 信号);本子流程按用户意图挑动作,守两条红线,落盘仍走 `fab_review` 写路径(单一写路径,不自改 store `knowledge/`)。
+
+写新条目用 default archive;批量审 pending 用 `pending` 模式;retire 专管 **已归档条目的退役**。
+
+## 进入 retire 子流程
+
+`maintain` 关键词命中「审计 / 体检知识库」「清理陈旧知识」「这些旧决策还要吗」「知识库瘦身」「淘汰旧决策」「deprecate 条目」,或 doctor 报了 orphan/stale/低 health 想逐条处置时。
+
+## 两条红线(NON-NEGOTIABLE)
+
+1. **deprecate-over-delete**:陈旧 ≠ 该删。一条「当时为什么这么决策」的 decision/pitfall 即使方案已换,其 rationale 仍是知识。退役 = 降 maturity(proven→verified→draft)/ 标 `deprecated` + 记 `superseded-by`(保留正文),而非 `rm`。删除只用于「从未成立 / 纯噪声 / 重复」的条目。
+2. **rescue-before-delete**:任何 *打算删* 的条目,删前必做抢救检查 —— 它是否携带别处没有的独特 rationale / 反例 / 边界?有则先 merge 进取代它的条目(或在新条目加 `related` 边指回),再删空壳。抢救检查没做过,不许删。
+
+## 意图 → 动作映射
+
+| 意图 | 动作 |
+|---|---|
+| 体检 / 健康度 | `fabric doctor`(读 lint + health rollup);零阻断,只报告 |
+| 找孤儿 / 陈旧条目 | `fabric doctor`(消费 orphan / stale / orphan-demote 信号) |
+| 退役一条陈旧条目 | **不删** → 降 maturity 或标 deprecated + `superseded-by`;经 `fab_review` 落盘 |
+| 删一条「从未成立 / 重复」条目 | 先跑 rescue 检查(独特 rationale?有则 merge/加 related);确认空壳后才删 |
+| 被取代但有价值 | rescue:把独特 rationale merge 进取代条目,新条目加 `related` 边指回,再退役旧条目 |
+
+## 流程(逐条处置)
+
+1. `fabric doctor` 取 KB health + orphan/stale 候选清单(引擎给信号,不自算)。
+2. 对每个候选判 **三态**:still-valid(留) / superseded(退役,走 deprecate) / never-valid(删,走 rescue 检查)。
+3. superseded → deprecate:降 maturity 或标 deprecated + `superseded-by`,保留正文 rationale。
+4. never-valid → rescue-before-delete:独特知识?有则 merge + `related`,无则删空壳。
+5. 处置经 `fab_review` 写路径落盘(本子流程给决策,fab_review 做写入),保持单一写路径。
+
+## Scope re-assignment(迁移 / backfill 后纠偏)
+
+`fabric store migrate backfill` 给老条目补 `semantic_scope`,**默认把所有 team-layer 条目标成 `semantic_scope: team`** —— over-broad 的保守默认,会让项目专属知识错误暴露给所有项目。纠偏:
+
+- **team-scope 判定测试**:「换一个**没有本 app 代码**的不同 repo,这条知识还成立吗?」—— 成立才是 `team`。app **内部**跨功能 / 跨玩法复用的共享组件(同一 app 多处用)**≠ team**,仍是 `project:<id>`(跨玩法复用 ≠ 跨项目复用,如 VoiceRoom)。
+- **纠偏动作**:`fabric store migrate scope <store> --to project:<id> --id <id>`。
+- 完整判定树 / worked examples 见单一真源:`fabric-archive/ref/phase-3-7-semantic-scope.md`。
+
+## Constraints
+
+- 本子流程**只读 + 给处置建议**;实际写入(降级 / 标记 / 删)经 `fab_review` 写路径,不自行改 store `knowledge/`。
+- NEVER 绕过 rescue 检查直接删;删前 MUST 先跑抢救。删是最后手段,默认 deprecate。
+- store counters 派生态严禁手改;退役改的是 markdown frontmatter(maturity / deprecated / superseded-by),再 `fabric doctor --fix` reconcile。
+- health / orphan / stale 一律取自 `fabric doctor` JSON 输出,不在 skill 内重算(单一真源)。

package/templates/skills/fabric-review/ref/semantic-check.md

@@ -10,7 +10,7 @@ Semantic check is the LLM's job — the MCP tool does NOT compare meaning.
 
 For each pending entry to be presented:
 
-1. Call `fab_review action="search"` with `query=<title or summary keywords>` and `filters.type=<same type>` to fetch already-canonical entries of the same type.
+1. Call `fab_pending action="search"` with `query=<title or summary keywords>` and `filters.type=<same type>` to fetch already-canonical entries of the same type.
 2. Compare semantically (LLM judgment, not string match). 三类判断均为 LLM 主观判断 dup/subsumption；具体阈值不可量化（不使用百分比 / 相似度数值伪精度）：
    - **Duplicate** — same essential claim. 标题与摘要表达同一核心结论，pending 未提供新证据或新上下文。Flag: `⚠ Possible duplicate of <stable_id>`.
    - **Contradiction** — opposing claims about the same subject. 例：一个 entry 说 "use X"，pending 说 "avoid X"，且作用域一致。Flag: `⚠ Contradicts <stable_id>`.

package/templates/skills/fabric-review/ref/worked-examples.md

@@ -12,8 +12,8 @@ Inferred mode: `pending` (Step 1 keyword "review … pending").
 
 Skill flow:
 
-1. `fab_review action="list"` → returns 3 pending items.
-2. Semantic check on item 2 (`pending/decisions/single-cjs-hook.md`) — `fab_review action="search"` with `query="single cjs hook"` filter `type=decisions` returns canonical `KT-D-0007--single-cjs-hook-across-clients.md` (similarity high).
+1. `fab_pending action="list"` → returns 3 pending items.
+2. Semantic check on item 2 (`pending/decisions/single-cjs-hook.md`) — `fab_pending action="search"` with `query="single cjs hook"` filter `type=decisions` returns canonical `KT-D-0007--single-cjs-hook-across-clients.md` (similarity high).
 3. Display block:
 
    ```md
@@ -36,7 +36,7 @@ Inferred mode: `revisit` (Step 1 keyword "look at <id>").
 
 Skill flow:
 
-1. Read the canonical path returned by `fab_review search` for `KT-G-0003`. Display body to user.
+1. Read the canonical path returned by `fab_pending search` for `KT-G-0003`. Display body to user.
 2. AskUserQuestion `{options: ["approve", "modify", "reject", "skip"]}` — user picks `modify`.
 3. Skill detects user-stated intent "actually personal not team" — surface AskUserQuestion `{options: ["team", "personal"]}` with current layer=team noted; user confirms `personal`.
 4. Call:
@@ -60,7 +60,7 @@ Inferred mode: `health` (Step 1 keyword "stale").
 
 Skill flow:
 
-1. `fab_review action="list"` (no filter) + tail events.jsonl for trailing-30d demoted/layer_changed counts.
+1. `fab_pending action="list"` (no filter) + tail events.jsonl for trailing-30d demoted/layer_changed counts.
 2. Compute stale candidates: 3 pending entries with mtime >14d (KP-G-5 candidate-pending, KT-P-9 candidate-pending, KP-G-3 canonical draft with no evidence-append in 21d).
 3. Render dashboard then loop per stale item.
 4. Per-item AskUserQuestion fires:
@@ -74,7 +74,7 @@ Skill flow:
 User: "review the pending knowledge".
 
 Inferred mode: `pending`. Skill lists 5 pending entries; entry 3's frontmatter 
-shows `source_sessions[0] = "fabric-import-2026-05-10"` → import-origin.
+shows `source_sessions[0] = "fabric-archive-source-2026-05-10"` → import-origin.
 
 Display block prepends warning line. User picks `modify` on entry 3.
 AskUserQuestion fires with extended options including `narrow scope`.