@bovinphang/frontend-craft 2.7.0 → 2.9.0

package/skills/fec-tdd-workflow/SKILL.md

@@ -1,52 +1,56 @@
 ---
 name: fec-tdd-workflow
-description: Use when implementing new frontend behavior, fixing bugs, or refactoring logic where tests can describe the expected behavior first. Apply to components, hooks/composables, utilities, API clients, route guards, or user workflows; Chinese triggers include TDD, 测试驱动, 先写测试, 红绿重构, 回归测试.
+description: Use when implementing new observable frontend behavior or fixing a behavior-changing bug where a failing test can describe the missing or incorrect behavior first. Apply to components, hooks/composables, utilities, API clients, route guards, or user workflows; pure behavior-preserving refactoring uses an already-green contract instead.
 ---
 
-# 前端 TDD 工作流
+# Front-end TDD workflow
 
 ## Purpose
 
-用“先写失败测试，再实现最小代码，再重构”的节奏交付前端功能，避免只在实现后补覆盖率。
+Use the rhythm of "write failing tests first, then implement the minimum code, and then refactor" to deliver front-end functions to avoid supplementing coverage only after implementation.
 
 ## Procedure
 
-1. 识别可观察行为：用户能看到的 UI、组件契约、hook/composable 返回值、路由守卫结果、API client 输出或错误状态。
-2. 先写一个最小失败测试：
-   - 纯逻辑优先单元测试。
-   - 组件交互优先 Testing Library / Vue Test Utils。
-   - 跨页关键流程优先 Playwright / Cypress。
-3. 运行该测试并确认失败原因正确，失败应来自行为尚未实现，而不是语法、导入或测试环境错误。
-4. 写刚好能通过测试的最小实现，不顺手扩大范围。
-5. 重新运行测试，确认变绿。
-6. 在测试保持通过的前提下重构命名、边界和重复逻辑。
-7. 对 bug 修复，保留能复现问题的回归测试。
-8. 每轮只扩大一个可观察行为；新需求、新边界和新异常路径各自进入下一轮。
+1. Identify observable behaviors: UI, component contracts, hook/composable return values, route guard results, API client output or error status that users can see.
+2. First write a minimum failure test:
+   - Pure logic first unit testing.
+   - Prioritize component interaction Testing Library / Vue Test Utils.
+   - Prioritize critical processes across pages Playwright/Cypress.
+3. Run the test and confirm that the failure reason is correct and should come from behavior that has not yet been implemented, rather than a syntax, import, or test environment error.
+4. Write the minimum implementation that can just pass the test, and do not expand the scope easily.
+5. Rerun the test and confirm it turns green.
+6. Refactor naming, boundaries and duplication logic while keeping tests passing.
+7. Fix bugs and retain regression tests that can reproduce the problem.
+8. Only one observable behavior is expanded in each round; new requirements, new boundaries and new abnormal paths enter the next round respectively.
+
+## Pure Refactoring Boundary
+
+Pure behavior-preserving refactoring does not manufacture a failing test. If existing behavior is already correct and the goal is structural only, establish or add characterization coverage that passes for the current behavior, then keep it green through each refactoring step. Use RED → GREEN → REFACTOR for new behavior or a behavior-changing defect fix; use GREEN → REFACTOR → GREEN for pure refactoring.
 
 ## Prove-It Pattern
 
-修复缺陷时先让测试失败，再让它通过。若无法先失败，说明测试没有覆盖原始问题，需要收窄输入、断言或测试层级。
+When fixing a defect, make the test fail first, then make it pass. If it cannot fail first, it means that the test does not cover the original problem, and the input, assertion or test level needs to be narrowed.
 
 ## Frontend Test Selection
 
 | Risk | Preferred Test |
 | ---- | -------------- |
-| utils、schema、状态计算 | 单元测试 |
-| hooks / composables | 单元或轻量集成测试 |
-| 组件 props、emits、交互、状态 | 组件测试 |
-| Router、Provider、Store 协作 | 轻量集成测试 |
-| 登录、支付、权限、关键 CRUD | E2E 测试 |
+| utils, schema, status calculation | unit testing |
+| hooks / composables | unit or lightweight integration testing |
+| Component props, emits, interactions, status | Component testing |
+| Router, Provider, Store collaboration | Lightweight integration testing |
+| Login, payment, permissions, key CRUD | E2E testing |
 
 ## Constraints
 
