重置项目上下文与规范文档

openspec/config.yaml

@@ -1,147 +1 @@
-# OpenSpec Configuration
-# https://github.com/Fission-AI/OpenSpec
-
 schema: spec-driven
-
-# 项目上下文 - 注入到所有 artifacts（proposal, specs, design, tasks）
-context: |
-  ## 项目概述
-  junhong_cmp_fiber 是一个基于 Go + Fiber 的企业级中后台管理系统（Content Management Platform），
-  专注于物联网卡和号卡的全生命周期管理，支持代理商体系和分佣结算。
-
-  ## 核心技术栈
-  - **后端框架**: Go 1.25.4 + Fiber v2.x（HTTP）+ GORM v1.25.x（ORM）
-  - **数据存储**: PostgreSQL 14+ + Redis 6.0+
-  - **基础设施**: Asynq v0.24.x（任务队列）+ Viper（配置）+ Zap（日志）
-  - **JSON 序列化**: sonic（优先），encoding/json（必要时）
-  - **验证**: Validator
-
-  ## 架构分层（严格遵守）
-  ```
-  Handler → Service → Store → Model
-  ```
-  - **Handler**: 仅处理 HTTP 请求/响应，参数验证，无业务逻辑
-  - **Service**: 所有业务逻辑，支持跨模块调用
-  - **Store**: 统一数据访问，支持事务
-  - **Model**: 数据结构和 DTO
-
-  ## 核心约束
-  - ❌ 禁止使用 `database/sql` 直接调用（必须用 GORM）
-  - ❌ 禁止使用 `net/http` 替代 Fiber
-  - ❌ 禁止使用外键约束和 GORM 关联关系（foreignKey, hasMany, belongsTo）
-  - ✅ 表关联通过 ID 字段手动维护，代码层显式查询
-  - ✅ Go 惯用模式：扁平化包结构、小接口、组合优于继承、显式错误返回
-  - ✅ 遵循 gofmt、Effective Go、Go Code Review Comments
-
-  ## 语言要求
-  - 交互、注释、文档、日志、错误消息：中文
-  - 变量名、函数名、类型名：英文（Go 命名规范）
-  - Git commit：中文
-
-  ## 性能要求
-  - API P95 < 200ms，P99 < 500ms
-  - 数据库查询 < 50ms
-  - 列表查询必须分页（默认 20，最大 100）
-
-  ## 测试要求
-  - 核心业务逻辑测试覆盖率 ≥ 90%
-  - 所有 API 端点必须有集成测试
-  - 使用 table-driven tests
-
-# 每个 artifact 的特定规则
-rules:
-  proposal:
-    - 必须检查技术栈合规性（Fiber、GORM、Viper、Zap、Asynq）
-    - 必须说明架构分层（Handler → Service → Store → Model）
-    - 必须包含测试计划和性能考虑
-    - 文档使用中文，代码命名使用英文
-    - 包含功能 ID（如 feature-001-xxx）
-
-  specs:
-    - API 规格必须定义统一响应格式 {code, message, data, timestamp}
-    - 错误码在 pkg/errors/ 中定义，使用双语错误消息
-    - 数据模型禁止使用外键和 GORM 关联，关联通过 ID 维护
-    - 必须明确数据权限规则（基于用户类型和店铺层级）
-    - Redis key 必须使用函数生成：Redis{Module}{Purpose}Key(params...)
-
-  design:
-    - 严格遵循 Handler → Service → Store → Model 分层
-    - 必须说明依赖注入方式（结构体字段注入）
-    - 必须包含事务处理设计（如涉及多表操作）
-    - 必须定义常量在 pkg/constants/（禁止硬编码）
-    - 异步任务使用 Asynq，必须支持重试和幂等性
-    - 性能敏感操作必须考虑 Redis 缓存
-
-  tasks:
-    # 契约规则
-    - tasks.md 是契约，不可擅自变更
-    - 禁止跳过任务、合并任务、简化任务（除非获得许可）
-    - 必须逐项完成并标记状态
-    
-    # TDD 工作流（必须遵守）
-    - "任务组 0 必须是测试准备：生成测试 + 运行确认全部 FAIL"
-    - "按功能单元组织任务，而非按技术层级（Store/Service/Handler）"
-    - "每个功能单元完成后必须有验证步骤：运行相关测试确认 PASS"
-    - "最终验证必须包含：全部验收测试 PASS + 全部流程测试 PASS"
-    
-    # 任务组结构模板
-    # ```
-    # ## 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 完整测试套件无回归
-    # ```
-    
-    # 其他规则
-    - 每个任务必须包含验证步骤（单元测试、集成测试、lsp_diagnostics）
-    - 数据库变更必须包含迁移文件（使用 golang-migrate）
-    - 新增 Handler 必须更新文档生成器（cmd/api/docs.go 和 cmd/gendocs/main.go）
-
-  # 共识锁定规则
-  consensus:
-    - 在 /opsx:explore 讨论后，必须使用 /opsx:lock 锁定共识
-    - consensus.md 必须包含四个维度：要做什么、不做什么、关键约束、验收标准
-    - 每个维度必须由用户逐条确认（不能一次性确认全部）
-    - 验收标准必须是可测量的（禁止模糊表述如"性能要好"）
-    - proposal 生成时必须验证与 consensus 的一致性
-
-  # 验收测试规则
-  acceptance_tests:
-    - Spec 的每个 Scenario 必须对应一个验收测试用例
-    - 验收测试在实现前生成，预期全部 FAIL
-    - 每个测试必须包含"破坏点"注释（说明什么代码变更会导致失败）
-    - 测试使用 table-driven 模式（同一 API 多场景）
-    - 测试文件位置：tests/acceptance/{capability}_acceptance_test.go
-    - 验收测试使用 IntegrationTestEnv，不要 mock 依赖
-
-  # 业务流程测试规则
-  business_flow_tests:
-    - Spec 必须包含 Business Flows 部分（多 API 业务场景）
-    - 每个 Business Flow 对应一个流程测试
-    - 流程测试的 steps 之间共享状态（如 ID）
-    - 每个 step 必须声明依赖（依赖哪些前置 step）
-    - 每个 step 必须包含"破坏点"注释
-    - 测试文件位置：tests/flows/{capability}_{flow}_flow_test.go
-
-  # 测试金字塔比例
-  test_pyramid:
-    - 验收测试（单 API 契约）：30%
-    - 流程测试（多 API 业务场景）：15%
-    - 集成测试（组件集成）：25%
-    - 单元测试（复杂逻辑）：30%
-    - 单元测试仅保留：纯函数、状态机、复杂业务规则、边界条件
-    - 单元测试删除：简单 CRUD、DTO 转换、配置读取