feat: 安裝結構收進 system-dev/(不污染用戶根目錄)+ 舊版自動遷移 + bump 1.9.0
工具產物原散在用戶根目錄(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>
This commit is contained in:
@@ -0,0 +1,36 @@
|
||||
# .wikiignore — 不想被編入 wiki 的內容（像 .gitignore）
|
||||
#
|
||||
# 三層防護的 L1（檔案層）。CC 在 /wiki-init、/wiki-capture 掃描文件時，
|
||||
# 命中這裡 pattern 的「整個檔案」不讀、不編入 wiki。
|
||||
#
|
||||
# 語法：一行一個 glob pattern，相對專案根目錄。# 開頭是註解。
|
||||
#
|
||||
# ── 同場另兩層 ──────────────────────────────────────
|
||||
# L2 行內標記：檔案要編入，但某段不要 → 在該段前後包：
|
||||
# <!-- wiki:ignore -->
|
||||
# 這幾行不會被編入 wiki
|
||||
# <!-- wiki:end -->
|
||||
# L3 機械底線：萬一機敏值仍被寫進 .claude/wiki/，wiki-secret-scan.sh 會 exit 2 擋下。
|
||||
#
|
||||
# 三層的分工：L1 整檔排除（你主動列）｜L2 局部遮蔽（你標記）｜L3 兜底攔截（自動掃）。
|
||||
# ────────────────────────────────────────────────────
|
||||
|
||||
# ── 機敏檔案（預設就該排除）──────────────────────
|
||||
.env
|
||||
.env.*
|
||||
*.pem
|
||||
*.key
|
||||
*.p12
|
||||
*.pfx
|
||||
*credentials*
|
||||
*secret*
|
||||
**/secrets/**
|
||||
|
||||
# ── 個資 / 客戶資料（依專案調整）────────────────
|
||||
# customers/**
|
||||
# *personal-data*
|
||||
|
||||
# ── 草稿 / 暫存（不值得進記憶）──────────────────
|
||||
# **/draft/**
|
||||
# *.tmp.md
|
||||
# SCRATCH.md
|
||||
@@ -0,0 +1,43 @@
|
||||
# system-dev/wiki/ — LLM 記憶系統
|
||||
|
||||
> 新 session 開始時從這裡導航。
|
||||
> 目的：讓 CC 不需要重新學習已知的事。
|
||||
> 維護者：CC（人不手動編輯這裡）
|
||||
|
||||
---
|
||||
|
||||
## 核心檔案
|
||||
|
||||
| 檔案 | 何時讀 | 內容 |
|
||||
|------|-------|------|
|
||||
| `status.md` | session 開始第一件事 | 當前進度、下一步 |
|
||||
| `mistakes.md` | 做新功能前 | 已知誤解、快速檢查清單 |
|
||||
| `decisions-summary.md` | 遇到設計判斷時 | 架構決策摘要 |
|
||||
|
||||
---
|
||||
|
||||
## 維護規則
|
||||
|
||||
1. 只增不刪——記錄 append，決策改了加新條目說明「舊決策已更新」
|
||||
2. status.md 每次 session 結束更新
|
||||
3. mistakes.md 每次被糾正後 append
|
||||
4. 發現新的重要決策 → 同時更新 decisions-summary.md 和 system-dev/docs/2-architecture/decisions/
|
||||
|
||||
---
|
||||
|
||||
## 頂層索引：標籤視圖（由 /wiki-init 填入）
|
||||
|
||||
由 CC 改寫原文後填入。原文是唯讀 SSoT，wiki 是改寫過的記憶。
|
||||
頂層 INDEX 是**標籤視圖**（非資料夾列表），按 `TAXONOMY.md` 的軸聚類，指向各桶子索引：
|
||||
|
||||
```markdown
|
||||
### 知識管理
|
||||
- [[pkm/00-INDEX]] — PKM 知識管理（N 卡）
|
||||
|
||||
### AI 協作
|
||||
- [[ai/00-INDEX]] — AI 協作（M 卡）
|
||||
```
|
||||
|
||||
> 結構：頂層 INDEX（標籤視圖）→ `cards/<bucket>/00-INDEX.md`（桶子索引，固定名）→ 概念原子卡。
|
||||
> 指 `00-INDEX` **一律帶路徑** `[[bucket/00-INDEX]]`（固定名跨桶撞名）；卡片間用裸 `[[卡名]]`。
|
||||
> 分類由卡片 frontmatter `tags:` 承載，標籤字典見 `TAXONOMY.md`。詳見 `/wiki-init` 規範。
|
||||
@@ -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. **新增領域軸要慎**：領域是檢索骨架，動它影響全庫聚類；形態軸（呈現形式）擴充較安全。不確定就先用現有最接近的，並在卡片或本檔註記「待人類複核此分類」。
|
||||
@@ -0,0 +1,14 @@
|
||||
# 架構決策摘要
|
||||
|
||||
> 遇到設計判斷時查這裡。
|
||||
> 完整脈絡在 system-dev/docs/2-architecture/decisions/。
|
||||
|
||||
---
|
||||
|
||||
（初始化時為空，隨專案進行 append）
|
||||
|
||||
格式：
|
||||
## [主題] — [YYYY-MM-DD]
|
||||
**結論**：[一句話]
|
||||
**原因**：[簡短說明]
|
||||
**詳細**：system-dev/docs/2-architecture/decisions/[對應檔案]
|
||||
@@ -0,0 +1,25 @@
|
||||
# CC 已知誤解 + 避坑方法
|
||||
|
||||
> 做新功能前讀一遍。
|
||||
> 格式：每條必須有症狀 + 正確做法 + 原因。
|
||||
|
||||
---
|
||||
|
||||
## 快速檢查清單（做任何事前）
|
||||
|
||||
- [ ] 有對應 SDD 嗎？沒有 → 停手
|
||||
- [ ] 這次修改會影響哪些模組？有沒有連帶破壞？
|
||||
- [ ] 驗收標準是什麼？有客觀證據嗎？
|
||||
|
||||
---
|
||||
|
||||
## 誤解記錄
|
||||
|
||||
（初始化時為空，隨專案進行 append）
|
||||
|
||||
格式：
|
||||
⚠️ MISTAKE: [錯誤描述，一句話]
|
||||
症狀: [CC 通常怎麼表現這個錯]
|
||||
正確做法: [應該怎麼做]
|
||||
原因: [為什麼會錯]
|
||||
日期: [YYYY-MM-DD]
|
||||
@@ -0,0 +1,22 @@
|
||||
# 當前狀態
|
||||
|
||||
> 更新時間：[初始化時填入]
|
||||
> 每次 session 結束必須更新此檔。
|
||||
|
||||
---
|
||||
|
||||
## 正在做
|
||||
|
||||
（初始化後填入）
|
||||
|
||||
## 下次 session 第一件事
|
||||
|
||||
（初始化後填入）
|
||||
|
||||
## 待負責人確認
|
||||
|
||||
（無）
|
||||
|
||||
## 已知問題
|
||||
|
||||
（無）
|
||||
Reference in New Issue
Block a user