EaiLab/pj0235-eai_agentplatform
11
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
37 Commits 1 Branch 0 Tags
e8aedd50d24abb0c2a2031c566cbb606ad330338
Commit Graph
5 Commits
Author SHA1 Message Date
eaiadminandClaude Code e8aedd50d2 refactor: 后端仓库层更名为数据访问层（internal/repository → internal/dal） 
「仓库层」是 repository 的直译，中文里与「代码仓库 / git 仓库」同词，
而这一层做的事就是数据访问。名字改成它实际在做的事。

改名口径（纯机械替换，无逻辑改动）：
- 包：internal/repository → internal/dal（package repository → package dal）
- 类型：XxxRepo → XxxDAO（TaskRecordDAO / SpecialistDAO / PositionDAO …）
- 变量：xxxRepo → xxxDAO
- import 路径、包限定符、日志前缀 [repository] → [dal] 同步
- 注释里的「仓库层」→「数据访问层」；core.go 包注释补上 DAL/DAO 全称

命名规范补登（AR09 是命名问题的最高依据，改了名就得回去登记）：
- AR09 §3.1 术语表新增「数据访问层 dal / DAO」一行
- AR09 §5.6 缩写表新增 DAO / dal —— 原文是「只有下表内的缩写允许使用」，
  不登记就是自己破自己的规矩
- PROJECT_STATE.md 新增 D27 记录本次更名决策

验证：全部在 db 副本上做，生产库 data/eai_agentplatform.db 未触碰。
- 等价性对照：拿 HEAD 源码 + 仅改名 造出第二棵树，两棵树各自起
  httptest 服务跑同一份探针（60 个 GET + 13 个写/回读，覆盖专员/技能/应用/
  任务/交付物/项目/岗位/考试/知识/积分/管理端只读等），逐端点比对响应体：
  73 项里 52 项字节完全一致、21 项仅运行期时间戳不同、内容差异 0。
- 探针非空：往改名后的树注入「SpecialistDAO.List 限 3 条」变异，
  /api/specialists 立刻被抓出 —— 证明上面那个 0 不是没测到。
- 暂存区自洽：把索引整个导出成源码树，go build / go vet / go test ./... 全绿。
- gofmt：因 import 排序变化而错位的 19 个文件已修；另 2 个文件（skill_definition.go、
  seed.go）的格式问题是工作区里别人的在制品带来的，未替其改动。

未纳入本次提交：工作区里正在进行中的「文生语音技能 + 技能展示色/交互卡」
（tts_handlers.go、text_to_speech/manifest.go、skillCatalog.js 等），
以及 router.go / skill_definition.go / seed.go 三个文件里属于该在制品的改动 ——
这三个文件只把「改名那一版」放进索引，工作区原样保留。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-19 09:19:21 +08:00
eaiadminandClaude Code 9157df40f3 fix: 布尔字段的「没传」与「传 false」被库默认值合并 
三处同一形状的缺陷：模型的 bool 字段带 `gorm:"default:true"`，而 GORM 在
Create 时会跳过「带 default 标签的零值字段」，于是 Go 里的 false 被当成「没填」，
改由库默认值 true 生效。对象显式设的 false 被持久层改写成 true。

- skill_definition.exposed_to_user
- xapp_definition.exposed_to_user
- position_knowledge.is_mandatory

前两处有两个方向的病症：

1. 创建接口设不出 false —— 管理员建一个「不暴露给用户」的技能/应用，
   接口返回 200、看着成功，库里存的是 true。
2. **更新接口会静默撤下** —— 前端 admin 表单根本不发 exposed_to_user
   （只读不写，见 skillCatalog.js / xappCatalog.js），而 PUT 对每个字段
   无条件覆盖，于是管理员改个标题就把技能/应用从用户目录里摘了。
   这条是线上正在发生的，比第一条更狠。

position_knowledge 同样：前端的必学/选学 el-switch 怎么拨都存成必学。

修法是拿掉那层「持久层替对象拿主意」：

- 模型去掉 `default:true`，对象说了算，仓库原样落库；
- 请求 DTO 改 *bool，把「没传」和「传 false」分开 —— 三态只存在于线上，
  `not null` 的列没有「未设置」态，所以不进模型；
