@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/templates/shared/rules/fec-refactoring.md

@@ -1,47 +1,47 @@
-# 重构项目规则
+# Refactor project rules
 
-当任务涉及从现有项目重构、迁移或重写前端代码时，应用本文件。
+This document applies when the task involves refactoring, migrating, or rewriting front-end code from an existing project.
 
-## 目标
+## Target
 
-- **视觉和交互**：与原项目一致，用户无感知差异
-- **代码质量**：更简洁、易维护，符合目标框架规范
-- **业务功能**：与原项目保持一致，**不得缺失功能**；重构前后行为等价
+- **Visual and interactive**: consistent with the original project, no perceived difference by users
+- **Code Quality**: more concise, easier to maintain, and in line with the target framework specifications
+- **Business functions**: consistent with the original project, **no missing functions**; behaviors before and after reconstruction are equivalent
 
-## 图片与图标
+## Pictures and Icons
 
-- 直接使用原项目的图片资源路径，不重新托管或替换
-- 可使用 SVG 图片（`<img src="*.svg" />` 或 CSS `background-image`），**禁止使用内联 SVG**（`<svg>...</svg>` 直接写在组件中）
-- **若原项目使用了 iconfont 或 IcoMoon 图标，重构时继续使用**，保持图标体系一致；不替换为其他图标方案
-- 图标优先使用原项目已有的图标文件（iconfont / IcoMoon / 已有 SVG），必要时可引入 SVG 文件作为独立资源
+- Directly use the image resource path of the original project without rehosting or replacing it.
+- SVG images (`<img src="*.svg" />` or CSS `background-image`) can be used, **inline SVG is prohibited** (`<svg>...</svg>` written directly in the component)
+- **If the original project uses iconfont or IcoMoon icons, continue to use them** during reconstruction to keep the icon system consistent; do not replace it with other icon schemes
+- For icons, priority is given to using existing icon files in the original project (iconfont / IcoMoon / existing SVG). If necessary, SVG files can be introduced as independent resources
 
-## 样式
+## Style
 
-- 布局样式对齐原项目视觉效果，但**只参考原项目效果，不照搬其 CSS**
-- 优先使用 **flex 弹性布局**，避免 `float`、复杂 `position`、冗余嵌套
-- 避免不合理写法：`!important` 滥用、过深选择器、重复定义
-- **组件中禁止使用内联样式**（`style={{ ... }}` / `style="..."`），样式统一放在 CSS Modules、Tailwind 类或样式文件中，便于维护
+- The layout style aligns with the visual effects of the original project, but **only refers to the original project effects and does not copy its CSS**
+- Prioritize the use of **flex elastic layout** to avoid `float`, complex `position`, and redundant nesting
+- Avoid unreasonable writing methods: `!important` abuse, excessively deep selectors, and repeated definitions
+- **Inline styles are prohibited in components** (`style={{ ... }}` / `style="..."`). Styles are unified in CSS Modules, Tailwind classes or style files for easy maintenance.
 
-## 强约束
+##Strong constraints
 
-- 业务功能与原项目完整等价，不得缺失
-- 图片使用原项目资源，无内联 SVG；若原项目用 iconfont/IcoMoon 则继续使用
-- 样式参考原项目效果但不照搬 CSS，优先 flex 布局，无内联样式
-- 对公共 API、路由、事件、埋点、权限、缓存和错误状态建立行为清单，重构前后逐项核对
-- 涉及页面、组件、路由、表单、弹窗、导航或关键用户流程的迁移，必须使用 Playwright 或同等真实浏览器验证方式对关键路径做对比验证
-- 对视觉敏感页面，应补充截图对比或人工截图验收；动态内容、动画、字体和环境差异需明确屏蔽、稳定化或说明
-- 对纯逻辑、类型、构建或无 UI 的迁移，不强制 Playwright，应选择更贴近风险的验证层：type-check、unit test、component test、build 或 lint
-- 验证目标不是像素级完全一致，而是确认业务功能无缺失、关键交互等价、主要视觉布局无非预期偏差，并且代码比旧实现更清晰、可维护
+- The business functions are completely equivalent to the original project and must not be missing.
+- Images use original project resources, no inline SVG; if the original project uses iconfont/IcoMoon, continue to use it
+- The style refers to the original project effect but does not copy CSS, giving priority to flex layout, no inline style
+- Establish a behavior list for public APIs, routing, events, hidden points, permissions, caches and error status, and check them one by one before and after reconstruction
+- For migrations involving pages, components, routes, forms, pop-ups, navigation or key user processes, Playwright or equivalent real browser verification methods must be used to compare and verify the critical paths.
+- For visually sensitive pages, screenshot comparison or manual screenshot acceptance should be supplemented; dynamic content, animation, fonts and environmental differences need to be clearly blocked, stabilized or explained
+- For pure logic, type, build or no UI migrations, Playwright is not mandatory and a validation layer closer to the risk should be chosen: type-check, unit test, component test, build or lint
+- The verification goal is not to be completely consistent at the pixel level, but to confirm that there are no missing business functions, key interactions are equivalent, there are no unexpected deviations in the main visual layout, and the code is clearer and maintainable than the old implementation.
 
