@bovinphang/frontend-craft 2.7.0 → 2.8.0

package/skills/fec-alchemy/references/methodology.md

@@ -1,94 +1,94 @@
-# 项目吸收方法论
+# Project absorption methodology
 
-## 目标
+## Target
 
-本文档用于扩展 `SKILL.md` 中的核心流程，适合更大型的“参考系统到目标项目”能力吸收任务。参考系统可以是代码库、产品、服务、框架、库、CLI、插件、文档体系或 AI/Agent 工具链。
+This document is used to extend the core process in `SKILL.md`, suitable for larger "reference system to target project" capability absorption tasks. A reference system can be a code base, product, service, framework, library, CLI, plug-in, documentation system, or AI/Agent toolchain.
 
-## 阶段 1：建立目标项目基线
+## Phase 1: Establish Target Project Baseline
 
-在深入研究参考项目之前，先为目标项目建立简短基线：
+Before diving into the reference project, establish a brief baseline for the target project:
 
-- 目标项目声明的用途是什么？
-- 当前已有的顶层能力有哪些？
-- 已存在的入口、扩展点和用户工作流有哪些？
-- 哪些区域仍在活跃维护？
-- 哪些区域脆弱、复杂或过度设计？
-- 已有哪些测试和验证命令？
+- What is the purpose of the target project statement?
+- What are the current top-level capabilities?
+- What entry points, extension points and user workflows already exist?
+- Which areas are still under active maintenance?
+- Which areas are fragile, complex or over-engineered?
+- What testing and verification commands are in place?
 
-在理解目标项目基线之前，不要过早形成改造建议。
+Don’t prematurely formulate renovation recommendations before understanding the target project baseline.
 
-## 阶段 2：扫描参考项目
+## Phase 2: Scan Reference Projects
 
-扫描参考系统中的高信号材料：
+Scan high-signal materials in reference systems:
 
-- README 和文档：项目定位、使用模型、安装、配置。
-- 包或构建元数据：技术选型、依赖范围、脚本命令。
-- 源码布局：架构、模块边界、命名约定。
-- 能力域：产品能力、架构模式、领域模型、接口协议、数据流、运行时行为、开发体验、质量体系、交付流程、文档知识、生态扩展。
-- 项目形态探针：按参考系统类型选择相关目录和行为入口，不假设所有项目都有相同结构。
-- 测试：预期行为和边界场景。
-- 示例：面向用户的工作流和上手体验质量。
+- README and documentation: project location, usage model, installation, configuration.
+- Package or build metadata: technology selection, dependency scope, script commands.
+- Source code layout: architecture, module boundaries, naming conventions.
+- Capability domain: product capabilities, architectural patterns, domain models, interface protocols, data flow, runtime behavior, development experience, quality system, delivery process, document knowledge, and ecological expansion.
+- Project shape probe: select relevant directories and behavior entries according to the reference system type, without assuming that all projects have the same structure.
+- Testing: expected behavior and edge scenarios.
+- Example: User-facing workflow and quality of onboarding experience.
 
-记录观察时，应记录为“能力”，而不是“文件”。例如写“具备带环境检查的引导式配置向导”，而不是写“复制 setup.ts”。
+When recording observations, they should be recorded as “competencies,” not “documents.” For example, write "Has guided configuration wizard with environment checks" instead of "Copy setup.ts".
 
-### 项目形态探针
+### Project shape probe
 
-按目标和参考系统的实际形态选择扫描视角：
+Select the scan angle according to the actual shape of the target and reference system:
 
