Files
junhong_cmp_fiber/AGENTS.md
huang a924e63e68
All checks were successful
构建并部署到测试环境(无 SSH) / build-and-deploy (push) Successful in 4m42s
feat: 实现物联网卡独立管理和批量导入功能
新增物联网卡独立管理模块,支持单卡查询、批量导入和状态管理。主要变更包括:

功能特性:
- 新增物联网卡 CRUD 接口(查询、分页列表、删除)
- 支持 CSV/Excel 批量导入物联网卡
- 实现异步导入任务处理和进度跟踪
- 新增 ICCID 号码格式校验器(支持 Luhn 算法)
- 新增 CSV 文件解析工具(支持编码检测和错误处理)

数据库变更:
- 移除 iot_card 和 device 表的 owner_id/owner_type 字段
- 新增 iot_card_import_task 导入任务表
- 为导入任务添加运营商类型字段

测试覆盖:
- 新增 IoT 卡 Store 层单元测试
- 新增 IoT 卡导入任务单元测试
- 新增 IoT 卡集成测试(包含导入流程测试)
- 新增 CSV 工具和 ICCID 校验器测试

文档更新:
- 更新 OpenAPI 文档(新增 7 个 IoT 卡接口)
- 归档 OpenSpec 变更提案
- 更新 API 文档规范和生成器指南

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-01-24 11:03:43 +08:00

6.6 KiB
Raw Blame History

OpenSpec Instructions

These instructions are for AI assistants working in this project.

Always open @/openspec/AGENTS.md when the request:

  • Mentions planning or proposals (words like proposal, spec, change, plan)
  • Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
  • Sounds ambiguous and you need the authoritative spec before coding

Use @/openspec/AGENTS.md to learn:

  • How to create and apply change proposals
  • Spec format and conventions
  • Project structure and guidelines

Keep this managed block so 'openspec update' can refresh the instructions.


junhong_cmp_fiber 项目开发规范

重要: 本文件包含核心规范。详细规范已提取为 Skills在特定任务时按需加载。

专项规范 Skills按需加载

以下规范在相关任务时自动触发,无需手动加载:

任务类型 触发 Skill 说明
创建/修改 DTO 文件 dto-standards description 标签、枚举字段、验证标签规范
创建/修改 Model 模型 model-standards GORM 模型结构、字段标签、TableName 规范
注册 API 路由 / 新增 Handler api-routing Register() 函数、RouteSpec、文档生成器更新
测试接口/验证数据 db-validation PostgreSQL MCP 使用方法和验证示例
数据库迁移 db-migration 迁移命令、文件规范、执行流程、失败处理
维护规范文档 doc-management 规范文档流程和维护规则

⚠️ 新增 Handler 时必须同步更新文档生成器

新增 Handler 后,接口不会自动出现在 OpenAPI 文档中。必须手动更新以下两个文件

// cmd/api/docs.go 和 cmd/gendocs/main.go
handlers := &bootstrap.Handlers{
    // ... 添加新 Handler
    NewHandler: admin.NewXxxHandler(nil),
}

完整检查清单: 参见 docs/api-documentation-guide.md


语言要求

必须遵守:

  • 永远用中文交互
  • 注释必须使用中文
  • 文档必须使用中文
  • 日志消息必须使用中文
  • 用户可见的错误消息必须使用中文
  • 变量名、函数名、类型名必须使用英文(遵循 Go 命名规范)
  • GIT提交的commit必须使用中文

技术栈

必须严格遵守,禁止替代方案:

类型 技术
HTTP 框架 Fiber v2.x
ORM GORM v1.25.x
配置管理 Viper
日志 Zap + Lumberjack.v2
JSON 序列化 sonic优先encoding/json必要时
验证 Validator
任务队列 Asynq v0.24.x
数据库 PostgreSQL 14+
缓存 Redis 6.0+

