@bovinphang/frontend-craft 2.7.0 → 2.9.0

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

@@ -1,112 +1,112 @@
-# TypeScript / JavaScript 规则
+# TypeScript / JavaScript rules
 
-编写、修改或评审 `.ts`、`.tsx`、`.js`、`.jsx` 时应用本文件。本文只保留项目常驻硬约束；复杂类型建模、`tsconfig` 分层、声明产物、DTO / view model 边界、类型测试与发布入口设计，交给 `fec-typescript-project-standard` skill 或专项评审处理。注释风格另见 `fec-code-comments.md`；E2E 与校验流程另见 `fec-testing.md`。
+Use this file when writing, modifying or reviewing `.ts`, `.tsx`, `.js`, `.jsx`. This article only retains the permanent hard constraints of the project; complex type modeling, `tsconfig` layering, declared products, DTO / view model boundaries, type testing and release entry design are left to the `fec-typescript-project-standard` skill or special review. See also `fec-code-comments.md` for comment style; see `fec-testing.md` for E2E and verification process.
 
-## 类型与接口
+## Types and interfaces
 
-用类型让对外 API、共享模型与组件 props 显式、可读、可复用。
+Use types to make external APIs, shared models, and component props explicit, readable, and reusable.
 
-### 对外导出的 API
+### Externally exported API
 
-- 对**导出**的函数、共享工具函数、公开类方法，写明参数与返回值类型。
-- **局部**变量在类型显而易见时交给 TypeScript 推断，不为显而易见的中间变量重复标注。
-- 重复出现的内联对象形状抽成具名 `interface` 或 `type`，避免同一契约散落在多个签名中。
-- 外部数据、API DTO、路由参数、表单值与组件 props 的边界要显式命名；复杂建模分流到 `fec-typescript-project-standard`。
+- For **export** functions, shared tool functions, and public class methods, indicate the parameter and return value types.
+- **Local** variables are handed over to TypeScript for inference when the type is obvious, and obvious intermediate variables are not repeatedly annotated.
+- Recurring inline object shapes are extracted into named `interface` or `type` to avoid the same contract being scattered in multiple signatures.
+- The boundaries of external data, API DTOs, routing parameters, form values and component props must be explicitly named; complex modeling is offloaded to `fec-typescript-project-standard`.
 
-### `interface` 与 `type`
+### `interface` and `type`
 
-- 可能被扩展或 `implements` 的**对象形状**优先用 `interface`。
-- **联合、交叉、元组、映射类型、工具类型组合**用 `type`。
-- 状态、类型、角色等有限业务取值优先用字符串字面量联合；仅在互操作或团队统一要求时使用 `enum`。
+- Object shapes that may be extended or `implements` take precedence over `interface`.
+- **Union, intersection, tuple, map type, tool type combination** use `type`.
+- Limited business values such as status, type, role, etc. are first combined with string literals; `enum` is only used when interoperability or team unified requirements are met.
 
-### 函数参数：复杂类型宜具名
+### Function parameters: complex types should be named
 
-- 参数上的**复杂联合**、**内联对象类型**、**较复杂的回调签名**等，应优先提取为具名 `type` / `interface`，再在函数签名中引用。
-- 仅当类型简单、短小、一眼可读，且明显无复用价值时，允许在参数位置内联。
-- 回调参数与返回值必须表达清楚；不要用 `Function`、宽泛对象或隐式 `any` 承接业务契约。
+- **Complex unions**, **inline object types**, **more complex callback signatures**, etc. on parameters should be extracted as named `type` / `interface` first, and then referenced in the function signature.
+- Inlining in parameter positions is only allowed if the type is simple, short, readable at a glance, and has obvious no reuse value.
+- Callback parameters and return values must be expressed clearly; do not use `Function`, wide objects or implicit `any` to undertake business contracts.
 
-### 避免 `any`
+### Avoid `any`
 
-- 业务代码中避免 `any`；已有遗留 `any` 不随手扩散。
-- 外部或不可信数据用 `unknown`，通过 `typeof`、`in`、`instanceof`、schema parse 或自定义 predicate 安全收窄。
-- 类型随调用方变化时用泛型，但不要为简单场景引入难以理解的泛型层。
-- `as` 类型断言只用于明确的边界互操作或已验证收窄后的补充表达，不用于压制类型错误。
+- Avoid `any` in business code; existing `any` should not be spread casually.
+- Use `unknown` for external or untrusted data, safely narrowed through `typeof`, `in`, `instanceof`, schema parse or custom predicate.
+- Use generics when the type changes from caller to caller, but don’t introduce an incomprehensible layer of generics for simple scenarios.
+- `as` type assertions are only used for explicit boundary interoperation or supplementary expressions after verified narrowing, and are not used to suppress type errors.
 
