日期库改造在回归矩阵一致后仍有最后一道工程关口：锁定的究竟是哪份包、安装时实际取到了哪些文件，以及出现异常后能否回到此前的业务结果。前三篇把日期语义、跨时区转换和双驱动回归契约逐步固定下来，本篇收束为可追溯的版本治理流程。目标不是追求永远使用某一个库，而是在依赖替换时保留日期计算的可解释性、发布记录与可回退路径。 日期规则工作台继续以2026-10-28和Asia/Shanghai为常规输入，保留

日期工具库升级之后，最值得警惕的变化不一定来自接口重命名，而是相同输入被解析成不同的业务含义。上一章已经把日期划分为calendar-day、local-wall-time和instant，并约定对纽约夏令时跳过时刻返回gap、重复时刻返回overlap。现在需要把这些约定固化为回归矩阵：旧驱动与候选驱动各执行同一批输入，再从规范化输出、错误类别和持久化结果三个维度比较，而不是仅看界面上的日期字符

跨时区日期最棘手的问题往往不是把时间加减几个小时，而是用户输入的本地时刻并不总能指向一个确定的时间轴位置。同样写着“凌晨一点半”，在实行夏令时的地区可能出现两次；某些春季调表日的“凌晨两点半”则根本没有对应的瞬时值。如果应用直接构造一个没有偏移量的日期字符串，再交给设备当前区域设置解释，就可能让预约、审批或日程规则在另一台设备上产生不同结果。 本篇延续上一章的DateAdapter接口，进一步把c

在多设备应用中，一条业务记录可能同时包含合同签署日期、待办截止时刻和下一工作日。它们在界面上看起来都像日期，却不能共用一种解析方式。签署日期表达的是日历中的某一天；截止时刻表达的是时间轴上一个确定的瞬间；下一工作日还需要结合周末与节假日配置。若把三者都直接交给new Date()处理，输入是否带时区、设备当前区域设置、字符串宽松解析等差异就会渗入业务判断。日期规则库的集成应先定义输入和输出，再决定

合同核验工程的最后一个环节不是简单导出一页摘要，而是把条款版本、字段差异、复核责任和证据引用固定到同一份可重读的报告里。前七篇已经完成 service-agreement 的稳定条款编号、跨版本逐段对齐、金额和日期规则、宽屏三栏定位、双人修订冲突、离线核验记录以及 r2→r3 的迁移。到了收尾阶段，页面可以关闭，临时文档句柄可以释放，但 CL-02 和 CL-03 的待复核状态不能因报告生成就被改

公交换乘界面的退出与重新进入，表面上只是页面的打开和关闭，实际涉及路线选择、离线资料版本、筛选条件以及异步任务的重新组织。前七篇逐步建立了公交站点图、计划班次、候选路径、宽屏布局、离线资料合并、读屏顺序和异常恢复。此时如果直接保存整个页面对象，下次进入可能继续显示旧候选的“可用”标签；如果每次都清空，又会丢失用户正在查看的换乘方案。更稳妥的方式，是把需要长期保留的业务事实与短暂存在的页面资源彻底区

合同核验工作最容易出错的时间点，往往不是发现字段差异时，而是收到新版合同后继续使用旧版核验结论时。前六篇已经围绕 service-agreement 建立稳定条款编号、逐段差异、金额日期规则、宽屏三栏定位、双人修订冲突和离线记录包。现在合同从 r2 进入 r3，部分段落顺序发生变化，个别条款改写，还新增了资料保管条款。旧记录仍然需要保存，但每条记录能否引用新版文本，必须重新判断。 例如，CL-03

一条已经选中的公交换乘路线，并不会因为候选列表仍然能显示就持续有效。前六篇把市民中心、科技馆和图书馆组织为线路图，加入了计划班次、换乘约束、屏幕布局与读屏顺序，还用离线版本包更新站点资料。此时需要处理一个容易被忽视的变化：用户保存的路线 L1-0835>L2-0848 仍指向原来的车次，但科技馆 ST-B 的无台阶通行条件在新资料中出现分歧。如果仅显示原来的三十分钟行程，视觉上没有任何异常，

合同双人修订流程推进到线下会签环节后，真正需要传递的往往不是整份合同正文，而是一组经过定位的核验记录。前五篇已经建立 service-agreement 的稳定条款编号、r1与r2逐段对齐、金额日期规则，以及双人并行修订的冲突状态。当前的 CL-03 付款约定包含金额由120000.00元变为125000.00元、截止日期由2026-11-15变为2026-11-20两处字段变化；CL-02 验收

城市公交换乘页面最容易被忽略的并不是路径计算，而是同一条路线能否让不同阅读方式的乘客获得相同信息。此前的线路图已经把市民中心、科技馆与图书馆连接起来，候选路线保留了稳定键 L1-0835>L2-0848。当页面改成大字号，或者读屏服务按顺序读取卡片时，原先依赖颜色、图标和横向时间轴的表达就不够稳妥：蓝色线路与橙色线路需要有文字名称，换乘发生在哪个站、前后计划时刻以及是否存在通行条件变化，也必