-- 不为了 TDD 引入项目没有使用且收益不清晰的新测试框架。
-- 不测试实现细节、私有状态或脆弱 DOM 结构。
-- 不把 E2E 当作所有风险的默认答案；优先选择离风险最近的测试层。
-- 如果现有仓库没有测试基础设施，先输出最小测试落地建议，再请求用户确认是否引入。
-- 不在红灯阶段同时重构；先证明问题，再最小修复，再整理结构。
+- Do not introduce new testing frameworks for the sake of TDD that are not used by the project and whose benefits are not clear.
+- Does not test implementation details, private state, or fragile DOM structures.
+- Don’t treat E2E as the default answer for all risks; prioritize the test layer closest to the risk.
+- If the existing warehouse does not have testing infrastructure, output the minimum test implementation suggestions first, and then ask the user to confirm whether to introduce it.
+- Do not refactor at the same time during the red light stage; prove the problem first, then make minimal repairs, and then organize the structure.
 
 ## Expected Output
 
-- 至少一个先失败后通过的测试覆盖新增或修复行为。
-- 实现保持最小范围，重构只在测试通过后进行。
-- 总结运行过的测试命令、覆盖的行为和未覆盖风险。
+- At least one fail-then-pass test covering the new or fixed behavior.
+- Implementation is kept to a minimum scope and refactoring is done only after the tests pass.
+- Summarize the test commands run, behaviors covered, and risks not covered.

package/skills/fec-testing-strategy/SKILL.md

@@ -1,45 +1,45 @@
 ---
 name: fec-testing-strategy
-description: Use when planning or reviewing a frontend testing strategy, selecting the right test layer by risk, mapping coverage across static checks, unit tests, component tests, integration tests, E2E, Storybook/visual regression, a11y, security, performance, or CI gates. Do not use to write individual component/E2E tests or merely run existing validation commands; Chinese triggers include 测试策略, 测试分层, 测试计划, 覆盖矩阵.
+description: Use when planning or reviewing a frontend testing strategy, selecting the right test layer by risk, mapping coverage across static checks, unit tests, component tests, integration tests, E2E, Storybook/visual regression, a11y, security, performance, or CI gates. Do not use to write individual component/E2E tests or merely run existing validation commands; Chinese triggers include test strategy, test layering, test plan, coverage matrix.
 ---
 
-# 前端测试策略
+# Front-end testing strategy
 
 ## Purpose
 
-按“离代码多近 / 覆盖风险层级”选择测试方法，避免把所有风险都塞进组件测试或 E2E。
+Choose your testing approach by “closeness to code/level of risk coverage” to avoid cramming all risks into component tests or E2E.
 
 ## Procedure
 
