@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/skills/fec-browser-storage/SKILL.md

@@ -1,34 +1,34 @@
 ---
 name: fec-browser-storage
-description: Use when choosing, implementing, or reviewing browser storage such as localStorage, sessionStorage, IndexedDB, cookies, client persistence, offline data, secure storage, or cleanup strategy; Chinese triggers include 浏览器存储, 客户端持久化.
+description: Use when choosing, implementing, or reviewing browser storage such as localStorage, sessionStorage, IndexedDB, cookies, client persistence, offline data, secure storage, or cleanup strategy; Chinese triggers include browser storage, client persistence.
 ---
 
-# 浏览器存储
+# Browser storage
 
 ## Purpose
 
-根据数据大小、安全要求和生命周期选择合适的客户端存储方案。
+Choose the appropriate client storage solution based on data size, security requirements, and lifecycle.
 
 ## Procedure
 
-1. 先判断数据敏感度、体积、生命周期、是否需要跨 Tab、是否需要随请求发送。
-2. 小量非敏感偏好用 localStorage；Tab 级临时数据用 sessionStorage；大量结构化数据或离线缓存用 IndexedDB；认证态优先 httpOnly cookie。
-3. 封装统一 key 前缀、JSON parse/stringify、异常处理、过期清理和 quota 兜底。
-4. 敏感数据按安全规则处理，不把明文 token、密码、信用卡信息放进可被 JS 读取的存储。
-5. 审查隐私模式、存储配额、清理策略和跨浏览器兼容性。
+1. First determine the data sensitivity, volume, life cycle, whether it needs to be spread across tabs, and whether it needs to be sent with the request.
+2. Use localStorage for a small amount of non-sensitive preferences; use sessionStorage for tab-level temporary data; use IndexedDB for large amounts of structured data or offline caching; prioritize httpOnly cookies for authentication status.
+3. Encapsulate unified key prefix, JSON parse/stringify, exception handling, expiration cleanup and quota protection.
+4. Sensitive data is processed according to security rules, and plain text tokens, passwords, and credit card information are not put into storage that can be read by JS.
+5. Review privacy mode, storage quotas, sanitization policies, and cross-browser compatibility.
 
-## 详细参考
+## Detailed reference
 
-涉及存储选型表、localStorage/sessionStorage 封装、IndexedDB 示例、Cookie 辅助方法和敏感数据规则时，加载 [references/storage-patterns.md](references/storage-patterns.md)。
+Load [references/storage-patterns.md](references/storage-patterns.md) when it comes to storage selection tables, localStorage/sessionStorage wrappers, IndexedDB examples, cookie helpers, and sensitive data rules.
 
 ## Constraints
 
-- localStorage/sessionStorage 是同步 API，大数据读写会阻塞主线程。
-- 除 httpOnly cookie 外，客户端存储都可被 XSS 读取。
-- Cookie 每次请求自动携带，不适合大数据。
-- IndexedDB 配额和隐私模式行为有浏览器差异。
-- URL 中不要传 token 或敏感数据。
+- localStorage/sessionStorage is a synchronous API, and big data reading and writing will block the main thread.
+- Except for httpOnly cookies, client-side storage can be read by XSS.
+- Cookies are automatically carried with each request and are not suitable for big data.
+- There are browser differences in IndexedDB quota and privacy mode behavior.
+- Do not pass token or sensitive data in the URL.
 
 ## Expected Output
 
-产出统一的 storage/cookie/db 封装，key 有命名空间，数据有过期或清理策略，敏感数据只进入合适的安全边界。
+Produce a unified storage/cookie/db package, the key has a namespace, the data has an expiration or cleanup policy, and sensitive data only enters the appropriate security boundary.

package/skills/fec-browser-storage/references/storage-patterns.md

@@ -1,15 +1,15 @@
-# 浏览器存储模式
+# Browser storage mode
 
-## 选型表
+## Selection table
 
-| 存储 | 容量 | API | 是否发送服务端 | 适用场景 | 安全性 |
+| Storage | Capacity | API | Whether to send to the server | Applicable scenarios | Security |
 | --- | --- | --- | --- | --- | --- |
