丁卓審周衡的簽名與確認邏輯，周衡審丁卓的回放指令碼。交叉檢查剛開始，丁卓便發現相容層把閘道器時間戳直接當成上海時間。樣本里前幾十條都是本地時區，看不出問題；介面說明卻允許帶偏移量，展會臨時系統也可能使用統一協調時間。
如果不改，頁面仍會有資料，跨時區來源的先後順序卻可能錯八個小時。
周衡把原始時間、偏移量和刻度雲接收時間分別儲存，不在適配層裡提前覆蓋。回放報告必須能看到客戶原值，也能按統一時間排序。
一點二十二分，第一輪程式碼凍結。
周衡離開螢幕休息四十分鐘，丁卓繼續跑已有用例，但不在這段時間合併任何修改。兩個人沒有因為倒計時縮短，就把原定的強制休息從記錄裡抹掉。
一點四十七分，回放在第三百九十一條停住。
那條測試事件沒有狀態值。舊介面卡會把空值寫成“正常”，新相容層則按最小原則拒絕替客戶判斷，把原始事件保留在隔離區，並返回欄位缺失。
瀾橋技術負責人確認，閘道器在出票任務剛建立時確實可能沒有最終狀態。把它當正常會掩蓋待處理訂單，直接丟棄又會讓時間線缺一段。
雙方在工單裡確定處理方式：允許狀態為空，頁面顯示“待來源更新”，以後收到同一業務序號的新狀態時新增一條記錄，不覆蓋最初事件。這個行為進入驗收樣本，不用口頭答案改程式碼。
周衡回來後審完變更，重新跑過空值、重複狀態和亂序到達。
凌晨三點十二分，兩千四百條事件第一次完整進入隔離環境。總數一致，閘道器確認位置也到了末尾，可報告裡有十七條事件順序異常。
檢查後發現，它們並非程式亂序，而是瀾橋的一臺模擬節點比標準時間慢了九十多秒。周衡沿用嘉禾專案已經驗證過的做法，保留來源時間，另記接收順序與時鐘偏差，不為了報告整齊篡改客戶原值。
三點四十分，網路中斷、程序重啟、重複隨機數、錯誤簽名和過期時間戳五組失敗用例跑完。相容層在任何校驗不透過時都停止解析，沒有一條錯誤事件進入正式試點記錄。
還剩最後兩項：由瀾橋重新簽發一組測試金鑰，從空環境獨立安裝；把完整回放再跑一輪，證明成功不是依賴兩個人電腦裡的快取。
客戶值守人員凌晨四點才能申請新金鑰。第二輪完整回放加結果抽檢至少需要三個小時，十點以前理論上仍有時間。
但相容層只是剛寫出的第一版。按照雙方清單，它還要在回放通過後保留一段穩定觀察，才能允許第二天的旁路聯調。把所有環節壓到十點前，唯一能省掉的就是觀察和複核。
瀾橋業務負責人提出一個折中辦法：凌晨回放通過後，先把相容層裝到生產旁邊，但暫時不向刻度雲傳送；十點開會時再打開出口。這樣頁面上看起來仍能按時上線。
丁卓檢查後搖頭。程式即使不向外發送，也會讀取生產事件、維護游標並寫本地快取。它一旦裝進去，安裝、啟動和解除安裝本身都已經是生產變更，不是“只放著”。更何況新版本還沒在一臺由客戶獨立準備的空機器上安裝過，執行所需許可權是不是最小也沒有複核。
周衡把拒絕寫進工單，沒有隻在電話裡說不行。他同時給出替代安排：原聯調照常由瀾橋驗證自己的票務主鏈，刻度科技提供隔離回放結果；相容層完成驗收後，再約獨立的旁路觀察視窗。這樣會失去十點那張刻度雲頁面，卻不會讓客戶把一個臨時程式當成已經核准的生產元件。
對方隔了幾分鐘才回復：“按隔離方案繼續。延期另說。”
周衡重新算完時間，沒有把那兩項刪掉。
丁卓盯著還剩幾個小時的倒計時，手指停在鍵盤上。
“接單的時候，是我說舊介面半夜能搞定。”
“是我籤的合同。”周衡說，“現在先讓客戶知道，別到十點才給他一個驚喜。”
他把已經完成的回放發給客戶。新簽名、重複處理和斷點恢復都已經跑通，這幾個小時做出來的東西，足夠替瀾橋省下一次等原廠排期的折騰。現在該談的是完整交付的時間，不是讓自己為客戶過期的附件買單。
他在交付狀態後面寫下新的預計時間。
按完整驗收條件，交付會跨過原定時點，至少延期一天。
