Study 19｜家里常做的一张菜卡

2026-09-23。用户授权将菜谱升级为可复用菜卡：关联商品进入采购，配料与做法按备忘记录。沿用当前provisional设计内核；实验目录实现，不发布Foundation、不改首选源码快照、不接真实交易。

体验入口与职责

4301的/phone或/origin → 计划 → 家里常做。也可从“添加一道菜”进入。原推荐菜谱保留为次级入口，不新增底部导航。

1. 记一道自己的菜：只要求菜名；不要求图片。可插入多个真实示例SKU，各自选择合法克重、切法与份数。
2. 厨房备忘：逐行填配料与自由用量，允许“少许”、空白；做法可选填，不强迫勾选完成，不自动换算调味比例。
3. 保存后查看菜卡，可编辑常用做法，或一次选择多个日期、指定午餐／晚餐，加入计划。
4. 计划中的每餐保存独立快照。调整其中一餐只改该餐；常用菜卡后续变更不回写其他餐次。
5. 周核对列出每个关联SKU的规格与份数并累计金额。厨房备忘不产生商品行或费用。纯备忘可安排，但不会单独生成零元采购。
6. 付款再冻结一份深拷贝；已付餐次只读，允许另存为新菜卡，不允许改写已付规格。常用卡与其他日仍可使用。

原有菜品也可点图片查看其菜卡、另存为新的常用做法。示例“青椒炒肉”明确标记示例，不冒充用户收藏。

设计关系

菜卡是有边界的整体，不是把每一项材料做成独立小卡。商品区用浅底面和真实商品缩略图，备忘区用开放横线与轻量文字。没有照片时，计划中用文字卡呈现菜名与少量备忘，不要求用户做内容创作者。

菜品、原料、规格、厨房备忘各有职责。实心动作只用于保存或加入安排，更新常用做法与只改本餐用不同按钮，避免一个“保存”同时影响多个对象。对应LAW-CC-02/03/04/05/06与INV-CC-01/02，未改变品牌内核或正式tokens。

隔离、兼容与失败

• 菜卡库：dingwei-study19-cards-v1；餐次快照随原型计划保存；付款快照在Study18演示账本。均只在此浏览器，无账户与跨设备同步。
• 新菜卡快照加入周计划签名；旧餐次签名保持字节兼容，避免旧已付记录因升级全部变成“安排有变化”。未改首选源码。
• 不覆盖损坏的菜卡记录，读取失败与写入失败显示错误，不伪称保存成功。未保存退出会询问是否放弃。
• 已过去或已付日期不可安排；同张卡同日同餐重复加入会拒绝，整次操作不部分写入。提交时再次核对支付记录。
• 商品仍采用现有模拟目录标准规格与价格。本轮没有真实库存、缺货替换、离线同步或跨标签页原子事务保证。
• 老版推荐／饮食分析和旧订单不是新菜卡的正式消费者；本轮只接计划、核对、确认及实验桌面摘要。未来正式数据模型须替代兼容用的旧recipeId/首商品字段，不可将这些桥接字段用于新的真实采购。

验证与反证

菜卡交互证据：7组浏览器路径，建卡（含空名拒绝、2个SKU、自由与空白用量）、复用两天、只改一餐、完整SKU计价、已付只读、改模板后餐次／支付不变、刷新恢复、纯备忘午餐、重复加入拒绝与320宽压力。

周计划回归：沿用13组点击路径，增加经过菜卡入口前往推荐菜谱。涵盖旧独立购物冒烟，不等于26路由完整回归。verify-cards-model.mjs与verify-week-model.mjs提供模型检查。原始源码由verify-origin-source.mjs逐文件比对。

自审反证与修正：

• 对已付对象做引用变异测试，发现模型本身只浅拷贝输入，先前依赖UI调用方深拷贝。改为支付模型内部冻结深拷贝，测试直接证明后续修改不改变已付内容。
• 日期切换后横向滚动残留导致新菜卡被裁切；切换日期／餐次重置位置，新增菜卡定位到该卡。
• 菜卡内部切换页面保留旧滚动，保存后看不到新页标题；内部页面切换回到顶部，长卡仍允许自然滚动。
• 纯备忘没有商品时，不再提示重新选菜，直接说明没有需要采购的商品。

截图由主会话自审，不是独立design-critic结论。用户的完整体验反馈、真实设备键盘／读屏／大字号、超长菜卡与大量卡片、跨设备持久化未验证。多SKU或长备忘需要滚动，未宣称所有菜卡首屏可看完。

责任与回退

主会话维护实验及证据；用户评判体验，正式架构／交易责任人须在实施前明确。回退需同时撤回Study19组件引用、卡片签名扩展和桌面摘要改动并重建；先保留卡片库与餐次快照，旧版不能安全消费多SKU新餐次，不应直接用旧计价逻辑处理它们。本轮未删除用户数据、提交Git或发布产品。