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

fix(server): 统一衣服尺码推荐体重说明的规格键，避免 SYB/ERPGo 导入重复尺码 #360

New Issue
Open
opened 2026-10-06 15:37:38 +08:00 by ila · 3 comments
ila commented 2026-10-06 15:37:38 +08:00
Owner
Copy Link
Copy Source

2026-10-07 最新进展：用户另行授权按 ERPGo 最新尺码刷新两件报告商品的档案，已完成服务器受限备份、单事务定向更新和数据库/Admin详情回读；尺码分别13→7、8→6。仅尺码列表及更新时间变化，保留同名映射、颜色和其他数据，后续由用户手动匹配。历史 SYB 目标键不在本轮修复范围，仍可能与最新档案不一致；正式 #360 代码尚未实施。详见评论 8903、8904；下文“未生产写入”描述为10月6日那轮统计的历史边界。

基本信息

  • 类型：缺陷；所属 Epic / MVP：无。
  • 关联：#290（ERPGo 完整规格同步）、#301（规格键消歧）、#358（连写尺码角色识别）。
  • 阶段：v2保护方案、只读影响统计及本地候选模型验证已完成；正式修复仍待实施，真实SKU冲突的商品级判定必须先落定。不执行生产写入、真实同步/匹配/采购，不迁移或发布。

原始需求与核验基线

  • 来源：用户对话，2026-10-06。用户报告某 SYB 订单对应蝦皮商品的尺码重复，核验后确认按“仅统一明确衣服尺码的推荐体重说明、保留真实规格差异”的建议建工单。
  • 线上源码 e76de6fc08f8b8f0a4bec6a51eb9193451aa784e，release 20261006-e76de6f-358；只读核验代码 e2a68b33caab3f4b4cf04733afe91c3a66d51504。
  • 原报告对象当前 ERPGo 返回7个尺码，GoAuto 档案有13项；同一尺码标识存在裸尺码和不同推荐体重说明的完整名称。SYB 历史 raw_json 的 productSpec 确有不同体重版本，不是 GoAuto 凭空生成。
  • 原报告明细使用带推荐体重的完整尺码键，该键未映射；裸尺码及另一个体重版本已有映射。多个名字可能指向同一 PDD 尺码，但系统不会自动共享映射。
  • 本单仅保存脱敏事实与合成用例。真实订单号、商品ID、原始规格、完整响应和凭据不写入工单；历史修复对象实施前通过用户确认的原报告对象精确核对。
  • 不能仅凭当前 ERPGo 返回推断所有历史标签都是错误，更不能据此删除其他产品规格。

根因与代码证据

  1. sybspec.Parse / StripAnnotations 会剥离括号说明，得到裸尺码。
  2. sybspec/resolve_keys.go:ResolveKeys 收集同一商品所有原始规格；同一个裸键对应多个不同原文时，为防止长袖/短袖等真实差异被合并，恢复完整原文作为键。当前无法区分“推荐体重说明变化”和“真实规格差异”。
  3. sybimport/resolve_keys.go:resyncShopeeProductKeys 重新计算同商品明细键并补入档案，保留人工/AI确认明细。
  4. task/spec_sync.go:incomingDimensions 对 ERPGo 尺码统一 StripAnnotations，补入裸尺码；与 SYB 消歧后保留的完整键不一致。
  5. shopeeproduct/specs.go:Merge 仅按维度名＋完整规格名称去重，只增不删、保留已有映射，因此裸尺码和各历史完整键累积共存。
  6. source=import 未细分 SYB/ERPGo，不能从该字段单独断定某个历史值由哪次写入产生。根因由原始规格、现存档案及代码共同核验，不伪造逐次变更日志。

依赖与并行

  • 复用 #290/#301/#358 已有解析、规格同步及映射语义，不要求 ERPGo 改接口。
  • 不与共享解析/消歧/档案合并路径修改或同对象历史数据修复并行。
  • 与 #359 调度扫描修复无业务前置依赖，但若测试或共享文件重叠，需协调后串行。
  • 历史数据修复、迁移（若后来确需）、权限/并发变更和发布必须独立授权，本轮授权仅增加方案补齐、只读统计和本地验证，不含生产写入。

子项目影响 / 做什么、不做什么

  • server：规格键规范化、SYB消歧/明细写入、ERPGo尺码导入、必要的采购键一致性回归；原报告对象的授权定向历史纠正。
  • shared-docs：规格键及推荐体重说明的业务规则，必要的调用路径和运维修复说明。
  • 不改 Web/Android、页面布局、AI Provider、提示词或匹配阈值；不改 ERPGo 接口。
  • 不做任意文本前缀合并、所有括号内容删除、全库历史清理、相似尺码猜测或大规模规格重构。
  • 不改采购任务快照，不自动创建/执行采购或付款，不重跑全量 AI。
  • 不把本任务扩展为任意 ERPGo/SYB 标签差异的通用治理。

最小方案 v2：保留 Claude #59/#60 方向，补齐采购保护

1. 统一身份仅用于尺码

  • 只对字母尺码（x{0,4}[sml]、[2-9]xl）＋单个完整【】中的纯“建议/建議＋数值或范围＋斤/公斤/千克/kg”识别推荐体重附注；数值允许小数，范围符号限定 -、~、～、至、到，首尾完整匹配。
  • 均码、one/free size、数字/鞋码、非括号连写体重、混合款式描述、多段括号不纳入。不把2XL与XXL等号制别名合并，不改变原文大小写或规范化其他文本。
  • 同一共享尺码原文身份函数供ResolveKeys与采购CollapsedSpecKey的尺码分支使用；颜色分支维持原规则，不能因复用无角色函数顺手放宽颜色或所有空白差异。
  • 保留Parse/RawSpecHalves原文分工；ERPGo incomingDimensions不改生产实现，补一致性回归。真实款式差异的既有ERPGo剥括号问题不在本单修复。
  • 只读核对候选商品当前ERPGo规格，若同一字母尺码同时出现多个不同推荐体重原文，视为真实SKU冲突候选，保留原键、不统一；请求失败或语义无法确认不能记为安全。一次抽查不是未来源数据的永久保证，正式实施前必须定清此排除信息如何在统一身份与采购消费两端一致生效；发现真实冲突则停止全局放行，不能仅靠无商品上下文的正则绕过。

