eaiadminandClaude Code
c5af5084b1
refactor: 后端仓库层收口（A5：技能/应用定义 + 用户应用中心）
D25 定的对象层三类一级对象（专员 / 技能 / 应用），A4 收了专员，这次是
技能与应用。原先是 handler 里直接 store.DB.Create/Save/Delete，现在统一走
repository，与 A1~A4 同一形状：仓库方法返回 bool，三态参数用 *bool 表达。
新增：
- repository.SkillDefinitionRepo / XAppDefinitionRepo —— List / GetByID /
GetByKey / Insert / Update / Delete
- repository.UserXAppCenterRepo —— 收藏/最近使用/自定义应用，每人一份
两处刻意偏离既有惯例，都写了理由在代码里：
1. List(state string, exposedToUser *bool) 不在仓库里定默认值。「不传 state
就只看 active」是列表接口的契约，解析 query 参数是 handler 的活；仓库只
执行过滤。exposedToUser 用 *bool 而非 bool，因为「不传该参数」与「传
false」语义不同——前者要全量，压成 bool 会把不传当成 false。
2. UserXAppCenterRepo.FindByUser 返回 (row, error) 而不是 bool。「没找到」在
这个仓库是有意义的第三态：表示该用户还没配过、调用方要新建一份。若压成
bool，一旦读取真出错（SQLite 本地锁等待是常事）就会被当成「没配过」，转而
写一份空白配置，把用户已有的收藏和最近使用抹掉。
技能与应用的读接口共用同一个仓库变量，只声明一处（skillDefinitionRepo 留在
admin_handlers.go）——两份变量持有同一仓库时，测试里覆写一份、另一份照旧，
行为会静默分叉。
A5 范围内的 store.DB 直用已清零；skills/api/office_handlers.go 里仍有 3 处，
是 store.DB.Transaction，QueryBuilder 不带事务，留着别动。
验证（tmp_vfy_a5，临时程序，验完已删）：真实路由 + 真实 HTTP，跑在数据库
副本上。55 条断言全绿，覆盖技能/应用的列表三态、按 key 取、增改删、404 路径、
用户应用中心的空配置/覆盖写/多用户隔离。
另有 14 条变异测试确认断言真的会红（13 捕获 / 1 设计上不可观测），其中
排序断言原本是假的：三条种子的插入顺序恰好也是 sort_order 升序，删掉
ORDER BY 照样绿。补了一条「sort_order 更小但插入更晚」的记录才透光。
Co-Authored-By: Claude Code <noreply@anthropic.com>
2026-09-19 02:11:00 +08:00
..
2026-09-19 01:23:51 +08:00
2026-09-19 02:11:00 +08:00
2026-09-19 01:23:51 +08:00
2026-09-17 21:32:35 +08:00
2026-09-19 01:23:51 +08:00
2026-09-19 01:23:51 +08:00