OPC/goauto
2
0
Fork 0
Code Issues 207 Pull Requests Actions Packages Projects Releases Wiki Activity

fix(server): 修复 SYB 连写尺码未识别导致颜色尺码对换，并定向纠正受污染规格 #358

New Issue
Open
opened 2026-10-06 10:57:39 +08:00 by ila · 5 comments
ila commented 2026-10-06 10:57:39 +08:00
Owner
Copy Link
Copy Source

基本信息

  • 类型：缺陷
  • 所属 Epic / MVP：无；关联 #216（规格顺序识别）、#290（ERPGo 完整规格同步）、#301（规格键消歧）。
  • 阶段：代码已发布；用户指定的 1 条历史 SYB 商品明细与对应蝦皮档案的 2 项错误反向值均已独立授权、定向纠正并回读验证，待用户验收。

原始需求与基线

  • 来源：用户对话，2026-10-06。用户报告一个 SYB 订单商品的颜色、尺码对换，在核对原因与最小方案后要求建工单。
  • 核验代码基线：线上 release 20261006-0a79c83-356，源码提交 0a79c83a958c5d4edc3798c21e15402afa787af1；本地 main 955b34ad810d8f9d54b60491b039d2804375c350。
  • 只读核验发现：同一订单三件商品中一件错误；订单原始规格按“尺码,颜色”排列，尺码为字母尺码和体重范围无空格连写。GoAuto 保存为相反维度，parse_status=success，非人工/AI 确认。ERPGo 当前接口返回正确颜色/尺码，无解析警告。
  • ERPGo 正确规格已补入档案，但旧反向值仍保留，导致同一值出现在两个维度。未修改线上数据。
  • 工单仅保留脱敏事实和合成样例，不保存真实订单号、商品数据、完整响应、凭据或原始日志。实施生产修复前由用户确认原报告对象与精确影响集合。

依赖与并行

  • 依赖现有 #216 / #290 / #301 实现；不依赖 ERPGo 新版本，不要求 Android/Web 配合。
  • 不与涉及同一解析函数或同一档案的数据修复并行，避免规则漂移和覆盖。
  • v2 纳入一次合并前的新旧解析只读回归对比：范围仅限线上全部去重 productSpec 及统计受影响明细/商品数量所需的最小关联信息；不作通用全库审计、不全量重解析、不写业务数据。

子项目影响

  • server：SYB 规格解析、共享规格键相关回归测试；已报告对象的定向数据纠正。
  • shared-docs：业务规则与术语 Wiki 中补充支持的尺码形式。
  • 不修改 Web/Android、ERPGo、共享 API、数据库结构、权限或任务状态机；不预设追加业务库迁移。

根因与代码证据

  1. server/app/goauto/sybspec/parse.go 的 explicitSizePattern 使用首尾完整匹配，能识别独立字母尺码或独立重量范围，却不能识别两者连写。
  2. Parse 两侧都没有命中尺码证据时沿用“前颜色、后尺码”并记 success，导致反向输入被错误接受。
  3. server/app/goauto/sybimport/apply.go 的 mergeParsedSpec 将错误值并入蝦皮商品档案。
  4. server/app/goauto/task/spec_sync.go 与 server/app/goauto/shopeeproduct/specs.go:Merge 按维度增量补充、保留旧映射，不承担旧错误值删除或 SYB 明细重解析。
  5. server/app/goauto/sybimport/ai_parse_batch.go 仅挑选 uncertain/failed；这条 success 明细不会进入异常 AI 解析。

复现与目标契约（合成样例）

  • 输入：XL65-70kg,123深藍。
  • 当前：颜色=XL65-70kg，尺码=123深藍，状态=success。
  • 期望：颜色=123深藍，尺码=XL65-70kg，状态=success。
  • 反向输入 123深藍,XL65-70kg 应得到同样结果。
  • 保留尺码完整原文，不把重量说明丢弃，不擅自改成 XL。
  • v2 明确包含带空格形式：2XL 60.0-67.5公斤,黑色 及反向输入均正确识别；独立输入 2XL 60.0-67.5公斤 应识别为仅尺码。这是有意纠正此前“仅颜色”的错误，必须单独测试。

已确认最小方案 / 不做什么（v2，整合审核 M1～M3）

M1：最小识别语法与共享路径

  1. 明确包含“字母尺码＋可选空白＋数字体重/范围＋重量单位”，沿用现有字母尺码和重量单位集合，首尾完整匹配。例如 (?:x{0,4}[sml]|[2-9]xl)\s*<体重或范围><单位>；继续仅在一侧有明确尺码证据时决定角色，不用任意 XL/L 前缀匹配。
  2. 优先只修改 explicitSizePattern 一处。RawSpecHalves 已复用 Parse 结果，ResolveKeys 基于两者，不新建第二套角色判断。
  3. 合成回归覆盖正反顺序、空格/无空格、独立带空格尺码、已有纯字母尺码/体重/括号说明、单维度、数字前缀颜色、非尺码字母描述及双侧尺码的原有 uncertain/持久化失败语义。
  4. 为 RawSpecHalves 和 ResolveKeys 增加独立反向样例及同商品多规格塌缩样例；不塌缩且未受本规则影响的键应与旧版逐字一致。
  5. XL(65-70kg)、XL/65-70kg、异常单位后缀不顺手兼容；只读对比发现时分类报告，是否纳入另行确认。

M2：合并前只读回归差异清单

  • 使用基线和候选版本实际 Go Parse 实现，对线上全部不重复 productSpec 做一次比较，不用另一语言重写解析器冒充行为对比。
  • 只读最小规格字段，去重/数量关联在受限环境内处理；优先内存，不导出原始业务样本至仓库、工单、消息或日志。
  • 分类统计：对调被纠正；success 变 uncertain（两侧均成为尺码）；单维度颜色变尺码；其他变化；另记未变化数量。统计涉及的唯一规格数、明细数、商品数，互斥分类避免重复计数。
  • 工单仅记录汇总数量、合成样例、代码版本与核验时间。解释每类变化；未解释的变化或正常规格回归不得带入合并。
  • 这是 v2 新纳入的实施前验证范围，不代表已执行，也不授权任何全量数据修复。

M3：历史修复路径与边界

  • 明细：修复发布后，既有同步会重解析窗口内的明细；不得承诺所有人工/AI 确认数据都会被覆盖。窗口外已确认在范围内的明细，复用现有 ReparseBatch，先核对实际默认跳过/force 行为，保持 force=false，不绕过人工确认保护。额外 AI 确认变化须先报告，不盲目覆盖。
  • 档案：现有 Merge 只补充，不会删反向旧值。本单包含的是一次性定向写入，不是新增通用自动清理功能，也不是数据库结构迁移。
  • 默认候选范围仅为用户原报告的一件商品及两项错误维度值。实际写入前向用户私下列出精确商品、明细 ID、两个值及所在维度、预期变更数量，独立获得数据修复授权；工单只保存脱敏对象代号和结果，不写真实业务数据。
  • 写入前校验：确为此次解析造成；不是人工维护条目；检查同商品其他明细引用、人工/AI 确认及映射；错误条目挂有已确认 PDD 映射、仍被其他明细依赖或校验与预览不一致时，停止并报告，不能自动删除或扩围。
  • 明细修复复用服务已有事务；档案清理在单独事务中执行，重新校验当前数据/版本，防止覆盖并发修改，重复执行应安全无变更。不能把两阶段描述为已具备跨 API 的单一原子事务。
  • 执行前按现有运维规范在受限位置留存必要恢复依据；保留 raw_json、正确维度值与有效映射，不改既有采购任务快照，不创建/执行采购，不付款。
  • M2 若发现其他商品污染：报告数量和是否需要纠正档案；是否扩大明细重解析或档案清理由用户决定，不静默扩大，也不能在未处理时宣称全部修复完成。