2. 按商品＋规范尺码分组，先计划、后原子写入

  • 正常同步与Reparse都使用同一分组计划，覆盖所有存量兄弟明细以及当前incomingRaw；不能仅在兄弟循环continue后仍向外返回新键，导致ApplyDetail/Reparse重新写入冲突组。
  • 新旧映射冲突必须同时比较：裸键即使已有confirmed映射，也必须与旧完整键的已有确认映射一致；不同PDD目标时整组保留原键，不自动选赢家。
  • 无映射(nil)、待确认(pending)、确认(confirmed)分别处理。新键pending、目标失效、来源/结构不合法等不按“无映射”处理；不利用Merge只填nil的行为造成原confirmed丢失。
  • 新键无映射时，仅在被替换旧键均有有效confirmed映射、目标唯一且属于当前关联PDD可选尺码时，可复制既有映射到新键；不改变source/confidence/reason、不调用AI、不覆盖人工选择。不能因某旧值无映射就牺牲另一条原有confirmed明细；不满足安全合并条件则整组保留原键。
  • 新键已有有效confirmed且所有旧确认映射与之相同时可复用；缺失旧映射可因此补齐，但pending或人工维护/确认的特殊情况需保护，不静默覆盖。
  • 人工/AI确认明细、manual规格条目默认保留原键与映射；以保守分组保护避免混写，必要时停止该组并记录原因。
  • 只对新旧确属本单纯推荐体重等价的键迁移已有映射，不把其他原因引起的键变化纳入。保存映射与改明细键必须在同一事务，重读关联PDD、当前候选、商品版本及引用，避免并发覆盖；任一验证失败保持旧数据。
  • 通用Merge保持原语义。mergeParsedSpec若增加可选映射参数，默认调用行为必须不变；采购预检/批量创建、SYB同步、Reparse、人工/AI规格解析调用点均纳入回归。
  • “原有映射不丢失/不改目标”是验证指标，不等同于仅凭映射宣称整单可采购；完整SKU组合、设备及其他采购资格不在该统计中。

3. 历史修复分阶段，避免扩大影响

  • 代码未来上线后也不能自动宣称存量已清理。本轮只读统计与本地合成验证，不执行Reparse或映射写入。
  • 后续获得授权后，先对样例A执行既有ReparseBatch(force=false)验证，明确它可能重算同商品所有未确认明细；样例B仍仅是验证样例，未授权生产清理。
  • 其他商品随正常同步采用新逻辑的前提，是上述完整组保护已实现、影响统计与实际回归通过；未解决真实SKU冲突前不能全局放行。
  • 档案旧别名删除与改明细键分开：仅在独立授权、备份、无明细引用且无确认映射时允许定向删除，否则保留并报告。不把“保留旧别名”说成页面重复已消失。
  • 不修改raw_json、现存采购任务快照、正常颜色尺码及正确映射；不付款，不执行采购，不新增表/迁移/接口。

4. 本轮只读统计和回归范围

  • 只读取所需规格原文、目标键、确认标志、档案映射、关联PDD候选；业务内容在内存处理，不落仓库/工单/日志。ERPGo只做候选商品GET，串行有界，不重同步GoAuto、不调用AI。
  • 统计：匹配狭窄语法的原文种类/商品数；预计换键的明细数；未经保护会丢失确认映射或改变目标的数量；新旧映射冲突、pending、失效、人工保护等分组；当前ERPGo同尺码多个体重候选及查询失败数量。
  • 本地先运行当前代码相关回归，再用隔离的候选方案验证程序/合成用例验证计划。方案验证不冒充生产实现测试或完整采购成功率；实际代码集成回归仍须正式实施时执行。
  • 统计对线上读取时点有效，不代表未来源数据或整个历史范围绝无风险。

设计与原型门禁

  • 非UI数据/规格键缺陷，无需QuantUX或页面原型，无HTML导出。
  • 设计证据：本单v2流程、分组映射保护及合成正反例。
  • 流程：判定纯推荐体重说明 → 共享规范键 → SYB/ERPGo一致消歧及合并 → 对原报告对象预览引用/映射 → 独立授权 → 事务纠正 → 回读与再次同步验证。
  • 确认人：用户；确认时间2026-10-06；确认范围为上述最小方向及建单。
  • 狭窄语法、分组保护及本轮统计/回归已补齐；正式实施前仍需落定商品级当前SKU冲突信息在解析与采购两侧的传递。本轮已授权方案补齐、只读统计及隔离候选验证；未执行正式生产修复，也没有生产写入或发布授权。
  • 默认不要求数据库结构迁移或API变化；若确需，先更新方案并重新确认，不绕过授权。

验收标准

  • 同一明确尺码仅推荐体重说明不同，SYB与ERPGo得到同一规格键，不再增加多个别名。
  • 原始productSpec保持原文，不丢失后续排错与统计依据。
  • 同商品混合“纯体重说明”和“真实款式差异”时不会误合并；颜色、鞋码、单维度、非服装及#358连写体重原有行为不变。
  • 裸尺码、不同纯推荐体重别名混用，ResolveKeys与采购消费键一致；真实消歧和人工/AI确认保护不受破坏。
  • 已有正确映射保留；合并组映射不一致、PDD候选已失效、手工维护/确认条目均不被静默覆盖。
  • 原报告对象定向纠正前有明确授权、备份和精确引用范围；档案与明细一致，其他规格、采购快照不变。
  • 同一SYB明细再次同步、ERPGo规格再次同步均不重新产生本次别名；幂等重放安全。
  • 验证、未验证项、代码提交、历史修复实际范围回写工单；待用户验收，不自行关闭。
  • 样例B覆盖“其他尺码重复、当前明细目标映射正常”：保留正常目标和确认映射，不把重复直接判成当前明细不可采购；只读/合成验证不执行历史数据变更。

补充验证样例 B（2026-10-06，用户授权纳入）

  • 对象：同一报告订单中新核对的另一件商品，以“样例B”脱敏标识；不是原报告的样例A，不在工单保存真实订单号/商品ID。
  • 线上只读事实：ERPGo当前返回6个尺码，GoAuto档案有8项；一个字母尺码同时存在裸键及两个不同推荐体重版本的完整键，三者已有确认映射且指向相同PDD尺码。SYB历史原始规格确有两个体重版本，当前ERPGo返回中未发现该尺码同时有多个体重版本。
  • 与样例A的区别：样例B这笔订单使用另一个没有重复的裸尺码键，当前已有确认映射；属于“档案存在重复，但本条明细没有尺码映射缺失”，不能把重复直接等同于当前订单不能采购，也不能据此宣称已验证整单可采购。
  • 合成回归：构造某尺码裸键及两个纯推荐体重别名映射一致，同时存在另一个正常尺码供当前明细使用。验证规范化后不再制造别名、采购侧不会误报纯推荐说明塌缩，正常尺码的原有映射及明细目标保持不变。
  • 保护要求：已有确认映射的别名不能因名称重复直接删除；样例B仅新增只读核验与合成回归覆盖，不授权历史清理、重解析、映射迁移、真实同步或采购。
  • 已按Claude #59/#60及Codex代码核验整合v2保护；样例B仍不能证明所有商品同尺码体重差异都等价。

