決定改了，怎麼更正或忘記舊 Memory？

專案決定改了，舊 Memory 可能還在。我們想知道工程師在採用新版本前，實際能檢查哪些狀態。測試使用從固定原始碼啟動的本機開發預覽（source-run local preview），以及合成的 project-scoped 決定。Cairn（cairn.ink）把私人 Memory 和 Knowledge Card 分開；更正 Memory 不會自動把內容發布到共享 Collection。

資料庫在 local 環境，但原生 Claude client 使用既有訂閱，所以這不是離線測試。本次沒有 hosted Cairn write。

兩種不同的證據

第一輪使用 official MCP SDK 2.0.0 harness；MCP server runtime 是 Node 24.22.1。它對固定 source commit ad274b6 的 adapter 跑了 14 個 protocol cases，共 19 次工具呼叫、8 個新的 MCP server processes。14 個案例都通過，harness exit 0。correct_memory 使用正確 revision 後，原本 revision 1 的同一筆記錄升到 revision 2，並建立新的 Source Receipt。沿用 revision 1 再更正或忘記，都回傳 revision_conflict。Protocol 後續的 forget 呼叫對同一筆已更正記錄使用 expectedRevision 2；forget 後立即 inspection 回 memory_not_found，新 process 的 memory list 和來源清單則為空。

這是 adapter protocol 結果，不是原生用戶端測試。沒有設定模型時，keyless semantic-recall probe 如預期回傳 model_not_configured。read_memory_sources 只是來源清單，不是語意檢索。工具的能力界線寫在固定版本的 MCP 說明。

之後另做了一批 Claude-only 原生測試，仍是在同一個本機開發預覽。12 個合成案例使用 12 個不同工作階段，共有 20 次明確工具呼叫。MCP server runtime 是 Node 24.22.1；Claude Code 2.1.319 回報模型 claude-opus-5-5。每個 CLI process 都 exit 0，執行 wrapper exit 0，證據 audit 也 exit 0。另一輪 read-only event audit 重新檢視既有紀錄，沒有新增原生工具呼叫；audit 通過。另外用兩個 fresh server process（共 4 次呼叫）做的 SDK 檢查也確認了後置狀態。

在這批 Claude 測試裡，更正沿用同一個 Memory ID，從 revision 1 升到 2。新工作階段讀到更正後的記錄和目前來源。新的 Source Receipt 出現在 current-admitted view，舊 receipt 沒有出現在這份清單。拿舊 revision 重送 correction 或 forget 都發生衝突，revision 2 沒有被改掉。另一筆暫用記錄執行 forget 後回傳 true；新 process 的 inspection 回 memory_not_found，來源清單是空的。錯誤 project controls 也都沒有讀到該筆記錄。

這裡的「忘記」指什麼

新 process 的讀取結果表示，logical forget 後，這筆記錄已不在 adapter 當前可讀的來源範圍。測試沒有確認 SQLite 頁面、journal、snapshot 或 backup 裡的資料是否物理清除。revision 和 local state 的規則，見固定版本的local store contract。Source Receipt 可以幫忙追來源，不能證明一項決定現在仍然正確或適用。

重做原生用戶端檢查時，請建立新的合成資料庫和兩筆不同的 project-scoped 合成測試資料。先存下舊決定，檢查 scope 與 receipt；用精確的 memoryId 和 expectedRevision 更正，再從新工作階段檢查同一筆記錄。接著用舊 revision 重送一次，確認 stale request 會衝突。第二筆資料專門測 forget，再從新 process 檢查精確 ID 和目前來源清單。預期答案不要放進接收端提示或 repo。這是重現步驟，不代表每個用戶端都有相同控制方式。

這次沒有測到的事

這裡成功的原生 mutation 測試只涵蓋 Claude Code。前一次來源接續測試用的是 Codex 0.166.0。該批原生測試原規劃 14 個工作階段，實際嘗試 8 個（7 個通過、1 個 blocked），另外 6 個未執行。8 個 CLI invocation 都 exit 0，但 batch wrapper exit 1。該批裡 Codex 的更正呼叫走到 approval gate，因 approval policy 設為 never 而 blocked，沒有成功修改；read-only check 確認舊 revision 沒變，該批 native forget 也沒有執行。之後的 CLI capability check 使用 Codex 0.167.0；它的互動式 TUI 沒有 exec 測試使用的單次呼叫隔離選項，所以我們沒有在那套設定下再嘗試 mutation。我們沒有改全域設定或放寬核准政策，也把被擋下的嘗試和後來的 Claude 測試分開記錄。

Hosted 同帳戶行為、語意 recall 品質、自動擷取和自動回想都還沒測。Local owner 和 project 設定不是 hosted 帳戶認證。以上結果只描述本機開發預覽裡的合成資料。

想確認來源和管理私人 Memory，可以看Memory 來源控制的 Learn 指南。