-- 前端项目：页面、组件、路由、状态、数据请求、表单、设计系统、可访问性、性能、构建。
-- 后端项目：API、服务边界、数据库、队列、缓存、认证授权、任务调度、可观测性、部署。
-- 工具或 CLI 项目：命令模型、配置、插件机制、错误输出、安装分发、模板。
-- AI/Agent 项目：skills、commands、hooks、rules、agents、MCP、prompt、workflow。
-- 库项目：公开 API、类型、兼容性、构建产物、示例、版本策略。
-- 文档或知识库项目：信息架构、导航、示例、搜索、版本化、贡献流程、发布节奏。
+- Front-end projects: pages, components, routing, state, data requests, forms, design systems, accessibility, performance, build.
+- Backend projects: API, service boundary, database, queue, cache, authentication and authorization, task scheduling, observability, deployment.
+- Tool or CLI project: command model, configuration, plugin mechanism, error output, installation distribution, templates.
+- AI/Agent projects: skills, commands, hooks, rules, agents, MCP, prompts, workflow.
+- Library project: public API, types, compatibility, build artifacts, examples, version policy.
+- Documentation or knowledge base project: information architecture, navigation, examples, search, versioning, contribution process, release cadence.
 
-如果项目横跨多种形态，优先选择与用户目标直接相关的 1 到 3 个视角，避免把吸收任务扩大成全仓库审计。
+If the project spans multiple modalities, prioritize 1 to 3 perspectives that are directly related to user goals to avoid expanding the absorption task into a full warehouse audit.
 
-## 阶段 3：候选能力评分
+## Phase 3: Candidate Ability Scoring
 
-对每个候选项按 1 到 5 分评分。
+Rate each candidate on a scale of 1 to 5.
 
-| 维度 | 问题 |
+| Dimensions | Questions |
 |---|---|
-| 用户价值 | 是否能实质改善目标用户的工作流？ |
-| 适配度 | 是否符合目标项目的架构和路线图？ |
-| 原创化可行性 | 是否可以在不复制受保护表达的情况下重新创建？ |
-| 复杂度 | 是否可以安全交付并长期维护？ |
-| 可验证性 | 正确性是否可以通过测试或评审验证？ |
+| User value | Can it substantially improve the workflow of target users? |
+| Fit | Is it consistent with the target project's architecture and roadmap? |
+| Feasibility of originalization | Is it possible to recreate a protected expression without copying it? |
+| Complexity | Can it be delivered safely and maintained over the long term? |
+| Verifiability | Can correctness be verified through testing or review? |
 
-优先处理高价值、高适配、低风险的候选项。
+Prioritize high-value, high-fit, low-risk candidates.
 
-## 阶段 4：吸收策略
+## Phase 4: Absorption Strategy
 
-为每个候选项选择一种策略：
+Choose a strategy for each candidate:
 
-- **增强**：改进目标项目已有能力。
-- **新增**：引入新的目标项目原生能力。
-- **拆分**：拆解过载的目标概念或参考概念。
-- **合并**：合并目标项目中重叠的概念。
-- **替换**：在更安全设计准备好后，移除较弱的目标实现。
-- **文档化**：只补充知识，不改代码。
-- **拒绝**：明确延后或放弃，并说明原因。
+- **Enhancement**: Improve the existing abilities of the target item.
+- **New**: Introducing new target project native capabilities.
+- **Split**: Split an overloaded target concept or reference concept.
+- **Merge**: Merge overlapping concepts in the target project.
+- **Replace**: Remove weaker goal implementations once a more secure design is ready.
+- **Documentation**: Only add knowledge, do not change the code.
+- **Rejection**: Defer or give up clearly and explain the reasons.
 
-## 阶段 5：实现顺序
+## Phase 5: Implementation Sequence
 
-推荐按以下顺序推进：
+It is recommended to proceed in the following order:
 
-1. 文档和边界澄清。
-2. 测试或验证脚手架。
-3. 最小化的目标项目原生实现。
-4. 与现有工作流集成。
-5. 清理重复逻辑和废弃路径。
-6. 面向用户的文档和示例。
+1. Documentation and boundary clarification.
+2. Test or validate scaffolding.
+3. Minimized target project native implementation.
+4. Integrate with existing workflows.
+5. Clean up duplicate logic and abandoned paths.
+6. User-oriented documentation and examples.
 
-## 阶段 6：评审问题
+## Stage 6: Review Questions
 
-最终完成前，回答以下问题：
+Before finalizing, answer the following questions:
 
