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>
文件分類索引
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 |
架構決策摘要 | 重大決策後 |