同一份现场巡检记录在手机和大屏设备上使用时，最容易出现两类相互独立的问题。其一是窗口宽度变化后，输入项被重复创建或次序错乱，使页面把已有值写到错误的字段中。其二是草稿长期积累后，开发者试图按时间直接删除旧记录，结果把还没有确认保存的内容一起清掉。FormContinuity的收尾工作，需要同时解决布局变化与数据生命周期，但必须让两者保持清晰边界。 继续沿用前一章已经合并并保存的site-check

一份巡检草稿能够保存并恢复，不等于它已经解决多端连续编辑。手机保存之后，平板可能根据稍早的记录继续输入；两份草稿的修订号甚至相同，却分别包含不同内容。若把收到的整份记录直接覆盖本地记录，用户可能失去刚写完的问题说明。FormContinuity在前两章建立了稳定字段键、修订号和串行保存，本章要处理的是两个编辑分支如何回到同一份可解释的业务记录。 继续使用site-check现场设备巡检表：sche

表单编辑中最容易被忽视的时刻，是用户离开当前页面的那几秒。输入框里已经写好内容，页面跳转后组件被重新创建，如果草稿状态只存放在页面变量中，返回时就可能看到旧字段值。对现场巡检而言，反复录入同一段设备描述不仅浪费时间，还可能让后续记录出现不同版本的事实。页面切换需要一套明确的保存承诺，而不是依赖某个组件是否仍然留在内存中。 FormContinuity继续沿用上一章的site-check巡检草稿：s

现场巡检表单往往要在不同尺寸的窗口中使用。录入人员可能先选择现场位置，随后补充故障描述，再调整优先级。如果页面直接把三个输入框的显示文案当作数据字段，后续更换语言、调整文案或增加宽屏布局时，同一项数据就容易被写入不同位置。表单的第一步不是设计按钮颜色，而是建立可以长期稳定识别的字段主键。 FormContinuity以“现场设备巡检”为业务主线。首个版本只收集现场位置、问题摘要、优先级三项信息，使

发布前最难处理的情况，往往不是找到某个孤立错误，而是几位开发人员分别修复了权限、资源、签名和产物问题，却无法回答交付包究竟引用哪次配置、哪些问题已经关闭、还缺少什么核对。一个只显示红绿图标的看板无法支撑后续复盘。ReleaseGuard此前把配置模型、构建产物、隐私用途、多语言资源、签名引用和问题闭环拆成六种检查对象，现在需要把这些对象串成一份可以追溯到版本快照的审计索引。 工程基线仍为com.e

当三方库完成适配、回归和来源核查后，工程往往还面临一个更难回答的问题：候选能力究竟应在什么条件下接管现有业务，又该在什么条件下迅速退出。直接把依赖版本从一个整数改成另一个整数，无法覆盖跨模块引用、正在进行的异步请求、静态资源回退和后续维护账目。LibraryBridge的前七篇已经把这些事实拆成独立记录，收尾时需要把它们重新连接为一条可执行的决策链。 当前稳定记录为@ohos/lottie解析版本

版本迭代到发布前夕，风险并不只来自新功能本身。即使代码完成了修改，旧版本产生的配置记录、资源索引和业务草稿仍然可能采用另一套字段结构。只比较versionCode，无法解释旧数据能否被新业务正确读取；只准备旧安装包，也不足以处理用户数据已经迁移的情况。因此，发布门禁必须同时记录版本快照、迁移步骤和异常后的业务回退路径。 ReleaseGuard前六篇固定了com.example.releasegu

三方库适配完成后，代码看似稳定，依赖来源却可能发生变化。一个模块的声明版本范围没有修改，实际解析的内容仍可能因安装环境、锁文件更新或本地模块调整而不同。对于持续交付的项目，除了检查接口与业务行为，还要把这次使用的具体包、取得路径、文件摘要和许可证信息连成一份可复核的清单。LibraryBridge在前六篇中已经建立了依赖画像、模块适配边界、统一异步结果和资源清理契约，现在需要补齐这条供应链记录。

应用准备进入发布阶段时，常常同时存在几个看似很小的问题：多语言资源少了一个键，权限用途说明仍待补齐，签名文件引用需要人工确认，产物摘要也还没有入库。如果把它们散落在聊天记录和临时表格中，版本负责人很难判断哪些问题已经修复、哪些可以复核、哪些会继续阻止交付。ReleaseGuard的任务就是让这些分散信息汇聚为同一份版本快照和一套可追踪的质量门禁。 一、沿用已有发布快照，不重新开始 工程继续使用co

三方库升级最麻烦的环节，往往不是修改一个版本号，而是确认它是否改变了应用已经依赖的行为。同一个方法继续存在，并不意味着错误码、异步结束时机、回调次序和资源清理规则仍然相同。LibraryBridge此前已经把业务页面与动画实现隔离：页面只认识AnimationBridge，适配器由RegistryAnimationAdapter选择，bridge_utils承担数据规范化。现在要在这个基础上给依赖