-1. 识别改动类型：纯逻辑、UI 组件、跨模块流程、浏览器能力、视觉稳定性、专项质量风险或发布门禁。
-2. 建立测试层级矩阵，至少区分：
-   - 静态检查：TypeScript、ESLint、格式、依赖安全、构建。
-   - 单元测试：utils、hooks/composables、状态逻辑、schema、纯函数。
-   - 组件测试：props/emits、用户交互、loading/error/empty、mock 边界。
-   - 轻量集成测试：表单 + API mock + 路由/Store/Provider 上下文。
-   - E2E：真实浏览器、跨页面关键旅程、鉴权、支付、权限、CI artifacts。
-   - 视觉/交互文档：Storybook interaction、Chromatic、视觉回归基线。
-   - 专项质量：a11y、安全、性能、兼容性。
-3. 按风险分配覆盖：高频核心路径优先 E2E，复杂组件状态优先组件测试，纯逻辑优先单元测试，跨 provider 协作用轻量集成测试。
-4. 用测试金字塔控制维护成本：
-   - 越靠近纯逻辑，测试越多、越快、越稳定。
-   - E2E 只覆盖用户关键旅程和真实浏览器风险，不覆盖每个分支。
-   - 视觉、a11y、安全和性能属于专项质量层，不塞进普通组件测试。
-5. 检查是否已有命令、测试框架、目录约定和 CI 门禁；沿用项目现状，不为策略文档引入不必要工具。
-6. 规划失败证据：每个高风险项要说明失败时如何定位，例如断言、截图、trace、coverage、日志或报告。
-7. 设计测试数据与 mock 策略：共享 fixture 表达业务场景，测试数据 builder 只封装噪声字段，避免每个测试手写随机对象。
-8. 管理 flaky 风险：把时间、网络、动画、随机数、并发和外部服务标为不稳定来源，并指定隔离、重试和证据产物。
-9. 输出可执行的最小测试计划：每层覆盖什么、不覆盖什么、优先级、建议命令和责任 skill。
+1. Identify the type of change: pure logic, UI components, cross-module processes, browser capabilities, visual stability, dedicated quality risks, or release gates.
+2. Establish a test level matrix, at least distinguish:
+   - Static checking: TypeScript, ESLint, format, dependency security, build.
+   - Unit testing: utils, hooks/composables, state logic, schema, pure functions.
+   - Component testing: props/emits, user interaction, loading/error/empty, mock boundaries.
+   - Lightweight integration testing: form + API mock + routing/Store/Provider context.
+   - E2E: real browser, cross-page key journeys, authentication, payments, permissions, CI artifacts.
+   - Visual/interactive documentation: Storybook interaction, Chromatic, visual regression baseline.
+   - Special quality: a11y, security, performance, compatibility.
+3. Allocate coverage by risk: high-frequency core paths prioritize E2E, complex component status prioritizes component testing, pure logic prioritizes unit testing, and lightweight integration testing is used for cross-provider collaboration.
+4. Use the testing pyramid to control maintenance costs:
+   - The closer to pure logic, the more tests, the faster, and the more stable it is.
+   - E2E only covers key user journeys and real browser risks, not every branch.
+   - Vision, a11y, safety and performance belong to dedicated quality layers and are not included in ordinary component tests.
+5. Check whether commands, test frameworks, directory conventions, and CI gates already exist; use the current status of the project and do not introduce unnecessary tools to the policy document.
+6. Plan failure evidence: Each high-risk item should describe how to locate it when it fails, such as assertions, screenshots, traces, coverage, logs, or reports.
+7. Design test data and mock strategies: share fixtures to express business scenarios, and the test data builder only encapsulates noise fields to avoid handwriting random objects for each test.
+8. Manage flaky risks: Mark time, network, animation, nonce, concurrency, and external services as sources of instability, and specify isolation, retries, and evidence artifacts.
+9. Output the minimum executable test plan: what is covered by each layer, what is not covered, priority, recommended commands and responsibility skills.
 
 ## Constraints
 
-- 不把测试策略写成泛泛的“多写测试”；每个建议必须对应具体风险。
-- 不要求所有项目都补齐完整测试金字塔；按业务风险和团队维护能力裁剪。
-- 不把 E2E 当作单元/组件测试的替代品；不把组件测试当作真实浏览器兼容保证。
-- 不为小改动强制引入新框架；优先复用仓库已有工具和脚本。
-- 不追求没有风险说明的覆盖率数字；覆盖率只能辅助判断，不能替代场景覆盖。
-- 不把随机 fixture、共享全局状态或依赖执行顺序的测试纳入主干门禁。
+- Don't write the test strategy as a general "write more tests"; each suggestion must correspond to a specific risk.
+- All projects are not required to complete the complete testing pyramid; they are tailored according to business risks and team maintenance capabilities.
+- Do not consider E2E as a replacement for unit/component testing; do not consider component testing as a guarantee of true browser compatibility.
+- Do not force the introduction of new frameworks for small changes; give priority to reusing existing tools and scripts in the warehouse.
+- Do not pursue coverage figures without risk explanation; coverage can only assist judgment and cannot replace scene coverage.
+- Do not include random fixtures, shared global state, or tests that depend on execution order into trunk gates.
 
 ## Expected Output
 
-输出测试分层建议、风险到测试层的映射、优先级、建议命令、需新增或调整的测试文件范围，以及明确分流到哪些专项 skill 或 agent。
+Output test layering recommendations, mapping of risks to test layers, priorities, recommended commands, the scope of test files that need to be added or adjusted, and the specific skills or agents that need to be clearly diverted.

