# 全系统测试 + 阶段3业务组件抽象执行计划

## 任务概述

用户要求先执行全系统测试，测试通过后执行阶段3的业务组件抽象。本计划分为两个主要阶段：

1. **全系统测试**：运行现有E2E测试套件，验证系统功能完整性
2. **阶段3业务组件抽象**：创建配置化组件，解决架构债务

---

## 第一阶段：全系统测试

### 1.1 测试前准备

- [ ] 确认 dev server 正在运行（端口3015）
- [ ] 检查 Playwright 依赖是否已安装
- [ ] 验证数据库连接状态（`meoo-cli cloud status`）

### 1.2 执行测试套件

项目包含3个E2E测试文件：
- `e2e/auth.setup.ts` - 认证设置
- `e2e/core-workflow.spec.ts` - 核心工作流测试
- `e2e/collaboration-workflow.spec.ts` - 协作工作流测试
- `e2e/full-workflow.spec.ts` - 全流程模拟测试（采购商→纺织厂完整流程）

**执行命令**：
```bash
# 运行所有E2E测试
pnpm exec playwright test

# 或仅运行特定测试文件
pnpm exec playwright test e2e/full-workflow.spec.ts
```

### 1.3 测试结果验证

- [ ] 所有测试用例通过
- [ ] 无控制台错误
- [ ] 无运行时异常
- [ ] 数据一致性验证通过

### 1.4 测试失败处理策略

如果测试失败：
1. 分析失败原因（UI变更、数据问题、网络问题）
2. 修复代码或测试用例
3. 重新运行测试直至全部通过
4. 记录测试结果到 AGENTS.md

---

## 第二阶段：阶段3业务组件抽象

根据 AGENTS.md 中的优化路线图，阶段3包含以下任务：

### 2.1 创建 DashboardLayout 配置化组件

**目标**：统一三个角色 Dashboard 的布局结构，消除 ~70% 的代码重复

**文件位置**：`src/components/layout/DashboardLayout.tsx`

**设计要点**：
- 接收 `role` 参数（purchaser/textile/washing）
- 根据角色自动应用对应主题色（amber/emerald/violet）
- 统一 Header、统计卡片区域、快捷操作区域的布局
- 支持自定义内容插槽（children）
- 集成 NotificationCenter、HelpCenter 等通用组件

**替换目标**：
- `src/pages/purchaser/Dashboard.tsx`
- `src/pages/textile/Dashboard.tsx`
- `src/pages/washing/Dashboard.tsx`

### 2.2 创建 PaymentCard 组件

**目标**：统一采购商和水洗厂的付款展示

**文件位置**：`src/components/PaymentCard.tsx`

**设计要点**：
- 支持付款方/收款方两种视角
- 显示金额、状态、时间等关键信息
- 支持主题色适配
- 提供操作按钮（确认、详情等）

**替换目标**：
- `src/pages/purchaser/AccountsPayable.tsx` 中的内联实现
- `src/pages/washing/PaymentPending.tsx` 中的内联实现

### 2.3 创建 AccountProfileCard 组件

**目标**：统一三个角色的账户信息弹窗

**文件位置**：`src/components/AccountProfileCard.tsx`

**设计要点**：
- 显示用户头像、名称、公司信息
- 支持头像上传功能
- 集成功能菜单（账号管理、用户手册、反馈、关于）
- 支持主题色适配

**替换目标**：
- 3个 Dashboard 中的账户卡片弹窗内联实现

### 2.4 创建 ImageUploader 组件

**目标**：统一图片上传功能，消除4+处重复实现

**文件位置**：`src/components/ImageUploader.tsx`

**设计要点**：
- 支持预览、重新上传、删除
- 文件大小和格式验证
- 上传进度显示
- 错误处理和用户反馈
- 集成 Supabase Storage

**替换目标**：
- `src/components/warehouse/ProductForm.tsx` 中的图片上传
- 其他需要图片上传的场景

### 2.5 创建 WashingLayout 组件（解决架构债务）

**目标**：为水洗厂创建独立 Layout 组件，与采购商/纺织厂保持一致

**文件位置**：`src/components/layout/WashingLayout.tsx`

**设计要点**：
- 参考 PurchaserLayout 和 TextileLayout 的结构
- 使用 violet 主题色
- 包含6项导航：首页、计划总览、待处理坯布、已完成坯布、成品仓库、待结款
- 支持移动端折叠导航

**路由调整**：
- 将水洗厂的扁平路由改为嵌套路由模式
- 更新 `src/App.tsx` 中的路由配置

### 2.6 统一实时订阅至 useRealtime

**目标**：将所有直接使用 `supabase.channel` 的地方迁移到 `useRealtime` Hook

**涉及文件**：
- `src/pages/textile/PlanOverview.tsx` - 直接订阅 inventory_records
- 其他绕过单例管理器的页面

**实施步骤**：
1. 识别所有直接使用 `supabase.channel` 的位置
2. 评估是否适合迁移到 useRealtime
3. 逐步替换并验证功能

---

## 执行顺序与依赖关系

```
全系统测试
    ↓ (测试通过后)
DashboardLayout (基础，其他组件可能依赖)
    ↓
WashingLayout (解决架构债务，优先级高)
    ↓
AccountProfileCard (3个Dashboard都使用)
    ↓
PaymentCard (财务模块)
    ↓
ImageUploader (产品管理)
    ↓
统一实时订阅 (最后优化)
```

---

## 验证标准

每个组件完成后需验证：
- [ ] TypeScript 类型检查通过 (`pnpm run typecheck`)
- [ ] Dev server 正常启动 (`pnpm run dev`)
- [ ] 相关页面功能正常
- [ ] 移动端响应式正常
- [ ] 主题色正确应用

---

## 风险与注意事项

1. **测试环境依赖**：E2E测试需要 dev server 运行在 localhost:3015
2. **数据库状态**：测试可能修改数据库数据，建议在测试前备份
3. **组件替换风险**：替换内联实现时需保持功能完全一致
4. **路由变更**：WashingLayout 会改变路由结构，需全面测试
5. **向后兼容**：新组件应支持现有所有功能，避免破坏性变更

---

## 预期产出

完成本计划后：
- 全系统测试报告（通过/失败统计）
- 5个新的共享组件
- 3个 Dashboard 代码量减少约 50%
- 水洗厂获得独立 Layout，架构债务解决
- 实时更新机制统一，内存泄漏风险降低