- 默认值归接口契约，放 handler：新建时没传按 true（与种子数据、前端
  `exposed_to_user !== false` 口径一致），更新时没传保持原值
  （前端不发这个字段，不能因为一次无关编辑就改变可见性）。

没选的两个方案：给 Create 加 Select("*") 是把 GORM 的零值规则泄漏进 HTTP
适配层，只盖住症状还得每处创建路径都记得；模型改 *bool 则是给一个
不存在的领域状态造了个位置，还让 JSON 多出 null。

验证（tmp_vfy_fix，临时程序，验完已删）：真实路由 + 真实 HTTP，跑在数据库
副本上，39 条断言全绿。同一份断言在修复前跑出 6 条红（S1/X1/P2：显式 false
存成 true；S9/X9：更新不带该字段把 true 静默改成 false），确认断言确实在测
这个修复而不是装饰。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-19 02:17:19 +08:00
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
eaiadminandClaude Code 4f31e0c438 refactor: 后端仓库层收口（A4：任务/项目/笔记/专员/动作定义） 
把 B 档（此前尚无仓库的对象）的 api 裸查询收进仓库，api 层裸 store.DB
从 162 降到 96（口径：internal/ 下非测试 .go，不含 internal/repository/ 自身）。
新增 7 个仓库：TaskRecordRepo / TaskArtifactRepo / TaskRunRepo / ProjectRepo /
StudyNoteRepo / SpecialistRepo / ActionDefinitionRepo。

按对象补齐的方法：
- TaskRecordRepo：GetByID / GetByIDForOwners / ListBySpecialistKey / ListByOwners /
  ListByProject / CountBySpecialistKey / ClearProject / DeleteCascade
- ProjectRepo：GetByIDForOwners / ListByOwners
- StudyNoteRepo：ListByUser / GetByID
- SpecialistRepo：GetByKey / GetByID / Query / List / CountByKey
- TaskArtifactRepo / TaskRunRepo：GetByID / ListByTask
- ActionDefinitionRepo：List / GetByID / GetByKey

几条口径改由仓库单点持有，避免各处手写漂移：
- 归属过滤抽成 ownerScope：owners 为空时套恒假条件（空集），绝不退化成全表。
  specialists/runtime 的 MyTaskQuery / ProjectQuery 随之删除，调用方改用
  MyTaskOwners + 仓库方法 —— 任务与项目共用同一套归属口径。
- 「任务 + 交付物 + 运行记录三张表同事务级联删除」从 handler 收进 DeleteCascade，
  不留没有任务的孤儿交付物；删项目只解除其下任务的 project_id 归属（置 NULL，
  不是 0），不删任务本身 —— 任务是「做过的事」，删一个分组不该把它一起抹掉。
- 专员目录的 state 档位（默认 active / all 仅管理员 / system / 其它精确匹配，
  且除显式要 system 外一律排除 system 记录）收进 SpecialistRepo.List。
- GetByKey 有意不过滤 state：调用方口径不同（建任务时要能查到，对话取 prompt
  时要拒绝 inactive），口径留在调用方，仓库只负责取数。顺带把「按 key 找专员」
  从 4 个文件里各写一遍收敛成一处。
- ActionDefinitionRepo.List 不替调用方定 state 默认值 ——「不传 state 就只看
  active」是列表接口的契约，由 handler 解析 query 后传入。
- StudyNoteRepo.GetByID 不判归属，越权检查留在 handler（那里能把「不存在」与
  「不是你的」分别回成 404 / 403）。

保留未动：skills/api/office_handlers.go 里两处 store.DB.Transaction —— 运行记录
与交付物要在同一个事务里落库，QueryBuilder 不带事务，维持原样并就地注明。

验证：go build ./... 与 go vet ./... 干净，go test ./... 6 个包全绿。
另用独立验证程序走真实路由 + 真实 HTTP，对数据库副本跑 148 项断言全绿
（覆盖跨用户越权 404、空 owners 退化成空集、级联删除、解除归属置 NULL、
笔记按用户隔离、专员 key 唯一性排除自身、管理员 state=all 仍排除 system 等）。

