规则文件

2026-02-03 09:56:24 +08:00
parent 83a669033c
commit d8668ac1d3
2 changed files with 103 additions and 0 deletions
--- a/.trae/rules/mock-data.md
+++ b/.trae/rules/mock-data.md
@@ -0,0 +1,63 @@
+---
+alwaysApply: false
+description: 当新增包含业务逻辑的组件、页面或 API 请求时，必须同步创建符合真实性标准、类型规范及包含边缘情况的 Mock 数据。
+---
+# Mock Data Rules for Funtime Design System
+
+These rules define the standards for creating, managing, and using mock data within the project. The goal is to ensure the development environment closely mirrors the production experience.
+
+## 1. General Principles
+
+- **Realism First**: NEVER use meaningless placeholders like "test1", "demo", "asdf", or "123". Data must look and feel like real production data.
+- **Context Relevance**: Data must be relevant to the "Funtime Design" domain (e.g., design projects, assets, team members, creative workflows).
+- **Consistency**: Ensure relationships between data entities make logical sense (e.g., a "published" project shouldn't have a creation date in the future).
+- **Completeness**: Mock APIs should simulate latency (e.g., 300-800ms) to test loading states.
+
+## 2. Data Content Standards
+
+### Text Data
+- **Names**: Use realistic full names (e.g., "Sarah Jenkins", "Michael Chen") or creative project names (e.g., "Summer 2024 Campaign", "Mobile App Redesign").
+- **Descriptions**: Use complete sentences or paragraphs. Use Lorem Ipsum sparingly; prefer domain-specific generated text if possible, or meaningful placeholder text.
+- **IDs**: Use UUIDs or realistic database IDs (e.g., `1001`, `9482`) rather than sequential single digits (`1`, `2`, `3`) unless specifically testing ordering.
+
+### Visual Assets
+- **Images**: Use consistent, high-quality placeholder image services or local assets.
+  - Avatars: `https://i.pravatar.cc/150?u={id}`
+  - Thumbnails: `https://picsum.photos/seed/{seed}/400/300`
+- **Colors**: Use hex codes that align with the design system palette or realistic user-generated choices.
+
+### Dates & Numbers
+- **Dates**: Use ISO 8601 format (`2023-10-27T10:00:00Z`) or standard display formats. Distribute dates to show a timeline (past, recent, future).
+- **Metrics**: Use realistic ranges (e.g., views: 100-50000, not 999999999).
+
+## 3. Technical Implementation
+
+### Structure
+- **Response Wrapper**: All API responses must follow the standard response envelope:
+  ```typescript
+  interface ApiResponse<T> {
+    code: number;      // 0 or 200 for success
+    message: string;   // "success" or error message
+    data: T;           // The actual payload
+  }
+  ```
+- **Pagination**: List interfaces must support and mock pagination metadata:
+  ```typescript
+  interface PageResult<T> {
+    items: T[];
+    total: number;
+    page: number;
+    pageSize: number;
+  }
+  ```
+
+### Tooling
+- **Library**: Use `vite-plugin-mock` for API interception.
+- **Location**: Store mock definitions in `mock/` directory at the project root.
+- **Typing**: All mock data generators must be typed against the project's TypeScript interfaces.
+
+## 4. Edge Cases Coverage
+
+- **Empty States**: Ensure there are scenarios or toggles to test empty lists/tables.
+- **Long Content**: Include items with unusually long titles or descriptions to test text truncation and layout stability.
+- **Status Variations**: Include all possible enum values (e.g., 'Draft', 'Pending', 'Published', 'Archived') to verify UI badge variations.