package/skills/fec-typescript-project-standard/SKILL.md

@@ -1,54 +1,54 @@
 ---
 name: fec-typescript-project-standard
-description: Use when creating, configuring, reviewing, or debugging TypeScript project standards across frontend apps, libraries, SDKs, CLIs, monorepo packages, tsconfig, strictness, module/moduleResolution, path aliases, project references, declaration files, package exports, public API types, DTOs, advanced generics, discriminated unions, type guards, type narrowing, or type-level regressions. Prefer framework project skills for React/Vue/Next/Nuxt component architecture; Chinese triggers include TypeScript 项目规范, TS 项目规范, TypeScript 类型安全, 类型建模, 泛型, 判别联合, 类型收窄, tsconfig, 声明文件.
+description: Use when creating, configuring, reviewing, or debugging TypeScript project standards across frontend apps, libraries, SDKs, CLIs, monorepo packages, tsconfig, strictness, module/moduleResolution, path aliases, project references, declaration files, package exports, public API types, DTOs, advanced generics, discriminated unions, type guards, type narrowing, or type-level regressions. Prefer framework project skills for React/Vue/Next/Nuxt component architecture; Chinese triggers include TypeScript project specification, TS project specification, TypeScript type safety, type modeling, generics, discriminative unions, type narrowing, tsconfig, declaration files.
 ---
 
-# TypeScript 项目规范
+# TypeScript project specifications
 
 ## Purpose
 
-统一 TypeScript 层的工程配置、类型边界和发布产物规则。适用于前端应用、组件库、SDK、CLI、monorepo package 和纯 TypeScript 工具库，但不接管 React、Vue、Next.js、Nuxt 或 Vite 的框架架构职责。
+Unify project configuration, type boundaries, and release product rules for the TypeScript layer. Works with front-end applications, component libraries, SDKs, CLIs, monorepo packages, and pure TypeScript tool libraries, but does not take over the framework architecture responsibilities of React, Vue, Next.js, Nuxt, or Vite.
 
 ## Procedure
 
