@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/templates/shared/rules/fec-agent-workflow.md

@@ -1,54 +1,54 @@
-# 子代理协作规则
+# Subagent collaboration rules
 
-当前端任务涉及多视角分析、跨模块规划、专项质量审查或验证失败修复时，优先使用职责明确的子代理。
+When front-end tasks involve multi-perspective analysis, cross-module planning, dedicated quality reviews, or verification failure repairs, give priority to using subagents with clear responsibilities.
 
-## 选择原则
+## Selection principle
 
-- 架构、页面拆分、状态流、目录规划：`fec-architect`
-- 前端 PR 综合评审：`fec-code-reviewer`
-- TypeScript / JavaScript 语义与类型风险：`fec-typescript-reviewer`
-- 安全风险：`fec-security-reviewer`
-- 测试策略：`fec-test-planner`
-- E2E 编写与运行：`fec-e2e-runner`
-- 性能瓶颈：`fec-performance-optimizer`
-- 来源/版本敏感决策：优先由主代理查项目事实和官方来源，再交给专项代理落地
-- UI 视觉与设计稿差异：`fec-ui-checker`
-- 设计稿实现：`fec-figma-implementer`
-- Token 映射：`fec-design-token-mapper`
-- 构建、类型、测试、CI 失败：`fec-build-fixer`
-- 死代码与无用依赖清理：`fec-refactor-cleaner`
-- README、runtime docs、能力表同步：`fec-doc-updater`
+- Architecture, page splitting, state flow, directory planning: `fec-architect`
+- Front-end PR comprehensive review: `fec-code-reviewer`
+- TypeScript/JavaScript semantics and type risks: `fec-typescript-reviewer`
+- Security risk: `fec-security-reviewer`
+- Test strategy: `fec-test-planner`
+- E2E writing and running: `fec-e2e-runner`
+- Performance bottleneck: `fec-performance-optimizer`
+- Source/version sensitive decision-making: Prioritize the agent to check the project facts and official sources, and then hand it over to the special agent for implementation
+- Differences between UI visual and design draft: `fec-ui-checker`
+- Design draft implementation: `fec-figma-implementer`
+- Token mapping: `fec-design-token-mapper`
+- Build, type, test, CI failed: `fec-build-fixer`
+- Dead code and useless dependency cleaning: `fec-refactor-cleaner`
+- README, runtime docs, capability table synchronization: `fec-doc-updater`
 
-## 多代理评审编排
+## Multi-agent review orchestration
 
-复杂 PR 可按质量维度并行评审，但必须有主代理负责合并结论。
+Complex PRs can be reviewed in parallel along quality dimensions, but a lead agent must be responsible for merging conclusions.
 
-| 变更类型 | 建议组合 | 主合并者 |
+| Change Type | Recommended Combination | Master Consolidator |
 | --- | --- | --- |
 | UI feature | `fec-code-reviewer` + `fec-typescript-reviewer` + `fec-test-planner` | `fec-code-reviewer` |
-| 鉴权 / 上传 / 富文本 | `fec-security-reviewer` + `fec-code-reviewer` | `fec-security-reviewer` |
-| 大列表 / 图表 / 3D / 性能问题 | `fec-performance-optimizer` + `fec-code-reviewer` | `fec-performance-optimizer` |
-| 设计稿落地 | `fec-figma-implementer` + `fec-ui-checker` + `fec-code-reviewer` | `fec-figma-implementer` |
-| 大型重构 | `fec-architect` + `fec-refactor-cleaner` + `fec-test-planner` | `fec-architect` |
+| Authentication / Upload / Rich Text | `fec-security-reviewer` + `fec-code-reviewer` | `fec-security-reviewer` |
+| Big List / Charts / 3D / Performance Issues | `fec-performance-optimizer` + `fec-code-reviewer` | `fec-performance-optimizer` |
+| Design draft landing | `fec-figma-implementer` + `fec-ui-checker` + `fec-code-reviewer` | `fec-figma-implementer` |
+| Large refactoring | `fec-architect` + `fec-refactor-cleaner` + `fec-test-planner` | `fec-architect` |
 
