跨會話長週期開發連續性工作流 · Claude-Mem

為什麼需要長週期會話連續性？

在面對複雜的系統級開發（如將整個專案的資料庫架構重構）時，開發任務很難在一個下午或單一一次 Chat Session 中完成。我們必須分批提交、分段討論，這意味著我們需要頻繁地重啟 AI 助手（如重啟 Claude Code CLI）。

跨會話連續性工作流 (Session Continuity Flow) 透過 Claude-Mem 的持久化記憶管理，能讓 AI 助手在每天早上被啟動時，自動拉取昨天的開發上下文，無縫銜接昨天的進度。

步驟詳解與實戰指令

    ┌──────────────────────┐
    │ 1. 啟動全新會話      │  <-- 開啟終端機或 Chat 視窗
    └──────────┬───────────┘
               │ 
               ▼
    ┌──────────────────────┐
    │ 2. 自動/手動記憶載入 │  <-- 執行 get_observations
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │ 3. 接續 Tasks 實作   │  <-- 執行 /opsx:apply 推進進度
    └──────────┬───────────┘
               │
               ▼
    ┌──────────────────────┐
    │ 4. 結案與記憶歸檔    │  <-- 將今日重要決策寫入長期儲存
    └──────────────────────┘

步驟 1：啟動全新的會話

當你開啟一個新的工作天，開啟終端機並呼叫 AI 助手。此時 AI 的 Context 處於空白的初始狀態。

步驟 2：手動或自動載入過往記憶

AI 助手會首先讀取專案當前的 tasks.md，並使用 get_observations 查詢本地快取資料庫中與未完成任務相關的歷史共識與架構決策。

實戰指令：

get_observations(query: "database refactor")

步驟 3：接續 Tasks 實作與編譯

依照拉取出來的記憶（如「已決定使用 EF Core，廢棄 Dapper」），AI 會直接使用符合新規範的代碼進行實作，免去重複修改的摩擦。

實戰指令：
```
/opsx:apply
```

步驟 4：每日任務總結與記憶寫入

在當天工作結束或 Feature 實作完成後，將今日的核心改動背景與除錯收穫，顯式寫入長期記憶。

實戰指令：

save_observation(key: "payment_refactor_done", value: "已於 7-16 將 PaymentService 升級為非同步，所有上游呼叫已 await。")

v13.18.1～v13.24.1：長會話的 Runtime 邊界

長週期工作除了「記得昨天做什麼」，還要處理 observer 與 worker 的生命週期：

Observer 保持 silent / no-contact，不干預被觀察 session。
Subscription quota 已耗盡時，quota breaker 進入 cooldown，只允許單一 probe，不要每次 tool call 都重試。
Worker 異常先執行 npx claude-mem restart，確認 successor PID 與 readiness，而不是只看 port 還在。
Marketplace 若曾安裝 v13.24.0，升到 v13.24.1 後再開新 session，避免舊 bundle version mismatch。

這些 runtime hygiene 能避免「記憶系統本身」成為長週期開發的不穩定來源。