eaiadminandClaude Code
ddd2d2cbd8
- 新增 docs/02_Architecture/AR09_Object_Naming_Standard.md（规范性文件，非设计稿）： 十节结构 —— 原理 / 判据 / 对象术语表 / 五层命名规范 / 命名模式库 / 如何检查（人工五问 + 6 个机器守卫）/ 如何修复（迁移顺序 + 改名六步法）/ 现状问题登记（逐条带 file:line）/ 反例库 / 修订记录。 核心判断：名称即契约，改名前先查已靠名字建立的协议表 - 02_Architecture/README.md 登记 AR09，并说明其规范性定位（约束新增代码， 与 TOP_CODING_RULES.md 的 G03 配套），与 AR01–AR08 设计稿区别 - 收入本轮讨论与调研文档：对象命名标准化清单、对象标准化与解耦总则、 六层架构与三对象建设重点阶段性复盘、目录结构化迁移说明、 AionUi 对照分析两篇 Co-Authored-By: Claude Code <noreply@anthropic.com>
148 lines
3.4 KiB
Markdown
148 lines
3.4 KiB
Markdown
# 目录结构化迁移说明：专员 / 技能 / 应用
|
|
|
|
## 一、当前结论
|
|
|
|
目录主数据源已经从前端静态配置，切到了后端定义表 + 前端统一目录 store。
|
|
|
|
现在的三层关系是：
|
|
|
|
- **专员**：后端 `specialist` 表
|
|
- **技能**：后端 `skill_definition` 表
|
|
- **应用**：后端 `app_definition` 表
|
|
|
|
前端不再把这些对象的主目录写死在页面里，而是通过统一 store 消费：
|
|
|
|
- `frontend/src/store/specialistCatalog.js`
|
|
- `frontend/src/store/skillCatalog.js`
|
|
- `frontend/src/store/appCatalog.js`
|
|
|
|
---
|
|
|
|
## 二、后端结构
|
|
|
|
### 1. 专员
|
|
|
|
- 表：`specialist`
|
|
- 模型：`backend-go/internal/model/specialist.go`
|
|
- 公开接口：
|
|
- `GET /api/specialists`
|
|
- `GET /api/specialists/by-key/:key`
|
|
|
|
### 2. 技能
|
|
|
|
- 表：`skill_definition`
|
|
- 模型：`backend-go/internal/model/skill_definition.go`
|
|
- 公开接口：
|
|
- `GET /api/skills`
|
|
- `GET /api/skills/by-key/:key`
|
|
|
|
### 3. 应用
|
|
|
|
- 表：`app_definition`
|
|
- 模型：`backend-go/internal/model/app_definition.go`
|
|
- 公开接口：
|
|
- `GET /api/apps`
|
|
- `GET /api/apps/by-key/:key`
|
|
|
|
### 4. 管理端维护接口
|
|
|
|
管理员现在可以直接维护三类目录：
|
|
|
|
- `POST/PUT/DELETE /api/specialists`
|
|
- `POST/PUT/DELETE /api/skills`
|
|
- `POST/PUT/DELETE /api/apps`
|
|
|
|
---
|
|
|
|
## 三、前端结构
|
|
|
|
### 1. 统一目录 store
|
|
|
|
- 专员：`specialistCatalog`
|
|
- 技能：`skillCatalog`
|
|
- 应用：`appCatalog`
|
|
|
|
页面和组件只负责渲染与交互，不再作为真目录源。
|
|
|
|
### 2. 应用目录的合并规则
|
|
|
|
`appCatalog` 现在由两部分组成：
|
|
|
|
1. 后端返回的全局应用定义 `app_definition`
|
|
2. 当前用户自己的 `customApps`
|
|
|
|
合并顺序：
|
|
|
|
```text
|
|
全局应用定义 + 当前用户自定义应用
|
|
```
|
|
|
|
自定义应用不再在 `appCenter` 里自己生成正式编号，
|
|
而是在 `appCatalog` 合并时，按照当前全局应用数量动态补：
|
|
|
|
- `display_code`
|
|
- `eailogic_code`
|
|
|
|
这样应用编号不会再依赖静态常量。
|
|
|
|
---
|
|
|
|
## 四、已经移除的旧模式
|
|
|
|
以下模式已经不再作为生产目录源：
|
|
|
|
- `frontend/src/config/productizedApps.js`
|
|
- 页面内手写 `baseCatalogApps`
|
|
- 页面内手写 `productizedApps + customApps` 拼装
|
|
- `appCenter` 基于静态总数常量生成应用编号
|
|
|
|
其中 `productizedApps.js` 已删除。
|
|
|
|
---
|
|
|
|
## 五、当前剩余约束
|
|
|
|
虽然主目录已经结构化，但仍有两类“过渡型依赖”存在：
|
|
|
|
### 1. 技能展示增强字段
|
|
|
|
`skillCatalog` 仍会参考前端静态技能定义补充：
|
|
|
|
- `roleCard`
|
|
- `workflowSchema`
|
|
- `artifactSchema`
|
|
- `capabilityTags`
|
|
|
|
原因是后端 `skill_definition` 目前还没有完整覆盖这些前端展示字段。
|
|
|
|
### 2. 专员规则与技能绑定
|
|
|
|
专员本身已经后端化，但规则正文与绑定关系仍主要通过后端 seed 初始化：
|
|
|
|
- `seed_specialist_rules.go`
|
|
|
|
这已经比“前端写死”前进很多，但下一阶段仍可继续拆成更显式的关系表。
|
|
|
|
---
|
|
|
|
## 六、下一步建议
|
|
|
|
如果继续往“彻底结构化”推进，建议按这个顺序：
|
|
|
|
1. 给应用补 `app_specialist_binding / app_skill_binding`
|
|
2. 给专员补显式 `specialist_skill_binding`
|
|
3. 把技能的展示增强字段也收回后端 manifest
|
|
4. 后台管理页增加应用定义管理界面
|
|
|
|
这样最终会形成统一模式：
|
|
|
|
```text
|
|
对象定义表 + 绑定关系表 + 前端统一目录 store
|
|
```
|
|
|
|
而不是：
|
|
|
|
```text
|
|
后端有表，但前端继续靠配置文件拼目录
|
|
```
|