-## 死代码清理
+## Dead code cleanup
 
-清理未使用代码、导出、样式或依赖时：
+When cleaning unused code, exports, styles or dependencies:
 
-- 先建立验证基线，再做清理。
-- 使用工具或搜索证据证明候选项无引用。
-- 将候选项分为 SAFE、CAUTION、DANGER。
-- 仅自动清理 SAFE 项；路由、配置、运行时模板、动态 import 和公开 API 默认视为高风险。
-- 每批清理后运行受影响验证命令。
-- 若验证失败，先回到最近一批候选项定位，不继续扩大清理范围。
+- Establish a verification baseline first, then clean it up.
+- Use tools or search for evidence that candidates have no citations.
+- Classify candidates into SAFE, CAUTION, and DANGER.
+- Only SAFE items are automatically sanitized; routing, configuration, runtime templates, dynamic imports, and public APIs are considered high risk by default.
+- Run affected verification command after each batch cleanup.
+- If the verification fails, return to the most recent batch of candidates and do not continue to expand the scope of cleaning.
 
-不要把死代码清理与功能重写、视觉调整或依赖升级混在同一个改动里。
+Don’t mix dead code cleanup with feature rewrites, visual tweaks, or dependency upgrades in the same change.

package/templates/shared/rules/fec-rendering-patterns.md

@@ -1,40 +1,40 @@
-# 渲染模式选型
+#Rendering mode selection
 
-当项目需要选择或评估 CSR / SSR / SSG / ISR / RSC 时，参考本文件。本文只保留跨框架决策约束；Next.js App Router 细节交给 `fec-nextjs-project-standard`，Nuxt 细节交给 `fec-nuxt-project-standard`，性能证据交给 `fec-performance-optimization`。
+Reference this document when a project needs to select or evaluate CSR/SSR/SSG/ISR/RSC. This article only retains cross-framework decision constraints; Next.js App Router details are left to `fec-nextjs-project-standard`, Nuxt details are left to `fec-nuxt-project-standard`, and performance evidence is left to `fec-performance-optimization`.
 
-## 渲染模式概览
+## Rendering mode overview
 
-| 模式 | 生成时机 | 典型适用 |
+| Mode | Generation timing | Typical application |
 | ---- | -------- | -------- |