不做：修改 ERPGo/Web/Android、改变通用 Merge 语义、每次同步全量覆盖、额外 AI、全局跨角色删除、定时任务成功数据重扫。AI 匹配不能代替源规格纠正。

预计涉及：server/app/goauto/sybspec/parse.go 及测试，必要的 sybimport 回归测试；优先使用现有 ReparseBatch。若需新增接口、迁移或通用工具，须重新确认范围。

设计与原型门禁

  • 类型：非 UI、恢复既有正确角色识别的缺陷；无需 UI 原型，不改页面布局。
  • v2 流程：最小尺码语法及回归测试 → 新旧 Parse 只读差异核验 → 现有共享键/导入路径 → 单独授权后的定向历史纠正。
  • 2026-10-06：用户要求整合 Claude 审核评论 8836（SynapBus #49/#50），本正文为 v2。包括 M1 带空格语法、M2 只读全量去重规格对比及 M3 修复边界；实施、线上写入和发布仍另行授权。
  • 未要求 HTML 导出或任务快照。

验收标准

  • 连写/带空格尺码与颜色交换顺序均正确，尺码完整原文不丢失；独立带空格尺码识别为仅尺码。
  • 合并前完成新旧 Parse 只读差异清单，按类别汇总规格/明细/商品数量，所有变化有解释，无未解释回归。
  • RawSpecHalves/ResolveKeys 对调和塌缩样例通过，未受影响键保持稳定。
  • 正常颜色在前/尺码在后、单维度、括号清理和键消歧行为无回归。
  • 数字前缀颜色、非尺码字母描述不被误判；双侧尺码不被任意指定颜色。
  • 修正后的明细与蝦皮档案角色一致，错误反向条目不再污染该对象匹配；正确映射保留。
  • ERPGo 重同步或同一 SYB 明细再次同步不会重新注入本次错误；无需改 ERPGo 或扩大 AI 定时扫描范围。
  • 定向数据修复有独立授权、精确范围、写入前校验、事务、幂等性及恢复依据；人工确认、正确映射、无关数据和采购快照不受影响。范围外污染明确列为待用户决定，不默认扩围。
  • 代码测试、实际执行与未验证项、提交哈希集中回写，工单待用户验收，不自行关闭。

验证方式

  • 在 server 目录执行：go test ./app/goauto/sybspec ./app/goauto/sybimport ./app/goauto/shopeeproduct ./app/goauto/shopeespec。
  • 先核验测试基线，再运行受影响规格同步/采购键定向测试；不用真实下单验证解析。
  • Claude 报告 main 的 sybimport 包原有 12 个失败，此为历史审核信息，实施时须在相同环境重现并记录具体失败列表，再与修改后对照。不能未经复核认定所有失败都是存量，也不能要求修复无关旧失败；本次新增用例和受影响回归必须通过。
  • 合并前执行 M2 只读差异核验，记录新旧提交及汇总结果；不会因为允许读取就执行线上写入。
  • 线上数据纠正前后只读比对角色、映射及受影响数量；回写工单仅记录脱敏结果，不上传业务数据。
  • 建单时仅完成只读根因核验；截至本次更新已完成代码验证、发布和授权定向数据纠正，详见实施、发布与修复评论。线上主动重同步验收尚未执行，不以接口回读代替该验收。

风险与回退

  • 过宽的尺码表达式可能误伤商品描述，必须限制为明确尺码＋体重格式。
  • 代码回退可恢复旧版本，但不能自动恢复已修复数据；生产写入前须按现有运维规范在受限位置留存必要恢复依据，不进入仓库/工单。
  • 生产数据变更、迁移（如后续确需）及发布必须分别具备明确授权；本次工单方案更新不构成代码实施或上述高风险动作授权。

文档影响与任务记录

  • 更新业务规则与术语 Wiki：补充明确连写尺码识别范围及保留原文规则；长期事实变化后在线更新/回读，执行一次 sync 与 sync --check。
  • API、数据库结构、部署方式无变化，不新增对应契约或部署文档。
  • Gitea 为任务唯一事实来源；不创建任务快照，不导出生产样本。
  • Gitea 交互说明：当前工具清单未提供 Gitea MCP，故回退已配置 Gitea REST API；凭据仅从本机私有配置读取，不输出。

需求变化记录

  • 2026-10-06 v1：建单，最小识别修复及已报告对象定向纠正。

  • 2026-10-06 v2：按用户要求将评论 8836 整合进正文；明确接受带空格写法、新增合并前只读回归差异清单，拆清明细重解析与一次性档案清理，并补充测试基线核验。当前待实施。

  • 2026-10-06 实施：用户授权做 #358；代码 a8233ec、文档 fb3efc9 已推送 fix/358-syb-size-weight。M2 对比完成，无新增测试失败。M3 生产数据纠正、main 合并及发布未执行，详见集中验证评论。

  • 2026-10-06 发布：用户另行授权合并 main、部署线上；main 合并 e76de6f，发布 /home/goauto/releases/20261006-e76de6f-358，服务重启 active，公网 SPA/静态资源/健康验证通过。无迁移；历史明细与反向档案值的定向清理未执行。发布文档提交 e2a68b3。

  • 2026-10-06 档案清理：用户明确授权继续在本单定向清理两项旧反向值。单独事务仅修改原报告档案的 specs_json 与 updated_at；删除 2 项无映射 import 值，保留其余全部维度元数据、规格和映射。颜色 10→9、尺码 6→5，数据库与 Admin 详情接口回读通过；恢复依据保存在服务器受限目录。未重跑 AI、未触发采购或同步、未扩大对象范围，工单保持待验收。