-合并规则：
+Merge rules:
 
-- 相同文件、相同行号、相同根因的问题合并为一条，保留最高严重级别。
-- 相同根因分布在多处时写成模式级发现，列代表性位置，不逐行刷屏。
-- 结论冲突时先回到项目事实、测试结果和用户影响，不用代理身份决定谁对。
-- 主代理输出最终 Verdict，并列出各专项代理覆盖的范围和未覆盖范围。
+- Problems with the same file, same line number, and same root cause are merged into one, and the highest severity level is retained.
+- When the same root cause is distributed in multiple places, it is written as a pattern-level discovery. The representative positions are listed and the screen is not refreshed line by line.
+- When conclusions conflict, go back to the project facts, test results and user impact first, and do not use an agent's identity to decide who is right.
+- The main agent outputs the final Verdict and lists the coverage and non-coverage ranges of each special agent.
 
-## 协作约束
+## Collaboration constraints
 
-- 委托前先明确范围、输入和输出，不把模糊任务丢给子代理。
-- 多个独立问题可以并行分析；彼此有依赖的任务按顺序推进。
-- 子代理输出必须落到可验证结论：报告、文件路径、命令结果或具体风险。
-- 子代理建议不自动等于实现决策；与仓库现有约定冲突时，优先遵循仓库约定。
-- 主代理必须复核关键证据、验证命令和改动边界，不能只转述子代理结论。
+- Clarify the scope, input and output before delegating, and do not leave ambiguous tasks to sub-agents.
+- Multiple independent problems can be analyzed in parallel; tasks that depend on each other are advanced in sequence.
+- Subagent output must lead to verifiable conclusions: reports, file paths, command results, or specific risks.
+- Subagent suggestions do not automatically equal implementation decisions; when they conflict with the existing contracts of the warehouse, the warehouse contracts take precedence.
+- The primary agent must review key evidence, verify orders, and change boundaries, and cannot just relay the subagent's conclusions.
 
-## 反模式
+## Anti-pattern
 
-- 为简单单文件修改创建过多代理。
-- 让多个代理同时修改同一文件而没有边界。
-- 用子代理替代本应先做的代码阅读。
-- 只接收结论，不核对关键证据和验证命令。
+- Too many proxies were created for simple single file modifications.
+- Let multiple agents modify the same file simultaneously without boundaries.
+- Use subagent instead of code reading that should be done first.
+- Only conclusions are received, key evidence and verification orders are not checked.

package/templates/shared/rules/fec-api-layer.md

@@ -1,35 +1,35 @@
-# API 层规范
+# API layer specification
 
-凡是涉及 HTTP 请求、接口调用、数据获取或错误处理时，都应用本文件。
+This document applies whenever HTTP requests, interface calls, data retrieval, or error handling are involved.
 
-## 核心原则
+## Core Principles
 
-- 请求和响应必须有类型定义
-- 统一错误处理，不在每个组件中重复 try-catch
-- API 层与 UI 层分离
-- 敏感操作（删除、支付）必须有二次确认
+- Requests and responses must have type definitions
+- Unify error handling without repeating try-catch in each component
+-Separation of API layer and UI layer
+- Sensitive operations (deletion, payment) must require a second confirmation
 
-## 目录结构
+## Directory structure
 
-<!-- 请根据项目实际情况调整 -->
+<!-- Please adjust according to the actual situation of the project -->
 
 ```
 src/
-├── api/                    # API 定义层
+├── api/ # API definition layer
 │   ├── modules/
-│   │   ├── user.ts         # 用户相关接口
-│   │   ├── order.ts        # 订单相关接口
+│ │ ├── user.ts # User related interface
+│ │ ├── order.ts # Order related interface
 │   │   └── ...
-│   ├── types/              # 请求/响应类型
+│ ├── types/ # Request/response type
 │   │   ├── user.types.ts
 │   │   └── order.types.ts
-│   └── request.ts          # 统一请求封装
+│ └── request.ts # Unified request encapsulation
 ```
 
