實戰範例 004：技術會議記憶挖掘

背景

您的團隊每週進行技術架構會議，討論系統重構、技術債務清理、性能優化等議題。這些會議中產生許多重要決策與設討，但散落在 ChatGPT 對話中，難以追溯與應用。透過 MemPalace 的 recall 技能，您可以在新會話中搜尋「上次團隊對模組化架構的討論」或「上次關於既有 API 相容性保證的決策」。

情境

您的團隊正在對既有系統進行模組化重構，並在會議中討論了以下主題：

模組邊界定義原則
向後相容性（Backward Compatibility）策略
緩解技術債務的漸進式路徑

會議結束後，您希望將這些決議錨定到記憶宮殿中，以便在未來其他會議或實作階段快速召喚回顧。

您想做什麼？

用戶：「能不能幫我把剛才會議中關鍵的技術決議記錄到 MemPalace，方便日後參考？」

第 1 步：初始化 Palace（如果尚未初始化）

$ mempalace init --wing "d:/Repo/payment-system"
✓ Palace initialized at .mempalace
✓ First wing: d:/Repo/payment-system

第 2 步：添加 Decision Drawers

每個決議作為 Verbatim Drawer，逐字儲存會議內容，避免總結失真。

決議 1：模組邊界定義原則

$ mempalace add \
  --wing "d:/Repo/payment-system" \
  --room "architecture" \
  --title "模組邊界定義：反向依賴規則" \
  --content "模組之間禁止反向依賴——上層模組不得依賴底層模組的具體實作，應依賴抽象介面。此規則將在模組依賴檢查器中強制執行，違規模組將無法通過 CI/CD。" \
  --tags "architecture,modularity,dependency-rule"

決議 2：後向相容性策略

$ mempalace add \
  --wing "d:/Repo/payment-system" \
  --room "compatibility" \
  --title "後向相容性：API 刻意棄用流程" \
  --content "既有 API 端點不得直接刪除，必須經過至少三個版本的刻意棄用（Deprecation）流程。棄用時必須：（1）在回應中標示 X-Deprecated 頭部（2）在文件中顯著標記廢棄時間表（3）保留至少 90 天的遷移期。此流程將由 API 相容性閘道自動監控。" \
  --tags "compatibility,api,deprecation"

決議 3：技術債務緩解路徑

$ mempalace add \
  --wing "d:/Repo/payment-system" \
  --room "tech-debt" \
  --title "技術債務：漸進式重寫策略" \
  --content "系統分三期進行漸進式重寫。第一期：抽離認證模組，統一使用 OAuth 2.0，此模組優先重寫以降低安全漏洞行風險。第二期：重構訂單狀態機，從同事系列遷移至事件溯源（Event Sourcing）模式。第三期：拆分支付核心服務，將信用卡與銀行轉帳拆為獨立上下文。每期結束後進行測試覆蓋率審查，要求 ≥85% 的單元測試覆蓋率。" \
  --tags "tech-debt,refactor,event-sourcing"

第 3 步：連結相關 Decision

關聯決議，建立架構決策鏈：

$ mempalace link \
  --wing "d:/Repo/payment-system" \
  --from "模組邊界定義：反向依賴規則" \
  --to "後向相容性：API 刻意棄用流程" \
  --relation "enforces" \
  --description "模組邊界定則強制執行封裝，間接促成 API 刻意棄用流程的可控性"

✓ Linked drawer-001 → drawer-002

$ mempalace link \
  --wing "d:/Repo/payment-system" \
  --from "模組邊界定義：反向依賴規則" \
  --to "技術債務：漸進式重寫策略" \
  --relation "supports" \
  --description "反向依賴規則為模組化重寫提供基礎結構，確保新服務能永續演進"

✓ Linked drawer-001 → drawer-003

第 4 步：召喚會議記憶

數月後，您需要檢討模組化重構的進度，使用 recall 搜尋：

$ mempalace recall --wing "d:/Repo/payment-system" --query "模組邊界 重構 決策"

搜尋結果：

Top 1: drawer-001.md
Title: 模組邊界定義：反向依賴規則
Relevance: 0.92
Tags: architecture,modularity,dependency-rule
Content:
  模組之間禁止反向依賴——上層模組不得依賴底層模組的具體實作，應依賴抽象介面。此規則將在模組依賴檢查器中強制執行，違規模組將無法通過 CI/CD。

Related via Knowledge Graph:
  - Linked [enforces] → drawer-002.md: 後向相容性：API 刻意棄用流程
  - Linked [supports] → drawer-003.md: 技術債務：漸進式重寫策略

透過 Knowledge Graph，您不僅找到模組邊界定義，還發現相關的 API 相容性策略與技術債務路徑，方便全面審視架構重構進度。

第 5 步：驗證決議執行

使用 graph 技能檢查決議之間的關聯：

$ mempalace graph --wing "d:/Repo/payment-system" --drawer "模組邊界定義：反向依賴規則"

結果（視覺化 Mermaid 圖）：

graph LR
  drawer001[模組邊界定義：反向依賴規則] -->|enforces| drawer002[後向相容性：API 刻意棄用流程]
  drawer001 -->|supports| drawer003[技術債務：漸進式重寫策略]

此圖直接在定義頁面上動態生成，幫助團隊快速理解決議之間的邏輯依賴。

關鍵成果

✅ 技術會議中的三個關鍵決議已逐字儲存
✅ 建立 enforces、supports 關聯，形成架構決策鏈
✅ 透過 recall 可搜尋「模組邊界重構決策」，並從 Knowledge Graph 推理相關 API 與債務路徑
✅ 使用 graph 視覺化決議間的關係，便於團隊對齊理解

延伸練習

將會議的技術設計稿（Architecture Diagram 或設計文件）添加為 Reference Drawers，並連結到對應的 Decision Drawers，建立「設計 → 決議 → 實作」的完整鏈路。

Platform: Claude Code
Skill: oml-add、oml-link、oml-recall、oml-graph