一句话总结
完成一例生产在途库存缺陷的代码与数据定位，并将 Kibana 隧道大页面卡顿修复为可持久化的 TCP MSS 策略。
今日成果
- 生产只读核对同一采购明细分两次退货后仍显示在途 20，确认真实应为 0，并创建 DGJ Bug 变更包。
- 定位
PoOrderInfoSer.php对同一明细直接覆盖关闭量的根因，明确最小修复为累计多笔关闭/退货数量；未修改生产代码和数据。 - 在腾讯云
wg0 ↔ kzvpn-host转发链路固化 TCP MSS=1200，登录页完整返回约 68 KB、约 1 秒完成，策略服务重启后仍生效。
问题与风险
- 在途数量 Bug 尚未修复或发布，需覆盖分批退货、部分入库/出库和普通采购单回归。
- Kibana HTTPS 443 从云端仍为空响应，属于服务端问题；当前使用 HTTP 入口。
验证与证据
- 生产只读采购/退货/出入库数据与代码计算口径一致。
- WireGuard、两条企业 VPN、策略服务 active；HTTP 小请求返回
401，大页面传输恢复。 - 完整复盘：
/Users/zhoujiangbin/.codex/daily-reviews/2026/08/2026-08-16.md。
下一步
- 按 Bug 变更包实施最小累加修复并完成测试/预发回归。
- 评估历史展示是否需要补偿，不直接写生产数据。
- 将 Kibana 443 空响应交给服务端维护方处理。