-| CSR | 浏览器运行时 | 登录后后台、内部工具、高交互 SPA |
-| SSR | 请求时服务端 | SEO 关键且内容实时的公开页 |
-| SSG | 构建时 | 文档、博客、营销页、变化慢的公开内容 |
-| ISR | 构建时 + 按需再生成 | 页面数量多、内容更新频繁但允许延迟 |
-| RSC | 服务端组件渲染 | Next.js App Router 中需要减少客户端 JS 的场景 |
-
-## 选型原则
-
-- SEO 必须且内容实时：优先 SSR，并明确缓存、超时和错误降级。
-- SEO 必须且内容稳定：优先 SSG；页面数量巨大或更新频繁时考虑 ISR。
-- 登录后后台、强交互工作区、内部工具：优先 CSR，公开登录/注册页可单独 SSG/SSR。
-- 混合产品：公开页与私有页可以采用不同模式，不为统一架构牺牲体验或成本。
-- 页面数量、更新频率、服务器成本、部署平台、缓存策略和团队运维能力必须一起评估。
-- RSC 只在支持的框架和路由体系中使用；客户端交互、浏览器 API 和高频状态仍放在客户端叶子组件。
-
-## 实施约束
-
-- SSR / RSC 路径不得直接依赖 `window`、`document`、localStorage 或浏览器专属库。
-- Hydration 前后的 HTML、时间、随机数、用户偏好和媒体查询结果要保持一致，避免水合不匹配。
-- 服务端数据获取必须有超时、错误降级和缓存策略。
-- SSG / ISR 需要明确未预渲染路径、revalidate / 失效策略和回滚方式。
-- 客户端大型动效库、图表、编辑器、地图、WebGL/Canvas 等应按需加载，不进入根布局同步 bundle。
-- 不在没有响应头、构建输出、trace、路由行为或线上指标证据时断言某路由“已缓存”或“必须动态”。
-
-## 检查清单
-
-- [ ] 明确公开页与私有页、SEO 需求和实时性需求。
-- [ ] 明确每类页面使用 CSR / SSR / SSG / ISR / RSC 的理由。
-- [ ] 评估页面数量、构建时间、服务器成本和缓存失效策略。
-- [ ] 检查 SSR/RSC 代码没有浏览器 API 依赖和不可序列化 props。
-- [ ] 确认 loading、error、not-found、离线和权限状态不会因渲染模式丢失。
-- [ ] 用构建输出、响应头、trace 或路由行为验证最终模式。
+| CSR | Browser runtime | Post-login backend, internal tools, high-interaction SPA |
+| SSR | Server-side on request | SEO-critical and real-time content public page |
+| SSG | Build-time | Documentation, blogs, marketing pages, slow-changing public content |
+| ISR | Build time + regenerate on demand | Large number of pages, frequent content updates but allow for delays |
+| RSC | Server-side component rendering | Scenarios where client-side JS needs to be reduced in Next.js App Router |
+
+## Selection principles
+
+- SEO is a must and content is live: Prioritize SSR and be clear about caching, timeouts and error degradation.
+- SEO is required and the content is stable: Prioritize SSG; consider ISR when the number of pages is huge or updates are frequent.
+- Backend after login, strong interaction workspace, internal tools: priority CSR, public login/registration page can be separate SSG/SSR.
+- Hybrid product: Public pages and private pages can adopt different models without sacrificing experience or cost for a unified architecture.
+- Number of pages, update frequency, server cost, deployment platform, caching strategy and team operation and maintenance capabilities must be evaluated together.
+- RSC is only used in supported frameworks and routing architectures; client interactions, browser APIs, and high-frequency states are still placed in client leaf components.
+
+## Implement constraints
+
+- SSR/RSC paths must not directly depend on `window`, `document`, localStorage or browser-specific libraries.
+- HTML, time, random numbers, user preferences and media query results before and after hydration should be consistent to avoid hydration mismatch.
+- Server-side data retrieval must have timeout, error degradation and caching strategies.
+- SSG/ISR needs to clarify the non-prerendered path, revalidate/invalidation strategy and rollback method.
+- Client-side large animation libraries, charts, editors, maps, WebGL/Canvas, etc. should be loaded on demand without entering the root layout synchronization bundle.
+- No longer assert that a route is "cached" or "must be dynamic" without evidence of response headers, build output, traces, route behavior, or online metrics.
+
+## Checklist
+
+- [ ] Clarify public pages and private pages, SEO requirements and real-time requirements.
+- [ ] Clarify the reasons for using CSR / SSR / SSG / ISR / RSC for each type of page.
+- [ ] Evaluate page count, build times, server costs, and cache invalidation strategies.
+- [ ] Check that SSR/RSC code has no browser API dependencies and non-serializable props.
+- [ ] Confirm that loading, error, not-found, offline and permission states are not lost across render modes.
+- [ ] Verify the final schema with build output, response headers, traces, or routing behavior.

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

@@ -1,50 +1,50 @@
-# 响应式设计规则
+# Responsive design rules
 
-凡是任务涉及移动端适配、响应式布局、多端兼容、触摸目标或视口行为时，都应用本文件。本文只保留项目常驻约束；布局模式、container query、响应式表格、媒体和验证细节交给 `fec-responsive-layout`。
+This document should be used whenever the task involves mobile adaptation, responsive layout, multi-device compatibility, touch targets or viewport behavior. This article only retains project-resident constraints; layout mode, container query, responsive tables, media and validation details are left to `fec-responsive-layout`.
 
-## 核心原则
+## Core Principles
 
-- **移动优先**：从小屏幕开始设计，逐步增强到大屏幕。
-- **内容优先**：小屏优先展示核心任务、关键操作和反馈，次要内容折叠、延后或进入详情层。
-- **触摸友好**：所有交互元素必须适配手指操作，关键功能不能只依赖 hover。
-- **性能优先**：移动端网络和设备性能较弱，首屏资源、图表、动效和大列表要克制。
-- **容器感知**：可复用组件优先适配所在容器，而不是假设整页断点。
-- **稳定尺寸**：工具栏、表格列、棋盘、卡片网格和计数器需要稳定约束，避免状态变化导致布局跳动。
+- **Mobile First**: Start designing for small screens and work your way up to large screens.
+- **Content Priority**: Small screens give priority to core tasks, key operations and feedback, and secondary content is folded, postponed or entered into the detail layer.
+- **Touch Friendly**: All interactive elements must adapt to finger operations, and key functions cannot rely solely on hover.
+- **Performance first**: The mobile network and device performance are weak, so first-screen resources, charts, animations, and large lists should be restrained.
+- **Container Aware**: Reusable components will first adapt to the container in which they are located, instead of assuming full page breakpoints.
+- **Stable size**: Toolbars, table columns, checkerboards, card grids and counters need stable constraints to avoid layout jumps caused by state changes.
 
