Commit Graph
54 Commits
Author SHA1 Message Date
chengma 486a374869 feat: 复用颜色映射生成完整采购规格 (#295) 2026-08-24 00:12:36 +08:00
chengma f06ded8a0a feat: 建立商品颜色映射数据模型 (#293) 2026-08-23 23:55:33 +08:00
chengma 18ad85d3cb fix: 兼容相同顺运宝明细逐件回写 (#289) 2026-08-22 11:46:23 +08:00
chengma b685d2ce62 fix: 追加原始SKU字段兼容迁移 (#259) 2026-08-18 15:37:12 +08:00
chengma 4383bb87df fix: 使用原始SKU辅助档口匹配 (#259) 2026-08-18 15:25:58 +08:00
chengma b8f49fe4bb fix: 多件档口入库码逐件回写 (#250) 2026-08-18 15:18:35 +08:00
chengma 12414658d0 feat: 定义运行时规格解析契约与审计模型 (#254) 2026-08-17 16:53:11 +08:00
chengma f8f22a15c7 feat: 档口入库码后台批量回写 (#246) 2026-08-15 17:08:17 +08:00
chengma 8e500606c5 fix: 合并多件档口入库码回写 (#240) 2026-08-15 14:27:31 +08:00
chengma 2aea22b44d feat: 档口入库码支持软删除与重导恢复 (#238) 2026-08-15 10:49:28 +08:00
chengma 5a9c0f0e6c feat: 增加档口入库码单表导入 (#231) 2026-08-15 08:47:22 +08:00
chengma 1e0b7ad6e1 feat: AI 服务商接口兼容 HTTP (#223) 2026-08-14 11:15:50 +08:00
chengma d64579e9b3 feat: 增加顺运宝批量 AI 规格匹配 (#202) 2026-08-14 10:30:08 +08:00
chengma aac289a4d3 feat: 实现 AI 规格候选匹配与审计 (#201) 2026-08-14 10:08:32 +08:00
chengma 018da3f732 feat: 增加管理员 AI 模型配置 (#200) 2026-08-14 09:49:11 +08:00
chengma 4752fef54f feat: 支持人工修改蝦皮规格 (#215) 2026-08-13 12:14:02 +08:00
chengma 313e9f9151 feat: 收敛店铺管理和蝦皮分类搜索 (#212 #213) 2026-08-13 11:47:56 +08:00
chengma 8f707722ba feat: 建立全局店铺跨渠道管理 (#208 #209 #210 #211) 2026-08-13 11:15:54 +08:00
chengma ad1ccc2c60 feat: 完善 SYB 蝦皮主数据与软删除 (#203 #204 #205) 2026-08-13 10:39:21 +08:00
chengma 761058efc1 feat: 删除已停用的同步店铺 (#197) 2026-08-13 08:48:02 +08:00
chengma 8a8fff8480 feat: 按允许店铺筛选顺运宝同步 (#196) 2026-08-12 18:48:31 +08:00
chengma 4c5f0610fd feat: 明确顺运宝复用 PDD 关联 (#183) 2026-08-12 15:13:08 +08:00
chengma 253be7cb61 fix: 采购价格上限按数量计算总价 (#181) 2026-08-12 14:43:18 +08:00
chengma 9ad067503e feat: 任务改用采集采购独立序号 (#172) 2026-08-12 09:21:21 +08:00
chengma 9e328984e9 fix: 修复顺运宝采集任务孤儿状态 (#165) 2026-08-11 17:00:33 +08:00
chengma 9d4d6fc1e5 feat: 增加顺运宝店铺筛选 (#151) 2026-08-11 14:39:13 +08:00
chengma 9671202f4e fix: 补齐不完整的 v9 商品约束 (#144) 2026-08-11 11:30:08 +08:00
chengma fef97cf5f3 fix: 修复不完整的商品目录迁移 (#144) 2026-08-11 11:26:40 +08:00
chengma 38d6a0a04b feat: 展示蝦皮主图和店铺 (#142) 2026-08-11 11:18:51 +08:00
chengma 4259be0e55 feat: 支持无SKU目录导入策略 (#141) 2026-08-11 11:03:18 +08:00
chengma c05c4fafdb feat: 展示顺运宝观测规格 (#140) 2026-08-11 10:46:11 +08:00
chengma 0588ef18c8 refactor: 切换蝦皮数据到目录接口 (#135) 2026-08-11 10:16:48 +08:00
chengma 107ee5ce85 feat: 建立商品目录接入基础 (#132) 2026-08-11 10:00:07 +08:00
chengma a9f22b9b0e feat: 按创建人隔离采集采购任务 (#127) 2026-08-10 23:10:28 +08:00
chengma a26219091a fix: 简化真实采购创建并恢复客户端选择 (#112) 2026-08-10 18:15:28 +08:00
chengma 3aaa40cfe0 feat: 增加真实采购任务安全模式 (#98) 2026-08-10 15:11:38 +08:00
chengma 5a77bde534 feat: 增加规格匹配建议与决策审计 (#90) 2026-08-10 12:41:17 +08:00
chengma d1165b9e17 feat: 重构顺运宝规格主链路 (#88) 2026-08-10 12:24:23 +08:00
chengma 7e74bf210d feat: 建立 MySQL 8 数据库基础 (#78) 2026-08-10 01:22:22 +08:00
chengma 4433e3af37 feat: 完成规格映射与采购任务创建 (#69) 2026-08-09 22:55:14 +08:00
chengma 05a54b044d feat: 统一顺运宝日期同步并记录历史 (#59) 2026-08-09 18:22:58 +08:00
chengma e0c0dac7a0 feat: 增加客户端采购员归属管理 (#54) 2026-08-09 16:02:25 +08:00
chengma 0a7db404a1 feat: 实现 Admin 首次初始化与网页登录 (#50) 2026-08-09 13:36:41 +08:00
chengma fc03388ed4 docs: 定义 Admin 登录与账号管理基线 (#49) 2026-08-09 13:12:03 +08:00
chengmaandClaude Opus 5 5e426cacf6 feat: 顺运宝货运单同步 (#46)
顺运宝模块此前是骨架,「同步」点了提示"待接入"。5195 个蝦皮商品已经
进系统,但货运单(真实订单)一条都没有,后面的规格匹配无从谈起。

按接口契约(docs/admin/08,从 4 份 HAR 还原)实现:配置、登录(界面
手工输验证码)、会话缓存到 SQLite、按日期范围增量同步、落 syb_orders。

shopee_sku_id 绝不被同步覆盖。它是规格匹配的结果,顺运宝那边根本没有
这个值(只给 11 位商品ID,蝦皮規格ID 是 12 位)。同步写进去就是写空,
把人工攒的匹配成果洗掉且不报错。它只出现在 INSERT 列清单里,不在
DO UPDATE SET 里;repository 层和 service 端到端各有一个测试守着。

增量从「上次同步日期当天」重拉,不是第二天。created 筛选粒度是日期而
last_synced_at 精确到秒,从第二天拉会漏掉当天晚些时候创建的单且不报错。
宁可重复拉(upsert 幂等)也不能漏。中途失败不更新 last_synced_at,
否则下次跳过这段区间,漏的单永远补不回来。

日期运算用 UTC+8,不是 UTC。审查时从 HAR 确认 created 是当地时间:
抓包于 2026-07-28T03:31:45Z(= 11:31 UTC+8),同一响应里 created 是
"2026-07-28 10:37:59";若它是 UTC 则等于 18:37 UTC+8,比抓包晚 7 小时,
订单创建于未来,不成立。用 UTC 算会在本地 00:00-08:00 把"今天"算成昨天,
当天早晨的单这轮拉不到。用 time.FixedZone 写死,不用 LoadLocation——
那要读系统 tzdata,Windows 默认没有,打包成 exe 会失败。

金额一律取 detail/listByStock 的值:08 §5.1 实测同一响应里 amtOrder
在列表接口是分、escrowAmount 却不是,单位不统一,取错差 100 倍。

迁移 v5 纯追加(syb_session、syb_sync_state、syb_orders.product_spec),
v1-v4 逐字未动,CheckSchema 覆盖新表新列。

会话有效性判断把「网络故障」和「明确未登录」的分类集中在 Client.do()
一处——网络抖一下就判定登出的话,验证码会弹个不停,还会丢掉有效会话。

测试全部用 httptest 假服务端,不打真实站点。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-09 11:49:13 +08:00
chengma 93beef8b36 feat: 保存并展示 PDD 店铺与价格采样信息 (#31) 2026-08-07 17:13:25 +08:00
chengmaandClaude Opus 5 e40ce5a13c fix: 商品卡在「采集中」无法恢复 (#24)
MarkCollecting 原本只在 pending/failed 时成功,而全库只有客户端提交结果
才会把 collecting 改走。客户端离线、崩溃、任务被删都是常态——一旦发生,
这个商品就永久报废,界面上没有任何入口能救,只能改数据库。

改成 collecting 超过 15 分钟视为已超时,允许重新创建采集任务。

判定在读取那一刻现算,仍是同一条原子 UPDATE,不加后台清理协程:
后台扫要处理"扫到一半客户端正好提交了"的竞态,本项目已经在并发上
栽过两次,能不引入并发就不引入。

15 分钟写成有名字的常量并注明理由:采集本身几十秒到两分钟,加上排队
等客户端来领。宁可短也不要长——采集是只读的,多采一次没有副作用,
而卡死的代价是商品永久报废。

已知取舍:超时后老任务还在队列里,客户端上线可能两个都领走、采两次。
可接受(只读,后一次覆盖前一次),已写进代码注释和 03-data-model.md,
免得后来人当成 bug 去"修"成加锁或加租约——租约和心跳是被明确移除的设计。

时间比较用字符串,依赖 NowISO 产出定宽 UTC。已在 NowISO 上加注释:
改成带时区偏移的本地时间会让这个比较静默失效,不报错但判断全错。

界面两处:超时的显示「采集中(超时)」,否则操作员盯着「采集中」
不知道它已经死了;跳过原因按正在采集/已采集/已删除分类计数,
一个都没建成时告诉操作员还要等多久。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 14:42:54 +08:00
chengmaandClaude Opus 5 d2de7331bb fix: 修复迁移被原地改写导致老库缺表 (#20)
#16 原地改写了 migration v1 而不是新增一条。Migrate 只在
user_version < 版本数时才跑,老库版本号已越过 v1,改写后的语句
永远不会重跑——程序拿着对不上的库静默启动,点到 PDD 商品页才 500。

修法:v1 逐字恢复成 7ad82b7 的原样,#16 的结构改动全部挪进 v3。
全新库也走 v1→v2→v3,与老库升级跑的是同一份 v3 代码,
不需要维护两条路径。

v3 必须认两种 user_version=2:#16 的原地改写让这个版本号对应
两种不同结构(原始 v1 建的没有 pdd_products,改写后的 v1 建的已经有)。
所以 v3 每一步先查 PRAGMA table_info / sqlite_master 看实际结构
再决定做不做,只有版本号推进是无条件的;已是最终结构的库
只推版本号,日志也照实说,不谎称"新增 pdd_products"。

旧 sku_mappings 数据丢弃并打日志:新主键需要 pdd_option_key,
那是 Go 的 OptionKey() 用 json.Marshal 算的,SQL 复现不了。
硬凑一个键出来,轻则映射静默失效,重则撞上别的规格静默买错东西——
后者正是 #16 存在的全部意义。

collecting 映射成 pending:原样保留会让 MarkCollecting 永远不成功,
那个商品再也建不了采集任务,界面上表现为按钮永远置灰且无法解开。

表重建按 SQLite 官方 12 步顺序:先建 _new 再 RENAME。
实测 ALTER TABLE RENAME TO 会自动重写别的表里指向它的外键子句,
先 RENAME 让位会把 shopee_skus 的外键改成指向一张马上被删的表。

另加两道闸:启动时 CheckSchema 缺表即拒绝启动(不是警告后继续);
admin/AGENTS.md 写死"migrations 只追加、不得修改已发布条目"。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 12:23:24 +08:00
chengmaandClaude Opus 5 998c06a2bf feat: PDD 商品数据独立成表 (#16)
原来 pdd_data 是 shopee_products 上的一个 JSON 字段,两个蝦皮商品指向
同一个 PDD 链接时会各存一份、各采一次;collect_status 描述的是 PDD 商品的
状态,却挂在蝦皮商品上,两份可能不一致。

更要紧的是 PDD 商品变动频繁(A 下架就得换 B),而 sku_mappings 只按
shopee_sku_id 做键——换商品后旧映射还在,B 恰好有同名规格但完全是另一件货
时会静默买错,事后查不出来。

改动
- 新增 pdd_products 表:id 主键 + goods_id UNIQUE + 4 个状态值(去掉
  no_link,「未填链接」改由 shopee_products.pdd_goods_id 为空表达)+
  软删除可复活
- shopee_products 去掉 pdd_data / collect_status / collect_error /
  collected_at,pdd_goods_id 改为引用
- sku_mappings 主键改为 (shopee_sku_id, pdd_goods_id),新增 pdd_option_key。
  查映射永远带上当前 PDD 商品,换商品后天然查不到旧映射,不需要删数据;
  换回原商品时旧映射直接复用
- 新增 OptionKey():用 json.Marshal 实现(Go 序列化 map 按键名排序,
  天然规范化),不自己拼字符串——规格文字里可能含 = 或 ;。
  存映射和查 SKU 必须用同一个函数,各写一遍会静默算出不同结果
- 采集结果改落 pdd_products,新增两条校验:
  返回的 goods_id 与请求不符 → 整体回滚拒绝(422),不静默存下;
  skus 为空数组 → 置 failed 而非 collected,否则界面显示"已采集"
  但数据毫无用处

实施时超出工单但必要的三处
- TaskExists 重构为 GetTaskInfo:原函数只返回蝦皮 goods_id,
  而采集结果要按 PDD goods_id 落库,不改取不到正确的键
- 复活时一并清空旧采集结果(skus_json / collect_msg / collected_at),
  否则复活后会显示"已采集"但数据是删除前的
- 删除 repository/shopee.go:两个函数签名全变且已迁到 pdd.go,留着是死代码

已验证(Go 1.23.0)
- go vet / gofmt / go test 全过,55 个测试
- 端到端补验了工单未覆盖的 HTTP 层:goods_id 不符返回 422
  COLLECT_GOODS_MISMATCH 且整体回滚(skus_json 空、任务仍 claimed、
  幂等记录 0 条);skus 为空返回 200 但状态 failed

遗留
- MarkCollecting / SoftDeletePddProduct 暂无调用方,等界面工单接上
- artifact_ref 存 diagnostics 原始 JSON,未按 client-001:artifacts/... 规范化,
  因 Client 侧尚未定义 diagnostics 结构
- 界面未实现(工单明确排除),四个页面仍为骨架

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 10:27:39 +08:00
chengma 02073eab37 docs: define idempotent Client registration contract (#12) 2026-08-06 17:21:36 +08:00