Govern · Reliability contract
重試與 Replay Govern 工作
Govern 用三種不同機制處理三種問題，不應把它們視為同一顆通用的重試按鈕。
| 機制 | 用途 | Side effect |
|---|---|---|
| Delivery retry | 從暫時性的 transport 或 downstream failure 復原 | 可能使用相同 identity 重送 request |
| Idempotent reconciliation | 讓重複 delivery 收斂到同一筆 record | 回傳或更新同一筆 logical record |
| Fixture replay | 重新評估已捕捉的 contract case | 無；只做離線驗證 |
Delivery 與 Reconciliation Identity
| Surface | Stable identity | 必須維持的行為 |
|---|---|---|
| Provider webhook | Provider、tenant、channel 與 message ID | 相同 event 不會建立第二個 turn |
| Host tool call | Correlation、causation 與 idempotency ID | 重試時保留所有 ID |
| Proposal sink | Proposal ID 或 proposal idempotency key | 建立或回傳唯一一筆 Host record |
| Lifecycle callback | Proposal 與 callback idempotency key | 只記錄一筆 lifecycle fact |
| Execution receipt | Permit 與 idempotency key | 回傳既有 receipt |
| Witness 或 reversal event | Organization 與 idempotency key | 回傳既有 evidence event |
Govern 會為 inbound provider webhook 保存 processing receipt，包括 provider identity、status、attempts、last error 與 completion time。Proposal 也會在 sink delivery 前先保存，因此 delivery failure 不會刪除 proposal。
如何決定是否重試
如果 timeout 或 transport failure 使結果不確定，請使用相同 idempotency key 重試同一個 logical request。不要只因 client 沒收到 response 就產生新的 key。
請依 problem code 判斷處理方式，不要只看 HTTP status：
| 結果 | Client 行為 |
|---|---|
Transport failure 或 5xx | 使用相同 key 與有限的 backoff 重試 |
401 unauthorized 或 invalid_signature | 修正 authentication；不要盲目重試 |
404 *_not_found | 修正引用的 identity 或呼叫順序 |
400 missing_*、invalid_* | 修正 contract payload |
409 idempotency_key_conflict | 停止；相同 key 已搭配不同內容使用 |
422 host_evidence_rejected | 檢查 authority 或 evidence scope |
Tonetify 目前尚未為每個 Govern surface 公開統一的 retry budget、backoff schedule 或 dead-letter recovery contract。目前穩定的承諾是：在已公開 idempotency identity 的介面上，重複請求會收斂。
Fixture Replay 不是 Production Re-execution
已捕捉的 workflow fixture 情境會用目前的 verifier 與 proof builder 重新評估記錄下來的 JSON input：
mix tonetify.governed_action.replayReplay 是 pure contract validation。它不會讀取 database、不會呼叫 Host、不會執行 mutation、不會簽發 permit、不會建立 credential、不會套用 policy candidate，也不會重試失敗的 production job。
Fixture metadata 可以保留 authority evidence 或 policy candidate 供人審查。Replay 不會因此建立 authority 或將 policy 正式化。
目前的邊界
已捕捉的 Golden Loop evidence 可以作為 replayable proof artifact，但它不是 public replay API，也不是 production re-execution engine。Live permit-backed mutation 與公開的 operational recovery policy 仍屬於產品化工作。
下一步：查看目前的驗證邊界。