2026-09-15，增量设计草案。父能力：UC-CPT-04餐单/实吃、UC-CPT-05持续提醒；追踪REQ-R30/31/32/33/34/35/36/37。沿用UC-CPT-03身份/健康关注，不能另造身份库。已交接的VWCG-1361负责v0.5照片记录基础链，本UC为之后的餐前选择/反馈增量，未写入或修改该任务。
角色、触发与范围
主角色：自愿授权的健康成年会员；协作角色：餐厅菜单维护者、营养规则审核者、技术与测试。系统责任边界为一般吃动支持；医疗限制按专业确认，诊断/药物管理不适用本UC。
触发：本人进入当前餐段、菜单更新、本人换菜、可靠实吃事件修订或本人到达授权提醒窗口。
前置：跨系统人员映射明确；可供应菜单和价格/份量口径有时效；个人必要限制有来源；启用规则已审。无通知许可仍可站内查询，不能绕过许可发外部消息。没有可用菜单不触发“可购买组合”。
成功后置：保存可追溯的本人餐次选择、计划版本与理由；实吃作为独立事实，后续调整有依据和状态。失败后置：原记录/原订单不变、没有伪造组合/实吃/通知成功；可恢复待处理。
主流程
- M1读取已核验本人/组织/餐厅/日期餐段/目标/限制和菜单版本。
- M2从可供应且符合限制的菜中形成至多两套组合；规则引擎计算，AI只能表达理由。资料不足时输出受限选择或必要补问，不凑齐两套。
- M3展示实际菜品、窗口、可选份量口径、可得价格、适用理由和替代项。营养数据有可靠同口径才能汇总，缺失明确。
- M4本人接受或换菜；再次核对供应、限制和版本后保存餐次计划。接受不是自动下单或已实吃。
- M5通过既有饮食事件/照片链获得记录，必要时确认实吃/剩餐/分享；按当前可信版本比较结构和覆盖。
- M6只为尚未发生的下一餐生成一项适用调整；不改变过去实际记录，不做补偿性少吃/运动。
- M7若本人授权且在许可窗口，发送前重新核对完成状态、供应、依据时效、同主题重复和频次；否则站内保留/抑制。
- M8处理完成、稍后、不合适、关闭或缺反馈；根据障碍调整下一次选择和触达方式，形成周回顾。
分支、异常与恢复
- A1无记录：显示“未记录/资料不足”，不把缺记录设为0；不推导精准热量缺口。
- A2无足够适用菜单：给现有少量可选项或明确无合适组合，不能编造菜和库存。
- A3仅菜单部分营养数据齐备：按类别搭配，不出确定合计和精确达标结论。
- A4手动选择与建议不同：尊重本人选择，记录事实；若适用限制冲突则说明并请求确认/专业核对，不能默默认定安全。
- A5同一餐厅不同人：目标/限制/已吃不同可输出不同候选，若条件相同可相同，不为“个性化”强行不同。
- E1已推荐菜售罄：原候选失效，保留旧计划历史；本人再次选择前校验，必要时改菜单/窗口。
- E2照片重传、消费镜像或补传：依归属与原事件去重，不多算摄入/产生重复提醒。
- E3人工纠错或迟到剩餐：保存修订，重算未执行安排；AI候选不得覆盖当前人工版本。
- E4错人/权限/撤权：拒绝读取，取消未发动作；严禁按姓名、手机号相似或照片相似绑定。
- E5模型超时：保留有效菜单、确定规则筛选和已知事实，语言解释可降级，不等待模型才让用户选菜。
- E6非负有限重量/同口径单位校验失败：拒绝保存计算结果并说明待核对，不能截零掩盖数据冲突。
- R1用户稍后/关闭：按新的许可重新评估；恢复后不补发历史积压。
- R2渠道失败：保留待处理状态，有限重试需幂等；不自动切换短信等未授权渠道。
- R3多次未反馈：状态未知，了解障碍/减频；不判不自律，不以增加通知次数处理。
业务规则与逻辑数据合同
- MealOffer：org/restaurant/window/date/slot、dishId、available、price/priceBasis、servedWeightBasis、menuVersion、updatedAt、maintainer。
- RecipeBasis：recipeId/version、ingredients及可食部/生熟/用量、yieldWeight、nutrientSource/version、quality。E/W×m只能在同口径且W>0时计算，不能称为实际吸收。
- MealPlan：memberMappingId、date/slot、goal/constraint/rule版本、offer版本、组合与替换历史、acceptedAt。计划与订单、取餐、实吃分别保存。
- MealObservation：复用已有记录ID、source/message/photo/event ID、mealTime、food/weight/units、confirmation、currentVersion、correctionReason；不将一张照片与多图汇总重复算。
- ActionProposal：concern/goal、basisEventVersions、menu/ruleVersion、适用时间窗、status、reason、proposedAlternatives。
- ReminderAction：复用UC-CPT-05的许可/去重/频次/状态；完成≠点击，未响应≠失败。暂定最多一次普通主动触达/日须试点前确认，不用于覆盖医生要求的独立跟进。
拟定逻辑服务：读取当前供应菜单、生成候选、接受/替换计划、饮食版本更新事件、重新评估候选、抑制/发送与反馈。不在本轮臆造现网API或数据库表名；具体路由由负责人核实现有服务后确定。
页面与实现边界
手机：现有首页本餐卡→现有餐品详情/换菜→既有拍照添加→当餐记录→下一餐行动。是否增加首页卡位置需产品/设计确认，不替换已确认上传位置。
PC：store原膳食记录页，新增“建议/实际/差异”的局部区域或详情；不再建独立专业后台。保留原三餐、人员/日期与照片修正；不得把本UC扩展混入已交付的v0.5范围未评审就执行。
服务端归属由store/ai_api现有接口责任确定，移动客户端为ai_app；跨系统统一ID、规则版本与消息幂等必须先冻结后实现，不跨仓分散猜测。
验收与自动化测试设计
| ID | UC步骤/规则 | 给定与操作 | 可判定结果 |
|---|---|---|---|
| AC61/T61 | M1–M4供应与限制 | 合成菜单含售罄、过敏限制和可供应菜，分别给A/B选择 | 不适用项0；差异由输入解释，无法组合不编造 |
| AC62/T62 | M2/3配方基准 | 同样输入改生熟口径/出成缺失 | 不错误套用每100克，质量降级明确；口径齐备可独立重算 |
| AC63/T63 | M5/A1/E2 | 缺早餐、同照片重传、两图重叠食物 | 缺失不设未进餐；原事件幂等；无法确定重叠时保留待确认 |
| AC64/T64 | M4/M5 | 点击接受计划但尚未取餐 | 不增加实吃记录或能量累计；选择与事实分别可查 |
| AC65/T65 | M5/6/E3 | 原记录已人工纠错，随后AI重识别/剩餐晚到 | 人工当前值不被覆盖；新建议引用正确版本；历史不伪改 |
| AC66/T66 | M7/R1 | 已完成、免打扰、撤权、重复事件、关闭后恢复 | 不重复/越权发送，无积压轰炸；抑制原因可查 |
| AC67/T67 | M8/R3 | 用户反馈买不到或时机不合适；另一人已稳定执行 | 替代选项/时机或频次改变；无反馈仍未知，不凭点击结案 |
| AC68/T68 | E4 | A计划ID由B/异组织请求 | 接口拒绝；日志无个人正文，不仅前端隐藏 |
| AC69/T69 | E5/R2 | 模型超时、通知失败 | 有效菜单可继续看，显示降级；通知无假成功及未授权渠道切换 |
| AC70/T70 | 全流程 | 完整授权菜单→选择→取餐/照片→纠错→下一餐→反馈 | 来源/版本一致；不购商品也可完成完整流程 |
这些是待实施测试断言，本轮未运行真实API测试。关键错人、限制绕过、重复累计和越权消息目标为0；可用性和服务收益另测。
性能、安全与DoR
建议技术评估负载基线：一个点位、两餐段、每餐峰值并发与菜品量由点位实际提供，首周先测缓存菜单查询、规则筛选、异步解释。p95/重算延迟/送达窗口与失败重试预算必须在DoR转Ready前冻结；不把临时估算写成测试通过。
原菜单有效时，模型失败不得堵塞选择；已过期/售罄的数据不可用“缓存可用”掩盖。仅上传完成服务所需资料，权限与处理目的分开；公开原型只用合成菜单，不复制个人聊天截图。
DoR: BLOCKED。P0缺口：人员映射及接口版本（技术，开发前）；试点实际菜单/供应/份量口径（餐厅/数据，第一段）；审核规则及限制处理（营养负责人，第一段）；通知许可/频次/窗口与服务产能（产品/运营，第二段前）；性能负载与断言（技术/测试，开发前）；增量云效项目/负责人及是否并入后续里程碑（Jack/产品，正式流转前）。
当前未新建或修改云效、未派发消息、未启动开发。不适用：支付改造、硬件研发、医院诊疗、真实参与者招募、生产数据迁移与商业收费执行不属于本轮方案交付。