chore(qoder): 删除过时的指令和规则文档
- 移除 .qoder 目录下所有指令同步相关的 Markdown 文件 - 删除代码审查、创建PR、记忆同步、项目测试、安全检查等指令文档 - 清理后端API服务编码规范及代码修改规范相关规则文件 - 删除项目规则索引及需求文档编写规范的规则文件 - 移除 VSCode 的 PlantUML 配置文件 settings.json - 减少项目冗余文档，优化存储空间与项目结构
This commit is contained in:
parent
687f2ab37f
commit
0adeea7a06
|
|
@ -1,25 +0,0 @@
|
|||
# Qoder 指令同步文件
|
||||
|
||||
> 持久化存储项目指令，解决账号切换导致指令丢失。由 AI 自动维护，请勿手动编辑。
|
||||
|
||||
**最后更新时间:** 2026-03-05
|
||||
|
||||
---
|
||||
|
||||
## 指令列表
|
||||
|
||||
| 指令 | 说明 | 文件 |
|
||||
|------|------|------|
|
||||
| `/code-inspect` | 代码审查（技术评估、安全合规、质量评估） | `commands/code-inspect.md` |
|
||||
| `/create-pr` | 创建PR（代码提交流程、质量门禁） | `commands/create-pr.md` |
|
||||
| `/project-test` | 项目测试（单元/集成/冒烟测试） | `commands/project-test.md` |
|
||||
| `/security-check` | 安全检查（漏洞检测、威胁防御、合规验证） | `commands/security-check.md` |
|
||||
| `/memory-sync` | 记忆同步（项目记忆持久化同步） | `commands/memory-sync.md` |
|
||||
| `/start-store` | 启动商家后台（localhost:8120，Vue 2 + Ant Design Vue） | `commands/start-store.md` |
|
||||
| `/start-admin` | 启动超管后台（localhost:8110，Vue 2 + Ant Design Vue） | `commands/start-admin.md` |
|
||||
|
||||
## 同步规则
|
||||
|
||||
- 指令文件变更时自动同步到本文件
|
||||
- 启动时检查：文件中存在但系统缺失的指令需反向同步
|
||||
- 指令文件位于 `.qoder/commands/` 目录
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
description:
|
||||
---
|
||||
# 代码审查 (code-inspect)
|
||||
|
||||
##概
|
||||
用于评估源代码的系统化框架，以验证技术卓越性、稳健性和安全合规性。
|
||||
|
||||
## 评估领域
|
||||
|
||||
### 技术实现
|
||||
-准确实现
|
||||
-算效率
|
||||
-管理
|
||||
-性能考虑
|
||||
-系统集成
|
||||
|
||||
### 开发标准
|
||||
- 设计模式
|
||||
- 代码模块化
|
||||
- 文档完整性
|
||||
-测试覆盖
|
||||
- 日志实现
|
||||
-错误处理
|
||||
|
||||
###管理管理
|
||||
-安全最佳实践
|
||||
- 数据验证
|
||||
-身验证
|
||||
-授权规则
|
||||
- API安全
|
||||
|
||||
###维护方面
|
||||
- 代码可维护性
|
||||
- 依赖管理
|
||||
-版本兼容性
|
||||
-技术债务
|
||||
|
||||
## 使用方法
|
||||
在对话中输入 `/code-inspect`触发代码审查流程。
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
description:
|
||||
---
|
||||
# 创建PR (create-pr)
|
||||
|
||||
## 概述
|
||||
用于提交代码更改的标准化流程，包含全面的文档和验证要求。
|
||||
|
||||
## 主要步骤
|
||||
|
||||
### 1. 代码质量保证
|
||||
-分析
|
||||
-格验证
|
||||
-移除未使用代码
|
||||
- 更新注释
|
||||
-测试覆盖
|
||||
|
||||
### 2.变更文档
|
||||
- 实现细节
|
||||
-技术决策
|
||||
-性能影响
|
||||
-迁步骤
|
||||
-回程序
|
||||
|
||||
### 3. 测试验证
|
||||
-单元测试套件
|
||||
-测试
|
||||
-冒测试
|
||||
- UI/UX验证
|
||||
-跨测试
|
||||
|
||||
##门禁
|
||||
- 代码审查通过
|
||||
-安全审查通过
|
||||
-性能标准符合
|
||||
- CI/CD绿色
|
||||
|
||||
## 使用方法
|
||||
在对话中输入 `/create-pr`触发PR创建流程。
|
||||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
description:
|
||||
---
|
||||
#记忆同步 (memory-sync)
|
||||
|
||||
## 概述
|
||||
用于同步项目记忆与 `.qoder/memory-sync.md` 文件的指令，解决账号切换导致的记忆丢失问题。
|
||||
|
||||
##同步流程
|
||||
|
||||
### 1.系统 → 文件检查
|
||||
-扫描系统记忆
|
||||
-对比文件内容
|
||||
-识别变更
|
||||
|
||||
### 2. 文件 →系统检查
|
||||
-读取文件
|
||||
-检查缺失记忆
|
||||
-准备反向同步
|
||||
|
||||
### 3.执行同步
|
||||
-写入文件
|
||||
-导入系统
|
||||
-更新时间
|
||||
|
||||
##同步内容
|
||||
|
||||
### 项目配置记忆
|
||||
-目录结构
|
||||
-命名约定
|
||||
-技术栈版本
|
||||
|
||||
###环境配置记忆
|
||||
-启动命令
|
||||
-口配置
|
||||
-数据库连接
|
||||
- Docker部署
|
||||
|
||||
### 开发工作流记忆
|
||||
-构建步骤
|
||||
-测试命令
|
||||
-代码规范
|
||||
|
||||
## 使用方法
|
||||
在对话中输入 `/memory-sync`执行记忆同步。
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
---
|
||||
description:
|
||||
---
|
||||
# 项目测试 (project-test)
|
||||
|
||||
## 概述
|
||||
执行项目测试套件并通过系统化故障排除和验证解决检测到的问题。
|
||||
|
||||
## 测试阶段
|
||||
|
||||
### 1. 环境设置
|
||||
-验证开发环境
|
||||
-检查依赖状态
|
||||
-确认测试数据
|
||||
-验证配置
|
||||
|
||||
### 2.测试执行
|
||||
-单元测试套件
|
||||
-测试
|
||||
-冒测试
|
||||
-代码覆盖率检查
|
||||
|
||||
### 3. 问题解决
|
||||
-记录失败
|
||||
-分析错误模式
|
||||
-调试用例
|
||||
-实施修复
|
||||
|
||||
##验证矩阵
|
||||
|
||||
###核测试测试
|
||||
-单元测试
|
||||
- API测试
|
||||
-数据库测试
|
||||
-缓存行为
|
||||
|
||||
###系统健康
|
||||
-内存使用
|
||||
-响应时间
|
||||
-错误率
|
||||
-资源利用
|
||||
|
||||
## 使用方法
|
||||
在对话中输入 `/project-test`执行项目测试。
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
---
|
||||
description:
|
||||
---
|
||||
#安全检查 (security-check)
|
||||
|
||||
## 概述
|
||||
系统安全态势的系统化检查，专注于漏洞检测、威胁防御和合规验证。
|
||||
|
||||
## 评估领域
|
||||
|
||||
### 1.应用安全
|
||||
-漏洞扫描
|
||||
-安全补丁状态
|
||||
-框架安全审计
|
||||
-库版本控制
|
||||
|
||||
### 2.认证系统
|
||||
-身管理审查
|
||||
-密码策略合规
|
||||
-多因素认证
|
||||
-会话管理审计
|
||||
|
||||
### 3. 数据保护
|
||||
-加密实现
|
||||
- 数据访问模式
|
||||
-隐私合规
|
||||
-备份安全
|
||||
|
||||
### 4. 系统架构
|
||||
-络分段
|
||||
-火墙配置
|
||||
-载均衡器安全
|
||||
- API网关保护
|
||||
|
||||
##验证要点
|
||||
|
||||
###核心要求
|
||||
-安全补丁
|
||||
-加密标准
|
||||
-访问控制
|
||||
-审计日志
|
||||
-入侵检测
|
||||
|
||||
###高级措施
|
||||
-透测试
|
||||
-安全监控
|
||||
-灾恢复
|
||||
-事件响应
|
||||
|
||||
## 使用方法
|
||||
在对话中输入 `/security-check`执行安全检查。
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
---
|
||||
trigger: model_decision
|
||||
description: 后端API服务编码规范、技术栈、开发流程，生成或修改后端API代码时参考
|
||||
---
|
||||
|
||||
# API 编码规范
|
||||
|
||||
**技术栈**: Go 1.22.2 + Fiber v2 + GORM + Redis + Wire
|
||||
|
||||
**项目结构**:
|
||||
- `biz/` - 业务层（接口定义）
|
||||
- `data/` - 数据层（接口实现、数据库）
|
||||
- `server/` - 路由层
|
||||
- `service/` - 应用服务层
|
||||
|
||||
**开发流程**:
|
||||
1. `conf/conf.go` - 添加配置
|
||||
2. `biz/repository/` - 定义仓储接口
|
||||
3. `data/repositoryimpl/` - 实现接口
|
||||
4. `data/provider_set.go` - 注册 Provider
|
||||
5. `server/http.go` - 添加路由
|
||||
6. `make wire` - 生成依赖注入代码
|
||||
7. 调用 code_review 进行代码评审
|
||||
|
||||
**常用命令**:
|
||||
```bash
|
||||
make wire # 生成 Wire
|
||||
make build # 构建
|
||||
```
|
||||
|
||||
**代码规范**:
|
||||
- 符合 Go 基本原则（命名清晰、错误处理、上下文传递）
|
||||
- 合理应用设计模式（工厂、策略、适配器等）
|
||||
- 遵循设计原则（SOLID、DRY、KISS）
|
||||
- 使用 TDD 驱动开发（先写测试，后写实现）
|
||||
- 禁止硬编码（配置化、常量提取）
|
||||
- 函数第一参数: `context.Context`
|
||||
- 导入路径前缀: `trans_hub/app/ymt/post_bank_point_mall/service/...`
|
||||
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
trigger: always_on
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# 代码修改规范
|
||||
|
||||
## 修改前必须执行的操作
|
||||
|
||||
在执行任何文件内容修改操作前，必须：
|
||||
|
||||
1. **评估修改的置信度**（高/中/低）
|
||||
2. **明确说明**：
|
||||
- 要修改的文件路径
|
||||
- 修改的具体内容和原因
|
||||
- 可能的影响范围
|
||||
- 置信度评估结果
|
||||
3. **等待用户明确授权**后再执行修改
|
||||
4. **禁止**在未获得确认的情况下直接修改文件
|
||||
|
||||
## 置信度评估标准
|
||||
|
||||
- **高置信度**：需求明确、影响范围清晰、修改方案标准化
|
||||
- **中置信度**：需求较明确但可能有多种实现方式、影响范围需确认
|
||||
- **低置信度**：需求模糊、影响范围不明确、可能存在多种理解方式
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
trigger: always_on
|
||||
glob: "**/*.md"
|
||||
ignore: ["doc/**"]
|
||||
---
|
||||
|
||||
# 通用规则
|
||||
|
||||
## 项目记忆同步
|
||||
|
||||
- 记忆变更时同步更新 `.qoder/memory-sync.md`；用户要求同步时检查文件，缺失的记忆反向同步回系统
|
||||
|
||||
## 技术栈版本管理
|
||||
|
||||
- 开发阶段使用最新稳定兼容版本，引入新依赖前确认版本兼容性
|
||||
|
||||
## 任务拆分与聚焦
|
||||
|
||||
- 每次任务小而聚焦，专注单一功能点，确保质量后再进行下一步
|
||||
- 复杂任务必须拆分为多个独立小任务，逐个完成
|
||||
- 完成标准：代码检查通过、功能验证通过、无遗留问题
|
||||
|
|
@ -1,41 +0,0 @@
|
|||
---
|
||||
trigger: model_decision
|
||||
description: 项目规则索引，查看所有规则文件及其适用场景时参考
|
||||
---
|
||||
|
||||
# 项目规则索引
|
||||
|
||||
## 通用规则（始终生效）
|
||||
|
||||
| 规则文件 | 适用场景 | 说明 |
|
||||
|---------|---------|------|
|
||||
| [general.md](./general.md) | 通用规则 | 记忆同步、技术栈版本管理、任务拆分规范 |
|
||||
| [code-modification.md](./code-modification.md) | 代码修改规范 | 修改前评估、置信度判断、获取授权 |
|
||||
|
||||
## 文档规则（按需触发）
|
||||
|
||||
| 规则文件 | 适用场景 | 加载条件 |
|
||||
|---------|---------|----------|
|
||||
| [requirements.md](./requirements.md) | 需求文档规范 | 生成需求文档时 |
|
||||
| [api.md](./api.md) | 后端API规范 | 生成、修改后端API代码时 |
|
||||
|
||||
## 项目相关信息
|
||||
|
||||
### 项目概述
|
||||
- **项目名称**: 邮储积分商城 (post-bank-point-mall)
|
||||
- **主要文档**:
|
||||
- 接口设计规范文档
|
||||
- 营销开放API文档
|
||||
- 序列图设计文档
|
||||
|
||||
### 目录结构
|
||||
```
|
||||
post-bank-point-mall/
|
||||
├── .qoder/
|
||||
│ └── rules/ # 项目规则文件
|
||||
├── docs/ # 项目文档
|
||||
│ ├── 接口设计规范文档
|
||||
│ ├── 营销API文档
|
||||
│ └── 序列图文件
|
||||
└── README.md # 项目说明
|
||||
```
|
||||
|
|
@ -1,52 +0,0 @@
|
|||
---
|
||||
trigger: model_decision
|
||||
description: 生成需求文档的时候需要
|
||||
---
|
||||
|
||||
# 需求文档编写规范
|
||||
|
||||
## 文档结构要求
|
||||
|
||||
必须且仅包含以下6个章节,顺序固定:
|
||||
|
||||
1. **功能模块划分**: 明确的模块结构和模块关系
|
||||
2. **功能详细说明**: 每个功能的具体描述、业务规则、验收标准
|
||||
3. **用户故事**: 从用户视角描述需求和期望价值
|
||||
4. **数据需求**: 数据实体、字段定义、数据规则
|
||||
5. **流程图**: 使用 PlantUml 语法实现,清晰展示业务流程和逻辑
|
||||
6. **附录**: 业务术语表及其他补充说明
|
||||
|
||||
## 用户故事格式
|
||||
|
||||
采用标准用户故事格式:
|
||||
|
||||
```
|
||||
作为 [用户角色]，我希望 [功能需求]，以便 [业务价值]
|
||||
```
|
||||
|
||||
- **用户角色**: 明确的角色定义（如：普通用户、管理员、运营人员）
|
||||
- **功能需求**: 具体的功能期望
|
||||
- **业务价值**: 该功能带来的价值或解决的问题
|
||||
|
||||
## 附录要求
|
||||
|
||||
### 业务术语表
|
||||
|
||||
| 术语 | 定义 | 示例 |
|
||||
|------|------|------|
|
||||
| 术语名称 | 准确的业务定义 | 具体使用示例 |
|
||||
|
||||
|
||||
## 需求描述要求
|
||||
|
||||
- **简洁**: 避免冗余和无关信息
|
||||
- **聚焦**: 只描述业务需求,不涉及实现方案
|
||||
- **明确无歧义**: 每个需求点都有准确定义,避免模糊表述
|
||||
|
||||
## 规则作用
|
||||
|
||||
保持需求文档的纯粹性,将需求分析与设计实现分离,通过流程图直观展示业务逻辑
|
||||
|
||||
## 规则重要性
|
||||
|
||||
确保需求文档聚焦业务价值和用户需求,便于需求评审、开发理解和后续变更管理
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
{
|
||||
"plantuml.commandArgs": [
|
||||
|
||||
],
|
||||
"plantuml.server": "https://www.plantuml.com/plantuml"
|
||||
}
|
||||
|
||||
Loading…
Reference in New Issue