保留期限、法律保留與 purge 證據

保留政策防止 Custom Tables 證據遭到銷毀，不是資料列封存機制，不會讓一般編輯變成不可變更，也不會建立新的過帳流程。哪些寫入者可以操作，仍由既有權限、規則與動作政策決定。

證據的最短保留時間

PUT /private/module/custom_tables/{scope}/tables/{table_id}/retention-policy 接受 {"minimum_days": 30}。此處 {scope} 是 company、department/{department_id} 或 chatroom/{chatroom_id}；三種範圍都要求目前的資料表 moderator 權限。minimum_days 必須是 0–36,500 的整數，預設 0；不接受字串、浮點數、布林值或額外欄位。回應為 {table_id, retention_policy: {minimum_days}}。

政策存於資料表 settings，原生 IaC 匯出／套用會保留它。沒有政策代表零天；既存政策格式異常時採取保守拒絕。資料表建立、資料列建立／更新、歷史建立時間中，最新的時間必須已經過指定天數，才允許銷毀。這不是到期自動刪除資料列的計時器。拒絕為 409 detail.error: "ct.retention_active"，包含受保護資料表與期限提示。

受治理的法律保留

settings.legal_hold 由伺服器管理。資料表建立／更新與 IaC 都不能直接寫入或重播它；IaC 匯出也會省略它。只能透過 version-2、invoker authority、write mode 的 Command，使用以下資料表管理步驟變更：

{"kind":"set_legal_hold","name":"hold","table":"orders","active":true,"reason":"保留稽核證據"}

active 必須是布林值；reason 為 1–512 字元，且至少含一個非空白字元。程式最多可有 20 個這類動作，不能混合 insert／update／delete 或 child_collection 步驟或暫存資料列提案，也不能宣告資料列 effect_identity。執行者必須目前具備目標資料表的 moderator 權限；其他呼叫者會得到 403 與 detail.error: "ct.legal_hold_manager_required"（Changing a legal hold requires live table-manager authority.）。Backend 5.20.1 在執行 set_legal_hold Command 時會先回 HTTP 500，到不了這兩種結果；自 5.21.0 起它會執行，或以該 403 拒絕。授權 executor 會記錄 active、reason、command_id、changed_by、changed_at；一般 settings patch 不能代替此受治理動作。

啟用中的保留會以 409 detail.error: "ct.legal_hold" 阻止刪除資料表與不可逆銷毀。解除時也要執行另一個已授權的 set_legal_hold 動作，並提供原因。既存保留資訊異常時採取保守拒絕。此保護不表示其他資料列編輯已封存。保留期限／法律保留也會防止 CT 證據清理途徑刪除相關 Command execution 與 effect-identity 證據。

Purge 預覽的影響範圍

資料表與標籤 purge 預覽保留原有 tables、commands_to_delete、commands_affected、cross_table_impact、views、iac_state_rows、blockers，並新增型別明確、非負的 resource_counts：

attachment_blobs: "retained" 表示物件儲存 blob 與成本帳不會刪除。command_execution_evidence: "retained" 表示 Command execution 與 effect-identity 收據也保留，即使被 purge 資料表的資料列歷史已銷毀。不能把這些計數解讀成會清除上述保留資源。

ct.legal_hold、ct.retention_active 會列入預覽 blockers；只要有 blocker，ticket 與 expires_at 就是 null。執行會在資料表 guard 內重新檢查保護。標籤 purge 必須遵守每張表的保護，不能把整個系統的 purge 當成例外。

同步、一次性的同意 ticket

預覽所發、效期 15 分鐘的 ticket，只同意一次同步 purge，不是非同步 worker ticket。它綁定執行者、範圍、標的與結構指紋。預覽後資料列／歷史／run 計數增加，不會使 ticket 失效；設定或受影響結構集合變更才會。因此新寫入的資料列也可能被已同意的 purge 銷毀。

執行走到原子 ticket take 時，會在檢查執行者、標的與漂移之前消耗 ticket；遭拒的嘗試也會燒掉它。遇到 stale／missing／mismatched ticket 或消耗後的拒絕，請重新預覽。較早的路由權限／標的查詢可能在消耗前拒絕。尤其標籤回應名為 purge_blocked，不代表舊 ticket 還能用：該路由也可能把已消耗的 stale／missing-ticket 拒絕映射成這個名稱。

Purge 不可逆。既有生命週期邊界見資料表卡片、標籤卡片與軟刪除／歷史。這些契約描述已合併來源，不代表已部署或新完成線上驗收。