-| LocalStorage | ~5MB | 同步 | 否 | 用户偏好、非敏感持久数据 | XSS 可读取 |
-| SessionStorage | ~5MB | 同步 | 否 | Tab 级临时数据 | XSS 可读取 |
-| IndexedDB | 大 | 异步 | 否 | 大数据、文件、离线缓存 | XSS 可读取 |
-| Cookie | ~4KB | 同步 | 是 | 认证 Session/httpOnly token | httpOnly 可防 JS 读取 |
+| LocalStorage | ~5MB | Sync | No | User preferences, non-sensitive persistent data | XSS Readable |
+| SessionStorage | ~5MB | Sync | No | Tab-sized temporary data | XSS Readable |
+| IndexedDB | Large | Asynchronous | No | Big data, file, offline cache | XSS readable |
+| Cookie | ~4KB | Synchronization | Yes | Authentication Session/httpOnly token | httpOnly can prevent JS reading |
 
-## localStorage 封装
+## localStorage encapsulation
 
 ```ts
 const STORAGE_PREFIX = "app:";
@@ -53,13 +53,13 @@ export const db = openDB("app-offline-db", 1, {
 
 ## Cookie
 
-- httpOnly 只能由服务端设置。
-- 认证 Cookie 使用 `Secure`、`SameSite=Lax/Strict`。
-- 需要跨站点嵌入时才考虑 `SameSite=None; Secure`。
+- httpOnly can only be set by the server.
+- Authentication Cookie uses `Secure`, `SameSite=Lax/Strict`.
+- Only consider `SameSite=None; Secure` when cross-site embedding is required.
 
-## 敏感数据规则
+## Sensitive data rules
 
-- 认证 token、刷新 token、Session ID：优先 httpOnly cookie。
-- 用户偏好：localStorage。
-- 表单草稿：sessionStorage 或 IndexedDB，避免敏感字段。
-- 离线数据：IndexedDB，但不要缓存隐私或高价值敏感数据。
+- Authentication token, refresh token, Session ID: priority is given to httpOnly cookie.
+- User preference: localStorage.
+- Form draft: sessionStorage or IndexedDB, avoid sensitive fields.
+- Offline data: IndexedDB, but do not cache private or high-value sensitive data.

package/skills/fec-canvas-threejs/SKILL.md

@@ -1,23 +1,23 @@
 ---
 name: fec-canvas-threejs
-description: Use when building or reviewing Canvas 2D, Three.js/WebGL, React Three Fiber, GLSL shaders, ShaderToy-to-WebGL adaptation, 2D/3D visualization, game rendering, animation loops, GPU resource cleanup, or rendering performance. Do not use for standard DOM UI, charts already covered by a chart library, or non-graphical performance work; Chinese triggers include Canvas, Three.js, WebGL, GLSL, Shader, 3D, 数据可视化, 游戏.
+description: Use when building or reviewing Canvas 2D, Three.js/WebGL, React Three Fiber, GLSL shaders, ShaderToy-to-WebGL adaptation, 2D/3D visualization, game rendering, animation loops, GPU resource cleanup, or rendering performance. Do not use for standard DOM UI, charts already covered by a chart library, or non-graphical performance work; Chinese triggers include Canvas, Three.js, WebGL, GLSL, Shader, 3D, data visualization, games.
 ---
 
-# Canvas 与 Three.js
+# Canvas and Three.js
 
 ## Purpose
 
-在浏览器中实现高性能 2D/3D 图形渲染。
+Enable high-performance 2D/3D graphics rendering in the browser.
 
 ## Procedure
 
-1. 先选渲染层：标准 UI 用 DOM；简单 2D 图形/签名/粒子用 Canvas 2D；3D 模型、空间交互和复杂粒子用 Three.js/WebGL；React 项目中的声明式 3D 用 React Three Fiber。
-2. 为渲染容器定义稳定尺寸、DPI 适配和 resize 行为；Canvas 不会自动随 CSS 清晰缩放。
-3. 动画循环使用 `requestAnimationFrame`，不可见或无变化时暂停，卸载时取消。
-4. Three.js 必须释放 geometry/material/texture/renderer，并移除事件监听和 observer。
-5. Shader/WebGL 任务先识别是 SDF、ray marching、noise、particle、post-processing、multipass 还是调试问题，再决定是否需要原生 WebGL2、Three.js ShaderMaterial 或 R3F。
-6. WebGL2 适配时检查 GLSL 版本、入口函数、varying/in-out、texture API、uniform 使用和函数声明顺序，避免白屏只留控制台错误。
-7. 对不可访问的图形内容提供 `aria-label`、替代文本或 DOM 版摘要；交互式图形要有键盘兜底。
+1. First select the rendering layer: DOM for standard UI; Canvas 2D for simple 2D graphics/signatures/particles; Three.js/WebGL for 3D models, spatial interactions and complex particles; React Three Fiber for declarative 3D in React projects.
+2. Define stable size, DPI adaptation, and resize behavior for the render container; Canvas does not automatically scale cleanly with CSS.
+3. The animation loop uses `requestAnimationFrame`, which is paused when it is invisible or has no changes, and canceled when it is uninstalled.
+4. Three.js must release geometry/material/texture/renderer and remove event listeners and observers.
+5. Shader/WebGL tasks first identify whether it is an SDF, ray marching, noise, particle, post-processing, multipass or debugging issue, and then decide whether native WebGL2, Three.js ShaderMaterial or R3F is required.
+6. Check the GLSL version, entry function, varying/in-out, texture API, uniform usage and function declaration order when adapting to WebGL2 to avoid white screen leaving only console errors.
+7. Provide `aria-label`, alternative text or DOM summary for inaccessible graphic content; interactive graphics must have keyboard support.
 
 ## Core Patterns
 
@@ -45,22 +45,22 @@ return () => {
 };
 ```
 
