chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity
459 Commits 1 Branch 0 Tags
d64579e9b3ec81721d6e56b3e265a86a8c6d488d
Commit Graph
34 Commits
Author SHA1 Message Date
chengma d64579e9b3 feat: 增加顺运宝批量 AI 规格匹配 (#202) 2026-08-14 10:30:08 +08:00
chengma 1ba5c88604 style: 压缩顺运宝工具条 (#219) 2026-08-13 15:28:45 +08:00
chengma 8f2b3f725d feat: 支持顺运宝多订单号搜索 (#217) 2026-08-13 14:58:19 +08:00
chengma f834f6224c fix: 完善顺运宝列表紧凑布局 (#216) 2026-08-13 14:35:34 +08:00
chengma 40f62208b6 style: 优化顺运宝列表筛选与滚动 (#216) 2026-08-13 14:21:37 +08:00
chengma 8f707722ba feat: 建立全局店铺跨渠道管理 (#208 #209 #210 #211) 2026-08-13 11:15:54 +08:00
chengma 8a8fff8480 feat: 按允许店铺筛选顺运宝同步 (#196) 2026-08-12 18:48:31 +08:00
chengma 69bcf6116a feat: 支持采购任务追溯并安全重新创建 (#186) 2026-08-12 16:26:22 +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 5528b4b874 fix: 修复顺运宝采购完成状态与重复采购 (#169) 2026-08-11 18:05:27 +08:00
chengma b527204204 feat: 支持顺运宝批量创建采集任务 (#153) 2026-08-11 14:59:26 +08:00
chengma 9d4d6fc1e5 feat: 增加顺运宝店铺筛选 (#151) 2026-08-11 14:39:13 +08:00
chengma 10bb892e6c feat: 移除 Client 真实采购手工授权 (#114) 2026-08-10 18:37:35 +08:00
chengma a26219091a fix: 简化真实采购创建并恢复客户端选择 (#112) 2026-08-10 18:15:28 +08:00
chengma 66565d50cc feat: 采购价格仅展示选定规格 (#113) 2026-08-10 17:56:03 +08:00
chengma e1b32ea024 feat: 固定创建真实采购任务 (#112) 2026-08-10 17:52:48 +08:00
chengma 7106f6b024 feat: 顺运宝下一步支持单条建采购任务 (#106) 2026-08-10 16:34:55 +08:00
chengma fb2e4c4dab feat: 区分顺运宝标题与图片交互 (#105) 2026-08-10 16:33:42 +08:00
chengma 3aaa40cfe0 feat: 增加真实采购任务安全模式 (#98) 2026-08-10 15:11:38 +08:00
chengma d1165b9e17 feat: 重构顺运宝规格主链路 (#88) 2026-08-10 12:24:23 +08:00
chengma 4433e3af37 feat: 完成规格映射与采购任务创建 (#69) 2026-08-09 22:55:14 +08:00
chengma c6ef54dce1 feat: 建立顺运宝采购处理状态 (#67) 2026-08-09 22:32:19 +08:00
chengma d8a24247df fix: 同步记录弹窗改为局部刷新 (#62) 2026-08-09 21:02:28 +08:00
chengma 3fd863da64 feat: 优化顺运宝同步反馈与记录刷新 (#61) 2026-08-09 20:41:24 +08:00
chengma 05a54b044d feat: 统一顺运宝日期同步并记录历史 (#59) 2026-08-09 18:22:58 +08:00
chengma 4b5cd13807 fix: 增强顺运宝同步完整性保护 (#58) 2026-08-09 17:17:42 +08:00
chengma a18d4e67ae feat: 顺运宝支持指定日期同步 (#53) 2026-08-09 13:24:02 +08:00
chengmaandClaude Opus 5 6e6e99a5d7 fix: 进入顺运宝页面不再自动弹验证码框 (#48) 
配了 ocr_url 也会在进入页面时被拦一次输验证码。根因是 OCR 自动登录
只接在「点同步」那条路径上，而进入页面走的是另一条：
SybList → 本地会话过期 → NeedLogin=true → 模板直接弹手工输入框，
压根不调 OCR。

改成 NeedLogin 只由 login_reason 驱动——也就是操作员主动点过同步、
且自动登录确实失败时才弹。这时弹框是他预期的。

打开页面现在纯粹是看数据，不触发任何对外部系统的动作；真正会登录的
只有「同步」一个按钮。这与 Client 侧「『获取任务』是唯一会产生外部
后果的命令」是同一条原则。

会话无效时改成顶部一行提示，按 ocr_url 配没配分两种文案：配了却提示
"需要手工输入"会让人以为配置没生效；没配却提示"会自动登录"，点下去
弹出验证码框会让人莫名其妙。用 .hint 不用 .missing——这是状态说明
不是错误，红色留给「PDD 链接未填写」那种要立刻处理的。

EnsureSybSession 未改动：它只读 SQLite 缓存、本地判过期，不发外部
请求，页面渲染不会因此变慢。审查时我一度说它每次渲染都探测顺运宝，
那是错的，已核实。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 12:48:21 +08:00
chengmaandClaude Opus 5 2e686b17a4 feat: 顺运宝登录接入验证码自动识别 (#47) 
#46 的登录只有手工输验证码一条路，而会话 24 小时就过期——每天第一次
同步都得有人在场，将来也做不了定时同步。

docs/admin/08 §8 当时写死"不引入 OCR 服务"，理由是"多一个必须先启动的
东西"。那条判断基于示例脚本里的 http://127.0.0.1:8000/ocr（本机服务）。
用户提供了托管地址后前提不成立，本工单推翻它——文档里改写并保留原文，
让后来人知道这个决定变过、为什么变。

OCR 优先、手工兜底：识别成功直接登录，失败或服务不可达降级到 #46 已有的
手工弹窗，并在弹窗里说明是"已尝试 N 次"还是"服务不可用"。手工路径不删，
外部服务挂了不该让整个同步功能不可用。

识别失败也是 code:200。实测拿无文字图片探测 https://ocr.ilapage.cn/ocr
返回 {"code":200,"message":"Success","data":""}——不是错误码。所以
Recognize 只负责"这次 HTTP 调用有没有问题"，空 data 照常返回 (", nil)，
业务校验交给调用方；空 data 和长度不对收敛到同一个 len(code) != 4，
一条规则覆盖两种情况。

不合格的验证码不拿去登录：白费一次尝试，且频繁错误登录可能触发风控。
审查时变异测试发现这条没有测试守着——原测试只断言"重新取图了"和
"最终登录成功"，禁用长度校验后依然成立。已补 loginRecorder 记录每次
提交到 /am/auth/login 的 code，断言登录只被调用一次且提交的是合格的那个。

每次重试重新取图（同一张图再识别结果一样，且可能已被上次失败的登录作废）；
OCR 用独立 HTTP 客户端不带顺运宝 Cookie；验证码图片只在内存里传，不落盘。

OCR 不可达立即降级、不占用重试次数——对着连不上的地址重试 5 次，
操作员要等 50 秒才看到手工输入框，结果注定一样。

测试全部用 httptest，不打真实的 ocr.ilapage.cn 和 shunyunbaoerp.com。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-09 12:35:02 +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
chengmaandClaude Opus 5 6a7cde2ca6 feat: 顺运宝页与采集采购页搜索框收窄 (#34) 
跟上 #23 给 PDD 页做的：搜索框收到 30%，「搜索」按钮紧挨输入框。
蝦皮数据页和客户端列表页按用户要求暂不动。

复用 #23 已有的 .search-narrow 类，没有为这两页新写 CSS 规则——
多写一条就多一处将来要同步的地方。全局规则
.toolbar input[type="text"] 一字未动，它被五个页面共用。

搜索按钮靠左没有加对齐样式，是收窄的自然结果：输入框不再伸展之后，
多余空间留在按钮之后。额外加 margin-right:auto 之类会和 grow 叠加出
难预料的结果。两个表单的 grow 都保留，它负责把删除按钮顶到最右侧。

/tasks 的 placeholder 从「任务编号 / 订单号 / PDD 商品 ID」缩成
「任务编号 / 订单号 / 商品 ID」——收到 30% 之后原文案装不下，
会被截断成看不出意思的半截。缩文案而不是调回宽度。

文档把这条规则从 §5.1 提到 §3.1 表格通用规则里，三个页面都指向它。
原来写在 PDD 页那一节，另外两页要用时看不到。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:13:42 +08:00
chengmaandClaude Opus 5 6ae768463f feat: 实现客户端注册与任务领取接口 
Admin 的第一个业务功能。选它打头是因为它是穿透所有层的最薄一条竖切
（HTTP → handler/api → service → repository → SQLite → handler/web → 页面），
一个工单把分层模式立起来，后面四个模块照抄；同时它是与 Client 联调的接口，
能解锁另一条并行的工作线。

实现
- POST /tasks/claim：注册 + 领取。注册就在这里做，没有单独的注册接口，
  也没有心跳（理由见 docs/admin/04-client-api.md §3）
- 领取用条件更新 + 检查影响行数防并发，SQLite 没有 SELECT FOR UPDATE
- 客户端列表页：查询、按名称搜索、批量删除
- 在线状态是**算出来的**（last_seen_at 在 10 分钟内），数据库里没有该字段
- CSRF 中间件：双提交 Cookie，手写 82 行不引依赖。
  **只挂页面路由**，/api/v1/client/* 不能加——Client 不是浏览器、没有 Cookie
- 14 个单元测试

修复一个真 bug：PRAGMA 必须写进 DSN
并发领取测试报 database is locked (SQLITE_BUSY)。根因是
PRAGMA busy_timeout 每连接生效，而 database/sql 是连接池——
db.Exec("PRAGMA ...") 只作用于当时那条连接，池子新开的连接没执行过。
单线程正常、一并发就炸。改成 DSN 传参后并发测试跑 20 次全过。
这个坑已写进 docs/admin/03-data-model.md §2.1。

与工单的两处差异
- 去掉 name_is_custom 列后，"人工改的名字不被覆盖"改用更简单的做法：
  ON CONFLICT DO UPDATE SET 里不含 name，即只在首次注册时写入。
  效果相同，零额外字段、零迁移。已同步 04 §3
- 验收项"不向 dry_run 客户端分配真实下单任务"**未实现**：
  tasks 表没有字段标记任务是否需要真实下单。当前真实下单开关默认关闭、
  MVP 全是演练模式，暂不出问题，但开真实下单前必须补该字段，需另开工单

已验证（Go 1.23.0）
- go vet / gofmt / go test 全过，并发测试重复 20 次稳定通过
- 端到端：无任务 claim 204；插入任务后 claim 200 且 payload 含
  goods_url/goods_id/options/quantity/max_price_cent、无租约无 Admin 状态；
  重复 claim 204；缺 X-Client-Id 400；POST 无 CSRF token 403；
  列表页两台客户端在线状态与统计正确

说明：Gitea 尚未配置，本次无对应工单号。
submit_result / submit_failure 及其幂等处理留给下一个工单。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 16:56:18 +08:00
chengmaandClaude Opus 5 799ee33045 feat: 搭建 Admin 项目骨架（Go + Gin + html/template） 
可运行的骨架：四个页面能打开、数据库自动建表、给 Client 的三个接口
按契约响应。业务逻辑留 35 处 TODO(骨架)，每处标明要点和文档章节。

结构（对应 docs/admin/02-architecture.md §2/§3）
- handler/web + handler/api 分开：页面要 CSRF、出错渲染错误页；
  接口要认证、出错返回 JSON。混在一起迟早写错
- service 不认识 *gin.Context，方便不起服务器直接单测
- 只有 repository 能写 SQL
- 模板用 {{define "目录/名字"}}，一次全部 ParseFS 进来不冲突
- 模板和静态资源用 //go:embed 打进二进制

已实测（Go 1.23.0，本机验证）
- go build / go vet / gofmt 全部通过
- 单文件产物 34MB，无需 cgo
- 四个页面 + 静态资源均 200，/ 正确 302 到 /shopee
- 建表 7 张 + 索引 10 个，user_version=1，二次启动不重复建表
- claim 带 X-Client-Id 返回 204（无任务可领），
  缺 X-Client-Id 返回 400 + 契约格式的 JSON 错误体

依赖版本被 Go 1.23.0 卡死，已钉住并写进文档
- gin v1.11.0        （v1.12.0 起要求 Go >= 1.25.0）
- modernc.org/sqlite v1.38.0（v1.40.0 起要求 >= 1.24.0，v1.48.0 起 >= 1.25.0）
- excelize v2.9.1    （尚未入 go.mod，写导入功能时再加）
直接 go get 不带版本会拉到最新版并报 requires go >= 1.25.0，
所以文档里的命令一律带版本号。要升依赖就得先升 Go。

一处主动调整：迁移语句从「一个字符串装多条 SQL」改成 [][]string 逐条执行。
database/sql 的 Exec 对一次多条语句的支持因驱动而异，拆开最稳妥，
报错还能精确到第几条。

说明：Gitea 尚未配置，本次无对应工单号。
admin/testdata/ 只有 README，脱敏小样本需人工制作。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 16:33:45 +08:00