-### React 组件 Props
+### React Component Props
 
-- 用具名 `interface` 或 `type` 定义 props，复杂公共 props 分流到类型模块。
-- 回调 props 写清参数与返回值；事件 payload 不用裸对象长期内联。
-- 无特殊理由不使用 `React.FC`，避免隐式 `children` 等差异。
-- TSX 泛型、复杂组件 props 或外部 DTO 映射问题，交给 React 规则与 `fec-typescript-project-standard` 共同收敛。
+- Define props with named `interface` or `type`, and offload complex public props to type modules.
+- Write clear parameters and return values in callback props; event payload does not require long-term inlining of bare objects.
+- Don't use `React.FC` without special reason, avoid differences such as implicit `children`.
+- TSX generics, complex component props or external DTO mapping issues are left to React rules and `fec-typescript-project-standard` to converge together.
 
-## 单文件规模与模块拆分
+## Single file size and module splitting
 
-- `.ts` / `.tsx` / `.js` / `.jsx` 单文件建议控制在**约 300 行以内**。该阈值是可维护性与评审效率的经验上限，不是机械硬限制。
-- 当文件明显超过该规模且承担多重职责时，应优先按职责拆分：数据访问、业务规则、视图渲染、适配层、常量与映射、类型定义。
-- 超阈值优先提取纯函数、子组件、自定义 Hook、`*.types.ts` 类型模块、常量表；不要仅为压行数做无意义切分。
-- 可接受例外：生成代码、极薄的 re-export 聚合文件、经团队评审确认的高内聚模块；例外建议在文件头简短注明原因。
+- `.ts` / `.tsx` / `.js` / `.jsx` It is recommended that a single file be controlled within **about 300 lines**. This threshold is an empirical upper limit for maintainability and review efficiency, not a mechanical hard limit.
+- When the file obviously exceeds this size and bears multiple responsibilities, priority should be given to splitting it by responsibility: data access, business rules, view rendering, adaptation layer, constants and mapping, and type definition.
+- Prioritize extraction of pure functions, subcomponents, custom Hooks, `*.types.ts` type modules, and constant tables above the threshold; do not make meaningless segmentation just for the number of pressed lines.
+- Acceptable exceptions: generated code, very thin re-export aggregation files, high cohesion modules confirmed by team review; exceptions are recommended to briefly indicate the reasons in the file header.
 
-### 仍为 JavaScript 的文件
+### Still a JavaScript file
 
-- 在 `.js` / `.jsx` 中，若短期无法迁 TS，可用 JSDoc 补类型，并与运行时行为一致。
-- 不为迁移方便引入新的隐式全局、宽松对象或未验证外部输入。
+- In `.js` / `.jsx`, if TS cannot be migrated in the short term, JSDoc can be used to complement the type, and the behavior will be consistent with the runtime.
+- Do not introduce new implicit globals, loose objects, or unvalidated external inputs for migration convenience.
 
-## 禁止 Magic Number / Magic String
+## Disable Magic Number / Magic String
 
-- **业务代码中禁止**使用**无语义**的硬编码数字或字符串直接表示状态、类型、标识或业务含义，包括 `if` / `switch` / 赋值 / API 字段映射。
-- 固定且有限的取值范围须在单一真源处定义，并在全仓引用名称，避免裸值散落。
-- 前端主路径优先使用 `as const` 常量对象配合字面量联合；与后端协议或团队约定强绑定时可使用 `enum`。
-- 不属本条的典型例外仍应保持可读：纯算法下标、明显的 `0` / `1` 长度判断、与业务无关的 UI 刻度；视觉值若已有设计 Token，应改走 `fec-design-system.md`。
+- **It is prohibited** in business code to use **semantic** hard-coded numbers or strings to directly represent status, type, identity or business meaning, including `if` / `switch` / assignment / API field mapping.
+- The fixed and limited value range must be defined at a single true source, and the name must be referenced in the entire warehouse to avoid the scattering of bare values.
+- The front-end main path preferentially uses `as const` constant objects with literal unions; `enum` can be used when strongly bound to the back-end protocol or team agreement.
+- Typical exceptions that do not fall under this article should still remain readable: pure algorithm subscripts, obvious `0` / `1` length judgments, UI scales that have nothing to do with business; if the visual value already has a design token, it should be changed to `fec-design-system.md`.
 
