# 目录结构化迁移说明：专员 / 技能 / 应用

## 一、当前结论

目录主数据源已经从前端静态配置，切到了后端定义表 + 前端统一目录 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
后端有表，但前端继续靠配置文件拼目录
```