-## 类型规范
+## Type specification
 
 ```typescript
-// 请求参数类型
+//Request parameter type
 interface GetUserListParams {
     page: number;
     pageSize: number;
@@ -37,7 +37,7 @@ interface GetUserListParams {
     status?: UserStatus;
 }
 
-// 响应数据类型
+//Response data type
 interface GetUserListResponse {
     list: User[];
     total: number;
@@ -45,55 +45,55 @@ interface GetUserListResponse {
     pageSize: number;
 }
 
-// API 函数签名
+// API function signature
 export function getUserList(params: GetUserListParams): Promise<GetUserListResponse>;
 ```
 
-要求：
+Requirements:
 
-- 禁止使用 `any` 作为请求参数或响应类型
-- 枚举值使用 TypeScript enum 或 union type
-- 分页参数和响应格式保持统一
+- Disallow the use of `any` as a request parameter or response type
+- Use TypeScript enum or union type for enumeration values
+- Pagination parameters and response format remain unified
 
-## 错误处理
+## Error handling
 
-### 统一拦截器
+### Unified Interceptor
 
-在请求封装层统一处理：
+Unified processing at the request encapsulation layer:
 
-- 401: 跳转登录或刷新 token
-- 403: 提示无权限
-- 500: 显示通用错误提示
-- 网络错误: 显示网络异常提示
+- 401: Jump to login or refresh token
+- 403: Prompt No Permission
+- 500: Display general error message
+- Network error: Display network exception prompts
 
-### 业务错误
+### Business error
 
-- 业务错误码与 HTTP 状态码分离
-- 业务错误信息使用 i18n key（如支持国际化）
-- 需要用户操作的错误（如表单校验失败）由调用方处理
+- Separate business error codes and HTTP status codes
+- Business error messages use i18n key (if internationalization is supported)
+- Errors that require user action (such as form validation failure) are handled by the caller
 
-## Loading / Error / Empty 状态
+## Loading / Error / Empty status
 
-每个数据请求场景都需要考虑：
+Each data request scenario needs to be considered:
 
-- **Loading**: 首次加载 skeleton/spinner，后续刷新不阻断 UI
-- **Error**: 显示错误信息 + 重试按钮
-- **Empty**: 显示空状态占位 + 引导操作
+- **Loading**: Load skeleton/spinner for the first time, subsequent refreshes will not block the UI
+- **Error**: display error message + retry button
+- **Empty**: Display empty status placeholder + boot operation
 
-## 检查清单
+## Checklist
 
-- [ ] 请求参数和响应有明确类型
-- [ ] 错误处理不依赖每个组件各自 try-catch
-- [ ] Loading / Error / Empty 三态均已处理
-- [ ] 敏感操作有二次确认
-- [ ] Token / 鉴权信息不在请求 URL 中明文传递
-- [ ] 大数据量使用分页或流式加载
+- [ ] Request parameters and responses have clear types
+- [ ] Error handling does not rely on each component's own try-catch
+- [ ] Loading / Error / Empty three states have been processed
+- [ ] Sensitive operations have secondary confirmation
+- [ ] Token/authentication information is not passed in clear text in the request URL
+- [ ] Use paging or streaming loading for large amounts of data
 
-## 反模式
+## Anti-pattern
 
-- 在组件中直接使用 `fetch` / `axios` 而不经过统一封装
-- 请求参数或响应使用 `any`
-- 忽略错误处理，只处理成功场景
-- 将 token 拼接在 URL 中
-- 在 GET 请求中传递敏感数据
-- 同一个接口在多个文件中重复定义
+- Use `fetch` / `axios` directly in components without unified encapsulation
+- Use `any` for request parameters or responses
+- Ignore error handling and only handle success scenarios
+- Splice token into URL
+- Pass sensitive data in GET requests
+- The same interface is repeatedly defined in multiple files