-## 详细参考
+## Detailed reference
 
-涉及 Canvas 2D 绘图、动画循环、Three.js 场景搭建、React Three Fiber、InstancedMesh 和性能清理时，加载 [references/rendering-patterns.md](references/rendering-patterns.md)。
+Load [references/rendering-patterns.md](references/rendering-patterns.md) when it comes to Canvas 2D drawing, animation loops, Three.js scene building, React Three Fiber, InstancedMesh, and performance cleanup.
 
-涉及着色器路由、WebGL2 适配、GLSL 调试、多 pass 预算和视觉验证时，加载 [references/shader-webgl-patterns.md](references/shader-webgl-patterns.md)。
+Load [references/shader-webgl-patterns.md](references/shader-webgl-patterns.md) when it comes to shader routing, WebGL2 adaptation, GLSL debugging, multi-pass budgeting, and visual verification.
 
 ## Constraints
 
-- Canvas/WebGL 内容对屏幕阅读器不可见，必须提供替代语义。
-- WebGL 消耗 GPU，低端设备需限制像素比、面数和纹理大小。
-- Three.js 资源不会自动释放，遗漏 `dispose()` 会造成 GPU 内存泄漏。
-- Canvas 响应式必须同步 CSS 尺寸、绘图尺寸和相机/viewport。
-- 复杂布局/路径规划可联用后台线程 workflow，但渲染本身仍在主线程/渲染线程协调。
-- Shader 主循环、采样层数和多 pass 数量必须有预算；低端设备上要降低 DPR、步数、粒子数或禁用重后处理。
-- 交付前必须确认 canvas 非空、尺寸正确、resize 后不拉伸、控制台无 shader compile/link 错误。
+- Canvas/WebGL content is not visible to screen readers and alternative semantics must be provided.
+- WebGL consumes GPU, and low-end devices need to limit the pixel ratio, number of faces and texture size.
+- Three.js resources will not be released automatically, and missing `dispose()` will cause GPU memory leaks.
+- Canvas responsive must synchronize CSS dimensions, drawing dimensions, and camera/viewport.
+- Complex layout/path planning can be combined with the background thread workflow, but the rendering itself is still coordinated on the main thread/rendering thread.
+- The Shader main loop, number of sampling layers, and number of multi-passes must be budgeted; on low-end devices, reduce the DPR, number of steps, number of particles, or disable heavy post-processing.
+- Before delivery, you must confirm that the canvas is not empty, has the correct size, is not stretched after resize, and has no shader compile/link errors in the console.
 
 ## Expected Output
 
-2D/3D 场景清晰、响应式、可清理，关键设备上接近 60fps；用户能通过替代文本或键盘路径理解/操作核心内容。
+2D/3D scenes are crisp, responsive, cleanable, and close to 60fps on key devices; users can understand/operate with core content via alt text or keyboard paths.

package/skills/fec-canvas-threejs/references/rendering-patterns.md

@@ -1,4 +1,4 @@
-# Canvas、Three.js 与 R3F 模式
+# Canvas, Three.js and R3F mode
 
 ## Canvas 2D
 
@@ -14,7 +14,7 @@ ctx.arc(100, 100, 30, 0, Math.PI * 2);
 ctx.fill();
 ```
 
-## 动画循环
+## Animation loop
 
 ```ts
 let animationId = 0;
@@ -30,7 +30,7 @@ animate();
 return () => cancelAnimationFrame(animationId);
 ```
 
-## Three.js 基础场景
+## Three.js basic scenario
 
 ```ts
 const scene = new THREE.Scene();
