01 — 每個元素是什麼
Wing
一棟大樓的側翼
最上層分區。每個人或專案就是一個 Wing。例如 wing_kai、wing_driftwood。
Hall
走廊的類型
Wing 內部的記憶類型走廊。固定五種：facts、events、discoveries、preferences、advice。
Room
走廊旁的房間
具體的主題。例如 auth-migration、graphql-switch。一個 Room 可出現在多個 Wing 中。
Closet
房間裡的衣櫃
Room 內的摘要索引。指向原始內容的指標，讓 AI 快速知道「這裡有什麼」。
Drawer
衣櫃裡的抽屜
實際的逐字原文。原始對話、決策、程式碼片段。永遠不摘要、不刪減。
02 — 包含關係（由外到內）
定址路徑：wing_kai / hall_facts / auth-migration / closet / drawer
03 — Closet vs Drawer：摘要索引 vs 逐字原文
Closet 和 Drawer 的關係就像書的目錄和書的內文。
AI 搜尋時先讀 Closet（快速判斷相關性），需要細節時再打開 Drawer（取得原文）。
Room: auth-migration
C
Closet — AI 先讀這裡
這間房有 2 份記憶：
1. Kai 發現 Auth0 refresh bug（2026-01-20）
2. PR#42 code review 發現 middleware 漏洞（2026-02-05）
作用：AI 讀 Closet 只需 ~30 tokens，就知道這間房有什麼。
像書的目錄 — 「第3章：Auth0 的 bug，第4章：PR#42 review」
D
Drawer #1 — 完整的原始對話
User: Auth0 的 token refresh 好像壞了？
Kai: 對，我查了一下，Auth0 SDK 在 mobile Safari 上有個奇怪的 refresh bug，token 過期後不會自動 renew。我試了三種 workaround，最後發現只有手動 rotate 才行。所以我建議我們直接換 Clerk，他們的 SDK 沒有這個問題。
~120 tokens — 原始對話的每一個字
D
Drawer #2 — 完整的原始對話
User: PR#42 的 review 怎麼樣？
Kai: /api/admin route 少了 middleware check。我查了一下 git log，這已經是這一季第三次出現這個 pattern 了。我覺得我們需要加一個 lint rule 來防止這種遺漏。
~100 tokens — 原始對話的每一個字
~30 tokens
Closet 摘要
AI 秒讀，快速判斷
~220 tokens
Drawer 原文合計
一字不漏，完整上下文
為什麼需要兩層？
如果你有 10,000 條記憶，AI 不可能全部讀完。Closet 讓 AI 用很少的 token 就能掃描「哪些房間可能有答案」，找到之後再打開對應的 Drawer 讀原文。
Closet = 書的目錄（快速掃描 → 哪一章可能有答案？）
Drawer = 書的內文（打開那一章 → 讀到原始的每一個字）
04 — 巢狀結構（可互動展開）
Wing: Kai (Person)
Halls — 記憶類型走廊（點擊展開說明）
hall_facts
hall_events
hall_discoveries
hall_preferences
hall_advice
auth-migration
Closet（摘要索引）
Kai 發現 OAuth token refresh 的 bug，推薦 Clerk 取代 Auth0。3 次 code review 都出現同樣的 middleware 漏洞。
Drawer #1（逐字原文）
"Auth0 SDK 在 mobile Safari 上有個奇怪的 refresh bug，token 過期後不會自動 renew..."
Drawer #2（逐字原文）
"PR#42 — /api/admin route 少了 middleware check，這是這季第三次出現這個 pattern..."
graphql-switch
Closet（摘要索引）
Kai 主導 REST 到 GraphQL 的遷移，解決了 dashboard N+1 問題。
Drawer #1（逐字原文）
"REST endpoints 的 N+1 問題把 dashboard 載入時間拉到 4 秒，GraphQL 解決了這個..."
Tunnel: auth-migration 跨 Wing 連結
Wing: Driftwood (Project)
Halls — 記憶類型走廊（點擊展開說明）
hall_facts
hall_events
hall_discoveries
hall_preferences
hall_advice
auth-migration
Closet（摘要索引）
團隊決定從 Auth0 遷移到 Clerk。Maya 負責執行，Priya 批准。
Drawer #1（逐字原文）
"比較完定價方案後，Clerk 給我們 10K MAU 免費額度，Auth0 要 $23/mo 起..."
ci-pipeline
Closet（摘要索引）
CI 從 CircleCI 遷到 GitHub Actions，build 速度提升 40%。
Drawer #1（逐字原文）
"CircleCI 設定檔已經超過 200 行，完全不可維護了..."
06 — 定址範例：ChromaDB 裡的 metadata
| Wing |
Hall |
Room |
內容（Drawer） |
wing_kai |
hall_events |
auth-migration |
"Kai debugged the OAuth token refresh" |
wing_driftwood |
hall_facts |
auth-migration |
"team decided to migrate auth to Clerk" |
wing_priya |
hall_advice |
auth-migration |
"Priya approved Clerk over Auth0" |
wing_kai |
hall_discoveries |
graphql-switch |
"N+1 problem solved by GraphQL batching" |
wing_driftwood |
hall_preferences |
ci-pipeline |
"always use Docker layer caching in CI" |
同一個 Room 名稱 auth-migration 出現在三個不同的 Wing 中 — 這就自動形成了一條 Tunnel，讓 AI 能跨人物、跨專案追蹤同一個主題。
07 — 真實世界類比
想像一座圖書館
Wing
圖書館的樓層
每個人或專案一層：「Kai 樓」「Driftwood 樓」
Hall
書架的分類走道
事實走道、事件走道、發現走道、偏好走道、建議走道
Room
某個主題的閱讀室
「auth-migration 室」「graphql-switch 室」
Closet
閱讀室的索引卡片
「這間有 3 份文件，關於 Clerk vs Auth0 的決策」
Drawer
書架上的原始文件
「Auth0 SDK has this weird refresh bug on mobile Safari...」
Tunnel
跨樓層的通道
「Kai 樓」和「Driftwood 樓」的 auth-migration 室相連
08 — 結構如何提升搜尋效能
22,000+ 條真實對話記憶的測試結果。結構不是裝飾 — 它是 +34% 的檢索提升。