晚上十一點二十八分，周衡把舊介面卡從測試鏈路裡摘了下來。
容器沒有刪除，日誌和配置也沒有改。他先固定映象編號、測試憑據版本和十條失敗事件的佇列位置，再讓丁卓匯出網路記錄。連線成功與事件拒收必須同時留下，不能等修好以後只保留一張綠色頁面。
瀾橋的生產環境沒有受到影響。
舊介面卡用的是隔離佇列和測試金鑰，刻度雲也只連向測試地址。現在停掉它，損失的是剩餘十個多小時，不是數萬張真實票。
客戶業務負責人又問了一次：“第二版簽名能不能先在生產閘道器旁邊試？只讀，不改訂單。”
“簽名請求本身也會佔用閘道器介面，還可能推進事件游標。”周衡說，“相容層沒透過回放以前，不進生產。只讀不等於沒有副作用。”
對方沒有再催開放許可權，只要求每小時收到一次狀態。
周衡把第一條狀態寫得很短：舊介面卡失效；生產未接入；改用最小相容方案；下一次更新時間零點三十分。
不是“正在緊急修復”，也沒有寫預計幾分鐘恢復。
周衡放棄修補舊包，直接寫一個只覆蓋本次試點的相容層。舊介面卡帶著十幾個用不上的功能，真正需要的是四個欄位和可靠的確認過程。
“廠商要是明天才回呢？”丁卓問。
“那我們先把能交的做出來。”
十一點四十七分，瀾橋發來簽名說明的正式版本。
第二版在客戶端標識和時間戳之外，增加了隨機數、請求路徑、正文摘要和一次性序號。五項內容要按固定順序拼接，路徑必須保留查詢引數，閘道器收到請求後還會檢查時間偏差與序號是否重複。
丁卓核對客戶樣例，周衡負責請求與確認。兩個人把任務拆開，新介面的資料很快進入同一套測試流程。
零點零六分，新相容層發出第一條請求。
閘道器返回簽名錯誤。
不是版本不支援，而是摘要不一致。周衡把本地參與簽名的五段內容逐項列印成不可還原金鑰的校驗記錄，與客戶示例對照。前四段一致，最後的請求路徑少了一個經過編碼的佇列引數。
舊說明只籤路徑主體，第二版要連排序後的查詢項一起籤。程式實際訪問的地址正確，簽名使用的卻是編碼前字串。
周衡沒有增加一個“簽名失敗就忽略查詢項”的相容開關。他把路徑規範化集中到同一處，讓發出的地址和參與簽名的地址由一個物件生成，再補上空引數、中文佇列名和引數換序三組測試。
零點二十九分，第一批十條事件進入刻度雲。
來源系統、事件型別、發生時間和狀態都能識別，頁面終於出現數字。瀾橋業務負責人發來一句“是不是可以了”，周衡只回復第一項透過，確認與失敗恢復仍在測試。
丁卓故意重放同一批資料。
閘道器拒絕了複用的隨機數，符合文件要求。換用新隨機數重新拉取，刻度雲保留第一次接收序號，沒有生成第二組事件。相容層收到確認後把測試游標從零推進到十，再次啟動時從十一開始。
接著，他在刻度雲返回確認前切斷網路。
相容層沒有先向閘道器報成功，十條事件仍留在未確認區。網路恢復後，它用新簽名重新發送；刻度雲依據事件編號識別重複，返回原確認結果，閘道器游標這才繼續推進。
這些步驟比把兩千四百條一次灌進去慢得多，卻是在確認重試不會把事件吞掉。
凌晨一點，按前夜排期時定下的規則，兩個人交換檢查。