禁止:

  • 直接使用 database/sql(必须通过 GORM
  • 使用 net/http 替代 Fiber
  • 使用 encoding/json 替代 sonic除非必要

架构分层

必须遵循以下分层架构:

Handler → Service → Store → Model
  • Handler: 只处理 HTTP 请求/响应,不包含业务逻辑
  • Service: 包含所有业务逻辑,支持跨模块调用
  • Store: 统一管理所有数据访问,支持事务处理
  • Model: 定义数据结构和 DTO

核心原则

错误处理

  • 所有错误必须在 pkg/errors/ 中定义
  • 使用统一错误码系统
  • Handler 层通过返回 error 传递给全局 ErrorHandler

响应格式

  • 所有 API 响应使用 pkg/response/ 的统一格式
  • 格式: {code, message, data, timestamp}

常量管理

  • 所有常量定义在 pkg/constants/
  • Redis key 使用函数生成: Redis{Module}{Purpose}Key(params...)
  • 禁止硬编码字符串和 magic numbers
  • 必须为所有常量添加中文注释

Go 代码风格

  • 使用 gofmt 格式化
  • 遵循 Effective Go
  • 包名: 简短、小写、单数、无下划线
  • 接口命名: 使用 -er 后缀Reader、Writer、Logger

数据库设计

核心规则:

  • 禁止建立外键约束
  • 禁止使用 GORM 关联关系标签foreignKey、hasMany、belongsTo
  • 关联通过存储 ID 字段手动维护
  • 关联数据在代码层面显式查询

Go 惯用法 vs Java 风格

Go 风格(推荐)

  • 扁平化包结构(最多 2-3 层)
  • 小而专注的接口1-3 个方法)
  • 直接访问导出字段(不用 getter/setter
  • 组合优于继承
  • 显式错误返回和检查

Java 风格(禁止)

  • 过度抽象(不必要的接口、工厂)
  • Getter/Setter 方法
  • 深层继承层次
  • 异常处理panic/recover
  • 类型前缀IService、AbstractBase、ServiceImpl

测试要求

  • 核心业务逻辑Service 层)测试覆盖率 ≥ 90%
  • 所有 API 端点必须有集成测试
  • 使用 table-driven tests
  • 单元测试 < 100ms集成测试 < 1s

测试连接管理(必读)

详细规范: docs/testing/test-connection-guide.md

标准模板:

func TestXxx(t *testing.T) {
    tx := testutils.NewTestTransaction(t)
    rdb := testutils.GetTestRedis(t)
    testutils.CleanTestRedisKeys(t, rdb)
    
    store := postgres.NewXxxStore(tx, rdb)
    // 测试代码...
}

核心函数:

  • NewTestTransaction(t): 创建测试事务,自动回滚
  • GetTestRedis(t): 获取全局 Redis 连接
  • CleanTestRedisKeys(t, rdb): 自动清理测试 Redis 键

禁止使用(已移除):

  • SetupTestDB / TeardownTestDB / SetupTestDBWithStore

性能要求

  • API P95 响应时间 < 200ms
  • API P99 响应时间 < 500ms
  • 数据库查询 < 50ms
  • 列表查询必须分页(默认 20最大 100
  • 避免 N+1 查询,使用批量操作

文档要求

  • 每个功能在 docs/{feature-id}/ 创建总结文档
  • 文档文件名和内容使用中文
  • 同步更新 README.md
  • 为导出的函数、类型编写文档注释

函数复杂度

  • 函数长度 ≤ 100 行(核心逻辑建议 ≤ 50 行)
  • main() 函数只做编排,不含具体实现
  • 遵循单一职责原则

访问日志

  • 所有 HTTP 请求记录到 access.log
  • 记录完整的请求/响应(限制 50KB
  • 包含: method, path, query, status, duration, request_id, ip, user_agent, user_id, bodies
  • 使用 JSON 格式,配置自动轮转

OpenSpec 工作流

创建提案前的检查清单:

  1. 技术栈合规
  2. 架构分层正确
  3. 使用统一错误处理
  4. 常量定义在 pkg/constants/
  5. Go 惯用法(非 Java 风格)
  6. 包含测试计划
  7. 性能考虑
  8. 文档更新计划
  9. 中文优先

详细规范和 OpenSpec 工作流请查看: @/openspec/AGENTS.md