package/templates/shared/rules/fec-ci-cd.md

@@ -1,40 +1,40 @@
-# CI/CD 规则
+# CI/CD rules
 
-本文件约定持续集成与部署流水线的常驻结构与门禁。具体 GitHub Actions、GitLab CI、云平台或 monorepo pipeline 写法，应按项目现有 CI 模板实现，不在本规则中复制长 YAML。
+This document stipulates the resident structure and access control of the continuous integration and deployment pipeline. The specific writing method of GitHub Actions, GitLab CI, cloud platform or monorepo pipeline should be implemented according to the existing CI template of the project, and long YAML will not be copied in this rule.
 
-## 流水线阶段
+## Pipeline stage
 
-建议顺序：
+Suggested order:
 
-1. **安装依赖**：使用锁文件安装，例如 `npm ci` 或 `pnpm install --frozen-lockfile`。
-2. **Lint / Format 检查**：ESLint、Stylelint、Prettier check 或项目等价命令。
-3. **类型检查**：`tsc --noEmit` 或项目 typecheck 脚本。
-4. **单元 / 组件测试**：Jest、Vitest、Testing Library、Vue Test Utils 等。
-5. **构建**：项目生产构建命令。
-6. **专项质量门禁**：包体、Lighthouse、依赖安全、license、a11y、视觉回归、E2E，按风险启用。
-7. **部署**：仅在前序门禁通过后上传产物或触发部署。
+1. **Install dependencies**: Use lock file installation, such as `npm ci` or `pnpm install --frozen-lockfile`.
+2. **Lint / Format check**: ESLint, Stylelint, Prettier check or project equivalent command.
+3. **Type check**: `tsc --noEmit` or project typecheck script.
+4. **Unit/component testing**: Jest, Vitest, Testing Library, Vue Test Utils, etc.
+5. **Build**: Project production build command.
+6. **Special quality access control**: package body, lighthouse, dependency security, license, a11y, visual regression, E2E, enabled according to risk.
+7. **Deployment**: Only upload products or trigger deployment after the pre-order access control is passed.
 
-任一必需阶段失败都应中止后续步骤。
+Failure at any required stage should abort subsequent steps.
 
-## 环境变量与密钥
+## Environment variables and keys
 
-- 敏感信息使用 CI 平台 Secrets，不写入仓库、日志或构建产物。
-- 只允许公开前缀的环境变量进入客户端 bundle，例如 `VITE_*`、`NEXT_PUBLIC_*` 等；服务端密钥不得使用公开前缀。
-- E2E 的 baseURL、测试账号、第三方 token 等从 Secrets 或受控测试环境读取。
-- CI 日志要避免打印完整环境变量、请求 header、token 或私密配置。
+- Sensitive information uses CI platform Secrets and is not written to the warehouse, logs or build products.
+- Only environment variables with public prefixes are allowed to enter the client bundle, such as `VITE_*`, `NEXT_PUBLIC_*`, etc.; server keys must not use public prefixes.
+- E2E's baseURL, test account, third-party token, etc. are read from Secrets or controlled test environment.
+- CI logs should avoid printing complete environment variables, request headers, tokens or private configurations.
 
-## 产物与证据
+## Products and Evidence
 
-- 上传或保留测试报告、覆盖率、E2E trace、截图、构建产物、包体报告和性能预算结果。
-- CI 失败时保留足够日志定位根因，不只返回“命令失败”。
-- 发布前确认版本、变更说明、迁移事项、回滚路径和影响范围。
-- 依赖升级 PR 保留 lockfile diff、关键包版本、release notes 摘要和验证矩阵。
-- Monorepo affected 快速验证可以用于 PR 反馈，但 release 或主干合并前应保留全量验证入口。
+- Upload or save test reports, coverage, E2E traces, screenshots, build artifacts, package reports and performance budget results.
+- When CI fails, keep enough logs to locate the root cause and not just return "command failure".
+- Confirm version, change description, migration matters, rollback path and impact scope before release.
+- Dependency upgrade PR retains lockfile diff, key package version, release notes summary and verification matrix.
+- Monorepo affected quick verification can be used for PR feedback, but the full verification entry should be retained before release or trunk merging.
 
