2026年07月工作日报 📌

这里按天记录工作内容、遇到的问题和当天的一点想法，方便月底回看。

2026/07/20 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

推进 POS 刷卡返回 0 排查，确认 posBankCardPay=1 只代表开关透出，真正发起还要看 retail-trade-core 支付链路是否带全 POS_BANK_CARD 和终端信息；当前重点收敛到发布状态、资产侧开关和支付参数透传边界。
推进 ONLINE-980193 门店 POI 问题排查，已从 JIRA 抽到 trace 和时间窗，但没有直接命中 app；后续需要继续用 trace 和关键词双向补证，把问题落到具体仓库和模块。
核查 OrderOperateOpenService.addRemark 类型异常，确认本地业务源码里没有直接调用点，问题更像发生在编译依赖、运行时 Dubbo 泛化或开放服务代理层；目前还需要方法签名和参数位置证据来判断是否为接口版本差异。
梳理 code-sentry 记忆召回链路，确认分析 run 里会做 pre_recall 和 evidence_enhanced 两次召回，命中的生效记忆会进入右侧“记忆召回”块，而不是 Timeline 里的独立步骤。
对齐 code-sentry 记忆展示和规则分层，明确记忆不应该只暴露底层字段，更要说明“什么情况下命中、命中后注入什么、分析时应该怎么用”；同时把“发布后错误不等于发布引入”沉淀成全局分析规则。
解析发布分析 prompt 的记忆注入方式，确认当前不是把整库全量塞入，而是先召回相关经验再完整注入；同时发现两条 NPE 经验与本次 PurchaseSuggestService 错误关联偏弱，后续要优化召回精度、去重和可观测性。
确认 GitLab 地址修改边界和本机 Git 提交身份，明确截图里改的是项目路径不是 Group 路径；当前仓库生效的提交名和邮箱来自全局 .gitconfig。

🧩 困难/需要帮助

POS 刷卡和 ONLINE-980193 还缺更完整的 trace、app 映射和配置/发布侧证据，暂时只能把范围收敛到链路和模块，不能直接下最终根因。
addRemark 类型异常还需要拿到运行时接口签名、依赖版本或 Dubbo 参数位置，才能确认是调用方传参问题还是 API 版本差异。
code-sentry 记忆系统还要继续对齐案例记忆、全局规则和 prompt 注入的边界，尤其要避免弱相关记忆因为异常类型相似而带偏判断。

💭 感想

今天主要是在把几个问题往真实链路和判断口径上收，支付、JIRA、Dubbo 异常都不能只凭现象下结论，还是要回到 trace、配置、接口签名和发布前后对比。

code-sentry 这边的方向也更明确了，记忆不是越多越好，关键是命中条件、注入内容和使用方式要讲清楚。

2026/07/22 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

梳理 PLU 价格取值异常整改，确认 PRD/RFC 里的核心矛盾是 PC 不新增字段却要求后端保留 PLU 标签金额；当前口径收敛为 BCartService.addGoods/sync 统一承接 pluAmount，在商品价和重量就绪后做 <=1分 校验并写入购物车。
核查 prod 终端绑定消息消费，确认 customer_core_pos_terminal_change 由 retail-trademanager 的 PosTerminalBindConsumer 消费，09:42:52 和 09:43:10 两条 ALLOCATION_CHANGE 已命中接收日志，同窗口没有参数异常、处理失败或重试日志。
继续追 POS 终端绑定落库细节，确认首次 insert 触发 uniq_provider_sn 唯一键冲突属于幂等 upsert 分支，不等同于消费失败；后续重点放在冲突后的 select + update 是否把绑定状态更新到预期。
梳理飞书转发字段，确认实际请求体只有 deployer、templateData、feishuGroup、msgType 4 个顶层字段，业务字段都在字符串化的 templateData 里，其中 mrIid 是 GitLab MR 的项目内编号，多 MR 时会拼接展示。
完成 youzan-cli 使用方式梳理，确认它是覆盖商品、客户、订单、营销、店铺、企微、进销存等领域的 Node.js 命令行工具；首次使用链路是安装、授权、auth status 验证，再通过 --help 和 schema 找到具体查询或导出命令。
解释 JsonUtils.toJson 和 json2Bean 的边界，确认 toJson 是 Java 对象到 JSON 字符串的序列化，不会校验或修复字符串里的不规范 JSON；如果输入本身是 JSON 文本，更适合走反序列化或显式校验。

