pj0235-eai_agentplatform

34 Commits 1 Branch 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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

Author

SHA1

Message

Date

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