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

package/templates/skills/fabric-archive/ref/phase-1-5-onboard.md

@@ -23,7 +23,7 @@ is the canonical taxonomy for this gate.
 |-------|--------|-------------------------------------------------------|
 | **E1** | `hook_passive` | stdout JSON `{decision:'block', ...}` from `fabric-hint.cjs` detected at skill entry (the Stop-hook reminder path). |
 | **E2** | `explicit_user_invoke` | User prompt is a direct invocation: `fabric archive` / `/fabric-archive` / `archive what we just did` / `归档一下` / similar imperative. |
-| **E3** | `ai_self_trigger` | AI internal marker `self-archive policy triggered by signal: <X>` present (substring match on the verbatim prefix `self-archive policy triggered by signal` per AGENTS.md self-archive policy section; `<X>` is the signal name. v2.0.0-rc.37 NEW-2 simplified the AGENTS.md taxonomy to 2 categories: `User-driven normative` / `Wrong-turn-and-revert`. Back-compat: legacy 4-state names (`Normative` / `Decision confirmation` / `Explicit dismissal`) still route correctly because the substring gate only matches the verbatim prefix and treats any text after `signal:` as the signal label.) |
+| **E3** | `ai_self_trigger` | DEFAULT else-branch: the AI invoked `fabric-archive` itself, following the AGENTS.md self-archive policy (a clear archival signal — `User-driven normative` or `Wrong-turn-and-revert` — surfaced this turn), AND none of the affirmative non-AI entry signals are present (no E1 hook `{decision:'block'}` block, no E2/E4 explicit user invocation, no E5 cron literal). v2.2 C1 W3b retired the AI-printed routing marker — E3 is now the deterministic else-branch, so routing no longer depends on the AI emitting an exact magic string (every other entry has its own non-AI affirmative detector; E3 is what remains). The signal category does not need to be conveyed to the skill — Phase 2.5's viability gate re-derives it independently. |
 | **E4** | `user_range_rollback` | Prompt contains a **range hint** (parsed in Phase 0 — e.g. `今日` / `上周` / `rc.20`) AND the user is invoking. Sub-mode of E2. |
 | **E5** | `cron` | Prompt contains literal `今日复盘` / `daily recap` / `daily-archive` AND no human is present (running under `/loop`, OS cron, or scheduled trigger). |
 
@@ -141,7 +141,7 @@ AskUserQuestion({
 })
 ```
 
-`fab_extract_knowledge` is called with `onboard_slot: <slot>` set so each
+`fab_propose` is called with `onboard_slot: <slot>` set so each
 proposed entry counts toward coverage once approved via fab_review.
 
 | User choice    | Action |
@@ -172,7 +172,7 @@ After Read-ing the slot-specific sources, classify the observation:
 - `build-system-idiom` → type=`processes`, `proposed_reason=new-dependency-or-pattern`
 - `domain-vocabulary` → type=`models`, `proposed_reason=new-dependency-or-pattern`
 
-Call `fab_extract_knowledge` with the inferred fields PLUS `onboard_slot:
+Call `fab_propose` with the inferred fields PLUS `onboard_slot:
 <slot>`. The pending file's frontmatter will carry the slot label, and the
 next `fabric onboard-coverage` run will see the slot as filled (once approved
 via fab_review).
@@ -180,7 +180,7 @@ via fab_review).
 Example:
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   source_sessions: ["<current-session-id>"],
   recent_paths: ["package.json", "tsconfig.json"],
   user_messages_summary: "Project uses TypeScript + pnpm workspace + Vitest. Node 20 LTS target. ESM-only.",