🧩 困难/需要帮助

PLU 价格整改还需要继续对齐 PC、前端和后端的字段契约，尤其是 pluAmount 单位、isPlu 复用边界、>1分 时返回 CART_PRICE_ADJUST_ERROR 的一致性。
终端绑定消费层面已经没有失败日志，但唯一键冲突后的 select + update 落库结果还要继续用数据或 trace 证据确认，避免只停留在“消费者收到消息”这一层。
飞书转发字段已收敛到请求体和 templateData，后面还要和实际模板展示口径对齐，避免字段存在但卡片侧没有按预期使用。

💭 感想

今天主要是在把几个问题往真实代码链路和接口契约上收敛，POS 终端绑定和 PLU 价格都不能只看现象，还是要落到 topic、consumer、DTO 和金额校验点。

工具使用和飞书转发这两条更偏口径梳理，写清字段来源和使用边界后，后面排查会少很多来回确认。

2026/07/23 今天做了啥？ ✨

今天主要是在把 5 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成交班优惠计算问题分析，确认多出的 0.01 元来自订单 E20260718204921088300063 的统计口径，不是打印机或外设链路多收；retail-printer/retail-peripheral 只是格式化上游 couponPayAmount 后打印。
梳理交班统计链路，确认 retail-sync 负责交班期间逐单累计，retail-trademanager.getStaffShiftWorkDetail 负责读取并组装交班详情；其余 10 笔订单与支付流水一致，差异收敛到单笔抖音券核销金额与真实支付金额的 1 分偏差。
推进扫码点单禁用规格展示排查，确认 retail-trade-misc#searchV2 返回了 33 个 SKU，而扫码点单分组配置里的 hiddenGoodsSkus 为空数组，因此服务端没有按装修隐藏配置过滤规格。
明确扫码点单问题边界，当前只处理“后端为何返回禁用规格”，不合并 iPad 盘点问题；验收口径收敛为服务端响应中不再包含 disableStatus=1 的 SKU。
梳理 code-sentry 命名和域名方向，确认产品定位更接近“发布风险分析 + 代码审计工作台”，不适合继续围绕 monitor 命名，也要避开 Sentry 这类已有强品牌词。

🧩 困难/需要帮助

扫码点单还需要继续确认商品中心“禁用规格”和装修页“隐藏规格”的职责边界，尤其是 disableStatus=1 是否必须在 searchV2 服务端统一过滤。
交班优惠修复方案还要对齐抖音券核销金额、真实支付流水和交班统计三方口径，避免修 1 分差异时影响历史报表或其他券类型。
code-sentry 命名还需要结合域名可注册性、商标风险和现有产品占用继续筛选，避免只从含义上判断。

💭 感想

今天主要是在把两个线上问题往真实数据口径和代码链路上收敛：扫码点单要分清商品禁用和装修隐藏，交班优惠要分清核销口径和支付流水。

这类问题看起来都是“展示不对”或“金额不对”，但最后都要落到具体接口、配置字段、订单和金额来源上，先把边界钉清楚比直接改代码更稳。

2026/07/25 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

