Files

T

eaiadminandClaude Code ddd2d2cbd8 docs: 对象命名规范 AR09 与标准化讨论文档入库

- 新增 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>

2026-09-17 23:38:42 +08:00

3.4 KiB

Raw Blame History

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

一、当前结论

目录主数据源已经从前端静态配置，切到了后端定义表 + 前端统一目录 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 现在由两部分组成：

后端返回的全局应用定义 app_definition
当前用户自己的 customApps

合并顺序：

全局应用定义 + 当前用户自定义应用

自定义应用不再在 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

这已经比“前端写死”前进很多，但下一阶段仍可继续拆成更显式的关系表。

六、下一步建议

如果继续往“彻底结构化”推进，建议按这个顺序：

给应用补 app_specialist_binding / app_skill_binding
给专员补显式 specialist_skill_binding
把技能的展示增强字段也收回后端 manifest
后台管理页增加应用定义管理界面

这样最终会形成统一模式：

对象定义表 + 绑定关系表 + 前端统一目录 store

而不是：

后端有表，但前端继续靠配置文件拼目录

3.4 KiB Raw Blame History