Leo
ecf1f882c6
工具產物原散在用戶根目錄(docs 七層、scripts),又把 wiki/VERSION 寄生在 CC 原生
.claude/ 裡,用戶分不清哪個 docs 是工具的。這版徹底收斂:除 .claude/(settings/
commands/hooks)與 CLAUDE.md 留根,工具所有資料收進 system-dev/。
對應 SDD: system-dev/docs/3-specs/install-layout/(內部記錄,依原則不推)。
- 新結構 system-dev/{VERSION,wiki/,docs/,scripts/};.claude/ 只剩 CC 機制檔
- wiki 改寫產物落點正式化:install 建 system-dev/wiki/cards/(.gitkeep)
- docs 雙語義拆開:工具文件→system-dev/docs/;用戶 raw source 維持原處只讀
- scripts 一開始就裝進 system-dev/scripts/
- 舊版自動遷移雙保險:update.sh 冪等搬移(wiki 含 .git、docs 白名單)
+ session-start hook 偵測舊結構未遷移時提示(low-code 用戶兜底)
- wiki-secret-scan 觸發路徑改 system-dev/wiki/**(否則新結構防護失效)
- 全套路徑引用同步:CLAUDE/SKILL/wiki-*/sdd-*/hooks/INDEX/README(中英)
- 沙盒驗證:遷移含 .git commit 一致、冪等、用戶自填 docs 保留;全 bash -n 過
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.5 KiB
2.5 KiB
TAXONOMY.md — 標籤字典（本 repo 專屬）
wiki 卡片的 frontmatter
tags:只能用這裡列出的標籤。 這不是凍結——字典可以擴充，只是禁止繞過字典在卡片裡直接冒新標籤。 維護者：CC（由 /wiki-init 初始化、隨 wiki 演進受控擴充）。遇到現有軸都裝不下的內容時，照這個流程（先查、後擴、登記）：
- 先查既有：現有標籤真的都不合，還是只是同義詞？（
知識管理vsKMvs筆記管理是同一軸，別重造）- 確實是新軸 → 把新標籤加進本檔（附一句定義），再用。不必停下來問人，但「先登記再使用」這道查核不能省。
- 自由增生才是要防的——同義標籤散開會讓同類卡片分散、下游聚類失準。受控擴充（先查重、再登記）不會。
字典是每個 repo 各自的：跨 repo 引擎靠各 repo 自己一致的 taxonomy 接合，不是逼所有 repo 共用一份。 知識型 vault 的領域軸（知識管理／學習認知）和開發 repo（子系統／基礎設施）本來就該不同。
分類採雙軸（一張卡可多重歸屬）
分類由 frontmatter tags: 承載，不靠資料夾、不靠行內 #tag。
一張卡同時掛「領域 1-3 個 + 形態 0-2 個」，可從任一軸過濾。
領域（主軸，每卡 1-3 個）
由 /wiki-init 依專案性質提出。以下為 PKM / 知識型 vault 的實證一組，請按你的專案調整：
知識管理學習認知AI協作生產力系統設計工具教學
（一般開發專案的領域軸可能是：子系統A / 子系統B / 基礎設施 / 前端 / 後端 …）
形態（副軸，每卡 0-2 個）
方法論工具實作觀點主張架構設計案例經驗
規則
- 先查重、再登記、才使用：禁止繞過字典在卡片直接冒新標籤；新標籤先確認非現有同義詞，加進本檔（附定義）再用。
- 領域 vs 形態分開：領域是「講什麼主題」，形態是「以什麼形式呈現」，不要混。
- 頂層 INDEX.md 的標籤視圖依本字典的軸聚類——字典改了，INDEX 視圖跟著更新。
- 新增領域軸要慎：領域是檢索骨架，動它影響全庫聚類；形態軸（呈現形式）擴充較安全。不確定就先用現有最接近的，並在卡片或本檔註記「待人類複核此分類」。