推进满减送重复赠送排查，确认 JIRA 指向生产环境、两个 trace、两个店铺和 7 月 24 日时间窗；关键 trace 已命中 iOS RetailHD 8.51.1 调用 increaseQueryActivity(activityType=8, activityId=0)，并由 retail-ump.IncreaseQueryServiceImpl 返回活动 4365206090 的赠品能力开关信息。
核对 retail-ump 仓库和数据口径，确认远端是 retail-service/retail-ump.git，工作区干净；表结构里 ability_status 默认值是 1，且 (kdt_id, activity_id) 有唯一键，因此先排除“字段 DDL 默认写 0”这个方向。
梳理赠品能力开关的代码链路，已命中 PresentDetailQuery、PresentOperateHandler、DAO/MyBatis 和现有单测，问题边界从“重复赠送现象”收敛到活动开关默认值、创建继承逻辑以及总部/门店数据分布。
定位发布预警分析空结果，确认失败点不是 HTTP 或鉴权错误，而是成功响应后没有最终文本，或连续 12 轮调用耗尽仍没有结论；分析器目前固定只重试 1 次，所以会进入 Retry Exhausted。
验证跨应用错误日志抓取，确认 retail-trade-core 的 ERROR 和 yz-cardvoucher-biz 的 WARN 可以通过同一个 traceId 关联；但只查单应用不会自动展开跨应用日志，需要显式把 trace 传给后续分析链路。
梳理 ONLINE-981860 初步边界，确认问题发生在生产环境 retail-trade-misc、店铺 91106488，时间集中在 12:24-12:26，当前没有 traceId；已先把 JIRA 产物落到 .doc/20260725130355-ONLINE-981860/jira，后续用截图、店铺 ID 和稳定日志短语补证。

🧩 困难/需要帮助

满减送问题还需要继续直查目标记录、总部/门店整体分布和近期开关继承结果，才能把默认值、创建链路和实际重复赠送现象完全闭环。
发布预警空结果还缺线上 run 的原始节点和调用产物；当前账号能看到审计表结构，但 qatools 审计表为空，暂时不能把“调用耗尽”当作最终根因。
ONLINE-981860 缺少 traceId，后面需要从附件截图、JIRA 评论和 12:24-12:26 的生产日志里继续补业务现象和调用链证据。

💭 感想

今天主要是在把满减送和发布预警两个问题往真实 trace、数据库默认值和代码分支上收敛，能确认的先写死，缺证据的地方先留边界。

跨应用日志这块也更清楚了：trace 能把链路串起来，但工具侧的补日志范围、数量和权限还是要讲清楚，不能只说“能查到”。

2026/07/26 今天做了啥？ ✨

今天主要是在把 5 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成 ONLINE-981928 深度分析，确认取餐状态本身已处理成功，真正断点在 retail-trademanager 获取小程序订阅模板时返回 132900009，后续又被伪模板 ID 放大成微信 40037 invalid template_id，所以顾客没有收到取餐提醒。
梳理 retail-trade-misc -> retail-trademanager -> msg-push -> wechat-push 的完整链路，确认 MessageClient#getMiniProgramTemplate 在失败时会兜底写入 Default-Mini-Program-Subscription-Template-ID，而 FreeBuyForMealTakeMessageHandler 又无条件继续发送，这是这次问题的关键代码点。
对照 JIRA 截图、trace 和评论，确认影响对象收敛到父店铺 160734909、子店铺 206598416、订单 E20260725181329036406197，模板范围是 1820 / order_state_meal_take，当前可以排除订单未完成和消息链路整体不可用。
输出了代码修改方案和验证计划，明确模板缺失时要在公共订阅消息链路直接阻断发送，补齐结构化日志，不再把模板配置缺口包装成“发送成功”。
整理了技术支持、商家和产品侧的对外口径，统一成“订单正常完成、模板查询失败、微信最终拒发”三层事实，避免只盯着表面消息成功。

🧩 困难/需要帮助

模板中心还没有直接补到 160734909/206598416 + 1820 + order_state_meal_take 的真实记录和授权状态，责任边界只能先停在“待补证”。
代码层还需要确认是否统一收紧伪模板兜底，避免后续其他订阅消息 handler 也沿用同类错误分支。

💭 感想

今天主要是在把问题往真实模板链路和配置边界上收，sendCount=1 这种上游成功信号不能直接等同于用户侧送达。

这类问题一旦把模板查询失败和微信回执拆开看，链路就清楚很多，后面要补的主要是模板中心证据和统一失败策略。