## 基本信息 - 类型：缺陷 - 所属 Epic / MVP：无；关联 #216（规格顺序识别）、#290（ERPGo 完整规格同步）、#301（规格键消歧）。 - 阶段：代码已发布；用户指定的 1 条历史 SYB 商品明细与对应蝦皮档案的 2 项错误反向值均已独立授权、定向纠正并回读验证，待用户验收。 ## 原始需求与基线 - 来源：用户对话，2026-10-06。用户报告一个 SYB 订单商品的颜色、尺码对换，在核对原因与最小方案后要求建工单。 - 核验代码基线：线上 release `20261006-0a79c83-356`，源码提交 `0a79c83a958c5d4edc3798c21e15402afa787af1`；本地 main `955b34ad810d8f9d54b60491b039d2804375c350`。 - 只读核验发现：同一订单三件商品中一件错误；订单原始规格按“尺码,颜色”排列，尺码为字母尺码和体重范围无空格连写。GoAuto 保存为相反维度，parse_status=success，非人工/AI 确认。ERPGo 当前接口返回正确颜色/尺码，无解析警告。 - ERPGo 正确规格已补入档案，但旧反向值仍保留，导致同一值出现在两个维度。未修改线上数据。 - 工单仅保留脱敏事实和合成样例，不保存真实订单号、商品数据、完整响应、凭据或原始日志。实施生产修复前由用户确认原报告对象与精确影响集合。 ## 依赖与并行 - 依赖现有 #216 / #290 / #301 实现；不依赖 ERPGo 新版本，不要求 Android/Web 配合。 - 不与涉及同一解析函数或同一档案的数据修复并行，避免规则漂移和覆盖。 - v2 纳入一次合并前的新旧解析只读回归对比：范围仅限线上全部去重 productSpec 及统计受影响明细/商品数量所需的最小关联信息；不作通用全库审计、不全量重解析、不写业务数据。 ## 子项目影响 - server：SYB 规格解析、共享规格键相关回归测试；已报告对象的定向数据纠正。 - shared-docs：业务规则与术语 Wiki 中补充支持的尺码形式。 - 不修改 Web/Android、ERPGo、共享 API、数据库结构、权限或任务状态机；不预设追加业务库迁移。 ## 根因与代码证据 1. `server/app/goauto/sybspec/parse.go` 的 explicitSizePattern 使用首尾完整匹配，能识别独立字母尺码或独立重量范围，却不能识别两者连写。 2. Parse 两侧都没有命中尺码证据时沿用“前颜色、后尺码”并记 success，导致反向输入被错误接受。 3. `server/app/goauto/sybimport/apply.go` 的 mergeParsedSpec 将错误值并入蝦皮商品档案。 4. `server/app/goauto/task/spec_sync.go` 与 `server/app/goauto/shopeeproduct/specs.go:Merge` 按维度增量补充、保留旧映射，不承担旧错误值删除或 SYB 明细重解析。 5. `server/app/goauto/sybimport/ai_parse_batch.go` 仅挑选 uncertain/failed；这条 success 明细不会进入异常 AI 解析。 ## 复现与目标契约（合成样例） - 输入：`XL65-70kg,123深藍`。 - 当前：颜色=XL65-70kg，尺码=123深藍，状态=success。 - 期望：颜色=123深藍，尺码=XL65-70kg，状态=success。 - 反向输入 `123深藍,XL65-70kg` 应得到同样结果。 - 保留尺码完整原文，不把重量说明丢弃，不擅自改成 XL。 - v2 明确包含带空格形式：`2XL 60.0-67.5公斤,黑色` 及反向输入均正确识别；独立输入 `2XL 60.0-67.5公斤` 应识别为仅尺码。这是有意纠正此前“仅颜色”的错误，必须单独测试。 ## 已确认最小方案 / 不做什么（v2，整合审核 M1～M3） ### M1：最小识别语法与共享路径 1. 明确包含“字母尺码＋可选空白＋数字体重/范围＋重量单位”，沿用现有字母尺码和重量单位集合，首尾完整匹配。例如 `(?:x{0,4}[sml]|[2-9]xl)\s*<体重或范围><单位>`；继续仅在一侧有明确尺码证据时决定角色，不用任意 XL/L 前缀匹配。 2. 优先只修改 explicitSizePattern 一处。RawSpecHalves 已复用 Parse 结果，ResolveKeys 基于两者，不新建第二套角色判断。 3. 合成回归覆盖正反顺序、空格/无空格、独立带空格尺码、已有纯字母尺码/体重/括号说明、单维度、数字前缀颜色、非尺码字母描述及双侧尺码的原有 uncertain/持久化失败语义。 4. 为 RawSpecHalves 和 ResolveKeys 增加独立反向样例及同商品多规格塌缩样例；不塌缩且未受本规则影响的键应与旧版逐字一致。 5. `XL(65-70kg)`、`XL/65-70kg`、异常单位后缀不顺手兼容；只读对比发现时分类报告，是否纳入另行确认。 ### M2：合并前只读回归差异清单 - 使用基线和候选版本实际 Go Parse 实现，对线上全部不重复 productSpec 做一次比较，不用另一语言重写解析器冒充行为对比。 - 只读最小规格字段，去重/数量关联在受限环境内处理；优先内存，不导出原始业务样本至仓库、工单、消息或日志。 - 分类统计：对调被纠正；success 变 uncertain（两侧均成为尺码）；单维度颜色变尺码；其他变化；另记未变化数量。统计涉及的唯一规格数、明细数、商品数，互斥分类避免重复计数。 - 工单仅记录汇总数量、合成样例、代码版本与核验时间。解释每类变化；未解释的变化或正常规格回归不得带入合并。 - 这是 v2 新纳入的实施前验证范围，不代表已执行，也不授权任何全量数据修复。 ### M3：历史修复路径与边界 - 明细：修复发布后，既有同步会重解析窗口内的明细；不得承诺所有人工/AI 确认数据都会被覆盖。窗口外已确认在范围内的明细，复用现有 ReparseBatch，先核对实际默认跳过/force 行为，保持 force=false，不绕过人工确认保护。额外 AI 确认变化须先报告，不盲目覆盖。 - 档案：现有 Merge 只补充，不会删反向旧值。本单包含的是一次性定向写入，不是新增通用自动清理功能，也不是数据库结构迁移。 - 默认候选范围仅为用户原报告的一件商品及两项错误维度值。实际写入前向用户私下列出精确商品、明细 ID、两个值及所在维度、预期变更数量，独立获得数据修复授权；工单只保存脱敏对象代号和结果，不写真实业务数据。 - 写入前校验：确为此次解析造成；不是人工维护条目；检查同商品其他明细引用、人工/AI 确认及映射；错误条目挂有已确认 PDD 映射、仍被其他明细依赖或校验与预览不一致时，停止并报告，不能自动删除或扩围。 - 明细修复复用服务已有事务；档案清理在单独事务中执行，重新校验当前数据/版本，防止覆盖并发修改，重复执行应安全无变更。不能把两阶段描述为已具备跨 API 的单一原子事务。 - 执行前按现有运维规范在受限位置留存必要恢复依据；保留 raw_json、正确维度值与有效映射，不改既有采购任务快照，不创建/执行采购，不付款。 - M2 若发现其他商品污染：报告数量和是否需要纠正档案；是否扩大明细重解析或档案清理由用户决定，不静默扩大，也不能在未处理时宣称全部修复完成。 不做：修改 ERPGo/Web/Android、改变通用 Merge 语义、每次同步全量覆盖、额外 AI、全局跨角色删除、定时任务成功数据重扫。AI 匹配不能代替源规格纠正。 预计涉及：`server/app/goauto/sybspec/parse.go` 及测试，必要的 sybimport 回归测试；优先使用现有 ReparseBatch。若需新增接口、迁移或通用工具，须重新确认范围。 ## 设计与原型门禁 - 类型：非 UI、恢复既有正确角色识别的缺陷；无需 UI 原型，不改页面布局。 - v2 流程：最小尺码语法及回归测试 → 新旧 Parse 只读差异核验 → 现有共享键/导入路径 → 单独授权后的定向历史纠正。 - 2026-10-06：用户要求整合 Claude 审核评论 8836（SynapBus #49/#50），本正文为 v2。包括 M1 带空格语法、M2 只读全量去重规格对比及 M3 修复边界；实施、线上写入和发布仍另行授权。 - 未要求 HTML 导出或任务快照。 ## 验收标准 - [x] 连写/带空格尺码与颜色交换顺序均正确，尺码完整原文不丢失；独立带空格尺码识别为仅尺码。 - [x] 合并前完成新旧 Parse 只读差异清单，按类别汇总规格/明细/商品数量，所有变化有解释，无未解释回归。 - [x] RawSpecHalves/ResolveKeys 对调和塌缩样例通过，未受影响键保持稳定。 - [x] 正常颜色在前/尺码在后、单维度、括号清理和键消歧行为无回归。 - [x] 数字前缀颜色、非尺码字母描述不被误判；双侧尺码不被任意指定颜色。 - [x] 修正后的明细与蝦皮档案角色一致，错误反向条目不再污染该对象匹配；正确映射保留。 - [ ] ERPGo 重同步或同一 SYB 明细再次同步不会重新注入本次错误；无需改 ERPGo 或扩大 AI 定时扫描范围。 - [x] 定向数据修复有独立授权、精确范围、写入前校验、事务、幂等性及恢复依据；人工确认、正确映射、无关数据和采购快照不受影响。范围外污染明确列为待用户决定，不默认扩围。 - [x] 代码测试、实际执行与未验证项、提交哈希集中回写，工单待用户验收，不自行关闭。 ## 验证方式 - 在 server 目录执行：`go test ./app/goauto/sybspec ./app/goauto/sybimport ./app/goauto/shopeeproduct ./app/goauto/shopeespec`。 - 先核验测试基线，再运行受影响规格同步/采购键定向测试；不用真实下单验证解析。 - Claude 报告 main 的 sybimport 包原有 12 个失败，此为历史审核信息，实施时须在相同环境重现并记录具体失败列表，再与修改后对照。不能未经复核认定所有失败都是存量，也不能要求修复无关旧失败；本次新增用例和受影响回归必须通过。 - 合并前执行 M2 只读差异核验，记录新旧提交及汇总结果；不会因为允许读取就执行线上写入。 - 线上数据纠正前后只读比对角色、映射及受影响数量；回写工单仅记录脱敏结果，不上传业务数据。 - 建单时仅完成只读根因核验；截至本次更新已完成代码验证、发布和授权定向数据纠正，详见实施、发布与修复评论。线上主动重同步验收尚未执行，不以接口回读代替该验收。 ## 风险与回退 - 过宽的尺码表达式可能误伤商品描述，必须限制为明确尺码＋体重格式。 - 代码回退可恢复旧版本，但不能自动恢复已修复数据；生产写入前须按现有运维规范在受限位置留存必要恢复依据，不进入仓库/工单。 - 生产数据变更、迁移（如后续确需）及发布必须分别具备明确授权；本次工单方案更新不构成代码实施或上述高风险动作授权。 ## 文档影响与任务记录 - 更新业务规则与术语 Wiki：补充明确连写尺码识别范围及保留原文规则；长期事实变化后在线更新/回读，执行一次 sync 与 sync --check。 - API、数据库结构、部署方式无变化，不新增对应契约或部署文档。 - Gitea 为任务唯一事实来源；不创建任务快照，不导出生产样本。 - Gitea 交互说明：当前工具清单未提供 Gitea MCP，故回退已配置 Gitea REST API；凭据仅从本机私有配置读取，不输出。 ## 需求变化记录 - 2026-10-06 v1：建单，最小识别修复及已报告对象定向纠正。 - 2026-10-06 v2：按用户要求将评论 8836 整合进正文；明确接受带空格写法、新增合并前只读回归差异清单，拆清明细重解析与一次性档案清理，并补充测试基线核验。当前待实施。 - 2026-10-06 实施：用户授权做 #358；代码 a8233ec、文档 fb3efc9 已推送 fix/358-syb-size-weight。M2 对比完成，无新增测试失败。M3 生产数据纠正、main 合并及发布未执行，详见集中验证评论。 - 2026-10-06 发布：用户另行授权合并 main、部署线上；main 合并 e76de6f，发布 /home/goauto/releases/20261006-e76de6f-358，服务重启 active，公网 SPA/静态资源/健康验证通过。无迁移；历史明细与反向档案值的定向清理未执行。发布文档提交 e2a68b3。 - 2026-10-06 档案清理：用户明确授权继续在本单定向清理两项旧反向值。单独事务仅修改原报告档案的 specs_json 与 updated_at；删除 2 项无映射 import 值，保留其余全部维度元数据、规格和映射。颜色 10→9、尺码 6→5，数据库与 Admin 详情接口回读通过；恢复依据保存在服务器受限目录。未重跑 AI、未触发采购或同步、未扩大对象范围，工单保持待验收。
ila commented 2026-10-06 11:07:12 +08:00
Author
Owner
Copy Link
Copy Source

