diff --git a/.agent/AGENT_ARCHITECTURE_V2.md b/.agent/AGENT_ARCHITECTURE_V2.md index 9d1b6f9..3e9a008 100644 --- a/.agent/AGENT_ARCHITECTURE_V2.md +++ b/.agent/AGENT_ARCHITECTURE_V2.md @@ -163,6 +163,8 @@ graph BT ├── business/ # 💼 业务域 │ ├── order-management/ │ └── product-management/ + ├── design/ # 🎨 设计规范 + │ └── visual-standards/ ├── tech-stack/ # 🛠️ 技术栈 │ └── umijs-procomponents/ └── engineering/ # 🛡️ 通用工程 diff --git a/.agent/NO_API_HALLUCINATION_UPDATE.md b/.agent/NO_API_HALLUCINATION_UPDATE.md deleted file mode 100644 index a0a5a33..0000000 --- a/.agent/NO_API_HALLUCINATION_UPDATE.md +++ /dev/null @@ -1,404 +0,0 @@ -# 禁止 API 幻觉规则更新总结 - -## 📋 更新概览 - -为所有开发类 Agent 添加了**禁止 API 幻觉、强制使用 Context7 查询文档**的关键规则，防止使用过时或不存在的 API。 - -**更新时间**: 2026-02-14 -**规则级别**: ⚠️ **CRITICAL（关键）** -**影响 Agent**: Frontend Expert, Umi Pro - ---- - -## ✅ 已更新的配置文件 - -### OpenCode Agent 配置 - -| 文件 | 状态 | 更新内容 | -| --- | --- | --- | -| `.opencode/agents/frontend.md` | ✅ 已更新 | 添加"禁止 API 幻觉"强制规则 | -| `.opencode/agents/umi-pro.md` | ✅ 已更新 | 扩展 Context7 部分为强制查询规则 | - -### Antigravity Agent 配置（建议同步） - -| 文件 | 状态 | 建议操作 | -| ---------------------------------------- | ----------- | ------------------ | -| `.agent/frontend_expert_agent_prompt.md` | 🔄 建议更新 | 添加相同规则 | -| `.agent/umi_pro_agent_prompt.md` | 🔄 建议更新 | 扩展 Context7 规则 | - ---- - -## 🎯 核心规则内容 - -### 禁止行为 ❌ - -**绝对禁止**凭记忆或猜测组件框架的 API/Props 定义 - -- ❌ 凭记忆假设某个 prop 存在 -- ❌ 使用未经验证的 API -- ❌ 基于"我记得好像有这个 API"的实现 - -### 强制要求 ✅ - -- ✅ **必须使用 Context7** 查询官方文档 -- ✅ 实现前先调用 `mcp_context7_query-docs` -- ✅ 根据查询结果使用**确切的** props 和方法 -- ✅ 验证 API 的存在性和正确用法 - ---- - -## 📊 适用范围 - -### 组件库 - -- **ProComponents**: `ProTable`, `ProForm`, `QueryFilter`, `ModalForm` 等 -- **Ant Design**: 所有 antd 组件 -- **Custom Components**: 任何项目特定组件 - -### Framework API - -- **UmiJS**: `useRequest`, `useModel`, `access`, `useIntl` 等 -- **React**: Hooks, Context 等 -- **第三方库**: 任何外部依赖 - ---- - -## 🔍 错误模式示例 - -### 示例 1: ProTable API 幻觉 - -```tsx -// ❌ 错误：凭记忆猜测 API - {}} // 实际不存在，应该是 request - data={data} // 实际不存在，数据通过 request 获取 - loading={loading} // request 自动处理 loading -/> -``` - -### 示例 2: QueryFilter Props 幻觉 - -```tsx -// ❌ 错误：猜测 props - -``` - -### 示例 3: useRequest Options 幻觉 - -```tsx -// ❌ 错误：猜测 options -const { data } = useRequest(fetchData, { - auto: true, // 实际应该是 ready - cache: true, // 不是这个 prop - onError: () => {}, // 正确 -}); -``` - ---- - -## ✅ 正确模式示例 - -### 示例 1: ProTable 正确用法 - -```tsx -// ✅ 正确：查询 Context7 后使用 -// Query: "ProTable API props request columns" -// Result: 使用 request prop，columns 定义列 - - { - const data = await fetchList(params); - return { - data: data.list, - success: true, - total: data.total, - }; - }} -/> -``` - -### 示例 2: QueryFilter 正确用法 - -```tsx -// ✅ 正确：查询文档确认 API -// Query: "QueryFilter props onFinish layout" -// Result: 使用 onFinish 和 layout props - - { - console.log('Search values:', values); - }} - onReset={() => { - console.log('Reset'); - }} -> - - - -``` - -### 示例 3: useRequest 正确用法 - -```tsx -// ✅ 正确：查询确认 options -// Query: "useRequest options manual ready onSuccess" -// Result: 确认可用的 options - -const { data, loading, run } = useRequest(fetchData, { - manual: true, // 确认存在 - ready: !!userId, // 确认存在 (不是 auto) - onSuccess: (data) => { - message.success('Success'); - }, -}); -``` - ---- - -## 🔄 正确工作流程 - -### 步骤 1: 确定组件/API - -``` -需求：实现一个带搜索的商品列表页 -组件：ProTable + QueryFilter -``` - -### 步骤 2: 查询 Context7 - -```typescript -// 查询 ProTable API -(await mcp_context7_query) - - docs({ - libraryId: '/ant-design/pro-components', - query: 'ProTable props request columns pagination', - }); - -// 查询 QueryFilter API -(await mcp_context7_query) - - docs({ - libraryId: '/ant-design/pro-components', - query: 'QueryFilter onFinish layout props', - }); -``` - -### 步骤 3: 阅读查询结果 - -``` -ProTable 文档结果： -- request: (params) => Promise<{data, success, total}> -- columns: ColumnsType[] -- pagination: 分页配置 - -QueryFilter 文档结果： -- onFinish: (values) => void -- layout: 'horizontal' | 'vertical' | 'inline' -- onReset: () => void -``` - -### 步骤 4: 使用确切 API 实现 - -```tsx - setSearchParams(values)} -> - {/* 搜索字段 */} - - - { - const res = await fetchProducts({...params, ...searchParams}); - return { - data: res.list, - success: true, - total: res.total, - }; - }} -/> -``` - ---- - -## 📝 Context7 查询技巧 - -### 查询模式 - -```typescript -// 模式 1: 查询特定组件 API -mcp_context7_query - - docs({ - libraryId: '/ant-design/pro-components', - query: '[组件名] API props [关注的 prop]', - }); - -// 模式 2: 查询使用示例 -mcp_context7_query - - docs({ - libraryId: '/ant-design/pro-components', - query: '[组件名] example usage [场景]', - }); - -// 模式 3: 查询特定功能 -mcp_context7_query - - docs({ - libraryId: '/umijs/umi', - query: '[Hook/API 名] options configuration', - }); -``` - -### 常用 Library ID - -| 框架/库 | Library ID | -| ------------- | ---------------------------- | -| ProComponents | `/ant-design/pro-components` | -| Ant Design | `/ant-design/ant-design` | -| UmiJS | `/umijs/umi` | -| React | `/facebook/react` | -| Axios | `/axios/axios` | - ---- - -## ⚠️ 常见陷阱 - -### 陷阱 1: 混淆相似 API - -```tsx -// ❌ 容易混淆 - // 不存在 - // ✅ 正确 - - // 不存在 - // ✅ 正确 -``` - -### 陷阱 2: TypeScript 类型推断错误 - -```tsx -// ❌ 假设类型 -const { data } = useRequest(fetch); // 假设返回类型 - -// ✅ 查询文档确认 -// 文档：useRequest 返回 {data, loading, error, run, ...} -const { data, loading, error } = useRequest(fetch); -``` - -### 陷阱 3: 版本差异 - -```tsx -// ❌ 使用旧版本 API（可能已废弃） - // Ant Design 4 - // ✅ Ant Design 5 - -// 必须通过 Context7 查询当前版本的 API -``` - ---- - -## 🎓 执行建议 - -### 对开发 Agent - -1. **实施前必查**：任何组件使用前都查询文档 -2. **不确定即查询**：即使"记得"API，也要验证 -3. **记录查询结果**：在代码注释中说明 API 来源 - -### 对 Code Reviewer - -1. **检查查询记录**：验证是否查询过文档 -2. **验证 API 正确性**：对照文档检查 props -3. **标记可疑用法**：发现未经验证的 API 使用 - -### 对 QA Tester - -1. **关注运行时错误**：props 不匹配会导致警告 -2. **检查 Console**：查看 React/Ant Design 警告 -3. **报告 API 问题**：发现后反馈给开发 Agent - ---- - -## 📚 配置文件具体变更 - -### Frontend Expert (`frontend.md`) - -**位置**: 核心指令 - 第 3 条 - -**添加内容**: - -```markdown -### 3. ⚠️ 禁止 API 幻觉（强制规则） - -**CRITICAL**: 使用组件框架时，**绝对禁止**凭记忆或猜测 API/Props 定义 - -#### 强制要求 - -- ✅ **必须使用 Context7** 查询官方文档 -- ✅ 实现前先调用 `mcp_context7_query-docs` 查询组件 API -- ✅ 根据查询结果使用**确切的** props 和方法 -- ❌ **绝对禁止**凭记忆假设某个 prop 存在 -- ❌ **绝对禁止**使用未经验证的 API -``` - -### Umi Pro (`umi-pro.md`) - -**位置**: 核心理念 - 第 7 条 - -**更新内容**: - -```markdown -### 7. ⚠️ 禁止 API 幻觉 - Context7 强制查询（关键规则） - -**CRITICAL**: 使用组件框架时，**绝对禁止**凭记忆或猜测 API/Props 定义 - -[包含完整的强制要求、适用范围、查询示例等] -``` - ---- - -## ✅ 预期效果 - -### 减少的问题 - -1. ❌ Props 不匹配导致的 React 警告 -2. ❌ 使用不存在的 API 导致的运行时错误 -3. ❌ 因版本差异导致的功能失效 -4. ❌ TypeScript 类型错误 - -### 提升的质量 - -1. ✅ 代码更符合官方最佳实践 -2. ✅ API 使用正确且最新 -3. ✅ 减少调试时间 -4. ✅ 提高代码可维护性 - ---- - -## 📊 影响统计 - -### 适用场景覆盖率 - -- **ProComponents 使用**: 100% -- **Ant Design 组件**: 100% -- **UmiJS API**: 100% -- **React Hooks**: 100% -- **第三方库**: 100% - -### 强制执行级别 - -- **Frontend Expert**: CRITICAL -- **Umi Pro**: CRITICAL -- **Planning**: 建议（规划阶段提醒） -- **Code Spec**: 必须检查（审查时验证） - ---- - -**更新完成时间**: 2026-02-14 -**规则重要性**: ⚠️ CRITICAL -**强制执行**: 是 diff --git a/.agent/PROCOMPONENTS_PADDING_UPDATE.md b/.agent/PROCOMPONENTS_PADDING_UPDATE.md deleted file mode 100644 index 45d1cad..0000000 --- a/.agent/PROCOMPONENTS_PADDING_UPDATE.md +++ /dev/null @@ -1,281 +0,0 @@ -# ProComponents 双内边距规范更新总结 - -## 📋 更新概览 - -已成功为所有 Agent 配置文件添加 **ProComponents 优先使用规范**，明确禁止在 ProComponents 外层包裹 Card 组件以避免双内边距问题。 - -**更新时间**: 2026-02-14 -**影响范围**: 所有 Agent 配置文件（OpenCode 和 Antigravity） - ---- - -## ✅ 更新的配置文件 - -### OpenCode Agent 配置（`.opencode/agents/`） - -| Agent 文件 | 状态 | 更新内容 | -| -------------- | --------- | ----------------------------------------- | -| `team.md` | ✅ 已更新 | 添加 ProComponents 优先原则和双内边距警告 | -| `planning.md` | ✅ 已更新 | 更新搜索区域优化规则 | -| `frontend.md` | ✅ 已更新 | 添加避免双内边距的视觉标准 | -| `umi-pro.md` | ✅ 已更新 | 更新搜索区域优化规范 | -| `code-spec.md` | ✅ 已更新 | 添加双内边距检查项到审计清单 | -| `qa-tester.md` | ✅ 已更新 | 添加双内边距问题检查到测试清单 | - -### Antigravity Agent 配置（`.agent/`） - -| Agent 文件 | 状态 | 更新内容 | -| ---------------------------------- | --------- | --------------------------- | -| `agent_team_coordinator_prompt.md` | ✅ 已更新 | 添加 ProComponents 优先原则 | -| `frontend_expert_agent_prompt.md` | ✅ 已更新 | 更新视觉标准规范 | -| `umi_pro_agent_prompt.md` | ✅ 已更新 | 更新搜索区域优化 | -| `code_spec_expert_prompt.md` | ✅ 已更新 | 添加双内边距检查到审计清单 | -| `qa_tester_agent_prompt.md` | ✅ 已更新 | 添加双内边距问题检查 | - -**总计**: 11 个配置文件全部更新 ✅ - ---- - -## 🎯 核心规范内容 - -### 问题描述 - -使用 ProTable、QueryFilter、ProForm 等 ProComponents 时，如果在外层包裹 Card 组件，会导致**双重内边距**问题，因为 ProComponents 自带卡片样式和内边距。 - -### 错误模式 ❌ - -```tsx -// 错误：外层包裹 Card - - - - - - - - - - - -``` - -### 正确模式 ✅ - -```tsx -// 正确：直接使用 ProComponents，通过 style 调整间距 - - - - - -``` - ---- - -## 📝 各 Agent 具体更新 - -### 1. Team Coordinator（主 Agent） - -**位置**: UI/UX Standards -**新增**: - -- ProComponents 优先原则（标记为 **CRITICAL**） -- 明确禁止外层包裹 Card -- 提供错误和正确示例 -- 解释双内边距问题原因 - -### 2. Planning Agent - -**位置**: 搜索区域优化 -**更新**: - -- 明确要求直接使用 QueryFilter 和 ProTable -- 添加避免双内边距的说明 -- 更新间距调整方式 - -### 3. Frontend Expert - -**位置**: 视觉标准 - 搜索表格 -**新增**: - -- ⚠️ 避免双内边距专项说明 -- 详细的错误和正确对比示例 - -### 4. Umi Pro Agent - -**位置**: 搜索区域优化 -**新增**: - -- ⚠️ 避免双内边距规范 -- ProComponents 使用最佳实践 - -### 5. Code Spec Expert - -**位置**: - -1. 搜索区域规范 -2. 代码审计清单 - -**新增**: - -- 双内边距检查项（标记为重要检查项） -- 错误模式识别 -- 修复建议 -- 审计清单中添加专项检查 - -### 6. QA Tester - -**位置**: "Separated Card" 模式合规性 -**新增**: - -- 双内边距问题检查（标记为高优先级） -- 检查方法和错误模式 -- 视觉后果说明 -- 修复建议 - ---- - -## 🔍 检查点对比 - -### 更新前 - -- ✅ 检查 ProComponents 使用 -- ✅ 检查样式 Token -- ❌ **未检查**双内边距问题 - -### 更新后 - -- ✅ 检查 ProComponents 使用 -- ✅ 检查样式 Token -- ✅ **新增**双内边距问题检查 -- ✅ **新增**Card 包裹检测 -- ✅ **新增**修复建议 - ---- - -## 📊 影响范围统计 - -### 受影响的组件 - -- `ProTable` - 表格组件 -- `QueryFilter` - 搜索过滤器 -- `LightFilter` - 轻量过滤器 -- `ProForm` - 表单组件 -- `ModalForm` - 模态表单 - -### 受影响的场景 - -1. **列表页面**: 搜索 + 表格组合 -2. **数据管理**: 过滤器 + 数据展示 -3. **表单页面**: 各类表单场景 - ---- - -## ⚠️ 重要性级别 - -### Code Spec Expert - -- 列为**关键检查项** -- 必须在代码审查时检查 -- 发现问题需提供修复建议 - -### QA Tester - -- 列为**高优先级检查** -- 视觉测试时必须验证 -- 影响用户体验评分 - -### Team Coordinator - -- 标记为 **CRITICAL** -- 属于架构级别规范 -- 影响整体代码质量 - ---- - -## 🎓 培训要点 - -### 开发人员需要了解 - -1. ProComponents 自带卡片样式 -2. 不要外层包裹 Card -3. 使用 style prop 调整间距 -4. Token 优先原则 - -### Code Reviewer 需要检查 - -1. 扫描 `` 包裹 ProComponents 的代码 -2. 验证间距调整方式 -3. 提供修复建议 - -### QA 测试人员需要验证 - -1. 视觉检查内边距是否过大 -2. 对比设计稿确认间距 -3. 截图记录问题 - ---- - -## 🛠️ 工具支持建议 - -### ESLint 规则（可选） - -可以考虑添加自定义 ESLint 规则检测： - -```javascript -// 伪代码示例 -// 检测 模式 -``` - -### 代码审查清单 - -在 Pull Request 模板中添加： - -- [ ] 确认 ProComponents 未被 Card 包裹 -- [ ] 验证间距使用 style={{ marginBottom: token.marginLG }} - ---- - -## 📚 相关文档 - -- [OpenCode Agent 配置](./.opencode/) -- [Antigravity Agent 配置](./.agent/) -- [Ant Design ProComponents 文档](https://procomponents.ant.design/) -- [Design Tokens 使用指南](./.agent/skills/ant-design-skill/SKILL.md) - ---- - -## ✨ 后续建议 - -### 1. 代码库审计 - -建议对现有代码库进行一次全面审计，查找并修复已存在的双内边距问题： - -```bash -# 搜索可能的问题代码 -grep -r "" src/pages/ | grep "ProTable\|QueryFilter\|ProForm" -``` - -### 2. 文档更新 - -在团队 Wiki 中添加： - -- ProComponents 使用最佳实践 -- 常见错误模式和修复方法 -- 视觉效果对比图 - -### 3. 设计规范同步 - -与设计团队同步此规范，确保设计稿中不出现双重卡片设计。 - ---- - -**更新完成时间**: 2026-02-14 -**更新执行者**: Antigravity Team -**规范版本**: v1.1 diff --git a/.agent/TEAM_AGENT_RESPONSIBILITY_UPDATE.md b/.agent/TEAM_AGENT_RESPONSIBILITY_UPDATE.md deleted file mode 100644 index 1f15c76..0000000 --- a/.agent/TEAM_AGENT_RESPONSIBILITY_UPDATE.md +++ /dev/null @@ -1,320 +0,0 @@ -# 主 Agent 职责边界规则更新 - -## 📋 更新概览 - -为主 Agent（Team Coordinator）添加了**禁止自行修复问题**的关键规则，明确职责边界和协作流程。 - -**更新时间**: 2026-02-14 -**影响 Agent**: Team Coordinator (主 Agent) -**规则级别**: ⚠️ **CRITICAL（关键）** - ---- - -## ✅ 更新的配置文件 - -| 文件 | 路径 | 状态 | -| --- | --- | --- | -| OpenCode Team Agent | `.opencode/agents/team.md` | ✅ 已更新 | -| Antigravity Team Coordinator | `.agent/agent_team_coordinator_prompt.md` | ✅ 已更新 | - ---- - -## 🎯 新增规则内容 - -### 核心规则 - -**❌ 禁止主 Agent 自行修复问题** - -当收到 @code-spec 或 @qa-tester 的问题报告后，主 Agent **禁止**自己动手修改代码。 - -### 正确流程 - -``` -1. 收到问题报告（来自 @code-spec 或 @qa-tester） - ↓ -2. 主 Agent 汇总和分析问题 - ↓ -3. 将问题委派给相应的开发 Agent - - 前端问题 → @frontend - - 服务/数据问题 → @umi-pro - ↓ -4. 等待开发 Agent 修复完成 - ↓ -5. 重新调用审查/测试 Agent 验证 - - @code-spec (代码审查) - - @qa-tester (功能测试) - ↓ -6. 确认问题解决后才继续 -``` - -### 错误做法 ❌ - -```markdown -## 错误示例 - -@code-spec: 发现问题 - ProTable 外层有 Card 包裹 - -Team Agent (错误): [直接调用 replace_file_content 修改代码] -``` - -### 正确做法 ✅ - -```markdown -## 正确示例 - -@code-spec: 发现问题 - ProTable 外层有 Card 包裹 - -Team Agent (正确): 收到审查报告，发现双内边距问题。现在委派 @frontend 修复此问题。 - -@frontend: [收到任务，修改代码] - -Team Agent: @frontend 已完成修复。现在重新调用 @code-spec 进行验证。 -``` - ---- - -## 💡 规则原因 - -### 1. 职责分离 - -- **主 Agent**: 协调者、项目经理 -- **子 Agent**: 专业领域执行者 - -### 2. 质量保证 - -- 确保专业的事由专业的 Agent 完成 -- 避免主 Agent 跨界导致质量下降 -- 保持代码风格和实现方式的一致性 - -### 3. 流程规范 - -- 明确的责任链 -- 清晰的问题解决路径 -- 可追溯的修复历史 - -### 4. 团队协作 - -- 保持 Agent 间的协作模式 -- 避免主 Agent "大包大揽" -- 确保每个 Agent 发挥专长 - ---- - -## 📊 适用场景 - -### 场景 1: 代码审查发现问题 - -``` -@code-spec 报告: -- 发现双内边距问题 -- i18n 缺少 defaultMessage -- TypeScript 使用了 any - -主 Agent 处理: -✅ 汇总问题列表 -✅ 分析影响范围 -✅ 委派 @frontend 或 @umi-pro 修复 -❌ 不要自己修改代码 -``` - -### 场景 2: QA 测试发现 Bug - -``` -@qa-tester 报告: -- 按钮点击无响应 -- 加载状态未显示 -- 国际化显示错误 - -主 Agent 处理: -✅ 分析 bug 性质 -✅ 判断由哪个 Agent 修复 -✅ 委派相应的开发 Agent -❌ 不要自己修改代码 -``` - -### 场景 3: 用户反馈问题 - -``` -用户反馈: -"页面显示不正常" - -主 Agent 处理: -✅ 理解问题描述 -✅ 调用 @qa-tester 诊断问题 -✅ 根据诊断结果委派修复 -❌ 不要直接修改代码 -``` - ---- - -## 🔄 修复循环流程 - -``` -┌─────────────────────────────────────┐ -│ 1. 实施阶段 │ -│ (@frontend / @umi-pro) │ -└───────────┬─────────────────────────┘ - │ - ↓ -┌─────────────────────────────────────┐ -│ 2. 审查阶段 │ -│ (@code-spec) │ -└───────────┬─────────────────────────┘ - │ - 发现问题？ - │ - ↓ Yes -┌─────────────────────────────────────┐ -│ 3. 主 Agent 汇总问题 │ -│ (Team Coordinator) │ -│ ❌ 不要自己修复 │ -└───────────┬─────────────────────────┘ - │ - ↓ -┌─────────────────────────────────────┐ -│ 4. 委派修复 │ -│ → @frontend / @umi-pro │ -└───────────┬─────────────────────────┘ - │ - ↓ -┌─────────────────────────────────────┐ -│ 5. 重新审查 │ -│ (@code-spec) │ -└───────────┬─────────────────────────┘ - │ - 仍有问题？ - │ - ↓ No -┌─────────────────────────────────────┐ -│ 6. 测试阶段 │ -│ (@qa-tester) │ -└───────────┬─────────────────────────┘ - │ - 发现 Bug？ - │ - ↓ No -┌─────────────────────────────────────┐ -│ 7. 任务完成 │ -│ (Team Coordinator) │ -└─────────────────────────────────────┘ -``` - ---- - -## 🎓 主 Agent 的正确行为 - -### ✅ 应该做的事 - -1. **协调**：调用合适的子 Agent -2. **汇总**：整合各 Agent 的输出 -3. **决策**：何时进入下一阶段 -4. **沟通**：向用户解释进度和问题 -5. **把控**：确保整体质量符合标准 - -### ❌ 不应该做的事 - -1. **直接编码**：不要调用 write_to_file 或 replace_file_content（除非是创建文档） -2. **越俎代庖**：不要替代专业 Agent 的工作 -3. **跳过流程**：不要绕过审查或测试环节 -4. **擅自决定**：不要在检查点后不经用户确认就继续 - ---- - -## 📝 配置文件具体变更 - -### OpenCode (`team.md`) - -**位置**: 禁止事项部分 - -**添加内容**: - -```markdown -- ❌ **不要自行修复问题** ⚠️ **关键规则**: - - 当收到 @code-spec 或 @qa-tester 的问题报告后 - - **禁止**主 Agent 自己动手修改代码 - - **必须**将问题反馈给相应的开发 Agent (@frontend 或 @umi-pro) 重新修复 - - **原因**: 主 Agent 职责是协调，不是执行。确保专业的事由专业的 Agent 完成 - - **流程**: 汇总问题 → 交给开发 Agent → 等待修复完成 → 重新审查/测试 -``` - -### Antigravity (`agent_team_coordinator_prompt.md`) - -**位置**: Prohibited Actions 部分（新增） - -**添加内容**: - -```markdown -- ❌ **Do NOT fix issues yourself** ⚠️ **CRITICAL RULE**: - - When receiving problem reports from @[/code-spec] or @[/qa] - - **FORBIDDEN**: Team Coordinator fixing code directly - - **REQUIRED**: Delegate issues to appropriate development agents (@[/fe] or @[/umi]) for re-implementation - - **Reason**: Team Coordinator's role is coordination, not execution. Ensure professionals handle professional work - - **Process**: Summarize issues → Delegate to dev agents → Wait for fixes → Re-audit/Re-test -``` - ---- - -## 🔍 验证清单 - -团队成员和用户在使用时应验证： - -- [ ] 主 Agent 收到问题报告后，是否汇总问题 -- [ ] 主 Agent 是否委派给相应的开发 Agent -- [ ] 主 Agent 是否等待修复完成 -- [ ] 主 Agent 是否重新调用审查/测试 -- [ ] 主 Agent 是否避免直接修改代码 - ---- - -## ⚠️ 特殊情况 - -### 例外场景（允许主 Agent 编辑） - -以下情况下主 Agent 可以使用 write_to_file： - -1. **创建文档**： - - - 项目文档 - - README - - 配置说明 - -2. **非代码文件**： - - - Markdown 文档 - - JSON 配置（非代码逻辑） - -3. **用户明确要求**： - - 用户直接要求主 Agent 创建某个文档 - -### 绝对禁止（主 Agent 不得编辑） - -1. **源代码文件**： - - - `.tsx`, `.ts`, `.jsx`, `.js` - - 组件文件 - - 服务文件 - - Mock 文件 - -2. **样式文件**： - - - `.css`, `.less`, `.scss` - - Style modules - -3. **配置代码**： - - 路由配置 - - 状态管理 - - API 配置 - ---- - -## 📚 相关文档 - -- [Team Agent 配置](./.opencode/agents/team.md) -- [Team Coordinator 配置](./.agent/agent_team_coordinator_prompt.md) -- [Agent 协作流程](./README.md) - ---- - -**更新完成时间**: 2026-02-14 -**规则重要性**: ⚠️ CRITICAL -**强制执行**: 是 diff --git a/.agent/TEAM_V2_VERIFICATION_PLAN.md b/.agent/TEAM_V2_VERIFICATION_PLAN.md deleted file mode 100644 index 348e311..0000000 --- a/.agent/TEAM_V2_VERIFICATION_PLAN.md +++ /dev/null @@ -1,262 +0,0 @@ -# Team V2 升级验证计划 - -## 📋 验证目标 - -验证升级后的灵活 Agent 团队架构是否正常工作，确认： - -1. PM 能正确扫描和分类 Skill -2. PM 能按照注入协议将 Skill 摘要下发给子 Agent -3. 子 Agent 能消费 Skill 摘要并遵循约束 -4. 子 Agent 能按统一格式汇报结果且不自行终止 -5. 技术栈特有规范（如双内边距、搜索区域）没有因迁移而丢失 -6. Agent 足够通用，不包含技术栈 hardcode - ---- - -## 🧪 测试用例 - -### 测试 1: PM 阶段 0 — Skill 扫描与分类 - -**操作**: 使用 `/team` 启动一个需求，例如： - -> "开发一个商品管理列表页，包含搜索、新增、编辑、删除功能" - -**验证清单**: - -- [ ] PM 是否扫描了 `.opencode/skills/` 目录？ -- [ ] PM 是否正确识别了**三类 Skill**？ - - [ ] 技术栈 Skill: `tech-stack/umijs-procomponents` - - [ ] 业务 Skill: `business/product-management` - - [ ] 通用 Skill: `engineering/code-quality` -- [ ] PM 是否读取了匹配到的 Skill 内容？ -- [ ] PM 是否在任务启动输出中列出了匹配的 Skill 清单？ - -**预期输出**: - -```markdown -## 🚀 任务启动 - -**需求**: 商品管理列表页 **Skill 匹配**: umijs-procomponents + product-management + code-quality **团队组装**: @planning + @frontend + @code-spec + @qa-tester -``` - ---- - -### 测试 2: PM → @planning 的 Skill 注入 - -**操作**: 观察 PM 委派 @planning 时的指令内容 - -**验证清单**: - -- [ ] 委派指令中是否包含 **📦 技术栈要点** 章节？ - - [ ] 是否提到 UmiJS 4 + ProComponents？ - - [ ] 是否提到搜索区域规范（< 4 字段 vs >= 4 字段）？ - - [ ] 是否提到零 CSS / Token 样式？ - - [ ] 是否提到双内边距禁止？ -- [ ] 委派指令中是否包含 **🔧 质量红线** 章节？ - - [ ] 是否提到禁止 any？ - - [ ] 是否提到 500 行限制？ - - [ ] 是否提到安全规范（XSS、金额精度）？ -- [ ] 委派指令中是否包含 **📋 业务要点** 章节？ - - [ ] 是否包含 product-management Skill 中的业务规则？ -- [ ] PM 是否直接写入了 Skill 内容（而非让 @planning 自己去读文件）？ - ---- - -### 测试 3: @planning 的 Skill 消费与规划 - -**操作**: 检查 @planning 输出的规划文档 - -**验证清单**: - -- [ ] 规划是否遵循了技术栈 Skill 的约束？ - - [ ] 是否规划使用 ProTable 做列表？ - - [ ] 是否规划了搜索区域模式（根据字段数量选择方案）？ - - [ ] 是否规划了 src/services/ + mock/ + data.d.ts 结构？ -- [ ] 规划是否融合了业务 Skill？ - - [ ] 是否包含商品数据模型？ - - [ ] 是否考虑了业务状态和约束？ -- [ ] @planning 是否调用了 superpowers 进行产品细化？ -- [ ] @planning 是否使用了 Context7 验证技术方案？ -- [ ] 输出是否使用了**子 Agent 协议的统一格式**？ - - [ ] 是否以 `## 📋 规划结果摘要` 开头？ - - [ ] 是否包含"下一步行动建议"？ - - [ ] 是否结尾有"请主 Agent 审阅"？ -- [ ] @planning 是否自行结束了会话？（**不应该**） - ---- - -### 测试 4: PM → @frontend 的 Skill 注入 - -**操作**: 用户确认规划后，观察 PM 委派 @frontend 时的指令 - -**验证清单**: - -- [ ] 委派指令中是否包含完整的技术栈摘要？ - - [ ] ProComponents 组件选型？ - - [ ] 禁止双内边距？ - - [ ] 零 CSS + Token？ - - [ ] 服务层目录结构？ - - [ ] i18n 规范？ -- [ ] 委派指令中是否包含业务摘要？ -- [ ] 委派指令中是否包含质量红线？ - ---- - -### 测试 5: @frontend 的红线执行 - -**操作**: 检查 @frontend 的实施过程 - -**验证清单**: - -- [ ] @frontend 是否在编码前调用了 Context7 查询组件 API？ -- [ ] @frontend 是否遵循了注入的技术栈约束？ - - [ ] 使用 ProTable 而非手写表格？ - - [ ] 使用 Token 样式而非 CSS 文件？ - - [ ] ProComponents 外层没有包裹 Card？ - - [ ] i18n 使用了 intl.formatMessage + defaultMessage？ -- [ ] @frontend 是否遵循了质量红线？ - - [ ] 无 any 类型？ - - [ ] 单文件不超过 500 行？ - - [ ] 服务层隔离？ -- [ ] 输出是否使用了统一格式 `## 🚀 实施结果摘要`？ -- [ ] @frontend 是否自行结束了会话？（**不应该**） - ---- - -### 测试 6: @code-spec 的动态审计 - -**操作**: 观察 PM 委派 @code-spec 时的审计过程 - -**验证清单**: - -- [ ] PM 委派指令中是否附带了技术栈审计要点？ -- [ ] @code-spec 是否执行了**固定审计项**？ - - [ ] any 类型检查？ - - [ ] 500 行限制？ - - [ ] XSS 安全？ - - [ ] 服务层隔离？ - - [ ] 加载状态？ - - [ ] 防重复点击？ -- [ ] @code-spec 是否执行了**Skill 驱动审计项**？ - - [ ] ProComponents 双内边距检查？ - - [ ] Token 样式检查？ - - [ ] i18n 完整性？ -- [ ] 输出是否使用了统一格式 `## ✅ 代码审查结果摘要`？ - - [ ] 是否有优先级分级（P0/P1/P2）？ -- [ ] @code-spec 是否自行结束了会话？（**不应该**） - ---- - -### 测试 7: @qa-tester 的动态测试 - -**操作**: 观察 PM 委派 @qa-tester 时的测试过程 - -**验证清单**: - -- [ ] PM 委派指令中是否附带了技术栈测试要点？ -- [ ] @qa-tester 是否执行了**固定测试项**？ - - [ ] 功能完整性（按钮、表单、CRUD）？ - - [ ] 控制台零错误？ - - [ ] 加载状态？ - - [ ] 防重复提交？ -- [ ] @qa-tester 是否执行了**Skill 驱动测试项**？ - - [ ] i18n 双语验证？ - - [ ] 样式合规（如 ProComponents 布局）？ -- [ ] 输出是否使用了统一格式 `## 🧪 QA 测试结果摘要`？ -- [ ] @qa-tester 是否自行结束了会话？（**不应该**） -- [ ] @qa-tester 是否尝试修改代码？（**不应该**） - ---- - -### 测试 8: PM 闭环与终止控制 - -**操作**: 观察整个流程的 PM 行为 - -**验证清单**: - -- [ ] PM 是否在 @planning 完成后停下等待用户确认？ -- [ ] PM 是否在收到子 Agent 汇报后检查了后续阶段？ -- [ ] 如果 @code-spec 发现问题： - - [ ] PM 是否回派给 @frontend 修复（而非自己修）？ - - [ ] 修复后是否重新走 @code-spec → @qa-tester 闭环？ -- [ ] 如果 @qa-tester 发现问题： - - [ ] PM 是否回派给 @frontend（而非自己修）？ - - [ ] 修复后是否从 @code-spec 重新走起？ -- [ ] PM 是否在所有阶段通过后才宣布完成？ -- [ ] 最终交付是否使用了 `## ✅ 任务完成` 格式？ - ---- - -### 测试 9: 通用性验证（负面测试） - -**操作**: 检查新 Agent 文件中是否有技术栈 hardcode 残留 - -**验证方法**（命令行）: - -```bash -# 在 Agent 文件中搜索不应出现的技术栈关键词 -grep -n 'UmiJS\|ProComponents\|ProTable\|QueryFilter\|Ant Design\|antd\|useRequest\|src/services\|data\.d\.ts\|零 CSS\|formatMessage' \ - .opencode/agents/frontend.md \ - .opencode/agents/code-spec.md \ - .opencode/agents/qa-tester.md \ - .opencode/agents/planning.md -``` - -**预期**: 命令应该无输出（无匹配）。如果有匹配，说明还有技术栈 hardcode 残留。 - -**注意**: `team.md` 中允许出现这些词，因为 PM 需要知道如何识别技术栈。但 4 个子 Agent 中不应有。 - ---- - -### 测试 10: Figma 集成验证（可选） - -**操作**: 使用带 Figma 链接的需求启动 `/team`，例如： - -> "根据这个 Figma 开发订单管理页面 https://figma.com/design/xxx/yyy?node-id=1-2" - -**验证清单**: - -- [ ] PM 阶段 0 是否调用了 Figma MCP 提取产品信息？ -- [ ] PM 是否将 Figma 产品信息和设计规范注入给 @planning？ -- [ ] @planning 是否在规划中融合了 Figma 信息？ -- [ ] @frontend 是否根据 Figma 设计稿进行高保真还原？ -- [ ] @qa-tester 是否执行了 Figma 视觉还原对比？ - ---- - -## 📊 验证结果记录模板 - -| 测试编号 | 测试名称 | 结果 | 发现的问题 | -| :------- | :------------------------- | :--: | :--------- | -| 1 | PM Skill 扫描与分类 | ⬜ | | -| 2 | PM → @planning Skill 注入 | ⬜ | | -| 3 | @planning Skill 消费与规划 | ⬜ | | -| 4 | PM → @frontend Skill 注入 | ⬜ | | -| 5 | @frontend 红线执行 | ⬜ | | -| 6 | @code-spec 动态审计 | ⬜ | | -| 7 | @qa-tester 动态测试 | ⬜ | | -| 8 | PM 闭环与终止控制 | ⬜ | | -| 9 | 通用性验证（负面测试） | ⬜ | | -| 10 | Figma 集成（可选） | ⬜ | | - ---- - -## 🚀 建议的验证需求 - -用以下需求启动一次完整的 `/team` 流程即可覆盖测试 1-8： - -> **"开发一个商品管理列表页。要求：** > **1. 包含商品名称、价格、状态、创建时间等字段的搜索和列表** > **2. 支持新增、编辑（弹窗表单）、删除操作** > **3. 价格需要支持分到元的转换显示** > **4. 支持中英双语"** - -这个需求会触发： - -- ✅ 技术栈 Skill 匹配（umijs-procomponents） -- ✅ 业务 Skill 匹配（product-management） -- ✅ 通用 Skill 加载（code-quality） -- ✅ 搜索区域模式判断（≥ 4 字段 → QueryFilter） -- ✅ 金额精度安全规则 -- ✅ i18n 双语验证 -- ✅ 完整的 规划 → 实施 → 审计 → 测试 流程 - ---- - -**验证完成标准**: 测试 1-9 全部通过（测试 10 可选）。 diff --git a/.agent/agent_team_coordinator_prompt.md b/.agent/agent_team_coordinator_prompt.md index 74d3dbb..9f04d33 100644 --- a/.agent/agent_team_coordinator_prompt.md +++ b/.agent/agent_team_coordinator_prompt.md @@ -161,6 +161,10 @@ PM 在委派任何子 Agent 时，**必须**使用以下结构化格式注入 Sk [逐条列出技术栈 Skill 中的关键约束，每条必须是具体可执行的] +## 🎨 视觉标准（from design/visual-standards） + +[逐条列出视觉规范：主题色、布局、按钮样式、Zero CSS 策略] + ## 🔧 质量红线（from code-quality） [逐条列出质量规范的关键约束] @@ -169,7 +173,7 @@ PM 在委派任何子 Agent 时，**必须**使用以下结构化格式注入 Sk [逐条列出业务规则要点] -## 🎨 设计规范（from Figma）（如有） +## 🖌️ 设计原稿（from Figma）（如有） [列出 Figma 提取的设计约束] @@ -189,10 +193,11 @@ PM 在委派任何子 Agent 时，**必须**使用以下结构化格式注入 Sk > 用户: "根据这个 Figma 开发订单管理页面" 主 Agent 阶段 0 输出: > -> - **技术栈要点** (from umijs-procomponents): UmiJS 4 + ProComponents, 零 CSS, ProTable 列表, 禁止双内边距... -> - **质量红线** (from code-quality): 禁止 any, 500 行限制, 金额用分... -> - **业务要点** (from order-management): 订单状态机、金额用分、30 分钟超时取消 -> - **设计规范** (from Figma): 列表含 8 列、有 3 个筛选条件、主色 #1890FF +> - **技术栈要点** (from umijs-procomponents): UmiJS 4, ProComponents, 列表需配置 request... +> - **视觉标准** (from visual-standards): 主题色 #fa541c, 行操作使用 Text 按钮, ModalForm 垂直布局... +> - **质量红线** (from code-quality): 禁止 any, 500 行限制... +> - **业务要点** (from order-management): 订单状态机... +> - **设计原稿** (from Figma): 列表含 8 列... ### 阶段 1: 架构规划 (@planning) @@ -257,6 +262,7 @@ PM 在委派任何子 Agent 时，**必须**使用以下结构化格式注入 Sk 4. **修复闭环**: - 如果 @code-spec 或 @qa-tester 报告问题，**必须**将具体问题分配回开发 Agent 进行修复。 - 修复后，**必须**重新经过审查和测试，形成完整闭环。 +5. **文档维护 (日志安全)**: 任何更新 `.doc/project_record.md` 的操作，**必须**先读取原内容并采用**追加模式**。**禁止**直接 overwrite 导致历史丢失。 ### 内部思维链 diff --git a/.agent/skills/design/visual-standards/SKILL.md b/.agent/skills/design/visual-standards/SKILL.md new file mode 100644 index 0000000..2dd6925 --- /dev/null +++ b/.agent/skills/design/visual-standards/SKILL.md @@ -0,0 +1,85 @@ +--- +name: visual-standards +description: 中后台应用视觉规范（Ant Design Pro 标准）。涵盖主题色、布局、排版、间距系统及操作区规范。所有 UI 界面必须严格遵循。 +--- + +# 视觉设计与交互规范 (Design System) + +## 1. 原则与理念 + +- **Ant Design Only**: 严格遵循 Ant Design 5.0+ 默认视觉风格。 +- **High Density**: 适用于信息密集型中后台场景，优先紧凑布局。 +- **Consistency**: 同类操作必须使用相同的视觉表现。 + +## 2. 主题配置 (Theme) + +全站统一采用 **Volcano (火山红)** 主题色，强调操作引导性与警示性。 + +```json +{ + "token": { + "colorPrimary": "#fa541c", + "colorInfo": "#fa541c", + "wireframe": false + } +} +``` + +## 3. 布局规范 (Layout) + +### 3.1 页面容器 + +- 所有页面必须使用 `PageContainer` 包裹。 +- **禁止双内边距**: 严禁在 `ProTable`、`ProForm` 外层再包裹 `Card`。ProComponents 自带卡片样式。 +- **错误示例**: `` ❌ + +### 3.2 搜索筛选区 + +- **< 4 个字段**: 使用 ProTable 内置 Search (LightFilter 风格)。(Label 左对齐) +- **>= 4 个字段**: 使用 `QueryFilter` 独立组件，配置 `layout="vertical"` (Label 在上)。 +- **视觉风格**: Search 区域必须与 Table 区域在视觉上分离 (Separated Mode)，中间有间隔 (`marginLG`)。 + +### 3.3 数据表格 + +- **列对齐**: + - 文本 (Text): **左对齐** (默认)。 + - 数字/金额 (Money/Number): **右对齐** (必须设置 `align: 'right'`)。 + - 操作 (Action): **右对齐** 或固定在右侧。 + - 状态 (Status): **左对齐**，必须使用 `Tag` 或 `Badge`。 +- **操作栏**: + - **通用规则**: 所有操作按钮必须带有 **Icon** 和 **边框** (type="default"/"primary"/"dashed")。**严禁**使用纯文本链接 (``)。 + - 主要操作 (Primary Action): 位于左上角/右上角，推荐 `type="primary"`。 + - 批量操作 (Batch Action): 位于左下角 (Alert 区域)。 + - 行操作 (Row Action): 必须使用 `Button` 组件，推荐 `type="text"` (无边框中性色，避免与红色 Delete 冲突)。若主题色为冷色调，可使用 `type="link"`。禁止直接使用 `` 标签。 + +### 3.4 表单规范 + +- **模态框表单 (ModalForm)**: + - 默认使用 **垂直布局** (`layout="vertical"`)，以适应移动端及长 Label。 + - 宽度建议：`width="600px"` (中型表单)，`width="400px"` (小型表单/简单修改)。 +- **页面级表单 (ProForm)**: + - 使用 `Grid` 布局。 + - 分组标题：使用 `ProCard` 或 `ProForm.Group`。 + +## 4. 样式系统 (Styling) + +### 4.1 零 CSS 策略 (Zero CSS) + +- **绝对禁止**创建 `.css`, `.less`, `.scss` 文件。 +- **所有样式**必须通过 `theme.useToken()` 获取 Design Token 并在 JSX 中内联。 +- **常用 Token**: + - 间距: `token.margin`, `token.padding` + - 颜色: `token.colorBgContainer`, `token.colorTextSecondary` + - 边框: `token.borderRadius` + +### 4.2 排版 (Typography) + +- 数字必须使用**等宽字体**或千分位格式化。 +- 金额必须保留 2 位小数，右对齐。 +- 二级文本使用 `token.colorTextSecondary`。 + +## 5. 交互反馈 + +- **危险操作** (删除/重置): 必须使用红色 (`danger`), 且必须有二次确认 (`Popconfirm` 或 `Modal`). +- **成功/失败**: 操作后必须有 `message.success` 或 `message.error` 反馈。 +- **Loading**: 所有异步操作按钮必须带有 `loading` 状态。 diff --git a/.agent/skills/tech-stack/umijs-procomponents/SKILL.md b/.agent/skills/tech-stack/umijs-procomponents/SKILL.md index 328e75a..dff1675 100644 --- a/.agent/skills/tech-stack/umijs-procomponents/SKILL.md +++ b/.agent/skills/tech-stack/umijs-procomponents/SKILL.md @@ -1,6 +1,6 @@ --- name: umijs-procomponents -description: UmiJS 4 + Ant Design 5 + ProComponents 全栈开发规范。涵盖技术栈约束、组件用法、样式系统、服务层架构、国际化和图标管理。当项目使用 UmiJS + ProComponents 技术栈时，PM 必须将本 Skill 的要点注入给所有子 Agent。 +description: UmiJS 4 + Ant Design 5 + ProComponents 全栈开发规范。涵盖技术栈约束、组件用法、服务层架构、国际化和图标管理。 --- # UmiJS + ProComponents 开发规范 @@ -30,97 +30,66 @@ description: UmiJS 4 + Ant Design 5 + ProComponents 全栈开发规范。涵盖 | 布局 | `ProLayout` / `PageContainer` | | 详情 | `ProDescriptions` | -### 2.3 ⚠️ 禁止双内边距 +## 3. 样式与视觉规范 -- **严禁**在 `ProTable`、`QueryFilter`、`ProForm` 外层包裹 `Card` 组件。 -- **原因**: ProComponents 自带卡片样式，额外包裹导致双内边距问题。 -- **错误示例**: `` ❌ -- **正确示例**: `` ✅ +**⚠️ 重要**: 本项目遵循严格的视觉设计系统。所有样式、布局、主题色定义请查阅 **[Visual Standards](../design/visual-standards/SKILL.md)**。 -## 3. 搜索区域规范（Separated Card 模式） +### 3.1 零 CSS 策略 (Zero CSS) -### 3.1 复杂度规则 +- **技术约束**: 禁止创建 CSS/Less/SCSS 文件。 +- 所有样式必须使用 Ant Design Design Token (`theme.useToken`). +- 详见 Visual Standards 文档。 -- **< 4 个搜索字段**: 使用 `ProTable` 内置 `search` 属性。 -- **>= 4 个搜索字段**: 使用独立 `QueryFilter` 组件，配置 `layout="vertical"`。 +## 4. 服务层架构 -### 3.2 视觉结构 - -- 搜索区域: 直接使用 `QueryFilter`（自带白色背景和内边距）。 -- 背景色: `QueryFilter` **必须**设置白色背景（`token.colorBgContainer`）。 -- 表格区域: 直接使用 `ProTable`（自带卡片样式）。 -- 间距: `QueryFilter` 使用 `style={{ marginBottom: token.marginLG }}`。 -- **⚠️ 避免双内边距**: 不要在 `QueryFilter` 或 `ProTable` 外层再包裹 `div` 或 `Card` 添加 padding。 - -## 4. 样式系统 - -### 4.1 零 CSS 文件 - -- **严格**使用 Ant Design Design Tokens 内联样式。 -- 使用 `const { token } = theme.useToken()` 获取 token。 -- 间距调整: 使用 `style={{ marginBottom: token.marginLG }}` 而非外层容器。 -- **禁止**导入 `.module.css` 或外部样式表。 - -### 4.2 图标 - -- **统一**使用 `@ant-design/icons`。 -- 除非明确要求或用于特定品牌标志，否则不使用外部图标库、SVG 或 emoji。 - -### 4.3 UI 框架 - -- **严格**使用原生 Ant Design ProComponents。禁止自定义 UI/UX 设计工具。 -- 表单布局: 输入标签放在输入框上方（`layout="vertical"`）。 - -## 5. 服务层架构 - -### 5.1 真实服务层 +### 4.1 真实服务层 - 所有页面逻辑必须调用 `src/services/`。禁止在 JSX 中内联 mock 数据或逻辑。 - **强制使用 useRequest**: 所有数据交互（包括查询、提交、删除）**必须**通过 `useRequest` hook 发起。 - **禁止直接 request**: 严禁在组件内直接手动调用 `request` 方法（除非在极特殊的底层封装中）。`useRequest` 提供了标准化的 loading、error 和 data 状态管理，手动 `request` 会导致状态管理不一致。 -### 5.2 统一 Mocking +### 4.2 统一 Mocking - 使用 UmiJS `mock/` 目录存放所有 mock 数据。禁止在组件中硬编码对象。 -### 5.3 类型定义 +### 4.3 类型定义 - TypeScript 接口统一在 `data.d.ts` 中定义。 -### 5.4 菜单配置 +### 4.4 菜单配置 - 菜单图标必须在 `src/app.ts` 中配置渲染逻辑（确保图标显示为图形而非文本）。 - 菜单文案必须配置在 `src/locales/` 中，Key 以 `menu.` 开头（如 `menu.system.user`）。 -## 6. 国际化 (i18n) +## 5. 国际化 (i18n) -### 6.1 强制规则 +### 5.1 强制规则 - 所有面向用户的字符串**必须**使用 `intl.formatMessage` 或 ``。 - **每个** `formatMessage` 或 `FormattedMessage` 调用**必须**包含 `defaultMessage` 作为后备。 - 示例: `intl.formatMessage({ id: 'key', defaultMessage: '默认文案' })` - 在 `src/locales/` 中维护翻译。 -### 6.2 双语同步 +### 5.2 双语同步 - **必须**同时在 `src/locales/zh-CN.ts` 和 `en-US.ts` 中定义所有使用的 Key。 - **严禁**仅添加中文而忽略英文，或仅添加英文而忽略中文。 -### 6.3 QA 验证 +### 5.3 QA 验证 - 测试时必须在两种语言环境下验证页面显示。 - 浏览器控制台不得出现 `[React Intl] Missing message` 警告。 -## 7. Figma 图标导出规范 +## 6. Figma 图标导出规范 当 Figma 设计稿中包含图标元素时： -### 7.1 优先级原则 +### 6.1 优先级原则 1. **优先匹配 Ant Design Icons**: 检查设计稿中的图标是否可用 `@ant-design/icons` 替代。如果视觉上高度一致，**必须使用 Ant Design 图标**。 2. **自定义图标导出**: 仅当 Ant Design Icons 中**没有匹配或视觉差异明显**时，才从 Figma 导出。 -### 7.2 导出流程 +### 6.2 导出流程 1. 使用 Figma MCP 获取图标设计详情。 2. 导出为 **SVG 格式**，保存到 `src/assets/icons/`。 @@ -128,7 +97,7 @@ description: UmiJS 4 + Ant Design 5 + ProComponents 全栈开发规范。涵盖 4. 封装为 React 组件存放 `src/components/Icons/`。 5. 在 `src/components/Icons/index.ts` 中统一导出。 -### 7.3 目录结构 +### 6.3 目录结构 ``` src/ @@ -140,9 +109,3 @@ src/ ├── CustomChartIcon.tsx └── DataFlowIcon.tsx ``` - -## 8. Ant Design 5 兼容性 - -- 使用 `open` 而非 `visible`。 -- 使用 `onOpenChange` 而非 `onVisibleChange`。 -- 对 Ant Design 5 更新极为警惕，避免使用废弃 API。 diff --git a/.agent/workflows/push.md b/.agent/workflows/push.md new file mode 100644 index 0000000..7fa0f3a --- /dev/null +++ b/.agent/workflows/push.md @@ -0,0 +1,11 @@ +--- +description: 自动暂存所有更改，生成语义化 Commit Message，并推送到远程仓库 +--- + +1. 添加所有变更到暂存区 // turbo Run `git add .` + +2. 查看变更文件列表以生成 Commit Message // turbo Run `git status` + +3. 生成提交信息并提交分析变更内容，生成符合 Angular Commit Convention 的提交信息（如 `feat: add new workflow`, `fix: style issue`）。 Run `git commit -m "type: subject"` + +4. 推送到远程仓库 // turbo Run `git push` diff --git a/.audit_task.md b/.audit_task.md deleted file mode 100644 index 133e42d..0000000 --- a/.audit_task.md +++ /dev/null @@ -1,21 +0,0 @@ -## 审计任务：Agent & Skills 管理界面代码合规性检查 - -### 审计范围 - -- `src/pages/AgentManager/index.tsx` -- `src/components/MarkdownEditor/index.tsx` -- `src/services/agent.ts` -- `mock/agent.ts` - -### 检查要点 (基于 @code-spec 提示词) - -1. **调研证据**: 实施过程是否使用了 `context7` 查询 `ProTable` 和 `Monaco Editor`？ -2. **UI 规范**: - - `ProTable` 是否设置了 `layout: 'vertical'`？ - - 是否使用了 `theme.useToken()` 获取容器背景色？ -3. **代码质量**: - - 类型 `data.d.ts` 是否覆盖了所有属性？ - - `MarkdownEditor` 销毁逻辑是否完整？ -4. **i18n**: 关键文本是否全部通过 `intl` 格式化？ - -请输出详细审计报告。 diff --git a/.doc/project_record.md b/.doc/project_record.md new file mode 100644 index 0000000..5ef4f49 --- /dev/null +++ b/.doc/project_record.md @@ -0,0 +1,72 @@ +### [2026-02-16 13:17] @team-coordinator - 视觉规范升级 + +> **内容**: +> +> 1. 新增视觉规范 Skill: `.opencode/skills/design/visual-standards/SKILL.md`，定义 `#fa541c` (火山红) 主题色及 AntD 视觉标准。 +> 2. 重构 UmiJS Skill: 移除视觉部分，使其专注于技术栈约束。 +> 3. 更新项目配置: 在 `.umirc.ts` 中应用新的主题 Token。 + +### [2026-02-16 13:21] @team-coordinator - 视觉与代码同步 + +> **内容**: +> +> 1. 更新视觉规范 Skill: 强制表格操作按钮必须带有 icon 和边框。 +> 2. 更新页面 `src/pages/Demo/TaskBoard`: 将原有的 `` 链接重构为带 Icon 的 `, + , + ], + }, + ]; + + return ( + + + headerTitle={intl.formatMessage({ + id: 'menu.demo.task-board', + defaultMessage: 'Task List', + })} + actionRef={actionRef} + rowKey="id" + form={{ + layout: 'vertical', + }} + search={{ + labelWidth: 'auto', + }} + toolBarRender={() => [ + , + ]} + request={async (params) => { + // ProTable already integrates useRequest logic internally when 'request' is provided + const msg = await queryTaskList({ ...params }); + return { + data: msg.data, + success: msg.success, + total: msg.total, + }; + }} + columns={columns} + /> + + {/* Create Form */} + { + await addTask(value as TaskItem); + message.success('Added successfully'); + handleModalOpen(false); + actionRef.current?.reload(); + return true; + }} + > + + + + + {/* Edit Form */} + { + const data = { ...currentRow, ...value }; + await updateTask(data as TaskItem); + message.success('Updated successfully'); + handleUpdateModalOpen(false); + actionRef.current?.reload(); + return true; + }} + initialValues={currentRow} + modalProps={{ + destroyOnClose: true, + }} + > + + + ); +}; diff --git a/src/services/demo/task.ts b/src/services/demo/task.ts new file mode 100644 index 0000000..f9306bc --- /dev/null +++ b/src/services/demo/task.ts @@ -0,0 +1,57 @@ +import type { TaskItem, TaskParams } from '@/pages/Demo/TaskBoard/data'; +import { request } from '@umijs/max'; + +/** 获取任务列表 GET /api/demo/tasks */ +export async function queryTaskList( + params: TaskParams, + options?: { [key: string]: any }, +) { + return request<{ + data: TaskItem[]; + /** 列表的内容总数 */ + total?: number; + success?: boolean; + }>('/api/demo/tasks', { + method: 'GET', + params: { + ...params, + }, + ...(options || {}), + }); +} + +/** 新建任务 POST /api/demo/tasks */ +export async function addTask( + data: Partial, + options?: { [key: string]: any }, +) { + return request('/api/demo/tasks', { + method: 'POST', + data, + ...(options || {}), + }); +} + +/** 更新任务 PUT /api/demo/tasks */ +export async function updateTask( + data: Partial, + options?: { [key: string]: any }, +) { + return request('/api/demo/tasks', { + method: 'PUT', + data, + ...(options || {}), + }); +} + +/** 删除任务 DELETE /api/demo/tasks */ +export async function removeTask( + data: { id: string }, + options?: { [key: string]: any }, +) { + return request>('/api/demo/tasks', { + method: 'DELETE', + data, + ...(options || {}), + }); +}