丁卓审周衡的签名与确认逻辑，周衡审丁卓的回放脚本。交叉检查刚开始，丁卓便发现兼容层把网关时间戳直接当成上海时间。样本里前几十条都是本地时区，看不出问题；接口说明却允许带偏移量，展会临时系统也可能使用统一协调时间。
如果不改，页面仍会有数据，跨时区来源的先后顺序却可能错八个小时。
周衡把原始时间、偏移量和刻度云接收时间分别保存，不在适配层里提前覆盖。回放报告必须能看到客户原值，也能按统一时间排序。
一点二十二分，第一轮代码冻结。
周衡离开屏幕休息四十分钟，丁卓继续跑已有用例，但不在这段时间合并任何修改。两个人没有因为倒计时缩短，就把原定的强制休息从记录里抹掉。
一点四十七分，回放在第三百九十一条停住。
那条测试事件没有状态值。旧适配器会把空值写成“正常”，新兼容层则按最小原则拒绝替客户判断，把原始事件保留在隔离区，并返回字段缺失。
澜桥技术负责人确认，网关在出票任务刚创建时确实可能没有最终状态。把它当正常会掩盖待处理订单，直接丢弃又会让时间线缺一段。
双方在工单里确定处理方式：允许状态为空，页面显示“待来源更新”，以后收到同一业务序号的新状态时新增一条记录，不覆盖最初事件。这个行为进入验收样本，不用口头答案改代码。
周衡回来后审完变更，重新跑过空值、重复状态和乱序到达。
凌晨三点十二分，两千四百条事件第一次完整进入隔离环境。总数一致，网关确认位置也到了末尾，可报告里有十七条事件顺序异常。
检查后发现，它们并非程序乱序，而是澜桥的一台模拟节点比标准时间慢了九十多秒。周衡沿用嘉禾项目已经验证过的做法，保留来源时间，另记接收顺序与时钟偏差，不为了报告整齐篡改客户原值。
三点四十分，网络中断、进程重启、重复随机数、错误签名和过期时间戳五组失败用例跑完。兼容层在任何校验不通过时都停止解析，没有一条错误事件进入正式试点记录。
还剩最后两项：由澜桥重新签发一组测试密钥，从空环境独立安装；把完整回放再跑一轮，证明成功不是依赖两个人电脑里的缓存。
客户值守人员凌晨四点才能申请新密钥。第二轮完整回放加结果抽检至少需要三个小时，十点以前理论上仍有时间。
但兼容层只是刚写出的第一版。按照双方清单，它还要在回放通过后保留一段稳定观察，才能允许第二天的旁路联调。把所有环节压到十点前，唯一能省掉的就是观察和复核。
澜桥业务负责人提出一个折中办法：凌晨回放通过后，先把兼容层装到生产旁边，但暂时不向刻度云发送；十点开会时再打开出口。这样页面上看起来仍能按时上线。
丁卓检查后摇头。程序即使不向外发送，也会读取生产事件、维护游标并写本地缓存。它一旦装进去，安装、启动和卸载本身都已经是生产变更，不是“只放着”。更何况新版本还没在一台由客户独立准备的空机器上安装过，运行所需权限是不是最小也没有复核。
周衡把拒绝写进工单，没有只在电话里说不行。他同时给出替代安排：原联调照常由澜桥验证自己的票务主链，刻度科技提供隔离回放结果；兼容层完成验收后，再约独立的旁路观察窗口。这样会失去十点那张刻度云页面，却不会让客户把一个临时程序当成已经核准的生产组件。
对方隔了几分钟才回复：“按隔离方案继续。延期另说。”
周衡重新算完时间，没有把那两项删掉。
丁卓盯着还剩几个小时的倒计时，手指停在键盘上。
“接单的时候，是我说旧接口半夜能搞定。”
“是我签的合同。”周衡说，“现在先让客户知道，别到十点才给他一个惊喜。”
他把已经完成的回放发给客户。新签名、重复处理和断点恢复都已经跑通，这几个小时做出来的东西，足够替澜桥省下一次等原厂排期的折腾。现在该谈的是完整交付的时间，不是让自己为客户过期的附件买单。
他在交付状态后面写下新的预计时间。
按完整验收条件，交付会跨过原定时点，至少延期一天。