-1. 识别 TypeScript 上下文
-   - 应用项目：优先检查 `tsconfig` 分层、strictness、路径别名、类型检查脚本和框架生成类型。
-   - 组件库或 SDK：优先检查 public API、声明文件、package exports、peer dependencies 类型边界和发布前 pack 校验。
-   - CLI 或 Node 工具：优先检查 Node 目标版本、ESM/CJS 策略、`moduleResolution`、shebang 产物和 `process.env` 类型边界。
-   - Monorepo package：优先检查 project references、composite build、包间导入边界和 workspace 路径别名是否泄漏到发布产物。
-   - React、Vue、Next.js、Nuxt 等框架的组件架构、路由组织和状态管理归对应框架 skill；本流程只处理跨框架 TypeScript 契约和工程边界。
-
-2. 收敛 `tsconfig`
-   - 默认开启 `strict`，不要为通过构建关闭 `noImplicitAny`、`strictNullChecks` 或 `exactOptionalPropertyTypes` 等关键约束。
-   - 按运行环境选择 `target`、`lib`、`module` 和 `moduleResolution`；浏览器应用、Node 脚本、库包不要共用一份含混配置。
-   - 将基础配置、应用配置、测试配置和构建声明配置拆开，避免测试全局类型污染生产代码。
-   - 路径别名必须同时被 TypeScript、bundler、test runner 和发布产物理解；库包不得发布无法解析的源码别名。
-
-3. 设计类型边界
-   - 外部输入、DTO、领域模型、UI view model、组件 props 和工具函数 API 分层命名。
-   - public API 的参数和返回值显式标注，内部局部变量优先依赖推断。
-   - 外部数据先以 `unknown` 接收，再通过 schema 或 type guard 收窄。
-   - 复杂泛型、判别联合、DTO 映射、类型守卫和类型测试加载 [类型安全参考](references/type-safety.md)；需要高级模式时加载 [类型安全模式](references/type-safety-patterns.md)。
-
-4. 固定发布与声明产物
-   - 库包必须确认 `package.json` 的 `exports`、`types`、`files` 和实际构建产物一致。
-   - 不默认双包发布；只有明确消费方需要时才同时产出 ESM/CJS，并验证类型入口不分叉。
-   - 通过 `tsc --emitDeclarationOnly`、构建工具声明插件或 API extractor 产出 `.d.ts`，并在发布前检查声明文件可被消费方解析。
-   - 不把测试、fixture、内部工具、未稳定类型或私有路径暴露到 package exports。
-
-5. 验证 TypeScript 质量
-   - 优先使用仓库已有脚本，如 `typecheck`、`build`、`test`、`lint` 和 package pack dry-run。
-   - Vite、Next、Nuxt 等构建不等于完整类型检查；CI 必须有独立 typecheck 或等效验证。
-   - 类型改动影响 public API 时补类型测试、编译期断言或消费方 fixture。
+1. Identify TypeScript context
+   - Application projects: Prioritize checking of `tsconfig` layering, strictness, path aliases, type checking scripts and framework generation types.
+   - Component library or SDK: Prioritize checking public API, declaration files, package exports, peer dependencies type boundaries and pre-release pack verification.
+   - CLI or Node tools: Prioritize checking Node target versions, ESM/CJS policies, `moduleResolution`, shebang artifacts, and `process.env` type boundaries.
+   - Monorepo package: Prioritize checking whether project references, composite builds, inter-package import boundaries, and workspace path aliases leak into release products.
+   - The component architecture, routing organization, and state management of frameworks such as React, Vue, Next.js, and Nuxt belong to the corresponding framework skills; this process only deals with cross-framework TypeScript contracts and project boundaries.
+
+2. Convergence `tsconfig`
+   - Turn on `strict` by default, do not turn off key constraints such as `noImplicitAny`, `strictNullChecks` or `exactOptionalPropertyTypes` for pass builds.
+   - Select `target`, `lib`, `module` and `moduleResolution` according to the running environment; browser applications, Node scripts, and library packages should not share an ambiguous configuration.
+   - Separate basic configuration, application configuration, test configuration and build declaration configuration to avoid testing global types from polluting production code.
+   - Path aliases must be understood by TypeScript, bundler, test runner, and published products at the same time; library packages must not publish source code aliases that cannot be resolved.
+
+3. Design type boundaries
+   - Hierarchical naming of external input, DTO, domain model, UI view model, component props and tool function API.
+   - The parameters and return values of the public API are explicitly marked, and internal local variables are inferred first.
+   - External data is received as `unknown` first, and then narrowed by schema or type guard.
+   - Complex generics, discriminative unions, DTO mappings, type guards and type tests are loaded [Type Safety Reference](references/type-safety.md); [Type Safety Patterns](references/type-safety-patterns.md) is loaded when advanced patterns are required.
+
+4. Fixed release and announcement of products
+   - The library package must confirm that the `exports`, `types`, and `files` of `package.json` are consistent with the actual build product.
+   - Do not default to dual-package publishing; only produce ESM/CJS at the same time when the consumer clearly needs it, and verify that the type entry does not fork.
+   - Produce `.d.ts` through `tsc --emitDeclarationOnly`, build tool declaration plug-in or API extractor, and check that the declaration file can be parsed by the consumer before publishing.
+   - Do not expose tests, fixtures, internal tools, unstable types, or private paths to package exports.
+
+5. Verify TypeScript quality
+   - Prioritize the use of existing scripts in the repository, such as `typecheck`, `build`, `test`, `lint` and package pack dry-run.
+   - Vite, Next, Nuxt, etc. builds do not equal full type checking; CI must have standalone typecheck or equivalent verification.
+   - Type changes affect public API time-filling type tests, compile-time assertions, or consumer fixtures.
 
 ## Constraints
 
-- 不用 `skipLibCheck`、`any`、无守卫非空断言或宽泛 `as` 掩盖真实边界问题。
-- 不在应用代码中依赖发布包私有深层路径。
-- 不把框架目录结构、组件分层、路由组织或状态管理决策放进本流程；这些交给对应框架或专项流程。
-- 不让生成类型、测试类型或 Node-only 类型污染浏览器运行代码。
-- 不发布只能在源码仓库内解析的路径别名、ambient 声明或隐式全局类型。
+- Don't use `skipLibCheck`, `any`, unguarded non-null assertions or the wide `as` to mask real boundary issues.
+- Do not rely on release package private deep paths in application code.
+- Do not put framework directory structure, component layering, routing organization or state management decisions into this process; these are left to the corresponding framework or dedicated process.
+- Don't pollute browser running code with generated, test, or Node-only types.
+- Do not publish path aliases, ambient declarations, or implicit global types that can only be resolved within the source code repository.
 
 ## Expected Output
 
