chore(wiki): 導入 system-dev-template + 合併 wiki 到新位置

- system-dev/ 模板包進版控(VERSION/docs/scripts/wiki 骨架)
- 逐檔合併舊 .claude/wiki/ → system-dev/wiki/:
  - status/mistakes/decisions-summary 真資料覆蓋空範本
  - INDEX 新「多角度視圖」結構 + 舊決策/導航併入(過時詞「萬物皆 Block」改 API-as-Wall)
  - principles/TAXONOMY 為新位置獨有,保留
- 刪舊 .claude/wiki/(git 識別為 rename,內容完整搬移)
- 三層機敏防護 hooks + wiki 命令更新

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-26 18:06:52 +08:00
parent 3a1faf19f4
commit 2dd80cd703
27 changed files with 2094 additions and 74 deletions
+50
View File
@@ -0,0 +1,50 @@
# 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 個)
> 由 /wiki-init 依專案性質提出。以下為 PKM / 知識型 vault 的實證一組,請按你的專案調整:
- `知識管理`
- `學習認知`
- `AI協作`
- `生產力`
- `系統設計`
- `工具教學`
(一般開發專案的領域軸可能是:`子系統A` / `子系統B` / `基礎設施` / `前端` / `後端` …)
### 形態(副軸,每卡 0-2 個)
- `方法論`
- `工具實作`
- `觀點主張`
- `架構設計`
- `案例經驗`
---
## 規則
1. **先查重、再登記、才使用**:禁止繞過字典在卡片直接冒新標籤;新標籤先確認非現有同義詞,加進本檔(附定義)再用。
2. **領域 vs 形態分開**:領域是「講什麼主題」,形態是「以什麼形式呈現」,不要混。
3. **頂層 INDEX.md 的標籤視圖依本字典的軸聚類**——字典改了,INDEX 視圖跟著更新。
4. **新增領域軸要慎**:領域是檢索骨架,動它影響全庫聚類;形態軸(呈現形式)擴充較安全。不確定就先用現有最接近的,並在卡片或本檔註記「待人類複核此分類」。