eaiadminandClaude Code
1875e7dd4c
wechat_official_account 包原先直接拿 store.DB 读写 27 处，是仓库里仅剩的最大
一块。收口后该包不再引用 store：任务/运行记录/交付物/专员四类模型用的是 A4 就
已有的仓库，只有两个包内私有模型（文章状态、热点缓存）新增了仓库。
顺带修掉一处三态混淆：原 loadOfficialAccountArticle 把「读取出错」和「还没有」
合并成同一条路（`if err == nil { return article }`，其余一律往下建新行），于是
读路径（GET workflow / 导出 / 执行步骤）上一次读取失败会去盲目 INSERT，撞上
task_id 唯一索引才失败 —— 那是运气不是设计。改成 FindByTaskID 明确返回三种
结果，读失败就报错，不再新建。
行为变化（有意，不是等价重构）：
- 热点缓存读失败、产物/运行记录查询失败，原先 web.Fail 成错误，现在按仓库层
bool 风格降级成「空」：调用方分别走不依赖热点的兜底选题路径 / 返回空时间线。
- 因此 loadFreshOfficialAccountHotspots 及其调用链上的 error 出口恒为 nil。
留着是为了不再往上传导签名改动，已在注释里写明这是行为变化。
验证（脚手架用完即删）：
- 真实请求：db 副本 + httptest 走完整路由，覆盖建任务/读工作流/改配置重置/
归属隔离（非归属人 404）/唯一键下不重复建文章行/重置后旧 run+artifact 清空。
- 仓库层直测：热点过滤（0 分、过期、跨业务域）、排序三级兜底、LIMIT 40、
同 URL 不同源必须是两行、FindByTaskID 三态、DeleteByTask 只清本任务。
- 14 个变异全部被杀死（去掉各过滤条件、ORDER BY、LIMIT、冲突键里的 source_key、
空切片保护；三态退化成两态；DeleteByTask 丢掉 task_id；归属校验改成不过滤）。
其中 M6 第一轮活下来，暴露出 R3a 用同一个 source_key、单 url 也能匹配 ——
是断言写空了，补了「同 URL 不同源必须两行」才真正测住。
Co-Authored-By: Claude Code <noreply@anthropic.com>