-## 断点与容器策略
+## Breakpoints and container strategies
 
-- 默认验证 375px、768px、1024px、1440px，以及断点中间值。
-- 使用 mobile-first `min-width` 断点；不要先写桌面样式再用 `max-width` 补移动端。
-- Tailwind 前缀从小到大使用：默认 → `sm:` → `md:` → `lg:` → `xl:` → `2xl:`。
-- 页面级结构可以使用断点；会被放进侧栏、弹窗、卡片或主内容区的复用组件优先使用 container query。
-- grid/flex 子项包含长文本、图表、代码、媒体或表格时，必须考虑 `min-width: 0`、`minmax()`、`aspect-ratio` 和明确溢出策略。
+- Default validation for 375px, 768px, 1024px, 1440px, and breakpoint intermediate values.
+- Use mobile-first `min-width` breakpoint; do not write the desktop style first and then use `max-width` to supplement the mobile version.
+- Tailwind prefixes are used from smallest to largest: default → `sm:` → `md:` → `lg:` → `xl:` → `2xl:`.
+- Page-level structures can use breakpoints; reusable components that will be placed into sidebars, pop-ups, cards, or main content areas preferentially use container queries.
+- `min-width: 0`, `minmax()`, `aspect-ratio` and explicit overflow strategies must be taken into account when grid/flex children contain long text, charts, code, media or tables.
 
-## 触摸目标与移动端交互
+## Touch target to interact with mobile terminal
 
-- 空间允许时，按钮、链接、关闭按钮等交互目标至少 44x44px；紧凑工具界面最低也要保证可操作。
-- 输入框字号避免低于 16px，防止 iOS Safari 自动缩放。
-- 固定底部栏、操作条、抽屉和对话框必须考虑 safe area 与虚拟键盘。
-- hover-only 信息必须有点击、焦点或常驻可见替代方案。
-- 横竖屏切换后，主操作、焦点位置、滚动容器和错误提示仍应可达。
+- When space permits, interaction targets such as buttons, links, and close buttons must be at least 44x44px; compact tool interfaces must be at least operable.
+- Avoid input box font size below 16px to prevent iOS Safari from automatically scaling.
+- Fixed bottom bar, action bar, drawer and dialog box must consider safe area and virtual keyboard.
+- Hover-only messages must have click, focus, or permanent visible alternatives.
+- After switching between horizontal and vertical screens, the main operation, focus position, scroll container and error prompts should still be accessible.
 
-## 数据密集区域
+## Data intensive area
 
-- 表格、列表、看板、编辑器和画布可以局部横向滚动，但页面整体不应出现无意水平溢出。
-- 移动端数据密集视图需先定义列优先级：主标识、状态和主操作优先保留；低优先级字段进入详情、展开行或抽屉。
-- 小屏仍要保留排序、筛选、分页和选择能力。
-- 虚拟滚动只解决 DOM 数量问题，不能替代信息层级设计。
+- Tables, lists, boards, editors and canvases can be partially scrolled horizontally, but the page as a whole should not have unintentional horizontal overflow.
+- Data-intensive views on the mobile terminal need to define column priorities first: main identification, status and main operations are retained first; low-priority fields enter details, expand rows or drawers.
+- Small screens must still retain the ability to sort, filter, paging, and select.
+- Virtual scrolling only solves the problem of DOM quantity and cannot replace information hierarchy design.
 
-## 响应式媒体
+## Responsive media
 
-- 图片和视频要有稳定尺寸、`aspect-ratio` 或容器约束，避免加载后推挤布局。
-- 需要多尺寸资源时使用 `srcset`、`sizes`、`picture` 或框架图片组件，避免移动端下载桌面大图。
-- 媒体裁切必须保留主体信息，不为填满卡片裁掉产品、人物、图表或状态关键区域。
+- Images and videos must have stable size, `aspect-ratio` or container constraints to avoid pushing the layout after loading.
+- Use `srcset`, `sizes`, `picture` or frame picture components when multi-size resources are needed to avoid downloading large desktop images on mobile devices.
+- Media cropping must preserve the main information and do not crop out key areas of products, people, graphics or status to fill the card.
 
-## 检查清单
+## Checklist
 
