本篇是故事五的「重現」篇。

本篇要回答：非同步命令的生命週期該怎麼建模，才能讓「完成」變成可驗證的狀態而不是一句宣稱？

當時發生了什麼

Day 22 的收據攤開後，自然長出一條狀態鏈——把每張收據升級成一個明確的狀態：

requested        呼叫端提出要求
  ↓
accepted         系統受理，command_id 誕生
  ↓
published        訊息已發布
  ↓
delivered        訊息已送達訂閱端
  ↓
processing       應用程式處理中
  ↓
device_accepted  設備接受命令
  ↓
executed         動作已執行
  ↓
state_confirmed  外部狀態已確認符合要求

我原本怎麼判斷

在畫出這條鏈之前，系統裡的「狀態」其實只存在於各元件的 log 裡，靠人腦在事故時拼湊。重現一次指令的旅程要開四、五個視窗、憑時間戳記猜哪筆對哪筆——因為沒有一個貫穿全程的身分證。

我怎麼查證或重現

建模時每一層都要回答六個問題，這是這條鏈能不能用的關鍵：

• 這個事件由誰產生？（不同節點的時鐘與可信度不同）
• 它可以證明什麼？（對照 Day 22 的效力表）
• 它不能證明什麼？（防止收據被擴張解讀）
• 用哪一個 ID 對應？（command_id 必須從 accepted 一路帶到 state_confirmed，斷了就無法對帳）
• 逾時之後狀態如何表示？（停在原地？標記 timed_out？——沒有答案的話，逾時的命令會變成幽靈）
• 重試是建立新命令，還是沿用冪等識別？（決定重複執行的風險與去重方式）

有了這條鏈，Day 21 的介面之爭可以精確改寫：舊介面把 success = True 允許蓋在任何一層（實作者蓋在 published，需求方以為蓋在 state_confirmed）；新模型強迫每個狀態自報層級，誰也不能替下一層發言。

（去識別化說明：狀態命名為通用建模示意；實際系統的狀態粒度依協定與設備能力調整，原則不變。）

區分證據等級。已確認事實：缺乏貫穿 ID 時跨元件對帳只能靠時間戳猜測，這是可普遍重現的困境。合理推論：八狀態粒度對多數設備控制場景足夠，粗於此會回到擴張解讀，細於此維運成本上升。

今天留下什麼方法

本篇結論：

非同步系統不是沒有結果，而是結果要沿著事件軌跡回來，不能在第一步就被預支。

下一篇（Day 24）分析衝突的根源：不是 Pub/Sub 不能回應，是我們把整個生命週期硬塞進一個 bool。