-## 强约束
+##Strong constraints
 
-- 使用并提交锁文件，禁止无锁安装。
-- 构建产物不提交到源码仓库，由 CI 生成并上传。
-- 部署前必须通过项目定义的 lint、typecheck、test、build。
-- 不跳过失败门禁直接部署，除非有明确风险接受、审批记录和回滚方案。
-- CI 配置应复用项目已有命令，不在流水线里发明与本地不同的替代命令。
+- Use and submit lock files to disable lockless installations.
+- The build products are not submitted to the source code repository, but are generated and uploaded by CI.
+- Project-defined lint, typecheck, test, and build must be passed before deployment.
+- Do not skip failed access control and deploy directly unless there are clear risk acceptance, approval records and rollback plans.
+- CI configuration should reuse existing commands in the project and do not invent alternative commands in the pipeline that are different from local ones.

package/templates/shared/rules/fec-code-comments.md

@@ -1,33 +1,33 @@
-# 代码注释
+# Code comments
 
-编写或评审前端实现时应用本文件。
+Use this document when writing or reviewing front-end implementations.
 
-## 原则
+## Principles
 
-- 意图优先靠**命名、类型与结构**表达；注释用于说明**为什么**、**约束与背景**，而不是复述代码在做什么。
-- 避免「整文件零注释」：在**非显而易见**处用**简短**注释降低误改成本，与「不写废话注释」不矛盾。
+- Intention is expressed first through **naming, type and structure**; comments are used to explain **why**, **constraints and background**, rather than reiterating what the code is doing.
+- Avoid "zero comments in the entire file": Use **short** comments in **non-obvious** places to reduce the cost of accidental modifications, which is not inconsistent with "no nonsense comments".
 
-## 应当注释的情况
+## Situations that should be commented
 
-- **业务或产品规则**：权限、展示条件、校验逻辑背后的依据（与需求或领域约定相关时）。
-- **非直观的实现或取舍**：为何选用当前写法（性能、兼容、与后端/第三方约定等）。
-- **外部契约**：与接口、设计稿、枚举或单位相关的字段含义、映射关系。
-- **临时方案与技术债**：`TODO` / `FIXME` 应写明预期收尾或关联工单（若有）。
-- **易踩坑点**：第三方库版本差异、必须满足的调用顺序、已知限制。
+- **Business or product rules**: permissions, display conditions, and the basis behind the verification logic (when related to requirements or domain agreements).
+- **Non-intuitive implementation or trade-offs**: Why choose the current writing method (performance, compatibility, agreement with backend/third party, etc.).
+- **External Contract**: Field meanings and mapping relationships related to interfaces, design drafts, enumerations or units.
+- **Interim Solutions and Technical Debt**: `TODO` / `FIXME` should indicate expected closure or associated work orders (if any).
+- **Easy pitfalls**: Third-party library version differences, the calling sequence that must be met, and known limitations.
 
-## 应避免的情况
+## Situations to avoid
 
-- 逐行翻译已能从代码直接看出的行为。
-- 注释与实现长期不一致；修改逻辑时同步更新或删除误导性注释。
-- 用大段注释代替应抽取的函数或应补全的类型。
+- Line-by-line translation of behavior that can be seen directly from the code.
+- Annotations are chronically inconsistent with the implementation; misleading annotations are updated or deleted synchronously when the logic is modified.
+- Use large comments to replace functions that should be extracted or types that should be completed.
 
-## 形式建议
+## Format Suggestions
 
