J16 · 原型 vs task #178 已交付语义 —— 差异清单

依据：docs/42-x-day-wellness-plan.md（Web v1 实现合同）与 docs/06-user-journey.md#j16。

对照对象：设计原型 etag 1788857149116559。

这一份只列差异，不改语义（按 @打包的的要求）。范围限普通用户主链：

创建 / 执行 / 调整 / 暂停恢复 / 复盘。future 能力不展开。

判定用探针跑在导出的 DCLogic 上，不是看图。

一致的部分（无需改动）

合同条款	原型实测
计划 3–30 天	2 天和 31 天报错、3 天和 30 天通过
同时只有一个 active 或 paused 计划	已有计划时再创建，计划 id 与天数都不变（新建被拒）
创建前预览每一个有日期的行动	向导「See every day」逐日预览，确认前不落库
每天一条具体、带理由的行动	有标题 / 详情 / 理由，取自目录
依据是创建时快照，之后账号或库存变化不改写计划	复盘页写明「Built from your goals on … and the 2 item(s) then in your Fridge」
完成任务不产生也不修改摄入	早前几轮已验证并保持
今天和过去可完成，过去完成标为补记	标「Done · backfilled today」
未来不可完成	对未来日调用完成，状态保持 `todo`
今天和未来可跳过/替换，过去不可新跳过或替换	已验证
完成或跳过可撤销回 planned，计划结束后不可	`undoAction` 在非 active 时不执行
暂停不编造结果；恢复只移动暂停日当天及之后仍 planned 的任务，已完成/跳过保持原日	恢复预览分「移动」与「保持原日」两栏
恢复从计划固定时区的次日开始，先给出完整建议日程再确认	恢复预览列出全部新日期，确认后才生效
暂停中的计划不按旧截止日到期（含暂停跨过原截止日）	已验证
到期后只读；手动结束是追加	到期自动进入 PLAN REVIEW · READ ONLY，无操作按钮
创建后不能改开始日/天数/时区，只能结束后另建	创建后 `planDraft` 为 null，界面无编辑入口

需要你决定的差异

D1 · 状态词汇：原型 `ended` / 派生 `expired`，合同只有 `completed`

合同：active、paused、completed 是仅有的三个状态；「到期后只读」是 active 的性质，

不是另一个状态。

原型：结束后 status = 'ended'；另有派生的 expired（当天超过 endISO 且仍 active 时计算得出）。
影响：只是词汇与建模差异，用户可见文案不受影响。但如果设计稿要和实现对齐，

建议原型改用 completed，并把 expired 明确表述为「active 且已过截止日 → 只读」的派生视图。

要你定：是否把原型的状态词改成合同口径。

D2 · 没有修订号与变更身份（revision / clientMutationId / event identity）

合同：每次变更都带 owner 域内的 clientMutationId、期望的 revision 和不可变事件身份；

完全相同的重试返回已存回执；意图不同的重复或过期 revision fail closed。

原型：这一层是我前几轮自建的尝试身份模型——每次写入尝试有稳定 attempt id，

模拟存储记录是否被接受，查询按 id 而不是比内容；冲突走「重读 → 保留最新 / 在其之上应用我的」。

计划对象上没有 revision 字段。

影响：两者都能表达「重试不重复、冲突要显式选择」，但不是同一套模型。

原型的冲突面板不体现 revision 递增，也不体现「过期 revision 直接失败」。

要你定：设计原型是否需要把 revision 显性化（例如冲突面板显示

「你基于第 3 版，现在是第 5 版」），还是维持现有的尝试身份表述即可。

D3 · 逐日任务没有稳定 id，只有数组下标

合同：恢复时移动的任务「保留其 ID 与顺序」，写入端会独立重建目录与允许的状态转移，

调用方无法伪造任务文案、状态、日期或归属。

原型：actions[] 的字段是 i / dateISO / title / detail / reason / state / backfilled / replaced

—— i 是下标，不是稳定 id。恢复时按下标建映射。

影响：在原型这种单机演示里不会出错；但设计稿如果要表达「任务有身份」，

目前的模型表达不出来。也意味着原型无法演示「伪造任务被写入端拒绝」这类合同保证。

要你定：是否给逐日任务引入显式 id（纯设计层面即可，不需要真实后端）。

D4 · 目录未版本化

合同：每日行动「确定性地取自版本化的 wellness-plan-v1 目录」。
原型：有目录，但没有版本标识；复盘页也不显示计划是基于哪个目录版本生成的。
要你定：创建快照说明里是否要露出目录版本（例如「catalogue v1」）。

D5 · 默认时区

合同：所选 IANA 时区不可变，旅行与设备设置不移动计划日期。
原型：向导可选时区（Asia/Tokyo / Europe/London / America/New_York），默认 Asia/Shanghai。
影响：行为一致，只是默认值不同；文档示例用的是 America/New_York。
要你定：默认值是否需要统一，或改成跟随设备但创建后锁定。

我建议的处理顺序

D1 状态词汇 —— 最便宜，纯改名，先做。
D3 任务 id —— 影响恢复/替换的表达，值得做。
D2 revision 显性化 —— 要先定「设计上要不要让用户看到版本号」，这是产品问题不是实现问题。
D4 / D5 —— 文案与默认值，随下一批一起。

我没有动任何语义，等你的判断。