熟食称重“先放后选”交互变更记录

代码状态：已实施并通过自动化验证；验收状态：待真实秤体和支付设备真机验收。分支为 refactor_cooked_model，未暂存、提交、推送或切换分支。

1. 目标与范围

稳定零位 → 放置商品 → 等待稳定 → 点击商品直接入车
        → 取走商品 → 用户主动归零 → 新稳定零位 → 下一件

本次调整称重协议读取、重量输入契约、称重周期、商品点击、购物车更新、页面门禁和支付前校验。购物车结构、订单 JSON、支付协议、数据库和上传方式不变。

2. 代码改动

串口与重量输入

• 新增 ScaleFrameAssembler，覆盖半帧、粘包、噪声和错误标记恢复。
• WeightSerialPortManager 只处理完整帧，增加异常断开通知，并修正连接状态与读线程的启动竞态。
• 新增不可变 WeightSnapshot，校验 BCC、负重、溢出、去皮、单位、零位一致性和快照时效，以 BigDecimal 规范化整数克。

称重周期

• 新增纯 Java CookedFoodWeighingStateMachine，管理等待秤、稳定零位、放置、稳定待选、等待取走归零和异常恢复。
• 同一周期先预留再入车，最多成功一次；活动周期断线继续锁定，无活动周期允许定值流程降级。

购物车与页面

• 新增 CookedFoodCartUpdater，以复制后替换方式合并称重行，返回本轮新增金额。
• 称重商品点击直接入车，提示商品、重量、本次新增金额以及取走、手动归零指引。
• 隐藏旧加入按钮，移除预选和二次加入路径，实时价格保持 0.00。
• 定值、手动金额、数量修改、模式切换和支付接入统一门禁；删除和清空仍可纠错。

用户归零与支付

• 系统不会自动归零；仅用户点击归零入口时发送归零命令，命令成功不直接解锁，必须等待新稳定零位帧。
• 打开账单、账单确认和真正发起支付前均复查称重周期。

3. 测试与质量复核

按 TDD 顺序先红后绿，新增或补充 35 个测试场景：组帧 5 个、快照 10 个、状态机 13 个、购物车更新 5 个、购物车行边界 2 个。

JAVA_HOME=$(/usr/libexec/java_home -v 1.8) bash gradlew \
  :app:testDebugUnitTest :app:assembleDebug --console=plain

• BUILD SUCCESSFUL
• 90 个 JVM 单元测试：失败 0、错误 0、跳过 0。
• Debug APK SHA-256：d88fa3b563d16950b12e2ceecfd0fb1cf22ea8b1504cc15c67c854ff1190f201
• git diff --check 无空白错误。
• 仅 zeroScaleByUser() 用户点击链路调用 zero()。
• 复核发现的“不稳定零位仍显示可选择”和“累计重量整数溢出”均已用失败测试复现并修复。

4. 待真机验收

只读预检发现一台已连接的 rk3568_r 设备，但设备上正在运行 com.cpt.cusumption/.activity.OrderVerifyActivity，已安装版本为 versionCode 42 / versionName 2.13.1；本次构建为 versionCode 11 / versionName 1.4.0。直接安装需要降级并会中断正在运行的业务页面，因此本次没有安装 APK、操作实体秤或触发任何支付。

1. 核对目标秤固件的稳定、零位、去皮、单位和 BCC 原始帧。
2. 验证半帧、粘包、拔线、重连和 3000ms 快照超时。
3. 验证慢放、快放、抖动、连续点击、取走、页面归零和实体键归零。
4. 核对同商品跨轮累计金额与每轮提示金额。
5. 验证无活动周期故障时的定值、手动金额和结算降级。
6. 账单打开后放商品，分别验证刷卡、扫码和人脸确认被拦截。
7. 验证支付成功、失败和离线记账后的购物车、秤状态与下一轮。

继续验收需要专用测试设备，或确认当前设备可中断、允许降级安装的维护窗口，并准备不会产生真实扣款的测试卡、测试码和人脸账号。

5. 风险与回滚

主要剩余风险是不同秤固件的零位标志和上报周期差异，真机验收前不标记全面验收完成。本次没有数据库或服务端迁移，可回退熟食页面和新增称重模块。是否提交由用户决定。