维护者确认：#4033 自建 OTA 原生事务恢复（冷更 / 安全 / 架构）

[MagicLizi]

PR #4033 需要维护者确认后再继续推进。

为什么拦

这次改的是 Mobile 自建 OTA 原生事务恢复，同时命中多类确认门：

• 产品 / UI：改到 apps/mobile 的 OTA 恢复链路、配置与文档，用户侧更新/恢复行为会变。
• 安全敏感：扫描到危险写法硬命中（dynamic-eval 形态），需要维护者确认这不是真实动态执行、也不会扩大隐私或系统面。
• 冷更：改到 fingerprint 输入（app.config.js、selfhost-ota 原生 journal / contract / patches 等），标题已写「需冷更」，要确认这次冷更是否必要、存量装机影响是否可接受。
• 架构：diff 约 2090 行，超过大改动阈值。

请维护者看什么

1. 冷更是否不可避免，Description 是否把影响和发版节奏写清楚。
2. 原生 journal / 事务恢复会不会在失败、中断、升级路径上丢更新或把用户卡在半恢复。
3. 所谓 dynamic-eval 命中是不是误报；若是真实动态执行，范围和风险是否可接受。
4. 改动是否超出「自建 OTA 原生事务恢复」这一件事。

怎么确认

• 可以直接在 PR 上 Approve，门就会放行。
• 需要修改就 Request Changes，作者改完后再 Approve。
• 普通评论、摘标签都不算通过。

---

关联 PR:#4033(作者 @guyong-zapo);本 issue 由 review-pr 流程自动创建,用于先讨论该 PR 涉及的产品 / UI 变更,维护者确认后 PR 会恢复推进。

[dash-s-cindy]

判断：这项工作有明确的用户价值：为显式启用自建 OTA 的 Android/iOS 新整包补齐进程中断恢复、候选启动失败回退，以及覆盖安装后的版本选择保护。现有纯 JS OTA bridge 能协调检查、下载和 reload，但无法在原生启动、首屏失败或进程被系统终止的阶段可靠接管这些状态，因此原生事务恢复和相应冷更方向具有合理性。当前建议先完成发布前阻断项，再批准合并；暂不建议仅凭已有替身测试和代码扫描结果 Approve。

已确认的范围与现状

• #3838 已合入，提供了自建 OTA 的纯 JS 两阶段协调器，覆盖启动、回前台和设置页手动检查，并以共享 UUID 替代单安装标识。其讨论也确认：已经运行旧 JS 且 consent=false 的存量客户端无法仅靠 OTA 下载首个 bridge，仍需要既定的冷包/整包分发路径。
• #4033 是在该基础上新增原生能力，范围限定为同时启用 EXPO_PUBLIC_XDT_OTA_SELFHOST=1 与 CINDY_MOBILE_OTA_NATIVE=1 的自建 Android/iOS 新整包。旧 runtime 继续使用已上线的 JS bridge，非自建 EAS/TestFlight 不改变。
• PR 描述中的 journal 设计区分“下载完成”和“首屏内容已成功出现”：前者只记录 pending，后者才提升为 good；候选启动失败时恢复 good/embedded，并保留相关资源。该设计直接对应强杀、首屏失败、覆盖安装和跨通道恢复问题。
• PR 记录的冷更确认只表示该方向可以进入正式评审，并不等于授权合并或发布。PR 本身明确写明 Android/iOS 完整原生整包编译、签名、安装和真机故障验收尚未完成。
• 当前仓库快照 b91b78c507a6605bb631ad6e85bf82d94d71efd2 的 apps/mobile 仍包含旧的 otaRequestCoordinator.ts、useStartupOtaGate.ts 和 app.config.js 逻辑，未出现 CINDY_MOBILE_OTA_NATIVE 或 selfhost-ota 原生目录。这证明 fix(mobile): 自建 OTA 原生事务恢复（需冷更） #4033 尚未落入该快照，不能据此宣称新 journal 已经发布或已在当前 main 生效。

对确认点的判断

1. 冷更是否必要

对 #4033 声称的能力而言，冷更是有技术依据的：原生更新配置、原生下载完成记录、启动选择、首屏成功/失败生命周期和资源保留都发生在 JS 可靠接管之前；只发 JS OTA 不能新增这些原生挂点。PR 还说明新原生源码摘要进入 fingerprint，并保留旧 runtime 分流，因此影响范围可以被限定，而不是要求所有 Mobile 用户同步迁移。

不过，必须把“新自建整包需要冷更”和“所有存量设备都会被覆盖”区分开。旧 runtime 不能直接获得原生 journal；已经被旧 consent 闸门挡住的 consent=false 存量设备也不能靠 OTA 自救。发布顺序应明确为：先构建并验收新整包，再按自建分发路径交付冷包，确认新 runtime 基线后才发布同原生输入的后续 OTA。新原生包出现问题时，不能简单把旧 runtime bundle 当作直接降级包投递。

2. journal 是否能避免丢更新或半恢复

