feat: add TaskBoard demo and refactor project structure
This commit is contained in:
ken
@@ -163,6 +163,8 @@ graph BT
|
||||
├── business/ # 💼 业务域
|
||||
│ ├── order-management/
|
||||
│ └── product-management/
|
||||
├── design/ # 🎨 设计规范
|
||||
│ └── visual-standards/
|
||||
├── tech-stack/ # 🛠️ 技术栈
|
||||
│ └── umijs-procomponents/
|
||||
└── engineering/ # 🛡️ 通用工程
|
||||
|
||||
@@ -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
|
||||
<ProTable
|
||||
onLoad={() => {}} // 实际不存在，应该是 request
|
||||
data={data} // 实际不存在，数据通过 request 获取
|
||||
loading={loading} // request 自动处理 loading
|
||||
/>
|
||||
```
|
||||
|
||||
### 示例 2: QueryFilter Props 幻觉
|
||||
|
||||
```tsx
|
||||
// ❌ 错误：猜测 props
|
||||
<QueryFilter
|
||||
onSearch={handleSearch} // 实际应该是 onFinish
|
||||
fields={searchFields} // 不是通过 props 传递
|
||||
resetable={true} // 拼写错误，应该是 resetButtonProps
|
||||
/>
|
||||
```
|
||||
|
||||
### 示例 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 定义列
|
||||
|
||||
<ProTable
|
||||
columns={columns}
|
||||
request={async (params) => {
|
||||
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
|
||||
|
||||
<QueryFilter
|
||||
layout="vertical"
|
||||
onFinish={(values) => {
|
||||
console.log('Search values:', values);
|
||||
}}
|
||||
onReset={() => {
|
||||
console.log('Reset');
|
||||
}}
|
||||
>
|
||||
<ProFormText name="name" label="名称" />
|
||||
<ProFormSelect name="status" label="状态" />
|
||||
</QueryFilter>
|
||||
```
|
||||
|
||||
### 示例 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
|
||||
<QueryFilter
|
||||
layout="vertical"
|
||||
onFinish={(values) => setSearchParams(values)}
|
||||
>
|
||||
{/* 搜索字段 */}
|
||||
</QueryFilter>
|
||||
|
||||
<ProTable
|
||||
columns={columns}
|
||||
request={async (params) => {
|
||||
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
|
||||
// ❌ 容易混淆
|
||||
<ProTable onLoad={...} /> // 不存在
|
||||
<ProTable request={...} /> // ✅ 正确
|
||||
|
||||
<QueryFilter onSearch={...} /> // 不存在
|
||||
<QueryFilter onFinish={...} /> // ✅ 正确
|
||||
```
|
||||
|
||||
### 陷阱 2: TypeScript 类型推断错误
|
||||
|
||||
```tsx
|
||||
// ❌ 假设类型
|
||||
const { data } = useRequest<ProductList>(fetch); // 假设返回类型
|
||||
|
||||
// ✅ 查询文档确认
|
||||
// 文档：useRequest 返回 {data, loading, error, run, ...}
|
||||
const { data, loading, error } = useRequest(fetch);
|
||||
```
|
||||
|
||||
### 陷阱 3: 版本差异
|
||||
|
||||
```tsx
|
||||
// ❌ 使用旧版本 API（可能已废弃）
|
||||
<Modal visible={show} /> // Ant Design 4
|
||||
<Modal open={show} /> // ✅ 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
|
||||
**强制执行**: 是
|
||||
@@ -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
|
||||
<Card>
|
||||
<ProTable />
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<QueryFilter />
|
||||
</Card>
|
||||
|
||||
<Card>
|
||||
<ProForm />
|
||||
</Card>
|
||||
```
|
||||
|
||||
### 正确模式 ✅
|
||||
|
||||
```tsx
|
||||
// 正确：直接使用 ProComponents，通过 style 调整间距
|
||||
<ProTable
|
||||
style={{ marginBottom: token.marginLG }}
|
||||
/>
|
||||
|
||||
<QueryFilter
|
||||
style={{ marginBottom: token.marginLG }}
|
||||
/>
|
||||
|
||||
<ProForm
|
||||
style={{ marginBottom: token.marginLG }}
|
||||
/>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📝 各 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. 扫描 `<Card>` 包裹 ProComponents 的代码
|
||||
2. 验证间距调整方式
|
||||
3. 提供修复建议
|
||||
|
||||
### QA 测试人员需要验证
|
||||
|
||||
1. 视觉检查内边距是否过大
|
||||
2. 对比设计稿确认间距
|
||||
3. 截图记录问题
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 工具支持建议
|
||||
|
||||
### ESLint 规则（可选）
|
||||
|
||||
可以考虑添加自定义 ESLint 规则检测：
|
||||
|
||||
```javascript
|
||||
// 伪代码示例
|
||||
// 检测 <Card><ProTable /></Card> 模式
|
||||
```
|
||||
|
||||
### 代码审查清单
|
||||
|
||||
在 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 "<Card>" src/pages/ | grep "ProTable\|QueryFilter\|ProForm"
|
||||
```
|
||||
|
||||
### 2. 文档更新
|
||||
|
||||
在团队 Wiki 中添加：
|
||||
|
||||
- ProComponents 使用最佳实践
|
||||
- 常见错误模式和修复方法
|
||||
- 视觉效果对比图
|
||||
|
||||
### 3. 设计规范同步
|
||||
|
||||
与设计团队同步此规范，确保设计稿中不出现双重卡片设计。
|
||||
|
||||
---
|
||||
|
||||
**更新完成时间**: 2026-02-14
|
||||
**更新执行者**: Antigravity Team
|
||||
**规范版本**: v1.1
|
||||
@@ -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
|
||||
**强制执行**: 是
|
||||
@@ -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 可选）。
|
||||
@@ -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 导致历史丢失。
|
||||
|
||||
### 内部思维链
|
||||
|
||||
|
||||
85
.agent/skills/design/visual-standards/SKILL.md
Normal file
85
.agent/skills/design/visual-standards/SKILL.md
Normal file
@@ -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 自带卡片样式。
|
||||
- **错误示例**: `<Card><ProTable /></Card>` ❌
|
||||
|
||||
### 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")。**严禁**使用纯文本链接 (`<a>`)。
|
||||
- 主要操作 (Primary Action): 位于左上角/右上角，推荐 `type="primary"`。
|
||||
- 批量操作 (Batch Action): 位于左下角 (Alert 区域)。
|
||||
- 行操作 (Row Action): 必须使用 `Button` 组件，推荐 `type="text"` (无边框中性色，避免与红色 Delete 冲突)。若主题色为冷色调，可使用 `type="link"`。禁止直接使用 `<a>` 标签。
|
||||
|
||||
### 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` 状态。
|
||||
@@ -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 自带卡片样式，额外包裹导致双内边距问题。
|
||||
- **错误示例**: `<Card><ProTable /></Card>` ❌
|
||||
- **正确示例**: `<ProTable style={{ marginBottom: token.marginLG }} />` ✅
|
||||
**⚠️ 重要**: 本项目遵循严格的视觉设计系统。所有样式、布局、主题色定义请查阅 **[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` 或 `<FormattedMessage>`。
|
||||
- **每个** `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。
|
||||
|
||||
11
.agent/workflows/push.md
Normal file
11
.agent/workflows/push.md
Normal file
@@ -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`
|
||||
@@ -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` 格式化？
|
||||
|
||||
请输出详细审计报告。
|
||||
72
.doc/project_record.md
Normal file
72
.doc/project_record.md
Normal file
@@ -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`: 将原有的 `<a>` 链接重构为带 Icon 的 `<Button size="small">`，符合新规范。
|
||||
|
||||
### [2026-02-16 13:23] @team-coordinator - 视觉微调 (Solid Primary Buttons)
|
||||
|
||||
> **内容**: 响应用户反馈 "按钮带颜色 Primary"。
|
||||
>
|
||||
> 1. 更新视觉规范 Skill: 行操作按钮推荐使用 Primary (实心) 样式。
|
||||
> 2. 更新页面 `Demo/TaskBoard`: 将行操作升级为 Full Primary Buttons (Blue) 和 Primary Danger Buttons (Red)。
|
||||
|
||||
### [2026-02-16 13:25] @team-coordinator - 视觉回滚 (Default Buttons)
|
||||
|
||||
> **内容**: 响应用户反馈 "改回默认按钮"。
|
||||
>
|
||||
> 1. 更新视觉规范 Skill: 行操作按钮推荐使用 Default (Outlined) 样式。
|
||||
> 2. 更新页面 `Demo/TaskBoard`: 将行操作按钮样式回滚为普通 Default 样式（带 Icon 和边框）。
|
||||
|
||||
### [2026-02-16 13:26] @team-coordinator - 视觉微调 (Link Buttons)
|
||||
|
||||
> **内容**: 响应用户反馈 "不需要不带边框"。
|
||||
>
|
||||
> 1. 更新视觉规范 Skill: 行操作按钮推荐使用 Link (`type="link"`) 样式。
|
||||
> 2. 更新页面 `Demo/TaskBoard`: 将行操作按钮样式更改为 Link 样式（无边框，带颜色）。
|
||||
|
||||
### [2026-02-16 13:27] @team-coordinator - 视觉冲突解决 (Neutral Text Buttons)
|
||||
|
||||
> **内容**: 响应用户反馈 "主题色与危险色冲突"。
|
||||
>
|
||||
> 1. 更新视觉规范 Skill: 在暖色调主题（如火山红）下，推荐行操作使用 `type="text"` (中性色) 而非 `link` (主题色)，以形成与 Danger 操作的色彩对比。
|
||||
> 2. 更新页面 `Demo/TaskBoard`: 将 Edit 按钮样式更改为 Text Style (Neutral)，保持 Delete 为 Danger (Red)。
|
||||
|
||||
### [2026-02-16 13:28] @team-coordinator - 视觉规范感知链升级
|
||||
|
||||
> **内容**: 响应用户问题 "主 Agent 和架构师需要感知吗"。
|
||||
>
|
||||
> 1. 更新 Team Agent Prompt (`.opencode/agents/team.md`): 将 `design/visual-standards` 列为必须扫描和注入的 Skill。
|
||||
> 2. 更新 Planning Agent Prompt (`.opencode/agents/planning.md`): 要求规划方案必须显式说明如何符合 Visual Standards。
|
||||
> 3. 确立 "视觉一致性" 为架构验收标准之一。
|
||||
|
||||
### [2026-02-16 13:30] @team-coordinator - 配置同步 (.agent)
|
||||
|
||||
> **内容**: 响应用户指令 "同步到 .agent"。
|
||||
>
|
||||
> 1. 执行文件同步脚本，将 `.opencode/agents/*.md` 映射复制到 `.agent/*_prompt.md`。
|
||||
> 2. 同步 `skills` 目录结构，包括新增的 `visual-standards`。
|
||||
> 3. 更新 `AGENT_ARCHITECTURE_V2.md` 以反映新的 `design/` 技能分类。
|
||||
|
||||
### [2026-02-16 13:31] @team-coordinator - 记录修复
|
||||
|
||||
> **内容**: 发现 `project_record.md` 写入逻辑错误（覆盖而非追加）。
|
||||
>
|
||||
> 1. 手动恢复过往 20 分钟内的操作记录。
|
||||
> 2. 修正后续写入行为（改为 Append 模式）。
|
||||
|
||||
### [2026-02-16 13:33] @team-coordinator - 文档规范升级
|
||||
|
||||
> **内容**: 响应用户指令 "怎样追加也加到 team 文档中"。
|
||||
>
|
||||
> 1. 更新 Team Agent Prompt (`.opencode/agents/team.md`): 增加 **文档维护 (日志安全)** 红线规则，强制使用追加模式。
|
||||
> 2. 同步配置到 `.agent` 目录。
|
||||
@@ -1,224 +0,0 @@
|
||||
# OpenCode Agent 配置完成总结
|
||||
|
||||
## ✅ 迁移完成
|
||||
|
||||
已成功将 Antigravity 的 Agent 配置完整迁移到 OpenCode 格式，并根据 OpenCode 规范进行了优化。
|
||||
|
||||
**完成时间**: 2026-02-14
|
||||
**配置版本**: v1.0
|
||||
|
||||
---
|
||||
|
||||
## 📦 交付清单
|
||||
|
||||
### 配置文件（7 个）
|
||||
|
||||
1. ✅ `.opencode/agents/team.md` - 主 Agent（项目经理）
|
||||
2. ✅ `.opencode/agents/planning.md` - 规划架构师（子 Agent）
|
||||
3. ✅ `.opencode/agents/frontend.md` - 前端专家（子 Agent）
|
||||
4. ✅ `.opencode/agents/umi-pro.md` - UmiJS 专家（子 Agent）
|
||||
5. ✅ `.opencode/agents/code-spec.md` - 代码规范专家（子 Agent）
|
||||
6. ✅ `.opencode/agents/qa-tester.md` - QA 测试专家（子 Agent）
|
||||
7. ✅ `opencode.json` - 统一配置文件
|
||||
|
||||
### 文档文件（3 个）
|
||||
|
||||
1. ✅ `.opencode/README.md` - 使用指南
|
||||
2. ✅ `.opencode/MIGRATION.md` - 迁移文档
|
||||
3. ✅ 本文件 - 完成总结
|
||||
|
||||
---
|
||||
|
||||
## 🎯 核心特性
|
||||
|
||||
### 1. 主-子 Agent 架构
|
||||
|
||||
```
|
||||
Team (主 Agent)
|
||||
├── @planning (规划)
|
||||
├── @frontend (前端)
|
||||
├── @umi-pro (UmiJS)
|
||||
├── @code-spec (审查)
|
||||
└── @qa-tester (测试)
|
||||
```
|
||||
|
||||
### 2. 统一输出格式
|
||||
|
||||
所有子 Agent 完成任务后都输出标准格式的结果摘要：
|
||||
|
||||
- 任务描述和状态
|
||||
- 完成内容清单
|
||||
- 待主 Agent 确认事项
|
||||
- 明确的结束标记
|
||||
|
||||
### 3. 严格会话控制
|
||||
|
||||
- ✅ 只有主 Agent (team) 可以开始和结束会话
|
||||
- ✅ 子 Agent 必须将结果交回主 Agent
|
||||
- ❌ 子 Agent 禁止自行结束会话
|
||||
- ❌ 子 Agent 禁止直接调用其他 Agent
|
||||
|
||||
### 4. 移除 Model 配置
|
||||
|
||||
所有 Agent 不再指定 model，由 OpenCode 统一管理模型选择，更加灵活。
|
||||
|
||||
### 5. Chrome DevTools MCP 集成
|
||||
|
||||
QA Tester 配置了 Chrome DevTools MCP 支持，用于自动化浏览器测试。
|
||||
|
||||
---
|
||||
|
||||
## 🚀 使用方式
|
||||
|
||||
### 直接对话（主 Agent）
|
||||
|
||||
```
|
||||
用户：创建一个产品管理页面
|
||||
Team Agent：理解需求 → 调用 @planning → 等待批准 → 实施 → 审查 → 测试 → 交付
|
||||
```
|
||||
|
||||
### 手动调用子 Agent
|
||||
|
||||
```
|
||||
@planning 分析这个需求并给出实施计划
|
||||
@frontend 实现这个 UI 界面
|
||||
@umi-pro 创建服务层和 Mock 数据
|
||||
@code-spec 审查代码是否符合规范
|
||||
@qa-tester 测试所有功能
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📋 工作流程
|
||||
|
||||
### 标准开发流程
|
||||
|
||||
1. **需求理解**: Team 与用户沟通，clarify 需求
|
||||
2. **架构规划**: Team 调用 @planning 生成详细计划
|
||||
3. **🛑 用户确认**: Team 暂停，等待用户批准计划
|
||||
4. **服务开发**: Team 调用 @umi-pro 创建服务和 Mock
|
||||
5. **UI 实施**: Team 调用 @frontend 或 @umi-pro 实现界面
|
||||
6. **代码审查**: Team 调用 @code-spec 审查代码
|
||||
7. **质量测试**: Team 调用 @qa-tester 进行测试
|
||||
8. **任务交付**: Team 整合所有结果，交付给用户
|
||||
|
||||
---
|
||||
|
||||
## 🎨 设计规范（所有 Agent 强制遵守）
|
||||
|
||||
### "Separated Card" 模式
|
||||
|
||||
- **< 4 搜索字段**: 使用 `ProTable` 内置 `search`
|
||||
- **>= 4 搜索字段**: 独立 `QueryFilter` 组件
|
||||
|
||||
### 强制样式 Tokens
|
||||
|
||||
```typescript
|
||||
{
|
||||
background: token.colorBgContainer, // 白色
|
||||
padding: token.paddingLG, // 24px
|
||||
borderRadius: token.borderRadius, // 6px
|
||||
marginBottom: token.marginLG, // 24px
|
||||
// 无 boxShadow - 扁平化设计
|
||||
}
|
||||
```
|
||||
|
||||
### 零 CSS 文件政策
|
||||
|
||||
所有样式必须通过 Ant Design Design Tokens 内联实现。
|
||||
|
||||
---
|
||||
|
||||
## 🔧 技术规范
|
||||
|
||||
### 架构层
|
||||
|
||||
- ✅ 真实服务层（`src/services/`）
|
||||
- ✅ 统一 Mock（`mock/` 目录）
|
||||
- ✅ TypeScript 严格（无 `any`）
|
||||
|
||||
### UI 层
|
||||
|
||||
- ✅ ProComponents 优先
|
||||
- ✅ 垂直表单布局 (`layout="vertical"`)
|
||||
- ✅ Design Tokens 样式化
|
||||
|
||||
### 数据层
|
||||
|
||||
- ✅ `useRequest` 统一数据请求
|
||||
- ✅ 加载状态显示
|
||||
- ✅ 防重复点击
|
||||
|
||||
### 国际化
|
||||
|
||||
- ✅ 所有字符串使用 `intl.formatMessage`
|
||||
- ✅ 包含 `defaultMessage`
|
||||
|
||||
---
|
||||
|
||||
## 📊 配置对比
|
||||
|
||||
### Antigravity vs OpenCode
|
||||
|
||||
| 特性 | Antigravity | OpenCode |
|
||||
| ---------- | ----------------------- | ------------------------ |
|
||||
| 调用方式 | `/plan`, `/fe`, `/umi` | `@planning`, `@frontend` |
|
||||
| 主协调器 | Team Coordinator Prompt | Team 主 Agent |
|
||||
| Agent 类型 | 平级 Agent | 主-子 Agent 架构 |
|
||||
| 会话控制 | 各 Agent 自行控制 | 主 Agent 统一控制 |
|
||||
| 输出格式 | 自由格式 | 统一标准格式 |
|
||||
| Model 配置 | 每个 Agent 指定 | 统一管理 |
|
||||
|
||||
---
|
||||
|
||||
## ⚙️ 配置细节
|
||||
|
||||
### 权限矩阵
|
||||
|
||||
| Agent | Mode | Write | Edit | Bash | Temperature |
|
||||
| --------- | -------- | ----- | ---- | ---- | ----------- |
|
||||
| team | primary | ✅ | ✅ | ✅ | 0.3 |
|
||||
| planning | subagent | ❌ | ❌ | ❌ | 0.2 |
|
||||
| frontend | subagent | ✅ | ✅ | ✅ | 0.3 |
|
||||
| umi-pro | subagent | ✅ | ✅ | ✅ | 0.3 |
|
||||
| code-spec | subagent | ✅ | ✅ | ❌ | 0.1 |
|
||||
| qa-tester | subagent | ❌ | ❌ | ✅ | 0.2 |
|
||||
|
||||
---
|
||||
|
||||
## 📚 相关文档
|
||||
|
||||
- [README.md](./.opencode/README.md) - 详细使用指南
|
||||
- [MIGRATION.md](./.opencode/MIGRATION.md) - 完整迁移说明
|
||||
- [OpenCode 官方文档](https://opencode.ai/docs/zh-cn/agents/)
|
||||
- [Antigravity 配置](./.agent/)
|
||||
|
||||
---
|
||||
|
||||
## ✨ 下一步建议
|
||||
|
||||
### 1. 测试配置
|
||||
|
||||
```bash
|
||||
# 使用 OpenCode 加载此项目
|
||||
# 测试主 Agent 是否正常工作
|
||||
# 测试子 Agent 调用是否正常
|
||||
```
|
||||
|
||||
### 2. 团队培训
|
||||
|
||||
- 向团队成员介绍新的 Agent 架构
|
||||
- 说明主-子 Agent 的协作方式
|
||||
- 演示标准工作流程
|
||||
|
||||
### 3. 持续优化
|
||||
|
||||
- 根据实际使用反馈调整 Agent 配置
|
||||
- 优化输出格式和提示词
|
||||
- 补充更多使用示例
|
||||
|
||||
---
|
||||
|
||||
**配置状态**: ✅ 已完成，可投入使用
|
||||
**维护者**: Antigravity Team
|
||||
**更新日期**: 2026-02-14
|
||||
@@ -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 导致历史丢失。
|
||||
|
||||
### 内部思维链
|
||||
|
||||
|
||||
85
.opencode/skills/design/visual-standards/SKILL.md
Normal file
85
.opencode/skills/design/visual-standards/SKILL.md
Normal file
@@ -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 自带卡片样式。
|
||||
- **错误示例**: `<Card><ProTable /></Card>` ❌
|
||||
|
||||
### 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")。**严禁**使用纯文本链接 (`<a>`)。
|
||||
- 主要操作 (Primary Action): 位于左上角/右上角，推荐 `type="primary"`。
|
||||
- 批量操作 (Batch Action): 位于左下角 (Alert 区域)。
|
||||
- 行操作 (Row Action): 必须使用 `Button` 组件，推荐 `type="text"` (无边框中性色，避免与红色 Delete 冲突)。若主题色为冷色调，可使用 `type="link"`。禁止直接使用 `<a>` 标签。
|
||||
|
||||
### 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` 状态。
|
||||
@@ -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 自带卡片样式，额外包裹导致双内边距问题。
|
||||
- **错误示例**: `<Card><ProTable /></Card>` ❌
|
||||
- **正确示例**: `<ProTable style={{ marginBottom: token.marginLG }} />` ✅
|
||||
**⚠️ 重要**: 本项目遵循严格的视觉设计系统。所有样式、布局、主题色定义请查阅 **[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` 或 `<FormattedMessage>`。
|
||||
- **每个** `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。
|
||||
|
||||
16
.umirc.ts
16
.umirc.ts
@@ -2,7 +2,15 @@ import { defineConfig } from '@umijs/max';
|
||||
|
||||
export default defineConfig({
|
||||
// Force restart
|
||||
antd: {},
|
||||
antd: {
|
||||
theme: {
|
||||
token: {
|
||||
colorPrimary: '#fa541c',
|
||||
colorInfo: '#fa541c',
|
||||
wireframe: false,
|
||||
},
|
||||
},
|
||||
},
|
||||
access: {},
|
||||
model: {},
|
||||
initialState: {},
|
||||
@@ -142,6 +150,12 @@ export default defineConfig({
|
||||
},
|
||||
],
|
||||
},
|
||||
{
|
||||
name: 'demo.task-board',
|
||||
path: '/demo/task-board',
|
||||
icon: 'ProfileOutlined',
|
||||
component: './Demo/TaskBoard',
|
||||
},
|
||||
],
|
||||
npmClient: 'npm',
|
||||
});
|
||||
|
||||
171
README.md
171
README.md
@@ -1,3 +1,170 @@
|
||||
# README
|
||||
# Agent Team V2 架构视图
|
||||
|
||||
`@umijs/max` 模板项目，更多功能参考 [Umi Max 简介](https://umijs.org/docs/max/introduce)
|
||||
本文档描述了当前 Agent 团队的协作模式、核心机制与防护体系。
|
||||
|
||||
## 1. 宏观架构视图
|
||||
|
||||
系统由 **Team Coordinator (PM)** 统一调度，通过动态组装 **Agent 池** 中的专业角色，并结合 **Skill 知识库** 来完成复杂研发任务。
|
||||
|
||||
```mermaid
|
||||
graph TD
|
||||
User([👤 用户]) <--> PM[👑 Team Coordinator (PM)]
|
||||
|
||||
subgraph "Skill Knowledge Base (技能知识库)"
|
||||
TechSkill[🛠️ Tech Stack Skills]
|
||||
BizSkill[💼 Business Skills]
|
||||
EngSkill[🛡️ Engineering Skills]
|
||||
end
|
||||
|
||||
subgraph "Agent Pool (能力池)"
|
||||
Planning[🧠 @planning<br>技术架构师]
|
||||
Frontend[⚡ @frontend<br>全栈开发专家]
|
||||
CodeSpec[🔍 @code-spec<br>代码审计专家]
|
||||
QATester[🧪 @qa-tester<br>QA 测试专家]
|
||||
end
|
||||
|
||||
PM -- "1. 扫描与提取" --> TechSkill
|
||||
PM -- "1. 扫描与提取" --> BizSkill
|
||||
PM -- "1. 扫描与提取" --> EngSkill
|
||||
|
||||
PM -- "2. 动态组装 & 任务委派" --> Planning
|
||||
PM -- "3. 任务委派" --> Frontend
|
||||
PM -- "4. 任务委派" --> CodeSpec
|
||||
PM -- "5. 任务委派" --> QATester
|
||||
|
||||
Planning -.->|遵循| TechSkill & BizSkill
|
||||
Frontend -.->|遵循| TechSkill & BizSkill
|
||||
CodeSpec -.->|审计依据| TechSkill & BizSkill
|
||||
QATester -.->|验收依据| TechSkill & BizSkill
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 全生命周期协作流
|
||||
|
||||
采用 **"PM 中心化调度 + 阶段性闭环"** 的工作流。PM 负责上下文流转，杜绝子 Agent 直接通信。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant User as 👤 User
|
||||
participant PM as 👑 Team Coordinator
|
||||
participant Skill as 📚 Skill System
|
||||
participant Planning as 🧠 @planning
|
||||
participant Dev as ⚡ @frontend
|
||||
participant Review as 🔍 @code-spec
|
||||
participant QA as 🧪 @qa-tester
|
||||
|
||||
Note over PM: Phase 0: 上下文采集
|
||||
User->>PM: 提出需求
|
||||
PM->>Skill: 扫描 .opencode/skills/
|
||||
Skill-->>PM: 返回匹配的 Skill (例如 UmiJS, 订单管理)
|
||||
PM->>PM: 构建「决策上下文包」
|
||||
|
||||
Note over PM, Planning: Phase 1: 架构规划
|
||||
PM->>Planning: 委派规划 (注入 Skill 摘要 + Figma)
|
||||
Planning-->>PM: 返回架构设计方案
|
||||
PM->>User: 🛑 检查点：展示方案并确认
|
||||
User->>PM: 批准继续
|
||||
|
||||
Note over PM, Dev: Phase 2: 实施开发
|
||||
PM->>Dev: 委派开发 (注入完整 Skill 约束)
|
||||
Dev->>Dev: 查询 Context7 / 编写代码
|
||||
Dev-->>PM: 提交代码与实施报告
|
||||
|
||||
loop 质量闭环 (Phase 3 & 4)
|
||||
PM->>Review: 委派代码审计
|
||||
Review-->>PM: 返回审计报告 (P0/P1 问题)
|
||||
|
||||
alt 审计不通过
|
||||
PM->>Dev: 回派修复问题
|
||||
Dev-->>PM: 修复完成
|
||||
else 审计通过
|
||||
PM->>QA: 委派功能测试
|
||||
QA-->>PM: 返回测试报告
|
||||
|
||||
alt 测试不通过
|
||||
PM->>Dev: 回派修复 Bug
|
||||
Dev-->>PM: 修复完成
|
||||
Note right of PM: 修复后必须重新审计
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
Note over PM: Phase 5: 交付
|
||||
PM->>User: ✅ 最终交付 (代码 + 测试报告)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 三层防护体系
|
||||
|
||||
通过三层机制确保 AI 行为可控、代码质量达标、技术规范落地。
|
||||
|
||||
```mermaid
|
||||
graph BT
|
||||
subgraph "Layer 3: 协议控制层 (Protocol Layer)"
|
||||
L3_1[统一汇报格式]
|
||||
L3_2[禁止子Agent结束会话]
|
||||
L3_3[PM 终审权]
|
||||
L3_4[Skill 注入协议]
|
||||
end
|
||||
|
||||
subgraph "Layer 2: 动态规范层 (Skill Layer)"
|
||||
L2_1[Tech: UmiJS/ProComponents 规范]
|
||||
L2_2[Biz: 业务状态机/数据模型]
|
||||
L2_3[Eng: 组件500行/TS严格模式]
|
||||
end
|
||||
|
||||
subgraph "Layer 1: 静态红线层 (Redline Layer)"
|
||||
L1_1[禁止 API 幻觉 (Context7 强制)]
|
||||
L1_2[禁止 XSS / 浮点金额计算]
|
||||
L1_3[禁止直接修改非代码文件]
|
||||
L1_4[只读模式 (@planning)]
|
||||
end
|
||||
|
||||
L1_1 --> L2_1
|
||||
L1_2 --> L2_3
|
||||
L2_1 --> L3_4
|
||||
```
|
||||
|
||||
### 每一层的职责：
|
||||
|
||||
1. **Layer 1: 静态红线层 (Redlines)**
|
||||
|
||||
- **定义位置**: Agent Prompt 文件本身 (e.g., `frontend.md`)。
|
||||
- **作用**: 绝对底线，无论什么任务都必须遵守。
|
||||
- **例子**: "编码前必须查 Context7"、"禁止 any 类型"。
|
||||
|
||||
2. **Layer 2: 动态规范层 (Skills)**
|
||||
|
||||
- **定义位置**: `.opencode/skills/` 目录。
|
||||
- **作用**: 可插拔的知识块，根据任务动态加载。
|
||||
- **例子**: "使用 ProTable"、"搜索栏 >=4 个字段用 QueryFilter"、"订单状态机定义"。
|
||||
|
||||
3. **Layer 3: 协议控制层 (Protocols)**
|
||||
- **定义位置**: `team.md` 和各子 Agent 的交互指令。
|
||||
- **作用**: 确保协作顺畅，防止 Agent "失控"或"偷懒"。
|
||||
- **例子**: "PM 必须将 Skill 摘要写入委派指令"、"子 Agent 必须用指定格式汇报"。
|
||||
|
||||
---
|
||||
|
||||
## 4. 目录结构映射
|
||||
|
||||
```text
|
||||
.opencode/
|
||||
├── agents/ # 🟢 角色定义 (Agents)
|
||||
│ ├── team.md # 👑 Coordinator
|
||||
│ ├── planning.md # 🧠 Architect
|
||||
│ ├── frontend.md # ⚡ Developer
|
||||
│ ├── code-spec.md # 🔍 Reviewer
|
||||
│ └── qa-tester.md # 🧪 Tester
|
||||
│
|
||||
└── skills/ # 🔵 能力定义 (Skills)
|
||||
├── business/ # 💼 业务域
|
||||
│ ├── order-management/
|
||||
│ └── product-management/
|
||||
├── tech-stack/ # 🛠️ 技术栈
|
||||
│ └── umijs-procomponents/
|
||||
└── engineering/ # 🛡️ 通用工程
|
||||
└── code-quality/
|
||||
```
|
||||
|
||||
44
mock/demoTask.ts
Normal file
44
mock/demoTask.ts
Normal file
@@ -0,0 +1,44 @@
|
||||
import { defineMock } from '@umijs/max';
|
||||
|
||||
const tasks: any[] = [];
|
||||
for (let i = 0; i < 20; i += 1) {
|
||||
tasks.push({
|
||||
id: `${i}`,
|
||||
title: `Task Name ${i}`,
|
||||
status: i % 3 === 0 ? 'todo' : i % 3 === 1 ? 'doing' : 'done',
|
||||
description: 'This is a description for the task.',
|
||||
priority: Math.floor(Math.random() * 3), // 0, 1, 2
|
||||
createdAt: new Date().toISOString(),
|
||||
});
|
||||
}
|
||||
|
||||
export default defineMock({
|
||||
'GET /api/demo/tasks': (req, res) => {
|
||||
const { keyword, current = 1, pageSize = 20 } = req.query as any;
|
||||
let dataSource = [...tasks].slice().reverse();
|
||||
|
||||
if (keyword) {
|
||||
dataSource = dataSource.filter((item) => item.title.includes(keyword));
|
||||
}
|
||||
|
||||
const start = (current - 1) * pageSize;
|
||||
const end = start + pageSize;
|
||||
|
||||
setTimeout(() => {
|
||||
res.json({
|
||||
success: true,
|
||||
data: dataSource.slice(start, end),
|
||||
total: dataSource.length,
|
||||
});
|
||||
}, 500);
|
||||
},
|
||||
'POST /api/demo/tasks': (req, res) => {
|
||||
res.json({ success: true, data: { ...req.body, id: `${tasks.length}` } });
|
||||
},
|
||||
'PUT /api/demo/tasks': (req, res) => {
|
||||
res.json({ success: true });
|
||||
},
|
||||
'DELETE /api/demo/tasks': (req, res) => {
|
||||
res.json({ success: true });
|
||||
},
|
||||
});
|
||||
@@ -1,59 +0,0 @@
|
||||
# Planning Agent Prompt
|
||||
|
||||
## Identity
|
||||
|
||||
You are a highly skilled **Technical Architect and Planner**. Your goal is to analyze the user's request and the existing codebase to generate a comprehensive, error-free implementation plan.
|
||||
|
||||
## Core Directives
|
||||
|
||||
1. **READ-ONLY**: You have **zero write permissions**. You must NOT attempt to create, edit, rename, or delete any files.
|
||||
2. **PLANNING ONLY**: Your output is documentation and strategy, not code execution.
|
||||
3. **DEEP ANALYSIS**: You must thoroughly explore the codebase (using `list_dir`, `view_file`, `grep_search`, etc.) to understand the context before proposing a plan.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Explore**: Use your tools to understand the current project structure and relevant files.
|
||||
2. **Analyze**: Identify what files need to be changed, created, or deleted based on the user's request.
|
||||
3. **Plan**: Output a detailed, step-by-step implementation plan.
|
||||
|
||||
## Output Format (The Plan)
|
||||
|
||||
Your final response should be a structured Markdown document containing:
|
||||
|
||||
### 1. Problem Analysis
|
||||
|
||||
- Brief summary of the user's request.
|
||||
- Analysis of the current codebase state relevant to the task.
|
||||
|
||||
### 2. Proposed Solution
|
||||
|
||||
- High-level architectural decisions.
|
||||
- Explanation of why this approach was chosen.
|
||||
|
||||
### 3. Implementation Steps
|
||||
|
||||
Break down the work into atomic, sequential steps. For each step, specify:
|
||||
|
||||
- **Description**: What needs to be done.
|
||||
- **Target File(s)**: Which files are involved.
|
||||
- **Action**: (e.g., "Create", "Modify function X", "Add import").
|
||||
- **Pseudo-code / Snippets**: Provide specific logic or code structures (but do not implement the full file).
|
||||
|
||||
### 4. Comprehensive Functional Test Plan 🟢 (NEW)
|
||||
|
||||
- **User Scenarios**: Define end-to-end user journeys (e.g., "User logs in -> Navigates to Dashboard -> Clicks 'Update'").
|
||||
- **Edge Cases**: Identify potential failure points (e.g., "Network error", "Invalid input", "Empty state").
|
||||
- **Acceptance Criteria**: Specific conditions that must be met for the feature to be considered "Done".
|
||||
|
||||
### 5. Verification Strategy
|
||||
|
||||
- How should the changes be tested?
|
||||
- What existing tests should be run?
|
||||
- What new tests need to be added?
|
||||
|
||||
## Restrictions
|
||||
|
||||
- **DO NOT** use `write_to_file`.
|
||||
- **DO NOT** use `replace_file_content` or `multi_replace_file_content`.
|
||||
- **DO NOT** run commands that modify the system (like `rm`, `mv`, `sed`).
|
||||
- If you find yourself wanting to edit code, STOP and write it down as a step in the plan instead.
|
||||
@@ -1,5 +1,6 @@
|
||||
export default {
|
||||
'menu.home': 'Home',
|
||||
'menu.demo.task-board': 'Demo Task Board',
|
||||
'menu.access': 'Access',
|
||||
'menu.table': 'Table',
|
||||
'menu.users': 'User Management',
|
||||
@@ -18,6 +19,17 @@ export default {
|
||||
'pages.product.table.title': 'Product List',
|
||||
'pages.product.add': 'Create Product',
|
||||
'pages.product.edit': 'Edit Product',
|
||||
'pages.demo.task.id': 'Task ID',
|
||||
'pages.demo.task.title': 'Task Title',
|
||||
'pages.demo.task.status': 'Status',
|
||||
'pages.demo.task.priority': 'Priority',
|
||||
'pages.demo.task.createdAt': 'Created At',
|
||||
'pages.demo.task.action': 'Action',
|
||||
'pages.demo.task.status.todo': 'To Do',
|
||||
'pages.demo.task.status.doing': 'Doing',
|
||||
'pages.demo.task.status.done': 'Done',
|
||||
'pages.demo.task.edit': 'Edit',
|
||||
'pages.demo.task.delete': 'Delete',
|
||||
'pages.product.columns.name': 'Product Name',
|
||||
'pages.product.columns.category': 'Category',
|
||||
'pages.product.columns.salePrice': 'Sale Price',
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
export default {
|
||||
'menu.home': '首页',
|
||||
'menu.demo.task-board': '演示任务板',
|
||||
'menu.access': '权限演示',
|
||||
'menu.table': '查询表格',
|
||||
'menu.users': '用户管理',
|
||||
@@ -18,6 +19,17 @@ export default {
|
||||
'pages.product.table.title': '商品列表',
|
||||
'pages.product.add': '新增商品',
|
||||
'pages.product.edit': '编辑商品',
|
||||
'pages.demo.task.id': '任务ID',
|
||||
'pages.demo.task.title': '任务标题',
|
||||
'pages.demo.task.status': '状态',
|
||||
'pages.demo.task.priority': '优先级',
|
||||
'pages.demo.task.createdAt': '创建时间',
|
||||
'pages.demo.task.action': '操作',
|
||||
'pages.demo.task.status.todo': '待办',
|
||||
'pages.demo.task.status.doing': '进行中',
|
||||
'pages.demo.task.status.done': '已完成',
|
||||
'pages.demo.task.edit': '编辑',
|
||||
'pages.demo.task.delete': '删除',
|
||||
'pages.product.columns.name': '商品名称',
|
||||
'pages.product.columns.category': '分类',
|
||||
'pages.product.columns.salePrice': '售价',
|
||||
|
||||
15
src/pages/Demo/TaskBoard/data.d.ts
vendored
Normal file
15
src/pages/Demo/TaskBoard/data.d.ts
vendored
Normal file
@@ -0,0 +1,15 @@
|
||||
export interface TaskItem {
|
||||
id: string;
|
||||
title: string;
|
||||
description?: string;
|
||||
status: 'todo' | 'doing' | 'done';
|
||||
priority: number;
|
||||
createdAt: string;
|
||||
}
|
||||
|
||||
export interface TaskParams {
|
||||
pageSize?: number;
|
||||
current?: number;
|
||||
keyword?: string;
|
||||
status?: string;
|
||||
}
|
||||
335
src/pages/Demo/TaskBoard/index.tsx
Normal file
335
src/pages/Demo/TaskBoard/index.tsx
Normal file
@@ -0,0 +1,335 @@
|
||||
import {
|
||||
addTask,
|
||||
queryTaskList,
|
||||
removeTask,
|
||||
updateTask,
|
||||
} from '@/services/demo/task';
|
||||
import { DeleteOutlined, EditOutlined, PlusOutlined } from '@ant-design/icons';
|
||||
import type { ActionType, ProColumns } from '@ant-design/pro-components';
|
||||
import {
|
||||
ModalForm,
|
||||
PageContainer,
|
||||
ProFormSelect,
|
||||
ProFormText,
|
||||
ProTable,
|
||||
} from '@ant-design/pro-components';
|
||||
import { useIntl } from '@umijs/max';
|
||||
import { Button, Tag, message } from 'antd';
|
||||
import { useRef, useState } from 'react';
|
||||
import type { TaskItem } from './data';
|
||||
|
||||
export default () => {
|
||||
const actionRef = useRef<ActionType>();
|
||||
const [createModalOpen, handleModalOpen] = useState<boolean>(false);
|
||||
const [currentRow, setCurrentRow] = useState<TaskItem>();
|
||||
const [updateModalOpen, handleUpdateModalOpen] = useState<boolean>(false);
|
||||
const intl = useIntl();
|
||||
|
||||
const columns: ProColumns<TaskItem>[] = [
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.id',
|
||||
defaultMessage: 'Task ID',
|
||||
}),
|
||||
dataIndex: 'id',
|
||||
hideInSearch: true,
|
||||
width: 80,
|
||||
},
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.title',
|
||||
defaultMessage: 'Title',
|
||||
}),
|
||||
dataIndex: 'title',
|
||||
copyable: true,
|
||||
ellipsis: true,
|
||||
tip: 'The task title is unique key',
|
||||
formItemProps: {
|
||||
rules: [
|
||||
{
|
||||
required: true,
|
||||
message:
|
||||
intl.formatMessage({
|
||||
id: 'pages.demo.task.title',
|
||||
defaultMessage: 'Title',
|
||||
}) + ' is required',
|
||||
},
|
||||
],
|
||||
},
|
||||
},
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.status',
|
||||
defaultMessage: 'Status',
|
||||
}),
|
||||
dataIndex: 'status',
|
||||
filters: true,
|
||||
onFilter: true,
|
||||
valueEnum: {
|
||||
todo: {
|
||||
text: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.todo',
|
||||
defaultMessage: 'To Do',
|
||||
}),
|
||||
status: 'Default',
|
||||
},
|
||||
doing: {
|
||||
text: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.doing',
|
||||
defaultMessage: 'Doing',
|
||||
}),
|
||||
status: 'Processing',
|
||||
},
|
||||
done: {
|
||||
text: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.done',
|
||||
defaultMessage: 'Done',
|
||||
}),
|
||||
status: 'Success',
|
||||
},
|
||||
},
|
||||
render: (_, record) => {
|
||||
const colorMap: Record<string, string> = {
|
||||
todo: 'default',
|
||||
doing: 'orange',
|
||||
done: 'success',
|
||||
};
|
||||
// handle undefined status
|
||||
const color = colorMap[record.status || 'todo'] || 'default';
|
||||
const statusText = record.status
|
||||
? intl.formatMessage({
|
||||
id: `pages.demo.task.status.${record.status}`,
|
||||
defaultMessage: record.status.toUpperCase(),
|
||||
})
|
||||
: '-';
|
||||
return <Tag color={color}>{statusText}</Tag>;
|
||||
},
|
||||
},
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.priority',
|
||||
defaultMessage: 'Priority',
|
||||
}),
|
||||
dataIndex: 'priority',
|
||||
valueType: 'digit',
|
||||
sorter: true,
|
||||
hideInForm: true,
|
||||
hideInSearch: true,
|
||||
},
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.createdAt',
|
||||
defaultMessage: 'Created At',
|
||||
}),
|
||||
dataIndex: 'createdAt',
|
||||
valueType: 'dateTime',
|
||||
sorter: true,
|
||||
hideInSearch: true,
|
||||
hideInForm: true,
|
||||
},
|
||||
{
|
||||
title: intl.formatMessage({
|
||||
id: 'pages.demo.task.action',
|
||||
defaultMessage: 'Action',
|
||||
}),
|
||||
dataIndex: 'option',
|
||||
valueType: 'option',
|
||||
render: (_, record) => [
|
||||
<Button
|
||||
key="edit"
|
||||
size="small"
|
||||
type="text"
|
||||
icon={<EditOutlined />}
|
||||
onClick={() => {
|
||||
setCurrentRow(record);
|
||||
handleUpdateModalOpen(true);
|
||||
}}
|
||||
>
|
||||
{intl.formatMessage({
|
||||
id: 'pages.demo.task.edit',
|
||||
defaultMessage: 'Edit',
|
||||
})}
|
||||
</Button>,
|
||||
<Button
|
||||
key="delete"
|
||||
size="small"
|
||||
type="text"
|
||||
danger
|
||||
icon={<DeleteOutlined />}
|
||||
onClick={async () => {
|
||||
await removeTask({ id: record.id });
|
||||
actionRef.current?.reload();
|
||||
message.success('Deleted successfully');
|
||||
}}
|
||||
>
|
||||
{intl.formatMessage({
|
||||
id: 'pages.demo.task.delete',
|
||||
defaultMessage: 'Delete',
|
||||
})}
|
||||
</Button>,
|
||||
],
|
||||
},
|
||||
];
|
||||
|
||||
return (
|
||||
<PageContainer>
|
||||
<ProTable<TaskItem>
|
||||
headerTitle={intl.formatMessage({
|
||||
id: 'menu.demo.task-board',
|
||||
defaultMessage: 'Task List',
|
||||
})}
|
||||
actionRef={actionRef}
|
||||
rowKey="id"
|
||||
form={{
|
||||
layout: 'vertical',
|
||||
}}
|
||||
search={{
|
||||
labelWidth: 'auto',
|
||||
}}
|
||||
toolBarRender={() => [
|
||||
<Button
|
||||
type="primary"
|
||||
key="primary"
|
||||
onClick={() => {
|
||||
handleModalOpen(true);
|
||||
}}
|
||||
>
|
||||
<PlusOutlined />{' '}
|
||||
{intl.formatMessage({
|
||||
id: 'pages.product.add',
|
||||
defaultMessage: 'New Task',
|
||||
})}
|
||||
</Button>,
|
||||
]}
|
||||
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 */}
|
||||
<ModalForm
|
||||
title={intl.formatMessage({
|
||||
id: 'pages.product.add',
|
||||
defaultMessage: 'New Task',
|
||||
})}
|
||||
width="400px"
|
||||
layout="vertical"
|
||||
labelCol={{ span: 24 }}
|
||||
wrapperCol={{ span: 24 }}
|
||||
open={createModalOpen}
|
||||
onOpenChange={handleModalOpen}
|
||||
onFinish={async (value) => {
|
||||
await addTask(value as TaskItem);
|
||||
message.success('Added successfully');
|
||||
handleModalOpen(false);
|
||||
actionRef.current?.reload();
|
||||
return true;
|
||||
}}
|
||||
>
|
||||
<ProFormText
|
||||
rules={[{ required: true, message: 'Title is required' }]}
|
||||
name="title"
|
||||
label={intl.formatMessage({
|
||||
id: 'pages.demo.task.title',
|
||||
defaultMessage: 'Title',
|
||||
})}
|
||||
/>
|
||||
<ProFormSelect
|
||||
name="status"
|
||||
label={intl.formatMessage({
|
||||
id: 'pages.demo.task.status',
|
||||
defaultMessage: 'Status',
|
||||
})}
|
||||
valueEnum={{
|
||||
todo: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.todo',
|
||||
defaultMessage: 'To Do',
|
||||
}),
|
||||
doing: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.doing',
|
||||
defaultMessage: 'Doing',
|
||||
}),
|
||||
done: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.done',
|
||||
defaultMessage: 'Done',
|
||||
}),
|
||||
}}
|
||||
placeholder="Please select a status"
|
||||
rules={[{ required: true, message: 'Please select your status!' }]}
|
||||
/>
|
||||
</ModalForm>
|
||||
|
||||
{/* Edit Form */}
|
||||
<ModalForm
|
||||
title={intl.formatMessage({
|
||||
id: 'pages.product.edit',
|
||||
defaultMessage: 'Edit Task',
|
||||
})}
|
||||
width="400px"
|
||||
layout="vertical"
|
||||
labelCol={{ span: 24 }}
|
||||
wrapperCol={{ span: 24 }}
|
||||
open={updateModalOpen}
|
||||
onOpenChange={handleUpdateModalOpen}
|
||||
onFinish={async (value) => {
|
||||
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,
|
||||
}}
|
||||
>
|
||||
<ProFormText
|
||||
name="id"
|
||||
label={intl.formatMessage({
|
||||
id: 'pages.demo.task.id',
|
||||
defaultMessage: 'ID',
|
||||
})}
|
||||
disabled
|
||||
hidden
|
||||
/>
|
||||
<ProFormText
|
||||
name="title"
|
||||
label={intl.formatMessage({
|
||||
id: 'pages.demo.task.title',
|
||||
defaultMessage: 'Title',
|
||||
})}
|
||||
rules={[{ required: true, message: 'Title is required' }]}
|
||||
/>
|
||||
<ProFormSelect
|
||||
name="status"
|
||||
label={intl.formatMessage({
|
||||
id: 'pages.demo.task.status',
|
||||
defaultMessage: 'Status',
|
||||
})}
|
||||
valueEnum={{
|
||||
todo: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.todo',
|
||||
defaultMessage: 'To Do',
|
||||
}),
|
||||
doing: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.doing',
|
||||
defaultMessage: 'Doing',
|
||||
}),
|
||||
done: intl.formatMessage({
|
||||
id: 'pages.demo.task.status.done',
|
||||
defaultMessage: 'Done',
|
||||
}),
|
||||
}}
|
||||
/>
|
||||
</ModalForm>
|
||||
</PageContainer>
|
||||
);
|
||||
};
|
||||
57
src/services/demo/task.ts
Normal file
57
src/services/demo/task.ts
Normal file
@@ -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<TaskItem>,
|
||||
options?: { [key: string]: any },
|
||||
) {
|
||||
return request<TaskItem>('/api/demo/tasks', {
|
||||
method: 'POST',
|
||||
data,
|
||||
...(options || {}),
|
||||
});
|
||||
}
|
||||
|
||||
/** 更新任务 PUT /api/demo/tasks */
|
||||
export async function updateTask(
|
||||
data: Partial<TaskItem>,
|
||||
options?: { [key: string]: any },
|
||||
) {
|
||||
return request<TaskItem>('/api/demo/tasks', {
|
||||
method: 'PUT',
|
||||
data,
|
||||
...(options || {}),
|
||||
});
|
||||
}
|
||||
|
||||
/** 删除任务 DELETE /api/demo/tasks */
|
||||
export async function removeTask(
|
||||
data: { id: string },
|
||||
options?: { [key: string]: any },
|
||||
) {
|
||||
return request<Record<string, any>>('/api/demo/tasks', {
|
||||
method: 'DELETE',
|
||||
data,
|
||||
...(options || {}),
|
||||
});
|
||||
}
|
||||
Reference in New Issue
Block a user