方案审核意见（2026-10-06，Claude Code，基于 main 955b34a）

审核由用户授权，经 SynapBus #goauto（消息 #47）发起；只做审核，未改代码或数据。按用户要求以评论形式补充，不改工单正文。

结论：根因成立，最小方案方向正确，可以实施；以下 M1～M3 须先补入方案。

已核实的事实

  • explicitSizePattern 为整段匹配（server/app/goauto/sybspec/parse.go:26），XL65-70kg 匹配不上；逗号两侧均未命中尺码时，按「前颜色、后尺码」处理并记 success（parse.go:145-152）。根因属实。
  • 共享路径一致：RawSpecHalves 判断角色时直接比对 Parse 的结果（sybspec/raw_spec.go:45），ResolveKeys 又建立在 Parse 和 RawSpecHalves 之上（sybspec/resolve_keys.go:22-44）。只改 explicitSizePattern 一处，三条路径自动保持一致，不需要另写角色判断。
  • 再次同步会自愈明细：ApplyDetail 对已存在的行会重新 Parse，并覆盖非人工确认行的 target_color/target_size（sybimport/apply.go:185-196）；mergeParsedSpec 只追加正确值。因此修复上线后，同步窗口内的同格式错误明细会自动纠正，但商品档案中的反向旧值不会被清除。
  • 不需要修改 ERPGo、Web、Android、通用 Merge 语义，也不需要新增数据库结构（M3 的一次性档案写入不涉及表结构）。

必须补齐

M1. 带空格的写法
parse.go 的注释里就出现过 2XL 60.0-67.5公斤。它在逗号分支同样整段匹配不上，2XL 60.0-67.5公斤,黑色 也会被对调。语法须明确二选一：

  • 包含：(?:x{0,4}[sml]|[2-9]xl)\s*<体重或范围><单位>；
  • 排除：并用测试固定当前行为。

如果选择包含，无逗号分支的整串 2XL 60.0-67.5公斤 会从「仅识别到颜色」变为「仅识别到尺码」，需在测试中覆盖并说明。

