@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/templates/openclaw/AGENTS.md

@@ -1,101 +1,101 @@
-# 项目说明
+# Project description
 
-本工作区由前端团队维护（由 **frontend-craft** OpenClaw 插件模板初始化）。
+This workspace is maintained by the frontend team (initialized by the **frontend-craft** OpenClaw plugin template).
 
-核心要求：
+Core requirements:
 
-- 在调整架构前，先理解现有代码
-- 优先复用，而不是重复造轮子
-- 保持改动小、清晰、便于评审
-- 先遵循项目标准，再考虑通用模式
+- Understand the existing code before adjusting the architecture
+- Prioritize reuse rather than reinventing the wheel
+- Keep changes small, clear, and easy to review
+- Follow project standards first, then consider common patterns
 
-## 项目基础信息
+##Basic project information
 
-<!-- 请根据项目实际情况修改以下配置 -->
+<!-- Please modify the following configuration according to the actual situation of the project -->
 
-- 语言：TypeScript
-- 包管理器：pnpm
-- 构建工具：Vite
-- 测试工具: Vitest + Testing Library
-- UI 体系：优先复用现有组件库和设计 Token
-- 设计实现流程：如有条件，优先使用设计工具 MCP（Figma / MasterGo / Pixso / 墨刀 / Sketch）上下文
+- Language: TypeScript
+- Package manager: pnpm
+- Build tool: Vite
+- Testing tools: Vitest + Testing Library
+- UI system: Prioritize reusing existing component libraries and design tokens
+- Design implementation process: If possible, give priority to using the design tool MCP (Figma / MasterGo / Pixso / Mo Knife / Sketch) context
 
-## 常用命令
+## Common commands
 
-优先使用仓库现有命令，不要自行发明替代命令。
+Prioritize using existing commands in the warehouse instead of inventing replacement commands.
 
-<!-- 请根据项目实际情况修改 -->
+<!-- Please modify according to the actual situation of the project -->
 
-- 安装：`pnpm install`
-- 开发：`pnpm dev`
+- Installation: `pnpm install`
+- Development: `pnpm dev`
 - Lint：`pnpm lint`
-- 类型检查：`pnpm type-check`
-- 测试：`pnpm test`
-- 构建：`pnpm build`
+- Type check: `pnpm type-check`
+- Test: `pnpm test`
+- Build: `pnpm build`
 
-如果命令缺失，先检查 `package.json`。
+If the command is missing, check `package.json` first.
 
-## 通用工作原则
+## General working principles
 
-改代码前：
+Before changing the code:
 
-1. 阅读目标模块及其周边模块
-2. 搜索已有可复用组件或工具函数
-3. 理解当前样式和 Token 约定
-4. 如果仓库里已有一套模式，不要再引入第二套
+1. Read the target module and its surrounding modules
+2. Search for existing reusable components or tool functions
+3. Understand the current style and Token convention
+4. If there is already a set of patterns in the warehouse, do not introduce a second set
 
-实现时：
+When implemented:
 
-- 保持组件职责聚焦
-- 将重复逻辑提取到 hooks / composables / utils
-- 优先使用明确类型
-- 优先使用可推导状态，避免重复维护状态
-- 除非任务明确要求破坏性变更，否则保持向后兼容
+- Keep component responsibilities focused
+- Extract duplicate logic to hooks/composables/utils
+- Prefer explicit types
+- Prioritize the use of deducible state to avoid repeated maintenance of state
+- Maintain backwards compatibility unless the mission explicitly requires breaking changes
 
-完成后：
+After completion:
 
-- 执行 lint
-- 如有类型检查则执行 type check
-- 如有测试则执行测试
-- 总结改动文件、关键决策和剩余风险
+- execute lint
+- If there is a type check, execute type check
+- If there is a test, execute the test
+- Summarize change documents, key decisions and remaining risks
 
-## Git 规范
+## Git specification
 
-- 提交前必须通过 lint 和类型检查
-- 未经我确认不要直接 commit
-- 分支命名: feature/xxx, fix/xxx, refactor/xxx
-- Commit 格式: 遵循 Conventional Commits（详见本文件同目录 skills 下的 `git-conventions.md`）
+- Must pass lint and type checking before submission
+- Don’t commit directly without my confirmation
+- Branch naming: feature/xxx, fix/xxx, refactor/xxx
+- Commit format: Follow Conventional Commits (for details, see `git-conventions.md` under skills in the same directory as this file)
 
-## 设计稿实现工作流
+## Design draft implementation workflow
 
-当存在设计上下文时：
+When a design context exists:
 
-1. 先通过 MCP 读取设计上下文（Figma / MasterGo / Pixso / 墨刀 / Sketch，摹客则使用截图/标注）
-2. 检查项目现有组件体系
-3. 先产出简短实现计划
-4. 分步骤实现
-5. 执行校验命令
-6. 总结偏差和风险
+1. First read the design context through MCP (Figma / MasterGo / Pixso / Ink Knife / Sketch, Mock uses screenshots / annotations)
+2. Check the existing component system of the project
+3. First produce a short implementation plan
+4. Implement in steps
+5. Execute the verification command
+6. Summarize biases and risks
 
