refactor: 一次性佣金配置从套餐级别提升到系列级别
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 6m29s
All checks were successful
构建并部署到测试环境（无 SSH） / build-and-deploy (push) Successful in 6m29s
主要变更: - 新增 tb_shop_series_allocation 表，存储系列级别的一次性佣金配置 - ShopPackageAllocation 移除 one_time_commission_amount 字段 - PackageSeries 新增 enable_one_time_commission 字段控制是否启用一次性佣金 - 新增 /api/admin/shop-series-allocations CRUD 接口 - 佣金计算逻辑改为从 ShopSeriesAllocation 获取一次性佣金金额 - 删除废弃的 ShopSeriesOneTimeCommissionTier 模型 - OpenAPI Tag '系列分配' 和 '单套餐分配' 合并为 '套餐分配' 迁移脚本: - 000042: 重构佣金套餐模型 - 000043: 简化佣金分配 - 000044: 一次性佣金分配重构 - 000045: PackageSeries 添加 enable_one_time_commission 字段 测试: - 新增验收测试 (shop_series_allocation, commission_calculation) - 新增流程测试 (one_time_commission_chain) - 删除过时的单元测试（已被验收测试覆盖）
This commit is contained in:
133
.opencode/command/opsx-gen-tests.md
Normal file
133
.opencode/command/opsx-gen-tests.md
Normal file
@@ -0,0 +1,133 @@
|
||||
---
|
||||
description: 从 Spec 的 Scenarios 和 Business Flows 自动生成验收测试和流程测试
|
||||
---
|
||||
|
||||
从 Spec 文档自动生成两类测试：
|
||||
1. **验收测试**（Acceptance Tests）：从 Scenarios 生成，验证单 API 契约
|
||||
2. **流程测试**（Flow Tests）：从 Business Flows 生成，验证多 API 业务场景
|
||||
|
||||
**Input**: 可选指定 change 名称（如 `/opsx:gen-tests add-auth`）。如果省略，从上下文推断或提示选择。
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **选择 change**
|
||||
|
||||
如果提供了名称，使用它。否则：
|
||||
- 从对话上下文推断
|
||||
- 如果只有一个活跃 change，自动选择
|
||||
- 如果模糊，运行 `openspec list --json` 让用户选择
|
||||
|
||||
2. **检查 change 状态**
|
||||
```bash
|
||||
openspec status --change "<name>" --json
|
||||
```
|
||||
确认 specs artifact 已完成（`status: "done"`）
|
||||
|
||||
3. **读取 spec 文件**
|
||||
|
||||
读取 `openspec/changes/<change-name>/specs/*/spec.md` 下的所有 spec 文件。
|
||||
|
||||
4. **解析 Scenarios**
|
||||
|
||||
从每个 spec 文件中提取 `#### Scenario:` 块：
|
||||
```markdown
|
||||
#### Scenario: 成功创建套餐
|
||||
- **GIVEN** 用户已登录且有创建权限
|
||||
- **WHEN** POST /api/admin/packages with valid data
|
||||
- **THEN** 返回 200 和套餐详情
|
||||
```
|
||||
|
||||
5. **解析 Business Flows**（如果存在）
|
||||
|
||||
从 spec 文件中提取 `### Flow:` 块，包含多步骤业务场景。
|
||||
|
||||
6. **生成验收测试**
|
||||
|
||||
输出路径：`tests/acceptance/<capability>_acceptance_test.go`
|
||||
|
||||
模板结构：
|
||||
```go
|
||||
func Test{Capability}_Acceptance(t *testing.T) {
|
||||
env := testutils.NewIntegrationTestEnv(t)
|
||||
|
||||
t.Run("Scenario_{name}", func(t *testing.T) {
|
||||
// GIVEN: ...
|
||||
// WHEN: ...
|
||||
// THEN: ...
|
||||
// 破坏点：...
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
7. **生成流程测试**
|
||||
|
||||
输出路径：`tests/flows/<capability>_<flow>_flow_test.go`
|
||||
|
||||
模板结构：
|
||||
```go
|
||||
func TestFlow_{FlowName}(t *testing.T) {
|
||||
env := testutils.NewIntegrationTestEnv(t)
|
||||
|
||||
var (
|
||||
// 流程级共享状态
|
||||
)
|
||||
|
||||
t.Run("Step1_{name}", func(t *testing.T) {
|
||||
// 依赖：...
|
||||
// 破坏点：...
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
8. **运行测试验证**
|
||||
|
||||
```bash
|
||||
source .env.local && go test -v ./tests/acceptance/... ./tests/flows/... 2>&1 | head -50
|
||||
```
|
||||
|
||||
**预期**：全部 FAIL（功能未实现，证明测试有效）
|
||||
|
||||
**如果测试 PASS**：说明测试写得太弱，需要加强
|
||||
|
||||
**Output**
|
||||
|
||||
```
|
||||
## 测试生成完成
|
||||
|
||||
**Change:** <change-name>
|
||||
**来源:** specs/<capability>/spec.md
|
||||
|
||||
### 生成的测试文件
|
||||
|
||||
**验收测试** (tests/acceptance/):
|
||||
- <capability>_acceptance_test.go
|
||||
- Scenario_xxx
|
||||
- Scenario_yyy
|
||||
|
||||
**流程测试** (tests/flows/):
|
||||
- <capability>_<flow>_flow_test.go
|
||||
- Step1_xxx
|
||||
- Step2_yyy
|
||||
|
||||
### 验证结果
|
||||
|
||||
$ source .env.local && go test -v ./tests/acceptance/... ./tests/flows/...
|
||||
|
||||
--- FAIL: TestXxx_Acceptance (0.00s)
|
||||
--- FAIL: TestXxx_Acceptance/Scenario_xxx (0.00s)
|
||||
xxx_acceptance_test.go:45: 404 != 200
|
||||
|
||||
✓ 所有测试预期 FAIL（功能未实现）
|
||||
✓ 测试生成完成
|
||||
|
||||
下一步: 开始实现 tasks，每完成一个功能单元运行相关测试验证
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
|
||||
- 每个 Scenario 必须生成一个测试用例（不要跳过）
|
||||
- 每个测试必须包含"破坏点"注释
|
||||
- 流程测试的 step 必须声明依赖
|
||||
- 使用 IntegrationTestEnv，不要 mock 依赖
|
||||
- 测试必须在功能缺失时 FAIL（不要写永远 PASS 的测试）
|
||||
- 详细模板参考：`.opencode/skills/openspec-generate-acceptance-tests/SKILL.md`
|
||||
@@ -102,7 +102,35 @@ Common artifact patterns:
|
||||
- The Capabilities section is critical - each capability listed will need a spec file.
|
||||
- **specs/<capability>/spec.md**: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
|
||||
- **design.md**: Document technical decisions, architecture, and implementation approach.
|
||||
- **tasks.md**: Break down implementation into checkboxed tasks.
|
||||
- **tasks.md**: Break down implementation into checkboxed tasks, following TDD workflow structure:
|
||||
|
||||
**TDD Tasks Structure (MUST follow)**:
|
||||
```markdown
|
||||
## 0. 测试准备（实现前执行）
|
||||
- [ ] 0.1 生成验收测试和流程测试（/opsx:gen-tests）
|
||||
- [ ] 0.2 运行测试确认全部 FAIL（证明测试有效）
|
||||
|
||||
## 1. 基础设施（数据库 + Model）
|
||||
- [ ] 1.x 创建迁移、Model、DTO
|
||||
- [ ] 1.y 验证：编译通过
|
||||
|
||||
## 2. 功能单元 A（完整垂直切片）
|
||||
- [ ] 2.1 Store 层
|
||||
- [ ] 2.2 Service 层
|
||||
- [ ] 2.3 Handler 层 + 路由
|
||||
- [ ] 2.4 **验证：功能 A 相关验收测试 PASS**
|
||||
|
||||
## N. 最终验证
|
||||
- [ ] N.1 全部验收测试 PASS
|
||||
- [ ] N.2 全部流程测试 PASS
|
||||
- [ ] N.3 完整测试套件无回归
|
||||
```
|
||||
|
||||
**Key principles**:
|
||||
- Task group 0 MUST be test preparation (generate tests + confirm all FAIL)
|
||||
- Organize by functional units, NOT by technical layers (Store/Service/Handler)
|
||||
- Each functional unit MUST end with "verify related tests PASS"
|
||||
- Final validation MUST include all acceptance + flow tests passing
|
||||
|
||||
For other schemas, follow the `instruction` field from the CLI output.
|
||||
|
||||
|
||||
@@ -252,11 +252,28 @@ You: That changes everything.
|
||||
|
||||
There's no required ending. Discovery might:
|
||||
|
||||
- **Lock consensus first**: "讨论已经比较清晰了，要锁定共识吗？" → `/opsx:lock <name>`
|
||||
- **Flow into action**: "Ready to start? /opsx:new or /opsx:ff"
|
||||
- **Result in artifact updates**: "Updated design.md with these decisions"
|
||||
- **Just provide clarity**: User has what they need, moves on
|
||||
- **Continue later**: "We can pick this up anytime"
|
||||
|
||||
### 推荐流程
|
||||
|
||||
当讨论涉及重要决策时，**建议先锁定共识再创建变更**：
|
||||
|
||||
```
|
||||
探索讨论 → /opsx:lock → /opsx:new 或 /opsx:ff
|
||||
```
|
||||
|
||||
锁定共识会生成 `consensus.md`，记录：
|
||||
- 要做什么
|
||||
- 不做什么
|
||||
- 关键约束
|
||||
- 验收标准
|
||||
|
||||
后续生成 proposal 时会自动验证是否符合共识。
|
||||
|
||||
When it feels like things are crystallizing, you might summarize:
|
||||
|
||||
```
|
||||
@@ -269,6 +286,7 @@ When it feels like things are crystallizing, you might summarize:
|
||||
**Open questions**: [if any remain]
|
||||
|
||||
**Next steps** (if ready):
|
||||
- Lock consensus: /opsx:lock <name> (推荐先锁定)
|
||||
- Create a change: /opsx:new <name>
|
||||
- Fast-forward to tasks: /opsx:ff <name>
|
||||
- Keep exploring: just keep talking
|
||||
|
||||
442
.opencode/skills/openspec-generate-acceptance-tests/SKILL.md
Normal file
442
.opencode/skills/openspec-generate-acceptance-tests/SKILL.md
Normal file
@@ -0,0 +1,442 @@
|
||||
---
|
||||
name: openspec-generate-acceptance-tests
|
||||
description: 从 Spec 的 Scenarios 和 Business Flows 自动生成验收测试和流程测试。测试在实现前生成，预期全部 FAIL，证明测试有效。
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: junhong
|
||||
version: "1.0"
|
||||
---
|
||||
|
||||
# 测试生成 Skill
|
||||
|
||||
从 Spec 文档自动生成两类测试：
|
||||
1. **验收测试**（Acceptance Tests）：从 Scenarios 生成，验证单 API 契约
|
||||
2. **流程测试**（Flow Tests）：从 Business Flows 生成，验证多 API 业务场景
|
||||
|
||||
## 触发方式
|
||||
|
||||
```
|
||||
/opsx:gen-tests [change-name]
|
||||
```
|
||||
|
||||
如果不指定 change-name，自动检测当前活跃的 change。
|
||||
|
||||
---
|
||||
|
||||
## 前置条件
|
||||
|
||||
1. Change 必须存在且包含 spec 文件
|
||||
2. Spec 必须包含 `## Scenarios` 部分
|
||||
3. Spec 建议包含 `## Business Flows` 部分（如果有跨 API 场景）
|
||||
|
||||
检查命令：
|
||||
```bash
|
||||
openspec list --json
|
||||
# 确认 change 存在且有 specs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 工作流程
|
||||
|
||||
### Step 1: 读取 Spec 文件
|
||||
|
||||
```bash
|
||||
# 读取 change 的所有 spec 文件
|
||||
cat openspec/changes/<change-name>/specs/<capability>/spec.md
|
||||
```
|
||||
|
||||
### Step 2: 解析 Scenarios
|
||||
|
||||
从 Spec 中提取所有 Scenario：
|
||||
|
||||
```markdown
|
||||
#### Scenario: 成功创建套餐
|
||||
- **GIVEN** 用户已登录且有创建权限
|
||||
- **WHEN** POST /api/admin/packages with valid data
|
||||
- **THEN** 返回 201 和套餐详情
|
||||
- **AND** 数据库中存在该套餐记录
|
||||
```
|
||||
|
||||
解析为结构：
|
||||
```json
|
||||
{
|
||||
"name": "成功创建套餐",
|
||||
"given": ["用户已登录且有创建权限"],
|
||||
"when": {"method": "POST", "path": "/api/admin/packages", "condition": "valid data"},
|
||||
"then": ["返回 201 和套餐详情"],
|
||||
"and": ["数据库中存在该套餐记录"]
|
||||
}
|
||||
```
|
||||
|
||||
### Step 3: 解析 Business Flows
|
||||
|
||||
从 Spec 中提取 Business Flow：
|
||||
|
||||
```markdown
|
||||
### Flow: 套餐完整生命周期
|
||||
|
||||
**参与者**: 平台管理员, 代理商
|
||||
|
||||
**流程步骤**:
|
||||
|
||||
1. **创建套餐**
|
||||
- 角色: 平台管理员
|
||||
- 调用: POST /api/admin/packages
|
||||
- 预期: 返回套餐 ID
|
||||
|
||||
2. **分配给代理商**
|
||||
- 角色: 平台管理员
|
||||
- 调用: POST /api/admin/shop-packages
|
||||
- 输入: 套餐 ID + 店铺 ID
|
||||
- 预期: 分配成功
|
||||
|
||||
3. **代理商查看可售套餐**
|
||||
- 角色: 代理商
|
||||
- 调用: GET /api/admin/shop-packages
|
||||
- 预期: 列表包含刚分配的套餐
|
||||
```
|
||||
|
||||
### Step 4: 生成验收测试
|
||||
|
||||
**输出路径**: `tests/acceptance/<capability>_acceptance_test.go`
|
||||
|
||||
```go
|
||||
package acceptance
|
||||
|
||||
import (
|
||||
"testing"
|
||||
|
||||
"github.com/stretchr/testify/assert"
|
||||
"github.com/stretchr/testify/require"
|
||||
|
||||
"junhong_cmp_fiber/tests/testutils"
|
||||
)
|
||||
|
||||
// ============================================================
|
||||
// 验收测试：套餐管理
|
||||
// 来源：openspec/changes/package-management/specs/package/spec.md
|
||||
// ============================================================
|
||||
|
||||
func TestPackage_Acceptance(t *testing.T) {
|
||||
env := testutils.NewIntegrationTestEnv(t)
|
||||
|
||||
// ------------------------------------------------------------
|
||||
// Scenario: 成功创建套餐
|
||||
// GIVEN: 用户已登录且有创建权限
|
||||
// WHEN: POST /api/admin/packages with valid data
|
||||
// THEN: 返回 201 和套餐详情
|
||||
// AND: 数据库中存在该套餐记录
|
||||
//
|
||||
// 破坏点：如果删除 handler.Create 中的 store.Create 调用，此测试将失败
|
||||
// ------------------------------------------------------------
|
||||
t.Run("Scenario_成功创建套餐", func(t *testing.T) {
|
||||
// GIVEN: 用户已登录且有创建权限
|
||||
client := env.AsSuperAdmin()
|
||||
|
||||
// WHEN: POST /api/admin/packages with valid data
|
||||
body := map[string]interface{}{
|
||||
"name": "测试套餐",
|
||||
"description": "测试描述",
|
||||
"price": 9900,
|
||||
"duration": 30,
|
||||
}
|
||||
resp, err := client.Request("POST", "/api/admin/packages", body)
|
||||
require.NoError(t, err)
|
||||
|
||||
// THEN: 返回 201 和套餐详情
|
||||
assert.Equal(t, 201, resp.StatusCode)
|
||||
|
||||
var result map[string]interface{}
|
||||
err = resp.JSON(&result)
|
||||
require.NoError(t, err)
|
||||
assert.Equal(t, 0, int(result["code"].(float64)))
|
||||
|
||||
data := result["data"].(map[string]interface{})
|
||||
packageID := uint(data["id"].(float64))
|
||||
assert.NotZero(t, packageID)
|
||||
|
||||
// AND: 数据库中存在该套餐记录
|
||||
// TODO: 实现后取消注释
|
||||
// pkg, err := env.DB().Package.FindByID(ctx, packageID)
|
||||
// require.NoError(t, err)
|
||||
// assert.Equal(t, "测试套餐", pkg.Name)
|
||||
})
|
||||
|
||||
// ------------------------------------------------------------
|
||||
// Scenario: 创建套餐参数校验失败
|
||||
// GIVEN: 用户已登录
|
||||
// WHEN: POST /api/admin/packages with invalid data (name empty)
|
||||
// THEN: 返回 400 和错误信息
|
||||
//
|
||||
// 破坏点：如果删除 handler 中的参数校验，此测试将失败
|
||||
// ------------------------------------------------------------
|
||||
t.Run("Scenario_创建套餐参数校验失败", func(t *testing.T) {
|
||||
// GIVEN: 用户已登录
|
||||
client := env.AsSuperAdmin()
|
||||
|
||||
// WHEN: POST /api/admin/packages with invalid data
|
||||
body := map[string]interface{}{
|
||||
"name": "", // 空名称
|
||||
"price": -1, // 负价格
|
||||
}
|
||||
resp, err := client.Request("POST", "/api/admin/packages", body)
|
||||
require.NoError(t, err)
|
||||
|
||||
// THEN: 返回 400 和错误信息
|
||||
assert.Equal(t, 400, resp.StatusCode)
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Step 5: 生成流程测试
|
||||
|
||||
**输出路径**: `tests/flows/<capability>_<flow-name>_flow_test.go`
|
||||
|
||||
```go
|
||||
package flows
|
||||
|
||||
import (
|
||||
"testing"
|
||||
|
||||
"github.com/stretchr/testify/assert"
|
||||
"github.com/stretchr/testify/require"
|
||||
|
||||
"junhong_cmp_fiber/tests/testutils"
|
||||
)
|
||||
|
||||
// ============================================================
|
||||
// 流程测试：套餐完整生命周期
|
||||
// 来源：openspec/changes/package-management/specs/package/spec.md
|
||||
// 参与者：平台管理员, 代理商
|
||||
// ============================================================
|
||||
|
||||
func TestFlow_PackageLifecycle(t *testing.T) {
|
||||
env := testutils.NewIntegrationTestEnv(t)
|
||||
|
||||
// 流程级共享状态
|
||||
var (
|
||||
packageID uint
|
||||
shopID uint = 1 // 测试店铺 ID
|
||||
)
|
||||
|
||||
// ------------------------------------------------------------
|
||||
// Step 1: 创建套餐
|
||||
// 角色: 平台管理员
|
||||
// 调用: POST /api/admin/packages
|
||||
// 预期: 返回套餐 ID
|
||||
//
|
||||
// 破坏点：如果套餐创建 API 不返回 ID，后续步骤无法执行
|
||||
// ------------------------------------------------------------
|
||||
t.Run("Step1_平台管理员创建套餐", func(t *testing.T) {
|
||||
client := env.AsSuperAdmin()
|
||||
|
||||
body := map[string]interface{}{
|
||||
"name": "流程测试套餐",
|
||||
"description": "用于流程测试",
|
||||
"price": 19900,
|
||||
"duration": 30,
|
||||
}
|
||||
resp, err := client.Request("POST", "/api/admin/packages", body)
|
||||
require.NoError(t, err)
|
||||
require.Equal(t, 201, resp.StatusCode)
|
||||
|
||||
var result map[string]interface{}
|
||||
err = resp.JSON(&result)
|
||||
require.NoError(t, err)
|
||||
|
||||
data := result["data"].(map[string]interface{})
|
||||
packageID = uint(data["id"].(float64))
|
||||
require.NotZero(t, packageID, "套餐 ID 不能为空")
|
||||
})
|
||||
|
||||
// ------------------------------------------------------------
|
||||
// Step 2: 分配给代理商
|
||||
// 角色: 平台管理员
|
||||
// 调用: POST /api/admin/shop-packages
|
||||
// 输入: 套餐 ID + 店铺 ID
|
||||
// 预期: 分配成功
|
||||
//
|
||||
// 依赖: Step 1 的 packageID
|
||||
// 破坏点：如果分配 API 不检查套餐是否存在，可能分配无效套餐
|
||||
// ------------------------------------------------------------
|
||||
t.Run("Step2_分配套餐给代理商", func(t *testing.T) {
|
||||
if packageID == 0 {
|
||||
t.Skip("依赖 Step 1 创建的 packageID")
|
||||
}
|
||||
|
||||
client := env.AsSuperAdmin()
|
||||
|
||||
body := map[string]interface{}{
|
||||
"package_id": packageID,
|
||||
"shop_id": shopID,
|
||||
}
|
||||
resp, err := client.Request("POST", "/api/admin/shop-packages", body)
|
||||
require.NoError(t, err)
|
||||
require.Equal(t, 200, resp.StatusCode)
|
||||
})
|
||||
|
||||
// ------------------------------------------------------------
|
||||
// Step 3: 代理商查看可售套餐
|
||||
// 角色: 代理商
|
||||
// 调用: GET /api/admin/shop-packages
|
||||
// 预期: 列表包含刚分配的套餐
|
||||
//
|
||||
// 依赖: Step 2 的分配操作
|
||||
// 破坏点：如果查询不按店铺过滤，代理商会看到其他店铺的套餐
|
||||
// ------------------------------------------------------------
|
||||
t.Run("Step3_代理商查看可售套餐", func(t *testing.T) {
|
||||
if packageID == 0 {
|
||||
t.Skip("依赖 Step 1 创建的 packageID")
|
||||
}
|
||||
|
||||
// 以代理商身份请求
|
||||
client := env.AsShopAgent(shopID)
|
||||
|
||||
resp, err := client.Request("GET", "/api/admin/shop-packages", nil)
|
||||
require.NoError(t, err)
|
||||
require.Equal(t, 200, resp.StatusCode)
|
||||
|
||||
var result map[string]interface{}
|
||||
err = resp.JSON(&result)
|
||||
require.NoError(t, err)
|
||||
|
||||
// 验证列表包含刚分配的套餐
|
||||
data := result["data"].(map[string]interface{})
|
||||
list := data["list"].([]interface{})
|
||||
|
||||
found := false
|
||||
for _, item := range list {
|
||||
pkg := item.(map[string]interface{})
|
||||
if uint(pkg["package_id"].(float64)) == packageID {
|
||||
found = true
|
||||
break
|
||||
}
|
||||
}
|
||||
assert.True(t, found, "代理商应该能看到刚分配的套餐")
|
||||
})
|
||||
}
|
||||
```
|
||||
|
||||
### Step 6: 运行测试验证
|
||||
|
||||
生成测试后，立即运行验证：
|
||||
|
||||
```bash
|
||||
# 预期全部 FAIL（因为功能尚未实现）
|
||||
source .env.local && go test -v ./tests/acceptance/... ./tests/flows/... 2>&1 | head -50
|
||||
```
|
||||
|
||||
**如果测试 PASS**：
|
||||
- 说明测试写得太弱，没有真正验证功能
|
||||
- 需要加强测试或检查是否功能已存在
|
||||
|
||||
---
|
||||
|
||||
## 测试模板规范
|
||||
|
||||
### 验收测试必须包含
|
||||
|
||||
1. **来源注释**：标明从哪个 spec 文件生成
|
||||
2. **Scenario 注释**：完整的 GIVEN/WHEN/THEN/AND
|
||||
3. **破坏点注释**：说明什么代码变更会导致测试失败
|
||||
4. **清晰的结构**：GIVEN → WHEN → THEN → AND 分块
|
||||
|
||||
### 流程测试必须包含
|
||||
|
||||
1. **来源注释**：标明从哪个 spec 文件生成
|
||||
2. **参与者注释**：涉及哪些角色
|
||||
3. **共享状态声明**：流程中需要传递的数据
|
||||
4. **依赖声明**：每个 step 依赖哪些前置 step
|
||||
5. **破坏点注释**：说明什么代码变更会导致测试失败
|
||||
|
||||
### 破坏点注释示例
|
||||
|
||||
```go
|
||||
// 破坏点：如果删除 handler.Create 中的 store.Create 调用，此测试将失败
|
||||
// 破坏点：如果移除参数校验中的 name 必填检查，此测试将失败
|
||||
// 破坏点：如果查询不按 shop_id 过滤，此测试将失败（会返回其他店铺数据）
|
||||
// 破坏点：如果状态机允许 "已使用" → "未分配" 的转换，此测试将失败
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 输出文件
|
||||
|
||||
| 来源 | 输出 |
|
||||
|------|------|
|
||||
| Spec Scenarios | `tests/acceptance/<capability>_acceptance_test.go` |
|
||||
| Spec Business Flows | `tests/flows/<capability>_<flow>_flow_test.go` |
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **不要跳过 Scenario** - 每个 Scenario 必须对应一个测试用例
|
||||
- **不要省略破坏点** - 每个测试必须有破坏点注释
|
||||
- **不要硬编码 ID** - 使用共享变量传递流程中的 ID
|
||||
- **不要忽略依赖** - 流程测试的 step 必须声明依赖
|
||||
- **不要写永远 PASS 的测试** - 测试必须在功能缺失时 FAIL
|
||||
|
||||
---
|
||||
|
||||
## 与其他 Skills 的关系
|
||||
|
||||
| Skill | 关系 |
|
||||
|-------|------|
|
||||
| `openspec-continue-change` | 生成 spec 后可触发 gen-tests |
|
||||
| `openspec-apply-change` | 实现时参考生成的测试 |
|
||||
| `openspec-verify-change` | 验证时运行生成的测试 |
|
||||
|
||||
---
|
||||
|
||||
## 示例交互
|
||||
|
||||
```
|
||||
User: /opsx:gen-tests package-management
|
||||
|
||||
AI: 正在分析 change: package-management
|
||||
|
||||
找到 spec 文件: openspec/changes/package-management/specs/package/spec.md
|
||||
|
||||
解析结果:
|
||||
- Scenarios: 5 个
|
||||
- Business Flows: 2 个
|
||||
|
||||
生成测试文件:
|
||||
|
||||
1. tests/acceptance/package_acceptance_test.go
|
||||
- Scenario_成功创建套餐
|
||||
- Scenario_创建套餐参数校验失败
|
||||
- Scenario_成功更新套餐
|
||||
- Scenario_成功删除套餐
|
||||
- Scenario_删除已分配套餐失败
|
||||
|
||||
2. tests/flows/package_lifecycle_flow_test.go
|
||||
- Step1_平台管理员创建套餐
|
||||
- Step2_分配套餐给代理商
|
||||
- Step3_代理商查看可售套餐
|
||||
- Step4_代理商创建订单
|
||||
- Step5_套餐使用统计更新
|
||||
|
||||
3. tests/flows/package_allocation_flow_test.go
|
||||
- Step1_批量分配套餐
|
||||
- Step2_验证分配结果
|
||||
- Step3_撤销部分分配
|
||||
|
||||
运行验证:
|
||||
$ source .env.local && go test -v ./tests/acceptance/package_... ./tests/flows/package_...
|
||||
|
||||
--- FAIL: TestPackage_Acceptance (0.00s)
|
||||
--- FAIL: TestPackage_Acceptance/Scenario_成功创建套餐 (0.00s)
|
||||
package_acceptance_test.go:45: 404 != 201
|
||||
--- FAIL: TestFlow_PackageLifecycle (0.00s)
|
||||
--- FAIL: TestFlow_PackageLifecycle/Step1_平台管理员创建套餐 (0.00s)
|
||||
package_lifecycle_flow_test.go:38: 404 != 201
|
||||
|
||||
✓ 所有测试预期 FAIL（功能未实现）
|
||||
✓ 测试生成完成
|
||||
|
||||
下一步: /opsx:continue 生成 design 和 tasks
|
||||
```
|
||||
281
.opencode/skills/openspec-lock-consensus/SKILL.md
Normal file
281
.opencode/skills/openspec-lock-consensus/SKILL.md
Normal file
@@ -0,0 +1,281 @@
|
||||
---
|
||||
name: openspec-lock-consensus
|
||||
description: 锁定共识 - 在探索讨论后，将讨论结果锁定为正式共识文档。防止后续提案偏离讨论内容。
|
||||
license: MIT
|
||||
compatibility: Requires openspec CLI.
|
||||
metadata:
|
||||
author: junhong
|
||||
version: "1.1"
|
||||
---
|
||||
|
||||
# 共识锁定 Skill
|
||||
|
||||
在 `/opsx:explore` 讨论后，使用此 skill 将讨论结果锁定为正式共识。共识文档是后续所有 artifact 的基础约束。
|
||||
|
||||
## 触发方式
|
||||
|
||||
```
|
||||
/opsx:lock <change-name>
|
||||
```
|
||||
|
||||
或在探索结束后，AI 主动提议：
|
||||
> "讨论已经比较清晰了，要锁定共识吗？"
|
||||
|
||||
---
|
||||
|
||||
## 工作流程
|
||||
|
||||
### Step 1: 整理讨论要点
|
||||
|
||||
从对话中提取以下四个维度的共识：
|
||||
|
||||
| 维度 | 说明 | 示例 |
|
||||
|------|------|------|
|
||||
| **要做什么** | 明确的功能范围 | "支持批量导入 IoT 卡" |
|
||||
| **不做什么** | 明确排除的内容 | "不支持实时同步，仅定时批量" |
|
||||
| **关键约束** | 技术/业务限制 | "必须使用 Asynq 异步任务" |
|
||||
| **验收标准** | 如何判断完成 | "导入 1000 张卡 < 30s" |
|
||||
|
||||
### Step 2: 使用 Question_tool 逐维度确认
|
||||
|
||||
**必须使用 Question_tool 进行结构化确认**，每个维度一个问题：
|
||||
|
||||
```typescript
|
||||
// 示例：确认"要做什么"
|
||||
Question_tool({
|
||||
questions: [{
|
||||
header: "确认：要做什么",
|
||||
question: "以下是整理的功能范围，请确认：\n\n" +
|
||||
"1. 功能点 A\n" +
|
||||
"2. 功能点 B\n" +
|
||||
"3. 功能点 C\n\n" +
|
||||
"是否准确完整？",
|
||||
options: [
|
||||
{ label: "确认无误", description: "以上内容准确完整" },
|
||||
{ label: "需要补充", description: "有遗漏的功能点" },
|
||||
{ label: "需要删减", description: "有不应该包含的内容" }
|
||||
],
|
||||
multiple: false
|
||||
}]
|
||||
})
|
||||
```
|
||||
|
||||
**如果用户选择"需要补充"或"需要删减"**：
|
||||
- 用户会通过自定义输入提供修改意见
|
||||
- 根据反馈更新列表，再次使用 Question_tool 确认
|
||||
|
||||
**确认流程**：
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ Question_tool: 确认"要做什么" │
|
||||
│ ├── 用户选择"确认无误" → 进入下一维度 │
|
||||
│ └── 用户选择其他/自定义 → 修改后重新确认 │
|
||||
├─────────────────────────────────────────────────────────────────────┤
|
||||
│ Question_tool: 确认"不做什么" │
|
||||
│ ├── 用户选择"确认无误" → 进入下一维度 │
|
||||
│ └── 用户选择其他/自定义 → 修改后重新确认 │
|
||||
├─────────────────────────────────────────────────────────────────────┤
|
||||
│ Question_tool: 确认"关键约束" │
|
||||
│ ├── 用户选择"确认无误" → 进入下一维度 │
|
||||
│ └── 用户选择其他/自定义 → 修改后重新确认 │
|
||||
├─────────────────────────────────────────────────────────────────────┤
|
||||
│ Question_tool: 确认"验收标准" │
|
||||
│ ├── 用户选择"确认无误" → 生成 consensus.md │
|
||||
│ └── 用户选择其他/自定义 → 修改后重新确认 │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Step 3: 生成 consensus.md
|
||||
|
||||
所有维度确认后，创建文件：
|
||||
|
||||
```bash
|
||||
# 检查 change 是否存在
|
||||
openspec list --json
|
||||
|
||||
# 如果 change 不存在，先创建
|
||||
# openspec new <change-name>
|
||||
|
||||
# 写入 consensus.md
|
||||
```
|
||||
|
||||
**文件路径**: `openspec/changes/<change-name>/consensus.md`
|
||||
|
||||
---
|
||||
|
||||
## Question_tool 使用规范
|
||||
|
||||
### 每个维度的问题模板
|
||||
|
||||
**1. 要做什么**
|
||||
```typescript
|
||||
{
|
||||
header: "确认：要做什么",
|
||||
question: "以下是整理的【功能范围】：\n\n" +
|
||||
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
|
||||
"\n\n请确认是否准确完整？",
|
||||
options: [
|
||||
{ label: "确认无误", description: "功能范围准确完整" },
|
||||
{ label: "需要补充", description: "有遗漏的功能点" },
|
||||
{ label: "需要删减", description: "有不应该包含的内容" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**2. 不做什么**
|
||||
```typescript
|
||||
{
|
||||
header: "确认：不做什么",
|
||||
question: "以下是明确【排除的内容】：\n\n" +
|
||||
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
|
||||
"\n\n请确认是否正确？",
|
||||
options: [
|
||||
{ label: "确认无误", description: "排除范围正确" },
|
||||
{ label: "需要补充", description: "还有其他需要排除的" },
|
||||
{ label: "需要删减", description: "有些不应该排除" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**3. 关键约束**
|
||||
```typescript
|
||||
{
|
||||
header: "确认：关键约束",
|
||||
question: "以下是【关键约束】：\n\n" +
|
||||
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
|
||||
"\n\n请确认是否正确？",
|
||||
options: [
|
||||
{ label: "确认无误", description: "约束条件正确" },
|
||||
{ label: "需要补充", description: "还有其他约束" },
|
||||
{ label: "需要修改", description: "约束描述不准确" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**4. 验收标准**
|
||||
```typescript
|
||||
{
|
||||
header: "确认：验收标准",
|
||||
question: "以下是【验收标准】（必须可测量）：\n\n" +
|
||||
items.map((item, i) => `${i+1}. ${item}`).join('\n') +
|
||||
"\n\n请确认是否正确？",
|
||||
options: [
|
||||
{ label: "确认无误", description: "验收标准清晰可测量" },
|
||||
{ label: "需要补充", description: "还有其他验收标准" },
|
||||
{ label: "需要修改", description: "标准不够清晰或无法测量" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 处理用户反馈
|
||||
|
||||
当用户选择非"确认无误"选项或提供自定义输入时：
|
||||
|
||||
1. 解析用户的修改意见
|
||||
2. 更新对应维度的内容
|
||||
3. 再次使用 Question_tool 确认更新后的内容
|
||||
4. 重复直到用户选择"确认无误"
|
||||
|
||||
---
|
||||
|
||||
## consensus.md 模板
|
||||
|
||||
```markdown
|
||||
# 共识文档
|
||||
|
||||
**Change**: <change-name>
|
||||
**确认时间**: <timestamp>
|
||||
**确认人**: 用户
|
||||
|
||||
---
|
||||
|
||||
## 1. 要做什么
|
||||
|
||||
- [x] 功能点 A（已确认）
|
||||
- [x] 功能点 B（已确认）
|
||||
- [x] 功能点 C（已确认）
|
||||
|
||||
## 2. 不做什么
|
||||
|
||||
- [x] 排除项 A（已确认）
|
||||
- [x] 排除项 B（已确认）
|
||||
|
||||
## 3. 关键约束
|
||||
|
||||
- [x] 技术约束 A（已确认）
|
||||
- [x] 业务约束 B（已确认）
|
||||
|
||||
## 4. 验收标准
|
||||
|
||||
- [x] 验收标准 A（已确认）
|
||||
- [x] 验收标准 B（已确认）
|
||||
|
||||
---
|
||||
|
||||
## 讨论背景
|
||||
|
||||
<简要总结讨论的核心问题和解决方向>
|
||||
|
||||
## 关键决策记录
|
||||
|
||||
| 决策点 | 选择 | 原因 |
|
||||
|--------|------|------|
|
||||
| 决策 1 | 选项 A | 理由... |
|
||||
| 决策 2 | 选项 B | 理由... |
|
||||
|
||||
---
|
||||
|
||||
**签字确认**: 用户已通过 Question_tool 逐条确认以上内容
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 后续流程绑定
|
||||
|
||||
### Proposal 生成时
|
||||
|
||||
`/opsx:continue` 生成 proposal 时，**必须**：
|
||||
|
||||
1. 读取 `consensus.md`
|
||||
2. 确保 proposal 的 Capabilities 覆盖"要做什么"中的每一项
|
||||
3. 确保 proposal 不包含"不做什么"中的内容
|
||||
4. 确保 proposal 遵守"关键约束"
|
||||
|
||||
### 验证机制
|
||||
|
||||
如果 proposal 与 consensus 不一致，输出警告：
|
||||
|
||||
```
|
||||
⚠️ Proposal 验证警告：
|
||||
|
||||
共识中"要做什么"但 Proposal 未提及：
|
||||
- 功能点 C
|
||||
|
||||
共识中"不做什么"但 Proposal 包含：
|
||||
- 排除项 A
|
||||
|
||||
建议修正 Proposal 或更新共识。
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **必须使用 Question_tool** - 不要用纯文本确认
|
||||
- **逐维度确认** - 四个维度分开确认，不要合并
|
||||
- **不要跳过确认** - 每个维度都必须让用户明确确认
|
||||
- **不要自作主张** - 只整理讨论中明确提到的内容
|
||||
- **避免模糊表述** - "尽量"、"可能"、"考虑"等词汇需要明确化
|
||||
- **验收标准必须可测量** - 避免"性能要好"这类无法验证的标准
|
||||
|
||||
---
|
||||
|
||||
## 与其他 Skills 的关系
|
||||
|
||||
| Skill | 关系 |
|
||||
|-------|------|
|
||||
| `openspec-explore` | 探索结束后触发 lock |
|
||||
| `openspec-new-change` | lock 后触发 new（如果 change 不存在）|
|
||||
| `openspec-continue-change` | 生成 proposal 时读取 consensus 验证 |
|
||||
| `openspec-generate-acceptance-tests` | 从 consensus 的验收标准生成测试骨架 |
|
||||
Reference in New Issue
Block a user