-## 不可变更新
+## Immutable updates
 
-- 优先返回新对象或新数组，避免直接改写入参、props、store 快照或缓存对象。
-- 对不应被修改的数据优先建模为 `readonly` / `Readonly<T>`。
-- 大型嵌套更新应使用项目既有状态方案或清晰的 reducer / helper，不在组件中堆叠临时可变逻辑。
+- Prioritize returning new objects or new arrays and avoid directly modifying parameters, props, store snapshots or cache objects.
+- Data that should not be modified is first modeled as `readonly` / `Readonly<T>`.
+- Large nested updates should use the project's existing state scheme or a clear reducer/helper, without stacking temporary mutable logic in components.
 
-## 异步与错误处理
+## Asynchronous and error handling
 
-- 使用 `async` / `await` 与明确的错误边界；不要吞掉 promise rejection。
-- `catch` 中将错误视为 `unknown` 再收窄，统一映射为用户可见错误、日志错误或调用方可处理的领域错误。
-- API、认证、上传、支付等跨边界错误遵循 `fec-api-layer.md`、`fec-error-handling.md` 和安全规则，不在业务组件中散落裸处理。
+- Use `async` / `await` with clear error boundaries; don't swallow promise rejections.
+- In `catch`, errors are treated as `unknown` and then narrowed down, and uniformly mapped to user-visible errors, log errors or domain errors that can be handled by the caller.
+- Cross-border errors such as API, authentication, upload, and payment follow `fec-api-layer.md`, `fec-error-handling.md` and security rules, and are not handled nakedly in business components.
 
-## 输入校验
+## Input verification
 
-- 外部输入（表单、API、URL 参数、localStorage、postMessage、第三方 SDK 回调等）必须在边界处校验或收窄。
-- 可使用 Zod、Valibot、Yup 或项目选用的同类 schema 工具；不要把具体库作为无条件新依赖引入。
-- schema 推导类型可作为输入类型单一真源；复杂 DTO、领域模型与 UI view model 的分层交给 `fec-typescript-project-standard`。
+- External input (forms, APIs, URL parameters, localStorage, postMessage, third-party SDK callbacks, etc.) must be validated or narrowed at boundaries.
+- You can use Zod, Valibot, Yup or similar schema tools selected by the project; do not introduce specific libraries as unconditional new dependencies.
+- Schema derived types serve as a single source of truth for input types; layering of complex DTOs, domain models and UI view models is left to `fec-typescript-project-standard`.
 
-## 类型资产分层与命名
+## Type asset layering and naming
 
-- 模块或特性专属类型使用 `*.types.ts`，并与实现文件同目录或同 feature 目录放置。
-- 全局与环境相关声明放在 `global.d.ts`、`env.d.ts` 或 `types/*.d.ts`，仅用于真全局或 ambient 声明，不将可模块化类型放入全局。
-- 仅用于类型的导入导出优先使用 `import type` 与 `export type`，减少值空间歧义并提升编译语义清晰度。
-- 与 API DTO 同源的类型，放在对应 feature 或 API 子目录，避免在页面或组件实现内散落大型匿名类型。
-- `index.ts` 聚合导出应保持浅层且按 feature 边界组织，避免深层 barrel 引发循环依赖与不必要耦合。
+- Module or feature-specific types use `*.types.ts` and are placed in the same directory as the implementation file or in the same feature directory.
+- Global and environment-related declarations are placed in `global.d.ts`, `env.d.ts` or `types/*.d.ts`, only for true global or ambient declarations, and do not put modular types into globals.
+- For import and export of types only, use `import type` and `export type` first to reduce value space ambiguity and improve compilation semantic clarity.
+- Types that have the same origin as the API DTO are placed in the corresponding feature or API subdirectory to avoid scattering large anonymous types within the page or component implementation.
+- `index.ts` aggregate exports should be kept shallow and organized according to feature boundaries to avoid deep barrels causing circular dependencies and unnecessary coupling.
 
-## 工程化与惯用法补充
+## Engineering and idiom additions
 