另对其中 10 条关键语义做了变异测试：逐条注入反向实现，确认断言确实会失败，
捕获 10 / 漏掉 0。变异测试同时暴露并修掉了验证体系自身的两个漏洞：
- 「state=all 排除 system」这条规则此前没有任何断言能观察到 —— 默认档被
  state=active 挡着、system 档被 state=system 挡着，删掉实现也不会红；
- 变异驱动只跑 HTTP 断言、不跑 go test，导致针对单元测试注入的变异
  （拒绝已下线专员的 prompt）永远逮不到。

验证程序为一次性脚手架，验证完成后已删除（tmp_vfy_b/）。
原始 data/eai_agentplatform.db 全程未触碰（mtime 仍为 2026-09-17 15:14）。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-19 01:55:26 +08:00
eaiadminandClaude Code 14f303459e refactor: 后端仓库层收口（A1：课程/产品/素材）+ 收进工作区既有对象化重构 
本提交含两部分。第一部分是本轮工作；第二部分是此前一直留在工作区、
从未提交的对象化重构，与第一部分在文件上互相咬合（internal/repository
整个包都是未跟踪状态，且 api 层已有文件引用它），无法拆成两个可编译的提交。

一、仓库层收口 A1 批（本轮工作）

把 api 层手写的 store.DB 查询收进具名仓库方法，只给真正获益的对象做方法，
不机械包裹全量。本批迁移 22 处裸查询（courses.go 9 / media.go 12 / products.go 1），
新增方法：

- MediaFileRepo.ListByBind / ListForAudit / MarkExtracted
- KnowledgeChunkRepo.CountByMediaFile
- ProductRepo.GetVisibleByID

两条业务口径改由仓库单点持有，避免各处手写漂移：
「只有 approved 素材出现在课程详情」与「已停用产品不在课程详情露出」。

修掉两个真实缺陷：
- ProductRepo.GetByID 缺 Where 条件。此前 GET /api/products/{id} 对任意 id 都返回
  第一条产品、对不存在的 id 返回 200，且 PUT /api/products/{id} 会覆盖第一条产品
  —— 数据损坏级。全仓扫描确认这是唯一一处同型写法。
- ProductRepo.Delete 写 status="deleted"，而 DELETE 处理器文档与回包都声称
  "inactive"，接口在说谎；管理员用 status=all 拉列表会看到前端不认识的状态。
  已对齐为 inactive（与 CourseRepo.Delete 一致）。

删除 8 个零调用且列名不存在的死方法（一调即 SQL 报错）：
- media_file 上的 file_path / file_type / approval_status 三列并不存在，
  GetByPath / ListByType / UpdateStatus 全废
- knowledge_chunk 上的 space_id 列不存在（模型早已改为 knowledge_space_key），
  List / Total / ListBySpaceIDs / DeleteBySpace / SearchByVector 全废
取舍边界：能对当前 schema 跑通的死方法保留，跑不通的删或修。

CourseRepo.List 补齐 status=all 档（此前传给它会当作 status='all' 过滤出空列表）。
该方法此前零调用，现与产品列表语义对齐。

验证：go build ./... 与 go test ./... 全绿；另用真实 HTTP 请求验证 34 项
（课程 17 / 产品 3 / 素材 14），跑在数据库副本与独立 KB_DATA_DIR 上，
含 multipart 真上传 → 审批 → pdftotext 提取 → 分片入库的完整链路。

二、此前未提交的对象化重构（非本轮工作）

- 新增 internal/repository 仓库层、connectors、skills、specialists、xapps、jsonutil，
  model/task_record|task_run|task_artifact、api/task_runtime|action_definition|chat_message
- 删除 api/app_definition、connectors、my_app_center、notification、office_skill、
  export_docx|pptx|xlsx、official_account_* 等，随 XApp/Skill/Specialist/Connector
  可插拔打包方向（AR10/AR11）调整
- 资产目录归位：backend-go/knowledge_source → assets/knowledge/source、
  training_materials → assets/training/materials；README 内相对路径同步加深两级；
  deploy env 补 ASSET_ROOT_DIR 并改 KNOWLEDGE_SOURCE_DIR / TRAINING_MATERIALS_DIR
- 前端新增 skills/ specialists/ connectors/ xapps/ 目录与对应页面

验证：前端 npm run build 通过（7.26s）。

Co-Authored-By: Claude Code <noreply@anthropic.com>
 2026-09-19 01:23:51 +08:00