-- 吸收后目标项目是否仍保持一致性？
-- 模块边界是否被保留或改善？
-- 每个新增能力是否可被发现？
-- 是否存在重叠的能力、入口、抽象、配置、运行时流程、工具函数、文档承诺或用户工作流？
-- 新增依赖是否有充分理由？
-- 验证命令是否已记录？
-- 是否透明说明了灵感来源，同时又没有暗示复制代码？
+- Will the target items remain consistent after assimilation?
+- Are module boundaries preserved or improved?
+- Is each new ability discoverable?
+- Are there overlapping capabilities, portals, abstractions, configurations, runtime processes, tool functions, document commitments, or user workflows?
+- Is there a good reason for adding new dependencies?
+- Verify that the command was logged?
+- Is the source of inspiration transparently stated without implying duplication of code?

package/skills/fec-alchemy/references/originality-and-licensing.md

@@ -1,57 +1,57 @@
-# 原创性与许可证约束
+# Originality and license restrictions
 
-## 目标
+## Target
 
-本流程用于合法、合规、伦理且可维护的适配。它应帮助使用者提炼思想，并重新创建符合目标项目风格的设计，而不是伪装复制。
+This process is used for legal, compliant, ethical, and maintainable adaptation. It should help users refine their ideas and recreate designs that fit the style of the target project, rather than pretending to be a copy.
 
-## 通常可以安全吸收的内容
+## Content that is generally safe to absorb
 
-- 高层思想和产品概念。
-- 通用架构模式。
-- 公开文档化的工作流。
-- 用自己的语言表达的行为需求。
-- 标准的、不可保护的或已获得适当许可的算法和技术。
-- 为目标环境重新创建的配置概念。
+- High-level thinking and product concepts.
+- Common architectural patterns.
+- Publicly documented workflow.
+- Behavioral needs expressed in own words.
+- Algorithms and technologies that are standard, unprotectable or properly licensed.
+- Configuration concepts recreated for the target environment.
 
-## 需要谨慎处理的内容
+## Content that needs to be handled with caution
 
-- 来自其他项目的大段代码。
-- 独特文本、提示词、示例、文档、图表、名称或品牌表达。
-- 与参考项目高度绑定且非显而易见的实现结构。
-- 包含许可证头或署名要求的生成文件。
-- 带有限制性许可证的依赖。
-- 私有或专有仓库。
+- Large chunks of code from other projects.
+- Unique text, prompts, examples, documents, graphics, names or brand expressions.
+- Highly tied and non-obvious implementation structure to the reference project.
+- Makefile containing license header or attribution requirements.
+- Dependencies with restrictive license.
+- Private or proprietary repositories.
 
-## 安全适配流程
+## Security adaptation process
 
-1. 用中性语言总结参考能力。
-2. 识别它解决的问题。
-3. 独立设计目标项目原生方案。
-4. 使用目标项目约定实现新代码。
-5. 将概念命名调整为目标项目语义。
-6. 基于期望行为添加测试，而不是基于参考项目内部实现添加测试。
-7. 当许可证要求署名时，保留必要署名。
-8. 将许可证不确定性记录为风险，而不是忽略。
+1. Summarize reference capabilities in neutral language.
+2. Identify the problem it solves.
+3. Independently design the original solution for the target project.
+4. Implement new code using target project conventions.
+5. Adjust concept naming to target project semantics.
+6. Add tests based on desired behavior rather than on the internal implementation of the reference project.
+7. When a license requires a signature, retain the necessary signature.
+8. Document license uncertainty as a risk rather than ignoring it.
 
-## 风险信号
+## Risk Signal
 
-- 输出在没有目标项目特定理由的情况下保留了参考项目相同的文件结构和命名。
-- 输出包含大量完全相同或近似相同的代码/文本。
-- Agent 无法解释目标设计为什么不同于参考设计。
-- 新模块与目标项目现有模块高度重叠。
-- 唯一理由只是“参考项目就是这样做的”。
+- The output retains the same file structure and naming of the reference project without target project specific justification.
+- The output contains a lot of identical or nearly identical code/text.
+- The Agent cannot explain why the target design differs from the reference design.
+- The new module has a high degree of overlap with the existing modules of the target project.
+- The only reason is just "that's what the reference project does".
 
