评审日期：2026-09-11。整理任务完成，人工review尚待Jack进行。原型与浏览器评审意见均不等于生产开发Ready。
已交付给本次评审
- 45项需求的Markdown真源、CSV和逐项页面/用例/验收映射。
- 手机小程序与营养师/教练PC原型V0.6，集成在评审页内可操作，也可独立打开。
- 32个页面/主要组件清单：SCREEN-01～23有既有演示；SCREEN-24～32为待设计容器，无可点击实现。一个页面可以承载多个组件，不能把这个数当独立URL数。
- 逐项意见、修改规则草稿和页面说明；本地保存、JSON/Markdown导出；没有预先替用户勾选认可。
- 既有PRD、后续UC、接入方案、产品总纲、商业/商品证据及历史入口。
覆盖情况
- 具备演示：16项。
- 待补原型（可能有局部示意）：16项。
- 接入/规则待定：5项。
- 非界面约束（实现未验）：5项。
- 后续建议：3项。
这里的具备演示只覆盖该条规定的合成UI行为，不代表真实接口、专业判断、商业效果。重点缺口：全天24h回放；体检/微体检与报告归属；每日餐单和实吃/剩餐；真实膳食结构趋势；持续个性化提醒和医疗跟进。真实模型、厂商后台到数、SKU准入和真人排期也没有完成。
双向审计与未确认规则
从需求到原型：每项需求有AC-R编号、用例或全局规则、页面或明确非UI标记。未来页面不能用旧页面截图冒充覆盖。从原型到需求：日历/纠错/行动/异常→REQ-01～07；睡眠与状态→REQ-R08～09；档案/会员/趋势/报告/干预/阶段服务→REQ-R10～15；样例问答→REQ-R16且标缺完整真实能力；连接/巡检/偏好→REQ-R17～23、35～37并明确只是局部模拟。
原型中的固定日期、合成目标数值、两个睡眠样例、默认成员、连接延迟和示例建议不是已批准的真实产品规则。实际供应餐单、专业阈值、通知频次、跨设备权限、云效负责人和上线性能目标仍未冻结。
本轮核验
重新运行既有三个浏览器脚本：25项基础检查、36项多端检查、21项睡眠与阶段服务检查，共82项通过。脚本使用隔离会话及合成数据，不重置用户的评审意见。
评审入口新增检查覆盖筛选/选项/本地恢复/安全显示/意见导出、手机PC切换、页面清单和双视口布局；结果详见review-verification.json。既有脚本原始回执在上级evidence目录。
反馈如何成为正式需求
用户填写→导出JSON或Markdown→逐条决定采纳/调整/待讨论→更新正式规则与相应UC/原型/验收→重新核对覆盖。当前review-decisions.csv只有一条待评审记录；annotations.json为空基线，实际浏览器草稿不会被这个文件覆盖。此次不自动写云效、不发送消息、不将认可勾选当上线批准。
原始意见的覆盖关系
- 非时间轴 → 后续明确24小时回放：采用后者，旧画布仅保留为历史实现。
- PC本人仪表盘假设 → 用户确认营养师/教练管理多人：采用后者。
- Oura备选 → 用户正式主对标：采用后者。
- 人工补记主流程 → 自动记录优先：保留补记处理缺口和纠错。
- 每日一对一服务推测 → 实际仅阶段讲座/解读：不得扩大资源承诺。
- 体检、微体检、餐单实吃、持续提醒：均纳入当前需求，但不声明已补齐原型。
- 28天、20人、第14天场次及服务收费：明确为建议，等待评审。
- 私人健康执行与共享产品：真实个人资料及计划在本机私有范围，本评审包只含通用需求和合成原型。
使用与导出
浏览器打开requirements-prototype-review.html（需通过HTTP服务）。建议先看差距，再对照手机/PC，按主题逐项记录意见，最后导出。草稿仅在当前浏览器恢复，换电脑需保留导出文件；当前没有云端协同或意见导入功能。