验证方式

  • server：go test ./app/goauto/sybspec ./app/goauto/shopeespec ./app/goauto/shopeeproduct。
  • 对 sybimport、task、purchase 执行受影响的消歧、规格同步、明细引用及匹配键回归，实施时补齐具体测试名。
  • 先复核存量失败基线，不能把历史失败伪装成本次通过，也不混入无关修复。
  • 合成测试覆盖正反顺序、简繁建议、空白、不同体重版本、同名裸尺码、真正款式差异、混合描述、映射冲突、无映射与人工确认保护。
  • 本地使用模拟Provider/现有映射验证，不通过真实采购验证。
  • 线上只读预览与实际数据修复分开记录；真实同步、修复和发布需确认授权，未执行不得标记验收通过。

风险、回退与文档影响

  • 主要风险是把不同真实SKU合并，或让明细规范键与档案映射再次不一致；使用狭窄纯推荐体重语法、统一函数及冲突停止控制范围。
  • 正确映射不以“都是同个尺码”强行覆盖；不能把当前ERPGo规格列表当成历史订单的唯一正确标签。
  • 更新 Business-Rules-and-Glossary 中的规范键/推荐体重规则；如调用路径变化更新 Architecture-and-Code-Map；必要时补 Deployment-and-Operations 的定向修复说明。
  • 共享Agent API、权限及产品页面无变化，不新增对应契约或原型。
  • 长期事实落地后在线更新Wiki并回读revision，完成一次sync和sync --check；建单阶段不编辑镜像。
  • 交付文档沿用已有业务/运维Wiki；不新增专项文档、通用清理工具或任务快照。
  • Gitea工单是任务唯一事实源。当前工具清单未提供Gitea MCP，回退已配置REST API，凭据只从本机私有配置读取。

需求变化记录

  • 2026-10-06 v1：用户确认按分析建议建单，限定纯推荐体重的衣服尺码键统一及原报告对象授权后的定向历史修复；不实施。
  • 2026-10-06 验证范围补充：用户授权将新核对商品纳入样例B，仅新增只读核验和合成回归场景；不扩大原报告对象的历史清理范围，不实施。
  • 2026-10-06 v2：用户授权保留Claude最小方向并补齐保护，再做只读影响统计与本地回归。纳入新旧映射冲突、nil/pending区分、当前导入明细返回值保护、角色限制及真实SKU排除；暂不实施正式修复、不写生产数据。

只读影响统计与本地验证结果（2026-10-06）

统计口径

  • 本次为方案预演，不是生产执行：线上数据库使用只读事务取最小字段，内存处理；Go探针直接调用现有Parse、RawSpecHalves、ResolveKeys作为基线，并在隔离程序中实现候选尺码身份规则；Python分组保护模型检查映射保留。未把新模型接入业务代码。
  • 第一读取时点北京时间16:00:11：7155件有原始明细的存活蝦皮商品、24004条带规格原文的明细；纯推荐体重语法匹配720种尺码原文、2601个商品-原文组合，涉及1267件商品。这是语法覆盖范围，不等于实际换键范围。
  • 实际预计换键为11件商品、15个商品-规范尺码组、48条未人工/AI确认的成功明细；其中18条当前具有有效confirmed尺码映射。
  • 对1267件候选商品串行GET当前ERPGo规格：1266件获得非空尺码，1件无法确认；发现1件商品的同一字母尺码同时有两种不同体重说明。
  • 16:09:06仅针对11件实际受影响商品复核：10件有尺码，1件HTTP200但size为空；冲突组当前确有两个不同数字体重范围，不是单纯空格重复。
  • 正常业务在统计期间继续运行，第二次数据库读取为7159件/24027条、721种原文/1268件候选；11件、15组、48条的实际换键集合数量未变化。第一次ERPGo全候选核对不冒充第二时点全部候选已逐件核对。

保护后预演

决策 尺码组 明细
复用有效且一致的裸尺码确认映射 6 27
原来未匹配，统一后仍保持未匹配 7 17
当前ERPGo同尺码多个体重说明，保留原键 1 3
当前ERPGo没有尺码证据，保留原键 1 1
合计 15 48
  • 候选计划可改键44条，保留4条；不是48条全量统一，更不是44条都变成可采购。
  • 当前数据中，新旧已确认映射目标冲突组为0、目标pending组为0、需从旧键携带映射到空裸键的组为0；它们仍由合成测试覆盖，不能据此删除保护逻辑。
  • 这48条若只改名称，当前已有裸键映射的18条未发现确认映射丢失或目标改变；加入完整保护后预演丢失数0、改变目标数0。此结论仅限当前数据，不能推断任何未来商品换名都安全。
  • 独立只读核对带纯体重别名相关档案的16项确认映射结构，未发现source/confidence/reason结构问题。
  • 未触碰真实明细、档案、任务快照、定时任务配置；未调用AI、Reparse、真实同步或采购。原样例A历史修复授权仍需单独取得，样例B仍仅为验证对象。

必须保留的实施限制

  • 已实际发现当前源规格冲突，因此“所有字母尺码＋纯体重说明均等价”不能作为全局规则直接上线。
  • 正式实现必须让SYB消歧与采购冲突检测共享同一个商品级“允许统一”判定；当前同尺码多体重SKU候选、size为空/来源不可确认时保留原身份，不能只在导入侧停止换键，却在采购侧全局放宽冲突检测。
  • 单独的无商品上下文rawIdentity函数不足以落实该保护。允许集合如何获取、复用及失效，需在正式实施前确定；不以本次只读核对结果作为永久白名单。
  • 本轮不为解决这一设计点引入表、迁移、接口或自动外部写入，也不开始全局上线。

已执行回归与限制