-输出应包含 TypeScript 上下文判断、关键 `tsconfig`/package 类型入口建议、类型边界方案、声明文件或 public API 风险、验证命令。完成后项目应能独立 typecheck，公开类型可被消费方解析，类型安全问题有明确收窄或建模方案。
+The output should include TypeScript context determinations, key `tsconfig`/package type entry suggestions, type boundary schemes, declaration file or public API risks, and verification commands. After completion, the project should be able to independently typecheck, public types can be parsed by consumers, and type safety issues should have clear narrowing or modeling solutions.

package/skills/fec-typescript-project-standard/references/type-safety-patterns.md

@@ -1,15 +1,15 @@
-# 类型安全模式
+# Type safety mode
 
-## 类型边界审查清单
+## Type Boundary Review Checklist
 
-- DTO 应与外部载荷对应，并在 API 边界处进行转换。
-- 领域模型或视图模型使用前端命名和稳定的联合类型。
-- 组件 props 需命名明确，仅在该文件外复用时才导出。
-- 公开函数必须有显式的参数和返回值类型。
-- 外部输入必须从 `unknown` 开始，通过 schema 校验或类型守卫逐步收窄。
-- 配置映射表优先使用 `as const` 和 `satisfies`，避免宽泛断言。
+- DTOs should correspond to external loads and be converted at API boundaries.
+- Domain model or view model uses front-end naming and stable union types.
+- Component props need to be named clearly and exported only when reused outside this file.
+- Public functions must have explicit parameter and return value types.
+- External input must start from `unknown` and be gradually narrowed through schema verification or type guarding.
+- Configure mapping tables using `as const` and `satisfies` first to avoid broad assertions.
 
-## 使用 `satisfies` 的配置映射表
+## Use the configuration mapping table of `satisfies`
 
 ```ts
 type Tone = "neutral" | "success" | "warning" | "danger";
@@ -23,9 +23,9 @@ const STATUS_TONE = {
 type InvoiceStatus = keyof typeof STATUS_TONE;
 ```
 
-这样既保留了字面量值，又验证了映射表符合预期的值域。
+This not only preserves the literal value, but also verifies that the mapping table conforms to the expected value range.
 
-## 映射类型用于表单错误
+## Mapping type used for form errors
 
 ```ts
 type FieldErrors<TValues extends Record<string, unknown>> = {
@@ -40,7 +40,7 @@ interface ProfileFormValues {
 type ProfileFormErrors = FieldErrors<ProfileFormValues>;
 ```
 
-## 模板字面量类型用于事件命名
+## Template literal type is used for event naming
 
 ```ts
 interface AnalyticsPayloads {
@@ -52,9 +52,9 @@ type AnalyticsEventName = keyof AnalyticsPayloads;
 type AnalyticsHandlerName = `on${Capitalize<string & AnalyticsEventName>}`;
 ```
 
-当项目中已有事件命名规范时使用此模式。不要为一次性字符串引入。
+Use this pattern when there is already an event naming convention in the project. Don't introduce it for one-time strings.
 
-## 更安全的泛型组件模式
+## Safer generic component pattern
 
 ```tsx
 interface Entity {
@@ -92,11 +92,11 @@ export function EntityPicker<TEntity extends Entity>({
 }
 ```
 
-## 类型审查反馈
+## Type Review Feedback
 
-报告类型安全问题时，需包含：
+When reporting a type safety issue, include:
 
-- 过于宽泛、过于狭窄或不合理的类型边界。
-- 尽管通过 TypeScript 但可能在运行时失败的行为。
-- 最小替换类型或守卫方案。
-- 该变更是否需要测试或类型测试。
+- Type boundaries that are too broad, too narrow, or unreasonable.
+- Behavior that may fail at runtime despite passing TypeScript.
+- Minimal replacement type or guard scheme.
+- Whether the change requires testing or type testing.