M2. 回归差异清单（只读）
合并前，用新旧两版 Parse 跑一遍线上所有不重复的 productSpec：只读规格字符串，在受限位置处理，不导出业务数据。按类别统计结果变化：

  • 对调被纠正；
  • success 变为 uncertain（新规则使两侧都像尺码）；
  • 其他变化。

工单只记录数量和合成样例。这份清单既能验证规则足够窄、不误伤正常颜色或描述，也能量化同格式污染涉及多少明细和商品。

M3. 写清修复路径与范围

  • 明细：同步窗口外的行复用现有 ReparseBatch（sybimport/reparse.go:137，默认跳过人工确认），不需要新工具。
  • 档案反向旧值：Merge 只追加，现有能力无法清除，所以这是新增的一次性定向写入。须写明：
    • 精确对象：哪个商品、哪两个值、各在哪个维度；
    • 前置校验：没有其他明细引用这两个值；如果有已确认的 PDD 映射挂在上面，如何处理（建议停止并报告）；
    • 在事务中执行，执行前在受限位置留存恢复依据；
    • 单独授权。
  • 范围决定：如果 M2 显示其他商品也被污染，它们的明细会随同步或重新解析自愈，但档案反向值会一直保留。是否扩大档案清理须由用户决定，不能默认只修已报告的对象。

建议（不阻塞）

  • 括号或斜杠写法（如 XL(65-70kg)、XL/65-70kg）只在 M2 实际出现时才另行决定，不顺手扩展。
  • 为 RawSpecHalves 和 ResolveKeys 单独写对调样例的测试；再加一个「同商品多规格且会塌缩」的样例，确认键稳定、不塌缩的键与修改前逐字一致。
  • 验证命令中的 go test ./app/goauto/sybimport 在 main 上原有 12 个失败（#353 审核时核对过）。验收时应按失败列表对比基线，确认没有新增失败，而不是期望全部通过。
## 方案审核意见（2026-10-06，Claude Code，基于 main `955b34a`） 审核由用户授权，经 SynapBus #goauto（消息 #47）发起；只做审核，未改代码或数据。按用户要求以评论形式补充，不改工单正文。 **结论：根因成立，最小方案方向正确，可以实施；以下 M1～M3 须先补入方案。** ### 已核实的事实 - `explicitSizePattern` 为整段匹配（`server/app/goauto/sybspec/parse.go:26`），`XL65-70kg` 匹配不上；逗号两侧均未命中尺码时，按「前颜色、后尺码」处理并记 success（`parse.go:145-152`）。根因属实。 - **共享路径一致**：`RawSpecHalves` 判断角色时直接比对 `Parse` 的结果（`sybspec/raw_spec.go:45`），`ResolveKeys` 又建立在 `Parse` 和 `RawSpecHalves` 之上（`sybspec/resolve_keys.go:22-44`）。只改 `explicitSizePattern` 一处，三条路径自动保持一致，不需要另写角色判断。 - **再次同步会自愈明细**：`ApplyDetail` 对已存在的行会重新 `Parse`，并覆盖非人工确认行的 `target_color`/`target_size`（`sybimport/apply.go:185-196`）；`mergeParsedSpec` 只追加正确值。因此修复上线后，同步窗口内的同格式错误明细会自动纠正，但商品档案中的反向旧值不会被清除。 - 不需要修改 ERPGo、Web、Android、通用 Merge 语义，也不需要新增数据库结构（M3 的一次性档案写入不涉及表结构）。 ### 必须补齐 **M1. 带空格的写法** `parse.go` 的注释里就出现过 `2XL 60.0-67.5公斤`。它在逗号分支同样整段匹配不上，`2XL 60.0-67.5公斤,黑色` 也会被对调。语法须明确二选一： - 包含：`(?:x{0,4}[sml]|[2-9]xl)\s*<体重或范围><单位>`； - 排除：并用测试固定当前行为。 如果选择包含，无逗号分支的整串 `2XL 60.0-67.5公斤` 会从「仅识别到颜色」变为「仅识别到尺码」，需在测试中覆盖并说明。 **M2. 回归差异清单（只读）** 合并前，用新旧两版 `Parse` 跑一遍线上所有不重复的 `productSpec`：只读规格字符串，在受限位置处理，不导出业务数据。按类别统计结果变化： - 对调被纠正； - success 变为 uncertain（新规则使两侧都像尺码）； - 其他变化。 工单只记录数量和合成样例。这份清单既能验证规则足够窄、不误伤正常颜色或描述，也能量化同格式污染涉及多少明细和商品。 **M3. 写清修复路径与范围** - **明细**：同步窗口外的行复用现有 `ReparseBatch`（`sybimport/reparse.go:137`，默认跳过人工确认），不需要新工具。 - **档案反向旧值**：Merge 只追加，现有能力无法清除，所以这是新增的一次性定向写入。须写明： - 精确对象：哪个商品、哪两个值、各在哪个维度； - 前置校验：没有其他明细引用这两个值；如果有已确认的 PDD 映射挂在上面，如何处理（建议停止并报告）； - 在事务中执行，执行前在受限位置留存恢复依据； - 单独授权。 - **范围决定**：如果 M2 显示其他商品也被污染，它们的明细会随同步或重新解析自愈，但档案反向值会一直保留。是否扩大档案清理须由用户决定，不能默认只修已报告的对象。 ### 建议（不阻塞） - 括号或斜杠写法（如 `XL(65-70kg)`、`XL/65-70kg`）只在 M2 实际出现时才另行决定，不顺手扩展。 - 为 `RawSpecHalves` 和 `ResolveKeys` 单独写对调样例的测试；再加一个「同商品多规格且会塌缩」的样例，确认键稳定、不塌缩的键与修改前逐字一致。 - 验证命令中的 `go test ./app/goauto/sybimport` 在 main 上原有 12 个失败（#353 审核时核对过）。验收时应按失败列表对比基线，确认没有新增失败，而不是期望全部通过。
ila commented 2026-10-06 11:19:33 +08:00
Author
Owner
Copy Link
Copy Source

#358 v2 实施与验证结果（2026-10-06）

已完成 / 状态边界

  • 实现提交 a8233ec：仅修改 shared sybspec 的 explicitSizePattern，新增 sybspec/sybimport 合成测试；RawSpecHalves、ResolveKeys、ERPGo、Merge、Web/Android 不改业务实现。
  • 文档提交 fb3efc9；已推送 fix/358-syb-size-weight，工作区干净。
  • 本轮授权内的代码、测试、只读差异、文档和提交推送已完成，代码待验收。
  • 未合并 main、未发布/重启、未迁移、未执行生产 ReparseBatch 或档案清理；线上原问题尚未被本次分支修复。工单保持开放。

M1 与回归

  • 包含无空格及带空格的字母尺码＋体重/范围＋单位，完整保存尺码描述。
  • 新增 5 个顶层测试函数（含子用例共 25 个 pass 事件），覆盖角色正反、单维度、描述误判边界、双侧尺码、RawSpecHalves、ResolveKeys、塌缩键及导入/重解析。
  • SQLite 合成集成验证：新导入角色正确；重同步/重解析纠正旧反向明细；force=false 跳过人工和 AI 确认；正确映射及 raw_json 保留；重复重解析幂等。旧档案反向值仍保留，证明需要单独授权清理，不能声称 Merge 会自愈。