2026/07/27 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

推进拆条目金额错误排查，确认折扣条目单价 2.38、数量 1 时小计显示 6.38 的问题已在后端回包里出现，不是前端展示字段映射；当前范围收敛到 retail-trade-cart 拆条和营销回包重构条目链路。
完成 PLU 秤码金额差异分析和修复核对，确认 isPlu=true 且 PLU 金额与计算金额差异 <=1 分时应统一取 pluAmount，目标分支 8 个 *PluAmountTest 已通过；另一个 7.30 元标签价 trace 与商品中心 3.40 元/kg 算价差 11 分，属于条码秤和商品中心价格未对齐，不应走 1 分容差。
完成 ONLINE-981990 活动叠加异常分析，确认不是 EXCLUDED 配置失效，而是加价购 JS 先按普通商品原价判断门槛，随后又从整车商品里挑换购 SKU，导致被排除的清新蓝莓仍被打上 EXCHANGE_GOODS 并改成 5 元。
查明重开单门店日流水号逻辑，确认重开单分支在 SyncRetailDataProcessor#getSerialNo 里调用 queryCurrentSerialNo(kdtId)，只读取当天门店 Redis 计数器当前值，不会 +1；普通门店单才会走 addSerialNo(kdtId) 自增。
评审三方券/交班尾差修复方案，确认 1 分差异不是订单实收多收，而是旧接口用“单券金额 * 张数”表达不了 287.67/287.67/287.66 这类分摊尾差；后续要在 Provider 和两个 Consumer 的兼容字段、回退逻辑上一起收口。
确认 Case 记忆沉淀列表和算法观察页两个线上问题的修复状态，当前用户可见故障仍未修复：前者生产接口仍返回 HTML 500，后者页面只在 feature/release_memory 分支且仍硬编码 /api，放到 /reports 路径下会打到错误网关。
梳理 CLI 接入 MCP 的授权、店铺选择和会话隔离方案，明确 MVP 先走本地安全文件保存 token + 显式 selected_kdt_id；“输入手机号直接枚举全部可访问店铺”不是当前 token 模型天然提供的能力，先作为后续账号/授权中心能力处理。

🧩 困难/需要帮助

PLU 和拆条金额治理还要继续对齐条码秤价、商品中心价、PC 透传字段和后端计算口径，尤其是 <=1 分取 pluAmount、>1 分阻断的边界要保持一致。
ONLINE-981990 的修复还需要继续确认门槛判断、排除商品能否作为换购品、会员价后是否需要撤销换购计划这几个边界，避免只修当前蓝莓案例。
两个线上页面问题还缺最终部署版本和网关路径改造确认，目前只能明确“用户路径仍异常”，服务端根因还需要继续补证。

💭 感想

今天主要是在把几个金额和活动问题往真实代码链路、日志 trace 和数据口径上收。PLU、拆条、三方券尾差都不是简单“金额算错”，关键还是要分清标签金额、商品中心价、单值乘数量的表达能力和最终展示字段。

线上状态核验也要把用户可见故障和服务端根因分开写，能确认的先确认，缺部署和配置证据的地方不要提前下死结论。

2026/07/28 今天做了啥？ ✨