代码基线e2a68b33caab3f4b4cf04733afe91c3a66d51504，所涉server路径与线上e76de6f无差异，server工作区无生产源码修改。

  • 通过：go test ./app/goauto/sybspec ./app/goauto/shopeespec ./app/goauto/shopeeproduct。

  • 通过：task的TestIncoming*（ERPGo规格导入现有行为）、purchase的塌缩/重复原文预检以及TestAdminQueriesAndBatchRetryDoNotResolveArchivedSpecs。

  • 通过：sybimport的人工/AI确认默认重解析跳过、raw_json保留、force及手工目标重新导入保护等定向测试。

  • 隔离候选程序通过：Go 4组测试（其中16个子用例），覆盖纯体重语法、真实款式/均码反例、基线采购冲突复现、只放宽尺码而不改颜色；Python 16项分组保护测试，覆盖新旧映射冲突、pending、失效/非法映射、人工保护、源SKU冲突/未知、幂等、当前明细与兄弟组同进退。

  • 三项当前代码基线失败（本轮未改生产源码，未顺手修复）：

    1. TestReparseUpdatesStatusWhenRuleImproves：旧用例预期uncertain，当前返回success。
    2. TestManualCorrectMergesIntoArchiveLikeASuccessfulParse：旧用例预期歧义输入未入档，当前行为不符。
    3. TestReimportPreservesIdenticalAIInputAndInvalidatesChangedSource：现有正常导入路径会在已确定性解析成功时清除AI确认，和该测试预期不符；不能把“Reparse跳过AI确认”推广为所有同步入口永远保留AI确认。

  • 隔离文件在本机临时目录 goauto-360-review-00001db1，只有代码与合成样例，不保存生产输入。候选模型通过不等于真实事务、并发、正式导入/采购完整集成回归通过；正式修复实施时必须重新验证。

  • 本轮无代码提交/推送、无迁移、无部署。规则尚未落地，无长期事实变化，暂不更新Wiki或同步镜像；正式实施时按本单文档影响处理。

  • 2026-10-06验证结论：已发现1组当前源规格冲突及1组空尺码来源，禁止无条件全局统一。受影响48条经保护模型预演允许44条、保留4条，确认映射退化0。正式业务代码仍未实施，旧测试失败及未验证项如上。