@@ -47,7 +47,7 @@ scene.add(cube);
 ## React Three Fiber
 
 ```tsx
-<Canvas camera={{ position: [0, 0, 5], fov: 75 }} role="img" aria-label="3D 产品预览">
+<Canvas camera={{ position: [0, 0, 5], fov: 75 }} role="img" aria-label="3D Product Preview">
   <ambientLight intensity={0.5} />
   <directionalLight position={[5, 5, 5]} />
   <mesh>
@@ -58,10 +58,10 @@ scene.add(cube);
 </Canvas>
 ```
 
-## 性能与清理
+## Performance and cleanup
 
-- 纹理尽量压缩并限制尺寸，常规上限先按 2048px 评估。
-- 重复几何体用 `InstancedMesh`。
-- 不需要持续重绘时暂停 animation loop。
-- 卸载时释放 geometry、material、texture、renderer、controls。
-- ResizeObserver 更新相机 aspect 和 renderer size。
+- Textures are compressed as much as possible and the size is limited. The normal upper limit is first evaluated at 2048px.
+- Use `InstancedMesh` for repeated geometry.
+- Pause animation loop when continuous redrawing is not required.
+- Release geometry, material, texture, renderer, and controls when uninstalling.
+- ResizeObserver updates camera aspect and renderer size.

package/skills/fec-canvas-threejs/references/shader-webgl-patterns.md

@@ -1,28 +1,28 @@
-# Shader 与 WebGL 模式
+# Shader and WebGL mode
 
-## 技术选型参考
+## Technical selection reference
 
-| 目标               | 推荐起点           | 注意事项                       |
+| Goals | Recommended starting points | Notes |
 | ------------------ | ------------------ | ------------------------------ |
-| 数学几何 3D 形态   | SDF + 光线步进     | 步数上限、法线质量、软阴影开销 |
-| 有机运动效果       | 噪声 + 域扭曲      | 过度绘制、重复噪声调用         |
-| 粒子效果           | 实例化或着色器粒子 | 移动端粒子数量上限、混合开销   |
-| 泛光/故障/色彩调整 | 后处理通道         | 额外帧缓冲区显存               |
-| 持续模拟           | 乒乓帧缓冲区       | 纹理格式支持                   |
-| 白屏调试           | 编译/链接日志      | 函数顺序、被优化掉的 uniform   |
+| Mathematical Geometry 3D Shape | SDF + Ray Stepping | Step Limit, Normal Quality, Soft Shadow Overhead |
+| Organic motion effects | Noise + domain distortion | Overdraw, repeated noise calls |
+| Particle effects | Instanced or shader particles | Mobile particle limit, blending overhead |
+| Bloom/Glitch/Color Adjustments | Post-Processing Passes | Extra Frame Buffer Video Memory |
+| Continuous Simulation | Ping Pong Frame Buffer | Texture Format Support |
+| White screen debugging | Compilation/link log | Function order, optimized uniform |
 
-## WebGL2 适配清单
+## WebGL2 adaptation list
 
-- 片元着色器以 `#version 300 es` 开头。
-- 添加 `precision highp float;` 和 `out vec4 fragColor;`。
-- 用 `in`/`out` 替代旧版 `varying`。
-- 用 `texture()` 替代 `texture2D()`。
-- 将 ShaderToy 风格的 `mainImage` 包装为标准 `main`。
-- 使用 `gl_FragCoord.xy` 获取片元坐标。
-- 辅助函数必须在被调用前声明。
-- 预计算常量，不要在宏定义中放函数调用。
+- Fragment shaders start with `#version 300 es`.
+- Added `precision highp float;` and `out vec4 fragColor;`.
+- Replace old `varying` with `in`/`out`.
+- Use `texture()` instead of `texture2D()`.
+- Wrap ShaderToy style `mainImage` into standard `main`.
+- Use `gl_FragCoord.xy` to obtain fragment coordinates.
+- Helper functions must be declared before being called.
+- Precompute constants, don't put function calls in macro definitions.
 
-## 运行时骨架
+## Runtime skeleton
 
 ```ts
 const gl = canvas.getContext("webgl2");
@@ -42,26 +42,26 @@ function compile(type: number, source: string) {
 }
 ```
 
-## 性能预算
+## Performance budget
 