@@ -214,4 +214,4 @@ mcp__fabric__fab_extract_knowledge({
 - MUST emit `onboard_slot: <slot>` verbatim — the slot name is one of
   the locked S5 strings (tech-stack-decision / architecture-pattern /
   code-style-tone / build-system-idiom / domain-vocabulary). The
-  fab_extract_knowledge schema enum will reject anything else.
+  fab_propose schema enum will reject anything else.

package/templates/skills/fabric-archive/ref/phase-1-cross-session.md

@@ -35,7 +35,7 @@ Before Step 5 builds the cross-session context, drop sessions that the outcome l
 - **(e) Never attempted (no `session_archive_attempted` event found for this `session_id`) → keep.** First-time scan; nothing to filter against.
 - **(f) Cross-session pending dedupe** (operates on candidate observations, not on `session_id` filter): gather all `knowledge_proposed_ids` from `session_archive_attempted` events with `outcome === "proposed"` across ALL sessions in the recent window (NOT just the current candidate session). This builds a global set of idempotency keys already proposed by prior archive runs but not yet reviewed by the user (the active write store may still contain matching pending entries). When classifying new observations in Phase 3, drop any candidate whose computed `idempotency_key` matches an id already in this set — it was already proposed by an earlier archive run, the user just hasn't reviewed it yet, so re-proposing would duplicate pending entries and inflate `candidates_proposed` counts. Per Phase 4.5 dedupe consumer of `knowledge_proposed_ids`.
 
-The resulting filtered `session_id[]` proceeds into Step 5's digest concatenation. Sessions filtered out in this step do NOT contribute to `### Cross-session digest`, are NOT included in `source_sessions` on any fab_extract_knowledge call, and are NOT referenced in `session_context` bodies.
+The resulting filtered `session_id[]` proceeds into Step 5's digest concatenation. Sessions filtered out in this step do NOT contribute to `### Cross-session digest`, are NOT included in `source_sessions` on any fab_propose call, and are NOT referenced in `session_context` bodies.
 
 ### Constants (rc.25 — verbatim)
 
@@ -54,7 +54,7 @@ The resulting filtered `session_id[]` proceeds into Step 5's digest concatenatio
 Concatenate the loaded digests into a single `### Cross-session digest` block to carry into Phase 2.5 + Phase 1. Use this block to:
 
 - Detect session-spanning patterns (e.g. a discussion that started in session A and continued in session B).
-- Populate the `source_sessions` array on every fab_extract_knowledge call — the array form (T5) replaces the legacy `source_session` string.
+- Populate the `source_sessions` array on every fab_propose call — the array form (T5) replaces the legacy `source_session` string.
 - Inform the `session_context` blob written to each pending entry's body (3-5 lines summarizing goal + key turning point, per T6).
 
 ## Graceful degradation

package/templates/skills/fabric-archive/ref/phase-2-5-viability.md

@@ -36,7 +36,7 @@ These force the gate to FAIL **unless** an archive signal also fires (i.e. anti-
 1. **Typo-only edits** — the entire session is whitespace / spelling / formatting changes. No semantic content to archive.
 2. **Pure refactor** — rename / move / extract with no behavior change AND no naming convention being established.
 3. **Narrow rename request** — user asked to rename one symbol / file with no rationale. Zero generalization potential.
-4. **Duplicate of existing canonical** — v2.0.0-rc.37 NEW-4: this check is now **mandatory** (was "do a quick Glob before deciding"). Pre-PASS MUST step: for each candidate, call `fab_review action="search"` scoped by type/slug keywords so the MCP read path searches mounted stores. If duplicate found → drop candidate. Silently writing a near-duplicate is the highest-noise failure mode.
+4. **Duplicate of existing canonical** — v2.0.0-rc.37 NEW-4: this check is now **mandatory** (was "do a quick Glob before deciding"). Pre-PASS MUST step: for each candidate, call `fab_pending action="search"` scoped by type/slug keywords so the MCP read path searches mounted stores. If duplicate found → drop candidate. Silently writing a near-duplicate is the highest-noise failure mode.
 
 ## Gate-FAIL user messages (E2 / E4 only)
 

package/templates/skills/fabric-archive/ref/phase-3-5-scope.md

@@ -62,7 +62,7 @@ Step 5: SCOPE GATE
 
 Step 6: ATTACH evidence_paths to FRONTMATTER (rc.37 NEW-7 upgrade)
   Pass evidence_candidate_paths (from Step 2, post-blacklist Step 3) to
-  fab_extract_knowledge as the `evidence_paths` input field. Server writes
+  fab_propose as the `evidence_paths` input field. Server writes
   them to frontmatter `evidence_paths: [...]` (NOT to body `## Evidence`).
   This makes evidence consumable by plan-context retrieval as structured
   data instead of forcing markdown re-parsing every recall. The legacy

package/templates/skills/fabric-archive/ref/phase-3-6-related-edges.md

@@ -2,7 +2,7 @@
 
 For each candidate, identify the **`related`** graph edges to other KB entries — the store-qualified `stable_id`s this entry semantically links to (the decision it supersedes, the pitfall it explains, the model it instantiates). You discovered these ids during the session via `fab_recall` / plan-context, so cite the ones you actually saw, NEVER invent stable_ids.
 
-Because `fab_extract_knowledge` has no dedicated `related` input, record the candidate edges as one line inside `session_context` (e.g. `related: team:KT-DEC-0007, team:KT-PIT-0011`) so they survive to approve-time frontmatter authoring (`fabric-review` writes the canonical `related: [...]` frontmatter).
+Because `fab_propose` has no dedicated `related` input, record the candidate edges as one line inside `session_context` (e.g. `related: team:KT-DEC-0007, team:KT-PIT-0011`) so they survive to approve-time frontmatter authoring (`fabric-review` writes the canonical `related: [...]` frontmatter).
 
 ## §4 privacy iron law — KT→KP is FORBIDDEN
 

package/templates/skills/fabric-archive/ref/phase-3-classify.md

@@ -5,7 +5,7 @@
 ## Five Knowledge Types (verbose)
 
 - **model** — A reusable mental abstraction or domain object schema. Worth-archive signal: the user names something ("the X pattern", "the Y phase"). Skip-it signal: ad-hoc terminology used once. Positive: "Wave-1/Wave-2 task DAG decomposition for parallel-safe planning". Negative: "the thing we did just now" (too thin, no reusable abstraction).
-- **decision** — A choice between alternatives with rationale. Worth-archive signal: ≥2 options were weighed AND a rationale was given. Skip-it signal: the choice was forced by external constraint with no real alternative. Positive: "Single .cjs hook script over three per-client scripts — rationale: identical stdout JSON shape across Claude/Codex". Negative: "Used the existing fab_extract_knowledge schema" (no alternative was considered).
+- **decision** — A choice between alternatives with rationale. Worth-archive signal: ≥2 options were weighed AND a rationale was given. Skip-it signal: the choice was forced by external constraint with no real alternative. Positive: "Single .cjs hook script over three per-client scripts — rationale: identical stdout JSON shape across Claude/Codex". Negative: "Used the existing fab_propose schema" (no alternative was considered).
 - **guideline** — A normative rule for future similar situations. Worth-archive signal: the user said "always" / "never" / "from now on". Skip-it signal: a one-off preference that won't generalize. Positive: "Slug naming: kebab-case, 2-5 words, 20-40 chars, semantic core only". Negative: "Use 4-space indent in this one file" (too narrow).
 - **pitfall** — A trap that wasted time and is non-obvious. Worth-archive signal: a bug took >15 min to diagnose AND is repeatable. Skip-it signal: a typo or one-time API quirk. Positive: "deepMerge replaces arrays — hooks.Stop[] needs special-case append-with-dedupe". Negative: "Forgot a comma in JSON" (too obvious).
 - **process** — A multi-step procedure with a stable shape. Worth-archive signal: the steps were executed in a specific order AND the order matters. Skip-it signal: a one-shot script with no reusable structure. Positive: "fab_review approve = counter++ → frontmatter inject → git mv → meta rebuild → event append (5 atomic steps)". Negative: "Ran the tests, then committed" (trivial, no reusable shape).

package/templates/skills/fabric-archive/ref/phase-4-5-emit.md

@@ -25,7 +25,7 @@ For EACH `session_id` in the run's scope (multi-session E4 runs emit MULTIPLE ev
 
 | Skill terminal state                                                 | outcome              | candidates_proposed | knowledge_proposed_ids                          |
 |----------------------------------------------------------------------|----------------------|---------------------|-------------------------------------------------|
-| Phase 4 wrote ≥ 1 pending entry                                      | `proposed`           | N (count written)   | `[idempotency_key_1, idempotency_key_2, ...]` (from each fab_extract_knowledge response) |
+| Phase 4 wrote ≥ 1 pending entry                                      | `proposed`           | N (count written)   | `[idempotency_key_1, idempotency_key_2, ...]` (from each fab_propose response) |
 | Phase 2.5 viability_failed AND entry_point ∈ {E2_explicit, E4_user_range} AND user saw + accepted the gate-FAIL message | `viability_failed`   | 0                   | `[]`                                            |
 | Phase 3 batch review — user dismissed ALL presented candidates       | `user_dismissed`     | 0                   | `[]`                                            |
 | Phase 1 filter dropped every session in scope OR Phase 2.5 silent-skip path (E1_hook / E3_ai_self_trigger / E5_cron) | `skipped_no_signal`  | 0                   | `[]`                                            |

package/templates/skills/fabric-archive/ref/phase-4-mcp-persist.md

@@ -5,15 +5,16 @@
 ## Full MCP tool call shape
 
 ```ts
-mcp__fabric__fab_extract_knowledge({
+mcp__fabric__fab_propose({
   source_sessions: ["<session id1>", "<session id2>", ...],  // T5: array form (Phase 1)
   recent_paths: ["<path1>", "<path2>", ...],   // capped at archive_max_recent_paths (config-resolved, default 20)
   user_messages_summary: "<compact prose ≤500 chars>",
   type: "decisions" | "pitfalls" | "guidelines" | "models" | "processes",
   slug: "<kebab-case-2-to-5-words>",
-  layer: "team" | "personal",
-  relevance_scope: "narrow" | "broad",         // from Phase 3.5
-  relevance_paths: ["<glob1>", "<literal2>", ...],  // narrow ⇒ derived; broad ⇒ []
+  // v2.2 C1 (W1): author-facing scope is TWO fields only — `audience` + `paths`.
+  // The engine derives layer / visibility_store / store / relevance_scope.
+  audience: "team" | "personal" | "project:<id>" | "org:<...>",  // WHO it's for (open coordinate); omit → engine default (project:<active> | team)
+  paths: ["<glob1>", "<literal2>", ...],  // relevance anchors; non-empty ⇒ narrow, empty/omit ⇒ broad (relevance_scope is derived from this — no separate flag)
   // v2.0.0-rc.7 T6: required fields for future-self reviewability.
   proposed_reason:
     "explicit-user-mark"      // user said "always / never / 下次注意" etc.
@@ -78,7 +79,7 @@ The server returns `{ pending_path, idempotency_key }`. Display `pending_path` t
 
 ## Idempotency Notes (T5 array-form, rc.7+)
 
-The MCP tool derives `idempotency_key = sha256({source_session, type, slug})`. Calling `fab_extract_knowledge` twice 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. The skill MAY be re-invoked on the same session without producing junk.
+The MCP tool derives `idempotency_key = sha256({source_session, type, slug})`. Calling `fab_propose` twice 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. The skill MAY be re-invoked on the same session without producing junk.
 
 If the skill needs to record a genuinely separate observation in the same session+type, the slug MUST differ.
 

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

@@ -2,7 +2,7 @@
 
 > **Loaded on demand.** SKILL.md hot path retains a 2-line mention of the 2-step atomic write pattern + a pointer to this file. This file holds the full Atomic State Write rationale, events.jsonl 4KB constraint, complete schema, and resume-logic state machine.
 
-The state file lives at `.fabric/.import-state.json` and is the single source of resumability for fabric-import. It is written via the explicit 2-step atomic pattern documented below so a crash between phases / between sub-steps never corrupts it.
+The state file lives at `.fabric/.import-state.json` and is the single source of resumability for archive source mode. It is written via the explicit 2-step atomic pattern documented below so a crash between phases / between sub-steps never corrupts it.
 
 ## Atomic State Write (2-step pattern)
 
@@ -15,7 +15,7 @@ This 2-step pattern is mandatory for every state file update. `mv` is atomic on
 
 Crash safety expectations:
 
-- Crash between Step A and Step B → leaves `.fabric/.import-state.json.tmp`. Phase 0 residue scan (see `ref/state-recovery.md`) triages it on next invocation.
+- Crash between Step A and Step B → leaves `.fabric/.import-state.json.tmp`. Phase 0 residue scan (see `ref/source-state-recovery.md`) triages it on next invocation.
 - Crash during Step B (between the `rename` syscall start and return) → POSIX `rename` is atomic; either the prior `.import-state.json` is intact, or the new one is in place. No torn state.
 - Crash before Step A → no state mutation occurred; prior state file is unchanged.
 
@@ -82,4 +82,4 @@ On every skill invocation, BEFORE Phase 1 starts:
 5. If `phase === "P2-done"` → skip Phase 1 + Phase 2; resume from Phase 3 Step 3.1; iterate Phase 2 outputs skipping any pending_path already in `p3_dedup_completed[]`.
 6. After every successful sub-step (one commit processed, one doc processed, one dedup pair resolved), write the updated state file via the 2-step `.tmp` + `mv` pattern. Failures append to `errors[]` and proceed (or halt with prompt if cumulative errors `>5`).
 
-The contract: re-invoking fabric-import after ANY interruption (Ctrl-C, crash, network blip on MCP) MUST NOT propose duplicates of already-proposed entries and MUST NOT redo already-completed dedup decisions.
+The contract: re-invoking archive source mode after ANY interruption (Ctrl-C, crash, network blip on MCP) MUST NOT propose duplicates of already-proposed entries and MUST NOT redo already-completed dedup decisions.

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

@@ -2,14 +2,14 @@
 
 > **Loaded on demand.** SKILL.md hot path retains the Phase 3 purpose statement + 4-step outline + completion sentinel. This file holds the full Step 3.1/3.2/3.3/3.4 MCP call shapes, semantic compare 5-way classification, and the underseed sentinel rationale.
 
-For each pending entry created in Phase 2 (read from `p2_processed_commits[].pending_path` and `p2_processed_docs[].pending_paths`), check if it duplicates / contradicts / is subsumed by an existing canonical entry. **Semantic comparison is the LLM's job — `fab_review` does not compare meaning.**
+For each pending entry created in Phase 2 (read from `p2_processed_commits[].pending_path` and `p2_processed_docs[].pending_paths`), check if it duplicates / contradicts / is subsumed by an existing canonical entry. **Semantic comparison is the LLM's job — `fab_pending` does not compare meaning.**
 
 ## Step 3.1 — Search Canonical of Same Type
 
 For each just-proposed pending entry (read its frontmatter via the `Read` tool to get type + slug + title):
 
 ```ts
-mcp__fabric__fab_review({
+mcp__fabric__fab_pending({
   action: "search",
   query: "<title or summary keywords from the pending entry>",
   filters: { type: "<same type as pending>" }
@@ -25,7 +25,7 @@ For each `(pending, canonical)` pair the LLM judges:
 - **Duplicate** — same essential claim. LLM 主观判断：标题与摘要表达同一核心结论，新 pending 未提供新证据。具体阈值不可量化。Action: **reject** the new pending.
 - **Subsumption** (pending narrower) — canonical fully covers the pending plus more. Action: **reject** the new pending (canonical already serves).
 - **Subsumption-with-novelty** (pending adds evidence) — canonical covers the claim but the new pending brings new evidence (commit sha, file paths). Action: **modify** the canonical to merge in the new evidence; **reject** the new pending citing the modified canonical.
-- **Contradiction** — opposing claims about the same scope. Action: leave pending; flag for user via roll-up. The user must decide via `fabric-review` later — `fabric-import` does NOT auto-resolve contradictions.
+- **Contradiction** — opposing claims about the same scope. Action: leave pending; flag for user via roll-up. The user must decide via `fabric-review` later — `archive source mode` does NOT auto-resolve contradictions.
 - **Genuinely new** — no canonical match. Action: leave pending in place (will surface in next `fabric-review` run for normal approval flow).
 
 ## Step 3.3 — Issue Dedup MCP Calls
@@ -68,7 +68,7 @@ Append to `.fabric/.import-state.json` after EACH successful MCP call:
 After all Phase 2 outputs are dedup-reviewed:
 
 - Update `.fabric/.import-state.json`: `phase = "complete"`, `last_checkpoint_at = <ISO8601 now>`, `final_summary = {proposed: N, kept: K, rejected_dup: R, merged: M, contradictions_flagged: C}`.
-- Render the final roll-up to the user (see Output Contract — see `ref/output-contract.md`).
+- Render the final roll-up to the user (see Output Contract — see `ref/source-output-contract.md`).
 
 > Setting `phase = "complete"` in `.fabric/.import-state.json` is enough to silence the SessionStart underseed self-check banner (`shouldRecommendImport()` returns false for any non-`absent` state). 无需额外清理 sentinel 文件 — 该机制已在 rc.8 下线。
 

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.",