M2 线上只读差异清单

  • 同一只读一致性快照，去重规格经 stdin 传入由旧/新实际 Go Parse 构建的探针，结果仅在内存中比较，没有生产样本落盘或上传工单。旧基线 955b34a；新解析源码与 a8233ec 完全一致。
  • 覆盖 10,869 个不重复规格、23,959 条明细。
  • 对调纠正：1 个规格 / 1 条明细 / 1 件商品。
  • 不变：10,868 个规格 / 23,958 条明细 / 7,146 件商品（分类商品数各自去重，不将其相加当全局唯一数）。
  • success→uncertain、单维度颜色→尺码、其他变化均为 0；非字符串遗漏 0。
  • 合成变化样例：XL65-70kg,123深藍 从前颜色后尺码纠正为颜色 123深藍、尺码 XL65-70kg。线上样本没有出现额外变化类别，无需扩大清理范围。

测试结果与存量限制

  • go test ./app/goauto/sybspec ./app/goauto/sybimport -run SizeWeight358 -count=1：通过。
  • go test -json ./app/goauto/sybspec ./app/goauto/sybimport ./app/goauto/shopeeproduct ./app/goauto/shopeespec：sybspec/shopeeproduct/shopeespec 通过；sybimport 仍有 12 个基线既有失败，新旧失败名称集合完全相同，没有新增失败，不能标记整包全绿。
  • go test ./app/goauto/task ./app/goauto/purchase -run 'Test(IncomingDimensions|IncomingDeduplicates|SpecSynced|BatchPreviewRefusesCollapsed)' -count=1：通过。
  • git diff --check：通过。
  • harness.py check --strict：基线 main 与本分支均同样失败，原因是已有 docs/evidence/pdd-home-35727-summary.md 为未登记 Wiki 镜像；本单未修改该文件/规则，不顺手修复。

M3 执行前须知 / 未执行项

  • 已核对 ReparseBatch(force=false) 会跳过人工和 AI 确认。其内部 resyncShopeeProductKeys 可能重算同商品兄弟明细，因此生产授权前应确认同商品完整影响集合，不把请求一个 ID 误写成绝对只影响一行。
  • 已报告对象的明细重解析及两项错误维度值清理仍待独立授权；执行前重新预览实际对象、引用、已确认映射与版本，留存受限恢复依据。
  • 无需表结构迁移；不修改或执行采购任务，不执行付款。若现场已被人工修改/映射变化，停止清理并报告，不沿用过期预览。

文档闭环

  • Wiki Business-Rules-and-Glossary 已在线更新并回读 revision e0ac4bb20494a2659b8b6a4f8598884b56a94fa3，明确分支实现、未发布及历史纠正边界。
  • 一次 harness.py sync 和一次 sync --check 完成，17 个核心镜像一致。
  • 不创建任务快照；无新接口、数据库结构或部署方式变化。
  • 当前无 Gitea MCP，继续按已记录回退方式使用 REST API，凭据未写入仓库或工单。

同环境复核的 12 项存量失败

  • TestRepairReversedSpecRolesKeepsAmbiguousColorUncertain
  • TestScheduledAIParseConfirmsClosedCandidatesAndDoesNotRepeat
  • TestScheduledAIParseLeavesLowConfidenceUnmatchedForSameFingerprint
  • TestScheduledAIParseRetriesProviderFailureAtMostThreeTimes
  • TestApplyDetailOnlyMergesSuccessfullyParsedSpecIntoArchive
  • TestParseRealSample_AmbiguousColorWithAnnotationAndSeparator
  • TestParseNoSeparatorIsUncertainNotFailed
  • TestParseBothSidesEmptyAfterStrippingIsUncertain
  • TestReparseUpdatesStatusWhenRuleImproves
  • TestManualCorrectMergesIntoArchiveLikeASuccessfulParse
  • TestReimportPreservesIdenticalAIInputAndInvalidatesChangedSource
  • TestServiceListFiltersByOrderCodesShopAndParseStatus
## #358 v2 实施与验证结果（2026-10-06） ### 已完成 / 状态边界 - 实现提交 `a8233ec`：仅修改 shared sybspec 的 explicitSizePattern，新增 sybspec/sybimport 合成测试；RawSpecHalves、ResolveKeys、ERPGo、Merge、Web/Android 不改业务实现。 - 文档提交 `fb3efc9`；已推送 `fix/358-syb-size-weight`，工作区干净。 - 本轮授权内的代码、测试、只读差异、文档和提交推送已完成，代码待验收。 - **未合并 main、未发布/重启、未迁移、未执行生产 ReparseBatch 或档案清理；线上原问题尚未被本次分支修复。工单保持开放。** ### M1 与回归 - 包含无空格及带空格的字母尺码＋体重/范围＋单位，完整保存尺码描述。 - 新增 5 个顶层测试函数（含子用例共 25 个 pass 事件），覆盖角色正反、单维度、描述误判边界、双侧尺码、RawSpecHalves、ResolveKeys、塌缩键及导入/重解析。 - SQLite 合成集成验证：新导入角色正确；重同步/重解析纠正旧反向明细；force=false 跳过人工和 AI 确认；正确映射及 raw_json 保留；重复重解析幂等。旧档案反向值仍保留，证明需要单独授权清理，不能声称 Merge 会自愈。 ### M2 线上只读差异清单 - 同一只读一致性快照，去重规格经 stdin 传入由旧/新实际 Go Parse 构建的探针，结果仅在内存中比较，没有生产样本落盘或上传工单。旧基线 `955b34a`；新解析源码与 `a8233ec` 完全一致。 - 覆盖 10,869 个不重复规格、23,959 条明细。 - 对调纠正：1 个规格 / 1 条明细 / 1 件商品。 - 不变：10,868 个规格 / 23,958 条明细 / 7,146 件商品（分类商品数各自去重，不将其相加当全局唯一数）。 - success→uncertain、单维度颜色→尺码、其他变化均为 0；非字符串遗漏 0。 - 合成变化样例：`XL65-70kg,123深藍` 从前颜色后尺码纠正为颜色 `123深藍`、尺码 `XL65-70kg`。线上样本没有出现额外变化类别，无需扩大清理范围。 ### 测试结果与存量限制 - `go test ./app/goauto/sybspec ./app/goauto/sybimport -run SizeWeight358 -count=1`：通过。 - `go test -json ./app/goauto/sybspec ./app/goauto/sybimport ./app/goauto/shopeeproduct ./app/goauto/shopeespec`：sybspec/shopeeproduct/shopeespec 通过；sybimport 仍有 12 个基线既有失败，新旧失败名称集合完全相同，没有新增失败，不能标记整包全绿。 - `go test ./app/goauto/task ./app/goauto/purchase -run 'Test(IncomingDimensions|IncomingDeduplicates|SpecSynced|BatchPreviewRefusesCollapsed)' -count=1`：通过。 - `git diff --check`：通过。 - `harness.py check --strict`：基线 main 与本分支均同样失败，原因是已有 `docs/evidence/pdd-home-35727-summary.md` 为未登记 Wiki 镜像；本单未修改该文件/规则，不顺手修复。 ### M3 执行前须知 / 未执行项 - 已核对 ReparseBatch(force=false) 会跳过人工和 AI 确认。其内部 resyncShopeeProductKeys 可能重算同商品兄弟明细，因此生产授权前应确认同商品完整影响集合，不把请求一个 ID 误写成绝对只影响一行。 - 已报告对象的明细重解析及两项错误维度值清理仍待独立授权；执行前重新预览实际对象、引用、已确认映射与版本，留存受限恢复依据。 - 无需表结构迁移；不修改或执行采购任务，不执行付款。若现场已被人工修改/映射变化，停止清理并报告，不沿用过期预览。 ### 文档闭环 - Wiki `Business-Rules-and-Glossary` 已在线更新并回读 revision `e0ac4bb20494a2659b8b6a4f8598884b56a94fa3`，明确分支实现、未发布及历史纠正边界。 - 一次 `harness.py sync` 和一次 `sync --check` 完成，17 个核心镜像一致。 - 不创建任务快照；无新接口、数据库结构或部署方式变化。 - 当前无 Gitea MCP，继续按已记录回退方式使用 REST API，凭据未写入仓库或工单。 ### 同环境复核的 12 项存量失败 - `TestRepairReversedSpecRolesKeepsAmbiguousColorUncertain` - `TestScheduledAIParseConfirmsClosedCandidatesAndDoesNotRepeat` - `TestScheduledAIParseLeavesLowConfidenceUnmatchedForSameFingerprint` - `TestScheduledAIParseRetriesProviderFailureAtMostThreeTimes` - `TestApplyDetailOnlyMergesSuccessfullyParsedSpecIntoArchive` - `TestParseRealSample_AmbiguousColorWithAnnotationAndSeparator` - `TestParseNoSeparatorIsUncertainNotFailed` - `TestParseBothSidesEmptyAfterStrippingIsUncertain` - `TestReparseUpdatesStatusWhenRuleImproves` - `TestManualCorrectMergesIntoArchiveLikeASuccessfulParse` - `TestReimportPreservesIdenticalAIInputAndInvalidatesChangedSource` - `TestServiceListFiltersByOrderCodesShopAndParseStatus`
ila commented 2026-10-06 11:29:15 +08:00
Author
Owner
Copy Link
Copy Source

