本次草稿依据提交记录，未逐行核对实现。依据：（2026-10-24，billing & points, generation Live Activities, task lifecycle, 027-030 migrations）、（2026-10-18，push notification support, bump to build 8）、（2026-10-24，记录生产 APNs 密钥安装）、（2026-10-18，本地通知 entitlements 与分发描述文件对齐）。实证：任务、租约存 PG，失联且结果不明的任务标记 needs_attention、不自动重发；Redis Pub/Sub 加快通知，PG outbox 经 SKIP LOCKED 投递、可能重复，消费者按持久状态处理，2 秒轮询兜底。
为什么生成需要一个任务
AI 生成是一段持续过程：发起、排队、调用模型、逐步产出、完成或失败，中间还可能被取消、失联、超时。用户可能切走、锁屏、退出再回来。若生成只是一次内存里的调用，用户一切走，状态就丢了。
生成任务是把一次生成变成有身份、有状态、有生命周期的持久实体：创建、执行、完成、取消、失联。状态存在 PG 里，跨进程可查询、可停止；手机上发起生成，Web 上查看进度，看到的是同一个任务。任务与租约绑在一起：执行者要先拿到带有效期的租约才有资格跑任务、发布结果。
失联任务：标记 needs_attention，不自动重发
存储文档记载了一个很克制的处理：失去执行者且结果不明的任务标记 needs_attention、不自动重发模型请求。原因是“结果不明”最危险：执行者失联前可能已调用过模型、已扣过费或消耗过点数（ 同时交付了 billing & points）。此时自动重发，可能导致重复生成、重复扣费；第一次结果若其实已生成，第二次又会产出第二份。标记 needs_attention，是把决定权交给人：先搞清第一次发生了什么，再决定重试、补发还是标记失败。
Live Activities 与推送：基于同一任务状态机
Live Activities 与推送不是两个独立功能，而是同一任务状态机的两种呈现。Live Activities 是 iOS 锁屏与灵动岛上的实时活动：任务创建，活动出现；执行中，活动更新进度；完成或取消，活动到达终态。推送也是同理：任务到达终态触发完成推送，进入 needs_attention 触发提醒推送。两者都由任务状态变化驱动，三者因此一致：锁屏进度、推送结果、应用内状态都从 PG 里同一份状态读。
状态通知用三层保障：Redis Pub/Sub 负责快，但订阅者不在线消息就丢了；PG outbox 负责不丢，变化先写进 PG 的 outbox 表，再由投递者用 SKIP LOCKED 逐条取出投递；2 秒轮询负责兜底，每 2 秒轮询一次持久状态也能把漏掉的变化补回来。
重复通知要以持久状态为准做幂等
outbox 可能重复通知：投递成功但确认没写回去，或投递者超时重试，同一条通知就可能被投递两次。消费者收到通知后，应先查 PG 里的持久状态：这条变化是不是已处理过？已处理过就直接丢弃，没处理过再执行。这就是幂等：同一条通知处理一次与两次，结果一样。关键不是“让通知只发一次”，而是“让消费者能识别重复、并安全地丢弃重复”。通用模式是：每次状态变化都有可识别的身份，消费者处理前先查“这个身份处理过没有”，处理过跳过。幂等缺失的后果很直观：锁屏进度乱跳、推送连着来两条同样的消息。
APNs 生产密钥与 entitlements 对齐的坑
推送要经过应用服务端、APNs、用户设备，提交信息点了两个最容易出问题的对齐点。一是 APNs 生产密钥： 记录为 TestFlight 推送安装生产 APNs 密钥。开发与生产密钥不一样，TestFlight 走生产环境；拿开发密钥发推送，推送到不了，且往往不报错。二是 entitlements 与描述文件对齐： 修复本地通知 entitlements 与分发描述文件不对齐的问题。entitlements 与 provisioning profile 要对齐。对不上，构建可能通过，但通知能力运行时不可用。 提到推送支持与构建号升到 8。推送的坑很少在代码里，而在配置对齐上。
小结
生成任务把一次生成变成持久实体，生命周期是创建、执行、完成、取消、失联；失联且结果不明时标记 needs_attention、不自动重发。Live Activities 与推送基于同一任务状态机，状态只在 PG 里存一份，三者一致。通知三层保障：Pub/Sub 负责快、outbox 负责不丢、2 秒轮询负责兜底；重复投递时消费者按持久状态做幂等。推送落地的坑在配置对齐：生产 APNs 密钥要装对、entitlements 与描述文件要对齐、版本边界要留档。
