背景
2026-06-06 兩個 session 並發（harness 整合 + Robinhood note）同時改 profile.md / inbox.md，push main 被拒、要手動解衝突。無資料遺失 （已手動解、兩邊內容都保留），但暴露一個原本四類缺陷（boot-miss / retrieval-miss / rot / merge-gap）沒涵蓋的問題。
這是這個記憶系統的第一筆非合成壓力測試 ，由 @user 指出（剛好示範了 Issue #6 R1「為什麼要用戶標的缺陷」——Claude 當下沒把它當缺陷）。
問題
profile.md 和 inbox.md 是單一熱檔 ，每個 session 的 sleep 都往同一個尾巴 append / 就地改 → 並發幾乎必撞 ，且衝突頻率隨並行 session 數上升。
兩種失敗：
明顯衝突 ：push 被拒、要手動解。成本是時間，不丟資料。靜默 auto-merge（更危險） ：git 對「不同行」的改動會自動合併。這次 profile.md 第 19 行被靜默選了一邊（剛好沒撞所以無損），但若兩 session 改同一行 不同內容，git 會無聲讓一邊覆蓋另一邊 ，不跳衝突、最難發現。
候選解（先記不改，反膨脹原則）
inbox.md 拆檔 ：它是 append-only，改成每日 / 每 session 一檔（inbox/2026-06-06-<slug>.md）就天生免衝突 。代價：grep 回憶要掃資料夾（本來就會 grep，影響小）。profile.md ：就地改的索引，沒法拆。靠（a）保持小（接 Issue 遞迴改進 harness:讓這個 repo 從「會記憶」進化到「會改進自己的記憶流程」 #6 寫前先 git fetch （這次已當場套用，有效）。寫入紀律 ：sleep 寫記憶檔前一律 fetch + rebase，把「single writer」假設補上。
與其他 issue 的關係
待決定（交 /meta-review）
要不要把「熱檔並發寫衝突」正式立為第五類缺陷 ？
還是視為 merge-gap 的子類就好（反膨脹：不輕易加類別）？
現況判斷
目前單人使用，並發是偶發 → 先放著不改 ，等真的常撞再處理，符合不過度設計。本 issue 當追蹤點。
https://claude.ai/code/session_01WceUtfUb5ibAdVXKVQCwQi
背景
2026-06-06 兩個 session 並發（harness 整合 + Robinhood note）同時改
profile.md/inbox.md，push main 被拒、要手動解衝突。無資料遺失（已手動解、兩邊內容都保留），但暴露一個原本四類缺陷（boot-miss / retrieval-miss / rot / merge-gap）沒涵蓋的問題。這是這個記憶系統的第一筆非合成壓力測試，由
@user指出（剛好示範了 Issue #6 R1「為什麼要用戶標的缺陷」——Claude 當下沒把它當缺陷）。問題
profile.md和inbox.md是單一熱檔，每個 session 的 sleep 都往同一個尾巴 append / 就地改 → 並發幾乎必撞，且衝突頻率隨並行 session 數上升。兩種失敗：
profile.md第 19 行被靜默選了一邊（剛好沒撞所以無損），但若兩 session 改同一行不同內容，git 會無聲讓一邊覆蓋另一邊，不跳衝突、最難發現。候選解（先記不改，反膨脹原則）
inbox/2026-06-06-<slug>.md）就天生免衝突。代價：grep 回憶要掃資料夾（本來就會 grep，影響小）。git fetch（這次已當場套用，有效）。與其他 issue 的關係
meta/defects.md@user。待決定（交
/meta-review）現況判斷
目前單人使用，並發是偶發 → 先放著不改，等真的常撞再處理，符合不過度設計。本 issue 當追蹤點。
https://claude.ai/code/session_01WceUtfUb5ibAdVXKVQCwQi