今天主要是在把 6 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成 PLU 会员价支付校验问题分析，确认支付侧 27.81 - 0.87 = 26.94 的总额口径本身没错，异常集中在 trade-core 商品行和订单聚合字段；计件 PLU 叠加会员价二次营销均摊时，标签金额被按单价和数量重新计算，少了 1 分，导致商品明细 26.93 和订单/支付 26.94 对不上。
梳理 retail-trade-cart 的 addGoods 改价字段链路，确认 pre 环境后端入参已经收到 pluAmount，问题不在 PLU 前缀或重量解析，而在 CartGoodsRequest.isChanged/changedPrice 与网关 changed_tag/change_price 之间的字段契约和绑定口径。
推进移动端订单报表缺失排查，当前主线已从刷卡支付状态机转到 pos-trade-order 和 pos-shift-daily-report；代码信号显示商品销售报表依赖 PcOrderItemPrice.totalPrice，没有价格对象时金额会降为 0，但还需要实单字段和报表落库证据继续闭环。
定位 Code Sentry Case 记忆未沉淀问题，确认不是飞书消息发送成功后就自动生成记忆，也不是 2a1c2867 修复后的写库链路仍失败；生产发送记录已能写入，当前根因收敛到发送数据被过短字段截断，随后被页面筛选条件过滤掉。
梳理重开单门店日流水号修复意图，确认旧逻辑在重开单时读取门店 Redis 当前流水号，可能拿到旧单之后新生成订单的流水号；新逻辑改为通过 reOrderNo 查询被重开的旧订单持久化数据，并复用旧单流水号。
核查 dev-skill 的 Windows 安装支持现状，确认当前安装入口仍是 make + bash 的 Unix-first 流程，不能算正式支持原生 Windows；方案已收敛到补 PowerShell 5.1+ 安装/卸载脚本，使用 Junction 降低普通用户权限要求，同时保留现有 macOS/Linux 流程。

🧩 困难/需要帮助

PLU 金额治理还需要继续对齐 PC、网关、retail-trade-cart 和 trade-core 的字段契约，尤其是 pluAmount、isChanged/changedPrice 以及 1 分容差和大于 1 分阻断的边界。
移动端订单报表缺失还缺实单字段值、报表落库结果和过滤条件证据，暂时只能把可疑点收敛到价格对象缺失分支，不能直接定最终根因。
Code Sentry 记忆列表还需要确认字段长度修复、历史数据回补和页面 API 读取同一数据源这几件事，否则用户侧看到的 0 记录还不能算完全闭环。

💭 感想

今天主要是在把 PLU 金额、报表缺失和 Case 记忆这些问题往真实 trace、字段契约和数据表筛选口径上收敛。

几个问题看起来都是“金额不对”或“页面没数据”，但真正要判断清楚，还是要一层层确认字段从网关到后端、从写库到页面是否都在同一个口径上。

2026/07/29 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成 ONLINE-981236 交班/日结三方券尾差修复，确认根因是旧接口只提供“单券金额 × 数量”，三张券真实支付金额 28767+28767+28766=86300 分被算成 86301 分；当前已在 retail-trade-misc 补 totalCouponPayAmount，retail-sync 和 retail-trademanager 改为消费新字段。
收敛三方券修复范围，明确 retail-trade-misc 负责按 buyerPayPrice 算准整组券实际支付总额，retail-sync 只替换 8 处旧乘法取值，retail-trademanager 只替换 1 处待支付金额取值；新字段为空时继续回退 couponPayAmount × count。
补强三方券链路观测，misc 记录映射不完整和查询异常，sync 记录精确金额命中数和旧逻辑回退数，trademanager 记录券明细为空及旧公式回退；同时确认不打印券码、不逐券刷日志，避免高频链路被噪音淹没。
推进 yz7/PLU 下单失败排查，确认不是购物车校验失败，而是下单阶段 retail-trade-cart 与 trade-core 两套计价口径不一致，零售应付 47.57 元、计价侧 47.48 元，相差 9 分后触发 RetailExtraPriceCalculator.checkPrice 金额一致性保护。
梳理 PLU 改动范围，确认问题边界在“改价事实、商品优惠、订单优惠”三层金额契约没有完全对齐；当前不能简单改通用 realPay 或全局优惠均摊，需要把 PLU 精确金额、改价金额和 PROS_DETAIL 重新均摊链路一起对齐。
推进 Code Sentry 发布告警记忆能力，确认 MySQL VARCHAR(2000) 和索引长度风险后，完成字段限额、超限压缩重试、人工编辑 400 明细返回、双召回 Top2 和 6000 字符注入控制；全量测试 49 个文件、233 个用例通过并推送远端 master。
补齐 dev-skill Windows 原生安装支持，新增 PowerShell 5.1+ 安装入口和安装器，覆盖 dry-run、install、uninstall、force、profile、客户端检测等常用流程；Windows 路径改为按用户目录解析，不硬编码用户名，README 也已同步更新并推送。