-- [ ] 320-375px 页面级无水平溢出。
-- [ ] 断点切换后阅读顺序合理，主操作不被隐藏。
-- [ ] 触摸目标、输入字号、safe area、虚拟键盘和横竖屏行为已验证。
-- [ ] loading、empty、error、disabled、hover/focus、长翻译文本和大数字不会撑坏固定格式控件。
-- [ ] 数据密集区域有列优先级、局部滚动或移动端摘要策略。
-- [ ] 首屏媒体尺寸稳定，非首屏媒体不会拖慢移动端主路径。
+- [ ] 320-375px No horizontal overflow at page level.
+- [ ] The reading order is reasonable after breakpoint switching, and the main operation is not hidden.
+- [ ] Touch target, input font size, safe area, virtual keyboard and horizontal and vertical screen behaviors have been verified.
+- [ ] loading, empty, error, disabled, hover/focus, long translation text and large numbers will not break the fixed format control.
+- [ ] Column priority, partial scrolling, or mobile summary strategies for data-intensive areas.
+- [ ] The size of first-screen media is stable, and non-first-screen media will not slow down the main path of the mobile terminal.

package/templates/shared/rules/fec-source-driven-development.md

@@ -1,31 +1,31 @@
-# 来源驱动开发规则
+# Source-driven development rules
 
-当实现依赖框架、库、浏览器、运行时、构建工具或平台行为时，先确认事实来源，再写代码或评审结论。
+When an implementation relies on a framework, library, browser, runtime, build tool, or platform behavior, confirm the source of truth before writing code or reviewing conclusions.
 
-## 事实来源优先级
+## Fact source priority
 
-1. 项目内 README、配置、测试、模板和已有实现。
-2. 官方文档、源码、类型定义、release notes、migration guide。
-3. Web 标准、浏览器兼容数据和平台文档。
-4. Issue、讨论、博客和第三方文章仅作为线索。
+1. README, configuration, testing, templates and existing implementations within the project.
+2. Official documents, source code, type definitions, release notes, migration guide.
+3. Web standards, browser compatibility data, and platform documentation.
+4. Issues, discussions, blogs and third-party articles are only used as clues.
 
-## 使用场景
+## Usage scenarios
 
-- 框架新版本、路由、渲染模式、缓存、构建配置、浏览器 API。
-- 公共接口、组件 API、设计系统 token、CLI 命令和插件元数据。
-- 依赖升级、迁移、废弃 API 替换、跨运行时兼容。
-- 与安全、性能、可访问性相关的版本敏感判断。
+- New versions of frameworks, routing, rendering modes, caching, build configurations, browser APIs.
+- Public interfaces, component APIs, design system tokens, CLI commands, and plugin metadata.
+- Dependency upgrade, migration, obsolete API replacement, cross-runtime compatibility.
+- Version-sensitive judgments related to security, performance, and accessibility.
 
-## 输出要求
+## Output requirements
 
-- 写清来源、版本或项目事实、决策结论、影响范围和验证方式。
-- 若项目现状与官方推荐冲突，说明冲突原因和渐进迁移策略。
-- 不复制长篇外部文档；只保留必要结论、链接或项目内文件路径。
-- 无法验证时标注不确定性和需要用户/团队确认的事项。
+- Write down the source, version or project facts, decision conclusion, scope of influence and verification method.
+- If the current status of the project conflicts with official recommendations, explain the cause of the conflict and the gradual migration strategy.
+- Do not copy long external documents; only keep necessary conclusions, links or file paths within the project.
+- Mark uncertainties and matters requiring confirmation from the user/team when they cannot be verified.
 
-## 反模式
+## Anti-pattern
 
-- 凭记忆使用版本敏感 API。
-- 用过时教程替代官方文档。
-- 为追新推翻稳定项目约定。
-- 在组件里散落外部库行为假设，而不是集中到适配层。
+- Use version-sensitive APIs from memory.
+- Replace official documentation with outdated tutorials.
+- Overturn the stable project agreement in order to pursue new projects.
+- Scatter external library behavior assumptions throughout components instead of centralizing them in the adaptation layer.

package/templates/shared/rules/fec-state-management.md

@@ -1,60 +1,60 @@
-# 状态管理规范
+# Status management specifications
 
-本文件约定前端状态归属底线。状态清单、Store 形状示例、URL 状态、持久化适配器和 SSR 隔离细节交给 `fec-state-management`；请求缓存细节交给数据获取 workflow；表单字段和校验交给表单 workflow。
+This document stipulates that the front-end status belongs to the bottom line. State manifests, Store shape examples, URL states, persistence adapters, and SSR isolation details are left to `fec-state-management`; request caching details are left to the data fetch workflow; and form fields and validation are left to the form workflow.
 
-## 状态分类
+## Status classification
 
-| 类型 | 示例 | 默认归属 |
+| Type | Example | Default Attribution |
 | ---- | ---- | -------- |