-## 报告中的推荐表述
+## Recommended statements in reports
 
-建议使用：
+Recommended to use:
 
-- “受参考项目在……方面的处理方式启发。”
-- “已重新实现为符合目标项目风格的模块，用于……”
-- “参考项目通过 X 解决该问题；本项目选择 Y，因为……”
+- "Inspired by the way reference projects are treated in..."
+- "Reimplemented as a module that matches the style of the target project, for..."
+- "The reference project solved this problem with X; this project chose Y because..."
 
-避免使用：
+Avoid using:
 
-- “复制自……”
-- “和……完全一样”
-- “隐藏式模仿……”
-- “让它看起来不相关……”
+- "Copied from..."
+- "Exactly the same as..."
+- "Hidden imitation..."
+- "Make it seem irrelevant..."

package/skills/fec-api-integration/SKILL.md

@@ -1,78 +1,78 @@
 ---
 name: fec-api-integration
-description: Use when designing, implementing, or reviewing frontend-to-backend API integration, typed API clients, REST/tRPC/OpenAPI client choices, auth refresh, API error mapping, upload flows, SSE/WebSocket/polling choices, CORS-facing frontend behavior, or cross-boundary loading/error states. Do not use for backend-only service architecture or TanStack Query cache policy alone; Chinese triggers include API 集成, 前后端联调, typed API client, 接口错误处理, SSE, WebSocket.
+description: Use when designing, implementing, or reviewing frontend-to-backend API integration, typed API clients, REST/tRPC/OpenAPI client choices, auth refresh, API error mapping, upload flows, SSE/WebSocket/polling choices, CORS-facing frontend behavior, or cross-boundary loading/error states. Do not use for backend-only service architecture or TanStack Query cache policy alone; Chinese triggers include API integration, front-end and back-end joint debugging, typed API client, Interface error handling, SSE, WebSocket.
 ---
 
-# API 集成
+# API integration
 
-适用于前端与后端边界的类型、错误、鉴权、上传、实时通信和用户状态设计。需要具体代码模式时加载 [integration-patterns.md](references/integration-patterns.md)。
+Suitable for front-end and back-end boundary types, errors, authentication, uploads, real-time communication and user status design. Load [integration-patterns.md](references/integration-patterns.md) when specific code patterns are required.
 
 ## Purpose
 
-规范前端 API 集成边界，让请求、错误、鉴权和实时数据可维护。
+Standardize front-end API integration boundaries to make requests, errors, authentication, and real-time data maintainable.
 
 ## Procedure
 