> **2026-10-07 最新进展**：用户另行授权按 ERPGo 最新尺码刷新两件报告商品的档案，已完成服务器受限备份、单事务定向更新和数据库/Admin详情回读；尺码分别13→7、8→6。仅尺码列表及更新时间变化，保留同名映射、颜色和其他数据，后续由用户手动匹配。历史 SYB 目标键不在本轮修复范围，仍可能与最新档案不一致；正式 #360 代码尚未实施。详见评论 8903、8904；下文“未生产写入”描述为10月6日那轮统计的历史边界。 ## 基本信息 - 类型：缺陷；所属 Epic / MVP：无。 - 关联：#290（ERPGo 完整规格同步）、#301（规格键消歧）、#358（连写尺码角色识别）。 - 阶段：v2保护方案、只读影响统计及本地候选模型验证已完成；正式修复仍待实施，真实SKU冲突的商品级判定必须先落定。不执行生产写入、真实同步/匹配/采购，不迁移或发布。 ## 原始需求与核验基线 - 来源：用户对话，2026-10-06。用户报告某 SYB 订单对应蝦皮商品的尺码重复，核验后确认按“仅统一明确衣服尺码的推荐体重说明、保留真实规格差异”的建议建工单。 - 线上源码 e76de6fc08f8b8f0a4bec6a51eb9193451aa784e，release 20261006-e76de6f-358；只读核验代码 e2a68b33caab3f4b4cf04733afe91c3a66d51504。 - 原报告对象当前 ERPGo 返回7个尺码，GoAuto 档案有13项；同一尺码标识存在裸尺码和不同推荐体重说明的完整名称。SYB 历史 raw_json 的 productSpec 确有不同体重版本，不是 GoAuto 凭空生成。 - 原报告明细使用带推荐体重的完整尺码键，该键未映射；裸尺码及另一个体重版本已有映射。多个名字可能指向同一 PDD 尺码，但系统不会自动共享映射。 - 本单仅保存脱敏事实与合成用例。真实订单号、商品ID、原始规格、完整响应和凭据不写入工单；历史修复对象实施前通过用户确认的原报告对象精确核对。 - 不能仅凭当前 ERPGo 返回推断所有历史标签都是错误，更不能据此删除其他产品规格。 ## 根因与代码证据 1. sybspec.Parse / StripAnnotations 会剥离括号说明，得到裸尺码。 2. sybspec/resolve_keys.go:ResolveKeys 收集同一商品所有原始规格；同一个裸键对应多个不同原文时，为防止长袖/短袖等真实差异被合并，恢复完整原文作为键。当前无法区分“推荐体重说明变化”和“真实规格差异”。 3. sybimport/resolve_keys.go:resyncShopeeProductKeys 重新计算同商品明细键并补入档案，保留人工/AI确认明细。 4. task/spec_sync.go:incomingDimensions 对 ERPGo 尺码统一 StripAnnotations，补入裸尺码；与 SYB 消歧后保留的完整键不一致。 5. shopeeproduct/specs.go:Merge 仅按维度名＋完整规格名称去重，只增不删、保留已有映射，因此裸尺码和各历史完整键累积共存。 6. source=import 未细分 SYB/ERPGo，不能从该字段单独断定某个历史值由哪次写入产生。根因由原始规格、现存档案及代码共同核验，不伪造逐次变更日志。 ## 依赖与并行 - 复用 #290/#301/#358 已有解析、规格同步及映射语义，不要求 ERPGo 改接口。 - 不与共享解析/消歧/档案合并路径修改或同对象历史数据修复并行。 - 与 #359 调度扫描修复无业务前置依赖，但若测试或共享文件重叠，需协调后串行。 - 历史数据修复、迁移（若后来确需）、权限/并发变更和发布必须独立授权，本轮授权仅增加方案补齐、只读统计和本地验证，不含生产写入。 ## 子项目影响 / 做什么、不做什么 - server：规格键规范化、SYB消歧/明细写入、ERPGo尺码导入、必要的采购键一致性回归；原报告对象的授权定向历史纠正。 - shared-docs：规格键及推荐体重说明的业务规则，必要的调用路径和运维修复说明。 - 不改 Web/Android、页面布局、AI Provider、提示词或匹配阈值；不改 ERPGo 接口。 - 不做任意文本前缀合并、所有括号内容删除、全库历史清理、相似尺码猜测或大规模规格重构。 - 不改采购任务快照，不自动创建/执行采购或付款，不重跑全量 AI。 - 不把本任务扩展为任意 ERPGo/SYB 标签差异的通用治理。 ## 最小方案 v2：保留 Claude #59/#60 方向，补齐采购保护 ### 1. 统一身份仅用于尺码 - 只对字母尺码（x{0,4}[sml]、[2-9]xl）＋单个完整【】中的纯“建议/建議＋数值或范围＋斤/公斤/千克/kg”识别推荐体重附注；数值允许小数，范围符号限定 -、~、～、至、到，首尾完整匹配。 - 均码、one/free size、数字/鞋码、非括号连写体重、混合款式描述、多段括号不纳入。不把2XL与XXL等号制别名合并，不改变原文大小写或规范化其他文本。 - 同一共享尺码原文身份函数供ResolveKeys与采购CollapsedSpecKey的尺码分支使用；颜色分支维持原规则，不能因复用无角色函数顺手放宽颜色或所有空白差异。 - 保留Parse/RawSpecHalves原文分工；ERPGo incomingDimensions不改生产实现，补一致性回归。真实款式差异的既有ERPGo剥括号问题不在本单修复。 - 只读核对候选商品当前ERPGo规格，若同一字母尺码同时出现多个不同推荐体重原文，视为真实SKU冲突候选，保留原键、不统一；请求失败或语义无法确认不能记为安全。一次抽查不是未来源数据的永久保证，正式实施前必须定清此排除信息如何在统一身份与采购消费两端一致生效；发现真实冲突则停止全局放行，不能仅靠无商品上下文的正则绕过。 ### 2. 按商品＋规范尺码分组，先计划、后原子写入 - 正常同步与Reparse都使用同一分组计划，覆盖所有存量兄弟明细以及当前incomingRaw；不能仅在兄弟循环continue后仍向外返回新键，导致ApplyDetail/Reparse重新写入冲突组。 - 新旧映射冲突必须同时比较：裸键即使已有confirmed映射，也必须与旧完整键的已有确认映射一致；不同PDD目标时整组保留原键，不自动选赢家。 - 无映射(nil)、待确认(pending)、确认(confirmed)分别处理。新键pending、目标失效、来源/结构不合法等不按“无映射”处理；不利用Merge只填nil的行为造成原confirmed丢失。 - 新键无映射时，仅在被替换旧键均有有效confirmed映射、目标唯一且属于当前关联PDD可选尺码时，可复制既有映射到新键；不改变source/confidence/reason、不调用AI、不覆盖人工选择。不能因某旧值无映射就牺牲另一条原有confirmed明细；不满足安全合并条件则整组保留原键。 - 新键已有有效confirmed且所有旧确认映射与之相同时可复用；缺失旧映射可因此补齐，但pending或人工维护/确认的特殊情况需保护，不静默覆盖。 - 人工/AI确认明细、manual规格条目默认保留原键与映射；以保守分组保护避免混写，必要时停止该组并记录原因。 - 只对新旧确属本单纯推荐体重等价的键迁移已有映射，不把其他原因引起的键变化纳入。保存映射与改明细键必须在同一事务，重读关联PDD、当前候选、商品版本及引用，避免并发覆盖；任一验证失败保持旧数据。 - 通用Merge保持原语义。mergeParsedSpec若增加可选映射参数，默认调用行为必须不变；采购预检/批量创建、SYB同步、Reparse、人工/AI规格解析调用点均纳入回归。 - “原有映射不丢失/不改目标”是验证指标，不等同于仅凭映射宣称整单可采购；完整SKU组合、设备及其他采购资格不在该统计中。 ### 3. 历史修复分阶段，避免扩大影响 - 代码未来上线后也不能自动宣称存量已清理。本轮只读统计与本地合成验证，不执行Reparse或映射写入。 - 后续获得授权后，先对样例A执行既有ReparseBatch(force=false)验证，明确它可能重算同商品所有未确认明细；样例B仍仅是验证样例，未授权生产清理。 - 其他商品随正常同步采用新逻辑的前提，是上述完整组保护已实现、影响统计与实际回归通过；未解决真实SKU冲突前不能全局放行。 - 档案旧别名删除与改明细键分开：仅在独立授权、备份、无明细引用且无确认映射时允许定向删除，否则保留并报告。不把“保留旧别名”说成页面重复已消失。 - 不修改raw_json、现存采购任务快照、正常颜色尺码及正确映射；不付款，不执行采购，不新增表/迁移/接口。 ### 4. 本轮只读统计和回归范围 - 只读取所需规格原文、目标键、确认标志、档案映射、关联PDD候选；业务内容在内存处理，不落仓库/工单/日志。ERPGo只做候选商品GET，串行有界，不重同步GoAuto、不调用AI。 - 统计：匹配狭窄语法的原文种类/商品数；预计换键的明细数；未经保护会丢失确认映射或改变目标的数量；新旧映射冲突、pending、失效、人工保护等分组；当前ERPGo同尺码多个体重候选及查询失败数量。 - 本地先运行当前代码相关回归，再用隔离的候选方案验证程序/合成用例验证计划。方案验证不冒充生产实现测试或完整采购成功率；实际代码集成回归仍须正式实施时执行。 - 统计对线上读取时点有效，不代表未来源数据或整个历史范围绝无风险。 ## 设计与原型门禁 - 非UI数据/规格键缺陷，无需QuantUX或页面原型，无HTML导出。 - 设计证据：本单v2流程、分组映射保护及合成正反例。 - 流程：判定纯推荐体重说明 → 共享规范键 → SYB/ERPGo一致消歧及合并 → 对原报告对象预览引用/映射 → 独立授权 → 事务纠正 → 回读与再次同步验证。 - 确认人：用户；确认时间2026-10-06；确认范围为上述最小方向及建单。 - 狭窄语法、分组保护及本轮统计/回归已补齐；正式实施前仍需落定商品级当前SKU冲突信息在解析与采购两侧的传递。本轮已授权方案补齐、只读统计及隔离候选验证；未执行正式生产修复，也没有生产写入或发布授权。 - 默认不要求数据库结构迁移或API变化；若确需，先更新方案并重新确认，不绕过授权。 ## 验收标准 - [ ] 同一明确尺码仅推荐体重说明不同，SYB与ERPGo得到同一规格键，不再增加多个别名。 - [ ] 原始productSpec保持原文，不丢失后续排错与统计依据。 - [ ] 同商品混合“纯体重说明”和“真实款式差异”时不会误合并；颜色、鞋码、单维度、非服装及#358连写体重原有行为不变。 - [ ] 裸尺码、不同纯推荐体重别名混用，ResolveKeys与采购消费键一致；真实消歧和人工/AI确认保护不受破坏。 - [ ] 已有正确映射保留；合并组映射不一致、PDD候选已失效、手工维护/确认条目均不被静默覆盖。 - [ ] 原报告对象定向纠正前有明确授权、备份和精确引用范围；档案与明细一致，其他规格、采购快照不变。 - [ ] 同一SYB明细再次同步、ERPGo规格再次同步均不重新产生本次别名；幂等重放安全。 - [ ] 验证、未验证项、代码提交、历史修复实际范围回写工单；待用户验收，不自行关闭。 - [ ] 样例B覆盖“其他尺码重复、当前明细目标映射正常”：保留正常目标和确认映射，不把重复直接判成当前明细不可采购；只读/合成验证不执行历史数据变更。 ## 补充验证样例 B（2026-10-06，用户授权纳入） - 对象：同一报告订单中新核对的另一件商品，以“样例B”脱敏标识；不是原报告的样例A，不在工单保存真实订单号/商品ID。 - 线上只读事实：ERPGo当前返回6个尺码，GoAuto档案有8项；一个字母尺码同时存在裸键及两个不同推荐体重版本的完整键，三者已有确认映射且指向相同PDD尺码。SYB历史原始规格确有两个体重版本，当前ERPGo返回中未发现该尺码同时有多个体重版本。 - 与样例A的区别：样例B这笔订单使用另一个没有重复的裸尺码键，当前已有确认映射；属于“档案存在重复，但本条明细没有尺码映射缺失”，不能把重复直接等同于当前订单不能采购，也不能据此宣称已验证整单可采购。 - 合成回归：构造某尺码裸键及两个纯推荐体重别名映射一致，同时存在另一个正常尺码供当前明细使用。验证规范化后不再制造别名、采购侧不会误报纯推荐说明塌缩，正常尺码的原有映射及明细目标保持不变。 - 保护要求：已有确认映射的别名不能因名称重复直接删除；样例B仅新增只读核验与合成回归覆盖，不授权历史清理、重解析、映射迁移、真实同步或采购。 - 已按Claude #59/#60及Codex代码核验整合v2保护；样例B仍不能证明所有商品同尺码体重差异都等价。 ## 验证方式 - server：go test ./app/goauto/sybspec ./app/goauto/shopeespec ./app/goauto/shopeeproduct。 - 对 sybimport、task、purchase 执行受影响的消歧、规格同步、明细引用及匹配键回归，实施时补齐具体测试名。 - 先复核存量失败基线，不能把历史失败伪装成本次通过，也不混入无关修复。 - 合成测试覆盖正反顺序、简繁建议、空白、不同体重版本、同名裸尺码、真正款式差异、混合描述、映射冲突、无映射与人工确认保护。 - 本地使用模拟Provider/现有映射验证，不通过真实采购验证。 - 线上只读预览与实际数据修复分开记录；真实同步、修复和发布需确认授权，未执行不得标记验收通过。 ## 风险、回退与文档影响 - 主要风险是把不同真实SKU合并，或让明细规范键与档案映射再次不一致；使用狭窄纯推荐体重语法、统一函数及冲突停止控制范围。 - 正确映射不以“都是同个尺码”强行覆盖；不能把当前ERPGo规格列表当成历史订单的唯一正确标签。 - 更新 Business-Rules-and-Glossary 中的规范键/推荐体重规则；如调用路径变化更新 Architecture-and-Code-Map；必要时补 Deployment-and-Operations 的定向修复说明。 - 共享Agent API、权限及产品页面无变化，不新增对应契约或原型。 - 长期事实落地后在线更新Wiki并回读revision，完成一次sync和sync --check；建单阶段不编辑镜像。 - 交付文档沿用已有业务/运维Wiki；不新增专项文档、通用清理工具或任务快照。 - Gitea工单是任务唯一事实源。当前工具清单未提供Gitea MCP，回退已配置REST API，凭据只从本机私有配置读取。 ## 需求变化记录 - 2026-10-06 v1：用户确认按分析建议建单，限定纯推荐体重的衣服尺码键统一及原报告对象授权后的定向历史修复；不实施。 - 2026-10-06 验证范围补充：用户授权将新核对商品纳入样例B，仅新增只读核验和合成回归场景；不扩大原报告对象的历史清理范围，不实施。 - 2026-10-06 v2：用户授权保留Claude最小方向并补齐保护，再做只读影响统计与本地回归。纳入新旧映射冲突、nil/pending区分、当前导入明细返回值保护、角色限制及真实SKU排除；暂不实施正式修复、不写生产数据。 ## 只读影响统计与本地验证结果（2026-10-06） ### 统计口径 - 本次为方案预演，不是生产执行：线上数据库使用只读事务取最小字段，内存处理；Go探针直接调用现有Parse、RawSpecHalves、ResolveKeys作为基线，并在隔离程序中实现候选尺码身份规则；Python分组保护模型检查映射保留。未把新模型接入业务代码。 - 第一读取时点北京时间16:00:11：7155件有原始明细的存活蝦皮商品、24004条带规格原文的明细；纯推荐体重语法匹配720种尺码原文、2601个商品-原文组合，涉及1267件商品。这是语法覆盖范围，不等于实际换键范围。 - 实际预计换键为11件商品、15个商品-规范尺码组、48条未人工/AI确认的成功明细；其中18条当前具有有效confirmed尺码映射。 - 对1267件候选商品串行GET当前ERPGo规格：1266件获得非空尺码，1件无法确认；发现1件商品的同一字母尺码同时有两种不同体重说明。 - 16:09:06仅针对11件实际受影响商品复核：10件有尺码，1件HTTP200但size为空；冲突组当前确有两个不同数字体重范围，不是单纯空格重复。 - 正常业务在统计期间继续运行，第二次数据库读取为7159件/24027条、721种原文/1268件候选；11件、15组、48条的实际换键集合数量未变化。第一次ERPGo全候选核对不冒充第二时点全部候选已逐件核对。 ### 保护后预演 | 决策 | 尺码组 | 明细 | |---|---:|---:| | 复用有效且一致的裸尺码确认映射 | 6 | 27 | | 原来未匹配，统一后仍保持未匹配 | 7 | 17 | | 当前ERPGo同尺码多个体重说明，保留原键 | 1 | 3 | | 当前ERPGo没有尺码证据，保留原键 | 1 | 1 | | 合计 | 15 | 48 | - 候选计划可改键44条，保留4条；不是48条全量统一，更不是44条都变成可采购。 - 当前数据中，新旧已确认映射目标冲突组为0、目标pending组为0、需从旧键携带映射到空裸键的组为0；它们仍由合成测试覆盖，不能据此删除保护逻辑。 - 这48条若只改名称，当前已有裸键映射的18条未发现确认映射丢失或目标改变；加入完整保护后预演丢失数0、改变目标数0。此结论仅限当前数据，不能推断任何未来商品换名都安全。 - 独立只读核对带纯体重别名相关档案的16项确认映射结构，未发现source/confidence/reason结构问题。 - 未触碰真实明细、档案、任务快照、定时任务配置；未调用AI、Reparse、真实同步或采购。原样例A历史修复授权仍需单独取得，样例B仍仅为验证对象。 ### 必须保留的实施限制 - 已实际发现当前源规格冲突，因此“所有字母尺码＋纯体重说明均等价”不能作为全局规则直接上线。 - 正式实现必须让SYB消歧与采购冲突检测共享同一个商品级“允许统一”判定；当前同尺码多体重SKU候选、size为空/来源不可确认时保留原身份，不能只在导入侧停止换键，却在采购侧全局放宽冲突检测。 - 单独的无商品上下文rawIdentity函数不足以落实该保护。允许集合如何获取、复用及失效，需在正式实施前确定；不以本次只读核对结果作为永久白名单。 - 本轮不为解决这一设计点引入表、迁移、接口或自动外部写入，也不开始全局上线。 ### 已执行回归与限制 代码基线e2a68b33caab3f4b4cf04733afe91c3a66d51504，所涉server路径与线上e76de6f无差异，server工作区无生产源码修改。 - 通过：go test ./app/goauto/sybspec ./app/goauto/shopeespec ./app/goauto/shopeeproduct。 - 通过：task的TestIncoming*（ERPGo规格导入现有行为）、purchase的塌缩/重复原文预检以及TestAdminQueriesAndBatchRetryDoNotResolveArchivedSpecs。 - 通过：sybimport的人工/AI确认默认重解析跳过、raw_json保留、force及手工目标重新导入保护等定向测试。 - 隔离候选程序通过：Go 4组测试（其中16个子用例），覆盖纯体重语法、真实款式/均码反例、基线采购冲突复现、只放宽尺码而不改颜色；Python 16项分组保护测试，覆盖新旧映射冲突、pending、失效/非法映射、人工保护、源SKU冲突/未知、幂等、当前明细与兄弟组同进退。 - 三项当前代码基线失败（本轮未改生产源码，未顺手修复）： 1. TestReparseUpdatesStatusWhenRuleImproves：旧用例预期uncertain，当前返回success。 2. TestManualCorrectMergesIntoArchiveLikeASuccessfulParse：旧用例预期歧义输入未入档，当前行为不符。 3. TestReimportPreservesIdenticalAIInputAndInvalidatesChangedSource：现有正常导入路径会在已确定性解析成功时清除AI确认，和该测试预期不符；不能把“Reparse跳过AI确认”推广为所有同步入口永远保留AI确认。 - 隔离文件在本机临时目录 goauto-360-review-00001db1，只有代码与合成样例，不保存生产输入。候选模型通过不等于真实事务、并发、正式导入/采购完整集成回归通过；正式修复实施时必须重新验证。 - 本轮无代码提交/推送、无迁移、无部署。规则尚未落地，无长期事实变化，暂不更新Wiki或同步镜像；正式实施时按本单文档影响处理。 - 2026-10-06验证结论：已发现1组当前源规格冲突及1组空尺码来源，禁止无条件全局统一。受影响48条经保护模型预演允许44条、保留4条，确认映射退化0。正式业务代码仍未实施，旧测试失败及未验证项如上。
ila commented 2026-10-06 16:10:42 +08:00
Author
Owner
Copy Link
Copy Source