-| 本地 UI 状态 | modal 开关、tab、展开行、hover 编辑态 | 组件内 state / ref |
-| 表单状态 | 输入值、脏字段、校验错误、提交中 | 表单库或表单组件 |
-| 服务端状态 | 列表、详情、分页结果、远程错误 | 请求缓存库 |
-| URL 状态 | 搜索词、筛选、排序、页码、选中 tab | 路由参数 / search params |
-| 全局客户端状态 | 登录用户、主题、权限快照、购物车草稿 | 全局 store |
-| 浏览器持久化状态 | 偏好、非敏感草稿、离线队列 | 存储层 + 状态适配器 |
-
-## 核心原则
-
-- **先归属，后选库**：不要先选 Redux、Zustand、Pinia 或 Context；先确定每个状态的唯一 owner。
-- **就近管理**：状态放在需要它的最近公共祖先。
-- **单一数据源**：同一份数据只在一个地方维护。
-- **派生优于同步**：可从 props、server state、URL 或已有 state 推导的值，不另存一份。
-- **最小全局状态**：全局 store 只保存真正跨页面、跨 feature 或需要统一动作的客户端状态。
-
-## React 状态边界
-
-- 单组件或小子树使用 `useState` / `useReducer`。
-- 低频全局配置、主题或依赖注入可用 Context；高频变化的大对象不要放 Context。
-- 中等复杂业务状态可用 Zustand、Jotai 或仓库既有方案；大型严格动作流可用 Redux Toolkit。
-- 服务端数据使用请求缓存库，不复制到全局 store。
-
-## Vue 状态边界
-
-- 局部状态使用 `ref` / `reactive` / `computed`。
-- 局部跨层级上下文使用 `provide/inject`。
-- 全局业务状态使用 Pinia 或项目既有 store。
-- 服务端数据优先使用请求库或 composable 管理，不原封不动写入 Pinia。
-
-## URL 与持久化状态
-
-- 搜索、筛选、排序、分页、选中 tab 等需要分享或刷新保留的视图状态优先放 URL。
-- 浏览器持久化只保存稳定偏好或非敏感草稿，并明确字段白名单、版本号、迁移路径、过期策略和敏感字段排除。
-- SSR 场景不要在模块顶层创建带用户数据的单例 store；每次请求需要独立实例。
-
-## 反模式
-
-- 将所有状态都放进全局 store。
-- 在 store 中存放 UI 临时状态或表单每个字段。
-- 手动同步多份相同数据，而不是从源状态派生。
-- 将服务端响应原封不动存入全局 store，而不用请求缓存库。
-- 用 Context / provide 承载高频变化大对象，导致大范围重渲染。
-- 持久化 token、权限细节、个人敏感数据或未版本化的大对象。
-
-## 检查清单
-
-- [ ] 每个状态都有明确归属：本地 / 表单 / 服务端缓存 / URL / 全局 store / 浏览器持久化。
-- [ ] 可派生的值没有被存为独立 state。
-- [ ] 全局 store 只包含真正跨边界共享的数据。
-- [ ] 服务端数据通过请求库管理，刷新、回退、权限变化和错误状态仍可恢复。
-- [ ] URL 状态与路由参数同步，刷新和分享行为符合预期。
-- [ ] 持久化状态有白名单、版本、迁移和敏感字段排除。
+| Local UI state | modal switch, tab, expand row, hover editing state | In-component state / ref |
+| Form status | Input value, dirty field, validation error, submitting | Form library or form component |
+| Server status | List, details, paging results, remote errors | Request cache library |
+| URL status | Search terms, filter, sort, page number, selected tab | Routing parameters / search params |
+| Global client status | Login users, topics, permission snapshots, shopping cart drafts | Global store |
+| Browser persistent state | Preferences, non-sensitive drafts, offline queues | Storage layer + state adapter |
+
+## Core Principles
+
+- **Own first, choose library later**: Don’t choose Redux, Zustand, Pinia or Context first; determine the unique owner of each state first.
+- **Nearest Management**: The state is placed in the nearest common ancestor that needs it.
+- **Single Data Source**: The same data is maintained in only one place.
+- **Derivation is better than synchronization**: Values that can be derived from props, server state, URL or existing state, do not save a new copy.
+- **Minimum global state**: The global store only saves client state that is truly cross-page, cross-feature, or requires unified action.
+
+## React state boundaries
+
+- Use `useState` / `useReducer` for single components or small subtrees.
+- Low-frequency global configuration, theme or dependency injection can use Context; large objects that change frequently should not be placed in Context.
+- For moderately complex business states, Zustand, Jotai or existing warehouse solutions can be used; for large and strict action flows, Redux Toolkit can be used.
+- Server-side data uses the request cache library and is not copied to the global store.
+
+## Vue state boundary
+
+- Use `ref` / `reactive` / `computed` for local state.
+- Use `provide/inject` for local cross-level context.
+- Global business status uses Pinia or the existing store of the project.
+- Server-side data is first managed using the request library or composable and is not written to Pinia intact.
+
+## URL and persistent state
+
+- When searching, filtering, sorting, paging, selecting tabs, etc., the view state that needs to be shared or refreshed should be given priority to the URL.
+- Browser persistence only saves stable preferences or non-sensitive drafts, and clearly identifies field whitelists, version numbers, migration paths, expiration policies, and sensitive field exclusions.
+- In SSR scenarios, do not create a single instance store with user data at the top level of the module; each request requires an independent instance.
+
+## Anti-pattern
+
+- Put all state into global store.
+- Store UI temporary state or each field of the form in the store.
+- Manually synchronize multiple copies of the same data instead of deriving from source state.
+- Store the server response intact in the global store without requesting the cache library.
+- Use Context / provide to carry large objects that change frequently, resulting in large-scale re-rendering.
+- Persistent tokens, permission details, personal sensitive data or unversioned large objects.
+
+## Checklist
+
+- [ ] Each state has a clear ownership: local / form / server cache / URL / global store / browser persistence.
+- [ ] Derivable values are not stored as independent state.
+- [ ] The global store only contains data that is truly shared across boundaries.
+- [ ] Server-side data is managed through the request library, and refreshes, rollbacks, permission changes, and error states can still be recovered.
+- [ ] URL state is synchronized with route parameters, and refresh and share behavior is as expected.
+- [ ] Persistence status has whitelist, version, migration and sensitive field exclusions.