-- 语言与仓库现有注释保持一致（中文或英文）。
-- 复杂模块或组件可在文件顶部用 **1～3 行** 说明职责与关键约束；跨包或对外导出的 API 宜用 **JSDoc** 说明参数、返回值与副作用。
-- 复杂条件分支或 `useEffect`：若依赖或触发条件不直观，用一行说明**触发条件**或**不变量**。
-- 临时规避、兼容旧系统或性能取舍必须说明原因和退出条件。
+- The language is consistent with the existing comments in the warehouse (Chinese or English).
+- Complex modules or components can use **1~3 lines** at the top of the file to describe responsibilities and key constraints; cross-package or externally exported APIs should use **JSDoc** to describe parameters, return values and side effects.
+- Complex conditional branches or `useEffect`: If the dependency or triggering condition is not intuitive, use one line to describe the **triggering condition** or **invariant**.
+- Temporary circumvention, compatibility with old systems or performance trade-offs must state reasons and exit conditions.
 
-## 文档同步
+## Document synchronization
 
-当修改公开命令、skill、agent、模板、报告命名或安装路径时，同步更新 README、runtime docs、项目结构文档和多语言说明。注释解释局部代码，公开文档解释团队如何使用能力，两者不要互相替代。
+When modifying public commands, skills, agents, templates, report naming or installation paths, synchronize updates to README, runtime docs, project structure documents and multi-language instructions. Comments explain local code, and public documentation explains how the team uses capabilities. The two should not replace each other.

package/templates/shared/rules/fec-design-system.md

@@ -1,72 +1,72 @@
-# 设计系统规则
+# Design system rules
 
-凡是任务涉及 UI 实现、设计稿转代码、样式、设计 Token 或组件复用时，都应用本文件。本文只保留项目常驻设计约束；产品化设计方向、设计系统生成、页面级 override、UI QA 细节交给 `fec-ui-design`；Tailwind token、variant、dark mode 和 class 治理交给 `fec-tailwind-design-system`；响应式布局交给 `fec-responsive-layout`。
+This document should be used whenever the task involves UI implementation, design draft conversion to code, style, design token, or component reuse. This article only retains the project's resident design constraints; product design direction, design system generation, page-level override, and UI QA details are handed over to `fec-ui-design`; Tailwind token, variant, dark mode and class management are handed over to `fec-tailwind-design-system`; responsive layout is handed over to `fec-responsive-layout`.
 
-## 核心优先级
+## Core priority
 
-1. 复用已有组件。
-2. 在已有组件上扩展。
-3. 创建新的叶子组件。
-4. 只有在理由充分、边界清晰且会被复用时，才创建新的共享基础组件。
+1. Reuse existing components.
+2. Expand on existing components.
+3. Create a new leaf component.
+4. Only create new shared base components if there is good reason, clear boundaries, and if they will be reused.
 
-## 产品化设计方向
+## Product design direction
 
-- 工具型页面、SaaS 后台、CRM、运营台：优先安静、密集、可扫描，首屏直接呈现核心工作区。
-- 品牌页、作品集、发布页：可以更有表现力，但 H1 应是品牌、产品、对象或品类，说明文案放在副标题。
-- 可视化、游戏、创作工具：可以使用更强视觉资产和动效，但必须保持交互可控、状态清晰。
-- 每个重要界面都应有贴合业务的视觉锚点，例如真实媒体、数据形态、行业材质、字体性格、空间组织或交互节奏。
-- 大胆设计必须服务场景；高频工具重效率和稳定，展示型页面重主体识别和记忆点。
+- Tool-type pages, SaaS backend, CRM, and operations desk: Prioritize quiet, dense, and scannable, and the core work area is directly displayed on the first screen.
+- Brand page, portfolio, release page: It can be more expressive, but H1 should be the brand, product, object or category, and the description copy should be placed in the subtitle.
+- Visualization, games, and creative tools: You can use stronger visual assets and animations, but you must keep the interaction controllable and the status clear.
+- Every important interface should have a visual anchor that fits the business, such as real media, data form, industry material, font character, spatial organization or interaction rhythm.
+- Bold design must serve the scene; high-frequency tools focus on efficiency and stability, and display-type pages focus on subject recognition and memory points.
 