授权合并与线上发布完成（2026-10-06）

  • 用户本轮授权：合并 main、部署线上；不包含历史规格数据定向写入。
  • 合并提交 e76de6fc08f8b8f0a4bec6a51eb9193451aa784e 已推送 main，发布文档提交 e2a68b3 已推送。
  • 线上目录 /home/goauto/releases/20261006-e76de6f-358，GoAuto 重启 active；旧目录 /home/goauto/releases/20261006-0a79c83-356 保留用于代码回滚。
  • Server Linux amd64（CGO_ENABLED=0）重新构建，SHA256 a4cf6c7028a2bbbfd86a1d657ad9c3daad7b4d08445405d8ca9a778adc584760，上传后及发布后均核对一致。Web 与旧线上源码无差异，沿用已验证 dist，全目录比较一致；无 APK 构建或安装。
  • 合并后新增 SizeWeight358 解析/导入/重解析测试及 task/purchase 规格同步/塌缩键定向测试通过。此前全包基线 12 项存量失败见评论 8839，本次不宣称全部测试全绿。
  • 首次检查发现执行中采购，未强制重启；待其离开运行态后，全部运行状态检查为空才切换 current。未取消、重置或修改该任务，未停止接单或更改定时任务状态。
  • 待执行迁移为空，未执行 migrate、生产 ReparseBatch、档案清理、采购、支付、人工触发同步/回填；原定时任务开关保持不变。
  • Nginx 配置检查通过，配置未修改，不需 reload。复用既有 config/环境文件及 static/temp/var 真实目录，不删除历史图片/APK/资源。
  • 公网 /、/index.html、/syb-products/index 与本次发布 SPA index 字节一致；10 项 JS/CSS 及健康接口正常，非 go-admin 默认欢迎页。发布后日志 panic/fatal/1054/1146 均为 0。
  • 期间两次 SSH 新连接 banner 失败发生于认证/执行前，重试后成功；上传完成且哈希核验通过，未发生未确认切换或重复重启。
  • Wiki Business-Rules-and-Glossary revision f5077a19801882ebb4e94c5b0fe93f00fa6ebc7d，Deployment-and-Operations revision 8be38ac192b9e1930fdc3d998c23027fda17e8f3；均在线回读，一次 sync 与一次 sync --check 完成，17 页一致。main 工作区干净。

状态：代码已发布、待验收；历史错误明细和两项反向档案值尚未执行定向纠正，仍须独立授权。新规则对后续正常导入/重同步生效，不等于历史档案已被清理。工单不关闭。

## 授权合并与线上发布完成（2026-10-06） - 用户本轮授权：合并 main、部署线上；不包含历史规格数据定向写入。 - 合并提交 `e76de6fc08f8b8f0a4bec6a51eb9193451aa784e` 已推送 main，发布文档提交 `e2a68b3` 已推送。 - 线上目录 `/home/goauto/releases/20261006-e76de6f-358`，GoAuto 重启 active；旧目录 `/home/goauto/releases/20261006-0a79c83-356` 保留用于代码回滚。 - Server Linux amd64（CGO_ENABLED=0）重新构建，SHA256 `a4cf6c7028a2bbbfd86a1d657ad9c3daad7b4d08445405d8ca9a778adc584760`，上传后及发布后均核对一致。Web 与旧线上源码无差异，沿用已验证 dist，全目录比较一致；无 APK 构建或安装。 - 合并后新增 SizeWeight358 解析/导入/重解析测试及 task/purchase 规格同步/塌缩键定向测试通过。此前全包基线 12 项存量失败见评论 8839，本次不宣称全部测试全绿。 - 首次检查发现执行中采购，未强制重启；待其离开运行态后，全部运行状态检查为空才切换 current。未取消、重置或修改该任务，未停止接单或更改定时任务状态。 - 待执行迁移为空，未执行 migrate、生产 ReparseBatch、档案清理、采购、支付、人工触发同步/回填；原定时任务开关保持不变。 - Nginx 配置检查通过，配置未修改，不需 reload。复用既有 config/环境文件及 static/temp/var 真实目录，不删除历史图片/APK/资源。 - 公网 `/`、`/index.html`、`/syb-products/index` 与本次发布 SPA index 字节一致；10 项 JS/CSS 及健康接口正常，非 go-admin 默认欢迎页。发布后日志 panic/fatal/1054/1146 均为 0。 - 期间两次 SSH 新连接 banner 失败发生于认证/执行前，重试后成功；上传完成且哈希核验通过，未发生未确认切换或重复重启。 - Wiki Business-Rules-and-Glossary revision `f5077a19801882ebb4e94c5b0fe93f00fa6ebc7d`，Deployment-and-Operations revision `8be38ac192b9e1930fdc3d998c23027fda17e8f3`；均在线回读，一次 sync 与一次 sync --check 完成，17 页一致。main 工作区干净。 状态：代码已发布、待验收；历史错误明细和两项反向档案值尚未执行定向纠正，仍须独立授权。新规则对后续正常导入/重同步生效，不等于历史档案已被清理。工单不关闭。
ila commented 2026-10-06 11:36:40 +08:00
Author
Owner
Copy Link
Copy Source