-1. 明确接口所有权
-   - 同团队 TypeScript 全栈可考虑 tRPC 或共享 schema。
-   - 多语言或多消费者 API 优先 OpenAPI/GraphQL codegen。
-   - 小型内部应用可用 typed fetch wrapper，但类型必须集中维护。
-   - 不在组件里散落 `fetch`、URL、header、错误解析和 token 逻辑。
-   - 公共接口需要明确版本、兼容窗口、废弃字段策略和调用方范围。
-
-2. 建立客户端边界
-   - 用一个 API client 处理 base URL、credentials、JSON 解析、超时、取消和统一错误。
-   - 环境变量只读取公开前缀，私密 token 不进入客户端 bundle。
-   - 组件只消费 domain 函数或 query/mutation hook，不直接拼接接口路径。
-   - 204、空响应、非 JSON 错误和网络断开要有明确行为。
-   - TypeScript contract 必须覆盖请求、响应、错误形状和分页/游标元数据。
-
-3. 映射用户可理解的错误
-   - 401：刷新失败后引导登录。
-   - 403：说明权限不足，不重复重试。
-   - 404：展示缺失状态或返回上级入口。
-   - 409：提示冲突和下一步操作。
-   - 422：映射字段级错误。
-   - 429/5xx/网络错误：允许退避重试或展示稍后再试。
-   - 未识别错误要落到统一 fallback，不把原始后端异常暴露给用户。
-   - 所有错误都应归一到用户可恢复动作：重试、重新登录、修改输入、返回上级、联系支持或稍后再试。
-   - 错误对象要保留面向日志的 trace id / request id，但 UI 不暴露内部堆栈、SQL、服务名或敏感字段。
-
-4. 管理接口演进
-   - 兼容新增字段；删除或改名字段必须走迁移期、适配层或双写/双读策略。
-   - 用 schema、类型生成物或 contract test 捕捉破坏性变更。
-   - 对前后端协作项记录状态码、错误码、幂等性、重试语义和时区/金额/枚举规则。
-
-5. 处理鉴权刷新
-   - Access token 生命周期短，refresh 优先放在 httpOnly cookie 或服务端会话。
-   - 401 后只允许单次刷新队列，避免多个请求同时刷新。
-   - 刷新失败要清理本地身份状态并跳转登录。
-   - 不把 bearer token 放在 URL、localStorage 或日志里。
-
-6. 选择上传与实时方案
-   - 小文件可用 multipart；大文件优先预签名直传或分片上传。
-   - 只需要服务端推送时用 SSE；双向协作、聊天或多人状态用 WebSocket。
-   - 简单状态刷新、低频任务进度可用 polling，并设置停止条件。
-   - 上传和实时连接都需要取消、重连、超时和错误 UI。
-
-7. 验证集成质量
-   - 检查 loading、empty、error、unauthorized、offline、retrying 状态。
-   - 用浏览器网络面板确认 base URL、credentials、CORS 和状态码行为。
-   - 用 mock 或测试服务覆盖 401、403、422、500、断网和取消请求。
-   - 确认客户端 bundle 不包含私密环境变量、服务端密钥或内部地址。
-   - 对关键 API client 行为补最小测试，证明超时、取消、错误映射和刷新队列可预期。
-   - 验证错误边界与请求层协作：渲染异常进 Error Boundary，请求失败进可恢复 UI，不互相吞掉。
+1. Clarify interface ownership
+   - For TypeScript full stack in the same team, tRPC or shared schema can be considered.
+   - Multi-language or multi-consumer API preferred OpenAPI/GraphQL codegen.
+   - Typed fetch wrapper can be used for small internal applications, but types must be maintained centrally.
+   - Do not scatter `fetch`, URL, header, error parsing and token logic in components.
+   - Public interfaces need to specify versions, compatibility windows, obsolete field policies, and caller scope.
+
+2. Establish client boundaries
+   - Handle base URL, credentials, JSON parsing, timeouts, cancellation and unified errors with an API client.
+   - The environment variable only reads the public prefix, and the private token does not enter the client bundle.
+   - The component only consumes domain functions or query/mutation hooks, and does not directly splice interface paths.
+   - 204, empty response, non-JSON error and network disconnection must have clear behavior.
+   - TypeScript contracts must cover request, response, error shapes, and pagination/cursor metadata.
+
+3. Map user-understandable errors
+   - 401: Boot login after failed refresh.
+   - 403: Indicates insufficient permissions, do not retry.
+   - 404: Display missing status or return to the upper level entrance.
+   - 409: Prompt for conflict and next step.
+   - 422: Mapping field level error.
+   - 429/5xx/Network Error: Allow backoff to retry or show try again later.
+   - Unrecognized errors should fall into a unified fallback, and the original backend exception should not be exposed to the user.
+   - All errors should be attributed to user-recoverable actions: retry, log in again, modify input, return to the previous level, contact support, or try again later.
+   - The error object should retain the log-oriented trace id / request id, but the UI should not expose the internal stack, SQL, service name or sensitive fields.
+
+4. Management interface evolution
+   - Compatible with new fields; deleting or renaming fields must go through the migration period, adaptation layer or double-write/double-read strategy.
+   - Capture breaking changes using schema, type generators or contract tests.
+   - Record status codes, error codes, idempotence, retry semantics and time zone/amount/enumeration rules for front-end and back-end collaboration items.
+
+5. Handle authentication refresh
+   - Access token has a short life cycle, and refresh is prioritized in httpOnly cookies or server sessions.
+   - Only a single refresh of the queue is allowed after 401 to avoid multiple requests being refreshed at the same time.
+   - If the refresh fails, you need to clear the local identity status and jump to login.
+   - Do not put bearer token in URL, localStorage or logs.
+
+6. Select the upload and real-time plan
+   - Multipart is available for small files; large files are given priority for pre-signed direct upload or multipart upload.
+   - Only use SSE for server push; use WebSocket for two-way collaboration, chat or multi-person status.
+   - Simple status refresh, low-frequency task progress can be polled, and stop conditions can be set.
+   - Both uploads and live connections require cancellation, reconnection, timeout and error UI.
+
+7. Verify integration quality
+   - Check loading, empty, error, unauthorized, offline, retrying status.
+   - Confirm base URL, credentials, CORS, and status code behavior using the browser network panel.
+   - Use mock or test services to cover 401, 403, 422, 500, disconnection and cancellation requests.
+   - Verify that the client bundle does not contain private environment variables, server keys, or internal addresses.
+   - Add minimal testing for key API client behaviors to demonstrate that timeouts, cancellations, error mappings, and flush queues are expected.
+   - Verification error boundary cooperates with the request layer: rendering exceptions go to the Error Boundary, and request failures go to the recoverable UI, without swallowing each other.
 
 ## Constraints
 
