docs: remove obsolete Codex multi-agent rules
This commit is contained in:
parent
4e0701d0d0
commit
231db310bb
102
AGENTS.md
102
AGENTS.md
@ -15,89 +15,15 @@
|
||||
- 非必要不要使用兜底逻辑；优先把原生主链路和标准流程做好，只有在明确需要兼容、降级或应急，并说明原因和影响范围时，才增加兜底处理。
|
||||
- 修改后必须验证，先跑最相关的验证，再视情况扩大范围。
|
||||
- 不触碰其他应用配置，不把项目规则写入全局 `Codex` 配置。
|
||||
- 数据库写入、删除或恢复，权限与下载资格，上传、下载、转码、外部接口、批量操作，后台统计、日志、导出与审计，以及影响线上数据或用户可见结果的改动，按高风险任务核对影响范围并加强验证。
|
||||
|
||||
## 3. 项目内 Multi-agents 规则
|
||||
## 3. 界面基线
|
||||
|
||||
当任务满足以下任一条件时，优先启用内置多代理：
|
||||
- 品牌中心实际入口是 `/workspaces/dashboard/core-metrics`；`app/page.tsx` 只负责登录和权限跳转。界面改动以 `DESIGN.md`、`components/department-dashboard/DepartmentShell.tsx` 和对应页面的现状为准。
|
||||
- 品牌中心采用深色导航轨与浅色内容区；素材资产库按其独立工作壳处理。
|
||||
- 项目不挂载 `.dark` 主题类，新代码不要添加无效的 `dark:` 变体。
|
||||
|
||||
- 任务同时涉及前后端、接口与页面联动。
|
||||
- 任务涉及上线前审查、发布门禁、回归检查。
|
||||
- 任务需要同时做“功能正确性 + UI 统一性 + 发布风险”判断。
|
||||
- 任务跨越多个目录，单代理容易遗漏影响范围。
|
||||
|
||||
当用户明确写出以下任一表达时，默认必须真正进入多代理流程，而不是只解释角色定义：
|
||||
|
||||
- “按项目的审查模式处理”
|
||||
- “按项目的修复模式处理”
|
||||
- “按项目的发布模式处理”
|
||||
- “用 Multi-agents 处理”
|
||||
- “启用项目团队”
|
||||
|
||||
默认团队结构：
|
||||
|
||||
- `orchestrator`：主控代理，负责拆解任务、分配角色、汇总结论。
|
||||
- `backend`：后端代理，负责 `app/api/**`、`lib/**`、`prisma/**` 风险审查与修复建议。
|
||||
- `frontend`：前端代理，负责 `app/**` 页面层、`components/**`、`hooks/**` 交互回归。
|
||||
- `ui_auditor`：UI 统一规范审查员，负责视觉系统和组件一致性审查。
|
||||
- `release_gate`：发布守门代理，负责按证据给出可上线/有条件上线/不可上线结论。
|
||||
|
||||
对外沟通规则：
|
||||
|
||||
- 只有 `orchestrator` 直接和用户对话。
|
||||
- 其它子代理只负责内部执行、审查、汇总，不直接面向用户输出。
|
||||
- 用户默认把需求交给 `orchestrator`；由 `orchestrator` 自行决定是否派发、派给谁、何时汇总。
|
||||
- 除非用户明确要求查看子代理原始结果，否则对外只输出主控汇总后的结论。
|
||||
|
||||
按需附加角色：
|
||||
|
||||
- `explorer`：跨文件侦察员，用于快速搜集上下文、文件归属和影响范围。
|
||||
- `worker`：定点执行代理，用于在职责明确后修改小范围文件。
|
||||
|
||||
## 4. 角色分工边界
|
||||
|
||||
- `backend` 默认优先处理：上传、下载、转码、权限、批量操作、后台统计、外部接口。
|
||||
- `frontend` 默认优先处理：管理后台页面、上传组件、分享页、首页、交互状态。
|
||||
- `ui_auditor` 默认不先改代码，先审查视觉问题；只有明确要求修 UI 时才参与改动建议。
|
||||
- `release_gate` 只做汇总和判定，不直接承担业务实现。
|
||||
- `worker` 只能接收已经明确边界的子任务，避免和主代理重复改动。
|
||||
|
||||
自动派单规则：
|
||||
|
||||
- 用户只需要把任务交给 `orchestrator`，不需要手动指定团队成员。
|
||||
- `orchestrator` 根据任务类型自动决定是否启用团队，以及启用哪些角色。
|
||||
- 默认分配逻辑：
|
||||
- 单一页面或纯 UI 小改动：`frontend` + `ui_auditor`
|
||||
- 纯接口、下载、上传、转码、权限、批量操作：`backend`
|
||||
- 前后端联动：`backend` + `frontend`
|
||||
- 前后端联动且涉及视觉统一：`backend` + `frontend` + `ui_auditor`
|
||||
- 上线前审查、高风险任务、改动范围大：`backend` + `frontend` + `ui_auditor` + `release_gate`
|
||||
- 影响范围不清：先派 `explorer` 摸底，再决定后续角色
|
||||
- 用户不负责选人，角色编组由 `orchestrator` 内部完成。
|
||||
|
||||
高风险边界规则：
|
||||
|
||||
- 下面这些任务默认视为高风险：
|
||||
- 涉及数据库写入、删除、恢复、批量更新、批量删除
|
||||
- 涉及权限判断、角色判断、下载资格、管理员能力
|
||||
- 涉及上传、下载、转码、外部接口、批量操作
|
||||
- 涉及后台统计、日志、导出、审计记录
|
||||
- 涉及可能影响线上已有数据、用户可见结果或管理后台操作结果的改动
|
||||
- 高风险任务默认至少派出：`backend`
|
||||
- 如果高风险任务同时影响页面或交互，再追加：`frontend`
|
||||
- 如果高风险任务还影响视觉一致性，再追加：`ui_auditor`
|
||||
- 如果任务准备上线、范围较大、或存在不确定性，再追加：`release_gate`
|
||||
- 只要任务落入高风险边界，`orchestrator` 默认采用更保守的判断和验证策略。
|
||||
|
||||
UI 基线规则（2026-08-15 更新）：
|
||||
|
||||
- 平台主体已切换为「由壹点·品牌中心」看板，UI 统一标准以**看板首页**为基线（`app/page.tsx`）。
|
||||
- 基线语言：Zen Minimal × Future Organic 白皮书风（白纸 #fafafa / 墨字 #1a1c1d / 发丝线 / 编号索引 / 柔紫光晕点缀 / 无阴影平面化），完整令牌见 `DESIGN.md`。
|
||||
- **全站浅色单主题**：深色主题已废弃（`tailwind darkMode: 'class'` 且不挂 `.dark`，`dark:` 变体全部失效）；新代码不得再写 `dark:` 类。
|
||||
- logo 双版本：浅底表面用 `loginLogoUrl`（深色图案），黑底遗留表面用 `headerLogoUrl`。
|
||||
- `ui_auditor` 在审查其它页面时，优先对齐上述语言；遗留页面（admin/profile/share/edit 与组织架构页旧壳）按「逐页统一」节奏迁移。
|
||||
- 如果某个后台页面或特殊业务页面需要偏离基线风格，必须说明原因和影响范围。
|
||||
|
||||
## 5. 前端体验与 Impeccable 规则
|
||||
## 4. 前端体验与 Impeccable 规则
|
||||
|
||||
- 凡涉及页面、组件、样式、布局、交互、响应式、可访问性或其它前端体验的工作，默认必须优先调用并严格遵循 `$impeccable` Skill；除非用户明确要求跳过。
|
||||
- 开始修改前，先读取项目现有代码、视觉规范、组件库和产品上下文，并判断当前页面属于 `Operate`、`Persuade`、`Read` 还是 `Experience` 模式。
|
||||
@ -105,24 +31,12 @@ UI 基线规则（2026-08-15 更新）：
|
||||
- 实现后必须检查桌面端与移动端实际页面，并处理层级、间距、字体、颜色、溢出、空状态、错误状态、交互反馈、响应式和可访问性问题。
|
||||
- 交付前执行与任务匹配的 `$impeccable critique`、`$impeccable audit` 或 `$impeccable polish` 流程，并保留必要的验证证据。
|
||||
|
||||
## 6. 输出要求
|
||||
|
||||
多代理任务的输出默认按下面结构收敛：
|
||||
|
||||
- `发现的问题`
|
||||
- `严重级别 P0 / P1 / P2`
|
||||
- `影响范围`
|
||||
- `修复建议`
|
||||
- `验证清单`
|
||||
- `最终结论`
|
||||
|
||||
## 开发进度同步
|
||||
## 5. 开发进度同步
|
||||
|
||||
- 可说明的工作提交后，运行 `npm run progress:sync -- ... --apply`，按真实证据使用 `code_complete`、`testing` 或 `done`。
|
||||
- 仅同步 Git 元数据；目录匹配不唯一就停止，同步失败不得阻断 Git 与生产发布。
|
||||
|
||||
## 7. 建议先读的文档
|
||||
## 6. 建议先读的文档
|
||||
|
||||
- `README.md`
|
||||
- `docs/CODEX_MULTI_AGENTS.md`
|
||||
- `.private\gongxiangp2-完整敏感接管清单-2026-08-13.md`
|
||||
|
||||
@ -82,12 +82,12 @@ gongxiangp2/
|
||||
│ ├── organization/ # 组织管理（人员架构顶层页）
|
||||
│ ├── register/ # 注册页
|
||||
│ ├── share/ # 分享页
|
||||
│ └── page.tsx # 品牌中心看板首页（登录落点）
|
||||
│ └── page.tsx # 登录与权限跳转至实际工作面
|
||||
├── components/ # 通用组件、后台组件、上传组件、看板壳（board/）
|
||||
├── lib/ # 业务工具、上传/下载/转码/权限逻辑
|
||||
├── prisma/ # Prisma schema
|
||||
├── scripts/ # 运维/修复/清理脚本
|
||||
├── docs/ # 网络、团队协作等项目文档
|
||||
├── docs/ # 网络、接口与部署等项目文档
|
||||
├── uploads/ # 本地上传与处理中间文件
|
||||
└── README.md
|
||||
```
|
||||
@ -367,7 +367,6 @@ npm run start
|
||||
- `docs/部署规范.md`：当前部署规范
|
||||
- `docs/Git增量部署方案.md`：Git 增量部署方案
|
||||
- `docs/生产存储桶接入信息.md`：当前 MinIO / uploads 存储事实
|
||||
- `docs/CODEX_MULTI_AGENTS.md`：项目内 Codex 团队协作规则
|
||||
- `docs/外部接口文档.md`：当前对外接口说明
|
||||
|
||||
## 说明
|
||||
|
||||
@ -1,345 +0,0 @@
|
||||
# Codex Multi-agents 团队方案
|
||||
|
||||
本文件只服务当前项目，不写入全局配置。
|
||||
|
||||
## 1. 团队目标
|
||||
|
||||
把 Codex 的内置多代理能力用于本项目的协作流程，重点解决：
|
||||
|
||||
- 任务拆分更准
|
||||
- 审查范围更全
|
||||
- UI 统一性有专门审查
|
||||
- 发布前有明确门禁
|
||||
- 输出格式统一，方便复核
|
||||
|
||||
## 2. 团队结构
|
||||
|
||||
### 核心 5 角
|
||||
|
||||
1. `orchestrator`
|
||||
- 拆解任务
|
||||
- 选择需要出动的角色
|
||||
- 汇总冲突意见
|
||||
- 给最终执行顺序
|
||||
- 作为团队唯一对外接口，直接和用户沟通
|
||||
|
||||
2. `backend`
|
||||
- 审查接口、数据、存储、转码、权限、日志链路
|
||||
- 重点目录：`app/api/**`、`lib/**`、`prisma/**`
|
||||
|
||||
3. `frontend`
|
||||
- 审查页面交互、状态流、用户路径
|
||||
- 重点目录：`app/**`、`components/**`、`hooks/**`
|
||||
|
||||
4. `ui_auditor`
|
||||
- 审查颜色、字体、间距、圆角、阴影、组件状态一致性
|
||||
- 默认优先输出问题，不直接主导业务改动
|
||||
|
||||
5. `release_gate`
|
||||
- 汇总所有角色输出
|
||||
- 按证据判定：
|
||||
- `可上线`
|
||||
- `有条件上线`
|
||||
- `不可上线`
|
||||
|
||||
## 2.1 对话方式
|
||||
|
||||
- 用户默认只和 `orchestrator` 对话。
|
||||
- `orchestrator` 负责理解需求、追问缺口、决定是否派发子代理。
|
||||
- 子代理默认不直接对用户说话，只向 `orchestrator` 回传结果。
|
||||
- `orchestrator` 对外输出的内容应是整理后的统一结论，而不是把子代理原文直接堆给用户。
|
||||
|
||||
### 辅助 2 角
|
||||
|
||||
6. `explorer`
|
||||
- 适合先做跨文件摸底、找影响范围、找入口文件
|
||||
- 不承担最终结论
|
||||
|
||||
7. `worker`
|
||||
- 适合在边界明确后，处理单一子任务的修改
|
||||
- 不能替代主控做总调度
|
||||
|
||||
## 3. 三种工作模式
|
||||
|
||||
### A. 审查模式
|
||||
|
||||
适用场景：
|
||||
|
||||
- 上线前检查
|
||||
- 大改前摸底
|
||||
- 不确定该不该动代码
|
||||
|
||||
推荐编组：
|
||||
|
||||
- `orchestrator`
|
||||
- `backend`
|
||||
- `frontend`
|
||||
- `ui_auditor`
|
||||
- `release_gate`
|
||||
|
||||
### B. 修复模式
|
||||
|
||||
适用场景：
|
||||
|
||||
- 已经确定问题所在，需要定点修改
|
||||
- 既要修功能，也要看 UI 回归
|
||||
|
||||
推荐编组：
|
||||
|
||||
- `orchestrator`
|
||||
- `explorer`
|
||||
- `backend` 或 `frontend`
|
||||
- `worker`
|
||||
- 需要时追加 `ui_auditor`
|
||||
|
||||
### C. 发布模式
|
||||
|
||||
适用场景：
|
||||
|
||||
- 发版前最终门禁
|
||||
- 需要形成可复核结论
|
||||
|
||||
推荐编组：
|
||||
|
||||
- `orchestrator`
|
||||
- `backend`
|
||||
- `frontend`
|
||||
- `ui_auditor`
|
||||
- `release_gate`
|
||||
|
||||
## 4. 调度规则
|
||||
|
||||
本项目默认采用“用户只对 `orchestrator` 提需求，由 `orchestrator` 自动派单”的方式。
|
||||
|
||||
### 自动派单总原则
|
||||
|
||||
- 用户不需要手动指定角色。
|
||||
- `orchestrator` 负责判断是否启用团队，以及需要出动哪些角色。
|
||||
- 如果任务很小，允许不启用完整团队。
|
||||
- 如果任务高风险、影响范围大、或准备上线，优先扩大编组。
|
||||
|
||||
### 仅后端类任务
|
||||
|
||||
例如：
|
||||
|
||||
- 下载
|
||||
- 上传
|
||||
- 转码
|
||||
- 批量删除
|
||||
- 外部接口
|
||||
- 管理后台统计接口
|
||||
|
||||
推荐角色：
|
||||
|
||||
- `orchestrator`
|
||||
- `backend`
|
||||
- 必要时加 `release_gate`
|
||||
|
||||
### 仅前端类任务
|
||||
|
||||
例如：
|
||||
|
||||
- 首页
|
||||
- 分享页
|
||||
- 上传弹窗
|
||||
- 管理后台页面
|
||||
|
||||
推荐角色：
|
||||
|
||||
- `orchestrator`
|
||||
- `frontend`
|
||||
- `ui_auditor`
|
||||
|
||||
### 全链路联动任务
|
||||
|
||||
例如：
|
||||
|
||||
- 上传后展示异常
|
||||
- 后台统计与页面表现同时改
|
||||
- 下载接口和前端下载入口一起变
|
||||
|
||||
推荐角色：
|
||||
|
||||
- `orchestrator`
|
||||
- `backend`
|
||||
- `frontend`
|
||||
- `ui_auditor`
|
||||
- `release_gate`
|
||||
|
||||
### 影响范围不清的任务
|
||||
|
||||
例如：
|
||||
|
||||
- 不确定问题在前端还是后端
|
||||
- 不确定影响几个目录
|
||||
- 只是看到现象，还没看到根因
|
||||
|
||||
推荐角色：
|
||||
|
||||
- `orchestrator`
|
||||
- `explorer`
|
||||
|
||||
说明：
|
||||
|
||||
- 先摸底，再扩编
|
||||
- 避免一开始全员出动造成重复劳动
|
||||
|
||||
## 5. 每个角色的标准输出
|
||||
|
||||
### `orchestrator`
|
||||
|
||||
- 任务目标
|
||||
- 角色分派
|
||||
- 依赖关系
|
||||
- 验收标准
|
||||
- 风险分级
|
||||
|
||||
### `backend`
|
||||
|
||||
- 发现的问题
|
||||
- P0 / P1 / P2
|
||||
- 影响接口或数据范围
|
||||
- 修复建议
|
||||
- 验证清单
|
||||
|
||||
### `frontend`
|
||||
|
||||
- 发现的问题
|
||||
- P0 / P1 / P2
|
||||
- 影响页面和交互路径
|
||||
- 修复建议
|
||||
- 验证清单
|
||||
|
||||
### `ui_auditor`
|
||||
|
||||
- 视觉一致性问题
|
||||
- 组件一致性问题
|
||||
- 页面级问题
|
||||
- 必须统一项
|
||||
- 可迭代项
|
||||
|
||||
### `release_gate`
|
||||
|
||||
- 门禁汇总
|
||||
- 是否可上线
|
||||
- 阻塞项
|
||||
- 上线前必须完成项
|
||||
- 上线后观察项
|
||||
|
||||
## 6. 发布判定规则
|
||||
|
||||
- 任一 `P0` 未关闭：`不可上线`
|
||||
- 关键链路未验证：`不可上线`
|
||||
- 只有可控 `P1`，且有回滚方案：`有条件上线`
|
||||
- 无阻塞项，验证通过：`可上线`
|
||||
|
||||
## 6.2 默认门禁严格度
|
||||
|
||||
- 当前项目默认采用“偏严格”的发布门禁。
|
||||
- 原因：
|
||||
- 项目已经在线上运行
|
||||
- 任务经常跨前后端和 UI
|
||||
- 用户默认不是程序员，应该尽量减少“技术上能上线、实际很难判断风险”的情况
|
||||
|
||||
默认解释如下：
|
||||
|
||||
- `严格拦截`
|
||||
- 只要有 `P0`
|
||||
- 只要关键链路没验证
|
||||
- 只要没有明确回滚路径
|
||||
- 结论就是 `不可上线`
|
||||
|
||||
- `有限放行`
|
||||
- 如果只有少量 `P1`
|
||||
- 且不影响核心链路
|
||||
- 且有明确回滚方案和后续跟踪项
|
||||
- 可以给 `有条件上线`
|
||||
|
||||
- `正常放行`
|
||||
- 没有 `P0`
|
||||
- 核心链路验证通过
|
||||
- UI 没有明显破坏统一性的问题
|
||||
- 就给 `可上线`
|
||||
|
||||
## 6.3 高风险边界
|
||||
|
||||
当前项目默认把下面这些改动视为高风险：
|
||||
|
||||
- 数据类
|
||||
- 数据库写入
|
||||
- 批量更新
|
||||
- 批量删除
|
||||
- 数据恢复
|
||||
- 会影响现有线上数据结果的逻辑调整
|
||||
|
||||
- 权限类
|
||||
- 登录后权限判断
|
||||
- 角色判断
|
||||
- 管理员能力
|
||||
- 下载资格
|
||||
- 外部接口访问控制
|
||||
|
||||
- 批量与资源类
|
||||
- 上传
|
||||
- 下载
|
||||
- 转码
|
||||
- 批量操作
|
||||
- 外部接口
|
||||
- 后台导出
|
||||
- 操作日志与审计记录
|
||||
|
||||
对应规则：
|
||||
|
||||
- 命中高风险边界时，`orchestrator` 默认至少启用 `backend`
|
||||
- 同时影响页面体验时，追加 `frontend`
|
||||
- 同时影响视觉统一时，追加 `ui_auditor`
|
||||
- 需要上线判断、范围大、或风险不清时，追加 `release_gate`
|
||||
- 高风险任务默认采用更保守的门禁和验证要求
|
||||
|
||||
## 6.1 UI 基线
|
||||
|
||||
- 当前项目的 UI 统一标准默认以首页为基线。
|
||||
- 基线文件：`app/page.tsx`
|
||||
- `ui_auditor` 审查其它页面时，默认对齐以下维度：
|
||||
- 视觉语言
|
||||
- 主按钮样式
|
||||
- 标题与信息层级
|
||||
- 间距与留白节奏
|
||||
- loading / empty / error / success 状态反馈
|
||||
- 如果某个页面因为管理后台密度、特殊业务流程或设备限制必须偏离首页风格，需要单独说明理由，不默认视为统一标准。
|
||||
|
||||
## 7. 推荐用法
|
||||
|
||||
进入本项目后，如果要启用内置多代理，建议以当前项目目录启动，并在任务里明确写出采用哪种模式。
|
||||
|
||||
当用户明确写出下面这些触发语时，`orchestrator` 默认应真正派发子代理，而不是只停留在口头说明：
|
||||
|
||||
- “按项目的审查模式处理这次改动”
|
||||
- “按项目的修复模式处理这次任务”
|
||||
- “按项目的发布模式做门禁”
|
||||
- “用项目团队处理”
|
||||
- “启用 Multi-agents”
|
||||
|
||||
示例表达：
|
||||
|
||||
- “按项目的审查模式处理这次改动。”
|
||||
- “按项目的修复模式先拆任务，再定点修改。”
|
||||
- “按项目的发布模式做一次完整门禁。”
|
||||
|
||||
如果当前 `Codex` 会话未启用多代理能力，可在启动时临时开启，不写入全局：
|
||||
|
||||
`codex --enable multi_agent -C "D:\AI Code\gongxiangp2"`
|
||||
|
||||
## 8. 目前还不能自动决定的四件事
|
||||
|
||||
这些问题我已经预留好团队位置，但还需要你和我一个一个定：
|
||||
|
||||
1. UI 统一标准到底以哪套页面为基线
|
||||
2. 发布门禁的阈值要多严格
|
||||
3. 哪些任务必须全队出动，哪些只需要局部编组
|
||||
4. 数据、权限、批量操作的高风险边界怎么划
|
||||
|
||||
当前已确定第 1 项：UI 基线默认以首页为准。
|
||||
当前已确定第 2 项：发布门禁默认采用偏严格标准。
|
||||
当前已确定第 3 项：用户只和 `orchestrator` 对话，由 `orchestrator` 自动派单。
|
||||
当前已确定第 4 项：数据、权限、批量操作、资源链路相关改动默认视为高风险。
|
||||
Loading…
x
Reference in New Issue
Block a user