重启后原型去哪了：备份与完整恢复
先看 RAM 的生命周期，再把几千字节原型放进现有可靠传输流程。传输的终点是整份数据检查并提交，不只是最后一次写入返回。
1 · 当前原型怎样存放
proto_model.c 把七类原型放在静态 RAM 数组中。RAM 可在运行中更新，但掉电后不会保留个人化原型；当前没有自动写入 Flash 的个人原型持久化流程。启动时还会初始化并按当前实现准备通用原型。
因此 App Pull 备份有实际用途：把当前数据取出来保存，再在合适时恢复。当前完整文件导入导出界面尚未实现，教程会把已有传输接口和待补的用户操作分开说明。
2 · 一份备份包含多少数据
数值部分为 7×128×4=3584 字节，当前载荷再加类型与版本共 3586 字节。完整内容按协议分成 30 片，每片还包含分片信息。蓝牙写入的分块与应用的这 30 片是两个层次。
float32 要按规定字节序序列化，接收字节地址不一定四字节对齐。当前 C 端通过 memcpy 读浮点数，手机端用 ByteData 显式小端访问；不能仅把偏移后的裸地址强转成 float 指针。
3 · 为什么先暂存，再一次性提交
每片确认有助于控制桥接缓冲和重试，重复片不能仅增加已收数量。事务编号用来避免旧传输的回复混进当前操作。最后提交确认与普通片确认有不同状态。
4 · 沿 App 实际恢复逻辑读等待
proto_transfer.dart 为每片先登记匹配事务、索引的确认等待，再写入，避免回复来得太快而错过。超时有限次重试，最后一片要求最终提交状态。发送 Future 完成必须对应这个最终结果。
中途断连、最后确认丢失、重复提交都需要可解释结果。恢复失败不应让 UI 显示成功，也不能通过无界重试占满链路。CRC 检查偶发数据损坏，不是发布者身份认证。
5 · 备份文件还应记录兼容关系
保存基础网络标识、特征维度、归一化规则、类别顺序、采集说明与原型版本。当前线上载荷较轻，并没有覆盖所有这些元数据；若新增文件格式，应明确区分文件清单与既有传输载荷，不能擅自改变三端协议。
按一次正常恢复列出每个确认时刻，再分别丢掉一片、重复一片、破坏 CRC。说明设备当前使用哪份原型，以及 App 可以凭哪个反馈显示完成。