-- 不在页面组件中直接管理 token refresh、错误格式解析或重试策略。
-- 不对 4xx 业务错误做盲目自动重试。
-- 不把后端异常栈、内部错误码或原始 SQL/服务名暴露给用户。
-- 不用 localStorage 存储高价值 token；若遗留系统无法避免，必须联动安全审查。
-- 不用 WebSocket 替代简单轮询，也不用轮询实现高频双向协作。
-- 不让上传经过 API 服务器转发大文件，除非有明确合规或扫描需求。
-- 不在公共接口里直接暴露临时字段、数据库字段名或后端内部错误结构。
+- Do not manage token refresh, error format parsing, or retry strategies directly in page components.
+- No blind automatic retries for 4xx business errors.
+- Do not expose backend exception stacks, internal error codes or raw SQL/service names to users.
+- Do not use localStorage to store high-value tokens; if legacy systems cannot be avoided, security review must be linked.
+- No need to use WebSocket to replace simple polling, and no need to use polling to achieve high-frequency two-way collaboration.
+- Do not allow uploads to be forwarded through the API server for large files unless there is an explicit compliance or scanning need.
+- Do not directly expose temporary fields, database field names or backend internal error structures in the public interface.
 
 ## Expected Output
 
-输出应包含 API client 边界、接口类型来源、错误映射、鉴权刷新策略、上传/实时方案和验证结果。完成后组件不散落请求细节，用户状态完整，失败场景可恢复，客户端不会泄露服务端密钥。
+The output should include API client boundaries, interface type sources, error mappings, authentication refresh policies, upload/real-time schemes, and validation results. After completion, the component will not scatter request details, the user status will be intact, failure scenarios can be recovered, and the client will not leak the server key.

package/skills/fec-api-integration/references/integration-patterns.md

@@ -1,6 +1,6 @@
-# API 集成实现模式
+# API integration implementation mode
 
-## 类型化 Fetch 客户端
+## Typed Fetch client
 
 ```ts
 export class ApiError extends Error {
@@ -8,7 +8,7 @@ export class ApiError extends Error {
     public readonly status: number,
     public readonly body: unknown,
   ) {
-    super(`API 请求失败，状态码 ${status}`);
+    super(`API request failed, status code ${status}`);
   }
 }
 
@@ -36,45 +36,45 @@ export async function requestJson<T>(
 }
 ```
 