-- 光线步进步数：从 64 起步，仅在出现伪影且证明必要时再提升。
-- 体积采样：桌面端每条射线 16-24 次，移动端酌情降低。
-- FBM 倍频：从 4 开始；避免在光线循环内嵌套 FBM。
-- DPR：桌面端上限 2，移动端重度场景上限 1.5。
-- 纹理尺寸：使用压缩或缩放资源；不要假设 4K 纹理是安全的。
+- Ray Steps: Start at 64 and only increase if artifacts appear and prove necessary.
+- Volume sampling: 16-24 times per ray on desktop, lower as appropriate on mobile.
+- FBM multiplier: starts from 4; avoid nesting FBMs inside ray loops.
+- DPR: The upper limit is 2 on desktop and 1.5 in severe scenarios on mobile.
+- Texture dimensions: Use compressed or scaled assets; don't assume 4K textures are safe.
 
-## 调试视图
+## Debug view
 
-- 法线：输出归一化后的法线，映射到 0-1 范围。
-- 步数：输出当前步数除以最大步数。
-- 距离/深度：以灰度输出命中距离。
-- UV：映射后输出 `vec3(uv, 0.0)`。
-- 材质 ID：将 ID 映射到少量固定调色板。
+- Normal: Outputs the normalized normal, mapped to the 0-1 range.
+- Number of steps: Output the current number of steps divided by the maximum number of steps.
+- Distance/Depth: Outputs hit distance in grayscale.
+- UV: Output `vec3(uv, 0.0)` after mapping.
+- Material IDs: Map IDs to a small number of fixed palettes.
 
-## 视觉验证
+## Visual verification
 
-- 桌面端和移动端尺寸下 Canvas 不为空白。
-- 缩放时更新绘制缓冲区、视口、相机纵横比和 uniform。
-- 低功耗模式下仍能响应，或有静态降级方案。
-- 控制台无着色器编译/链接错误。
-- 卸载或场景隐藏时停止动画。
+- Canvas is not blank in desktop and mobile sizes.
+- Update draw buffer, viewport, camera aspect ratio and uniform when zooming.
+- Still responsive in low power mode, or there may be a static degradation solution.
+- No shader compilation/linking errors in the console.
+- Stop animation when unloading or scene hidden.

package/skills/fec-code-review/SKILL.md

@@ -1,143 +1,162 @@
 ---
 name: fec-code-review
-description: Use when the user asks for general frontend code review, PR review, merge-readiness assessment, architecture maintainability, type-safety, rendering/state risks, style consistency, testability gaps, or a cross-cutting review summary. Delegate deep security, accessibility, E2E, or performance investigations to their specialized skills; Chinese triggers include 代码审查, 代码评审, review.
+description: Use when the user asks for general frontend code review, PR review, merge-readiness assessment, architecture maintainability, type-safety, rendering/state risks, style consistency, testability gaps, or a cross-cutting review summary. Delegate deep security, accessibility, E2E, or performance investigations to their specialized skills; Chinese triggers include code review, code review, review.
 ---
 
-# 前端代码评审
+# Front-end code review
+
+## Review modes and coverage
+
+User-specified scope takes precedence over the default. Use the following three review modes:
+
+- **Change review**: only when recent changes, current edits, staged changes, a PR or a commit are explicitly requested or clearly established by the active task, review those changes and necessary context. For local changes, inspect staged and unstaged diffs and relevant untracked project files within the requested scope; a staged-only request reviews only staged changes. If there are no changes, report that there is nothing to review; do not switch to recent commits or expand scope automatically.
+- **Targeted review**: when files or directories are specified, inventory and review existing code in that scope, including unchanged code; no Git diff is required.
+- **Project review (default)**: when no scope or change context is specified, or when the entire project is requested, inventory project-owned frontend code, related tests, configuration and dependency declarations, then review in module batches, including unchanged code; no Git diff is required.
+
+Select scope before collecting diffs. A file/directory alone means full review of that scope; a path combined with an explicit change request restricts incremental review to that path. An unqualified invocation defaults to project review even if Git changes exist. At review start, state the selected mode and target scope. When automatically delegating review after edits, pass the current change scope explicitly; do not trigger project review merely because the reviewer was called.
+
+Exclude dependency directories, build outputs, caches, generated files and third-party code by default, and record exclusions. Keep the frontend responsibility boundary; this is not a backend audit. A nonexistent target or a scope with no relevant files must be reported explicitly, not replaced with another scope.
+
+Merge findings with the same root cause across batches. Report **review mode, target scope, reviewed files/modules, exclusions, unreviewed files/modules, completion status and verification commands/results**. If context or execution limits prevent completion, mark the review partial and list remaining modules; never claim complete project coverage. Reading callers for context or running project-wide lint/typecheck does not count as manual review of those files.
+
+Change reviews retain merge recommendations. Targeted and project reviews use a risk assessment (Low / Medium / High, with blocking findings), not a claim of merge readiness. Preserve severity levels, evidence requirements and report filenames. Output reports only unless repairs are explicitly requested.
 
 ## Purpose
 