从 PR 描述和自动评审摘要看，状态机、串行协调、晚到 fetch 排空、pending/good/embedded 选择及失败回退已有实现和替身测试支持；自动评审未指出确定性代码缺陷。现有证据仍不足以证明真实设备行为，尤其是：

• Android 与 iOS 的真实完整构建、安装和覆盖安装；
• 下载完成后、reload 前、首屏内容出现前各个强杀窗口；
• 首次首屏失败、同进程 relaunch、离线资产回退、磁盘 I/O 异常；
• release/canary/beta 跨通道切换，以及同 runtime 覆盖安装；
• fetch 超时但原生请求晚到时，旧事务与下一笔事务不会交错；
• 真机上 Expo 数据库中的真实 embedded ID 与 journal 记录能保持一致。

这些不是建议顺手扩大的需求，而是 PR 已自行声明、且对“可发布”结论必需的验收边界。完成前应维持不合并、不发布。

3. dynamic-eval 安全命中

在当前 main 快照的 apps/mobile 检索中没有发现 dynamic-eval 或 CINDY_MOBILE_OTA_NATIVE；但 #4033 尚未合入，因此这不能证明 PR 分支没有命中，也不能证明命中是误报。PR 描述涉及 patches.js、固定版本 Expo Updates 源码适配和生成工程补丁，扫描器可能把静态源码变换、字符串拼接或构建期处理识别为 dynamic-eval 形态，但目前没有足够的 PR 文件级证据作最终安全结论。

批准前应要求作者逐处列出命中的文件、表达式和数据流，并确认：

1. 是否存在运行时执行字符串/远程内容的 eval、Function、动态脚本加载或等价机制；
2. 若只是构建期静态补丁或源码文本处理，执行时机、输入来源和输出边界是什么；
3. OTA URL、headers、manifest、用户数据和账号信息是否可能进入该执行路径；
4. 是否有 Android/iOS 双平台测试或静态检查锁定“非动态执行”的性质。

如果命中确实只是构建期源码适配，应在 PR 描述中附上可审查的最小代码定位和安全边界；若存在真实动态执行，则需要先缩小或重设计该路径，不能用普通 Approve 代替安全确认。

建议行动

1. 对 #4033 暂缓批准，保持其“正式评审但不合并、不发布”的状态；冷更方向已有明确确认，但该确认不替代设备验收。
2. 完成 Android/iOS 完整原生构建、签名安装和真机演练，至少覆盖：旧 runtime → 新冷包 → U1/U2 OTA、强杀窗口、首屏失败、离线/磁盘异常、跨通道切换、同 runtime 覆盖安装和晚到请求。
3. 在真机上抓包并核对数据库/日志：固定自建 OTA URL、共享匿名 headers、正确的 release/canary/beta channel；不得出现账号凭据或单安装标识泄漏；同时确认旧 runtime 分流仍然可用。
4. 对 dynamic-eval 命中逐处给出代码定位、输入来源和静态/构建期边界。没有这份解释前，不把扫描命中当作已确认误报。
5. 在发布说明中明确冷包覆盖范围、旧 runtime 的兼容策略、consent=false 存量设备的 bootstrap 限制，以及新原生包故障时必须重新评估 fingerprint/冷包的回滚方式。
6. 上述证据完成、CI 与人工评审通过后，再由维护者在 fix(mobile): 自建 OTA 原生事务恢复（需冷更） #4033 上执行正式 Approve；Approve 仍不应自动等同于立即发布。

相关记录

• #3838：已合入的纯 JS 自建 OTA bridge，是 fix(mobile): 自建 OTA 原生事务恢复（需冷更） #4033 的直接前置能力。它明确记录了旧 runtime 和 consent=false 存量设备无法仅靠 OTA 获得首个 bridge 的 bootstrap 限制。
• #3839：已完成的产品/隐私确认，允许自建 SSO Canary 使用共享 UUID 进行匿名 OTA，同时保留非自建 EAS/TestFlight 的 consent 闸门；fix(mobile): 自建 OTA 原生事务恢复（需冷更） #4033 沿用该自建/非自建边界，但新增了原生冷更范围，不能把 维护者确认：#3838 自建 OTA 匿名热更绕过 analytics consent #3839 的确认当作设备验收。
• #3823：提供了企业 SSO OTA 能力受设备历史 consent 影响的 Android 现象，是自建 OTA 修复方向的用户价值依据；它并不证明原生 journal 已在设备上验证。
• #3824：已撤回的早期方案，确认了共享 UUID 与原生 header 配置会引入冷更及存量迁移约束；后续 fix(mobile): 通过热更恢复 SSO Canary 匿名 OTA #3838 改为纯 JS bridge，fix(mobile): 自建 OTA 原生事务恢复（需冷更） #4033 又在明确范围内重新引入原生事务恢复。

[MagicLizi]

维护者确认已通过,讨论结束,PR 恢复正常推进。关联 PR:#4033(https://github.com/makecindy/cindy/pull/4033)。本 issue 由 review-pr 流程自动关闭。