Leo/system-dev-template
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

feat: 安裝結構收進 system-dev/(不污染用戶根目錄)+ 舊版自動遷移 + bump 1.9.0

Browse Source 
工具產物原散在用戶根目錄(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:
richblack
2026-06-26 15:13:43 +08:00
parent c95705c286
commit ecf1f882c6
27 changed files with 283 additions and 166 deletions
Download Patch File Download Diff File Expand all files Collapse all files
template/system-dev/VERSION
+1
View File
@@ -0,0 +1 @@
1.9.0
template/system-dev/docs/2-architecture/decisions/TEMPLATE-adr.md
+30
View File
@@ -0,0 +1,30 @@
# [主題] — Architecture Decision Record
> 日期：[YYYY-MM-DD]
> 狀態：[提議中 / 已採納 / 已廢棄]
> 影響範圍：[哪些子系統 / 模組]
---
## 背景
[遇到了什麼問題，需要做這個決定？]
## 決定
**[結論，一句話。]**
## 原因
[詳細說明為什麼這樣決定。]
## 放棄的選項
| 選項 | 放棄原因 |
|------|---------|
| [選項 A] | [原因] |
| [選項 B] | [原因] |
## 影響與後續
[這個決定影響哪些地方？有什麼技術債或需要注意的事？]
template/system-dev/docs/3-specs/TEMPLATE-sdd/design.md
+76
View File
@@ -0,0 +1,76 @@
# [子系統名稱] — Design
> 狀態：[草稿 / 審核中 / 已採納 / 已廢棄]
> 建立：[YYYY-MM-DD] | 最後更新：[YYYY-MM-DD]
> 負責人：[名稱]
---
## 一句話說明
[這個子系統做什麼，一句話。]
---
## 背景與問題
[為什麼需要這個子系統？解決了什麼問題？]
---
## 範圍
### 包含（In Scope）
- [這個 SDD 涵蓋的功能]
### 不包含（Out of Scope）
- [明確排除的功能，避免 CC 自行延伸]
---
## 設計
### 架構概覽
[用文字或 ASCII 描述系統結構]
```
[元件 A] → [元件 B] → [元件 C]
```
### 關鍵決策
| 決策 | 選擇 | 原因 | 放棄的選項 |
|------|------|------|----------|
| [問題] | [選擇] | [原因] | [其他選項] |
### API / 介面定義
[端點、資料格式、輸入輸出規格]
### 資料模型
[資料結構、欄位說明]
---
## 技術限制
- [不能用什麼]
- [必須相容什麼]
- [效能要求]
---
## 驗收標準
完成的定義（CC 完成任何 task 前必須確認）：
- [ ] [可客觀驗證的條件，例如：POST /api/xxx 回傳 200]
- [ ] [...]
---
## 相關文件
- [連結到相關 ADR]
- [連結到相關 SDD]
template/system-dev/docs/3-specs/TEMPLATE-sdd/tasks.md
+50
View File
@@ -0,0 +1,50 @@
# [子系統名稱] — Tasks
> 權威來源：此檔案是進度真相，不是 CLAUDE.md 或對話。
> 規則：動手前標 [🔄]，完成立刻標 [x]，不批次更新。
---
## Phase 1：[Phase 名稱]
### 前置條件
- [ ] [這個 Phase 開始前必須完成的事]
### Tasks
- [ ] 1.1 [task 描述]
- 驗收：[客觀可驗證的完成標準]
- 注意：[CC 容易犯的錯，可選]
- [ ] 1.2 [task 描述]
- 驗收：[...]
---
## Phase 2：[Phase 名稱]
> 前置條件：Phase 1 全部完成
- [ ] 2.1 [task 描述]
- 驗收：[...]
---
## 完成定義
整個 SDD 完成 = 以下全部達成：
- [ ] 所有 tasks 標 [x]
- [ ] 驗收標準通過（有客觀證據）
- [ ] design.md 與實作一致（如有出入需更新）
---
## 狀態說明
| 標記 | 意義 |
|------|------|
| `[ ]` | 未開始 |
| `[🔄]` | 進行中（當前 session）|
| `[x]` | 完成（有驗收證據）|
| `[~]` | 暫緩（說明原因）|
| `[!]` | 阻擋中（說明阻擋原因）|
template/system-dev/docs/README.md
+56
View File
@@ -0,0 +1,56 @@
# 文件分類索引
> 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` | 架構決策摘要 | 重大決策後 |
template/system-dev/docs/SKILL.md
+233
View File
@@ -0,0 +1,233 @@
---
name: wiki-cowork-scan
description: "掃描本機 Documents 下所有裝了 system-dev-template 的資料夾，自動整理 LLM Wiki。支援一般專案、Logseq vault、Obsidian vault 三種結構，偵測方式與 install.sh 一致。觸發時機：使用者說「整理 wiki」「幫我掃 wiki」「更新我的 wiki」「wiki 掃描」，或 Cowork cron 定期觸發。"
---
# Wiki Cowork Scan
## 核心原則
這個 skill 與 Claude Code 的 `/wiki-init` `/wiki-capture` 共用同一套規則：
| 層 | 規則 |
|------------|-------------------------------------------|
| raw source | 只讀，不動 |
| `system-dev/wiki/` | 唯一輸出地點，只增不覆 |
| `CLAUDE.md` | 不動 |
| `logseq/`、`.obsidian/`、`assets/` | 絕對不動 |
**CC 和 Cowork 輸出格式相同，任何一方整理過的內容，另一方看到就跳過或補充，不覆蓋。**
---
## 第一步：發現所有目標資料夾
掃描 `~/Documents`（遞迴深度 3 層），找出所有含 `system-dev/wiki/` 的資料夾。
```
~/Documents/
project-a/system-dev/wiki/ ← ✅ 目標
Logseq/system-dev/wiki/ ← ✅ 目標
其他資料夾/ ← ❌ 跳過
```
找到後列出清單，告訴使用者：「找到 N 個 wiki 資料夾，開始整理。」
---
## 第二步：對每個資料夾偵測 vault 類型
進入每個目標資料夾的**根目錄**（`system-dev/wiki/` 的上兩層），依序判斷：
### 判斷順序（與 install.sh 一致）
```
if 根目錄有 logseq/ 資料夾
→ vault 類型：Logseq
→ raw source：pages/、journals/
→ 忽略：logseq/、assets/
else if 根目錄有 .obsidian/ 資料夾
→ vault 類型：Obsidian
→ raw source：根目錄下所有 .md（排除 .obsidian/ 內的檔案）
else
→ vault 類型：一般專案
→ raw source：docs/ 下所有 .md
```
---
## 第三步：讀取現有 wiki 狀態
進入 `system-dev/wiki/`，讀取：
- `INDEX.md`：目前已有哪些 wiki 頁面
- `status.md`：上次整理時間、進度
- `log.md`（如果有）：誰動過什麼
目的：**知道哪些已整理過，只處理新增或有變動的 raw source**，不重複整理。
---
## 第四步：整理規則
### 讀 raw source
逐一讀取 raw source 的 `.md` 檔。跳過：
- 檔名以 `.` 開頭的隱藏檔
- `.wikiignore` 裡列出的 glob pattern（如果存在）
- 含有 `<!-- wiki:ignore -->` 標記的區段
### 整理邏輯
每個 raw source 檔案，判斷：
1. **INDEX.md 裡已有對應條目，且 raw source 未修改** → 跳過
2. **INDEX.md 裡已有條目，但 raw source 有新內容** → 更新對應 wiki 頁面，補充新資訊，不刪舊內容
3. **INDEX.md 裡沒有對應條目** → 新建 wiki 頁面
### Wiki 卡片格式（概念原子卡，存到 `cards/<bucket>/`）
```markdown
---
tags: [知識管理, AI協作, 方法論]
gloss: 一句話定義這個概念是什麼（給下游語義 normalize 用，選填、deep tier 才產）
---
# 概念全名
← [[<bucket>/00-INDEX]]
**來源**：`[raw source 相對路徑]`
**最後更新**：YYYY-MM-DD
## 摘要
[一句話核心]
## 重點
- [自包含改寫的要點，不寫「詳見原文」]
## 關聯
- [[本卡]] >> 謂詞（動詞短語） >> [[他卡]]
- [[原子筆記]] >> 是其最小單元 >> [[卡片盒筆記法]]
```
### 架構：三層 + 標籤橫切（183 卡實證）
```
INDEX.md ← 頂層：標籤視圖（非資料夾列表）
TAXONOMY.md ← 標籤字典（受控擴充：先查重再登記）
cards/<bucket>/
├── 00-INDEX.md ← 桶子索引（固定名，容器：只連不重寫）
└── <概念全名>.md ← 概念原子卡
```
- **資料夾只是儲存桶，分類由 frontmatter `tags:` 承載**——不繼承原稿目錄，由 AI 重新組織。
- **桶子索引固定名 `00-INDEX.md`**：`00-` 排序最前、一眼可辨，載入任何桶先讀它。
- **frontmatter `tags:` 而非行內 `#tag`**：內文常用 `#`（如 `#猜想`），行內標籤會讓 ingest 分不清「分類」與「內文範例」污染 graph；frontmatter 零歧義。標籤只能用 `TAXONOMY.md` 列出的；**禁止繞過字典在卡片直接冒新標籤**，但字典可受控擴充（遇新軸先查重、確認非同義詞，再登記進本 repo 的 TAXONOMY.md）。
- **麵包屑帶路徑**：H1 次行 `← [[<bucket>/00-INDEX]]`。指 `00-INDEX` 因固定名跨桶撞名，**一律帶路徑**；卡片間連結用裸 `[[卡名]]`。
### 使用 typed-edge 三元組（不只裸 `[[wikilink]]`）
整理時，發現內容與其他頁面有關聯，用**帶語義的三元組**寫進 `## 關聯`，而非只列裸 `[[頁面]]`。裸 `[[A]]` 只說「有關」、沒說關係，下游要建 knowledge graph 還得回讀兩張卡；三元組把關係也預編譯，ingest 直接 parse 出帶類型的有向邊。
格式 `A >> 謂詞 >> B`，規則：
1. **方向性**：必須讀成「A（謂詞）B」一句通順的話；A、B 順序＝主→賓真實方向。
2. **謂詞用動詞 / 動詞短語**（反駁、奠基於、是…的實作），天然帶方向。
3. **謂詞自由書寫**，不受控詞彙；下游對謂詞 embedding 時同義謂詞會自動聚類，但方向仍靠書寫順序保證。
4. **向後相容**：純 `[[A]]` 仍合法（無類型邊），盡量補謂詞。
`>>` 為分隔語法，全程一致即可。這是 Karpathy LLM Wiki「知識互連」的強化版——連結不只存在，還帶類型與方向。
### 萃 gloss（node 一句說明，供下游語義 normalize）
每張卡＝一個 entity / graph node。deep tier 改寫時，frontmatter 補一句 `gloss:`——這個 node 是什麼的一句定義。下游 KBDB 對「entity 名 + gloss」一起做 embedding 求相似度，自動歸一同義詞（比只對名字準、比手維護 alias 表自動）。
- **在知識生產的當下、由整理者（CC / Cowork）建**：gloss 跟三元組同階段萃，**不留給下游 ingest 臨時補**——下游只有單檔／跨庫視角，編不出貼合的 gloss。
- **選填、deep tier 才產**：淺萃不浪費。
- **gloss ≠ 摘要**：`gloss` 是 frontmatter 給機器 normalize 的定義句（「X 是…」）；`## 摘要` 是給人讀的核心句。
- **對齊下游 envelope**：frontmatter `gloss:` 對應 ingest envelope 的 `nodes[].gloss`。
> **改寫時必守**：① 絕不寫入 raw source（只往 `cards/<bucket>/` 寫，事後驗 raw source 0 異動）；② 檔名＝卡片全名，冒號用全形「：」、斜線用全形「／」，全程一種字元避免斷鏈。
### 使用 typed-edge 三元組（不只裸 `[[wikilink]]`）
整理時，發現內容與其他頁面有關聯，用**帶語義的三元組**寫進 `## 關聯`，而非只列裸 `[[頁面]]`。裸 `[[A]]` 只說「有關」、沒說關係，下游要建 knowledge graph 還得回讀兩張卡；三元組把關係也預編譯，ingest 直接 parse 出帶類型的有向邊。
格式 `A >> 謂詞 >> B`，規則：
1. **方向性**：必須讀成「A（謂詞）B」一句通順的話；A、B 順序＝主→賓真實方向。
2. **謂詞用動詞 / 動詞短語**（反駁、奠基於、是…的實作），天然帶方向。
3. **謂詞自由書寫**，不受控詞彙；下游對謂詞 embedding 時同義謂詞會自動聚類，但方向仍靠書寫順序保證。
4. **向後相容**：純 `[[A]]` 仍合法（無類型邊），盡量補謂詞。
`>>` 為分隔語法，全程一致即可。這是 Karpathy LLM Wiki「知識互連」的強化版——連結不只存在，還帶類型與方向。
---
## 第五步：更新 INDEX.md 和 status.md
### INDEX.md 格式（頂層 = 標籤視圖）
頂層 INDEX 按 `TAXONOMY.md` 的軸聚類，指向各桶子索引（帶路徑），不是平鋪頁面列表：
```markdown
# Wiki Index
> 最後更新：YYYY-MM-DD HH:MM | 來源：cowork-scan | 總卡數：N
### 知識管理
- [[pkm/00-INDEX]] — PKM 知識管理（N 卡）
### AI 協作
- [[ai/00-INDEX]] — AI 協作（M 卡）
```
桶子索引 `cards/<bucket>/00-INDEX.md` 是容器（只連不重寫，H2/H3 分節列出該桶卡片）。
### status.md 更新
在現有內容**末尾追加**（不覆蓋）：
```markdown
## YYYY-MM-DD HH:MM｜cowork-scan
- vault 類型：[Logseq / Obsidian / 一般專案]
- 掃描檔案：N 個
- 新增頁面：N 個
- 更新頁面：N 個
- 跳過：N 個（未變動）
```
---
## 第六步：回報結果
整理完所有資料夾後，輸出摘要：
```
✅ Wiki 整理完成
資料夾 1：~/Documents/project-a
類型：一般專案
新增：3 頁，更新：1 頁，跳過：12 頁
資料夾 2：~/Documents/Logseq
類型：Logseq vault
新增：5 頁，更新：2 頁，跳過：47 頁
總計：8 頁新增，3 頁更新
```
---
## 絕對禁止
- ❌ 修改任何 raw source 檔案
- ❌ 修改 `CLAUDE.md`
- ❌ 動 `logseq/`、`.obsidian/`、`assets/` 資料夾
- ❌ 刪除 `system-dev/wiki/` 裡已有的頁面（只增補，不刪除）
- ❌ 把機敏資訊（密碼、金鑰、個資）寫進 wiki（遇到跳過並記錄）
- ❌ 整理沒有 `system-dev/wiki/` 的資料夾（那不是這個 skill 的目標）
template/system-dev/wiki/.wikiignore
+36
View File
@@ -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
template/system-dev/wiki/INDEX.md
+43
View File
@@ -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` 規範。
template/system-dev/wiki/TAXONOMY.md
+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. **新增領域軸要慎**：領域是檢索骨架，動它影響全庫聚類；形態軸（呈現形式）擴充較安全。不確定就先用現有最接近的，並在卡片或本檔註記「待人類複核此分類」。
template/system-dev/wiki/decisions-summary.md
+14
View File
@@ -0,0 +1,14 @@
# 架構決策摘要
> 遇到設計判斷時查這裡。
> 完整脈絡在 system-dev/docs/2-architecture/decisions/。
---
（初始化時為空，隨專案進行 append）
格式：
## [主題] — [YYYY-MM-DD]
**結論**：[一句話]
**原因**：[簡短說明]
**詳細**：system-dev/docs/2-architecture/decisions/[對應檔案]
template/system-dev/wiki/mistakes.md
+25
View File
@@ -0,0 +1,25 @@
# CC 已知誤解 + 避坑方法
> 做新功能前讀一遍。
> 格式：每條必須有症狀 + 正確做法 + 原因。
---
## 快速檢查清單（做任何事前）
- [ ] 有對應 SDD 嗎？沒有 → 停手
- [ ] 這次修改會影響哪些模組？有沒有連帶破壞？
- [ ] 驗收標準是什麼？有客觀證據嗎？
---
## 誤解記錄
（初始化時為空，隨專案進行 append）
格式：
⚠️ MISTAKE: [錯誤描述，一句話]
症狀: [CC 通常怎麼表現這個錯]
正確做法: [應該怎麼做]
原因: [為什麼會錯]
日期: [YYYY-MM-DD]
template/system-dev/wiki/status.md
+22
View File
@@ -0,0 +1,22 @@
# 當前狀態
> 更新時間：[初始化時填入]
> 每次 session 結束必須更新此檔。
---
## 正在做
（初始化後填入）
## 下次 session 第一件事
（初始化後填入）
## 待負責人確認
（無）
## 已知問題
（無）