@bovinphang/frontend-craft 2.9.0 → 3.0.0

package/templates/shared/rules/fec-source-driven-development.md

@@ -1,31 +1,5 @@
-# Source-driven development rules
+# Frontend source checks
 
-When an implementation relies on a framework, library, browser, runtime, build tool, or platform behavior, confirm the source of truth before writing code or reviewing conclusions.
+For version-sensitive frontend decisions, inspect actual framework/library versions, routing/rendering modes, caches, build configuration, browser APIs and compatibility.
 
-## Fact source priority
-
-1. README, configuration, testing, templates and existing implementations within the project.
-2. Official documents, source code, type definitions, release notes, migration guide.
-3. Web standards, browser compatibility data, and platform documentation.
-4. Issues, discussions, blogs and third-party articles are only used as clues.
-
-## Usage scenarios
-
-- New versions of frameworks, routing, rendering modes, caching, build configurations, browser APIs.
-- Public interfaces, component APIs, design system tokens, CLI commands, and plugin metadata.
-- Dependency upgrade, migration, obsolete API replacement, cross-runtime compatibility.
-- Version-sensitive judgments related to security, performance, and accessibility.
-
-## Output requirements
-
-- Write down the source, version or project facts, decision conclusion, scope of influence and verification method.
-- If the current status of the project conflicts with official recommendations, explain the cause of the conflict and the gradual migration strategy.
-- Do not copy long external documents; only keep necessary conclusions, links or file paths within the project.
-- Mark uncertainties and matters requiring confirmation from the user/team when they cannot be verified.
-
-## Anti-pattern
-
-- Use version-sensitive APIs from memory.
-- Replace official documentation with outdated tutorials.
-- Overturn the stable project agreement in order to pursue new projects.
-- Scatter external library behavior assumptions throughout components instead of centralizing them in the adaptation layer.
+The product supplies the common source-driven method. Frontend-specific evidence includes component APIs, design tokens, browser security, performance, accessibility, package exports and runtime integration. Use project implementation and authoritative versioned sources; record versions, impact and observed verification instead of treating old tutorials as stable contracts.

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

@@ -1,6 +1,6 @@
 # TypeScript / JavaScript rules
 
-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.
+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 `cc-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
 
@@ -11,7 +11,7 @@ Use types to make external APIs, shared models, and component props explicit, re
 - 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`.
+- The boundaries of external data, API DTOs, routing parameters, form values and component props must be explicitly named; complex modeling is offloaded to `cc-typescript-project-standard`.
 
 ### `interface` and `type`
 
@@ -37,7 +37,7 @@ Use types to make external APIs, shared models, and component props explicit, re
 - 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.
+- TSX generics, complex component props or external DTO mapping issues are left to React rules and `cc-typescript-project-standard` to converge together.
 
 ## Single file size and module splitting
 
