# examples/ — 四個真實專案的去個資版本

這裡放作者四個實際在用的專案文件，讓你（AI）看到「規則長什麼樣、實際用起來是什麼樣」。
**全部已去個資：機構名、帳號、金額、檢驗數值、藥名、主機名、路徑中的使用者名稱、通知 topic 都改成示意或佔位。**
數字與名稱一律當作示意，不是真值；結構、設計理由、決策、坑、指令是真的。

| 資料夾 | 專案 | 示範什麼 |
|---|---|---|
| `events/` | 城市活動蒐集器（scraper → LLM 標籤 → 靜態網頁） | 一個完整的長期專案：資料流、不變量、runbook、發佈鐵律；「README 兼 DESIGN」的例外；公開 repo 的秘密規則；unit 失敗後的自動修復 |
| `health/` | 個人健康資料管理（健檢、用藥、裝置量測） | 敏感資料的專案怎麼設計：快照／歷史分離、原始不可變、收件匣流程；「DESIGN 不可自行修改」的治理；STATUS「完成即刪、不用 ARCHIVE」變體 |
| `finance/` | 個人財務資料管線（原始檔 → 可驗證的 SQLite → 報表） | 大型專案的文件管理：DESIGN 當「憲法」＋ `DESIGN-CHANGELOG.md` 修訂紀錄；很長的 STATUS 怎麼讀、怎麼拆 ARCHIVE；AGENTS 裡「什麼時候跑什麼測試」；agent 工作守則的寫法 |
| `knowledge_base/` | Markdown 筆記庫（Obsidian）在主機上的配套 | 「沒有 STATUS」的例外；筆記／to-do／工作日誌怎麼跟專案分工；筆記庫自己的守則（多個專案的 agent 共寫一本筆記的規矩） |

每個資料夾開頭有自己的 README 說明拿掉了什麼。

讀的時候建議看的重點：

- **每條規則後面的「為什麼」**——多半是踩過坑之後寫的，比規則本身更值得帶走。
- **文件分工是否一致**：DESIGN（是什麼／為什麼）、STATUS（做到哪）、AGENTS（怎麼操作）三者不重複。
- **例外怎麼宣告**：每個專案都可以偏離標準，但要在自己的 DESIGN 裡寫明。