-- 需要同时满足字面量保留与结构校验时优先使用 `satisfies`，再考虑类型断言。
-- 使用判别式联合表达清晰状态；关键分支需要穷尽性时用 `never` 检查。
-- 新业务代码默认采用 ES Module；`namespace` 与三斜线指令仅用于声明合并或遗留互操作场景。
-- 扩展第三方类型时使用独立声明文件并通过局部 `declare module` 扩展，避免污染全局实现文件。
-- `tsconfig`、package exports、声明文件、路径别名和 public API 类型属于 TypeScript 项目规范深水区，不在本规则内展开。
+- When both literal preservation and structure verification need to be met, use `satisfies` first, and then consider type assertions.
+- Use discriminant unions to express clear states; use `never` checks when exhaustiveness is required for critical branches.
+- New business code uses ES Module by default; `namespace` and triple slash directives are only used to declare merge or legacy interop scenarios.
+- When extending third-party types, use independent declaration files and extend them through local `declare module` to avoid polluting the global implementation file.
+- `tsconfig`, package exports, declaration files, path aliases and public API types belong to the deep water area of TypeScript project specifications and are not expanded within this rule.
 
-## 日志与 `console.log`
+## Logs and `console.log`
 
-- 生产路径避免遗留 `console.log`；使用项目统一的日志方案。
-- 调试日志提交前应删除，或按团队工具链通过 lint / hook / CI 提示。
+- Avoid legacy `console.log` in the production path; use the project's unified logging scheme.
+- Debug logs should be deleted before submission, or prompted by the team toolchain via lint/hook/CI.
 
-## 密钥与敏感配置
+## Keys and sensitive configurations
 
-- **禁止**在源码中硬编码密钥、Token、私钥或真实凭证示例。
-- 必须通过环境变量或构建期注入读取配置，并在缺失时显式失败或提供清晰降级策略。
-- 涉及认证、支付、上传、第三方脚本或敏感数据处理时，结合项目安全规范做专项评审。
+- **Prohibited** Hardcoding keys, tokens, private keys, or real credential examples in source code.
+- Configuration must be read via environment variables or build-time injection, and fail explicitly if missing or provide a clear downgrade strategy.
+- When authentication, payment, uploading, third-party scripts or sensitive data processing are involved, special reviews will be conducted in conjunction with project security specifications.
 
-## 与测试规则的关系
+## Relationship with test rules
 
-类型改动影响 public API、DTO、外部输入收窄或关键业务分支时，应补充 typecheck、类型测试、组件测试或消费方 fixture。关键用户路径的端到端覆盖方式（Playwright、Cypress、Page Object 等）以 `fec-testing.md` 为准；本文件不重复展开 E2E 细则。
+When type changes affect public APIs, DTOs, external input narrowing, or business-critical branches, typechecks, type tests, component tests, or consumer fixtures should be supplemented. The end-to-end coverage method of key user paths (Playwright, Cypress, Page Object, etc.) is subject to `fec-testing.md`; this document does not repeat the E2E details.
 
-## 与 `typescript-reviewer` 子代理
+## With the `typescript-reviewer` subagent
 
-对 **`.ts` / `.tsx` / `.js` / `.jsx`** 进行专项评审（先跑 typecheck / eslint、PR 合并就绪检查、分级结论）时，可委托插件内置的 **`typescript-reviewer`** 子代理；其报告默认写入 `reports/typescript-review-YYYY-MM-DD-HHmmss.md`，规则底线仍以本文件与项目 `CLAUDE.md` 为准。
+When conducting a special review of **`.ts` / `.tsx` / `.js` / `.jsx`** (run typecheck / eslint first, PR merge readiness check, graded conclusion), you can entrust the plug-in's built-in **`typescript-reviewer`** subagent; its report is written by default `reports/typescript-review-YYYY-MM-DD-HHmmss.md`, the bottom line of the rules is still based on this file and the project `CLAUDE.md`.

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

@@ -1,64 +1,64 @@
-# Vue 规则
+# Vue rules
 
-当仓库或目标模块使用 Vue 时，应用本文件。
+This file applies when the repository or target module uses Vue.
 
-## 技术栈
+## Technology stack
 
-<!-- 请根据项目实际情况修改 -->
+<!-- Please modify according to the actual situation of the project -->
 