@@ -74,7 +74,7 @@ Use types to make external APIs, shared models, and component props explicit, re
 
 - 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`.
+- 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 `cc-typescript-project-standard`.
 
 ## Type asset layering and naming
 

package/templates/shared/rules/references/common/source-driven-development.md

@@ -0,0 +1,19 @@
+# Source-driven development
+
+Use project facts, authoritative sources and version-specific evidence to make engineering decisions.
+
+1. Establish the question, affected version and local contract. Read the project's manifests, configuration, implementation, callers and tests before proposing changes. Stable local transformations can rely on those facts; changing runtime, package or public API assumptions need authoritative verification.
+2. Collect official documentation, source, type definitions, release notes, specifications and migration guides for the actual version. Third-party discussions provide clues, not the final basis. Record source paths/URLs, versions, dates and relevant conclusions.
+3. Compare recommendations with the running project. State compatibility, maintenance cost, migration scope and rollback. Isolate unstable external assumptions behind a small boundary; do not overturn stable conventions just to use a newer pattern.
+4. Prove key assumptions using the project's existing checks or a minimal reproduction. Select checks for the actual stack. Record commands and observed outcomes; if verification is unavailable, report the uncertainty rather than claim support.
+5. Update a lightweight ADR, migration record or factual documentation when public interfaces, dependencies or team conventions change. Do not copy long external documents.
+
+## Local knowledge requests
+
+When a user restricts evidence to a local repository or knowledge directory, search that source first and do not fill gaps with online guesses. Use the explicit path, otherwise check whether `knowledge/` exists. If absent, identify the missing source instead of inventing one.
+
+Read `data_structure.md` navigation where available, choose relevant branches, and search progressively instead of loading the entire corpus. Default to at most five keyword refinement rounds. Record file paths, sections/pages/sheets, version range and evidence gaps. For PDF or spreadsheets choose an appropriate extraction tool before reading large content. Use external sources only when the user's scope permits them.
+
+## Evidence priority and delivery
+
+Project implementation/configuration/tests establish the local contract; official versioned documentation/source establishes external behavior; specifications establish platform constraints; issues and articles only supplement these. Deliver the decision, sources, implementation impact, verification results and remaining uncertainty. "Checked the docs" without traceable evidence is insufficient.

package/localized/zh-CN/skills/fec-image-generation/assets/quality-examples/README.md

@@ -1,14 +0,0 @@
-# 技术图质量样例
-
-JSON 样例覆盖时序自调用、流程决策回环、架构分组和双向连接。Mermaid 源用于标准时序与流程图；修改布局时保留全部文字和连接关系。
-
-```sh
-node skills/fec-image-generation/scripts/tech-diagram-render.mjs --input skills/fec-image-generation/assets/quality-examples/workflow.json --type workflow --output workflow.html --manifest workflow.layout.json
-node skills/fec-image-generation/scripts/export-diagram.mjs --input workflow.html --format png --output workflow.png --theme light --scale 2 --manifest workflow.layout.json --output-manifest workflow.actual.json
-node skills/fec-image-generation/scripts/png-qa.mjs --png workflow.png --manifest workflow.actual.json --format json
-node skills/fec-image-generation/scripts/mermaid-render.mjs --input skills/fec-image-generation/assets/quality-examples/sequence.mmd --output sequence.svg --report sequence.render.json
-```
-
-PNG 需要本地 Chromium，可用 FEC_BROWSER_PATH 指定路径。Mermaid 需要已安装的 mmdc，不自动安装或使用 CDN；缺失时明确记录并使用 JSON/HTML。需要手工编辑的架构图复用 fec-drawio-studio，大型拓扑可选 Graphviz。
-
-按交付阅读尺寸检查 1x 和 2x 图片，检查形状内部文字、标签和箭头、分支返回、回环、分组及明暗主题对比。几何 QA 不能替代看图。显式尺寸不足或 waypoints 受阻时报告问题，在源级修复且保留意图。默认最多修复两轮，用户要求时最多五轮，未解决则报告部分验收。

package/localized/zh-CN/skills/fec-source-driven-development/SKILL.md

@@ -1,87 +0,0 @@
----
-name: fec-source-driven-development
-description: 用于前端决策依赖可能变化的框架、库、浏览器、运行时、包、API 或平台行为时，包括官方文档核验、版本敏感模式、迁移选择或公共接口假设；中文触发词包括 查官方文档、以源码为准、source-driven、版本差异。
----
-
-# 来源驱动开发
-
-## 用途
-
-在前端实现、评审和架构决策中优先依据项目内事实、官方文档和当前版本行为，避免沿用过时经验或未经验证的假设。
-
-## 流程
-
-1. 判断是否需要查源
-   - 涉及框架新版本、路由、渲染模式、缓存、构建工具、浏览器 API、包发布格式、鉴权协议或公共接口时必须查源。
-   - 涉及项目约定时先读本仓库 README、配置、模板、已有实现、测试和迁移记录。
-   - 只是稳定语言语法或明显局部重构时，可使用项目现有模式作为事实来源。
-
-2. 收集权威材料
-   - 首选官方文档、规范、源码、release notes、migration guide、类型定义和项目内测试。
-   - 第三方文章只能作为线索，不能作为最终依据。
-   - 对快速变化的库记录包名、版本、文档日期或页面标题。
-   - 当用户要求从本地知识库、项目资料库或 `knowledge/` 目录回答问题时，先走本地知识检索，不使用网络搜索补事实。
-
-3. 提炼决策
-   - 写清当前版本推荐做法、弃用做法、限制条件和迁移注意事项。
-   - 对多个可行方案说明选择理由、兼容性、维护成本和回退方式。
-   - 若文档和项目现状冲突，优先解释冲突并给出渐进调整，不直接推翻已运行系统。
-   - 对依赖升级、框架迁移和公共 API 变化，记录 release notes、migration guide、版本范围、破坏性变更和回滚方案。
-
-4. 落到实现
-   - 将外部行为隔离在适配层、配置层或小型工具函数中，避免在组件里散落版本假设。
-   - 公共接口变化要保持命名、错误形状、默认值和兼容策略清晰。
-   - 代码注释只记录非显而易见的来源约束，不粘贴大段文档。
-
-5. 验证假设
-   - 用类型检查、最小复现、单元测试、组件测试、E2E、构建或浏览器验证证明关键假设。
-   - 如果无法验证，报告不确定性、风险范围和需要用户或团队确认的信息。
-6. 留下轻量决策记录
-   - 当结论会影响公共接口、依赖版本、目录规范或团队工作流时，补充 ADR/变更记录或交给文档同步流程。
-
-## 本地知识检索
-
-当用户指定本地知识库路径，或默认 `knowledge/` 目录存在时，可用本流程回答资料库问题、抽取证据或辅助决策。
-
-1. 定位根目录
-   - 用户明确指定路径时使用该路径。
-   - 否则检查当前项目下 `knowledge/` 是否存在；不存在时说明未找到默认知识库并请求路径。
-   - 不用文件 glob 判断目录是否存在。
-
-2. 分层导航
-   - 优先读取根目录和子目录中的 `data_structure.md`。
-   - 根据目录说明选择最相关的少量分支，不一次性遍历整个知识库。
-   - 记录候选文件、主题、时间/版本范围和为什么相关。
-
-3. 渐进检索
-   - Markdown、文本、日志：先用关键词搜索，再局部读取命中上下文。
-   - PDF：处理前先确认可用工具和提取路线，优先提取到临时文本后再检索，避免把整份 PDF 打进上下文。
-   - Excel：处理前先确认读取/分析路线，先看工作表、列名和少量样例，再按字段过滤或聚合。
-   - 默认最多 5 轮关键词迭代；每轮根据已找到证据调整同义词、缩写和范围。
-
-4. 回答与溯源
-   - 先给结论，再列文件路径、章节、页码、工作表或行号附近作为依据。
-   - 证据不足时说明查过哪些路径、缺什么信息，以及用户如何缩小范围。
-   - 不把知识库外的网络信息混入答案，除非用户另行要求查外部来源。
-
-## 事实源优先级
-
-| 优先级 | 来源 | 用途 |
-| ------ | ---- | ---- |
-| 1 | 项目内配置、测试、已有实现 | 判断本仓库真实约定 |
-| 2 | 官方文档、源码、类型定义 | 判断当前推荐行为 |
-| 3 | 标准规范、浏览器兼容数据 | 判断平台能力和兼容边界 |
-| 4 | Issue、讨论、第三方文章 | 辅助排查，不能单独定案 |
-
-## 约束
-
-- 不凭记忆给版本敏感结论。
-- 不把过时教程当作当前最佳实践。
-- 不引用无法复核的来源作为关键依据。
-- 不为追新而改动稳定项目约定；必须说明收益和迁移成本。
-- 不在交付中复制长篇外部文档；只保留必要结论和链接或文件路径。
-- 不把“查过文档”停留在口头；版本敏感决策需要能追溯到具体版本、路径或官方页面。
-
-## 预期输出
-
-输出来源清单、版本或项目事实、决策结论、实现影响、验证命令和未决风险。若修改代码，关键行为应有测试或构建验证支撑。

package/skills/fec-source-driven-development/SKILL.md

@@ -1,87 +0,0 @@
----
-name: fec-source-driven-development
-description: Use when frontend decisions depend on framework, library, browser, runtime, package, API, or platform behavior that may have changed, including official documentation checks, version-sensitive patterns, migration choices, or public interface assumptions; Chinese triggers include Check official documentation, source code shall prevail, source-driven, version differences.
----
-
-# Source driven development
-
-## Purpose
-
-Prioritize the use of in-project facts, official documentation, and current version behavior in front-end implementation, review, and architecture decisions, and avoid relying on outdated experience or unverified assumptions.
-
-## Procedure
-
-1. Determine whether it is necessary to check the source
-   - Source checking is required when new versions of frameworks, routing, rendering modes, caches, build tools, browser APIs, package publishing formats, authentication protocols, or public interfaces are involved.
-   - When it comes to project commitments, read the README, configuration, templates, existing implementations, testing and migration records of this warehouse first.
-   - Use the project's existing schema as a source of truth when simply stabilizing the language syntax or significantly partial refactoring.
-
-2. Collect authoritative materials
-   - Preferred official documentation, specifications, source code, release notes, migration guide, type definitions and in-project testing.
-   - Third-party articles can only be used as clues and cannot be used as the final basis.
-   - Record package name, version, document date or page title for rapidly changing libraries.
-   - When a user asks to answer a question from a local knowledge base, project repository or `knowledge/` directory, perform local knowledge retrieval first and do not use network search to fill in the facts.
-
-3. Refine decisions
-   - Write down recommended practices, deprecated practices, limitations and migration considerations for the current version.
-   - Explain the reasons for selection, compatibility, maintenance costs and fallback methods for multiple feasible options.
-   - If there is a conflict between the document and the current status of the project, priority will be given to explaining the conflict and making incremental adjustments instead of directly overturning the running system.
-   - Record release notes, migration guide, version scope, breaking changes and rollback plans for dependency upgrades, framework migrations and public API changes.
-
-4. Fall to implementation
-- Isolate external behavior in the adaptation layer, configuration layer or small utility functions to avoid spreading version assumptions throughout the component.
-   - Public interface changes should keep naming, error shapes, default values, and compatibility policies clear.
-   - Code comments only record non-obvious source constraints and do not paste large sections of documentation.
-
-5. Test your hypothesis
-   - Prove key assumptions with type checking, minimal reproduction, unit testing, component testing, E2E, build or browser validation.
-   - If verification is not possible, report uncertainty, risk range, and information that requires confirmation by the user or team.
-6. Leave a lightweight record of decisions
-   - Supplement ADR/change records or hand off to the document sync process when conclusions impact public interfaces, dependency versions, catalog specifications or team workflows.
-
-## Local Knowledge Retrieval
-
-When the user specifies the local knowledge base path, or the default `knowledge/` directory exists, this process can be used to answer database questions, extract evidence, or assist decision-making.
-
-1. Locate the root directory
-   - Use this path when the user explicitly specifies the path.
-   - Otherwise, check whether `knowledge/` under the current project exists; if it does not exist, it means that the default knowledge base is not found and the path is requested.
-   - No need to use file glob to determine whether the directory exists.
-
-2. Hierarchical navigation
-   - Read `data_structure.md` in the root directory and subdirectories first.
-   - Select the most relevant few branches according to the directory description, without traversing the entire knowledge base at once.
-   - Document candidate files, topics, time/version range and why they are relevant.
-
-3. Progressive search
-   - Markdown, text, log: first search with keywords, and then partially read the hit context.
-   - PDF: Confirm the available tools and extraction routes before processing, and prioritize extraction of temporary text before retrieval to avoid putting the entire PDF into context.
-   - Excel: Confirm the read/analysis route before processing, first look at the worksheet, column names and a few samples, and then filter or aggregate by field.
-   - Default to up to 5 rounds of keyword iteration; each round adjusts synonyms, abbreviations, and scope based on found evidence.
-
-4. Answer and traceability
-   - Give the conclusion first, and then list the file path, chapter, page number, worksheet or line number as a basis.
-   - If there is insufficient evidence, explain which paths have been checked, what information is missing, and how the user can narrow down the scope.
-   - Do not mix online information from outside the knowledge base into answers unless the user requests otherwise to check external sources.
-
-## Source Priority
-
-| Priority | Source | Use |
-| -------- | ------ | --- |
-| 1 | Configuration, testing, and implementation within the project | Determine the true agreement of this warehouse |
-| 2 | Official documents, source code, type definitions | Determine current recommended behavior |
-| 3 | Standard specifications, browser compatibility data | Determine platform capabilities and compatibility boundaries |
-| 4 | Issues, discussions, third-party articles | Auxiliary investigation, cannot be finalized alone |
-
-## Constraints
-
-- Don't give version-sensitive conclusions from memory.
-- Do not treat outdated tutorials as current best practices.
-- Do not cite sources that cannot be reviewed as critical evidence.
-- Do not change the stable project agreement to pursue new developments; the benefits and migration costs must be explained.
-- Do not copy long external documents in the delivery; keep only necessary conclusions and links or file paths.
-- Don't just say "checked the documentation"; version-sensitive decisions need to be traceable to a specific version, path or official page.
-
-## Expected Output
-
-Output source lists, version or project facts, decision conclusions, implementation impacts, validation orders, and open risks. If code is modified, key behaviors should be supported by tests or build verification.