@bovinphang/frontend-craft 2.5.0 → 2.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude-plugin/marketplace.json +7 -3
- package/.claude-plugin/plugin.json +1 -1
- package/CHANGELOG.md +39 -0
- package/CHANGELOG.zh-CN.md +40 -0
- package/CONTRIBUTING.md +15 -10
- package/CONTRIBUTING.zh-CN.md +15 -10
- package/README.md +61 -39
- package/README.openclaw.md +8 -8
- package/README.openclaw.zh-CN.md +8 -8
- package/README.zh-CN.md +61 -39
- package/commands/fec-doc-sync.md +7 -6
- package/dist/bin/frontend-craft.js +30 -27
- package/docs/example-prompts.md +4 -3
- package/docs/ja-JP/README.md +61 -39
- package/docs/ko-KR/README.md +61 -39
- package/docs/runtimes/antigravity.md +1 -1
- package/docs/runtimes/augment.md +1 -1
- package/docs/runtimes/claude.md +16 -10
- package/docs/runtimes/claude.zh-CN.md +16 -10
- package/docs/runtimes/cline.md +1 -1
- package/docs/runtimes/codebuddy.md +1 -1
- package/docs/runtimes/codex.md +1 -1
- package/docs/runtimes/copilot.md +1 -1
- package/docs/runtimes/cursor.md +1 -1
- package/docs/runtimes/gemini.md +1 -1
- package/docs/runtimes/kilo.md +1 -1
- package/docs/runtimes/openclaw.md +1 -1
- package/docs/runtimes/opencode.md +1 -1
- package/docs/runtimes/qoder.md +1 -1
- package/docs/runtimes/trae.md +1 -1
- package/docs/runtimes/windsurf.md +1 -1
- package/docs/zh-CN/example-prompts.md +4 -3
- package/docs/zh-TW/README.md +61 -39
- package/openclaw.plugin.json +1 -1
- package/package.json +1 -1
- package/skills/eval_queries.json +25 -0
- package/skills/fec-accessibility-check/SKILL.md +1 -1
- package/skills/fec-alchemy/SKILL.md +74 -0
- package/skills/fec-alchemy/assets/absorption-plan-template.md +47 -0
- package/skills/fec-alchemy/assets/intake-template.md +55 -0
- package/skills/fec-alchemy/assets/review-checklist.md +31 -0
- package/skills/fec-alchemy/references/methodology.md +94 -0
- package/skills/fec-alchemy/references/originality-and-licensing.md +57 -0
- package/skills/fec-browser-storage/SKILL.md +1 -1
- package/skills/fec-canvas-threejs/SKILL.md +1 -1
- package/skills/fec-code-review/SKILL.md +10 -2
- package/skills/fec-data-fetching/SKILL.md +15 -15
- package/skills/fec-data-fetching/references/query-patterns.md +27 -1
- package/skills/fec-debug-framework/SKILL.md +14 -19
- package/skills/fec-debug-framework/references/report-template.md +58 -0
- package/skills/fec-doc-sync/SKILL.md +19 -17
- package/skills/fec-e2e-testing/SKILL.md +3 -3
- package/skills/fec-form-handling/SKILL.md +11 -11
- package/skills/fec-form-handling/references/advanced-form-patterns.md +34 -5
- package/skills/fec-implement-from-design/SKILL.md +2 -2
- package/skills/fec-legacy-to-modern-migration/SKILL.md +33 -23
- package/skills/fec-legacy-web-standard/SKILL.md +1 -1
- package/skills/fec-list-virtualization/SKILL.md +3 -3
- package/skills/fec-list-virtualization/references/virtualization-patterns.md +32 -4
- package/skills/fec-performance-optimization/SKILL.md +5 -1
- package/skills/fec-performance-optimization/references/report-template.md +53 -0
- package/skills/fec-pwa-implementation/SKILL.md +3 -4
- package/skills/fec-react-project-standard/SKILL.md +1 -1
- package/skills/fec-refactor-clean/SKILL.md +4 -1
- package/skills/fec-refactor-clean/references/report-template.md +42 -0
- package/skills/fec-security-review/SKILL.md +3 -3
- package/skills/fec-state-management/SKILL.md +1 -1
- package/skills/fec-storybook-component-doc/SKILL.md +2 -2
- package/skills/fec-typescript-type-safety/SKILL.md +1 -1
- package/skills/fec-validation-fix/SKILL.md +5 -2
- package/skills/fec-validation-fix/references/report-template.md +43 -0
- package/skills/fec-vue3-project-standard/SKILL.md +1 -1
- package/skills/fec-web-workers/SKILL.md +3 -4
- package/skills/metadata.json +82 -45
- package/skills/relations.json +20 -0
- package/docs/superpowers/plans/2026-05-29-fec-debug.md +0 -491
- package/docs/superpowers/specs/2026-05-29-fec-debug-design.md +0 -340
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Alchemy 吸收计划
|
|
2
|
+
|
|
3
|
+
## 目标
|
|
4
|
+
|
|
5
|
+
描述需要交付的目标项目原生化改进。
|
|
6
|
+
|
|
7
|
+
## 参考项目优势
|
|
8
|
+
|
|
9
|
+
| 候选项 | 参考洞察 | 目标项目缺口 | 策略 | 优先级 |
|
|
10
|
+
|---|---|---|---|---|
|
|
11
|
+
| | | | 增强 / 新增 / 拆分 / 合并 / 替换 / 文档化 / 拒绝 | |
|
|
12
|
+
|
|
13
|
+
## 目标设计
|
|
14
|
+
|
|
15
|
+
- 目标架构落点:
|
|
16
|
+
- 用户可见能力:
|
|
17
|
+
- 公开 API / CLI / 配置 / UI 入口:
|
|
18
|
+
- UI / API / 数据 / 运行时 / 工具链 / 文档影响:
|
|
19
|
+
- 公开 API 或用户可见行为:
|
|
20
|
+
- 内部数据流:
|
|
21
|
+
- 命名和约定:
|
|
22
|
+
- 依赖影响:
|
|
23
|
+
- 向后兼容性:
|
|
24
|
+
|
|
25
|
+
## 实现步骤
|
|
26
|
+
|
|
27
|
+
1.
|
|
28
|
+
2.
|
|
29
|
+
3.
|
|
30
|
+
|
|
31
|
+
## 验证
|
|
32
|
+
|
|
33
|
+
- 类型检查:
|
|
34
|
+
- Lint:
|
|
35
|
+
- 单元测试:
|
|
36
|
+
- 集成测试:
|
|
37
|
+
- 构建:
|
|
38
|
+
- 人工评审:
|
|
39
|
+
|
|
40
|
+
## 风险
|
|
41
|
+
|
|
42
|
+
- 许可证 / 来源:
|
|
43
|
+
- 范围膨胀:
|
|
44
|
+
- 架构重叠:
|
|
45
|
+
- 性能:
|
|
46
|
+
- 安全:
|
|
47
|
+
- 维护:
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# Alchemy 信息收集模板
|
|
2
|
+
|
|
3
|
+
## 目标项目
|
|
4
|
+
|
|
5
|
+
- 路径 / URL:
|
|
6
|
+
- 项目定位:
|
|
7
|
+
- 项目类型:
|
|
8
|
+
- 主要用户:
|
|
9
|
+
- 技术栈:
|
|
10
|
+
- 当前相关模块:
|
|
11
|
+
- 已有类似能力:
|
|
12
|
+
- 目标项目适配边界:
|
|
13
|
+
- 验证命令:
|
|
14
|
+
- 约束条件:
|
|
15
|
+
|
|
16
|
+
## 参考项目
|
|
17
|
+
|
|
18
|
+
- 路径 / URL:
|
|
19
|
+
- 项目定位:
|
|
20
|
+
- 项目类型:
|
|
21
|
+
- 主要用户:
|
|
22
|
+
- 技术栈:
|
|
23
|
+
- 重点模块:
|
|
24
|
+
- 特色能力:
|
|
25
|
+
- 许可证 / 来源:
|
|
26
|
+
- 风险:
|
|
27
|
+
|
|
28
|
+
## 能力域清单
|
|
29
|
+
|
|
30
|
+
- 产品能力:
|
|
31
|
+
- 架构模式:
|
|
32
|
+
- 领域模型:
|
|
33
|
+
- 接口协议:
|
|
34
|
+
- 数据流:
|
|
35
|
+
- 运行时行为:
|
|
36
|
+
- 开发体验:
|
|
37
|
+
- 质量体系:
|
|
38
|
+
- 交付流程:
|
|
39
|
+
- 文档知识:
|
|
40
|
+
- 生态扩展:
|
|
41
|
+
|
|
42
|
+
## 项目形态探针
|
|
43
|
+
|
|
44
|
+
- 前端项目(页面 / 组件 / 路由 / 状态 / 数据请求 / 表单 / 设计系统 / 可访问性 / 性能 / 构建):
|
|
45
|
+
- 后端项目(API / 服务边界 / 数据库 / 队列 / 缓存 / 认证授权 / 任务调度 / 可观测性 / 部署):
|
|
46
|
+
- 工具或 CLI 项目(命令模型 / 配置 / 插件机制 / 错误输出 / 安装分发 / 模板):
|
|
47
|
+
- AI/Agent 项目(skills / commands / hooks / rules / agents / MCP / prompt / workflow):
|
|
48
|
+
- 库项目(公开 API / 类型 / 兼容性 / 构建产物 / 示例 / 版本策略):
|
|
49
|
+
- 文档或知识库项目(信息架构 / 导航 / 示例 / 搜索 / 版本化 / 贡献流程 / 发布节奏):
|
|
50
|
+
|
|
51
|
+
## 不吸收范围
|
|
52
|
+
|
|
53
|
+
- 明确拒绝:
|
|
54
|
+
- 延后观察:
|
|
55
|
+
- 只作为灵感不落地:
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Alchemy 评审检查清单
|
|
2
|
+
|
|
3
|
+
## 架构
|
|
4
|
+
|
|
5
|
+
- [ ] 变更属于选定的目标模块。
|
|
6
|
+
- [ ] 没有重复实现已有能力、入口、抽象或用户工作流。
|
|
7
|
+
- [ ] 职责清晰且不重叠。
|
|
8
|
+
- [ ] 命名符合目标项目语义。
|
|
9
|
+
- [ ] 目标架构落点清晰,未为了参考项目形态引入并行体系。
|
|
10
|
+
- [ ] 配置、运行时流程、工具函数和文档承诺没有互相冲突。
|
|
11
|
+
|
|
12
|
+
## 原创性
|
|
13
|
+
|
|
14
|
+
- [ ] 不存在缺少许可证依据的非平凡复制代码或文本。
|
|
15
|
+
- [ ] 实现已用目标项目原生风格表达。
|
|
16
|
+
- [ ] 参考项目影响被总结为思想、模式或行为。
|
|
17
|
+
- [ ] 如许可证要求,已保留必要署名。
|
|
18
|
+
|
|
19
|
+
## 质量
|
|
20
|
+
|
|
21
|
+
- [ ] 测试或验证步骤覆盖了被吸收的行为。
|
|
22
|
+
- [ ] 错误与边界场景已处理。
|
|
23
|
+
- [ ] 依赖新增有充分理由。
|
|
24
|
+
- [ ] 文档和示例已更新。
|
|
25
|
+
- [ ] 选用的项目形态探针与实际目标相关,没有做无关全量扫描。
|
|
26
|
+
|
|
27
|
+
## 交付
|
|
28
|
+
|
|
29
|
+
- [ ] 已总结面向用户的变更。
|
|
30
|
+
- [ ] 已说明被拒绝的候选项。
|
|
31
|
+
- [ ] 已记录风险和后续工作。
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# 项目吸收方法论
|
|
2
|
+
|
|
3
|
+
## 目标
|
|
4
|
+
|
|
5
|
+
本文档用于扩展 `SKILL.md` 中的核心流程,适合更大型的“参考系统到目标项目”能力吸收任务。参考系统可以是代码库、产品、服务、框架、库、CLI、插件、文档体系或 AI/Agent 工具链。
|
|
6
|
+
|
|
7
|
+
## 阶段 1:建立目标项目基线
|
|
8
|
+
|
|
9
|
+
在深入研究参考项目之前,先为目标项目建立简短基线:
|
|
10
|
+
|
|
11
|
+
- 目标项目声明的用途是什么?
|
|
12
|
+
- 当前已有的顶层能力有哪些?
|
|
13
|
+
- 已存在的入口、扩展点和用户工作流有哪些?
|
|
14
|
+
- 哪些区域仍在活跃维护?
|
|
15
|
+
- 哪些区域脆弱、复杂或过度设计?
|
|
16
|
+
- 已有哪些测试和验证命令?
|
|
17
|
+
|
|
18
|
+
在理解目标项目基线之前,不要过早形成改造建议。
|
|
19
|
+
|
|
20
|
+
## 阶段 2:扫描参考项目
|
|
21
|
+
|
|
22
|
+
扫描参考系统中的高信号材料:
|
|
23
|
+
|
|
24
|
+
- README 和文档:项目定位、使用模型、安装、配置。
|
|
25
|
+
- 包或构建元数据:技术选型、依赖范围、脚本命令。
|
|
26
|
+
- 源码布局:架构、模块边界、命名约定。
|
|
27
|
+
- 能力域:产品能力、架构模式、领域模型、接口协议、数据流、运行时行为、开发体验、质量体系、交付流程、文档知识、生态扩展。
|
|
28
|
+
- 项目形态探针:按参考系统类型选择相关目录和行为入口,不假设所有项目都有相同结构。
|
|
29
|
+
- 测试:预期行为和边界场景。
|
|
30
|
+
- 示例:面向用户的工作流和上手体验质量。
|
|
31
|
+
|
|
32
|
+
记录观察时,应记录为“能力”,而不是“文件”。例如写“具备带环境检查的引导式配置向导”,而不是写“复制 setup.ts”。
|
|
33
|
+
|
|
34
|
+
### 项目形态探针
|
|
35
|
+
|
|
36
|
+
按目标和参考系统的实际形态选择扫描视角:
|
|
37
|
+
|
|
38
|
+
- 前端项目:页面、组件、路由、状态、数据请求、表单、设计系统、可访问性、性能、构建。
|
|
39
|
+
- 后端项目:API、服务边界、数据库、队列、缓存、认证授权、任务调度、可观测性、部署。
|
|
40
|
+
- 工具或 CLI 项目:命令模型、配置、插件机制、错误输出、安装分发、模板。
|
|
41
|
+
- AI/Agent 项目:skills、commands、hooks、rules、agents、MCP、prompt、workflow。
|
|
42
|
+
- 库项目:公开 API、类型、兼容性、构建产物、示例、版本策略。
|
|
43
|
+
- 文档或知识库项目:信息架构、导航、示例、搜索、版本化、贡献流程、发布节奏。
|
|
44
|
+
|
|
45
|
+
如果项目横跨多种形态,优先选择与用户目标直接相关的 1 到 3 个视角,避免把吸收任务扩大成全仓库审计。
|
|
46
|
+
|
|
47
|
+
## 阶段 3:候选能力评分
|
|
48
|
+
|
|
49
|
+
对每个候选项按 1 到 5 分评分。
|
|
50
|
+
|
|
51
|
+
| 维度 | 问题 |
|
|
52
|
+
|---|---|
|
|
53
|
+
| 用户价值 | 是否能实质改善目标用户的工作流? |
|
|
54
|
+
| 适配度 | 是否符合目标项目的架构和路线图? |
|
|
55
|
+
| 原创化可行性 | 是否可以在不复制受保护表达的情况下重新创建? |
|
|
56
|
+
| 复杂度 | 是否可以安全交付并长期维护? |
|
|
57
|
+
| 可验证性 | 正确性是否可以通过测试或评审验证? |
|
|
58
|
+
|
|
59
|
+
优先处理高价值、高适配、低风险的候选项。
|
|
60
|
+
|
|
61
|
+
## 阶段 4:吸收策略
|
|
62
|
+
|
|
63
|
+
为每个候选项选择一种策略:
|
|
64
|
+
|
|
65
|
+
- **增强**:改进目标项目已有能力。
|
|
66
|
+
- **新增**:引入新的目标项目原生能力。
|
|
67
|
+
- **拆分**:拆解过载的目标概念或参考概念。
|
|
68
|
+
- **合并**:合并目标项目中重叠的概念。
|
|
69
|
+
- **替换**:在更安全设计准备好后,移除较弱的目标实现。
|
|
70
|
+
- **文档化**:只补充知识,不改代码。
|
|
71
|
+
- **拒绝**:明确延后或放弃,并说明原因。
|
|
72
|
+
|
|
73
|
+
## 阶段 5:实现顺序
|
|
74
|
+
|
|
75
|
+
推荐按以下顺序推进:
|
|
76
|
+
|
|
77
|
+
1. 文档和边界澄清。
|
|
78
|
+
2. 测试或验证脚手架。
|
|
79
|
+
3. 最小化的目标项目原生实现。
|
|
80
|
+
4. 与现有工作流集成。
|
|
81
|
+
5. 清理重复逻辑和废弃路径。
|
|
82
|
+
6. 面向用户的文档和示例。
|
|
83
|
+
|
|
84
|
+
## 阶段 6:评审问题
|
|
85
|
+
|
|
86
|
+
最终完成前,回答以下问题:
|
|
87
|
+
|
|
88
|
+
- 吸收后目标项目是否仍保持一致性?
|
|
89
|
+
- 模块边界是否被保留或改善?
|
|
90
|
+
- 每个新增能力是否可被发现?
|
|
91
|
+
- 是否存在重叠的能力、入口、抽象、配置、运行时流程、工具函数、文档承诺或用户工作流?
|
|
92
|
+
- 新增依赖是否有充分理由?
|
|
93
|
+
- 验证命令是否已记录?
|
|
94
|
+
- 是否透明说明了灵感来源,同时又没有暗示复制代码?
|
|
@@ -0,0 +1,57 @@
|
|
|
1
|
+
# 原创性与许可证约束
|
|
2
|
+
|
|
3
|
+
## 目标
|
|
4
|
+
|
|
5
|
+
本流程用于合法、合规、伦理且可维护的适配。它应帮助使用者提炼思想,并重新创建符合目标项目风格的设计,而不是伪装复制。
|
|
6
|
+
|
|
7
|
+
## 通常可以安全吸收的内容
|
|
8
|
+
|
|
9
|
+
- 高层思想和产品概念。
|
|
10
|
+
- 通用架构模式。
|
|
11
|
+
- 公开文档化的工作流。
|
|
12
|
+
- 用自己的语言表达的行为需求。
|
|
13
|
+
- 标准的、不可保护的或已获得适当许可的算法和技术。
|
|
14
|
+
- 为目标环境重新创建的配置概念。
|
|
15
|
+
|
|
16
|
+
## 需要谨慎处理的内容
|
|
17
|
+
|
|
18
|
+
- 来自其他项目的大段代码。
|
|
19
|
+
- 独特文本、提示词、示例、文档、图表、名称或品牌表达。
|
|
20
|
+
- 与参考项目高度绑定且非显而易见的实现结构。
|
|
21
|
+
- 包含许可证头或署名要求的生成文件。
|
|
22
|
+
- 带有限制性许可证的依赖。
|
|
23
|
+
- 私有或专有仓库。
|
|
24
|
+
|
|
25
|
+
## 安全适配流程
|
|
26
|
+
|
|
27
|
+
1. 用中性语言总结参考能力。
|
|
28
|
+
2. 识别它解决的问题。
|
|
29
|
+
3. 独立设计目标项目原生方案。
|
|
30
|
+
4. 使用目标项目约定实现新代码。
|
|
31
|
+
5. 将概念命名调整为目标项目语义。
|
|
32
|
+
6. 基于期望行为添加测试,而不是基于参考项目内部实现添加测试。
|
|
33
|
+
7. 当许可证要求署名时,保留必要署名。
|
|
34
|
+
8. 将许可证不确定性记录为风险,而不是忽略。
|
|
35
|
+
|
|
36
|
+
## 风险信号
|
|
37
|
+
|
|
38
|
+
- 输出在没有目标项目特定理由的情况下保留了参考项目相同的文件结构和命名。
|
|
39
|
+
- 输出包含大量完全相同或近似相同的代码/文本。
|
|
40
|
+
- Agent 无法解释目标设计为什么不同于参考设计。
|
|
41
|
+
- 新模块与目标项目现有模块高度重叠。
|
|
42
|
+
- 唯一理由只是“参考项目就是这样做的”。
|
|
43
|
+
|
|
44
|
+
## 报告中的推荐表述
|
|
45
|
+
|
|
46
|
+
建议使用:
|
|
47
|
+
|
|
48
|
+
- “受参考项目在……方面的处理方式启发。”
|
|
49
|
+
- “已重新实现为符合目标项目风格的模块,用于……”
|
|
50
|
+
- “参考项目通过 X 解决该问题;本项目选择 Y,因为……”
|
|
51
|
+
|
|
52
|
+
避免使用:
|
|
53
|
+
|
|
54
|
+
- “复制自……”
|
|
55
|
+
- “和……完全一样”
|
|
56
|
+
- “隐藏式模仿……”
|
|
57
|
+
- “让它看起来不相关……”
|
|
@@ -17,7 +17,7 @@ description: Use when choosing, implementing, or reviewing browser storage such
|
|
|
17
17
|
4. 敏感数据按安全规则处理,不把明文 token、密码、信用卡信息放进可被 JS 读取的存储。
|
|
18
18
|
5. 审查隐私模式、存储配额、清理策略和跨浏览器兼容性。
|
|
19
19
|
|
|
20
|
-
##
|
|
20
|
+
## 详细参考
|
|
21
21
|
|
|
22
22
|
涉及存储选型表、localStorage/sessionStorage 封装、IndexedDB 示例、Cookie 辅助方法和敏感数据规则时,加载 [references/storage-patterns.md](references/storage-patterns.md)。
|
|
23
23
|
|
|
@@ -9,7 +9,7 @@ description: Use when the user asks for general frontend code review, PR review,
|
|
|
9
9
|
|
|
10
10
|
从架构、类型安全、可访问性、样式一致性、性能和可测试性等 8 个维度审查前端代码质量,输出分级评审报告。
|
|
11
11
|
|
|
12
|
-
##
|
|
12
|
+
## Procedure
|
|
13
13
|
|
|
14
14
|
1. 先读项目事实:package scripts、框架、目录约定、最近 diff、现有测试和相关规则。
|
|
15
15
|
2. 按风险找问题,而不是按个人偏好挑风格;每个发现都要能指向具体文件、行号和用户影响。
|
|
@@ -121,10 +121,18 @@ description: Use when the user asks for general frontend code review, PR review,
|
|
|
121
121
|
- [ ] 命名语义清晰
|
|
122
122
|
- [ ] 注释覆盖复杂逻辑
|
|
123
123
|
|
|
124
|
-
##
|
|
124
|
+
## 详细参考
|
|
125
125
|
|
|
126
126
|
撰写代码评审报告时,加载 [references/report-template.md](references/report-template.md)。发现必须具体且可操作;不要写"优化性能"等空泛建议而不指出具体代码模式。
|
|
127
127
|
|
|
128
|
+
## Constraints
|
|
129
|
+
|
|
130
|
+
- 不把个人风格偏好写成阻塞问题;阻塞项必须有明确用户影响、运行时风险、安全风险或维护成本证据。
|
|
131
|
+
- 不在缺少 diff、文件位置或复现线索时给确定结论。
|
|
132
|
+
- 深度安全、无障碍、E2E 和性能问题只做初筛;需要证据链时分流到专项 skill。
|
|
133
|
+
- 同一根因不要重复报多条;合并为一条代表性发现并列出影响范围。
|
|
134
|
+
- 自动化工具稳定覆盖的格式问题交给 lint/format,不作为人工评审主发现。
|
|
135
|
+
|
|
128
136
|
## Expected Output
|
|
129
137
|
|
|
130
138
|
- 分级评审报告(CRITICAL / HIGH / MEDIUM / LOW)
|
|
@@ -1,23 +1,23 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: fec-data-fetching
|
|
3
|
-
description: Use when implementing or reviewing
|
|
3
|
+
description: Use when implementing or reviewing frontend server-state flows: typed queries, request caching, invalidation, mutations, optimistic updates, infinite queries, prefetch, SSR hydration, or API-layer integration. Do not use for local UI state or Service Worker caching; Chinese triggers include 数据获取, 缓存, 乐观更新.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
|
-
#
|
|
6
|
+
# Server State 数据获取
|
|
7
7
|
|
|
8
8
|
## Purpose
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
为前端 server state 建立清晰的数据获取、缓存、失效和提交边界,避免请求状态散落在页面组件中。
|
|
11
11
|
|
|
12
12
|
## Procedure
|
|
13
13
|
|
|
14
|
-
1. 判断状态来源:来自服务端且需要缓存、去重、刷新、分页或 mutation
|
|
15
|
-
2.
|
|
16
|
-
3. 设计稳定 query key
|
|
17
|
-
4. API
|
|
18
|
-
5. mutation 成功后 invalidation;需要即时反馈时使用 optimistic update
|
|
14
|
+
1. 判断状态来源:来自服务端且需要缓存、去重、刷新、分页或 mutation 时使用请求缓存方案;纯本地 UI 状态用组件 state 或 store。
|
|
15
|
+
2. 先沿用项目已有数据获取库;新增依赖时 React/Vue/Solid/Svelte 可考虑 TanStack Query,也可沿用 SWR、Nuxt/Nitro 数据获取或项目封装。
|
|
16
|
+
3. 设计稳定 cache key/query key:结构包含实体、动作和所有影响结果的参数。
|
|
17
|
+
4. API 函数保持纯请求函数,数据 hook/composable 负责缓存、select、loading/error/empty 状态。
|
|
18
|
+
5. mutation 成功后 invalidation;需要即时反馈时使用 optimistic update 并在失败时回滚。
|
|
19
19
|
|
|
20
|
-
## Quick Start
|
|
20
|
+
## React Quick Start
|
|
21
21
|
|
|
22
22
|
```tsx
|
|
23
23
|
import { useMutation, useQuery, useQueryClient } from "@tanstack/react-query";
|
|
@@ -45,17 +45,17 @@ export function useCreateUser() {
|
|
|
45
45
|
}
|
|
46
46
|
```
|
|
47
47
|
|
|
48
|
-
##
|
|
48
|
+
## 详细参考
|
|
49
49
|
|
|
50
|
-
|
|
50
|
+
涉及是否需要查询库、QueryClient 默认配置、Vue adapter、乐观更新、无限滚动查询、预取、SSR 水合和 API 层整合时,加载 [references/query-patterns.md](references/query-patterns.md)。
|
|
51
51
|
|
|
52
52
|
## Constraints
|
|
53
53
|
|
|
54
|
-
- 相同数据必须复用相同 query key;参数缺失会造成缓存串读。
|
|
54
|
+
- 相同数据必须复用相同 cache key/query key;参数缺失会造成缓存串读。
|
|
55
55
|
- `staleTime` 过长会显示旧数据,过短会造成频繁请求。
|
|
56
|
-
-
|
|
57
|
-
-
|
|
58
|
-
-
|
|
56
|
+
- 请求缓存库不管理本地 UI 状态;不要把 modal、输入框值放进 query cache。
|
|
57
|
+
- 乐观更新必须保存快照并在失败时回滚。
|
|
58
|
+
- SSR/SSG 场景必须使用框架支持的预取、水合或服务端数据边界。
|
|
59
59
|
|
|
60
60
|
## Expected Output
|
|
61
61
|
|
|
@@ -1,4 +1,30 @@
|
|
|
1
|
-
#
|
|
1
|
+
# Server State 数据获取模式
|
|
2
|
+
|
|
3
|
+
## 先判断是否需要查询库
|
|
4
|
+
|
|
5
|
+
- 简单静态请求、一次性提交或已有框架 loader 足够表达的页面,不必默认引入查询库。
|
|
6
|
+
- 需要跨组件缓存、去重、后台刷新、分页、乐观更新、预取或 SSR hydration 时,再使用 TanStack Query、SWR、Nuxt 数据获取或项目既有请求缓存方案。
|
|
7
|
+
- 查询库只管理 server state,不替代本地 UI 状态、表单状态、权限判断或 Service Worker 缓存。
|
|
8
|
+
|
|
9
|
+
## 选型参考
|
|
10
|
+
|
|
11
|
+
先沿用仓库已有请求层和缓存方案;新增依赖时再按框架与复杂度选择。
|
|
12
|
+
|
|
13
|
+
| 场景 | 候选方案 | 注意点 |
|
|
14
|
+
| --- | --- | --- |
|
|
15
|
+
| React server state | TanStack Query / SWR / 项目既有封装 | TanStack Query 适合 mutation、invalidation 和无限查询;SWR 适合轻量读取缓存。 |
|
|
16
|
+
| Vue server state | TanStack Query Vue adapter / VueUse / Nuxt `useFetch` / 项目既有封装 | 不要让 Vue 项目照搬 React-only hook 示例。 |
|
|
17
|
+
| Solid / Svelte / 跨框架 | TanStack Query 对应 adapter 或项目既有资源层 | cache key、staleTime、mutation 回滚原则保持一致。 |
|
|
18
|
+
| 简单页面请求 | 框架 loader、组件内轻量请求或 API composable | 仍要处理 loading/error/empty 和取消或过期响应。 |
|
|
19
|
+
| SSR / SSG | 框架预取、水合或服务端数据边界 | 确保服务端 key 与客户端 key 一致,避免重复请求和水合错配。 |
|
|
20
|
+
|
|
21
|
+
## 通用边界
|
|
22
|
+
|
|
23
|
+
- API 函数只负责请求、解析和错误归一化,不包含 UI toast、loading 或缓存逻辑。
|
|
24
|
+
- cache key/query key 必须包含所有影响响应的参数。
|
|
25
|
+
- mutation 成功后按实体或列表失效;乐观更新必须先保存快照,失败时回滚。
|
|
26
|
+
- 无限查询只处理数据分页;DOM 虚拟化由列表虚拟化流程处理。
|
|
27
|
+
- 预取要有明确用户路径或首屏收益,不为所有可能数据提前请求。
|
|
2
28
|
|
|
3
29
|
## QueryClient 默认配置
|
|
4
30
|
|
|
@@ -5,7 +5,11 @@ description: Use when diagnosing frontend build failures, runtime errors, UI ano
|
|
|
5
5
|
|
|
6
6
|
# 前端诊断框架
|
|
7
7
|
|
|
8
|
-
##
|
|
8
|
+
## Purpose
|
|
9
|
+
|
|
10
|
+
用证据驱动的分类、收集、假设、验证和修复流程定位前端故障,避免凭直觉扩大改动范围。
|
|
11
|
+
|
|
12
|
+
## Procedure
|
|
9
13
|
|
|
10
14
|
所有前端问题诊断遵循统一流程:
|
|
11
15
|
|
|
@@ -134,29 +138,20 @@ description: Use when diagnosing frontend build failures, runtime errors, UI ano
|
|
|
134
138
|
|
|
135
139
|
---
|
|
136
140
|
|
|
137
|
-
##
|
|
138
|
-
|
|
139
|
-
保存至 `reports/debug-YYYY-MM-DD-HHmmss.md`:
|
|
140
|
-
|
|
141
|
-
### 诊断报告
|
|
141
|
+
## 详细参考
|
|
142
142
|
|
|
143
|
-
|
|
144
|
-
| ---------- | -------------------------- |
|
|
145
|
-
| 问题类型 | build / runtime / ui / api |
|
|
146
|
-
| 问题描述 | 用户报告的现象 |
|
|
147
|
-
| 收集的证据 | 关键日志、截图、请求记录 |
|
|
148
|
-
| 假设与验证 | 每个假设的验证结果 |
|
|
149
|
-
| 根因 | 最终确认的根本原因 |
|
|
150
|
-
| 修复内容 | 修改的文件和具体改动 |
|
|
151
|
-
| 验证结果 | 修复后的验证命令和结果 |
|
|
152
|
-
| 剩余风险 | 未覆盖的边界或潜在回归 |
|
|
143
|
+
撰写诊断报告时,加载 [references/report-template.md](references/report-template.md)。
|
|
153
144
|
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
## 强约束
|
|
145
|
+
## Constraints
|
|
157
146
|
|
|
158
147
|
- 不在缺少证据时猜测根因
|
|
159
148
|
- 不通过关闭规则、删除测试或降低类型安全来「修复」
|
|
160
149
|
- 每次只改一个变量来验证假设
|
|
161
150
|
- 不在验证前扩大改动范围
|
|
162
151
|
- 同一假设连续 3 次验证失败,停止并报告阻塞
|
|
152
|
+
|
|
153
|
+
## Expected Output
|
|
154
|
+
|
|
155
|
+
- 诊断报告保存为 `reports/debug-YYYY-MM-DD-HHmmss.md`
|
|
156
|
+
- 报告包含问题类型、关键证据、假设验证记录、根因、修复内容、验证结果和剩余风险
|
|
157
|
+
- build/runtime/ui/api 问题均能说明复现路径、验证命令或下一步阻塞点
|
|
@@ -0,0 +1,58 @@
|
|
|
1
|
+
# 诊断报告模板
|
|
2
|
+
|
|
3
|
+
```markdown
|
|
4
|
+
# 前端诊断报告
|
|
5
|
+
|
|
6
|
+
> 生成时间: YYYY-MM-DD HH:mm
|
|
7
|
+
> 问题类型: build / runtime / ui / api
|
|
8
|
+
> 影响范围: 页面、功能、用户群或环境
|
|
9
|
+
|
|
10
|
+
## 问题描述
|
|
11
|
+
|
|
12
|
+
- 用户报告或观察到的现象
|
|
13
|
+
- 首次出现时间、环境、分支或版本
|
|
14
|
+
|
|
15
|
+
## 复现路径
|
|
16
|
+
|
|
17
|
+
1. 操作步骤或触发命令
|
|
18
|
+
2. 期望结果
|
|
19
|
+
3. 实际结果
|
|
20
|
+
|
|
21
|
+
## 收集的证据
|
|
22
|
+
|
|
23
|
+
- 日志 / stderr / console stack
|
|
24
|
+
- 截图、DOM、样式、网络请求或 trace
|
|
25
|
+
- 相关配置、依赖版本、环境变量或状态快照
|
|
26
|
+
|
|
27
|
+
## 假设与验证
|
|
28
|
+
|
|
29
|
+
| 假设 | 验证方法 | 结果 |
|
|
30
|
+
| --- | --- | --- |
|
|
31
|
+
| 因为 X,导致 Y | 通过 Z 验证 | 证实 / 证伪 / 待定 |
|
|
32
|
+
|
|
33
|
+
## 根因
|
|
34
|
+
|
|
35
|
+
- 最终确认的根本原因
|
|
36
|
+
- 为什么已有证据能支持该结论
|
|
37
|
+
|
|
38
|
+
## 修复内容
|
|
39
|
+
|
|
40
|
+
- 修改的文件和行为
|
|
41
|
+
- 为什么这是最小有效修复
|
|
42
|
+
|
|
43
|
+
## 验证结果
|
|
44
|
+
|
|
45
|
+
- 执行的命令、手工路径或浏览器验证
|
|
46
|
+
- 修复后观察到的结果
|
|
47
|
+
|
|
48
|
+
## 剩余风险
|
|
49
|
+
|
|
50
|
+
- 未覆盖的边界
|
|
51
|
+
- 可能回归的区域
|
|
52
|
+
|
|
53
|
+
## 下一步
|
|
54
|
+
|
|
55
|
+
- 需要用户决策、后续任务或监控项
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
诊断完成后,将报告保存到 `reports/debug-YYYY-MM-DD-HHmmss.md`,并告知用户报告路径。
|
|
@@ -1,37 +1,39 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: fec-doc-sync
|
|
3
|
-
description: Use when synchronizing frontend project documentation with source-of-truth files such as package.json,
|
|
3
|
+
description: Use when synchronizing frontend project documentation with source-of-truth files such as package.json, lockfiles, config, env examples, routes, API clients or server routes, schemas, components, tests, CI, build/deploy config, ADRs, changelogs, or migration notes. Do not use for general prose polishing only; Chinese triggers include 文档同步, 更新 README, docs sync, 环境变量文档, 命令清单, API 文档同步.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# 文档同步
|
|
7
7
|
|
|
8
8
|
## Purpose
|
|
9
9
|
|
|
10
|
-
|
|
10
|
+
从代码、配置、测试、类型、脚本和运行时模板同步前端项目文档,避免 README、docs、环境变量说明、API/路由说明、架构决策和迁移说明与实际项目行为漂移。
|
|
11
11
|
|
|
12
12
|
## Procedure
|
|
13
13
|
|
|
14
|
-
1.
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
5. 若变更来自依赖升级、架构决策或公共能力调整,同步轻量 ADR、变更说明、示例 prompt 和迁移注意事项。
|
|
23
|
-
6. 运行文档/元数据一致性测试或相关打包检查。
|
|
14
|
+
1. 识别项目栈、文档入口和本次需要同步的范围;README 同步必须扫描根目录 `README*`、`docs/*/README*`、包、应用、部署或运行时相关 README,并排除 `node_modules`、构建产物和第三方依赖目录。
|
|
15
|
+
2. 收集事实来源:`package.json`、lockfile、框架和构建配置、`.env.example`、路由、API clients 或 server routes、types/schemas、组件、测试、CI、build/deploy config。
|
|
16
|
+
3. 比对 README、docs、ADR、changelog、example prompts、setup/deploy/env docs 中的命令、环境变量、路由、API 行为、部署步骤和支持矩阵。
|
|
17
|
+
4. 只更新稳定的公共约定;不要把临时调试结论、一次性报告或未落地设计写入长期文档。
|
|
18
|
+
5. 若仓库已有多语言文档或国际化 README,主 README 的公共事实更新后必须检查其它语言 README 是否需要同步;功能名称、命令名、脚本名、包名、组件/API 名称、报告文件名、路径、环境变量、路由/API 名称、版本约束和支持矩阵必须跨语言一致。
|
|
19
|
+
6. 产品文案可保持本地化表达,但不得保留旧事实、旧默认推荐或过期示例;无法高质量翻译时,至少同步关键事实,并在输出中标出人工翻译风险。
|
|
20
|
+
7. 当项目暴露插件、SDK、CLI、组件库、模板或集成能力时,同步对应的功能清单、集成说明、命令/脚本说明、公开 metadata、示例提示词或示例用法。
|
|
21
|
+
8. 运行相关文档一致性、旧口径搜索、报告格式一致性、类型检查、测试、构建或打包检查。
|
|
24
22
|
|
|
25
23
|
## Constraints
|
|
26
24
|
|
|
27
25
|
- 不把 README 变成完整实现细节;公开文档保留高信号摘要。
|
|
28
|
-
-
|
|
26
|
+
- 不引入与事实来源不一致的命令、路径、环境变量、API 行为或能力名称。
|
|
27
|
+
- 不把未确认的 TODO、草案或实验能力写成已支持行为。
|
|
29
28
|
- 不修改用户项目私有文档,除非用户明确指定。
|
|
30
|
-
-
|
|
29
|
+
- 多语言文档若无法完整翻译,至少保持命令名、环境变量、路由/API 名称、版本约束和报告格式一致。
|
|
30
|
+
- 不把国际化 README 同步简化成只改主 README;公共事实、功能清单、报告清单、命令/脚本说明和示例用法必须检查所有语言入口。
|
|
31
31
|
- 不把 ADR 当作长篇复盘;只记录背景、决策、取舍、影响范围、验证和回滚线索。
|
|
32
32
|
|
|
33
33
|
## Expected Output
|
|
34
34
|
|
|
35
|
-
- README
|
|
36
|
-
-
|
|
37
|
-
-
|
|
35
|
+
- 列出已同步的 README/docs/ADR/changelog/env/setup/deploy 文档。
|
|
36
|
+
- 列出已检查的 README/docs 入口,并说明哪些语言文件已同步、哪些无需同步、哪些需要人工确认。
|
|
37
|
+
- 总结使用的事实来源、更新范围、验证命令和未覆盖风险。
|
|
38
|
+
- 汇总旧口径搜索、报告文件名/路径/命令一致性和多语言关键事实一致性验证结果。
|
|
39
|
+
- 标出仍需人工确认的产品文案、翻译、外部服务配置或发布说明。
|
|
@@ -20,10 +20,10 @@ description: Use when creating, maintaining, debugging, or reviewing real-browse
|
|
|
20
20
|
7. 对关键浏览器能力、支付、权限、上传和实时通信流程,记录测试环境、种子数据和清理策略。
|
|
21
21
|
8. 测试数据必须可重复:优先使用 API seed、数据库 fixture、测试账号或 mock 服务;随机数据需带唯一前缀并在 teardown 清理。
|
|
22
22
|
|
|
23
|
-
##
|
|
23
|
+
## 详细参考
|
|
24
24
|
|
|
25
|
-
-
|
|
26
|
-
-
|
|
25
|
+
- 需要目录结构、Page Object、spec 组织、配置、flaky 调试和产物示例时,加载 [references/playwright-patterns.md](references/playwright-patterns.md)。
|
|
26
|
+
- 需要 CI 示例、Markdown 报告模板、Web3/钱包流程、高风险金融流程或视觉回归配置时,加载 [references/e2e-advanced.md](references/e2e-advanced.md)。
|
|
27
27
|
|
|
28
28
|
## Constraints
|
|
29
29
|
|
|
@@ -11,13 +11,13 @@ description: Use when building or reviewing substantial forms with React Hook Fo
|
|
|
11
11
|
|
|
12
12
|
## Procedure
|
|
13
13
|
|
|
14
|
-
1.
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
4.
|
|
14
|
+
1. 先识别框架、项目既有表单库、schema 校验库、组件库和复杂度;10+ 字段、动态字段、联动校验、文件上传、多步流程或输入卡顿时再引入专门表单方案。
|
|
15
|
+
2. 按项目栈选型:React 可考虑 React Hook Form + Zod;Vue 可考虑 vee-validate / FormKit + Zod、Yup 或 Valibot;简单表单可用框架原生状态和基础校验。
|
|
16
|
+
3. 用运行时 schema 或明确校验函数守住外部输入边界;TypeScript 类型可从 schema 推导,但不要只写 TS 类型。
|
|
17
|
+
4. 明确默认值、字段注册、受控/非受控边界和组件库适配;错误提示用 `aria-invalid`、`aria-describedby` 和 `role="alert"`。
|
|
18
18
|
5. 提交时处理 loading、服务端错误、重复提交和 reset;大型表单用局部订阅和子组件隔离控制重渲染。
|
|
19
19
|
|
|
20
|
-
## Quick Start
|
|
20
|
+
## React Quick Start
|
|
21
21
|
|
|
22
22
|
```tsx
|
|
23
23
|
import { zodResolver } from "@hookform/resolvers/zod";
|
|
@@ -59,17 +59,17 @@ export function LoginFormView() {
|
|
|
59
59
|
}
|
|
60
60
|
```
|
|
61
61
|
|
|
62
|
-
##
|
|
62
|
+
## 详细参考
|
|
63
63
|
|
|
64
|
-
|
|
64
|
+
涉及是否需要表单库、框架选型、`Controller`、`useFieldArray`、联动校验、文件上传、多步表单、异步校验和性能模式时,加载 [references/advanced-form-patterns.md](references/advanced-form-patterns.md)。
|
|
65
65
|
|
|
66
66
|
## Constraints
|
|
67
67
|
|
|
68
|
-
-
|
|
69
|
-
-
|
|
70
|
-
-
|
|
68
|
+
- 沿用仓库既有表单库、schema 库和组件库适配方式,不为单个表单引入第二套体系。
|
|
69
|
+
- 默认值必须完整,避免 undefined 触发受控/非受控警告或初始化抖动。
|
|
70
|
+
- reset 应传服务器返回或明确的完整默认对象。
|
|
71
71
|
- 异步校验必须 debounce 或放到提交边界,避免每次键入请求。
|
|
72
|
-
-
|
|
72
|
+
- schema 级联动校验的错误 path 必须指向实际字段。
|
|
73
73
|
|
|
74
74
|
## Expected Output
|
|
75
75
|
|