-避免：
+Avoid:
 
-- 把日常高频工具做成营销落地页。
-- 默认使用紫色渐变、装饰光斑、堆叠卡片、空泛 hero 或无语境默认字体。
-- 页面区块大面积卡片化，尤其是卡片套卡片。
-- 用可见说明文字解释常见控件本该表达的功能。
-- 让整个界面只由一个色相的深浅变化组成。
+- Turn daily high-frequency tools into marketing landing pages.
+- Use purple gradient, decorative light spots, stacked cards, empty hero or non-contextual default font by default.
+- Large areas of the page are card-based, especially card sets.
+- Use visible explanatory text to explain the functions that common controls are supposed to express.
+- Let the entire interface consist of only one shade of hue.
 
-## 设计稿转代码规则
+## Design draft conversion code rules
 
-- 有设计上下文时，先通过 MCP 或截图/标注读取事实来源，不靠猜测决定布局、间距、字体、颜色或状态。
-- 设计稿中的颜色、间距、圆角、阴影和字体应映射到现有 token、CSS 变量、主题变量或组件 variant。
-- 创建新组件前先检查现有组件库和业务组件，优先复用。
-- 默认验证 mobile(375px)、tablet(768px)、desktop(1440px)。
-- 像素还原要求以项目约定为准；没有约定时，核心结构、间距、字体、状态和交互优先于机械追求截图重合。
-- 复杂设计任务实现前先给出简短实现计划，说明复用组件、新建组件、可能改动文件、响应式策略和 token 映射。
+- When given design context, read the source of truth first through MCP or screenshots/annotations, and don’t rely on guesswork to determine layout, spacing, fonts, colors, or status.
+- Colors, spacing, rounded corners, shadows, and fonts in the design should be mapped to existing tokens, CSS variables, theme variables, or component variants.
+- Check existing component libraries and business components before creating new components and prioritize reuse.
+- Default verification is mobile(375px), tablet(768px), desktop(1440px).
+- Pixel restoration requirements are subject to the project agreement; if there is no agreement, the core structure, spacing, fonts, status and interaction will take precedence over mechanical pursuit of screenshot overlap.
+- Before implementing complex design tasks, a brief implementation plan is given, describing reused components, new components, possible changed files, responsive strategies and token mapping.
 
-## 设计 Token 与样式
+## Design Token and style
 
-- 优先使用已有 design token、CSS 变量或主题变量；不要硬编码颜色、圆角、间距、阴影和字体取值。
-- 缺少所需 token 时要明确指出，并集中补齐或记录，不在多个组件里散落字面量。
-- Tailwind 项目中，token 应通过语义化 `theme.extend`、CSS 变量或组件 variant 承接；不要把 `blue-600`、`rounded-xl` 等具体值复制成事实标准。
-- 组件 variant 应区分语义 tone、尺寸 size、密度 density 和状态 state；不要让一个字符串参数同时承载多种业务含义。
-- 动态 Tailwind class 必须可被构建扫描识别；复杂映射使用显式对象、variant 工具或 safelist。
-- 优先使用局部、受控的样式，不做大范围全局覆盖；与项目现有 CSS Modules、Tailwind、组件库或样式体系保持一致。
+- Prefer using existing design tokens, CSS variables, or theme variables; do not hard-code colors, rounded corners, spacing, shadows, and font values.
+- When required tokens are missing, clearly point them out and centrally complete or record them, rather than scattering literals in multiple components.
+- In the Tailwind project, tokens should be inherited through semantic `theme.extend`, CSS variables or component variants; do not copy specific values such as `blue-600` and `rounded-xl` into de facto standards.
+- Component variants should distinguish semantic tone, size, density and state; do not let a string parameter carry multiple business meanings at the same time.
+- Dynamic Tailwind classes must be recognized by build scans; use explicit objects, variant tools, or safelist for complex mappings.
+- Prioritize the use of local, controlled styles instead of large-scale global coverage; be consistent with the project's existing CSS Modules, Tailwind, component libraries or style systems.
 