-- 框架: Vue 3 + TypeScript
-- 状态管理: Pinia
-- UI 组件库: 按项目实际选择（如 Element Plus、Naive UI、Vant 或内部 Design System）
-- 版本与依赖：新建模块、补充 `package.json` 或更新本节前，优先采用彼此兼容的主流稳定版本（对齐官方文档、脚手架默认值或包管理器推荐），避免混用已停止维护或与仓库主线 major 不匹配的依赖。
+- Framework: Vue 3 + TypeScript
+- Status management: Pinia
+- UI component library: Actual selection by project (e.g. Element Plus, Naive UI, Vant or in-house Design System)
+- Versions and dependencies: Before creating a new module, supplementing `package.json` or updating this section, give priority to using mainstream stable versions that are compatible with each other (align with official documents, scaffolding defaults or package manager recommendations) to avoid mixing dependencies that have stopped maintaining or do not match the major of the mainline of the warehouse.
 
-## Vue 组件规范
+## Vue component specification
 
-- 使用 `<script setup lang="ts">`
-- 明确使用 `defineProps` 和 `defineEmits`
-- 保持模板逻辑简单、可读
-- 将可复用逻辑提取到 composables
-- 优先使用 computed，而不是大范围 watcher
-- 保持组件职责聚焦，避免上帝组件
-- props、emits、refs 和 expose 方法尽量使用强类型
+- Use `<script setup lang="ts">`
+- Explicit use of `defineProps` and `defineEmits`
+- Keep template logic simple and readable
+- Extract reusable logic into composables
+- Prefer computed over large-scale watchers
+- Keep component responsibilities focused and avoid god components
+- Try to use strong types for props, emits, refs and expose methods
 
-## Vue 实现指导
+## Vue Implementation Guide
 
-创建新组件前：
+Before creating a new component:
 
-1. 先搜索项目中是否已有可复用组件
-2. 判断逻辑是否适合提取到 composable
-3. 检查样式是否应沿用周边现有模式
+1. First search whether there are reusable components in the project
+2. Determine whether the logic is suitable for extraction into composable
+3. Check whether the style should inherit surrounding existing patterns
 
-编辑 Vue 组件时：
+When editing a Vue component:
 
-- 在可能的情况下，不要把 API 调用直接放进纯展示组件
-- 不要在组件文件中内联大段业务逻辑
-- 不要重复维护可从 props 或 store 推导出的状态
-- 事件 payload 要明确且有类型约束
+- Where possible, don’t put API calls directly into purely presentational components
+- Do not inline large sections of business logic in component files
+- Don't repeatedly maintain state that can be derived from props or stores
+- Event payload should be clear and type-constrained
 
-## Vue 文件组织
+## Vue file organization
 
-优先遵循项目已有约定。
-常见输出可能包括：
+Prioritize compliance with existing project agreements.
+Common output may include:
 
 - `ComponentName.vue`
 - `types.ts`
 - `useXxx.ts`
-- 只有在符合仓库模式时才新增本地样式文件
+- Add local style files only if they conform to the warehouse mode
 
-## 组件文件规模
+## Component file size
 
-- 单个 `.vue` 文件或同一组件模块保持**职责单一**、语义清晰、易于维护。
-- **行数参考**：优先控制在约 **300 行**以内；超过 **500 行**应视为**强烈拆分信号**。
-- **未到 500 行也应拆分**的情形：同时存在**复杂响应式状态**、**过多副作用 / watch**、**模板嵌套过深**、**`<script setup>` 内逻辑过长**、密集条件分支等，应拆为**子组件**、**Composables**、**工具模块**、**常量**与**类型定义**等（与上文「Vue 组件规范」「Vue 文件组织」一致）。
+- A single `.vue` file or the same component module maintains a single responsibility, clear semantics, and easy maintenance.
+- **Row number reference**: Prioritize control within about **300 lines**; more than **500 lines** should be regarded as a **strong split signal**.
+- **Situations that should be split even if it is less than 500 lines**: if there are **complex responsive states**, **too many side effects/watch**, **templates nested too deeply**, **`<script setup>` internal logic is too long**, dense conditional branches, etc., they should be split into **subcomponents**, **Composables**, **tool modules**, **constants** and **type definitions**, etc. (consistent with the "Vue component specification" and "Vue file organization" above).
 
-## Vue 反模式
+## Vue anti-patterns
 
-避免：
+Avoid:
 
-- 本该使用 computed 却使用大范围 watcher
-- 对 props、emits 或 refs 无理由使用 `any`
-- 模板分支层级过深却不提取
-- 在一个组件中混入无关职责
-- 单 `.vue` **逾 500 行或复杂度已高**仍拒不拆分（参见上文「组件文件规模」）
-- 用大范围全局样式覆盖去解决局部 UI 问题
+- Used wide range watcher instead of computed
+- Use `any` for props, emits or refs without reason
+- The template branch level is too deep but not extracted
+- Mixing unrelated responsibilities into a component
+- A single `.vue` **exceeds 500 lines or is too complex** and still refuses to be split (see "Component file size" above)
+- Use large-scale global style coverage to solve local UI problems