🧩 困难/需要帮助

三方券兼容回退场景仍可能复现旧尾差，需要继续确认 trade-misc-api 二方包发布、MR 合入和 QA 新单验证节奏。
PLU 问题影响面偏中高风险，优惠券会在多个商品之间重新均摊，仍需要产品、营销、交易一起确认改价事实、商品优惠、订单优惠三层金额契约。
Code Sentry 旧分支不能整分支合并，旧表结构和当前 VARCHAR-safe 方案有冲突，后续需要选择性迁移控制台、灰度策略和召回观测能力。

💭 感想

今天主要是在把几个问题往真实链路和字段口径上收，尤其是金额类问题，本质都是上游字段语义没讲清楚后被下游二次解释。这个方向比较明确，但后面还是要先把字段契约、回退边界和观测点定清楚，再做最小代码改动。

2026/07/30 今天做了啥？ ✨

今天主要是在把 7 个重点事项往真实链路、明确口径和可落地结论上收，既有问题排查，也有流程和记录方式上的整理。

✅ 工作内容

完成拉卡拉 POS_BANK_CARD 支付拦截定位，确认 retail-trade-core 提示“当前 POS 机未绑定该门店”不是 SN 不存在，而是 retail_pos_terminal_bind 中 SN 00000104YP620300016136 绑定到 kdtId=159831351，未绑定到当前下单门店 201479448；支付前校验口径是当前 kdtId + deviceSn + is_deleted=0，rootKdtId 和收款归属不参与命中。
收敛拉卡拉支付渠道错误链路，确认另一条链路里 retail-trademanager.queryEnabledBind 已返回终端 usable=true、status=enabled，问题不在终端绑定，而是继续收敛到支付资产/渠道配置或 deepLinkInfo 生成链路。
完成 PLU 739/738 一分差修复和审计，已按“改价重算金额与 PLU 总价相差 <=1 分时取 pluAmount”的口径落到 ProductEntity；继续审计发现营销 JS、本地购物车和预约开单等路径仍可能重新按单价 × 重量计算，需要补齐 pluAmount 透传和统一一分校验。
推进 ONLINE-981236 三方券尾差 RFC 和只读评审，确认正式 RFC 已写好并推送 codex/ONLINE-981236-rfc；评审中进一步确认 totalCouponPayAmount 挂在通用 transferResp/queryCoupon 明细上，不是只影响抖音券，平台分支、组合支付和降级回退还要继续核对。
对齐 Code Sentry 双召回 MVP 和 005 迁移口径，明确不做灰度，改为新旧召回始终双跑、只用全局 active_algorithm 控制注入；005 已从六表收敛为三表，删除冗余字段和索引，统一 updated_at，聚焦测试 12/12 通过。
梳理 Code Sentry 召回观测和记忆沉淀页展示，完成分页列表、行内展开、应用/发布单/任务号/标题搜索，以及阶段和差异结果筛选；同时确认“分析”列只取简要分析，不再用建议动作兜底，避免页面语义混在一起。
补齐 POS workspace 文档和前端应用接入说明，README 已同步 20 个 submodule、retail-node-setting、retail-pc-prepaid 等前端应用职责，以及储值、拉卡拉终端、交班日结、打印等 skill 路由；make check-workspace 通过并已推送 master。

🧩 困难/需要帮助

拉卡拉问题还需要继续补齐资产侧分配对象、支付渠道配置和 deepLinkInfo 生成证据，尤其要把“总部收款”和“当前下单门店校验”两个口径分开，避免后续排查误判。
PLU 金额链路仍要继续对齐 PC、网关、本地购物车和营销 JS，核心是所有入口都能稳定使用 pluAmount，并保持 <=1 分取标签金额、>1 分阻断的边界一致。
Code Sentry 双召回目前更适合按 MVP 测试验证，生产前还需要确认 001-005 迁移执行、表结构/索引校验和线上 checksum 边界。