eaiadminandClaude Code
c5af5084b1
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>