v2保护、只读统计与本地验证已集中回写正文

  • 用户授权本轮方案补齐、只读统计及回归，未执行生产写入或正式修复。
  • 实际可能换键11件商品、15组、48条明细；ERPGo核对发现1组同时存在两种体重说明、1组当前无尺码。
  • 保护后候选计划44条可换键、4条保留；已有confirmed映射丢失0、目标改变0。这不是全部44条可采购的声明。
  • 已记录Go现有回归、隔离候选程序及16项映射保护测试；sybimport三项基线失败如正文，未掩盖或修复。
  • 无商品上下文的全局rawIdentity方案不能直接上线：必须先把当前源规格排除条件一致传递到解析和采购两侧。此限制已补入正文，正式实现未开始。
  • 工单保持待实施；无新增提交、迁移、发布或Wiki长期事实变更。
## v2保护、只读统计与本地验证已集中回写正文 - 用户授权本轮方案补齐、只读统计及回归，未执行生产写入或正式修复。 - 实际可能换键11件商品、15组、48条明细；ERPGo核对发现1组同时存在两种体重说明、1组当前无尺码。 - 保护后候选计划44条可换键、4条保留；已有confirmed映射丢失0、目标改变0。这不是全部44条可采购的声明。 - 已记录Go现有回归、隔离候选程序及16项映射保护测试；sybimport三项基线失败如正文，未掩盖或修复。 - 无商品上下文的全局rawIdentity方案不能直接上线：必须先把当前源规格排除条件一致传递到解析和采购两侧。此限制已补入正文，正式实现未开始。 - 工单保持待实施；无新增提交、迁移、发布或Wiki长期事实变更。
ila commented 2026-10-07 14:42:51 +08:00
Author
Owner
Copy Link
Copy Source

