chengma/cmautobuy
2
0
Fork 0
Code Issues 89 Pull Requests Actions Packages Projects Releases Wiki Activity
87 Commits 1 Branch 0 Tags
e65cc2afda0153f59c73a3533a73a99054e83cc7
Commit Graph
87 Commits
This Branch
This Branch
All Branches
Author SHA1 Message Date
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
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
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 f1c2700fde fix: 校验 PDD 采集商品链接 (#28) 2026-08-07 16:14:43 +08:00
chengma 0044442f5d docs: 归档任务 #28 2026-08-07 16:13:48 +08:00
chengma 4aff22c009 feat: 实现 PDD 商品采集基础服务 (#28) 2026-08-07 16:12:39 +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 6d863a1a8a feat: 检测 Android 设备 PDD 安装状态 (#29) 2026-08-07 15:54:12 +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 57503978bd fix: 修复 Wi-Fi ADB 拔线后刷新丢失 (#27) 2026-08-07 15:12:32 +08:00
chengma ffaeb55a25 docs: 归档任务 #26 2026-08-07 14:53:57 +08:00
chengma dc9b000a36 fix: 启动时恢复已保存的 Android 设备 (#26) 2026-08-07 14:53:28 +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
chengma d478e690b6 feat: 支持 USB 设备转 Wi-Fi ADB (#25) 2026-08-07 14:42:00 +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
chengma 27a09e524c feat: 保存当前使用的 Android 设备 (#22) 2026-08-07 14:13:40 +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
chengma 45fde81b8b feat: 实现 Android 设备搜索 (#21) 2026-08-07 11:53:03 +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 ab988b39de docs: 新增多模型协作规则，回填 Gitea 约定 
CLAUDE.md（新增）
按"错了多久才会被发现"划分角色，而不是按任务难度：
设计错要几周后买错货才发现，实现错跑测试就红，复述错人一看就知道。
所以 Opus 设计和审查、Sonnet 实现、Haiku 只读查询。

关键几条：
- 工单里每条约束必须写清"在防什么"。下游没有上游的上下文，
  理由不明的约束会被当成冗余优化掉
- 实现角色不得改工单范围、不得删改看不懂的约束或测试
  （本项目测试名就是规则本身，删掉等于删掉一条业务规则）
- 审查五步，第一步是架构角色亲自跑验证，不采信报告结论
- 打回必须说清：哪条没达到、当前是什么、期望是什么
- 同一个点打回两次仍不达标，问题在工单不在实现，
  这时该改工单或自己接手，继续打回只是消耗

AGENTS.md §0 重写
Gitea 一直可用（#1~#13 在正常使用），但 §0 还留着 <待填写>，
于是"未配置"成了跳过建单的长期借口。这次 PDD 那批就是靠聊天里的
草稿直接开工的，没有工单号。

- §0.1 填上真实地址和仓库；写明工单层级靠标题前缀区分，
  不使用标签和里程碑（13 条工单实测两者均为空，也不要去建）
- §0.2 聊天里的草稿不算工单；不得默认直通，
  不得因为上次直通过就默认这次也行
- §0.3 防呆：任何地方看到本仓库的工单链接就说明 Gitea 可用，
  必须立刻回填 §0.1 并停止直通。提交信息里不得再出现
  "Gitea 未配置 / 无工单号"这类说法

两份文档边界划清：CLAUDE.md 只讲协作方式，项目规则一律指向
AGENTS.md 不复述——复述一次就走样一次。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
 2026-08-07 10:28:05 +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 fab5778049 feat: 保存并登记当前 Client (#11) 2026-08-06 17:57:49 +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