kbdb-ingest-plugin/system-dev/wiki/TAXONOMY.md

TAXONOMY.md — 標籤字典（本 repo 專屬）

wiki 卡片的 frontmatter tags: 只能用這裡列出的標籤。 這不是凍結——字典可以擴充，只是禁止繞過字典在卡片裡直接冒新標籤。 維護者：CC（由 /wiki-init 初始化、隨 wiki 演進受控擴充）。

遇到現有軸都裝不下的內容時，照這個流程（先查、後擴、登記）：

1. 先查既有：現有標籤真的都不合，還是只是同義詞？（知識管理 vs KM vs 筆記管理 是同一軸，別重造）
2. 確實是新軸 → 把新標籤加進本檔（附一句定義），再用。不必停下來問人，但「先登記再使用」這道查核不能省。
3. 自由增生才是要防的——同義標籤散開會讓同類卡片分散、下游聚類失準。受控擴充（先查重、再登記）不會。

字典是每個 repo 各自的：跨 repo 引擎靠各 repo 自己一致的 taxonomy 接合，不是逼所有 repo 共用一份。 知識型 vault 的領域軸（知識管理／學習認知）和開發 repo（子系統／基礎設施）本來就該不同。

---

分類採雙軸（一張卡可多重歸屬）

分類由 frontmatter tags: 承載，不靠資料夾、不靠行內 #tag。 一張卡同時掛「領域 1-3 個 + 形態 0-2 個」，可從任一軸過濾。

領域（主軸，每卡 1-3 個）

kbdb-ingest-plugin（餵食器）的子系統軸。/wiki-init 2026-06-26 依本 repo 性質定。

• ingest管線 — 採取/萃取/匯總/輸出的資料流本身
• 契約邊界 — ingest↔graph 的 envelope 契約、職責切割
• 萃取策略 — extract 路徑（模型選擇、品質門檻、升級閘）
• 掛載架構 — base→graph→ingest 堆疊、API 邊界、三守則
• 部署 — wrangler 部署、繞 Actions、觸發機制

形態（副軸，每卡 0-2 個）

• 架構設計 — 結構/邊界/資料流的設計判斷
• 鐵律約束 — 不可違反的硬規則（與 principles.md 呼應）
• 模型策略 — LLM 萃取的模型/tier 選擇
• 契約規格 — 逐字依凍結契約的形式規格

---

規則

1. 先查重、再登記、才使用：禁止繞過字典在卡片直接冒新標籤；新標籤先確認非現有同義詞，加進本檔（附定義）再用。
2. 領域 vs 形態分開：領域是「講什麼主題」，形態是「以什麼形式呈現」，不要混。
3. 頂層 INDEX.md 的標籤視圖依本字典的軸聚類——字典改了，INDEX 視圖跟著更新。
4. 新增領域軸要慎：領域是檢索骨架，動它影響全庫聚類；形態軸（呈現形式）擴充較安全。不確定就先用現有最接近的，並在卡片或本檔註記「待人類複核此分類」。