变更目标
汇总 410 型优卡特称重台扫码短暂断码问题的两类处理方案,形成后续产品、客户端、服务端、硬件、测试和交付共同评审的统一入口。
新增内容
- 新增正式方案文档:
docs/2026-09-10-scan-interruption-two-layer-order-protection-plan.md。 - 新增同名 HTML 人审版本。
- 统一说明两层职责:
- 900~1200ms 断码宽限是前置防抖主防线;
- 2 分钟断连订单过滤是后置纠错兜底。
- 记录当前源码实际状态:连续空码次数已经可配置,但独立时间窗口和服务端纠错规则尚未完整实现。
- 汇总红外逐步关闭的灰度要求、职责边界、建议数据字段、分阶段实施顺序和验收标准。
- 将用户提供的业务截图仅作为需求上下文,不作为已经上线或验证通过的证据。
关键决策
- 不把两个方案理解为二选一,应形成前置预防与后置兜底的双层保护。
- 不用控制板重复包数量直接换算真实扫码失败次数;优先使用单调时钟计算断码持续时间。
- 后置纠错建议由服务端负责,Android 补充会话、起止稳定重量和幂等字段。
- 原订单明细建议业务作废或冲正,不建议物理删除。
- 后置规则先运行“只检测不改账”观察期,准确率经人工评审后再灰度自动纠错。
证据与边界
- 源码状态来自
ZhctWeightingTableYoukate当前zymy_ongoing分支只读核查。 - 硬件时序来自 2026-09-07 会议纪要,仍待供应商书面说明或抓包确认。
- 2 分钟、至少 4 条、5g、15g 规则来自用户提供的业务方案,字段语义仍有 P0 待确认项。
- 本次只修改
zhctprompt文档,没有修改 Android 业务源码、服务端代码、数据库或设备配置。
验证标准
- Markdown 与 HTML 标题、章节、结论、规则和表格语义一致。
- 文档同时包含当前实现、目标方案、未实现项、风险、P0 待确认项和验收标准。
- 所有项目内来源路径真实存在。
- 不包含账号、密钥、客户个人信息或生产敏感配置。
git diff --check通过。
人审状态
- 状态:待评审。
- 待评审角色:产品、Android、服务端、硬件/控制板、测试、结算/财务和现场交付。
- 本记录不表示方案已经实现、发布或通过真机验收。