package/templates/shared/rules/fec-testing.md

@@ -1,98 +1,98 @@
-# 测试与校验规则
+# Testing and verification rules
 
-凡是新增、修改、重构或评审代码时，都应用本文件。
+This document should be used whenever code is added, modified, refactored, or reviewed.
 
-## 校验顺序
+## Verification sequence
 
-优先按以下顺序执行：
+Prioritize execution in the following order:
 
 1. lint
 2. type check
 3. unit test
 4. build
 
-优先使用仓库已有脚本。
-如果命令不确定，先检查 `package.json`。
+Priority is given to using existing scripts in the warehouse.
+If the command is uncertain, check `package.json` first.
 
-## 改动校验原则
+## Change the verification principle
 
-- 先修复范围最小且正确的问题
-- 每次关键修复后重新执行受影响的命令
-- 不要盲目压掉报错或关闭规则
-- 不要为了通过检查而降低类型安全
-- 不要因为一个局部测试失败就重写无关模块
+- Fix the smallest and correct issues first
+- Re-execute affected commands after each critical fix
+- Don’t blindly suppress error reporting or closing rules
+- Don't compromise type safety to pass checks
+- Don't rewrite unrelated modules just because a local test fails
 
-## 测试要求
+## Testing requirements
 
-新增或修改行为时，考虑是否需要覆盖以下内容：
+When adding or modifying behaviors, consider whether you need to override the following:
 
-- 组件渲染
-- 交互行为
-- 状态切换
-- 边界场景
-- loading / empty / error 状态
-- 与可访问性相关的关键交互
+- Component rendering
+- interactive behavior
+- Status switching
+- Border scenes
+- loading / empty / error status
+- Key interactions related to accessibility
 
-如果没有补测试，需要说明原因。
+If there is no supplementary test, the reason needs to be explained.
 
-## Fixture 与 Mock
+## Fixture and Mock
 
-- Fixture 表达业务场景，不使用随机、无语义或只对测试作者有意义的数据
-- 复杂对象使用 builder 填充默认值，每个测试只覆盖当前场景相关字段
-- 测试间不共享可变全局状态、fake timer、store 或 mock server handler
-- 网络 mock 应模拟公开契约和用户可见错误，不复制后端内部实现
+- Fixture expresses business scenarios without using random, meaningless or data that is meaningful only to the test author
+- Complex objects use builder to fill in default values, and each test only covers fields related to the current scenario.
+- No mutable global state, fake timers, stores or mock server handlers are shared between tests
+- Network mocks should simulate public contracts and user-visible errors and not replicate backend internal implementations
 
-## TDD 与回归测试
+## TDD and regression testing
 
-新增行为、修复 Bug 或重构关键逻辑时，优先采用 TDD：
+When adding new behaviors, fixing bugs, or refactoring key logic, TDD is preferred:
 
-1. 先写能描述期望行为的失败测试。
-2. 运行测试并确认失败原因正确。
-3. 写最小实现让测试通过。
-4. 测试保持通过后再重构。
+1. Start by writing failing tests that describe the desired behavior.
+2. Run the test and confirm that the failure reason is correct.
+3. Write the minimum implementation to make the test pass.
+4. Refactor after the test remains passed.
 
