Leo/kbdb-ingest-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: template 1.9.x 知識庫遷移 → system-dev/

Browse Source 
把 system-dev-template 1.9.x 的知識庫基建搬進 git（從功能 PR 拆出，獨立成筆）：
- system-dev/wiki/：LLM 記憶系統（principles 鐵律 + 5 張 ingest 卡 + INDEX/TAXONOMY + status/mistakes）
- system-dev/docs/：SDD 新家（3-specs/ + 2-architecture/ + README/SKILL）；ingest-pipeline SDD 從 docs/3-specs/ 搬來
- system-dev/scripts/：install/update
- .claude/：wiki/SDD harness（commands + hooks：session-recall / sdd-guard / wiki-secret-scan）

SDD 位置統一：docs/3-specs/ingest-pipeline → system-dev/docs/3-specs/ingest-pipeline
（對齊 SDD guard hook 預期路徑 + template 1.9.x 規約）。

純基建遷移，不含任何功能程式碼（src/tests/contracts 在功能 PR #3）。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
richblack
2026-06-26 20:45:18 +08:00
parent dffefdcdc2
commit 06e901f590
36 changed files with 2635 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
system-dev/docs/2-architecture/decisions/TEMPLATE-adr.md
+30
View File
@@ -0,0 +1,30 @@
# [主題] — Architecture Decision Record
> 日期：[YYYY-MM-DD]
> 狀態：[提議中 / 已採納 / 已廢棄]
> 影響範圍：[哪些子系統 / 模組]
---
## 背景
[遇到了什麼問題，需要做這個決定？]
## 決定
**[結論，一句話。]**
## 原因
[詳細說明為什麼這樣決定。]
## 放棄的選項
| 選項 | 放棄原因 |
|------|---------|
| [選項 A] | [原因] |
| [選項 B] | [原因] |
## 影響與後續
[這個決定影響哪些地方？有什麼技術債或需要注意的事？]
system-dev/docs/3-specs/TEMPLATE-sdd/design.md
+76
View File
@@ -0,0 +1,76 @@
# [子系統名稱] — Design
> 狀態：[草稿 / 審核中 / 已採納 / 已廢棄]
> 建立：[YYYY-MM-DD] | 最後更新：[YYYY-MM-DD]
> 負責人：[名稱]
---
## 一句話說明
[這個子系統做什麼，一句話。]
---
## 背景與問題
[為什麼需要這個子系統？解決了什麼問題？]
---
## 範圍
### 包含（In Scope）
- [這個 SDD 涵蓋的功能]
### 不包含（Out of Scope）
- [明確排除的功能，避免 CC 自行延伸]
---
## 設計
### 架構概覽
[用文字或 ASCII 描述系統結構]
```
[元件 A] → [元件 B] → [元件 C]
```
### 關鍵決策
| 決策 | 選擇 | 原因 | 放棄的選項 |
|------|------|------|----------|
| [問題] | [選擇] | [原因] | [其他選項] |
### API / 介面定義
[端點、資料格式、輸入輸出規格]
### 資料模型
[資料結構、欄位說明]
---
## 技術限制
- [不能用什麼]
- [必須相容什麼]
- [效能要求]
---
## 驗收標準
完成的定義（CC 完成任何 task 前必須確認）：
- [ ] [可客觀驗證的條件，例如：POST /api/xxx 回傳 200]
- [ ] [...]
---
## 相關文件
- [連結到相關 ADR]
- [連結到相關 SDD]
system-dev/docs/3-specs/TEMPLATE-sdd/tasks.md
+50
View File
@@ -0,0 +1,50 @@
# [子系統名稱] — Tasks
> 權威來源：此檔案是進度真相，不是 CLAUDE.md 或對話。
> 規則：動手前標 [🔄]，完成立刻標 [x]，不批次更新。
---
## Phase 1：[Phase 名稱]
### 前置條件
- [ ] [這個 Phase 開始前必須完成的事]
### Tasks
- [ ] 1.1 [task 描述]
- 驗收：[客觀可驗證的完成標準]
- 注意：[CC 容易犯的錯，可選]
- [ ] 1.2 [task 描述]
- 驗收：[...]
---
## Phase 2：[Phase 名稱]
> 前置條件：Phase 1 全部完成
- [ ] 2.1 [task 描述]
- 驗收：[...]
---
## 完成定義
整個 SDD 完成 = 以下全部達成：
- [ ] 所有 tasks 標 [x]
- [ ] 驗收標準通過（有客觀證據）
- [ ] design.md 與實作一致（如有出入需更新）
---
## 狀態說明
| 標記 | 意義 |
|------|------|
| `[ ]` | 未開始 |
| `[🔄]` | 進行中（當前 session）|
| `[x]` | 完成（有驗收證據）|
| `[~]` | 暫緩（說明原因）|
| `[!]` | 阻擋中（說明阻擋原因）|
system-dev/docs/3-specs/ingest-pipeline/design.md
+38
View File
@@ -0,0 +1,38 @@
# ingest pipeline — Design
> 對應 requirements.md。**架構設計（envelope 契約、職責切割、normalize 歸屬、MCP 邊界、模型策略）在 InkStoneCo `docs/3-specs/mira-dissolve/design.md`。本檔只放 ingest 內部設計。**
## 1. 資料流
```
GitHub repo MD（精耕 LLM Wiki）
│ commit / content-hash 變動
▼
SourceAdapter（拉 + content-hash）
│
├─ 路徑 A：本地已建三元組+gloss → 採取（拉）
└─ 路徑 B：裸原文 → extract(text, model) → 候選 (s,p,o)+gloss
│
▼ 跨 repo 匯總（織跨庫關聯）
▼ POST envelope（contracts/ingest-candidate.json）
graph 寫入端 POST /triplets/ingest
```
## 2. envelope（= contracts/ingest-candidate.json）
形狀與職責切割見 InkStoneCo design §3。ingest 給：原始 s/p/o + source.* + extractor.* + nodes[].gloss/type + confidence。**禁送**：id / clusters / bridge_score / 時間戳 / 邊上 type（graph 算）。
## 3. extract 模型策略
見 InkStoneCo design §6.6：用戶選意圖非型號、品質門檻白名單（深層暗示+中文）、預設 Haiku、深萃 Claude via CC、難度隨來源分層（AI 報告弱模型夠/人類 vault 須好模型）。
## 4. 觸發
被 KBDB MCP `refresh` 代轉（人發起，非自動 fan-out）。flag 紅線見 InkStoneCo design §6.7：禁 Actions/webhook 自動觸發。
## 5. cherry-pick 來源
- `polaris/mira/tools/_kbdb_client.py` → 純餵食器 client。
- `polaris/mira/arcrun/wiki_synthesis.yaml` classify 節點 → extract。
- 兩個 KBDB skill block（精耕規則 prompt）。
詳 InkStoneCo requirements §6。
system-dev/docs/3-specs/ingest-pipeline/requirements.md
+27
View File
@@ -0,0 +1,27 @@
# ingest pipeline — Requirements
> 建立：2026-06-26
> **跨專案藍圖在 InkStoneCo `docs/3-specs/mira-dissolve/`（R7 攝入分工、§6.6 模型策略、§6.7 MCP 邊界）。本 SDD 只放 ingest 內部實作細節。**
> 凍結契約：`contracts/ingest-candidate.json`（與 graph repo 同一份，唯一耦合面）。
## 範圍
ingest 插件內部：SourceAdapter（拉）+ 採取/extract + 跨庫織網匯總 + POST envelope 給 graph。**不涉**graph 內部圖演算法、不涉 base 儲存。
## 需求
- **R1 SourceAdapter**：GitHub 拉 repo + content-hash（`source.uri = github:owner/repo@path`）。webhook/排程觸發，或被 KBDB MCP `refresh` 代轉觸發。
- **R2 採取（路徑 A，優先）**：用了 system-dev-template 的 repo → 本地 CC 已建三元組 + gloss → ingest 拉取，不重萃。
- **R3 extract（路徑 B，fallback）**：裸原文 → 萃 (s,p,o)+gloss。模型用戶可選（意圖非型號）+ 品質門檻白名單（深層暗示 + 中文）；預設 Haiku；深萃 Claude via CC；JSON-fail 升級閘。
- **R4 跨 repo 織網**：匯總多 repo 三元組（單 repo 看不到的橋/異見）＝主職。
- **R5 輸出**：POST envelope（嚴格符合 contract）給 graph `POST /triplets/ingest`，不直連 base。
- **R6 ops CLI**：手動觸發重萃。不帶查詢 MCP。
## 約束（沿用 ingest 鐵律，見 CLAUDE.md）
- 純餵食器、不碰儲存、不算向量、不帶查詢 MCP、部署繞 Actions、三守則（無環/純 API/凍結契約）。
## 待對端
- graph 的 `POST /triplets/ingest` 寫入端（InkStoneCo T3.3，graph repo 實作）。
- 模型品質門檻測試集（含中文 + 人類暗示樣本，InkStoneCo §6.6）。
system-dev/docs/3-specs/ingest-pipeline/tasks.md
+48
View File
@@ -0,0 +1,48 @@
# ingest pipeline — Tasks
> 唯一進度來源。狀態：[ ] 未開始　[🔄] 進行中　[x] 完成　[⏸] 卡住
> 跨專案藍圖：InkStoneCo `docs/3-specs/mira-dissolve/`。
> 實作分支：`claude/ingest-t1-t5-implementation`（vitest 28 passed / tsc clean / dry-run 乾淨）。
## T0 repo 骨架
- [x] 0.1 建 public repo `uncle6me-web/kbdb-ingest-plugin`
- [x] 0.2 CLAUDE.md（上游指針 + ingest 鐵律）+ README + .gitignore
- [x] 0.3 `contracts/ingest-candidate.json`（從頂層 SDD 複製，凍結契約）
- [x] 0.4 SDD 三件式骨架（本輪搬到 `system-dev/docs/3-specs/`，對齊 SDD guard hook）
- [x] 0.5 package.json / tsconfig / wrangler.toml / vitest.config（參考 kbdb-graph-plugin：Hono + zod-openapi，無 D1/Vectorize/AI 綁定）
## T1 SourceAdapter（R1）— `src/lib/source-adapter.ts`
- [x] 1.1 GitHub 拉 repo（runtime git/trees + contents API，非 Actions）；GitHubFetcher 介面（測試走 mock）
- [x] 1.2 content-hash（per-file sha256；source.uri = github:owner/repo@path，makeSourceUri/parseSourceUri round-trip）
- [x] 1.3 被 graph `POST /graph/refresh` 代轉觸發的受理端：`POST /refresh`（`src/index.ts`，被動代轉、無排程）
## T2 採取（R2，路徑 A 優先）— `src/lib/harvest.ts`
- [x] 2.1 採取本地 CC 已建三元組 + gloss（template 1.8.0+ 格式：frontmatter gloss、`## 實體`、`## 關聯` typed-edge；卡對卡 vs 內文端點分流）
- [x] 2.2 cherry-pick `_kbdb_client.py` → 改純餵食器 `src/lib/graph-client.ts`（POST envelope，**不寫 KBDB/base**）
## T3 extract（R3，路徑 B fallback）— `src/lib/extract.ts`
- [x] 3.1 cherry-pick `wiki_synthesis.yaml` classify 模式 → extract prompt（JSON nodes[]+triplets[]）
- [x] 3.2 模型用戶可選（意圖非型號，LlmCaller 介面，預設 shallow/Haiku、deep/Claude via CC）
- [ ] 3.3 模型測試集（中文 + 人類暗示樣本，轉回歸測試）— **deferred**（先跑預設；護欄 + parse 已有單元測試）
- [x] 3.4 JSON-fail 升級閘（淺萃 fail/過稀 → 升 deep 一次）
- [x] 3.5 第一版不 embed（仍【打標】embed/predicate_embed 供未來 base 讀標；embed 動作等 Arcrun #7）
- [x] 3.x 端點對齊硬自檢護欄（`src/lib/endpoint-check.ts`，leo 壓測 14→0；自檢 + autoAlign 補齊）
## T4 跨 repo 織網（R4，主職）— `src/lib/weave.ts`
- [x] 4.1 匯總多 repo 三元組 → 偵測跨庫橋（同名 node 跨 ≥2 repo）+ 異見（同 s/o 對、不同謂詞）；**不算 bridge_score**（graph 領域，禁送）
## T5 輸出 + CLI（R5/R6）
- [x] 5.1 POST envelope 給 graph `POST /triplets/ingest`（嚴格符合 contract；buildEnvelope strict + 顯式禁送欄位自檢提早攔）。對齊【full contract】（含 embed/id/aliases/predicate_embed，總管裁定 ingest 不退）
- [x] 5.2 薄 ops CLI（`scripts/ingest-cli.mjs`：refresh 經 Worker / pull dry-run）；**不帶查詢 MCP**
## 阻擋項 / 誠實標記
1. ⏸ **端到端 ingest→graph 走通**：依賴 graph receiver 補對齊 full contract（graph#1 補對齊任務，**現 .strict() 會 422 新向量化欄位**）+ ingest 部署 + `GRAPH_BASE_URL` 設定 → **待部署驗**，未假綠。
2. ⏸ embed 依賴 base vectorize（Arcrun #7）。第一版不 embed（只打標）已動。
3. T3.3 模型測試集 deferred；refresh 端 extract（Workers AI）第一版只走採取，深萃留 CLI/CC。
system-dev/docs/README.md
+56
View File
@@ -0,0 +1,56 @@
# 文件分類索引
> CC 整理文件時的分類依據。找不到分類就問，不要猜。
---
## 分類規則
| 目錄 | 放什麼 | 判斷標準 |
|------|--------|---------|
| **1-vision/** | 為什麼做這個 | 產品願景、北極星、設計哲學 |
| **2-architecture/** | 系統怎麼設計的 | 架構圖、技術棧、元件關係 |
| **2-architecture/decisions/** | 為什麼這樣設計 | ADR，選A不選B的原因 |
| **3-specs/** | 要做什麼 | SDD，每個子系統一個目錄 |
| **4-guides/** | 怎麼做 | 部署、開發流程、CLI 用法 |
| **5-records/** | 發生過什麼 | 歷史記錄，不修改只增加 |
| **5-records/incidents/** | 生產問題復盤 | 故障原因、時間線、改進方案 |
| **5-records/test-reports/** | 測試結果 | 壓測報告、驗收記錄 |
| **6-user/** | 給使用者看的 | README、安裝教學、FAQ |
---
## CC 整理文件時的判斷流程
```
這個文件是...
├── 有明確子系統 + 設計內容？ → docs/3-specs/[子系統]/
├── 解釋為什麼做某個決定？ → docs/2-architecture/decisions/
├── 說明怎麼操作？ → docs/4-guides/
├── 記錄發生過的事？ → docs/5-records/
├── 給外部使用者看的？ → docs/6-user/
└── 以上都不確定？ → 列為「待確認」，問負責人
```
---
## SDD 結構（docs/3-specs/ 下每個子系統）
```
docs/3-specs/[子系統名]/
├── design.md ← 設計文件（要做什麼、怎麼做、邊界在哪）
└── tasks.md ← 任務清單（[ ] 未開始 [🔄] 進行中 [x] 完成）
```
CC 動手前必須有這兩個檔案。找不到就停手。
---
## .claude/wiki/ — CC 的記憶空間（CC 維護，人不手動編輯）
| 檔案 | 用途 | 更新時機 |
|------|------|---------|
| `INDEX.md` | wiki 導引 | 新增 wiki 檔案時 |
| `mistakes.md` | CC 已知誤解 + 避坑 | 每次被糾正後 |
| `status.md` | 當前進度 + 下一步 | 每次 session 結束 |
| `decisions-summary.md` | 架構決策摘要 | 重大決策後 |
system-dev/docs/SKILL.md
+260
View File
@@ -0,0 +1,260 @@
---
name: wiki-cowork-scan
description: "掃描本機 Documents 下所有裝了 system-dev-template 的資料夾，自動整理 LLM Wiki。支援一般專案、Logseq vault、Obsidian vault 三種結構，偵測方式與 install.sh 一致。觸發時機：使用者說「整理 wiki」「幫我掃 wiki」「更新我的 wiki」「wiki 掃描」，或 Cowork cron 定期觸發。"
---
# Wiki Cowork Scan
## 核心原則
這個 skill 與 Claude Code 的 `/wiki-init` `/wiki-capture` 共用同一套規則：
| 層 | 規則 |
|------------|-------------------------------------------|
| raw source | 只讀，不動 |
| `system-dev/wiki/` | 唯一輸出地點，只增不覆 |
| `CLAUDE.md` | 不動 |
| `logseq/`、`.obsidian/`、`assets/` | 絕對不動 |
**CC 和 Cowork 輸出格式相同，任何一方整理過的內容，另一方看到就跳過或補充，不覆蓋。**
---
## 第一步：發現所有目標資料夾
掃描 `~/Documents`（遞迴深度 3 層），找出所有含 `system-dev/wiki/` 的資料夾。
```
~/Documents/
project-a/system-dev/wiki/ ← ✅ 目標
Logseq/system-dev/wiki/ ← ✅ 目標
其他資料夾/ ← ❌ 跳過
```
找到後列出清單，告訴使用者：「找到 N 個 wiki 資料夾，開始整理。」
---
## 第二步：對每個資料夾偵測 vault 類型
進入每個目標資料夾的**根目錄**（`system-dev/wiki/` 的上兩層），依序判斷：
### 判斷順序（與 install.sh 一致）
```
if 根目錄有 logseq/ 資料夾
→ vault 類型：Logseq
→ raw source：pages/、journals/
→ 忽略：logseq/、assets/
else if 根目錄有 .obsidian/ 資料夾
→ vault 類型：Obsidian
→ raw source：根目錄下所有 .md（排除 .obsidian/ 內的檔案）
else
→ vault 類型：一般專案
→ raw source：docs/ 下所有 .md
```
---
## 第三步：讀取現有 wiki 狀態
進入 `system-dev/wiki/`，讀取：
- `INDEX.md`：目前已有哪些 wiki 頁面（多角度視圖入口）
- `status.md`：上次整理時間、進度
- `principles.md`（如果有）：本專案跨全局的設計原則——整理時必須服從
目的：**知道哪些已整理過，只處理新增或有變動的 raw source**，不重複整理。
---
## 第四步：整理規則
### 核心判準：push vs pull（wiki 是給 AI 看的）
整理任何內容前，先判斷它該進 **push 檔** 還 **cards（pull）**——判準是「**CC 做事時會不會被動看見**」：
- **push 檔**（`status.md` / `mistakes.md` / `principles.md`）：CC session 開始就被 hook 注入。給「CC 不會主動查、但不看就出事」的東西。
- **pull**（`cards/`）：CC 想到要查才看見。一切知識內容（原文摘要、AI 筆記、決策、概念…）都寫成 cards。
| 內容 | 去哪 | 理由 |
|------|------|------|
| 當前進度、下一步 | `status.md`（push 全文） | 時態狀態，不看會重做 |
| 跨全局設計原則（一行一條，≤15） | `principles.md`（push 全文） | 會被遺忘的盲區，CC 設計時必服從 |
| 踩坑、被糾正的誤解 | `mistakes.md`（push 摘要+按需展開） | 防 CC 不自覺的盲區 |
| 決策、原文摘要、概念知識、其餘一切 | `cards/<bucket>/`（pull） | 知識內容；CC 面對時自然會查 |
> `decisions-summary.md` 已**降級為 cards + INDEX 決策視圖**（決策＝知識內容）。既有的保留為相容，不刪。
> CC 與 Cowork **共用此判準**，產出一致：任一方寫進 push 檔或 cards，另一方看到就跳過或補充，不覆蓋。
### 讀 raw source
逐一讀取 raw source 的 `.md` 檔。跳過：
- 檔名以 `.` 開頭的隱藏檔
- `.wikiignore` 裡列出的 glob pattern（如果存在）
- 含有 `<!-- wiki:ignore -->` 標記的區段
### 整理邏輯
每個 raw source 檔案，判斷：
1. **INDEX.md 裡已有對應條目，且 raw source 未修改** → 跳過
2. **INDEX.md 裡已有條目，但 raw source 有新內容** → 更新對應 wiki 頁面，補充新資訊，不刪舊內容
3. **INDEX.md 裡沒有對應條目** → 新建 wiki 頁面
### Wiki 卡片格式（概念原子卡，存到 `cards/<bucket>/`）
```markdown
---
tags: [知識管理, AI協作, 方法論]
gloss: 一句話定義這個概念是什麼（給下游語義 normalize 用，選填、deep tier 才產）
---
# 概念全名
← [[<bucket>/00-INDEX]]
**來源**：`[raw source 相對路徑]`
**最後更新**：YYYY-MM-DD
## 摘要
[一句話核心]
## 重點
- [自包含改寫的要點，不寫「詳見原文」]
## 實體
> 本卡內文的關鍵實體（也是 graph node）。名＋描述一起供下游 embedding normalize。
> AI 生產、人不必讀；集中放、一實體一行、不縮排、不重複。
- **原子筆記**（atomic note／卡片原子化）— 每張卡只承載一個不可再分論點的知識記錄單元。
- **傳統筆記**（大鍋炒筆記）— 把多主題混雜在同一篇、難精確引用的記錄方式。
## 關聯
### 內文知識關係（內文實體間；端點＝上方 `## 實體` 的正規名，一字不差）
- 原子筆記 >> 對立於 >> 傳統筆記
- 傳統筆記 >> 犧牲 >> 精確引用
### 卡片關係（卡對卡）
- [[本卡]] >> 謂詞（動詞短語） >> [[他卡]]
```
### 架構：三層 + 標籤橫切（183 卡實證）
```
INDEX.md ← 頂層：標籤視圖（非資料夾列表）
TAXONOMY.md ← 標籤字典（受控擴充：先查重再登記）
cards/<bucket>/
├── 00-INDEX.md ← 桶子索引（固定名，容器：只連不重寫）
└── <概念全名>.md ← 概念原子卡
```
- **資料夾只是儲存桶，分類由 frontmatter `tags:` 承載**——不繼承原稿目錄，由 AI 重新組織。
- **桶子索引固定名 `00-INDEX.md`**：`00-` 排序最前、一眼可辨，載入任何桶先讀它。
- **frontmatter `tags:` 而非行內 `#tag`**：內文常用 `#`（如 `#猜想`），行內標籤會讓 ingest 分不清「分類」與「內文範例」污染 graph；frontmatter 零歧義。標籤只能用 `TAXONOMY.md` 列出的；**禁止繞過字典在卡片直接冒新標籤**，但字典可受控擴充（遇新軸先查重、確認非同義詞，再登記進本 repo 的 TAXONOMY.md）。
- **麵包屑帶路徑**：H1 次行 `← [[<bucket>/00-INDEX]]`。指 `00-INDEX` 因固定名跨桶撞名，**一律帶路徑**；卡片間連結用裸 `[[卡名]]`。
### 使用 typed-edge 三元組（抓內文實體關係，不只卡對卡）
用**帶語義的三元組** `A >> 謂詞 >> B` 寫進 `## 關聯`。**重點是抓內文裡的實體關係**——卡對卡（`[[卡A]] >> 謂詞 >> [[卡B]]`）只是把既有雙鏈加個動詞、資訊量幾乎沒增加；知識圖譜的價值在內文概念間的關係（`原子筆記 >> 對立於 >> 傳統筆記`，這些 A/B 是內文概念、不是卡標題）。
格式 `A >> 謂詞 >> B`，規則：
1. **方向性**：必須讀成「A（謂詞）B」一句通順的話；A、B 順序＝主→賓真實方向。
2. **謂詞用動詞 / 動詞短語**（反駁、奠基於、犧牲），天然帶方向。**禁名詞當謂詞**——`>> 存儲格式 >>`、`>> 操作體驗 >>` 讀不通，是錯的。
3. **謂詞自由書寫但別太天馬行空**：寫「參考／參照」皆可（下游 embed 自動聚類同義謂詞），別寫「瞄了一眼」這種抓不到同義的。
4. **內文三元組端點用裸文字**（非 `[[wikilink]]`），避免在 Logseq 產生大量紅色斷鏈；卡對卡那層才用 `[[]]`。
5. **向後相容**：純 `[[A]]` 仍合法（無類型邊），盡量補謂詞。
> **★ 硬自檢（Haiku 量產必備護欄）★** —— 內文三元組的「端點 = `## 實體` 詞條」
> `A >> 謂詞 >> B` 的 A、B 必須與 `## 實體` 某個粗體正規名【一字不差】。**寫完後逐條自檢**：把 A、B 拿去 `## 實體` 找有沒有完全相同的正規名，沒有 → 這條錯了。
> 修法擇一：(a) 改用實體表已有的詞；(b) 端點確是重要實體 → 補進 `## 實體` 再指它。
> 禁止：端點帶括號註解、端點是整句補語、端點是形容詞短語。
> （實證：光寫規則 Haiku 會略過，端點對不齊 14 條；寫成自檢動作後 14→0。跑 1-2 張看不出，跑 12 張才暴露。）
`>>` 為分隔語法，全程一致即可。這是 Karpathy LLM Wiki「知識互連」的強化版——連結不只存在，還帶類型與方向。
### 萃 gloss（node 一句說明，供下游語義 normalize）
每張卡＝一個 entity / graph node。deep tier 改寫時，frontmatter 補一句 `gloss:`——這個 node 是什麼的一句定義。下游 KBDB 對「entity 名 + gloss」一起做 embedding 求相似度，自動歸一同義詞（比只對名字準、比手維護 alias 表自動）。
- **在知識生產的當下、由整理者（CC / Cowork）建**：gloss 跟三元組同階段萃，**不留給下游 ingest 臨時補**——下游只有單檔／跨庫視角，編不出貼合的 gloss。
- **選填、deep tier 才產**：淺萃不浪費。
- **gloss ≠ 摘要**：`gloss` 是 frontmatter 給機器 normalize 的定義句（「X 是…」）；`## 摘要` 是給人讀的核心句。
- **兩層 gloss**：① frontmatter `gloss:` 描述「卡標題」這個 node；② `## 實體` 區塊的每行描述句，描述「內文實體」這些 node。**內文實體也是 graph node、也需描述句**才能被下游 embedding normalize（`黃仁勳` vs `Jensen Huang` 靠描述拉近向量）。
- **實體要描述、謂詞不用**：實體同義詞字面差遠需描述拉近；謂詞同義詞字面本就近，裸詞 embed 自動聚類。
- **對齊下游 envelope**：frontmatter `gloss:` 與 `## 實體` 詞條對應 ingest envelope 的 `nodes[].gloss`。
> **改寫時必守**：① 絕不寫入 raw source（只往 `cards/<bucket>/` 寫，事後驗 raw source 0 異動）；② 檔名＝卡片全名，冒號用全形「：」、斜線用全形「／」，全程一種字元避免斷鏈。
---
## 第五步：更新 INDEX.md 和 status.md
### INDEX.md 格式（頂層 = 標籤視圖）
頂層 INDEX 按 `TAXONOMY.md` 的軸聚類，指向各桶子索引（帶路徑），不是平鋪頁面列表：
```markdown
# Wiki Index
> 最後更新：YYYY-MM-DD HH:MM | 來源：cowork-scan | 總卡數：N
### 知識管理
- [[pkm/00-INDEX]] — PKM 知識管理（N 卡）
### AI 協作
- [[ai/00-INDEX]] — AI 協作（M 卡）
```
桶子索引 `cards/<bucket>/00-INDEX.md` 是容器（只連不重寫，H2/H3 分節列出該桶卡片）。
### status.md 更新
在現有內容**末尾追加**（不覆蓋）：
```markdown
## YYYY-MM-DD HH:MM｜cowork-scan
- vault 類型：[Logseq / Obsidian / 一般專案]
- 掃描檔案：N 個
- 新增頁面：N 個
- 更新頁面：N 個
- 跳過：N 個（未變動）
```
---
## 第六步：回報結果
整理完所有資料夾後，輸出摘要：
```
✅ Wiki 整理完成
資料夾 1：~/Documents/project-a
類型：一般專案
新增：3 頁，更新：1 頁，跳過：12 頁
資料夾 2：~/Documents/Logseq
類型：Logseq vault
新增：5 頁，更新：2 頁，跳過：47 頁
總計：8 頁新增，3 頁更新
```
---
## 絕對禁止
- ❌ 修改任何 raw source 檔案
- ❌ 修改 `CLAUDE.md`
- ❌ 動 `logseq/`、`.obsidian/`、`assets/` 資料夾
- ❌ 刪除 `system-dev/wiki/` 裡已有的頁面（只增補，不刪除）
- ❌ 把機敏資訊（密碼、金鑰、個資）寫進 wiki（遇到跳過並記錄）
- ❌ 整理沒有 `system-dev/wiki/` 的資料夾（那不是這個 skill 的目標）