用户授权的定向尺码刷新（2026-10-07，执行前范围）

用户明确要求按 ERPGo 最新尺码更新原报告的两件蝦皮商品，再由用户手动匹配。本轮仅对样例 A、B 的线上商品档案尺码列表作一次性定向刷新，不实施本单全局规格键规则。

  • 先读取 ERPGo 最新 size，沿用当前 incomingDimensions 的 StripAnnotations/去重规则；空值、来源失败或无法安全确定唯一尺码维度时停止。
  • 仅替换两件档案的尺码 values，原名仍存在的条目及映射保留；旧列表中不再存在的尺码从本次档案列表移除，新增值不猜测、不自动迁移映射，交用户手动匹配。
  • 颜色及映射、其他维度、商品关联、SYB 明细和采购任务快照保持不变。不调用 AI、同步、Reparse 或采购，不改代码、不迁移、不重启。
  • 写入前服务器受限备份；事务锁定并重核当前数据和活动匹配工作，条件更新；提交后数据库与只读详情接口复核。
  • 历史 SYB 明细可能仍引用被移除旧键；本轮不修改历史引用，后续同步仍可能追加旧别名，不能把此次刷新声明为 #360 根因已修复。用户后续手动匹配不能自动消除历史引用差异。
  • 本轮仅数据操作，无长期契约变化，不更新 Wiki。最终结果集中回写，#360 正式代码仍待实施。
