v0.3最新决定（覆盖下方v0.2的PC目标与手机增量）：PC真源是用户指定的https://zhct.yyangpt.cn/dist/，对应store/public/static（Vue2+ElementUI）；已真实找到“膳食监控→个体监控→查看分析→膳食记录”，复用该页，不新建侧栏菜单或一级页面。手机AI运动营养师不改，仅作现有页面示意。人员头像head_img已在正确系统源码中证实，不再是未知字段。当前实施切片见store原页复用说明。跨系统人员ID映射仍需真实核验。

给Codex：v0.2复用实施切片

先读requirements.md与contracts.md。用户否定v0.1独立新采集流程：复用已有上传、后台自动识别、PC按人和餐次看详情。

1. 定位AI问答选图/预览/发送、饮食拍照识别、PC营养饮食页及人员详情。业务库真实路径/分支/HEAD重新核验，原库仍只读，待指定开发分支。
2. 手机页面不改，上传入口沿用现有AI运动营养师。直接复用pages/chat/services/imageService.js、messageService.js和api/upload.js，不再生成新上传页/API。已有餐次入口能给mealId/selectDate，优先沿用。
3. 后台调整：使用已发送消息/已提交记录事件自动触发既有识别；落人员、日期、餐次组、加餐/零食子类型、全部照片、食物明细、估计量、四指标、缺失/失败/待归餐状态。别让用户在PC点每条“开始识别”。
4. 正常人员来自现有账号映射，禁止每次上传人工选人。仅缺失/冲突身份进入异常核查。
5. 扩展store现有dietaryMonitoring/personalMonitor/foodRecord.vue，复用父页personalMonitorCheck.vue人员/日期布局，展示本人照片+上传原图、餐次内多条正餐/加餐/零食、夜宵及待归餐。正确store父页已有head_img；继续验证真实授权和跨系统映射。
6. meal_times=4现为夜宵，不能改为加餐。加餐类型另存并与1/2/3归组；时间/餐次不明则待归餐，不靠上传时间强猜。
7. 保留原体重/体测功能。只扩展必要的表格字段和关联，不另造体测页面。

交付顺序

• A：冻结现有file/message/person/meal契约，补正式环境Before证据；确认图片与消息发送不同事件、归餐优先级、NLP/份量准确率门槛、人员照片来源。
• B：后台自动识别与结果关联垂直切片（UC001/002）；验证幂等、多图、非食物、食物咨询、补记、跨天、待归餐、识别失败。
• C：PC既有膳食记录页局部补充（UC004）；验证两人隔离、头像缺失、原图放大、三餐加餐多条、类型/日期筛选与纠错。
• D：沿用体测并扩展两表导出（UC003/005）；状态与空值可追溯。

每项验收见15AC追踪表；补服务端契约/安全/性能测试，不以原型650ms模拟与本地CSV代替生产验收。P0问题未定DoR: BLOCKED；先完成规则确认和源码核验，再进入业务开发。

云效意图已确认，但需求负责人/编号仍未明确。落云效时正文直接包含完整UC及本开发切片，CLI回读；不得只放链接，不任意指派。

当前原型

现有手机AI问答；现有PC饮食上传明细。新增HTML适配脚本仅为原型模拟：不得把IndexedDB、本地角色/合成食物数据当成生产架构。