principle-separate-before-serializing-shared-state | 先拆共享輸出再考慮序列化
本頁以 pstack-claude 0.9.126 為基準。原文設定 user-invocable: false，通常由 poteto-mode 按需讀取。這裡的序列化是依序控制存取，不是把物件轉成 JSON。
定位與適用情境
當多個執行者可能修改同一檔案、分支、鍵值或狀態物件，先確認是否真的需要共享寫入目標。各自發布獨立事實時，分開輸出通常比立刻加鎖更直接。只有單一共享狀態是必要不變條件時，才結構性地序列化存取。
例如索引程序與監測程序都讀寫 state.json，前者更新 lastIndexed，後者更新 lastMeasured。即使欄位不同，兩者仍可能讀到舊版本，再各自整份覆寫，造成另一方的更新消失。
準備
- 提供兩個程序的狀態讀寫位置、啟動方式與報表讀取端。
- 列出每個欄位的寫入者及讀取者，確認索引與監測是否為可獨立發布的事實。
- 訂定報表一致性需求。若一定要同一時間點的共同快照，必須明列，不能假設拆檔後自然具有該保證。
操作步驟
- 追蹤共享可變狀態的讀取、修改、寫回流程。畫出兩個程序同時讀取舊
state.json的交錯順序，指出可能遺失哪個欄位。 - 先消除不必要的共享目標。讓索引程序獨占
indexer-state.json，監測程序獨占metrics-state.json。不要只在同一物件中分配不同欄位。 - 將合併移到報表讀取邊界，讀取兩份狀態並顯示各自時間。若確認需要共同快照或唯一序號，才為必要共享部分選擇單一寫入者、鎖定檔、循序階段或原子比較交換。
- 在隔離測試中讓兩個程序交錯更新，確認各自狀態都保留最新值。若使用同步機制，另驗證競爭時只有合法寫入能成功，不以「請勿同時執行」代替控制。
可直接使用的提示詞
套用 principle-separate-before-serializing-shared-state，檢查索引程序與監測程序共寫 state.json 的設計。
先列出讀寫流程與各欄位擁有者。
優先將獨立事實拆為 indexer-state.json 與 metrics-state.json，在報表讀取端合併。
若有真正需要單一共享物件的不變條件，指出證據，再提出結構性同步方法。
給出交錯更新的驗證案例與一致性限制。這次只交付方案，不啟動程序或修改共用檔。預期結果與驗收
- 每個獨立輸出都有唯一寫入者，並行更新不會互相覆蓋。
- 報表能同時顯示兩個來源的最新值，也明示兩份資料不一定屬於同一瞬間。
- 仍保留的共享寫入目標，都能說出不能拆分的原因及實際保護機制。
- 交錯測試可重現原本遺失更新的風險，並在新設計中檢查兩邊結果，而非只看程序是否結束。
限制與權限
常見誤用是未分析就加全域鎖，或認為不同 JSON 欄位不算共享。文字約定、排程習慣與提醒代理小心，都不是並行控制。
拆分輸出只消除不必要的共享，不自動保證跨檔交易或共同快照。也不能在未確認報表端的情況下改名、刪除原檔。本頁未操作任何並行程序或共享檔，讀者仍須取得實作與資料變更授權。