-Bug 修复应优先保留能复现问题的回归测试。若现有项目缺少测试基础设施，不要盲目引入新框架；先给出最小测试落地建议并说明维护成本。
+Bug fixes should prioritize keeping regression tests that reproduce the problem. If the existing project lacks testing infrastructure, do not blindly introduce a new framework; first provide minimum test implementation suggestions and explain maintenance costs.
 
-## 代码评审输出风格
+## Code review output style
 
-评审代码时，返回：
+When reviewing code, return:
 
-- 总体评估
-- 必修问题
-- 建议优化
-- 可选优化项
-- 风险等级
+- Overall assessment
+- Required questions
+- Suggestions for optimization
+- Optional optimization items
+- Risk level
 
-结论要具体且可执行。
+Conclusions should be specific and actionable.
 
-## E2E 测试规则
+## E2E test rules
 
-使用 Playwright 或 Cypress 时：
+When using Playwright or Cypress:
 
-- 遵循 **Page Object**，spec 内不写裸选择器；优先 **`data-testid`**，其次 **`role` / `label`**
-- 用 **`test.describe` + `beforeEach`** 组织场景，单用例可独立运行、不依赖执行顺序
-- 禁止用固定 **`sleep`** 当主要同步手段；用 **Locator 自动等待**、`expect`、`waitForResponse` 等
-- Playwright：**`playwright.config.ts`** 中配置 `baseURL`、CI 下 `retries`/`workers`、`trace`/`screenshot`/`video`、**`webServer`** 与多 **`projects`（含移动端）**
-- 关键流程至少覆盖桌面、平板、移动端视口（或等价 device 项目）
-- **不稳定用例**：`test.fixme` / `test.skip` 需写原因与 issue；用 `--repeat-each` 辅助定位 flaky
-- 失败时保留 **截图、Trace、视频**，CI 用 **artifact** 上传 HTML 报告与产物
-- 高风险/资金类流程：**勿在生产跑真实 E2E**；staging 或 mock，必要时 `test.skip`
-- 测试数据可重复：优先 seed、测试账号或 mock 服务；随机值必须带唯一前缀并在 teardown 清理
+- Follow **Page Object**, do not write naked selectors in spec; give priority to **`data-testid`**, followed by **`role` / `label`**
+- Use **`test.describe` + `beforeEach`** to organize scenarios. A single use case can run independently and does not depend on the execution sequence.
+- It is forbidden to use fixed **`sleep`** as the main synchronization method; use **Locator to automatically wait**, `expect`, `waitForResponse`, etc.
+- Playwright: Configure `baseURL` in **`playwright.config.ts`**, `retries`/`workers`, `trace`/`screenshot`/`video`, **`webServer`** and many **`projects` (including mobile)** under CI
+- Key processes cover at least desktop, tablet, and mobile viewports (or equivalent device projects)
+- **Unstable use case**: `test.fixme` / `test.skip` needs to write the reason and issue; use `--repeat-each` to assist in locating flaky
+- Keep **Screenshots, Traces, Videos** in case of failure, CI uses **artifact** to upload HTML reports and products
+- High-risk/funding processes: **Do not run real E2E in production**; staging or mock, if necessary `test.skip`
+- Test data is repeatable: priority is seed, test account or mock service; random values must be uniquely prefixed and cleaned in teardown
 
-详细模式与示例见插件 **`fec-e2e-testing`** skill。
+For detailed modes and examples, see the plug-in **`fec-e2e-testing`** skill.
 
-## 重构规则
+## Refactoring rules
 
-进行重构时：
+When refactoring:
 
-- 除非任务明确要求改行为，否则保持行为一致
-- 说明可能的迁移风险
-- 优先做渐进式修改，而不是大范围重写
-- 总结改动文件、执行过的命令和剩余风险
+- Maintain consistent behavior unless the task specifically requires a change in behavior
+- Describe possible migration risks
+- Prioritize incremental changes over extensive rewrites
+- Summarize changed files, executed commands and remaining risks
 
-## 验证失败处理
+## Verification failure handling
 
-- 按文件和根因分组错误，一次修复一类问题。
-- 每次修复后重新运行最近的失败命令。
-- 不删除失败测试、不关闭规则、不降低类型安全来换取通过。
-- 同一错误多次修复仍失败时，停止扩大改动并报告阻塞。
+- Group errors by file and root cause to fix one type of problems at a time.
+- Rerun the most recent failed command after each fix.
+- Don't remove failing tests, don't close rules, don't reduce type safety in exchange for passing.
+- When the same error is repaired multiple times and still fails, the expansion of changes will be stopped and a blockage will be reported.