-从架构、类型安全、可访问性、样式一致性、性能和可测试性等 8 个维度审查前端代码质量，输出分级评审报告。
+Review the front-end code quality from 8 dimensions including architecture, type safety, accessibility, style consistency, performance and testability, and output a graded review report.
 
 ## Procedure
 
-1. 先读项目事实：package scripts、框架、目录约定、最近 diff、现有测试和相关规则。
-2. 按风险找问题，而不是按个人偏好挑风格；每个发现都要能指向具体文件、行号和用户影响。
-3. 用五轴收敛结论：正确性、可维护性、类型/接口、用户体验、验证覆盖。
-4. 对安全、无障碍、E2E、性能等深水区只做初筛；需要专项调查时明确分流。
-5. 多维评审时先按职责拆分，再合并同类发现；同一文件同一根因只保留一条主发现，避免重复噪声。
-6. 报告先列阻塞问题，再列建议项；没有证据的问题不要写成确定结论。
+1. Read the project facts first: package scripts, frameworks, directory conventions, recent diffs, existing tests and related rules.
+2. Find problems based on risk, rather than picking styles based on personal preference; each finding must be able to point to specific files, line numbers, and user impacts.
+3. Use five axes to converge conclusions: correctness, maintainability, type/interface, user experience, and verification coverage.
+4. Only preliminary screening will be done for deep water areas such as safety, accessibility, E2E, and performance; diversion will be clearly defined when special investigation is needed.
+5. During multi-dimensional review, first split according to responsibilities, and then merge similar findings; only one main finding for the same root cause of the same file is retained to avoid repeated noise.
+6. List blocking issues first in the report, then recommendations; do not write firm conclusions on issues without evidence.
 
-## 多维评审编排
+## Multi-dimensional review arrangement
 
-当改动跨越多个质量维度时，按“主评审 + 专项分流”组织，而不是让所有维度重复检查同一处代码。
+When changes span multiple quality dimensions, organize them according to "main review + special diversion" instead of having all dimensions repeatedly check the same code.
 
-| 维度                | 触发条件                                             | 分流边界                             |
+| Dimension | Trigger condition | Diversion boundary |
 | ------------------- | ---------------------------------------------------- | ------------------------------------ |
-| TypeScript 工程与类型契约 | DTO、泛型、公共类型、类型守卫、`any`、断言、tsconfig | 深入类型建模和 TS 配置交给 TypeScript 流程 |
-| 状态管理            | 状态归属、全局 store、URL 状态、派生状态、跨页面同步 | 状态选型与迁移交给状态管理专项流程   |
-| 安全                | 用户输入、HTML 渲染、token、上传、第三方脚本         | 漏洞级分析交给安全专项流程           |
-| 无障碍              | 弹窗、菜单、表单、键盘操作、焦点管理                 | WCAG 细查交给无障碍专项流程          |
-| 性能                | 大列表、重依赖、重复请求、长任务、包体积             | 性能证据与预算交给性能专项流程       |
-| E2E                 | 关键用户路径、登录态、支付、跨页面流程               | 浏览器用例与 trace 交给 E2E 专项流程 |
+| TypeScript Projects and Type Contracts | DTOs, generics, public types, type guards, `any`, assertions, tsconfig | In-depth type modeling and TS configuration handed over to the TypeScript process |
+| State management | State attribution, global store, URL state, derived state, cross-page synchronization | State selection and migration are handed over to the state management special process |
+| Security | User input, HTML rendering, token, upload, third-party script | Vulnerability level analysis is handed over to the security-specific process |
+| Accessibility | Pop-up windows, menus, forms, keyboard operations, focus management | WCAG scrutinizes the special accessibility process |
+| Performance | Large lists, heavy dependencies, repeated requests, long tasks, package sizes | Handle performance evidence and budget to the performance-specific process |
+| E2E | Key user path, login status, payment, cross-page process | Browser use cases and traces are handed over to E2E special process |
 
-发现合并规则：
+Discover merge rules:
 
