chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity
100 Commits 1 Branch 0 Tags
ccc146cfbe32495e123e889efebb163e7709d49f
Commit Graph
72 Commits
Author SHA1 Message Date
chengma d199867101 docs: 归档任务 #40 2026-08-08 10:30:49 +08:00
chengma d8505a4b2b docs: 更新任务 #39 验收修正 2026-08-08 10:30:49 +08:00
chengma 9dadac2bff feat: 滚动采集评价数量和店铺名 (#40) 2026-08-08 10:30:04 +08:00
chengma 2f83be5e40 fix: 中文显示任务当前步骤 (#39) 2026-08-08 10:29:59 +08:00
chengmaandClaude Opus 5 10b724f62a docs: 归档 #38；改正六份归档里未经验证的 Go 版本说法 
#38 归档记录了打回一次的经过（ParseSpec 两个失败分支无测试覆盖，
其中 size=="" 就是真实数据里 2 行走的分支），以及架构角色第一轮
变异打在死分支上、差点误报「测试没牙」的过程。

改正：/usr/local/go 从 2026-07-02 起一直是 1.26.5，而六份归档都写着
「架构角色亲自执行（Go 1.23.0）」——那是照项目固定版本抄的，
没有实际验证过工具链，违反 CLAUDE.md §9「说验证过必须真的跑过」。
措辞改为不宣称具体版本。已用 GOTOOLCHAIN=go1.23.0 补验，结论不变。

admin/AGENTS.md 加两条 [必须]：
- 交付前至少跑一次带 GOTOOLCHAIN=go1.23.0 的验证。开发机装的可能更新，
  Go 会默默用它编译，测过的不是要交付的那个版本。新加依赖时尤其要跑。
- 改数据库时不要只测全新库，先列出现实中存在哪些 schema 状态再一个个验（来自 #20）。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-08 09:59:34 +08:00
chengma 18770f25e1 docs: 归档任务 #39 2026-08-08 09:47:49 +08:00
chengma cb323d37ba feat: 实现 PDD 任务详情窗口 (#39) 2026-08-08 09:46:58 +08:00
chengma 6c12e058c3 docs: 归档任务 #37 2026-08-08 09:26:21 +08:00
chengma 9562da9aad fix: 蛇形遍历颜色并逐色采价 (#37) 2026-08-08 09:25:40 +08:00
chengma e08fd89c91 docs: 归档任务 #36 2026-08-07 18:14:28 +08:00
chengma e65cc2afda fix: 商品页就绪后立即进入规格面板 (#36) 2026-08-07 18:13:10 +08:00
chengma 09b27cec42 docs: 归档任务 #35 2026-08-07 17:59:20 +08:00
chengma c59b4b0d59 fix: 修复 PDD 页面误判与失败回执 (#35) 2026-08-07 17:58:30 +08:00
chengma 51c2292be1 docs: 归档任务 #32 2026-08-07 17:39:16 +08:00
chengma 2d1fdbea3f feat: 执行并提交 PDD 采集任务 (#32) 2026-08-07 17:38:29 +08:00
chengmaandClaude Opus 5 34b4b54b63 docs: 归档任务 #34，记录验收通过 
记录两处主动判断及依据：缩短 /tasks 的 placeholder（工单 [注意] 里
预先写明"真装不下就缩文案，不要把宽度调回去"）；把搜索框宽度规则从
§5.1 提到 §3.1 通用规则（原来写在 PDD 页那一节，另外两页看不到）。

未验证：浏览器实机目视、主题与缩放。用户已实机确认。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:23:49 +08:00
chengmaandClaude Opus 5 3fdab7b2a8 docs: 记录 #16 #17 #19 #20 #24 验收通过 
补上 #20 和 #24 的归档（此前只提交了代码），并把 #16 #17 #19
的状态改为验收通过。

#20 归档记录了工单中途被修改的经过：原工单写死「user_version=2 ⇒ 老结构」，
用户实测炸出 table already exists 后才发现 #16 的原地改写让这个版本号
对应两种结构，路径本来就是两条。按 CLAUDE.md §7.5 改工单而不是让实现硬凑。
也记录了变异测试第一轮漏掉两个的原因——架构角色的设计让收敛测试变成了
近乎同义反复。

#24 归档记录了四个变异全部被抓到，其中「破坏原子性判断」那个最关键：
加超时分支最容易顺手把原子抢占破坏掉。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 17:18:32 +08:00
chengma 61d8d1b263 docs: 归档任务 #31 2026-08-07 17:14:12 +08:00
chengma 93beef8b36 feat: 保存并展示 PDD 店铺与价格采样信息 (#31) 2026-08-07 17:13:25 +08:00
chengma a2fc1501c4 docs: 归档任务 #30 2026-08-07 16:43:49 +08:00
chengma 51062f4c7b feat: 领取 Admin 采集任务并保存本地 (#30) 2026-08-07 16:42:31 +08:00
chengma 107366f1f0 docs: 补充任务 #28 实现提交 2026-08-07 16:14:59 +08:00
chengma 77ec0d997b docs: 补充任务 #28 链接校验记录 2026-08-07 16:14:44 +08:00
chengma 0044442f5d docs: 归档任务 #28 2026-08-07 16:13:48 +08:00
chengma d2decc7a29 docs: 记录任务 #29 验收结果 2026-08-07 15:57:57 +08:00
chengma 52f11eecdc docs: 归档任务 #29 2026-08-07 15:55:18 +08:00
chengma a6e3fe0417 docs: 完成 Android 设备工单验收 (#21 #22 #25 #26 #27) 2026-08-07 15:20:48 +08:00
chengmaandClaude Opus 5 fbfa2fce3d docs: 归档任务 #19 
如实记录打回两次的过程，以及两次都是架构角色的检查指令给窄了：
第一次给的 grep 只覆盖「四个模块」，漏掉「四个页面」这个变体；
第二次改成直接给 6 处确切行号，并点明哪两处的「四个」是对的不许改。

未验证四项：浏览器实机交互、主题与缩放、采购任务真实创建路径
（入口尚未实现，验证用的是手工插库）、目标列规格顺序与工单示意图不同。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 15:17:32 +08:00
chengmaandClaude Opus 5 f0d7da37cf feat: 采集采购页，采集与采购统一展示 (#19) 
原来的采购任务页是骨架：var rows []gin.H 从不查库，页面永远为空；
TODO 写的还是只查 task_type = 'purchase'。所以 #18 建出来的采集任务
在界面上哪儿都看不到——用户点完「创建采集任务」只能盯着
collect_status 猜。

模块名定为「采集采购」（用户指定），直接点出这页装的是哪两类任务，
比泛称「任务」更能让人一眼知道点进去看什么。路由 /tasks 不变，
改路由会让已有书签和文档链接全失效，没有收益。

列不按类型并列——两种任务字段完全不同，并列会让采集任务行一半是空列。
改成固定列 + 一列「目标」把业务信息概括成一句话：
  采集  PDD 737116531267
  采购  SO-001 · M/黑色 · 2件 · ≤¥42.00
拼接逻辑在 service 层，模板只负责显示。

统计和列表共用同一个筛选条件拼装函数。分开写的话总有一天会忘了
给统计也加条件，数字和表格对不上，操作员会以为页面坏了。

无主任务的客户端列显示「—」。#17 之后采集任务默认无主，这列会大量为空。

详情弹窗只读，采购专有字段（数量、价格上限、目标规格）在采集任务里
整段不出现，不显示空行。复用 #18 的弹窗机制，app.js 无需改动。

顺带清掉 PDD 页加进来之后一直没跟上的模块计数：多处「四个模块/四个页面」
改成五个。其中 06-quality-security.md 那两处是验证清单，
照着做的人只会测四个页面，PDD 页永远不在回归范围里。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 15:16:05 +08:00
chengma c07fe56ac3 docs: 归档任务 #27 2026-08-07 15:13:07 +08:00
chengma ffaeb55a25 docs: 归档任务 #26 2026-08-07 14:53:57 +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
chengma ec7705fd17 docs: 归档任务 #25 2026-08-07 14:42:37 +08:00
chengmaandClaude Opus 5 bf81bad741 docs: 记录 #18 #23 验收通过 
#18 归档状态改为验收通过，补上实现与归档的提交哈希，并链到 #23。
#23 新增归档：为什么用 .search-narrow 类而不是改被五个页面共用的
.toolbar input[type="text"]；搜索按钮靠左是收窄的自然结果，没有额外样式。

两份都保留了"未验证到的部分"——浏览器实机交互、主题与缩放，
用户已实机确认后验收。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 14:19:44 +08:00
chengmaandClaude Opus 5 96267f4a18 feat: PDD 商品页工具条文案与宽度调整 (#23) 
三处：
- 「创建」改成「添加 PDD 商品」。同一条工具条上还有「创建采集任务」，
  两个都以「创建」开头，第一次用的人分不清哪个是加商品、哪个是发起采集。
- 搜索框收到 30%。
- 「搜索」按钮紧挨输入框——这是收窄的自然结果：表单里没有会伸展的
  元素之后，多余空间留在按钮之后，按钮就不会被顶到很右边。

用 .search-narrow 类而不是改 .toolbar input[type="text"]：
后者被五个页面共用（蝦皮/顺运宝/任务/客户端/PDD 各一个搜索框），
改了会把另外四页一起改掉。

用 flex 而不是 width：工具条是 flex 布局，width 会被 flex-grow 盖掉。
min-width: 160px 仍从通用规则继承，窄屏时不会缩到没法输入。

表单上的 grow 类保留，它负责把「删除」按钮顶到最右侧。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 14:15:35 +08:00
chengma c96228fb72 docs: 归档任务 #22 2026-08-07 14:14:48 +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
chengma 03f91c2488 docs: 归档任务 #21 2026-08-07 11:54:05 +08:00
chengmaandClaude Opus 5 4975c6898d docs: 归档任务 #18 
记录审查时实跑的结果：4 并发建采集任务只产生 1 条、商品标题 XSS 在
列表页和弹窗均已转义、13 规格弹窗渲染正常。

如实记录打回过程：架构角色先按 §7.3"单处笔误"例外自改 §4.3，
发现该例外不成立（全库 5 处），剩余 3 处按 §7.2 打回。

未验证四项：浏览器实机交互、主题与缩放、20+ 规格弹窗滚动、artifact_ref。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 11:27:06 +08:00
chengmaandClaude Opus 5 eb8d357f5a feat: PDD 商品页面 (#18) 
打通 Client↔Admin 闭环的一环：录入 PDD 链接 → 创建采集任务 →
客户端领走去采 → 规格和价格显示在页面上。#16 写的 MarkCollecting 和
SoftDeletePddProduct 至此才有生产调用方。

链接解析严格、不做容错兜底：goods_id 上有 UNIQUE 约束，防重全靠它。
猜一个的话同一商品会存成好几行、采好几遍，规格映射还说不清指向哪一行。
短链一律拒绝，卡域名是为了拦"粘了淘宝链接"这种失误。

创建采集任务先占状态再建任务：MarkCollecting 只在 pending/failed 时成功，
同时充当"有没有人已经在采"的判断，与建任务在同一事务里，
所以并发点多次只会建出一个任务（实测 4 并发 → 1 条）。

submit.go 的 collectedData 增加 Dimensions —— 没有它就只能按 Go 的 map
遍历，而 map 无序，同一商品每次刷新"颜色/尺码"的先后都可能变。

顺带修 #16 一处缺陷：EnsurePddProduct 复活分支清空了 skus_json 却漏了
title，导致复活后状态显示"未采集"但标题还留着旧值。

审查打回一次：清理"PDD 链接唯一的录入口"这一过期说法（全库 5 处），
以及 shopee.go 里"空 → no_link"的过期 TODO —— no_link 已在 #16
从 CHECK 约束删除，照写会直接撞约束。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 11:27:06 +08:00
chengmaandClaude Opus 5 fab20cfd2f docs: 归档任务 #16 #17 
按 AGENTS.md §9 补上两份归档。内容是审查时实跑的结果，不是复述报告。

#16 PDD 商品数据独立成表
- 记录三处超出工单但必要的决定：TaskExists → GetTaskInfo、
  采错商品做成整体回滚的硬拒绝、复活时清空旧采集结果
- 记录审查时补验的 HTTP 层端到端：422 拒绝后幂等记录 0 条
  （若残留会导致客户端重试永远拿到缓存的失败响应）
- 三项未验证：界面未实现、MarkCollecting/SoftDeletePddProduct 无生产调用方、
  artifact_ref 未规范化

#17 claim 支持领取无主任务
- 记录契约变更：§5.1 从「只分配给指定 Client」改为两种并存
- 记录优先级测试的构造方式（无主任务 created_at 更早，
  没有优先级规则时会红）
- 遗留：tasks 表缺「需要真实下单」标记，本次把无主任务开放后风险被放大，
  开启真实下单前必须补

两个工单保持 open，等用户验收。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 11:02:21 +08:00
chengmaandClaude Opus 5 dd387e3ee5 feat: claim 支持领取无主任务 (#17) 
PDD 商品页要能「创建采集任务」而不指定客户端——采集只是浏览商品页，
没有副作用，哪台设备采都一样。但原来的查询是

    WHERE assigned_client = ? AND status = 'assigned'

无主任务（assigned_client 为空 + pending）永远没人能领，建出来就是死的。

改动
- ClaimNextTask 同时查两种：指定给本机的 + 无主的
- 排序 ORDER BY (assigned_client IS NULL), priority DESC, created_at
  ——指定给本机的优先。显式分配是人为决定，应当先兑现
- 原子更新两种情况合成一条语句：对"指定给我的"写 assigned_client
  是写同一个值无副作用；对无主的，这一步就是"谁领到就标记谁"
- 表结构不用动（assigned_client 本来可空，status 已有 pending）

推翻了一条已定案的规则
Client 契约 §5.1 原写「Admin 只把任务分配给指定的 Client」，
现改为两种并存并说明各自适用场景：
- 采集任务不指定客户端
- 采购任务可指定可留空。涉及钱和账号——不同设备可能登着不同的
  拼多多账号，需要指定账号时必须显式分配，留空即接受"谁先抢到谁下单"

Client 侧对两种没有区别，不需要知道任务原来有没有主。

已验证（Go 1.23.0）
- 新增 7 个测试，全量 62 个全过
- 并发抢占用例重复 20 次稳定：8 个客户端抢同一条无主任务，
  正好 1 个拿到，且 assigned_client 记的就是那个赢家
- 既有测试未受影响，"只领分配给自己的"仍然成立

一处仍未解决的风险（已记入 #17 风险表）
tasks 表没有字段标记"该任务需要真实下单"，所以契约里
"不向 dry_run 客户端分配真实下单任务"实际无法执行。
真实下单开关关闭时不出问题，开启前必须补该字段。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 10:53:32 +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 036144ec8e docs: 记录 #11 验收通过 2026-08-06 18:00:34 +08:00
chengma 988444407a docs: 归档任务 #11 2026-08-06 17:58:13 +08:00
chengma 262f48c778 docs: 归档 Client 登记接口验收结果 (#12) 2026-08-06 17:41:19 +08:00
chengma 42d6478646 docs: 记录 Admin 热重载验收通过 (#13) 2026-08-06 17:36:22 +08:00
chengma 446510bfb9 docs: 归档 Admin 热重载任务 (#13) 2026-08-06 17:35:05 +08:00
chengma 7a6c647eda chore: 为 Admin 启动脚本增加热重载 (#13) 2026-08-06 17:34:56 +08:00
chengmaandClaude Opus 5 5a5c1f1f68 feat: 新增幂等 Client 登记接口 (#12) 
PUT /api/v1/client/registration —— 设置页点"保存"时调用，
只登记客户端，不碰任务。

为什么需要它
原设计"注册就在 claim 里做"有个真问题：设置页保存被迫调 claim，
而 claim 可能真的领到一个任务——Admin 那边已把任务标成 claimed，
Client 必须可靠落库否则任务就丢了。一个"保存设置"的动作
不该承担"领取任务并保证不丢"的责任。这违反了本项目自己的原则
（05 §1：界面上只有一个会产生外部后果的命令）。

实现
- ClientProfileRequest + Validate() 由**登记和领取共用**，
  避免两个入口的结构和校验各写一份、迟早漂移
- 校验：名称 <=50 字（按字符不按字节，中文一个字三字节）、
  supported_types 非空且只含 collect/purchase、platform 只支持 android、
  purchase_mode 必填且只允许 dry_run/live、schema_versions 均为正整数
- 非法内容返回 422 INVALID_CLIENT_PROFILE，错误消息指明具体字段
- UpsertClient 加 explicit 参数区分名称规则：
  显式登记（用户点保存）带非空名称时更新名称；
  隐式登记（claim 顺带）永不更新，否则操作员改的名字会被反复冲掉

已验证（Go 1.23.0）
- 单元测试 40 个全过，含"登记不产生任何任务副作用"的快照比对
- 端到端逐条走完手册 §5.2~5.7：重复登记记录数恒为 1；
  更新/空名称行为正确；插入任务后登记 3 次任务字段完全未变且仍可领取；
  四种非法输入均 422 且不写库；claim 不受影响

一处行为变更需注意
名称归属规则改了：原来是"Admin 操作员永远赢"，现在是"最后一次
显式操作赢"——用户在 Client 点保存会覆盖 Admin 侧改的名字。
按 #12 文档实现，已拆成三个独立测试盯住三种情况。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-06 17:31:38 +08:00