指定历史明细纠正完成（2026-10-06）

  • 用户本轮明确授权仅纠正原报告的 1 条线上 SYB 商品明细；没有授权清理蝦皮档案值。
  • 写入前核对目标唯一、无人工/AI 确认，同商品明细总数为 1；运行 release 为已发布 #358。
  • 通过现有单条重新解析接口，force=false，仅调用一次写请求；HTTP 200 / 业务码 200，outcome=reparsed，状态 success→success。
  • 数据库及 Admin 详情接口回读：颜色/尺码角色已正确；原 raw_json 摘要未变，蝦皮商品 specs_json 按 JSON 内容比较完全未变。没有清除两项反向档案值，没有修改/创建采购任务，也没有触发 SYB 同步或付款。
  • 修改前必要恢复依据留存在服务器 /home/goauto/backups/20261006-358-detail/before.json，目录0700、文件0600，不下载或复制到工单/仓库。
  • 两次 SSH banner 失败均发生在认证及任何写入前，连接成功后只执行一次接口请求；未盲目重放已提交的请求。
  • 无源码、契约或长期业务规则变化，本次仅为已授权数据操作结果，不重复 Wiki 更新或同步。

剩余：两项旧反向档案值未清理，保留待独立授权；不以明细纠正代表整个档案已清理。工单保持开放。

## 指定历史明细纠正完成（2026-10-06） - 用户本轮明确授权仅纠正原报告的 1 条线上 SYB 商品明细；没有授权清理蝦皮档案值。 - 写入前核对目标唯一、无人工/AI 确认，同商品明细总数为 1；运行 release 为已发布 #358。 - 通过现有单条重新解析接口，force=false，仅调用一次写请求；HTTP 200 / 业务码 200，outcome=reparsed，状态 success→success。 - 数据库及 Admin 详情接口回读：颜色/尺码角色已正确；原 raw_json 摘要未变，蝦皮商品 specs_json 按 JSON 内容比较完全未变。没有清除两项反向档案值，没有修改/创建采购任务，也没有触发 SYB 同步或付款。 - 修改前必要恢复依据留存在服务器 `/home/goauto/backups/20261006-358-detail/before.json`，目录0700、文件0600，不下载或复制到工单/仓库。 - 两次 SSH banner 失败均发生在认证及任何写入前，连接成功后只执行一次接口请求；未盲目重放已提交的请求。 - 无源码、契约或长期业务规则变化，本次仅为已授权数据操作结果，不重复 Wiki 更新或同步。 剩余：两项旧反向档案值未清理，保留待独立授权；不以明细纠正代表整个档案已清理。工单保持开放。
ila commented 2026-10-06 11:52:33 +08:00
Author
Owner
Copy Link
Copy Source

授权定向档案清理完成（2026-10-06，待验收）

  • 授权来源：用户本轮明确要求在 #358 清理原报告对象的两项错误反向值，并保留其他正常颜色、尺码与正确映射。本次未扩大范围。
  • 前置核验：两个条目均为 import、无映射；同商品 SYB 明细对错误角色值的引用为 0；无该商品自动匹配工作项。正确维度的对应值各存在一项。此前已修复的 SYB 明细维持正确角色及 success。
  • 执行：锁定精确档案与关联明细，在独立数据库事务内重核；先备份，再按主键、商品身份、旧 updated_at 和旧 JSON 的精确条件更新。实际只改变 1 个档案的 specs_json 与 updated_at，删除 2 项；无其他业务字段、明细或采购任务写入。清理逻辑对“两项均不存在”只读退出，部分存在或预期不符则停止。
  • 恢复依据：服务器 /home/goauto/backups/20261006-358-archive/before.json，目录 0700、文件 0600，写入前已校验内容及权限；不覆盖上一阶段明细备份，不将业务内容导出到工单或仓库。恢复也须按当前版本校验后独立授权执行，不能盲目覆盖后续变化。
  • 验证：提交前、提交后 JSON 与预期一致；其余规格值及映射逐项完全一致、维度元数据不变、其余档案字段与关联明细不变。颜色由 10 项变为 9 项，尺码由 6 项变为 5 项。线上 Admin 商品详情 API 返回 HTTP/code 200，错误角色条目不存在，正确对应值保留。
  • 连接异常：首次 SSH 在认证前 banner 阶段断开，未连接业务库、未执行写入；重连后成功执行一次事务。没有在提交状态不明时盲目重试。
  • 未执行：再次线上 SYB/ERPGo 同步、AI 匹配、采购或付款；“重同步不重新注入”的线上验收仍未勾选。本次没有代码修改、迁移或发布，不新增提交。
  • 文档影响：一次性已设计的数据修复，不改变长期业务规则/API/部署方式；此前本单 Wiki 闭环已完成，本次不重复同步。
  • Gitea：当前无 Gitea MCP，沿用已记录的 REST API 回退。工单仍为 open / 待用户验收。
## 授权定向档案清理完成（2026-10-06，待验收） - 授权来源：用户本轮明确要求在 #358 清理原报告对象的两项错误反向值，并保留其他正常颜色、尺码与正确映射。本次未扩大范围。 - 前置核验：两个条目均为 import、无映射；同商品 SYB 明细对错误角色值的引用为 0；无该商品自动匹配工作项。正确维度的对应值各存在一项。此前已修复的 SYB 明细维持正确角色及 success。 - 执行：锁定精确档案与关联明细，在独立数据库事务内重核；先备份，再按主键、商品身份、旧 updated_at 和旧 JSON 的精确条件更新。实际只改变 1 个档案的 specs_json 与 updated_at，删除 2 项；无其他业务字段、明细或采购任务写入。清理逻辑对“两项均不存在”只读退出，部分存在或预期不符则停止。 - 恢复依据：服务器 /home/goauto/backups/20261006-358-archive/before.json，目录 0700、文件 0600，写入前已校验内容及权限；不覆盖上一阶段明细备份，不将业务内容导出到工单或仓库。恢复也须按当前版本校验后独立授权执行，不能盲目覆盖后续变化。 - 验证：提交前、提交后 JSON 与预期一致；其余规格值及映射逐项完全一致、维度元数据不变、其余档案字段与关联明细不变。颜色由 10 项变为 9 项，尺码由 6 项变为 5 项。线上 Admin 商品详情 API 返回 HTTP/code 200，错误角色条目不存在，正确对应值保留。 - 连接异常：首次 SSH 在认证前 banner 阶段断开，未连接业务库、未执行写入；重连后成功执行一次事务。没有在提交状态不明时盲目重试。 - 未执行：再次线上 SYB/ERPGo 同步、AI 匹配、采购或付款；“重同步不重新注入”的线上验收仍未勾选。本次没有代码修改、迁移或发布，不新增提交。 - 文档影响：一次性已设计的数据修复，不改变长期业务规则/API/部署方式；此前本单 Wiki 闭环已完成，本次不重复同步。 - Gitea：当前无 Gitea MCP，沿用已记录的 REST API 回退。工单仍为 open / 待用户验收。
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/goauto#358