桌面更新链路至少包含版本发现、比较、下载、验签和安装。很多故障发生在第一步，却因为后面使用成熟更新框架而被忽略：应用拿到的是空 feed，自然会得出“没有更新”。
把版本发现和安装拆开
分别记录 feed 请求结果、解析出的最新版本、当前版本和最终决定。空响应、格式错误、网络失败与“确实没有新版本”必须是四种不同结果，否则用户只会看到模糊的无更新提示。
后台检查要安静，手动检查要有答案
后台网络失败可以稍后重试，不应频繁打断用户；用户主动点击检查时，则应说明检查失败、当前版本和可访问的发布页，而不是假装一切最新。
稍后提醒应绑定具体版本
用户跳过或推迟的是某个版本，不是永久关闭更新器。保存 snoozedVersion 和到期时间；出现更高版本时重新提示，避免一次“稍后”让所有未来版本消失。
旧版本边界不能靠新代码修复
如果已安装版本根本无法发现新 feed，新版本里的修复无法自动到达它。官网、GitHub Release 和安装文档必须明确给出一次性手动升级路径，这是更新系统的一部分。
测试真正的交付链路
- feed 正常、为空、损坏和超时。
- 后台检查与手动检查的不同反馈。
- 版本比较、稍后提醒和跨版本恢复。
- 签名失败、下载中断和安装回滚。
- 从一个真实旧版本升级到当前稳定版。
Agent Island 的 macOS 更新验证细节见可验证的 macOS 更新；当前稳定安装包统一发布在 GitHub Releases。
需要记录的可观测字段
一次检查至少应记录触发方式、feed URL、HTTP 结果、解析出的版本、当前版本、比较结果和最终动作。日志中不要包含凭证，但要能区分 DNS、超时、空正文、签名字段缺失与真正的无更新。
旧安装的恢复方案
官网应保留一个长期稳定的 releases/latest 入口，并在已知受影响版本旁明确说明需要手动下载一次。修复发布后还应实际启动旧安装，验证它能否发现新版本；只测试最新版对最新版，无法覆盖被困用户。