create-dwy 0.4.0 → 0.5.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/package.json
CHANGED
package/src/sync.js
CHANGED
|
@@ -28,6 +28,14 @@ export async function syncClaude() {
|
|
|
28
28
|
}
|
|
29
29
|
}
|
|
30
30
|
|
|
31
|
+
// Sync CLAUDE.md
|
|
32
|
+
const claudeMdSrc = path.join(sourceDir, 'CLAUDE.md')
|
|
33
|
+
if (await fs.pathExists(claudeMdSrc)) {
|
|
34
|
+
await fs.copy(claudeMdSrc, path.join(targetDir, 'CLAUDE.md'))
|
|
35
|
+
syncedCount++
|
|
36
|
+
console.log(chalk.green(' ✓ CLAUDE.md'))
|
|
37
|
+
}
|
|
38
|
+
|
|
31
39
|
const settingsSrc = path.join(sourceDir, 'settings.json')
|
|
32
40
|
if (await fs.pathExists(settingsSrc)) {
|
|
33
41
|
const settingsDest = path.join(targetDir, 'settings.json')
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
所有回答必须使用中文。
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# 优先使用成熟开源方案
|
|
2
|
+
|
|
3
|
+
开发新功能时，优先选用成熟的开源项目/库，而不是手写实现。只有在确认没有合适的开源方案时，才自行实现。
|
|
4
|
+
|
|
5
|
+
## 决策流程
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
需要某项功能
|
|
9
|
+
→ 1. 搜索是否有成熟的开源库（npm/PyPI/GitHub stars > 1k、近期有维护）
|
|
10
|
+
→ 有：评估是否适配当前技术栈（Vue 3 / FastAPI / Node.js）
|
|
11
|
+
→ 适配：直接使用，不重复造轮子
|
|
12
|
+
→ 不适配：寻找替代方案
|
|
13
|
+
→ 没有合适的：自行实现，但在代码注释中说明为什么没用现成方案
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## 强制规则
|
|
17
|
+
|
|
18
|
+
- **禁止**手写已有成熟方案的功能：日期处理(dayjs/date-fns)、HTTP 请求(axios)、表单校验(zod/vee-validate)、状态管理(pinia)、图表(echarts/chart.js)、富文本(tiptap/quill)、拖拽(vuedraggable/dnd-kit)、虚拟滚动(@tanstack/virtual)、Markdown 渲染(markdown-it)、模糊搜索(fuse.js)
|
|
19
|
+
- **禁止**手写加密/哈希/JWT 算法，必须使用 bcrypt/jose/crypto 等标准库
|
|
20
|
+
- 选用开源库时，优先选择：项目已在用的依赖 > 社区主流方案 > 小众但适合的方案
|
|
21
|
+
|
|
22
|
+
## 例外情况
|
|
23
|
+
|
|
24
|
+
以下情况允许自行实现：
|
|
25
|
+
- 功能极其简单（< 20 行），引入一个库反而增加复杂度
|
|
26
|
+
- 开源库有严重的安全漏洞或已停止维护
|
|
27
|
+
- 开源库的依赖体积过大，与需求不成比例
|
|
28
|
+
- 项目有特殊定制需求，开源库无法满足且改造成本高于自建
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dwy-dev-qa
|
|
3
|
+
description: "功能开发完成后的通用质量保障流程。触发条件：完成新功能、修复 bug、重构代码后，准备提交前。"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# 开发完成后质量保障流程
|
|
7
|
+
|
|
8
|
+
功能开发完成后，按以下 9 步流程逐步执行。**不可跳步，不可调换顺序。**
|
|
9
|
+
|
|
10
|
+
## 流程总览
|
|
11
|
+
|
|
12
|
+
```
|
|
13
|
+
功能完成 → 构建验证 → 写测试 → 跑测试 → Code Review → 修复问题 → 性能优化 → 文档同步 → 集成测试 → 输出报告
|
|
14
|
+
```
|
|
15
|
+
|
|
16
|
+
## 第 1 步：构建验证
|
|
17
|
+
|
|
18
|
+
确认代码能编译通过，没有语法错误或类型错误。
|
|
19
|
+
|
|
20
|
+
执行项目的构建命令（查看 `package.json` scripts 或 `Makefile` 确定具体命令）。
|
|
21
|
+
|
|
22
|
+
**不通过 → 修复编译错误，不进入下一步。**
|
|
23
|
+
|
|
24
|
+
## 第 2 步：编写测试用例
|
|
25
|
+
|
|
26
|
+
为本次新增/修改的代码编写测试：
|
|
27
|
+
|
|
28
|
+
- 新组件/模块：至少覆盖核心功能、关键输入输出
|
|
29
|
+
- 新函数：覆盖正常输入、边界条件、异常输入
|
|
30
|
+
- Bug 修复：先写复现 bug 的测试用例，确认失败，再确认修复后通过
|
|
31
|
+
- 只测新增/修改的部分，不给未改动的代码补测试
|
|
32
|
+
|
|
33
|
+
## 第 3 步：运行测试
|
|
34
|
+
|
|
35
|
+
执行项目的测试命令，确认所有测试通过。
|
|
36
|
+
|
|
37
|
+
**有失败 → 修复代码或测试，不进入下一步。**
|
|
38
|
+
|
|
39
|
+
## 第 4 步：Code Review
|
|
40
|
+
|
|
41
|
+
审查本次所有变更（代码 + 测试），检查：
|
|
42
|
+
|
|
43
|
+
- [ ] 逻辑正确性：边界条件、竞态风险、空值处理
|
|
44
|
+
- [ ] 安全性：XSS、注入、硬编码凭证、敏感数据泄露
|
|
45
|
+
- [ ] 向后兼容：已有 API 是否被破坏（参数重命名/删除、返回值结构变更）
|
|
46
|
+
- [ ] 代码风格：是否符合项目规范
|
|
47
|
+
- [ ] 测试质量：测试是否真正验证了功能
|
|
48
|
+
|
|
49
|
+
输出 Review 问题清单。
|
|
50
|
+
|
|
51
|
+
## 第 5 步：修复 Review 问题
|
|
52
|
+
|
|
53
|
+
逐条修复第 4 步发现的问题。每修一条，跑相关测试确认无回归。
|
|
54
|
+
|
|
55
|
+
**有未修复的问题 → 不进入下一步。**
|
|
56
|
+
|
|
57
|
+
## 第 6 步：性能优化
|
|
58
|
+
|
|
59
|
+
审查本次变更的性能影响：
|
|
60
|
+
|
|
61
|
+
- [ ] 是否有不必要的重复计算或重复请求
|
|
62
|
+
- [ ] 是否有大数据集缺少分页、虚拟滚动或懒加载
|
|
63
|
+
- [ ] 是否有 N+1 查询或缺少索引
|
|
64
|
+
- [ ] 是否有不必要的深拷贝或大对象序列化
|
|
65
|
+
- [ ] 前端：是否有不必要的重渲染或未做 memo/computed 优化
|
|
66
|
+
|
|
67
|
+
发现优化点：
|
|
68
|
+
1. 实施优化
|
|
69
|
+
2. 跑测试确认无回归
|
|
70
|
+
3. 如果发现了通用的性能规范不在项目文档中，更新 CLAUDE.md 或 rules
|
|
71
|
+
|
|
72
|
+
## 第 7 步：文档同步
|
|
73
|
+
|
|
74
|
+
检查以下文档是否需要更新：
|
|
75
|
+
|
|
76
|
+
- [ ] **API 文档 / Skills** — 新增或修改了对外接口？更新对应文档
|
|
77
|
+
- [ ] **示例 / Demo** — 新增了用户可感知的功能？补充示例
|
|
78
|
+
- [ ] **项目 CLAUDE.md** — 模块结构、命令、架构发生变化？更新
|
|
79
|
+
- [ ] **导航 / 索引** — 新增了页面或模块？注册到路由和导航
|
|
80
|
+
|
|
81
|
+
如果项目有专门的文档检查 skill（如 `dwy-docs-check`），调用它自动执行。
|
|
82
|
+
|
|
83
|
+
## 第 8 步：集成测试
|
|
84
|
+
|
|
85
|
+
运行全量测试套件 + 构建验证，确认无回归。
|
|
86
|
+
|
|
87
|
+
**任何失败 → 回到第 5 步修复。**
|
|
88
|
+
|
|
89
|
+
## 第 9 步：输出报告
|
|
90
|
+
|
|
91
|
+
向用户输出以下报告，等待审查确认后才能 commit：
|
|
92
|
+
|
|
93
|
+
```
|
|
94
|
+
## 质量保障报告
|
|
95
|
+
|
|
96
|
+
### 变更概要
|
|
97
|
+
- 涉及文件：X 个
|
|
98
|
+
- 新增/修改行数：+X / -X
|
|
99
|
+
|
|
100
|
+
### 测试结果
|
|
101
|
+
- 单元测试：X 通过 / X 失败
|
|
102
|
+
- 集成测试：全量 X 用例通过
|
|
103
|
+
|
|
104
|
+
### Code Review
|
|
105
|
+
- 发现问题：X 条
|
|
106
|
+
- 已修复：X 条
|
|
107
|
+
- 遗留：0 条
|
|
108
|
+
|
|
109
|
+
### 性能优化
|
|
110
|
+
- 优化项：（具体优化点，或"无需优化"）
|
|
111
|
+
|
|
112
|
+
### 文档同步
|
|
113
|
+
- 更新了：（文件列表，或"无需更新"）
|
|
114
|
+
|
|
115
|
+
### 待用户确认
|
|
116
|
+
- [ ] 确认可以提交
|
|
117
|
+
```
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# 文档同步规则
|
|
2
|
-
|
|
3
|
-
代码变更时，必须同步更新所有关联文档。不允许只改代码不更新文档。
|
|
4
|
-
|
|
5
|
-
## 核心原则
|
|
6
|
-
|
|
7
|
-
**代码和文档是一个整体。** 如果一次变更修改了对外可见的 API（props、函数签名、导出类型、命令行参数等），那么描述该 API 的文档必须在同一个 commit 中更新。
|
|
8
|
-
|
|
9
|
-
## 检查清单
|
|
10
|
-
|
|
11
|
-
完成代码变更后，逐项确认：
|
|
12
|
-
|
|
13
|
-
1. **Skills / 速查文档** — 是否有 SKILL.md 或类似的 AI 速查文档描述了被修改的 API？如果有，更新对应条目。
|
|
14
|
-
2. **示例 / Demo 页面** — 新增的功能是否有对应的交互演示？如果没有，补充 demo。
|
|
15
|
-
3. **导航 / 搜索索引** — 新增的页面或组件是否已注册到路由、侧边栏、搜索索引？
|
|
16
|
-
4. **项目 CLAUDE.md** — 模块结构（新增/删除/重命名包或模块）、构建命令、测试命令是否变化？如果是，更新 CLAUDE.md。
|
|
17
|
-
5. **版本号** — 变更是否对外可见？如果是，更新 package.json / pyproject.toml 版本号。
|
|
18
|
-
|
|
19
|
-
## 提交规范
|
|
20
|
-
|
|
21
|
-
- 文档更新应与代码变更在**同一个 commit** 中
|
|
22
|
-
- 遗漏后发现，立即补一个 `docs: sync xxx` 的 commit
|
|
23
|
-
- 纯文档更新用 `docs:` 前缀，代码+文档混合用 `feat:` / `fix:`
|