## 用户授权的定向尺码刷新（2026-10-07，执行前范围） 用户明确要求按 ERPGo 最新尺码更新原报告的两件蝦皮商品，再由用户手动匹配。本轮仅对样例 A、B 的线上商品档案尺码列表作一次性定向刷新，不实施本单全局规格键规则。 - 先读取 ERPGo 最新 size，沿用当前 incomingDimensions 的 StripAnnotations/去重规则；空值、来源失败或无法安全确定唯一尺码维度时停止。 - 仅替换两件档案的尺码 values，原名仍存在的条目及映射保留；旧列表中不再存在的尺码从本次档案列表移除，新增值不猜测、不自动迁移映射，交用户手动匹配。 - 颜色及映射、其他维度、商品关联、SYB 明细和采购任务快照保持不变。不调用 AI、同步、Reparse 或采购，不改代码、不迁移、不重启。 - 写入前服务器受限备份；事务锁定并重核当前数据和活动匹配工作，条件更新；提交后数据库与只读详情接口复核。 - 历史 SYB 明细可能仍引用被移除旧键；本轮不修改历史引用，后续同步仍可能追加旧别名，不能把此次刷新声明为 #360 根因已修复。用户后续手动匹配不能自动消除历史引用差异。 - 本轮仅数据操作，无长期契约变化，不更新 Wiki。最终结果集中回写，#360 正式代码仍待实施。
ila commented 2026-10-07 14:45:46 +08:00
Author
Owner
Copy Link
Copy Source

两件商品尺码定向刷新完成（2026-10-07，待用户手动匹配）

按用户本轮明确授权执行，仅更新原报告样例 A、B，不实施全局 #360 代码。

  • ERPGo 最新 size 经现有导入规则 StripAnnotations（仅去除【…】）及唯一性校验后，样例 A 尺码 13→7，样例 B 8→6；本次最新列表未发生归一化塌缩，无新增尺码。
  • 分别移除旧别名 6、2 项，其中带旧映射 3、2 项；仍存在的同名尺码分别保留 6、6 个映射。不把旧别名映射猜测迁移到新名称，用户后续手动匹配。
  • 服务器受限恢复依据：/home/goauto/backups/20261007-360-sizes-144436/before.json；目录0700、文件0600，包含精确对象与更新前尺码所在档案、预期更新结果，不复制业务内容到仓库/工单。
  • 写前重新获取 ERPGo，核对相较只读预览的摘要完全一致；数据库事务内锁定两个档案，校验档案完整摘要、无人工来源尺码和无 running 自动匹配工作项。按主键、商品身份、原更新时间和原 JSON 条件更新，实际2行；同一事务提交。
  • 只修改 specs_json 中 size 维度 values 以及 updated_at。颜色/其他维度及其映射、维度元数据、商品关联和其余列完全一致；没有修改 SYB 明细、采购任务及快照。
  • 提交前后数据库回读通过；Admin 两个详情 GET 均 HTTP/业务码200，specs 与预期逐项一致，尺码数7和6。
  • 未调用 AI、Reparse、SYB/ERPGo 同步写入、采购或付款；不修改定时任务开关、不迁移、不发布、不重启，无源码提交。

边界与后续

更新前只读统计有17/2条历史 SYB 明细目标尺码不在归一化后的最新列表中；这些引用按授权范围保持原样。手动匹配商品档案不能自动纠正这些历史目标键，后续同步也仍可能再追加旧别名。本次不是全局根因修复或整单可采购保证。

#360 正式代码仍待实施，本轮仅完成独立授权的数据刷新，等待用户手动匹配/验收。一次性数据操作不改变长期契约，跳过 Wiki 更新和镜像同步。

## 两件商品尺码定向刷新完成（2026-10-07，待用户手动匹配） 按用户本轮明确授权执行，仅更新原报告样例 A、B，不实施全局 #360 代码。 - ERPGo 最新 size 经现有导入规则 StripAnnotations（仅去除【…】）及唯一性校验后，样例 A 尺码 13→7，样例 B 8→6；本次最新列表未发生归一化塌缩，无新增尺码。 - 分别移除旧别名 6、2 项，其中带旧映射 3、2 项；仍存在的同名尺码分别保留 6、6 个映射。不把旧别名映射猜测迁移到新名称，用户后续手动匹配。 - 服务器受限恢复依据：/home/goauto/backups/20261007-360-sizes-144436/before.json；目录0700、文件0600，包含精确对象与更新前尺码所在档案、预期更新结果，不复制业务内容到仓库/工单。 - 写前重新获取 ERPGo，核对相较只读预览的摘要完全一致；数据库事务内锁定两个档案，校验档案完整摘要、无人工来源尺码和无 running 自动匹配工作项。按主键、商品身份、原更新时间和原 JSON 条件更新，实际2行；同一事务提交。 - 只修改 specs_json 中 size 维度 values 以及 updated_at。颜色/其他维度及其映射、维度元数据、商品关联和其余列完全一致；没有修改 SYB 明细、采购任务及快照。 - 提交前后数据库回读通过；Admin 两个详情 GET 均 HTTP/业务码200，specs 与预期逐项一致，尺码数7和6。 - 未调用 AI、Reparse、SYB/ERPGo 同步写入、采购或付款；不修改定时任务开关、不迁移、不发布、不重启，无源码提交。 ### 边界与后续 更新前只读统计有17/2条历史 SYB 明细目标尺码不在归一化后的最新列表中；这些引用按授权范围保持原样。手动匹配商品档案不能自动纠正这些历史目标键，后续同步也仍可能再追加旧别名。本次不是全局根因修复或整单可采购保证。 #360 正式代码仍待实施，本轮仅完成独立授权的数据刷新，等待用户手动匹配/验收。一次性数据操作不改变长期契约，跳过 Wiki 更新和镜像同步。
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#360