新程序能启动，就算升级成功了吗
把候选、试运行、确认和回退画成状态变化，再通过重新启动文件模型观察每个分支。
1 · 启动成功只走完了一部分
新应用可能在进入 main 后才出现内存错误、设备初始化失败或看门狗复位。仅检查镜像格式和摘要，不能证明业务能够持续工作。因此新版本先试运行，满足健康条件后再确认。
成熟启动方案会记录未确认试运行，在下次复位时据此决定回退。MCUboot 的测试启动、确认和回退机制可以作为设计参考，实际采用方式要按目标端配置。
2 · 用状态说明每次启动选择
| 状态 | 下一次启动的选择 |
|---|---|
| 候选未收全 | 启动旧确认内容，不采用候选。 |
| 完整候选待试运行 | 候选有效则试运行，保留旧确认内容。 |
| 试运行未确认又启动 | 回退到旧确认内容。 |
| 新内容已经确认 | 继续使用新确认内容。 |
设备应能从持久状态推断下一步，而不是只用 RAM 中“刚刚更新了”一个标志。状态变更时掉电要有明确恢复规则，不能让两份记录互相矛盾。
3 · 在文件模型中观察回退
接前篇 finish；第一次试运行，未确认的第二次启动回退
python ota_files.py --root update_practice boot
python ota_files.py --root update_practice boot首次 boot 把候选设为 active，并留下 trial=true；再次 boot 看到上次尚未确认，切回 confirmed。这里 active 表示本模型选择的文件，程序不会执行其中字节，更不会跳转真实设备。
4 · 怎样确认，才代表实际健康
在另一份已完成接收且刚试运行的练习目录使用
python ota_files.py --root another_practice confirm实际应用要在关键初始化完成、采集与必要通信持续推进等条件满足后提交确认。不能在进入 main 的第一行无条件确认，否则之后立刻崩溃也失去试运行保护。健康条件还应考虑看门狗和版本兼容。
确认只说明满足预设运行条件，不证明全部产品功能已经验收。条件应具体、可测量，并保留失败恢复入口。文件模型需要先建立对应目录并完成 begin、chunk、finish、boot，再执行 confirm。
5 · 签名与摘要分别保护什么
CRC 或哈希摘要可以检查内容是否与预期一致；若攻击者同时替换内容和摘要，单凭摘要无法证明来源。数字签名通过受信任的公钥验证发布者授权。密钥配置、签名检查和版本策略应在真实启动方案中设计。
本示例不实现签名验证。课堂可先比较合法内容、损坏内容、错误目标和过旧版本的拒绝；真正认证必须使用成熟密码库与受保护信任信息，不能把示例字符串当签名系统。
分别完成“试运行后再次 boot”和“试运行后 confirm 再 boot”，比较 active 与 confirmed。写出你认为该手表应满足的三项健康条件。