移盘连续性与夹重：增补Use Case

关联原任务 ZHCTPROMPT-20260909-YOUKATE-SCAN-SDK-AUDIT。本轮研究与方案完成；实现未启动、未创建/修改云效、未改变设备。延续 原Use Case，不另设重复主任务。

UC-YKSCAN-001/002/003 增补约束

• 已确认识别介质为二维码，由扫码器读取；硬件输入契约和改造均沿用二维码，不引入RFID/NFC或替换为其他标记编码。

• UC-001现场证据新增：允许移动的平面范围/高度/角度；区内挪动与物理离开的定义；菜盆承重示意；夹子在手/盆/回位架/搭边状态。

• UC-002输入新增：独立且带健康/时间的presence；如有身份位置，保留ID与位置关联；未知/过期presence不转ABSENT；NoRead不等于通信断流。
• UC-003会话新增：身份暂失保留会话但不无限按旧ID归账；同区A→B、手遮挡换盘和邻台串读进入歧义处理；重新确认身份后按已冻结规则归属待处理重量。不同身份的边界重量无法确认时不得直接拼接。
• 三者硬件接口、时间参数、允许动作、归属规则仍为DoR: BLOCKED，待产品/Android/供应商/测试确认。已确定的代码缺陷可先形成修复切片，但本轮不执行。

UC-YKSCAN-004：允许区域内移盘保持正确身份与取餐

• 角色/触发：就餐人在一台410前将同一餐盘/码牌平移、旋转或在允许高度内短暂抬起。
• 边界：识别对象不等于菜盆；身份与在位通道须覆盖批准的活动区域；单次接待/多盘规则待定。
• 前置：传感器输入质量可判；A身份已确认，起始取餐重量可靠；T_reacquire、T_exit与允许区域已确认。
• 成功后置：同一业务动作维持一个会话，身份/重量准确关联；离开只触发一次收尾。
• 失败后置：不能可靠确认时明确进入待确认，不生成猜测归属的账单。

主流程

1. M1 采集新鲜二维码ID、位置（若可提供）/在位、健康和菜盆重量，将A关联一个会话。
2. M2 同ID在允许区移动，沿用A会话；移动不是结束触发条件。
3. M3 短时失读但独立在位有效，进入重获，保留会话，新增重量暂存；不能刷新lastGoodRead或据持续占区证明仍是A。
4. M4 重新读到A且没有换盘/冲突证据，按已确认连续性规则恢复同一会话。
5. M5 有效区域持续空、达到T_exit，并且无身份/时序矛盾时进入收尾；待重量稳定及夹子条件满足后只保存一次。

分支/异常/恢复

• A1@M3 出现B：保持A证据，进入换盘确认；不得覆盖A起始重量，分别核实边界与B身份。
• A2@M3 手留区内或两牌重叠：在位连续但身份不明，不能将新重量归旧人。
• E1 任一传感通道无新数据/错误：UNKNOWN，不能当作物理空；已有可靠独立通道可维持其自身观测，但不伪造缺失身份。
• E2 A离开全部观测区后再回来：执行约定宽限/新会话规则，不保证猜中“只是挪动”的意图。
• R1 同身份可靠重获后恢复；R2 长时未重获提示重新放盘/扫码，待人工或业务规则确认。

规则与数据

• BR-01 reader_trigger_end、NoRead、ABSENT、订单结束四者不能混用。
• BR-02 presence只能证明区域占用；身份归属要求ID/轨迹/交互契约证据。
• BR-03 request generation与session_id绑定，旧查询/重复回调不可导致多次收尾。
• 页面：HomeActivity/取餐Fragment/诊断状态，保留业务主要流程；短暂正常恢复尽量不打扰，长期歧义才提示。
• API/事件：SDK/适配层ID、presence、健康、时间与位置；原取餐上传接口是否需要会话追踪字段待技术确认。
• 数据：session_id、候选ID、lastGoodRead、lastPresenceUpdate、pending_weight_events、一次收尾标识。

验收与测试

