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>
This commit is contained in:
eaiadmin
@@ -0,0 +1,128 @@
|
||||
# 更名收尾说明
|
||||
|
||||
> 给正在做更名与收口的 AI。**结论：本轮命名与数据结构迁移已经完成闭环；业务代码已切到新口径，旧名只应保留在迁移逻辑、迁移测试与历史说明中。**
|
||||
|
||||
---
|
||||
|
||||
## 一、当前状态
|
||||
|
||||
代码、数据库迁移、种子与前端调用口径现在已经对齐。当前正式口径如下：
|
||||
|
||||
| 维度 | 当前正式名 |
|
||||
|---|---|
|
||||
| 任务主表 | `task_record` |
|
||||
| 任务运行表 | `task_run` |
|
||||
| 任务产物表 | `task_artifact` |
|
||||
| 我的应用中心表 | `user_xapp_center` |
|
||||
| 专员形态列 | `specialist_mode` |
|
||||
| APP 模式列 | `xapp_mode` |
|
||||
| AI 用量列 | `usage_kind` |
|
||||
| 技能对象分类列 | `object_kind` |
|
||||
|
||||
旧库升级路径也已经补齐，并挂在启动链上、位于 `AutoMigrate` 之前：
|
||||
|
||||
- `migrateLegacyTaskRuntimeSchema`
|
||||
- `migrateLegacyXAppSchema`
|
||||
- `migrateObjectModeColumns`
|
||||
- `migrateAIUsageKindColumn`
|
||||
- `migrateSkillObjectKindColumn`
|
||||
- `normalizeSkillObjectKinds`
|
||||
|
||||
这意味着：
|
||||
|
||||
- **业务代码**必须只使用新名；
|
||||
- **迁移逻辑 / 迁移测试**必须保留旧名，才能识别升级前状态。
|
||||
|
||||
---
|
||||
|
||||
## 二、此前会挂的点，现已修复
|
||||
|
||||
编译器抓不到 —— 表名列名在 Go 里是**字符串**。`go build ./...` 退出码 0，我验过。
|
||||
|
||||
### 1. `workbench_overview.go` 的旧表名字符串
|
||||
|
||||
```go
|
||||
artifactQuery := store.DB.Table("worker_artifact").
|
||||
Select("worker_artifact.id, worker_artifact.title, ... worker_task.id as task_id, ...").
|
||||
Joins("left join worker_task on worker_task.id = worker_artifact.task_id")
|
||||
...
|
||||
artifactQuery = artifactQuery.Where("worker_task.owner IN ?", ...)
|
||||
...
|
||||
artifactQuery.Order("worker_artifact.created_at DESC, worker_artifact.id DESC")
|
||||
```
|
||||
|
||||
这类引用现在已经改到新口径，不再打旧表名。
|
||||
|
||||
### 2. `specialist.go` 的旧列名统计
|
||||
|
||||
```go
|
||||
resp.DW = count("specialist_mode", "dw")
|
||||
resp.ADW = count("specialist_mode", "adw")
|
||||
```
|
||||
|
||||
这处也已经修完，不再依赖 `worker_type`。
|
||||
|
||||
---
|
||||
|
||||
## 三、绝对不要全局替换的地方
|
||||
|
||||
如果你想 `sed -i 's/worker_/task_/g'`，**这两处会被改坏**：
|
||||
|
||||
- **`db.go:117-133`** `migrateLegacyTaskRuntimeSchema` —— 迁移**必须**写旧名，否则它不知道自己要改什么。改成 `task_task` 就永远不生效。
|
||||
- **`db_migration_test.go:237-276`** —— 测试**必须**断言旧名消失，才能证明迁移真的跑了。
|
||||
|
||||
> **判据：这行代码是在「改」名字，还是在「用」名字。**
|
||||
> 改名字的地方（迁移 + 迁移的测试）保留旧名；用名字的地方（业务代码、API、前端 store、种子、文档规范）必须改新名。
|
||||
|
||||
---
|
||||
|
||||
## 四、本轮已顺手清掉的账
|
||||
|
||||
下面这些本来属于“改名后会继续扩散歧义”的源头，本轮已经补掉：
|
||||
|
||||
| 项 | 现状 |
|
||||
|---|---|---|
|
||||
| `ai_call_log.capability` | 已迁到 `usage_kind`，并补迁移与测试 |
|
||||
| `skill_definition` 中的 `assistant` 对象分类 | 已收口，正式值只保留 `specialist / skill` |
|
||||
| `eai-app-center` 本地存储 key | 前端改为一次迁移后清旧 key，不再长期兼容 |
|
||||
| `capabilitySchema` fallback | 已移除，统一为 `runtimeSchema` |
|
||||
| 工作台局部 `appKey` | 已收口为 `workspaceKey`，避免把工作台状态误导成 APP 私有状态 |
|
||||
|
||||
---
|
||||
|
||||
## 五、文档也同步收口
|
||||
|
||||
下面这些文档引用与描述也需要跟代码现实一致，当前已按此原则更新：
|
||||
|
||||
- `store/workerRuntime.js` → 现在是 `store/taskRuntime.js`
|
||||
- `api/assistant.js` / `smart_assistant.go` 这类旧主对话引用 → 现在应对齐 `api/chatMessage.js` / `chat_message.go`
|
||||
- `capability` 作为 AI 用量字段 → 现在应为 `usage_kind`
|
||||
- `assistant / specialist / skill` 作为 `object_kind` 值 → 现在应为 `specialist / skill`
|
||||
|
||||
历史方案文档如果要保留，也应明确标注：
|
||||
|
||||
1. 哪些是**历史阶段描述**
|
||||
2. 哪些是**当前规范**
|
||||
3. 哪些旧词是**迁移专用，不可再回流业务代码**
|
||||
|
||||
---
|
||||
|
||||
## 附：怎么自己复现这些结论
|
||||
|
||||
```bash
|
||||
cd eai_agentplatform/backend-go
|
||||
|
||||
# 1. 编译能过 —— 证明编译器帮不上忙
|
||||
go build ./... # 退出码 0
|
||||
|
||||
# 2. 代码里的正式表名 / 列名
|
||||
grep -n 'TableName' internal/model/task_*.go
|
||||
grep -n 'usage_kind' internal/model/ai_call_log.go internal/api/ai_usage.go
|
||||
grep -n 'object_kind' internal/model/skill_definition.go internal/api/skill_action_definition.go
|
||||
|
||||
# 3. 迁移入口都挂在启动链上
|
||||
sed -n '20,110p' internal/store/db.go
|
||||
|
||||
# 4. 迁移测试覆盖了旧库升级场景
|
||||
go test ./internal/store
|
||||
```
|
||||
Reference in New Issue
Block a user