v0.3最新决定（覆盖下方v0.2的PC目标与手机增量）：PC真源是用户指定的
https://zhct.yyangpt.cn/dist/，对应store/public/static（Vue2+ElementUI）；已真实找到“膳食监控→个体监控→查看分析→膳食记录”，复用该页，不新建侧栏菜单或一级页面。手机AI运动营养师不改，仅作现有页面示意。人员头像head_img已在正确系统源码中证实，不再是未知字段。当前实施切片见store原页复用说明。跨系统人员ID映射仍需真实核验。
v0.2 最小增量契约（覆盖v0.1）
生产DoR: BLOCKED。禁止直接执行v0.1中的新上传API、每次人工选人和人工复核必经流程。
复用与扩展
| 部分 | 复用事实 | 必要增量 |
|---|---|---|
| 选图上传 | pages/chat/index.vue、services/imageService.js→UploadApi.image→upload/image；最多6图 | 复用既有file/message ID和发送成功事件，不新建上传页面或服务 |
| 识别 | identify.vue→RunAgent({image,type:'这是什么菜'}) | 后端自动处理与持久化四指标、估计分量、结果状态、来源与版本；不把临时返回只留前端 |
| 人员 | 现有账号→user/staff映射 | 复用真实映射；缺失/冲突才异常处理，禁止靠人脸推断 |
| PC明细 | store foodRecord.vue与personalMonitorCheck.vue已有头像、日期、三餐/菜品/重量/能量 | 扩展本人照片、上传原图、上传/用餐时间、入口、消息、子类型、四指标、状态、原图放大 |
| 体测 | 已有体重管理及设备API | 保持既有链路；两表关联同一人员，不另建强制体测表单 |
最小落库字段提议
在既有消息/饮食模型上扩展或关联记录，是否新表必须先核实真实Schema，不能假设本轮已完成迁移设计。
- owner：可信org/tenant、user_id、staff_id（来自现有登录映射，不信任客户端任意传入）。
- source：既有message_id/record_id、photo_id数组、source_entry、original_text、uploaded_at。
- eating：consumed_date、consumed_at(nullable)、meal_times(nullable)、intake_type(main/extra/snack/night/unknown)、assignment_basis、confidence/conflict标记。
- result：recognition_status、attempt_id/model_version、food/library ID/version、estimated_grams、portion_basis、energy_kcal/protein_g/zinc_mg/magnesium_mg(nullable)、missing_reason。
- correction：expected_version、old/new、operator、reason、timestamp。
- portrait：本人照片从已授权人员详情/档案字段读取；现有字段为head_img，来自/p/Ontoanalysis/StaffInfo；未配置使用原fallback。性别图标不算本人照片。不要为本功能新增强制用户拍人像流程。
餐次与子类型兼容
meal_times=1/2/3保持早餐/午餐/晚餐原值，前台各组展示对应加餐；4保留夜宵。intake_type在组内区分正餐、加餐、零食，实际进食事件可多条。未确定meal_times使用nullable+待归餐状态，不擅自新增0/5之类现有枚举值。
来源优先级提议：已有饮食入口显式mealId/selectDate；然后消息明确日期/餐次/时间；冲突则待确认。仅上传时刻不能作为实际用餐时间，尤其补记/跨天；不明确日期的“昨天”等须参考可信客户端/用户时区或异常补充。具体NLP与时间规则待锁定。
普通食物问答（例如“这个有多少热量”）与实际摄入记录区分。照片是否食物不等于用户确实吃了它；不得把所有图片自动写饮食账本。已明确记录意图/餐次上下文才正式归餐，不明进入候选/待归餐而非确定摄入。
状态与API行为
事件契约为新提议，文件上传与消息发送API本身继续沿用。新增后端消费逻辑应从已提交消息/饮食事件触发；仅选图尚未发送不记入饮食。
- 接收既有已提交消息→按来源幂等登记→automatic processing。
- ready：识别结果完整自动展示，无需人工复核；估计量依然标注估计。
- failed：原图/上传时间/用户仍可见；同消息重试只生成新attempt。
- pending：餐次/日期/是否摄入不明，单独待归餐区；不得丢弃。
- partial：营养或分量不完整，展示缺失与依据，不填0。
- nonfood：保留普通问答，不进入饮食列表及统计。
- identity_error：已有账号无法唯一关联人员，管理员异常核查，其他记录继续正常处理。
PC查询复用/扩展store的/p/Ontoanalysis/FoodRecord及/p/Ontoanalysis/StaffInfo，按已有参数规范接日期/人员/餐次/类型分页。真实返回结构待当前分支核验；新需求不能通过前端拼接其它人员的数据绕过服务端权限。
纠错须expected_version，冲突返回409且刷新后再处理；权限拒绝401/403，图片失效重取受控引用；算法失败不伪装空餐。照片与人物照片各自鉴权，公开永久链接不作为默认设计。
导出
饮食导出按上传事件×食物项，带人员、日期/进食时间、原餐次值、进食类型、消息/图片引用、上传时间、四指标、分量依据、识别状态、缺失原因。待处理记录保留状态，不能因为未人工复核被隐藏；分析人员可筛掉非ready。体测沿用现有表按同一人员ID关联。正式XLSX模板Q04仍待确认。
原型当前增加的是PC当前筛选的饮食CSV；既有体测入口不重构。未实现真实XLSX、服务端快照、鉴权或设备接入。CSV需防公式注入，原图导出为受控引用而非公开图片数据。