• AC-M01 允许范围内平移/旋转/边缘/抬起，身份可见时会话不重建；IT-M01。
• AC-M02 短时失读→同A恢复，一个会话，无重复记录；失读期间重量归属有可核证据；IT-M02。
• AC-M03 真离开在约定L_exit内完成一次收尾；T_exit±1ms/乱序/迟到/暂停恢复测试；IT-M03。
• AC-M04 遮挡换A→B、手停留、邻台两盘、同区两ID不得错归旧用户；E2E-M04。
• PERF-M01 分别记录误结束/漏结束/错身份/重复记录/ID重获P95与P99/离开延迟；正式目标、工况和样本量未冻结，不能标合格。
• SEC-M01 诊断数据脱敏有限存储；视觉若采用，只采识别区必要内容，避免非必要人员影像。
• 待确认：活动区、短抬上限、时限、身份失读期间计量策略、换盘边界；负责人建议产品+Android+供应商+测试，日期待安排。DoR: BLOCKED。

UC-YKSCAN-005：夹子状态不污染食物计量

• 角色/触发：就餐人在菜盆取菜，夹子可放回或不放回。
• 范围：食物减重与夹子承重影响；夹子信号不参与“餐盘是否在位”的直接决定。
• 前置：先选择机械隔离夹子，或可靠获得夹子开始/结束的承重状态；校准噪声/固定夹重适用边界。
• 成功后置：符合条件的食物量准确计算；不符合模型时保留异常证据，不靠截零隐藏错误。
• 失败后置：状态未知不自动套用固定扣重，不丢弃已取菜事实。

主流程

1. M1 对齐身份会话，取稳定菜盆开始重量与夹子承重状态s0。
2. M2 记录取菜、夹子动作、补菜/外力及载荷稳定质量。
3. M3 结束时得到稳定W1与s1，校验无补菜/外力等不适用条件。
4. M4 机械隔离有效时直接用前后差；状态补偿方式在模型适用时用 D=ΔW−(s0−s1)T。
5. M5 记录原始差、补偿项、食品净量、模型状态及同一会话标识。

分支/异常/恢复

• A1 两端夹子同态：夹重抵消；A2在→不在：减夹重；A3不在→在：加夹重。
• E1 回位架空但不知道夹子在手还是盆里：夹子状态未知，不能推为任一二值。
• E2 湿夹、带菜、搭边/部分承重、手压、补菜：模型不成立，保留事件并按确认流程处理。
• R1 待外力消失重新取得稳定边界；原会话无法恢复可靠边界时转人工核对，不跨人复用新边界。

规则、实现入口和验收

• BR-W01 修复SPOON_WEIGHT设置get/put问题不等于补偿完成；数据值与状态都要接入。
• BR-W02 现场实际夹重不能用默认20g或示例80g代替；不可每单固定减一次。
• 页面/代码：SetActivity勺重设置、两种取餐中Fragment的重量计算、会话控制器；持久化现有MMKV与新增夹子质量状态。
• 对外API：[不适用：本UC先确认本地计算与证据；需要传补偿记录时另定兼容契约]。
• AC-W01 get改put后重启回读一致、输入合法性通过；UT-W01。
• AC-W02 已知食品量×夹子四状态，误差符合事先约定E_weight；UT/IT-W02。
• AC-W03 机械隔离架有承重独立证据；回盆违规或夹子状态未知能识别为模型不适用；E2E-W03。
• AC-W04 湿/干/带菜/搭边/补菜/手压/网络慢等输入不误归账，负值能解释且不靠简单归零宣布成功；E2E-W04。
• PERF-W01 稳定等待时限及可容忍噪声/误差需实测冻结；SEC-W01补偿日志脱敏并可审计。
• 待确认：用户是否接受独立回位架、夹子状态传感方式、实际夹重变化、E_weight与收尾等待上限；责任产品+硬件+Android+测试，日期待安排。DoR: BLOCKED。

下一步交接

优先建立同一台架的对比实验，先验证现有红外能否读出独立状态；软件修复、存在检测、身份覆盖、夹子计量分别量化，再做整机会话验收。若后续进入云效，按项目规则把详细父UC/开发切片写入正文并回读，不能只放本文件链接。