第二天，周野把一塊板放在傳送端，一塊板放在接收端，中間隔著完整的飛行模擬鏈路。
他不讓人先改軟體，而是讓每個動作留下獨立標記：命令到達、遠端校驗透過、狀態寫入可保留區、回執發出、傳送端確認收到。五個動作不能再被一行“通訊成功”糊成一團。
第一輪重放，前三個標記亮了，第四個沒有。接收端的狀態已經寫穩，回執卻在介面供電切換時丟失。周野鬆了半口氣：遠端沒有漏做命令，只是沒能把完成的事實告訴傳送端。
接收端工程師想把回執傳送動作提前，放到狀態落盤之前。林浩立刻指出矛盾：那樣回聲可能先回來，遠端狀態卻還沒儲存。電源若恰好在中間斷開，地面會以為下一階段可用，遠端醒來卻沒有相應記錄。
周野把順序寫在試驗卡上：先完成，再保留，最後回話。三步中任一步失敗，都要留下可辨認的狀態，而不能用一個綠色圖示把剩餘兩步順手帶過。
可飛控負責人提醒，即使這一輪是回執丟了，也不能假設下一次同樣如此。若遠端沒執行，傳送端只看見沉默，兩種情況在舊介面上一模一樣。
“所以要把沉默拆開。”周野說。
他們給接收端加一份獨立事件序號。每個命令只對應一個序號，狀態先寫穩，再生成回執；傳送端沒收到時可以詢問序號狀態，而不是盲目再發一條可能重複執行的命令。
林浩拿門禁刷卡打比方：“刷了一次，螢幕沒亮，你再刷一次，門可能只該開一回。”陳大川說他家小區門禁沒這麼高階，常常刷兩次才認人。梁師傅提醒他們別把火箭的後續動作也做成“多刷幾次總會開”。
退役遙測板被拆解檢測，仍能使用的儲存單元與隔離介面各有一半。系統能把兩塊板的合格部分合在一起，但周野先把失敗板上的舊資料徹底隔離，避免上一臺裝置的事件序號跑進新箱。
質量組為每塊板建立新舊序列號對照表。退役前的失效部位、重構後的複測專案和實際裝入的位置一一對應。誰若只看到“重構成功”四個字，卻不知道哪一半曾經損壞，就無法判斷下一輪故障該從哪裡查起。
梁師傅檢查接外掛時發現兩塊板的定位缺口不同。系統可以修正，但外殼上若仍留著舊標記，工人可能把新模組當成舊型號拿去別處。周野要求重構同時更新物理識別牌，能插上不是唯一的驗收標準。
【檢測到可重構遙測回執模組】
【重構目標：獨立事件留存與切電後回讀】
【消耗重構點：】
【當前重構點：】
重構後的模組沒有把所有資料都存進去，只保留完成確認所需的最小記錄。儲存越多，越容易在短暫切換裡把時間浪費在無關細節上；該留下的，是序號、結果和遠端自身的狀態。
質量組做斷電試驗，第一輪過了，第二輪卻出現一條舊序號重放。林浩追查到測試指令碼，它在恢復供電後自動補發上一條查詢。模組正確回答舊事件，介面卻把這個回答當成新確認。
負責介面的工程師起初不服，說回執內容是真的。周野把新舊任務編號放在一起：“昨天的車票是真的，也不能拿它進今天的站。”介面顯示的資料必須帶著發生時的身份，不能只看一句“完成”就替當前任務蓋章。
他們把舊序號重放三次，模擬備鏈路延遲、控制器重啟和記錄伺服器亂序。三次都只進入歷史日誌，沒有給當前階段加一盞綠燈。這幾輪看似沒推進試驗，實際上把最難解釋的一類假成功擋在門外。
周野讓軟體同時比對任務週期與事件序號。舊週期的回覆可以存檔，不能給當前階段亮綠燈。這樣既沒有丟證據，也不會把昨天的回答拿來證明今天已經完成。
第三輪開始，他們故意在五個動作的不同位置切電。命令未到達、已到達未寫穩、已寫穩未回執、回執已發但傳送端未收，各有不同的恢復路徑。最危險的“只知道對面沉默”被拆成幾種可查狀態。
周野把傳送端的自動重試次數限制住，真正的不確定狀態要求地面或飛控按預案處理。系統不準為了讓螢幕儘快變綠，擅自把不可逆動作重複一遍。
試驗主管要求預案不能只寫“人工確認”。值班員拿不到拆開裝置的機會，必須知道能檢視哪兩路獨立證據、等多久、何時停止下一階段。飛控組把這些條件寫成清楚的操作欄，周野讓沒參與研發的夜班人員照欄演練一次，避免手冊只對作者自己有用。
遠端回執終於在連續切換中穩定出現。陳大川看著新介面的灰、黃、綠三色：“以前綠燈只有嘴，現在綠燈總算有簽字了。”
但周野沒有讓它進入飛行配置。模組由兩塊報廢板重構，能扛一次切電，不代表能扛溫度迴圈、振動和長時間執行。下一章要讓這聲“收到”在最難的條件下仍能留下來。