-- 同一根因出现在多个维度时，只保留最高严重级别，并在 `Dimension` 中列出相关维度。
-- 同一文件多处重复模式，合并为一条模式级发现，列出代表性位置。
-- 置信度不足的问题放入 Open Questions，不升级为阻塞项。
-- 自动化可稳定捕获的格式问题交给 lint/format，不作为人工评审主发现。
+- When the same root cause appears in multiple dimensions, only the highest severity level is retained and the related dimensions are listed in `Dimension`.
+- Repeated patterns in multiple places in the same file are merged into one pattern-level discovery, and representative locations are listed.
+- Questions with insufficient confidence are placed in Open Questions and will not be upgraded to blocked items.
+- Format issues that can be stably captured by automation are handed over to lint/format and are not discovered by human reviewers.
 
-## 评审维度
+## Review dimensions
 
-1. 架构
+1. Architecture
 
-- 组件边界是否清晰
-- 展示逻辑与业务逻辑是否分离
-- 是否有可复用抽象
-- 是否存在上帝组件
+- Is the component boundary clear?
+- Whether display logic and business logic are separated
+- Is there a reusable abstraction?
+- Whether there is a God component
 
-2. 类型安全
+2. Type safety
 
-- 是否存在不必要的 `any`
-- props 类型是否明确
-- hooks/composables 返回值是否稳定
-- 在可行情况下 API 契约是否有类型约束
+- Whether there is unnecessary `any`
+- Is the props type clear?
+- Is the return value of hooks/composables stable?
+- Whether the API contract has type constraints where feasible
 
-3. 渲染与状态
+3. Rendering and status
 
-- 是否存在不必要的重复渲染
-- key 的使用是否稳定
-- 可推导状态是否被重复存储
-- 本地状态是否耦合过深
-- 全局 store 是否只保存真正跨边界共享的客户端状态
-- URL 状态、服务端状态、表单状态和浏览器持久化是否边界清晰
+- Is there unnecessary repeated rendering?
+- Is the use of key stable?
+- Whether the deducible state is stored repeatedly
+- Is the local state coupled too deeply?
+- Whether the global store only saves client state that is truly shared across borders
+- Whether the boundaries between URL state, server state, form state and browser persistence are clear
 
-4. 样式
+4. Style
 
-- 已有 Token 时是否还在使用 magic number
-- 类名是否与仓库约定一致
-- 响应式处理是否明确
-- 是否无必要地混用了多套样式体系
+- Whether the magic number is still used when there is already a Token
+- Whether the class name is consistent with the warehouse convention
+- Is responsive processing clear?
+- Are multiple style systems being mixed unnecessarily?
 
-5. 可访问性
+5. Accessibility
 
-- 语义结构是否合理
-- 是否在需要时正确使用 label 和 aria
-- 是否支持键盘操作
-- 浮层和菜单的焦点管理是否正确
+- Is the semantic structure reasonable?
+- Whether label and aria are used correctly when needed
+- Whether to support keyboard operation
+- Is the focus management of floating layers and menus correct?
 
-6. 可维护性
+6. Maintainability
 
-- 组件/页面文件规模是否合理（宜约 **300 行**内；逾 **500 行**或复杂度过高须拆分，见共享 React / Vue 规则中的「组件文件规模」）
-- 命名质量是否良好
-- 是否有应该提取的重复逻辑
-- 是否存在死代码、过期注释或临时性 hack
-- 业务状态、类型、标识是否用裸数字/裸字符串（应对齐 `templates/shared/rules/fec-typescript.md`「禁止 Magic Number / Magic String」）
+- Is the component/page file size reasonable (it should be within **300 lines**; if it exceeds **500 lines** or is too complex, it must be split. See "Component file size" in the shared React/Vue rules)
+- Is the naming quality good?
+- Is there any repetitive logic that should be extracted
+- Whether there is dead code, outdated comments or temporary hacks
+- Whether the business status, type, and identification use bare numbers/naked strings (should be aligned with `templates/shared/rules/fec-typescript.md` "Magic Number / Magic String is prohibited")
 
-7. 测试
+7. Test
 
-- 是否缺少关键测试覆盖
-- 是否存在脆弱的选择器或不稳定的测试模式
+- Is critical test coverage missing?
+- Is there a fragile selector or unstable test mode?
 
-8. 安全
+8. Security
 
-- 无明显 XSS 风险（dangerouslySetInnerHTML / v-html 必须审查）
-- 无敏感信息硬编码
-- 无未校验的用户输入直接渲染
+- No obvious XSS risks (dangerouslySetInnerHTML/v-html must be reviewed)
+- No sensitive information hardcoded
+- Direct rendering without unvalidated user input
 
-9. 性能与体验证据
+9. Performance and experience evidence
 
