lishican/agent
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: add TaskBoard demo and refactor project structure

Browse Source
This commit is contained in:
ken
2026-02-16 13:36:29 +08:00
parent ca828a6c7f
commit a4a68ec039
24 changed files with 976 additions and 1698 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
.agent/AGENT_ARCHITECTURE_V2.md
View File

@@ -163,6 +163,8 @@ graph BT
├── business/ # 💼 业务域
│ ├── order-management/
│ └── product-management/
├── design/ # 🎨 设计规范
│ └── visual-standards/
├── tech-stack/ # 🛠️ 技术栈
│ └── umijs-procomponents/
└── engineering/ # 🛡️ 通用工程

404
.agent/NO_API_HALLUCINATION_UPDATE.md
View File

@@ -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
**强制执行**: 是

281
.agent/PROCOMPONENTS_PADDING_UPDATE.md
View File

@@ -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

320
.agent/TEAM_AGENT_RESPONSIBILITY_UPDATE.md
View File

@@ -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
**强制执行**: 是

262
.agent/TEAM_V2_VERIFICATION_PLAN.md
View File

@@ -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 可选）。

16
.agent/agent_team_coordinator_prompt.md
View File

@@ -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
View 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` 状态。

77
.agent/skills/tech-stack/umijs-procomponents/SKILL.md
View File

@@ -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
View 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`