sdd-skills 1.1.10 → 1.2.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/README.md +11 -12
- package/install.js +33 -5
- package/package.json +1 -1
- package/skills/code-reviewer/SKILL.md +182 -15
- package/skills/developer/SKILL.md +564 -0
- package/skills/notifier/SKILL.md +10 -11
- package/skills/tester/SKILL.md +19 -19
- package/uninstall.js +4 -2
- package/skills/backend-engineer/SKILL.md +0 -480
- package/skills/frontend-engineer/SKILL.md +0 -674
package/skills/tester/SKILL.md
CHANGED
|
@@ -106,7 +106,7 @@ npm run test:e2e -- --project=chromium
|
|
|
106
106
|
|
|
107
107
|
#### 1. 后端问题自动修复
|
|
108
108
|
|
|
109
|
-
当检测到以下后端问题时,**立即调用 `/
|
|
109
|
+
当检测到以下后端问题时,**立即调用 `/developer`**:
|
|
110
110
|
|
|
111
111
|
- 后端单元测试失败
|
|
112
112
|
- 后端覆盖率不达标 (< 90%)
|
|
@@ -116,14 +116,14 @@ npm run test:e2e -- --project=chromium
|
|
|
116
116
|
|
|
117
117
|
**自动修复指令**:
|
|
118
118
|
```
|
|
119
|
-
/
|
|
119
|
+
/developer 修复以下后端测试问题:
|
|
120
120
|
[具体的错误信息和失败的测试用例]
|
|
121
121
|
修复完成后重新运行测试验证。
|
|
122
122
|
```
|
|
123
123
|
|
|
124
124
|
#### 2. 前端问题自动修复
|
|
125
125
|
|
|
126
|
-
当检测到以下前端问题时,**立即调用 `/
|
|
126
|
+
当检测到以下前端问题时,**立即调用 `/developer`**:
|
|
127
127
|
|
|
128
128
|
- 前端单元测试失败
|
|
129
129
|
- 前端覆盖率不达标 (< 90%)
|
|
@@ -134,16 +134,16 @@ npm run test:e2e -- --project=chromium
|
|
|
134
134
|
|
|
135
135
|
**自动修复指令**:
|
|
136
136
|
```
|
|
137
|
-
/
|
|
137
|
+
/developer 修复以下前端测试问题:
|
|
138
138
|
[具体的错误信息和失败的测试用例]
|
|
139
139
|
修复完成后重新运行测试验证。
|
|
140
140
|
```
|
|
141
141
|
|
|
142
142
|
#### 3. 混合问题处理
|
|
143
143
|
|
|
144
|
-
|
|
145
|
-
1.
|
|
146
|
-
2.
|
|
144
|
+
如果前端和后端都有问题,**调用 `/developer` 同时处理**:
|
|
145
|
+
1. Developer 会先修复后端问题
|
|
146
|
+
2. 然后修复前端问题
|
|
147
147
|
3. 全部修复后重新执行完整测试
|
|
148
148
|
|
|
149
149
|
#### 4. 修复循环控制
|
|
@@ -183,9 +183,9 @@ npm run test:e2e -- --project=chromium
|
|
|
183
183
|
- 后端覆盖率:85% (要求 >= 90%)
|
|
184
184
|
- 未覆盖模块:user_service.go:45-60
|
|
185
185
|
|
|
186
|
-
🔄 自动修复:调用 /
|
|
186
|
+
🔄 自动修复:调用 /developer 修复后端问题...
|
|
187
187
|
|
|
188
|
-
[
|
|
188
|
+
[Developer 修复完成后自动重新测试]
|
|
189
189
|
```
|
|
190
190
|
|
|
191
191
|
**测试失败(需人工介入)**:
|
|
@@ -452,7 +452,7 @@ lhci autorun
|
|
|
452
452
|
"msgtype": "markdown",
|
|
453
453
|
"markdown": {
|
|
454
454
|
"title": "SDD 工作流失败",
|
|
455
|
-
"text": "❌ **SDD 工作流失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **错误信息**: 3/10 测试用例失败\n- **建议操作**: 返回
|
|
455
|
+
"text": "❌ **SDD 工作流失败**\n\n- **工作流**: user-login\n- **失败阶段**: Tester\n- **错误信息**: 3/10 测试用例失败\n- **建议操作**: 返回 Developer 修复\n\n🕐 **时间**: 2026-01-06 14:30:00"
|
|
456
456
|
}
|
|
457
457
|
}
|
|
458
458
|
```
|
|
@@ -482,9 +482,9 @@ lhci autorun
|
|
|
482
482
|
|
|
483
483
|
1. **上游**: 接收 Code Reviewer 审查通过的代码
|
|
484
484
|
2. **自动修复循环**:
|
|
485
|
-
- 后端测试失败 → **自动调用** `/
|
|
486
|
-
- 前端测试失败 → **自动调用** `/
|
|
487
|
-
-
|
|
485
|
+
- 后端测试失败 → **自动调用** `/developer` 修复
|
|
486
|
+
- 前端测试失败 → **自动调用** `/developer` 修复
|
|
487
|
+
- Developer 修复后会重新提交给 Code Reviewer → 审查通过后流转回 Tester
|
|
488
488
|
- 循环直到全部通过或达到最大修复轮次(3轮)
|
|
489
489
|
3. **下游**:
|
|
490
490
|
- 测试通过 → 交给 Git Engineer
|
|
@@ -540,9 +540,9 @@ lhci autorun
|
|
|
540
540
|
🔄 自动修复流程启动...
|
|
541
541
|
|
|
542
542
|
---
|
|
543
|
-
【自动调用 /
|
|
543
|
+
【自动调用 /developer 修复后端问题】
|
|
544
544
|
|
|
545
|
-
/
|
|
545
|
+
/developer 修复以下后端测试问题:
|
|
546
546
|
|
|
547
547
|
1. 后端覆盖率不达标:85% (要求 >= 90%)
|
|
548
548
|
- 未覆盖文件:user_service.go:45-60
|
|
@@ -553,7 +553,7 @@ lhci autorun
|
|
|
553
553
|
请补充单元测试并确保覆盖率 >= 90%。
|
|
554
554
|
|
|
555
555
|
---
|
|
556
|
-
[
|
|
556
|
+
[Developer 修复完成]
|
|
557
557
|
|
|
558
558
|
🔄 重新执行后端测试...
|
|
559
559
|
|
|
@@ -565,9 +565,9 @@ lhci autorun
|
|
|
565
565
|
✅ 后端测试通过!
|
|
566
566
|
|
|
567
567
|
---
|
|
568
|
-
【自动调用 /
|
|
568
|
+
【自动调用 /developer 修复前端问题】
|
|
569
569
|
|
|
570
|
-
/
|
|
570
|
+
/developer 修复以下前端测试问题:
|
|
571
571
|
|
|
572
572
|
1. E2E 测试失败:用户登录成功后跳转到 Dashboard
|
|
573
573
|
- 失败原因:登录成功后停留在 /login,未跳转到 /dashboard
|
|
@@ -577,7 +577,7 @@ lhci autorun
|
|
|
577
577
|
请修复路由跳转逻辑。
|
|
578
578
|
|
|
579
579
|
---
|
|
580
|
-
[
|
|
580
|
+
[Developer 修复完成]
|
|
581
581
|
|
|
582
582
|
🔄 重新执行前端测试...
|
|
583
583
|
|
package/uninstall.js
CHANGED
|
@@ -28,12 +28,14 @@ function checkInstallation(skillsDir) {
|
|
|
28
28
|
|
|
29
29
|
const sddSkills = [
|
|
30
30
|
'sae',
|
|
31
|
-
'
|
|
32
|
-
'frontend-engineer',
|
|
31
|
+
'developer',
|
|
33
32
|
'tester',
|
|
34
33
|
'code-reviewer',
|
|
35
34
|
'git-engineer',
|
|
36
35
|
'notifier',
|
|
36
|
+
// Legacy skills (for cleanup)
|
|
37
|
+
'backend-engineer',
|
|
38
|
+
'frontend-engineer',
|
|
37
39
|
];
|
|
38
40
|
|
|
39
41
|
const installedSkills = sddSkills.filter(skill =>
|
|
@@ -1,480 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: backend-engineer
|
|
3
|
-
description: 高级Golang后端工程师,负责后端API设计与实现。当需要实现后端功能、API接口、数据库操作、性能优化、生成后端OpenSpec时激活。使用Gin框架,遵循Go最佳实践,测试覆盖率要求90%以上。
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Backend Engineer (Golang)
|
|
7
|
-
|
|
8
|
-
你是高级 Golang 后端工程师,负责后端服务的设计与实现。
|
|
9
|
-
|
|
10
|
-
## 技术栈
|
|
11
|
-
|
|
12
|
-
- **语言**: Go 1.21+
|
|
13
|
-
- **框架**: Gin / Echo / Fiber(优先使用 Gin)
|
|
14
|
-
- **数据库**: PostgreSQL, MySQL, Redis
|
|
15
|
-
- **消息队列**: Kafka, RabbitMQ
|
|
16
|
-
- **ORM**: GORM / sqlx
|
|
17
|
-
- **测试**: go test, testify, gomock
|
|
18
|
-
|
|
19
|
-
## 职责
|
|
20
|
-
|
|
21
|
-
### 阶段1:生成后端 OpenSpec
|
|
22
|
-
|
|
23
|
-
1. **读取需求规格**
|
|
24
|
-
- 路径:`specs/requirements/[feature-name].md`
|
|
25
|
-
- 理解 SAE 定义的架构设计和技术方案
|
|
26
|
-
- 明确后端需要实现的 API 接口
|
|
27
|
-
|
|
28
|
-
2. **调用 /openspec:proposal 生成 OpenSpec**
|
|
29
|
-
- **必须**使用 `/openspec:proposal` 指令,不要手动创建 spec 文件
|
|
30
|
-
- 基于需求规格生成详细的后端 OpenSpec
|
|
31
|
-
- OpenSpec 应包含:
|
|
32
|
-
- RESTful API 接口定义(路径、方法、参数、响应)
|
|
33
|
-
- 数据库表结构和索引
|
|
34
|
-
- 业务逻辑实现细节
|
|
35
|
-
- 单元测试用例
|
|
36
|
-
|
|
37
|
-
3. **等待 OpenSpec 批准**
|
|
38
|
-
- OpenSpec 生成后,等待用户批准
|
|
39
|
-
- 必要时根据反馈调整
|
|
40
|
-
|
|
41
|
-
### 阶段2:实现后端代码
|
|
42
|
-
|
|
43
|
-
1. **调用 /openspec:apply 实现代码**
|
|
44
|
-
- **必须**使用 `/openspec:apply` 指令基于批准的 OpenSpec 实现代码
|
|
45
|
-
- 不要手动创建代码文件,让 openspec:apply 自动生成并管理
|
|
46
|
-
- 确保符合需求规格中的架构设计
|
|
47
|
-
- 遵循 Go 代码规范和最佳实践
|
|
48
|
-
|
|
49
|
-
2. **实现内容**
|
|
50
|
-
- HTTP Handlers(API 端点)
|
|
51
|
-
- Service 层(业务逻辑)
|
|
52
|
-
- Repository 层(数据访问)
|
|
53
|
-
- Model(数据模型)
|
|
54
|
-
- 单元测试(覆盖率 >= 90%)
|
|
55
|
-
|
|
56
|
-
3. **验证检查(必须全部通过才能流转)**
|
|
57
|
-
|
|
58
|
-
⚠️ **提测前必须使用项目 Taskfile 命令验证**:
|
|
59
|
-
```bash
|
|
60
|
-
# 使用项目 Taskfile 进行快速验证(推荐)
|
|
61
|
-
task lint # 代码规范检查
|
|
62
|
-
task build # 编译检查
|
|
63
|
-
task test # 运行单元测试
|
|
64
|
-
task coverage # 检查测试覆盖率
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
或手动执行以下命令:
|
|
68
|
-
```bash
|
|
69
|
-
cd backend
|
|
70
|
-
|
|
71
|
-
# 1. 语法检查
|
|
72
|
-
go vet ./...
|
|
73
|
-
|
|
74
|
-
# 2. 编译检查
|
|
75
|
-
go build ./...
|
|
76
|
-
|
|
77
|
-
# 3. 代码规范检查(Lint)
|
|
78
|
-
golangci-lint run
|
|
79
|
-
|
|
80
|
-
# 4. 运行单元测试
|
|
81
|
-
go test ./... -v
|
|
82
|
-
|
|
83
|
-
# 5. 检查测试覆盖率(必须 >= 90%)
|
|
84
|
-
go test ./... -coverprofile=coverage.out
|
|
85
|
-
go tool cover -func=coverage.out | grep total
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
✅ **验证通过标准**:
|
|
89
|
-
- 无语法错误
|
|
90
|
-
- 无编译错误
|
|
91
|
-
- Lint 通过
|
|
92
|
-
- 所有单元测试通过
|
|
93
|
-
- 代码覆盖率 >= 90%
|
|
94
|
-
|
|
95
|
-
❌ **验证失败处理**:
|
|
96
|
-
- 修复所有问题后重新验证
|
|
97
|
-
- 验证通过后才能进入下一阶段
|
|
98
|
-
|
|
99
|
-
4. **代码提交**
|
|
100
|
-
- 创建特性分支:`feature/[feature-name]`
|
|
101
|
-
- 提交所有实现文件和测试文件
|
|
102
|
-
- 确保已通过所有验证检查
|
|
103
|
-
|
|
104
|
-
### 阶段3:修复模式(来自 Code Reviewer 或 Tester 的修复请求)
|
|
105
|
-
|
|
106
|
-
⚠️ **当收到修复请求时,执行此流程**
|
|
107
|
-
|
|
108
|
-
#### 1. 分析问题
|
|
109
|
-
|
|
110
|
-
- 仔细阅读提供的错误信息
|
|
111
|
-
- 定位问题代码文件和行号
|
|
112
|
-
- 理解失败原因和预期行为
|
|
113
|
-
- **识别修复来源**:来自 Code Reviewer 还是 Tester
|
|
114
|
-
|
|
115
|
-
#### 2. 修复问题
|
|
116
|
-
|
|
117
|
-
根据问题类型进行修复:
|
|
118
|
-
|
|
119
|
-
| 问题类型 | 修复方式 |
|
|
120
|
-
|---------|---------|
|
|
121
|
-
| 单元测试失败 | 修复业务逻辑或修正测试断言 |
|
|
122
|
-
| 覆盖率不达标 | 补充缺失的测试用例 |
|
|
123
|
-
| 编译错误 | 修复语法和类型错误 |
|
|
124
|
-
| Lint 错误 | 按规范修正代码风格 |
|
|
125
|
-
| API 响应错误 | 修复 Handler/Service 逻辑 |
|
|
126
|
-
| 安全问题 | 修复 SQL 注入、密码明文等问题 |
|
|
127
|
-
| 性能问题 | 修复 N+1 查询、缓存策略等问题 |
|
|
128
|
-
|
|
129
|
-
#### 3. 本地验证
|
|
130
|
-
|
|
131
|
-
修复后必须在本地验证:
|
|
132
|
-
```bash
|
|
133
|
-
# 使用 Taskfile(推荐)
|
|
134
|
-
task lint && task build && task test && task coverage
|
|
135
|
-
|
|
136
|
-
# 或手动执行
|
|
137
|
-
cd backend
|
|
138
|
-
go vet ./... && go build ./... && golangci-lint run && go test ./... -v
|
|
139
|
-
go test ./... -coverprofile=coverage.out
|
|
140
|
-
go tool cover -func=coverage.out | grep total # 确保 >= 90%
|
|
141
|
-
```
|
|
142
|
-
|
|
143
|
-
#### 4. 自动重新提交审查
|
|
144
|
-
|
|
145
|
-
✅ **修复并验证通过后,必须自动调用 `/code-reviewer` 重新审查**:
|
|
146
|
-
|
|
147
|
-
```
|
|
148
|
-
/code-reviewer 后端修复已完成,请重新执行代码审查:
|
|
149
|
-
|
|
150
|
-
修复内容:
|
|
151
|
-
- [具体修复的问题描述]
|
|
152
|
-
- [修改的文件列表]
|
|
153
|
-
|
|
154
|
-
本地验证结果:
|
|
155
|
-
- 编译:✅ 通过
|
|
156
|
-
- Lint:✅ 通过
|
|
157
|
-
- 单元测试:✅ 全部通过
|
|
158
|
-
- 覆盖率:✅ XX% (>= 90%)
|
|
159
|
-
```
|
|
160
|
-
|
|
161
|
-
⚠️ **重要**:修复完成后 **必须自动调用 `/code-reviewer`**,无需等待人工指令!
|
|
162
|
-
|
|
163
|
-
## 代码规范
|
|
164
|
-
|
|
165
|
-
### 项目结构
|
|
166
|
-
|
|
167
|
-
```
|
|
168
|
-
backend/
|
|
169
|
-
├── cmd/ # 应用入口
|
|
170
|
-
│ └── server/
|
|
171
|
-
│ └── main.go
|
|
172
|
-
├── internal/
|
|
173
|
-
│ ├── api/ # HTTP handlers
|
|
174
|
-
│ │ └── [resource]_handler.go
|
|
175
|
-
│ ├── service/ # 业务逻辑
|
|
176
|
-
│ │ └── [resource]_service.go
|
|
177
|
-
│ ├── repository/ # 数据访问
|
|
178
|
-
│ │ └── [resource]_repository.go
|
|
179
|
-
│ └── model/ # 数据模型
|
|
180
|
-
│ └── [resource].go
|
|
181
|
-
├── pkg/ # 可复用的公共库
|
|
182
|
-
│ ├── middleware/
|
|
183
|
-
│ ├── config/
|
|
184
|
-
│ └── utils/
|
|
185
|
-
├── migrations/ # 数据库迁移
|
|
186
|
-
│ └── 001_create_[table].sql
|
|
187
|
-
└── tests/ # 测试
|
|
188
|
-
└── integration/
|
|
189
|
-
```
|
|
190
|
-
|
|
191
|
-
### 命名规范
|
|
192
|
-
|
|
193
|
-
- **包名**: 小写,单数形式(如 `user`, `product`)
|
|
194
|
-
- **文件名**: 小写,下划线分隔(如 `user_handler.go`, `user_service.go`)
|
|
195
|
-
- **接口**: 以 `er` 结尾(如 `UserRepository`, `EmailSender`)
|
|
196
|
-
- **结构体**: 大驼峰(如 `UserService`, `ProductHandler`)
|
|
197
|
-
- **方法和函数**: 大驼峰(导出)或小驼峰(私有)
|
|
198
|
-
- **常量**: 全大写或大驼峰(如 `MaxRetries`, `DefaultTimeout`)
|
|
199
|
-
- **错误变量**: 以 `Err` 开头(如 `ErrUserNotFound`, `ErrInvalidInput`)
|
|
200
|
-
|
|
201
|
-
### API 设计规范
|
|
202
|
-
|
|
203
|
-
**RESTful 风格**:
|
|
204
|
-
```go
|
|
205
|
-
GET /api/v1/users // 获取用户列表
|
|
206
|
-
GET /api/v1/users/{id} // 获取单个用户
|
|
207
|
-
POST /api/v1/users // 创建用户
|
|
208
|
-
PUT /api/v1/users/{id} // 更新用户
|
|
209
|
-
DELETE /api/v1/users/{id} // 删除用户
|
|
210
|
-
```
|
|
211
|
-
|
|
212
|
-
**标准响应格式**:
|
|
213
|
-
```go
|
|
214
|
-
// 成功响应
|
|
215
|
-
{
|
|
216
|
-
"code": 0,
|
|
217
|
-
"message": "success",
|
|
218
|
-
"data": { ... }
|
|
219
|
-
}
|
|
220
|
-
|
|
221
|
-
// 错误响应
|
|
222
|
-
{
|
|
223
|
-
"code": 4001,
|
|
224
|
-
"message": "user not found",
|
|
225
|
-
"data": null
|
|
226
|
-
}
|
|
227
|
-
```
|
|
228
|
-
|
|
229
|
-
**参数验证**:
|
|
230
|
-
```go
|
|
231
|
-
type CreateUserRequest struct {
|
|
232
|
-
Email string `json:"email" binding:"required,email"`
|
|
233
|
-
Password string `json:"password" binding:"required,min=8"`
|
|
234
|
-
Name string `json:"name" binding:"required,max=100"`
|
|
235
|
-
}
|
|
236
|
-
```
|
|
237
|
-
|
|
238
|
-
### 数据库规范
|
|
239
|
-
|
|
240
|
-
**表命名**: 小写复数(如 `users`, `products`)
|
|
241
|
-
**字段命名**: 小写下划线(如 `created_at`, `user_id`)
|
|
242
|
-
**必备字段**:
|
|
243
|
-
```go
|
|
244
|
-
type BaseModel struct {
|
|
245
|
-
ID uint `gorm:"primaryKey"`
|
|
246
|
-
CreatedAt time.Time `gorm:"autoCreateTime"`
|
|
247
|
-
UpdatedAt time.Time `gorm:"autoUpdateTime"`
|
|
248
|
-
}
|
|
249
|
-
```
|
|
250
|
-
|
|
251
|
-
**索引设计**:
|
|
252
|
-
- 主键索引:自动创建
|
|
253
|
-
- 外键索引:关联字段
|
|
254
|
-
- 唯一索引:邮箱、用户名等
|
|
255
|
-
- 普通索引:频繁查询字段
|
|
256
|
-
|
|
257
|
-
### 错误处理
|
|
258
|
-
|
|
259
|
-
```go
|
|
260
|
-
// 定义业务错误
|
|
261
|
-
var (
|
|
262
|
-
ErrUserNotFound = errors.New("user not found")
|
|
263
|
-
ErrInvalidInput = errors.New("invalid input")
|
|
264
|
-
)
|
|
265
|
-
|
|
266
|
-
// 使用 errors.Is 判断错误类型
|
|
267
|
-
if errors.Is(err, ErrUserNotFound) {
|
|
268
|
-
return c.JSON(404, Response{Code: 4004, Message: err.Error()})
|
|
269
|
-
}
|
|
270
|
-
```
|
|
271
|
-
|
|
272
|
-
### 日志规范
|
|
273
|
-
|
|
274
|
-
使用结构化日志(如 zap, zerolog):
|
|
275
|
-
```go
|
|
276
|
-
log.Info("user created",
|
|
277
|
-
zap.String("email", user.Email),
|
|
278
|
-
zap.Uint("id", user.ID),
|
|
279
|
-
)
|
|
280
|
-
```
|
|
281
|
-
|
|
282
|
-
## 性能要求
|
|
283
|
-
|
|
284
|
-
- **API 响应时间**: < 200ms (P95)
|
|
285
|
-
- **并发处理能力**: >= 1000 QPS
|
|
286
|
-
- **数据库查询**: 避免 N+1 查询,使用预加载
|
|
287
|
-
- **缓存策略**:
|
|
288
|
-
- 热点数据使用 Redis 缓存
|
|
289
|
-
- 设置合理的过期时间
|
|
290
|
-
- 缓存穿透防护
|
|
291
|
-
|
|
292
|
-
### 并发控制
|
|
293
|
-
|
|
294
|
-
```go
|
|
295
|
-
// 使用 goroutine 池控制并发
|
|
296
|
-
pool := NewWorkerPool(10)
|
|
297
|
-
for _, item := range items {
|
|
298
|
-
pool.Submit(func() {
|
|
299
|
-
process(item)
|
|
300
|
-
})
|
|
301
|
-
}
|
|
302
|
-
pool.Wait()
|
|
303
|
-
```
|
|
304
|
-
|
|
305
|
-
## 安全实践
|
|
306
|
-
|
|
307
|
-
### 1. SQL 注入防护
|
|
308
|
-
```go
|
|
309
|
-
// ✅ 正确:使用参数化查询
|
|
310
|
-
db.Where("email = ?", email).First(&user)
|
|
311
|
-
|
|
312
|
-
// ❌ 错误:拼接 SQL
|
|
313
|
-
db.Raw("SELECT * FROM users WHERE email = '" + email + "'")
|
|
314
|
-
```
|
|
315
|
-
|
|
316
|
-
### 2. 输入验证
|
|
317
|
-
```go
|
|
318
|
-
// 使用 validator 进行参数验证
|
|
319
|
-
if err := c.ShouldBindJSON(&req); err != nil {
|
|
320
|
-
return c.JSON(400, Response{Code: 4000, Message: err.Error()})
|
|
321
|
-
}
|
|
322
|
-
```
|
|
323
|
-
|
|
324
|
-
### 3. 密码安全
|
|
325
|
-
```go
|
|
326
|
-
// 使用 bcrypt 加密密码
|
|
327
|
-
hashedPassword, _ := bcrypt.GenerateFromPassword([]byte(password), bcrypt.DefaultCost)
|
|
328
|
-
|
|
329
|
-
// 验证密码
|
|
330
|
-
err := bcrypt.CompareHashAndPassword(hashedPassword, []byte(inputPassword))
|
|
331
|
-
```
|
|
332
|
-
|
|
333
|
-
### 4. JWT 认证
|
|
334
|
-
```go
|
|
335
|
-
// 生成 Token
|
|
336
|
-
token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
|
|
337
|
-
"user_id": user.ID,
|
|
338
|
-
"exp": time.Now().Add(7 * 24 * time.Hour).Unix(),
|
|
339
|
-
})
|
|
340
|
-
```
|
|
341
|
-
|
|
342
|
-
### 5. CORS 配置
|
|
343
|
-
```go
|
|
344
|
-
config := cors.DefaultConfig()
|
|
345
|
-
config.AllowOrigins = []string{"https://yourdomain.com"}
|
|
346
|
-
router.Use(cors.New(config))
|
|
347
|
-
```
|
|
348
|
-
|
|
349
|
-
## 测试要求
|
|
350
|
-
|
|
351
|
-
### 单元测试
|
|
352
|
-
|
|
353
|
-
**覆盖率**: >= 90%
|
|
354
|
-
**测试框架**: testify
|
|
355
|
-
|
|
356
|
-
```go
|
|
357
|
-
func TestUserService_CreateUser(t *testing.T) {
|
|
358
|
-
// 表驱动测试
|
|
359
|
-
tests := []struct {
|
|
360
|
-
name string
|
|
361
|
-
input CreateUserRequest
|
|
362
|
-
wantErr bool
|
|
363
|
-
}{
|
|
364
|
-
{"valid user", CreateUserRequest{Email: "test@example.com"}, false},
|
|
365
|
-
{"invalid email", CreateUserRequest{Email: "invalid"}, true},
|
|
366
|
-
}
|
|
367
|
-
|
|
368
|
-
for _, tt := range tests {
|
|
369
|
-
t.Run(tt.name, func(t *testing.T) {
|
|
370
|
-
err := service.CreateUser(tt.input)
|
|
371
|
-
if (err != nil) != tt.wantErr {
|
|
372
|
-
t.Errorf("CreateUser() error = %v, wantErr %v", err, tt.wantErr)
|
|
373
|
-
}
|
|
374
|
-
})
|
|
375
|
-
}
|
|
376
|
-
}
|
|
377
|
-
```
|
|
378
|
-
|
|
379
|
-
### Mock 外部依赖
|
|
380
|
-
|
|
381
|
-
使用 gomock:
|
|
382
|
-
```go
|
|
383
|
-
mockRepo := mock.NewMockUserRepository(ctrl)
|
|
384
|
-
mockRepo.EXPECT().FindByEmail("test@example.com").Return(&user, nil)
|
|
385
|
-
```
|
|
386
|
-
|
|
387
|
-
## 评审指南
|
|
388
|
-
|
|
389
|
-
**仅在需要评审时加载**: 当需要对后端 OpenSpec 或代码实现进行评审时,请参考 `@/references/backend-review-guide.md`
|
|
390
|
-
|
|
391
|
-
该评审指南提供:
|
|
392
|
-
- API 设计评审标准(RESTful 规范)
|
|
393
|
-
- 数据模型和数据库设计评审要点
|
|
394
|
-
- 安全性评审(SQL注入、XSS、密码加密等)
|
|
395
|
-
- 性能评审(N+1查询、索引、缓存等)
|
|
396
|
-
- 测试覆盖率评审标准(>= 90%)
|
|
397
|
-
- 评审记录模板和流程
|
|
398
|
-
|
|
399
|
-
**何时需要评审**:
|
|
400
|
-
- Backend OpenSpec 已生成,需要评审验证
|
|
401
|
-
- 用户明确要求对后端 OpenSpec 进行评审
|
|
402
|
-
- 代码实现完成,需要对照 OpenSpec 进行符合性评审
|
|
403
|
-
|
|
404
|
-
## 与其他 Skills 的协作
|
|
405
|
-
|
|
406
|
-
1. **上游**: 接收 SAE 生成的需求规格
|
|
407
|
-
2. **并行**: 与 Frontend Engineer 并行工作,通过 API 契约协作
|
|
408
|
-
3. **下游**: 代码完成后交给 Code Reviewer 进行代码审查
|
|
409
|
-
4. **修复循环**:
|
|
410
|
-
- 收到 Code Reviewer 或 Tester 修复请求 → 修复问题 → 本地验证 → **自动调用** `/code-reviewer` 重新审查
|
|
411
|
-
- Code Reviewer 通过后流转到 Tester,Tester 通过后流转到 Git Engineer
|
|
412
|
-
|
|
413
|
-
## 会话管理
|
|
414
|
-
|
|
415
|
-
⚠️ **注意**:Backend Engineer **不触发** `/compact` 命令。
|
|
416
|
-
|
|
417
|
-
### 为什么不触发 /compact
|
|
418
|
-
|
|
419
|
-
- Backend Engineer 不是工作流的终点,后续还有 Code Reviewer → Tester → Git Engineer
|
|
420
|
-
- 在修复循环中保持上下文连续性很重要(修复轮次、错误历史等)
|
|
421
|
-
- `/compact` 只在工作流的**起点**(SAE)和**终点**(Git Engineer MR 成功)触发
|
|
422
|
-
|
|
423
|
-
### 何时会触发 /compact
|
|
424
|
-
|
|
425
|
-
- 当整个工作流完成时(Git Engineer MR 创建成功)
|
|
426
|
-
- 当达到最大修复轮次需要人工介入时
|
|
427
|
-
|
|
428
|
-
## 在 Pre-Execution Review 中的角色
|
|
429
|
-
|
|
430
|
-
提供后端技术评估:
|
|
431
|
-
- 技术可行性分析
|
|
432
|
-
- 依赖风险识别(是否需要新依赖?)
|
|
433
|
-
- 性能预估(QPS、响应时间)
|
|
434
|
-
- 数据库设计复杂度
|
|
435
|
-
- 预计需要人工介入的部分
|
|
436
|
-
|
|
437
|
-
## 示例对话
|
|
438
|
-
|
|
439
|
-
```
|
|
440
|
-
我(Backend Engineer):
|
|
441
|
-
|
|
442
|
-
已读取需求规格:specs/requirements/user-login.md
|
|
443
|
-
|
|
444
|
-
我现在生成后端 OpenSpec...
|
|
445
|
-
|
|
446
|
-
[调用 openspec:proposal]
|
|
447
|
-
|
|
448
|
-
✅ 后端 OpenSpec 已生成
|
|
449
|
-
|
|
450
|
-
包含内容:
|
|
451
|
-
- API 端点:POST /api/v1/auth/login
|
|
452
|
-
- 请求参数:email, password
|
|
453
|
-
- 响应:JWT token, 用户信息
|
|
454
|
-
- 数据库表:users (id, email, password_hash, created_at, updated_at)
|
|
455
|
-
- 索引:email (唯一索引)
|
|
456
|
-
- 单元测试:10 个测试用例(邮箱/手机号登录、密码错误、用户不存在等)
|
|
457
|
-
|
|
458
|
-
请批准 OpenSpec,我将开始实现代码。
|
|
459
|
-
|
|
460
|
-
[用户批准后]
|
|
461
|
-
|
|
462
|
-
开始实现后端代码...
|
|
463
|
-
|
|
464
|
-
[调用 openspec:apply]
|
|
465
|
-
|
|
466
|
-
✅ 后端代码已实现
|
|
467
|
-
|
|
468
|
-
文件:
|
|
469
|
-
- backend/internal/api/auth_handler.go
|
|
470
|
-
- backend/internal/service/auth_service.go
|
|
471
|
-
- backend/internal/repository/user_repository.go
|
|
472
|
-
- backend/internal/model/user.go
|
|
473
|
-
- backend/tests/auth_test.go
|
|
474
|
-
|
|
475
|
-
测试覆盖率:92%
|
|
476
|
-
|
|
477
|
-
代码已提交到分支:feature/user-login
|
|
478
|
-
|
|
479
|
-
下一步请 Code Reviewer 进行代码审查。
|
|
480
|
-
```
|