-## 用户端错误映射
+## User side error mapping
 
 ```ts
 export function getApiMessage(error: unknown): string {
-  if (!(error instanceof ApiError)) return "操作失败，请稍后重试。";
+  if (!(error instanceof ApiError)) return "The operation failed, please try again later.";
 
-  if (error.status === 401) return "请重新登录。";
-  if (error.status === 403) return "您没有权限执行此操作。";
-  if (error.status === 404) return "请求的资源已不存在。";
-  if (error.status === 409) return "此变更与最新数据冲突。";
-  if (error.status === 422) return "请检查标红字段。";
-  if (error.status === 429) return "请求过于频繁，请稍后再试。";
+  if (error.status === 401) return "Please log in again.";
+  if (error.status === 403) return "You do not have permission to perform this operation.";
+  if (error.status === 404) return "The requested resource no longer exists.";
+  if (error.status === 409) return "This change conflicts with the latest data.";
+  if (error.status === 422) return "Please check the red fields.";
+  if (error.status === 429) return "The request is too frequent, please try again later.";
 
-  return "服务暂不可用，请稍后重试。";
+  return "The service is temporarily unavailable, please try again later.";
 }
 ```
 
-## 上传选型
+## Upload selection
 
-| 需求             | 推荐方案                      |
+| Requirements | Recommended solutions |
 | ---------------- | ----------------------------- |
-| 小头像或 CSV     | Multipart 请求                |
-| 大视频或归档文件 | 预签名直传                    |
-| 弱网环境大文件   | 分片断点续传                  |
-| 入库前合规扫描   | 经 API 中介上传（含大小限制） |
+| Avatar or CSV | Multipart request |
+| Large video or archive file | Pre-signed direct transfer |
+| Large files in weak network environment | Fragmented breakpoint resume download |
+| Compliance scanning before warehousing | Uploading through API intermediary (including size limit) |
 
-## 实时通信选型
+## Real-time communication selection
 
-| 需求                 | 推荐方案                  |
+| Requirements | Recommended solutions |
 | -------------------- | ------------------------- |
-| 任务进度或通知       | SSE（Server-Sent Events） |
-| 聊天、在线状态、协作 | WebSocket                 |
-| 数秒一次的状态轮询   | 定时轮询（Polling）       |
-| 服务端 AI Token 流   | SSE 或 fetch 流式响应     |
+| Task progress or notification | SSE (Server-Sent Events) |
+| Chat, Presence, Collaboration | WebSocket |
+| Status polling every few seconds | Scheduled polling (Polling) |
+| Server-side AI Token stream | SSE or fetch streaming response |
 
-## 审查清单
+## Review Checklist
 
-- API 地址和凭证集中管理。
-- 客户端需处理 204、非 JSON 错误、取消和离线状态。
-- Token 刷新机制不能引发请求风暴。
-- 组件应消费 hooks/领域函数，而非直接调用原始 fetch。
-- 上传和实时流需暴露进度、取消、失败和重试状态。
+- Centralized management of API addresses and credentials.
+- The client needs to handle 204, non-JSON errors, cancellation and offline status.
+- The Token refresh mechanism cannot trigger request storms.
+- Components should consume hooks/domain functions rather than calling raw fetch directly.
+- Uploads and live streams need to expose progress, cancellation, failure and retry status.

package/skills/fec-backend-requirements-handoff/SKILL.md

@@ -1,45 +1,45 @@
 ---
 name: fec-backend-requirements-handoff
-description: Use when frontend work needs to communicate data, action, state, permission, validation, or business-rule needs to backend teams without dictating endpoint design, field names, database shape, or implementation details; Chinese triggers include 前后端需求交接, 后端需求, API 需求澄清, 数据需求说明.
+description: Use when frontend work needs to communicate data, action, state, permission, validation, or business-rule needs to backend teams without dictating endpoint design, field names, database shape, or implementation details; Chinese triggers include front-end and back-end requirements handover, back-end requirements, API requirements clarification, data requirements description.
 ---
 
-# 前后端需求交接
+# Handover of front-end and back-end requirements
 
 ## Purpose
 
-把前端页面和交互所需的数据、动作、状态和疑问整理成后端可讨论的需求说明。
+Organize the data, actions, status, and questions required for front-end pages and interactions into discussion-ready requirements for the back-end.
 
 ## Procedure
 
-1. 明确功能上下文
-   - 说明页面、流程或组件是什么，面向哪类用户，以及用户完成任务的成功状态。
-   - 如果已有设计稿、路由、用户故事或权限角色，先把它们作为事实来源。
+1. Clarify the functional context
+- Describe what the page, process, or component is, what type of user it is intended for, and the success status of the user completing the task.
+   - If there are existing designs, routes, user stories, or permission roles, use them as sources of truth first.
 