-## 界面质感基线
+## Interface texture baseline
 
-- 嵌套圆角保持光学关系：外层圆角约等于内层圆角 + 间距。
-- 图标按钮、箭头、播放三角等非对称图形按视觉中心微调。
-- 小控件命中区域至少 40x40px，空间允许时优先 44x44px。
-- 标题和短文本可用 `text-wrap: balance`，短中正文可用 `text-wrap: pretty`。
-- 计数器、价格、时间、表格数字使用 `font-variant-numeric: tabular-nums`。
-- 动效只声明实际变化属性，禁止 `transition: all` 和 `will-change: all`，并尊重 `prefers-reduced-motion`。
+- Nested fillets maintain an optical relationship: the outer fillet is approximately equal to the inner fillet + spacing.
+- Asymmetric graphics such as icon buttons, arrows, and playback triangles are fine-tuned according to the visual center.
+- The hit area of the small control should be at least 40x40px, and 44x44px is preferred if space allows.
+- `text-wrap: balance` can be used for titles and short texts, and `text-wrap: pretty` can be used for short and medium text.
+- Use `font-variant-numeric: tabular-nums` for counters, prices, times, and tabular numbers.
+- Animation only declares actual change attributes, prohibits `transition: all` and `will-change: all`, and respects `prefers-reduced-motion`.
 
-## 暗色模式
+## Dark mode
 
-- 项目级暗色模式只选择一种主策略：CSS 变量、根节点 class、`data-theme` 或组件库主题。
-- 支持手动切换主题时，要在首屏绘制前初始化用户偏好，避免主题闪烁；实现细节交给 Tailwind / design-system skill reference。
-- 亮色与暗色都要复核 disabled、focus、selected、invalid、skeleton、chart、表单控件、第三方组件和阴影层级。
-- 不只靠降低透明度表达 disabled，不只补背景色而忽略文本、边框、图表和焦点状态。
+- Project-level dark mode only selects one main strategy: CSS variables, root node class, `data-theme` or component library theme.
+- When supporting manual theme switching, user preferences must be initialized before the first screen is drawn to avoid theme flickering; the implementation details are left to Tailwind / design-system skill reference.
+- Review disabled, focus, selected, invalid, skeleton, chart, form controls, third-party components and shadow levels for both light and dark colors.
+- Don't just reduce the transparency to express disabled, don't just fill in the background color and ignore text, borders, charts and focus states.
 
-## 可访问性基线
+## Accessibility Baseline
 
-- 优先使用语义化 HTML。
-- 表单控件具备标签，纯图标按钮具备可访问名称。
-- 菜单、标签页、对话框和自定义控件支持键盘操作。
-- 焦点样式可见，标题层级正确，真实表格数据使用表格语义。
-- 颜色对比度、触摸目标、reduced-motion 和错误提示不能被视觉 polish 破坏。
+- Prefer semantic HTML.
+- Form controls have labels and pure icon buttons have accessible names.
+- Menus, tabs, dialog boxes and custom controls support keyboard operation.
+- Focus styles are visible, title levels are correct, and real table data uses table semantics.
+- Color contrast, touch targets, reduced-motion and error prompts cannot be destroyed by visual polish.
 
-## UI 任务输出
+## UI task output
 
-实现完成后说明复用了什么、新建了什么、与设计稿或项目 token 的偏差、缺少哪些资源或交互细节。复杂 UI 还应说明状态覆盖、响应式验证和剩余设计风险。
+After the implementation is completed, explain what was reused, what was newly created, deviations from the design draft or project token, and what resources or interaction details are missing. Complex UIs should also account for state overrides, responsive validation, and remaining design risks.