package/skills/fec-typescript-project-standard/references/type-safety.md

@@ -1,14 +1,14 @@
-# TypeScript 类型安全
+#TypeScript type safety
 
 ## Purpose
 
-为前端和 TypeScript 工程建立可演进的类型契约，减少 `any`、断言和运行时形状漂移。
+Establish evolvable type contracts for front-end and TypeScript projects, reducing `any`, assertions, and runtime shape drift.
 
 ## Procedure
 
-### 1. 先确定类型边界
+### 1. First determine the type boundary
 
-把类型分为外部输入、领域模型、UI view model、组件 props、工具函数 API。不要让后端 DTO、表单模型和 UI 展示模型互相冒充。
+Divide types into external input, domain model, UI view model, component props, and tool function API. Don't let backend DTOs, form models, and UI presentation models pretend to be each other.
 
 ```ts
 interface UserDto {
@@ -32,9 +32,9 @@ export function mapUserDto(dto: UserDto): UserViewModel {
 }
 ```
 
-### 2. 用 `unknown` 和收窄处理不可信数据
+### 2. Use `unknown` and narrowing to handle untrusted data
 
-外部输入先校验再使用。不要用 `as` 让编译器闭嘴。
+External input must be verified before use. Don't use `as` to shut up the compiler.
 
 ```ts
 interface ApiErrorBody {
@@ -55,9 +55,9 @@ export function getApiErrorMessage(value: unknown): string {
 }
 ```
 
-### 3. 用判别联合表达状态机
+### 3. Express state machine using discriminant union
 
-异步状态、权限分支、支付状态等有限状态，用判别字段让新增分支在编译期暴露。
+Limited states such as asynchronous status, permission branches, payment status, etc. use discriminant fields to expose new branches during compilation.
 
 ```ts
 type Loadable<T> =
@@ -86,9 +86,9 @@ export function renderUserState(user: Loadable<{ name: string }>): string {
 }
 ```
 
-### 4. 让泛型服务调用方，而不是炫技
+### 4. Let generics serve callers, not show off their skills
 
-泛型应减少重复并保持调用方推断清晰。复杂类型超过阅读成本时，优先拆具名类型。
+Generics should reduce duplication and keep caller inference clear. When the complex type exceeds the reading cost, the named type will be demolished first.
 
 ```ts
 interface SelectOption<TValue extends string | number> {
@@ -119,9 +119,9 @@ export function Select<TValue extends string | number>({
 }
 ```
 
-### 5. 用类型测试保护公共类型
+### 5. Protect public types with type testing
 
-公共工具类型、组件库类型和 SDK 类型，应有轻量类型测试或编译期断言。
+Public tool types, component library types, and SDK types should have lightweight type tests or compile-time assertions.
 
 ```ts
 type Equal<TLeft, TRight> =
@@ -137,12 +137,12 @@ type _UserStatusTest = Expect<Equal<UserStatus, "active" | "disabled">>;
 
 ## Constraints
 
-- 避免 `any`、无守卫的非空断言和不相关类型之间的强制 `as`。
-- 不把大型匿名类型堆在函数参数或 JSX props 上；提取具名类型表达业务含义。
-- 不为简单业务过度设计递归条件类型；类型复杂度应服务可维护性。
-- 公共 API 的输入输出必须显式标注，局部变量可依赖推断。
-- 类型建模不能替代运行时校验；外部数据仍需 schema 或 type guard。
+- Avoid `any`, unguarded non-null assertions and coercion `as` between unrelated types.
+- Don’t pile large anonymous types on function parameters or JSX props; extract named types to express business meaning.
+- Do not over-design recursive conditional types for simple business; type complexity should serve maintainability.
+- The input and output of the public API must be explicitly annotated, and local variables can be relied upon for inference.
+- Type modeling does not replace runtime validation; external data still requires schema or type guard.
 
 ## Expected Output
 
-产出清晰的类型边界、可收窄的数据模型、必要的类型测试和验证命令。评审时应列出类型风险、运行时影响、推荐建模方式和是否需要专项修复。
+Produce clear type boundaries, narrowable data models, and necessary type testing and verification commands. The review should list type risks, runtime impacts, recommended modeling methods, and whether special fixes are needed.