-2. 描述前端展示需求
-   - 按屏幕或组件列出需要展示的信息、信息之间的关系、排序/过滤/分页需求和可见性规则。
-   - 使用业务语言描述“需要展示什么”，不要提前规定 endpoint、字段名、DTO、数据库表或响应嵌套结构。
+2. Describe front-end display requirements
+   - List information to be displayed by screen or component, relationships between information, sorting/filtering/pagination requirements and visibility rules.
+   - Use business language to describe "what needs to be displayed" and do not specify endpoints, field names, DTOs, database tables or response nested structures in advance.
 
-3. 描述用户动作和结果
-   - 列出用户能执行的动作、期望结果、成功反馈、失败反馈和是否需要乐观更新。
-   - 标出幂等性、撤销、确认、危险操作、批量操作或长任务进度等对 UI 有影响的行为。
+3. Describe user actions and results
+   - List the actions the user can perform, expected results, success feedback, failure feedback and whether optimistic updates are needed.
+   - Mark behaviors that affect the UI such as idempotence, undo, confirm, dangerous operations, batch operations, or long task progress.
 
-4. 补齐状态和业务规则
-   - 覆盖 loading、empty、error、partial、permission denied、expired、conflict、offline 和 retrying 等状态。
-   - 记录影响 UI 的权限、生命周期、金额/时区/枚举、校验、可编辑条件和边界规则。
+4. Complete status and business rules
+   - Override the status of loading, empty, error, partial, permission denied, expired, conflict, offline and retrying.
+   - Document permissions, lifecycle, amounts/timezones/enumerations, validations, editable conditions, and boundary rules that affect the UI.
 
-5. 输出讨论文档
-   - 默认写到 `docs/backend-requirements/<feature-name>.md`；若仓库已有需求文档目录，沿用现有位置。
-   - 文档包含 Context、Screens/Components、Data Needs、User Actions、UI States、Business Rules、Uncertainties、Questions for Backend 和 Decision Log。
-   - 若用户只需要聊天回复，可以直接输出同样结构的 Markdown，不创建文件。
+5. Output discussion document
+   - By default, it is written to `docs/backend-requirements/<feature-name>.md`; if the warehouse already has a requirements document directory, the existing location will be used.
+   - Documentation includes Context, Screens/Components, Data Needs, User Actions, UI States, Business Rules, Uncertainties, Questions for Backend and Decision Log.
+   - If the user only needs chat replies, they can directly output Markdown with the same structure without creating a file.
 
 ## Constraints
 
-- 不替后端规定 URL、HTTP 方法、字段名、数据库 schema、缓存实现或服务拆分。
-- 不把前端猜测写成事实；不确定的业务规则必须进入 Uncertainties 或 Questions。
-- 不忽略错误、空态、权限和部分数据；这些状态决定接口协作质量。
-- 不把内部错误栈、数据库字段或敏感实现细节要求暴露给 UI。
-- 不与 API 集成流程重复：本 skill 描述需求，客户端边界、类型来源和错误映射实现应在后续实现阶段处理。
+- Does not specify URLs, HTTP methods, field names, database schema, cache implementation, or service splitting for the backend.
+- Don't write front-end guesses into facts; uncertain business rules must go into Uncertainties or Questions.
+- Errors, empty states, permissions and partial data are not ignored; these states determine the quality of interface collaboration.
+- Do not expose internal error stacks, database fields, or sensitive implementation details to the UI.
+- Does not duplicate the API integration process: This skill describes the requirements, client boundaries, type sources and error mapping implementation should be handled in subsequent implementation phases.
 
 ## Expected Output
 
-产出一份前端视角的后端需求交接说明，清楚描述 UI 需要什么数据和行为、哪些规则仍需确认，以及后续前后端需要共同决定的问题。
+Produce a back-end requirements handover description from a front-end perspective, clearly describing what data and behaviors the UI requires, which rules still need to be confirmed, and subsequent issues that need to be decided jointly by the front-end and back-end.