-## 安全要求
+## Security requirements
 
-不要主动暴露或打印任何密钥。
-除非任务明确要求且权限允许，不要读取或修改敏感文件。
-除非明确要求并获得批准，不要执行破坏性 shell 命令。
+Do not actively expose or print any keys.
+Do not read or modify sensitive files unless explicitly required by the task and permitted by permissions.
+Do not execute destructive shell commands unless explicitly requested and approved.
 
-## 规则与扩展技能
+## Rules and Extended Skills
 
-OpenClaw 会从本工作区的 `skills/` 加载 Markdown 技能。初始化后规则文件位于：
+OpenClaw will load Markdown skills from `skills/` in this workspace. After initialization the rules file is located at:
 
 `skills/frontend-craft-rules/`
 
-按需阅读并在对话中引用相关片段，例如：
+Read as needed and quote relevant passages in the conversation, for example:
 
-- `skills/frontend-craft-rules/fec-vue.md` / `fec-react.md` — 框架规范
-- `skills/frontend-craft-rules/fec-typescript.md` — TypeScript/JavaScript（与 `typescript-reviewer` 剧本联动）
-- `skills/frontend-craft-rules/fec-code-comments.md` — 代码注释（何时写、写什么）
-- `skills/frontend-craft-rules/fec-testing.md`、`fec-performance.md`、`fec-design-system.md` 等
-- `skills/frontend-craft-rules/fec-agent-workflow.md` — 子代理协作边界
-- `skills/frontend-craft-rules/fec-working-modes.md` — 调研、计划、开发、评审、收尾模式
+- `skills/frontend-craft-rules/fec-vue.md` / `fec-react.md` — Framework specification
+- `skills/frontend-craft-rules/fec-typescript.md` — TypeScript/JavaScript (linked with `typescript-reviewer` script)
+- `skills/frontend-craft-rules/fec-code-comments.md` — code comments (when to write, what to write)
+- `skills/frontend-craft-rules/fec-testing.md`, `fec-performance.md`, `fec-design-system.md`, etc.
+- `skills/frontend-craft-rules/fec-agent-workflow.md` — subagent collaboration boundary
+- `skills/frontend-craft-rules/fec-working-modes.md` — research, planning, development, review, finishing modes
 
-若项目不需要某项规则，可删除对应文件或在对话中说明忽略。
+If the project does not require a certain rule, you can delete the corresponding file or explain it in the dialog to ignore it.

package/templates/openclaw/OPENCLAW-CONFIG.md

@@ -1,12 +1,12 @@
-# OpenClaw 配置说明（替代原 Claude Code settings.json）
+# OpenClaw configuration instructions (replacing the original Claude Code settings.json)
 
-本插件不再提供 `settings.json`（Claude Code 专用）。在 OpenClaw 中请使用网关配置文件，例如：
+This plugin no longer provides `settings.json` (Claude Code only). In OpenClaw please use a gateway configuration file, for example:
 
-- 用户级：`~/.openclaw/openclaw.json`（或你的 profile 路径）
-- 工作区：按 `openclaw configure` / 文档约定
+- User level: `~/.openclaw/openclaw.json` (or your profile path)
+- workspace: as per `openclaw configure`/documentation convention
 
-常用关注点：
+Common concerns:
 
-- **沙箱与执行策略**：参见官方文档 [Sandboxing](https://docs.openclaw.ai/gateway/sandboxing) 中的 `agents.defaults.sandbox` 等键
-- **插件开关**：`plugins.entries.frontend-craft` 下可覆盖本插件 `configSchema` 中的布尔项（如 `formatAfterWrite`、`notifyOnAgentEnd`）
-- **MCP**：原生插件不会自动合并仓库根目录的 `.mcp.json`；请将其中 `mcpServers` 合并到你的 embedded Pi / 网关 MCP 配置（见主 README 的 MCP 章节）
+- **Sandbox and execution strategy**: See the `agents.defaults.sandbox` and other keys in the official document [Sandboxing](https://docs.openclaw.ai/gateway/sandboxing)
+- **Plug-in switch**: `plugins.entries.frontend-craft` can override the Boolean items in the `configSchema` of this plugin (such as `formatAfterWrite`, `notifyOnAgentEnd`)
+- **MCP**: The native plug-in will not automatically merge `.mcp.json` in the warehouse root directory; please merge `mcpServers` into your embedded Pi/gateway MCP configuration (see the MCP chapter of the main README)

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

@@ -1,54 +1,55 @@
-# 子代理协作规则
+# 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.
+- For automatic review after edits, explicitly pass the current change scope (files and diff/PR/commit context). Unqualified review defaults to the entire project; specifying a file/directory alone requests full review of that scope, not incremental review.
+- 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.