-- 是否引入首屏重依赖、重复请求、大列表渲染或长任务
-- loading、empty、error、disabled、focus 等状态是否完整
-- 响应式布局是否有可验证断点和文本溢出保护
+- Whether to introduce heavy dependencies on the first screen, repeated requests, large list rendering or long tasks
+- Whether the status of loading, empty, error, disabled, focus, etc. is complete
+- Whether the responsive layout has verifiable breakpoints and text overflow protection
 
-10. 必检项（阻塞合并）
+10. Must-check items (blocking merge)
 
-- [ ] TypeScript 类型完整，无 `any`
-- [ ] 外部输入、DTO、公共类型边界无无守卫断言
-- [ ] 无 XSS 风险
-- [ ] 无敏感信息硬编码
-- [ ] 核心逻辑有单元测试
+- [ ] TypeScript complete type, no `any`
+- [ ] No guardless assertions for external input, DTO, and public type boundaries
+- [ ] No XSS risk
+- [ ] No sensitive information hardcoded
+- [ ] Core logic has unit tests
 
-11. 质量项（建议修改）
+11. Quality items (suggested modifications)
 
-- [ ] 组件文件规模符合约定（约 300 行内为佳；逾 500 行或高复杂度已拆子组件 / Hooks / Composables / utils）
-- [ ] 无重复代码（DRY 原则）
-- [ ] 无未使用的 import
+- [ ] The size of the component file complies with the agreement (within about 300 lines is preferred; if it exceeds 500 lines or is highly complex, the sub-components/Hooks/Composables/utils have been disassembled)
+- [ ] No duplicate code (DRY principle)
+- [ ] No unused imports
 
-12. 规范项（风格建议）
+12. Normative items (style suggestions)
 
-- [ ] 命名语义清晰
-- [ ] 注释覆盖复杂逻辑
+- [ ] clear naming semantics
+- [ ] comments cover complex logic
 
-## 详细参考
+## Detailed reference
 
-撰写代码评审报告时，加载 [references/report-template.md](references/report-template.md)。发现必须具体且可操作；不要写"优化性能"等空泛建议而不指出具体代码模式。
+When writing a code review report, load [references/report-template.md](references/report-template.md). Findings must be specific and actionable; don't write general recommendations such as "optimize performance" without pointing out specific code patterns.
 
 ## Constraints
 
-- 不把个人风格偏好写成阻塞问题；阻塞项必须有明确用户影响、运行时风险、安全风险或维护成本证据。
-- 不在缺少 diff、文件位置或复现线索时给确定结论。
-- 深度安全、无障碍、E2E 和性能问题只做初筛；需要证据链时分流到专项 skill。
-- 同一根因不要重复报多条；合并为一条代表性发现并列出影响范围。
-- 自动化工具稳定覆盖的格式问题交给 lint/format，不作为人工评审主发现。
+- Do not write personal style preferences as blocking issues; blocking items must have clear evidence of user impact, runtime risk, security risk, or maintenance cost.
+- Do not give findings without file locations and supporting evidence; a diff is required only for change review.
+- In-depth security, accessibility, E2E and performance issues are only screened initially; when an evidence chain is needed, they will be diverted to special skills.
+- Do not report multiple reports for the same root cause; merge them into one representative finding and list the scope of impact.
+- Format issues that are stably covered by automated tools are handed over to lint/format and are not discovered by human reviewers.
 
 ## Expected Output
 
-- 分级评审报告（CRITICAL / HIGH / MEDIUM / LOW）
-- 每个问题关联具体文件和行号，附修复建议
-- 阻塞项（CRITICAL）修复前不建议合并
-- 评审报告保存为 `reports/code-review-YYYY-MM-DD-HHmmss.md`
-- 多维评审要合并重复发现，并说明已分流到哪些专项能力
-- 对不确定项标注需要的验证命令或补充上下文，不把猜测写成事实
+- Grading review report (CRITICAL / HIGH / MEDIUM / LOW)
+- Each problem is associated with a specific file and line number, with suggestions for repairing it.
+- It is not recommended to merge the blocking item (CRITICAL) until it is repaired
+- The review report is saved as `reports/code-review-YYYY-MM-DD-HHmmss.md`
+- Multi-dimensional reviews should consolidate duplicate findings and explain which special capabilities have been diverted to
+- Label uncertain items with required verification commands or supplementary context, and do not write guesses into facts
+## Refactoring Boundary
+
+A general review may flag maintainability evidence, but dedicated smell diagnosis or a behavior-preserving refactoring plan owns deeper structural analysis. Review should not silently execute structural changes; it can recommend diagnosis/planning when a finding needs systematic transformation.