package/templates/shared/rules/fec-working-modes.md

@@ -1,50 +1,50 @@
-# 工作模式规则
+# Working mode rules
 
-根据任务阶段选择合适的工作模式，避免一边探索一边大改代码。
+Choose the appropriate working mode according to the task stage to avoid making major changes to the code while exploring.
 
-## 调研模式
+## Research mode
 
-适用于需求不清、现状复杂、需要比较方案或定位风险时。
+It is suitable when the requirements are unclear, the current situation is complex, and it is necessary to compare plans or locate risks.
 
-- 先阅读 README、项目规则、相关源码和最近变更。
-- 用 `rg` 查找已有模式、组件、工具函数和测试。
-- 先列发现，再给建议。
-- 在证据不足时不要下确定结论。
-- 涉及版本敏感框架、库或平台行为时，先查项目内事实和官方来源。
+- Read the README, project rules, relevant source code and recent changes first.
+- Use `rg` to find existing patterns, components, utility functions and tests.
+- List findings first, then give suggestions.
+- Do not draw firm conclusions when there is insufficient evidence.
+- When version-sensitive frameworks, libraries, or platform behaviors are involved, check the facts within the project and official sources first.
 
-## 计划模式
+## Planning mode
 
-适用于复杂功能、架构调整、跨文件重构和高风险修复。
+Suitable for complex features, architecture adjustments, cross-file refactoring, and high-risk fixes.
 
-- 重述目标、成功标准和不做什么。
-- 标出影响范围、文件边界、依赖关系、风险和验证方式。
-- 计划应能分批执行，每批都有可验证结果。
-- 用户未确认前，不执行大范围实现。
+- Restate goals, success criteria, and what not to do.
+- Map out scope of impact, file boundaries, dependencies, risks and verification methods.
+- The plan should be able to be executed in batches, with verifiable results for each batch.
+- Large-scale implementation will not be performed before the user confirms.
 
-## 开发模式
+## Development mode
 
-适用于目标明确且已有计划或范围很小的实现。
+Suitable for implementations with clear goals and plans or a small scope.
 
-- 优先复用现有模式。
-- 行为变更优先使用 TDD：先失败测试，再最小实现，再重构。
-- 每次关键修改后运行最近的验证命令。
-- 完成时总结改动、命令和剩余风险。
-- 行为、接口或性能假设必须能被类型、测试、构建、浏览器观察或文档来源支撑。
+- Prioritize reuse of existing patterns.
+- Use TDD first for behavior changes: fail the test first, then implement the minimum, and then refactor.
+- Run the latest verification command after every critical modification.
+- Summarize changes, orders, and remaining risks upon completion.
+- Behavior, interface, or performance assumptions must be supported by types, tests, builds, browser observations, or documentation sources.
 
-## 评审模式
+## Review mode
 
-适用于 PR、最近变更、合并前检查和专项审查。
+Applies to PRs, recent changes, pre-merger checks, and ad hoc reviews.
 
-- 先通读上下文，再按严重程度列问题。
-- 优先报告会导致 bug、安全风险、回归或维护成本明显上升的问题。
-- 每个问题给出文件位置、影响、建议修复方式和置信度。
-- 无问题时明确说明剩余测试缺口。
+- Read through the context first, then list the issues in order of severity.
+- Prioritize reporting of issues that result in bugs, security risks, regressions, or significant increases in maintenance costs.
+- Each issue gives the file location, impact, recommended fix and confidence level.
+- Clear indication of remaining test gaps when no issues arise.
 
-## 收尾模式
+## Ending mode
 
-适用于提交前或交付前。
+Applies to pre-submission or delivery.
 
-- 运行 lint、type-check、test、build 中与改动相关的命令。
-- 检查是否有调试代码、临时文件、未同步文档或未说明的风险。
-- 不在未经确认时提交或推送。
-- 不用“应该可以”作为交付依据；交付前报告实际运行过的命令和结果。
+- Run commands related to changes in lint, type-check, test, and build.
+- Check for debug code, temporary files, unsynced documentation, or unaccounted for risks.
+- Don't commit or push without confirmation.
+- Do not use "should be able" as the basis for delivery; report the actual run commands and results before delivery.