移除已弃用的文件：content_upload.py、content-manager.html、middleware.ts，以及与VIP会员和内容管理相关的各种API路由。此次清理通过移除未使用的代码和文件，提高了项目的可维护性
This commit is contained in:
乘风
@@ -1,11 +1,23 @@
|
||||
# API 稳定性与提现模块开发规范
|
||||
---
|
||||
description: next-project API 稳定性与提现规范（仅 next-project 参考，soul-api 为 Go 不适用）
|
||||
globs: ["next-project/**/*"]
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# API 稳定性与提现模块开发规范（next-project）
|
||||
|
||||
**适用范围**：本规则仅适用于 **next-project**（Next.js + lib/db.ts）。当前线上后端为 **soul-api**（Go + GORM），不涉及 `query()`、`toArray`、`ensureTableExists`，请勿在 soul-api 中套用本规则。
|
||||
|
||||
## 核心原则
|
||||
在本项目中开发 API（尤其是涉及财务和管理后台的接口）时，必须遵守以下稳定性规则，以防止常见的 JavaScript 运行时错误。
|
||||
|
||||
在 **next-project** 中开发 API（尤其是涉及财务和管理后台的接口）时，必须遵守以下稳定性规则，以防止常见的 JavaScript 运行时错误。
|
||||
|
||||
## 1. 数据库查询安全性 (防御 `undefined.length`)
|
||||
|
||||
**问题背景**：`lib/db.ts` 中的 `query()` 在网络波动或表不存在时可能返回 `undefined`。
|
||||
|
||||
**要求**：
|
||||
|
||||
- 所有调用 `query()` 的结果必须经过 `toArray` 处理。
|
||||
- 在 API 文件顶部定义 `toArray` 辅助函数：
|
||||
```typescript
|
||||
@@ -18,12 +30,16 @@ function toArray<T>(x: any): T[] {
|
||||
- 使用方式：`const rows = toArray(await query(sql))`。
|
||||
|
||||
## 2. 数据库自愈 (Self-Healing Tables)
|
||||
|
||||
**要求**：
|
||||
|
||||
- 在 `GET` 接口逻辑开始前，必须调用 `ensureTableExists()` 函数。
|
||||
- 确保核心表（如 `withdrawals`）在查询前已存在，避免 `Table 'xxx' doesn't exist` 导致的 500 错误。
|
||||
|
||||
## 3. 提现模块状态映射
|
||||
|
||||
**映射标准**：
|
||||
|
||||
- **数据库存值**：`pending` (待处理), `processing` (处理中), `success` (成功), `failed` (失败)
|
||||
- **前端显示值**：`pending`, `processing`, `completed` (已完成), `rejected` (已拒绝)
|
||||
- **转换逻辑**：
|
||||
@@ -32,6 +48,7 @@ const displayStatus = dbStatus === 'success' ? 'completed' : (dbStatus === 'fail
|
||||
```
|
||||
|
||||
## 4. 财务字段处理
|
||||
|
||||
- **金额转换**：从数据库读取的 `decimal` 类型必须经过 `parseFloat()` 转换后再进行数学运算。
|
||||
- **配置归一化**：分成比例字段（如 `distributorShare`）必须兼容 `90` 和 `0.9` 两种存值：
|
||||
```typescript
|
||||
@@ -40,11 +57,14 @@ if (rate >= 1) rate = rate / 100; // 将 90 转为 0.9
|
||||
```
|
||||
|
||||
## 5. 管理后台列表必备字段
|
||||
|
||||
所有管理后台的 API 必须包含以下映射字段以支持通用 UI 组件：
|
||||
|
||||
- `user_name` 或 `userNickname`: 展示用户名称。
|
||||
- `userAvatar`: 展示头像（若无，前端需展示首字母）。
|
||||
- `status`: 统一后的显示状态。
|
||||
- `amount`: 格式化后的数字金额。
|
||||
|
||||
## 6. 调试模式
|
||||
|
||||
- 遇到顽固 500 错误时，优先采用“最小化接口法”：移除所有业务逻辑，仅返回 `{success: true, data: []}`，确认通路正常后再分步加回代码。
|
||||
32
.cursor/rules/soul-admin-boundary.mdc
Normal file
32
.cursor/rules/soul-admin-boundary.mdc
Normal file
@@ -0,0 +1,32 @@
|
||||
---
|
||||
description: 管理端边界约束，防止与小程序/API 路径互窜
|
||||
globs: soul-admin/**/*
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# 管理端开发边界（防互窜）
|
||||
|
||||
在 **soul-admin/** 下新增、优化或编辑任何代码时，必须遵守以下约束：
|
||||
|
||||
## API 路径（强制）
|
||||
|
||||
- **允许**：仅使用 soul-api 中面向管理端的路径，例如：
|
||||
- `/api/admin`、`/api/admin/logout`、`/api/admin/withdrawals`、`/api/admin/chapters`、`/api/admin/content`、`/api/admin/settings` 等；
|
||||
- `/api/db/users`、`/api/db/config/full`、`/api/db/chapters` 等；
|
||||
- `/api/orders` 等与现网一致的管理端接口。
|
||||
- **禁止**：
|
||||
- 不得调用 `/api/miniprogram/*`（小程序专属，如 miniprogram/login、miniprogram/book、miniprogram/withdraw 等）。
|
||||
- 不得在管理端实现「使用小程序登录或小程序 token」的业务逻辑。
|
||||
- **请求方式**：统一通过 `src/api/client.ts` 的 `get`、`post`、`put`、`del`、`request`；鉴权使用 `src/api/auth.ts` 的 admin_token（Bearer）。
|
||||
|
||||
## 目录与职责
|
||||
|
||||
- 仅修改 **soul-admin/** 内文件（含 src/pages、src/components、src/api、src/layouts 等）。
|
||||
- 不在此处实现小程序逻辑；不在此处编写 soul-api 的 Go 代码或 miniprogram 的 WXML/WXSS/JS。
|
||||
|
||||
## 参考
|
||||
|
||||
- 代码风格、业务逻辑与 API 对接细节见 **.cursor/skills/SKILL-管理端开发.md**。
|
||||
- 接口实现与路由分组见 soul-api 的 `.cursor/rules/soul-api-coding.mdc` 与 **.cursor/skills/SKILL-API开发.md**。
|
||||
|
||||
违反上述路径或职责边界即视为「互窜」，需纠正后再提交。
|
||||
33
.cursor/rules/soul-api-boundary.mdc
Normal file
33
.cursor/rules/soul-api-boundary.mdc
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
description: soul-api 路由与使用方边界，防止管理端与小程序接口互窜
|
||||
globs: soul-api/**/*.go
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# soul-api 开发边界（防互窜）
|
||||
|
||||
在 **soul-api/** 下新增、优化或编辑 Go 代码（尤其是路由与 handler）时，必须遵守以下约束：
|
||||
|
||||
## 路由按使用方归类（强制）
|
||||
|
||||
- **仅管理端用的接口**：只挂在 `admin` 或 `db` 组（`/api/admin/*`、`/api/db/*`），**不得**在 `miniprogram` 组注册。
|
||||
- **仅小程序用的接口**：只挂在 `miniprogram` 组（`/api/miniprogram/*`），**不得**仅在 admin/db 下注册而让小程序去调 `/api/xxx`。
|
||||
- **两端共用的接口**：在 `api` 下挂一份，并在 `miniprogram` 组内用同一 handler 再挂一遍，保证小程序统一走 `/api/miniprogram/xxx`；handler 注释中标明使用方（如「小程序-提现记录」「管理端-提现列表」）。
|
||||
|
||||
## 禁止行为
|
||||
|
||||
- 禁止在 `miniprogram` 组挂仅管理端调用的接口（如后台审核、DB 初始化）。
|
||||
- 禁止在 `admin`/`db` 组挂小程序专属逻辑（如 wx code 登录、小程序码生成），除非该逻辑同时以「管理端可用的形式」在 admin 下提供。
|
||||
- 禁止在 handler 内混用「管理端路径」与「小程序路径」的语义（如根据 path 分支写两套业务而不按使用方拆 handler/路由）。
|
||||
|
||||
## 目录与职责
|
||||
|
||||
- 路由注册仅在 **internal/router** 中修改；handler 在 **internal/handler**；model 在 **internal/model**；配置在 **internal/config**；微信/支付在 **internal/wechat**。
|
||||
- 新增接口流程：先确定使用方（小程序 / 管理端 / 共用） → 再决定挂到哪个 Group → 再实现或修改 handler。
|
||||
|
||||
## 参考
|
||||
|
||||
- 完整编码规范与 GORM/响应约定见 **.cursor/rules/soul-api-coding.mdc**。
|
||||
- 归纳与对接要点见 **.cursor/skills/SKILL-API开发.md**。
|
||||
|
||||
违反上述路由归类或职责边界即视为「互窜」，需纠正后再提交。
|
||||
@@ -53,6 +53,8 @@ alwaysApply: false
|
||||
- **两端共用的接口**：在 `router.go` 里两处都注册同一 handler：先写在 `api` 的对应区块（如「推荐」「用户」），再在 `// ----- 小程序组 -----` 里用 `miniprogram.GET/POST(... path, handler.XXX)` 挂一遍，保证小程序统一走 `/api/miniprogram/xxx`。
|
||||
- handler 注释和路由注释中标明使用方，例如：`// GET /api/miniprogram/withdraw/records 小程序-提现记录`、`// GET /api/admin/withdrawals 管理端-提现列表`。
|
||||
|
||||
**管理端列表接口返回约定**：列表类接口（如 withdrawals、orders、users）的响应应包含 soul-admin 通用展示所需字段：`user_name` 或 `userNickname`、`userAvatar`、`status`、`amount`（金额用数字）。提现状态：数据库存值 `pending`/`processing`/`success`/`failed`，前端展示可映射 `success`→`completed`、`failed`→`rejected`。
|
||||
|
||||
## 5. 目录与包约定
|
||||
|
||||
- `cmd/server/main.go`：入口，只做 config/database/wechat/router 的初始化与启停。
|
||||
|
||||
35
.cursor/rules/soul-change-checklist.mdc
Normal file
35
.cursor/rules/soul-change-checklist.mdc
Normal file
@@ -0,0 +1,35 @@
|
||||
---
|
||||
description: 变更时关联层检查清单，防止漏改（前端/后端/管理端/表结构）
|
||||
globs: ["miniprogram/**/*", "soul-admin/**/*", "soul-api/**/*"]
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# Soul 创业派对 - 变更关联检查清单（防漏改）
|
||||
|
||||
在 **miniprogram/**、**soul-admin/** 或 **soul-api/** 下做任何**修改、优化、新增**后，必须按下列项过一遍，确认关联层已同步，避免只改一端导致数据不一致或功能缺管理入口。
|
||||
|
||||
## 一、按「你改了什么」对表检查
|
||||
|
||||
| 你改的是… | 必须同时检查/修改的关联 |
|
||||
|-----------|--------------------------|
|
||||
| **前端（小程序或管理端）** 新增/改了**字段**或**接口入参/出参** | soul-api 对应接口的 request/response、model 是否已改？数据库表是否有对应列（无则加迁移/字段）？ |
|
||||
| **小程序** 新增或改了一个**功能**（页面、能力、配置项） | soul-api 是否已有或需新增接口（挂到 `/api/miniprogram/...`）？**管理端**是否需要对应的**配置、审核、统计、列表**？ |
|
||||
| **管理端** 新增或改了**列表/表单/配置项** | soul-api 的 admin/db 接口是否已提供对应数据或写接口？字段名与类型是否与前端一致？ |
|
||||
| **soul-api** 新增/改了**接口**（路径、请求体、响应体、model） | 小程序或管理端是否有**调用处**？类型/字段是否已同步更新？若改了表结构，迁移是否已加？ |
|
||||
| **soul-api** 新增/改了**表或字段** | 相关 handler、model 是否已改？是否有接口暴露给小程序/管理端？若有，前端是否已对接？ |
|
||||
|
||||
## 二、按「业务功能」想三端
|
||||
|
||||
以**功能/领域**为单位（如：提现、推荐、章节权限、找伙伴、配置项），问一句：
|
||||
|
||||
- **小程序**：用户侧是否已实现/已更新？
|
||||
- **soul-api**：接口是否在正确路由组（miniprogram / admin / db）、请求响应是否一致？
|
||||
- **管理端**：该功能是否需要**配置、审核、统计、列表**？有则需在 soul-admin 与 soul-api 的 admin/db 下补齐。
|
||||
|
||||
## 三、执行约定
|
||||
|
||||
- **每次**在 miniprogram、soul-admin、soul-api 内完成一轮修改后，**先过一遍上表 + 二**，再视为本次变更完成。
|
||||
- 若本次变更涉及多端（例如小程序新功能 + 管理端配置页），应在同一次任务内一并完成或明确记录未做项，避免漏改。
|
||||
- 更详细的「如何做关联检查、以领域为单位思考」见 **.cursor/skills/SKILL-变更关联检查.md**。
|
||||
|
||||
未通过上述检查即提交视为可能漏改，需补全后再提交。
|
||||
29
.cursor/rules/soul-miniprogram-boundary.mdc
Normal file
29
.cursor/rules/soul-miniprogram-boundary.mdc
Normal file
@@ -0,0 +1,29 @@
|
||||
---
|
||||
description: 小程序端边界约束，防止与管理端/API 路径互窜
|
||||
globs: miniprogram/**/*
|
||||
alwaysApply: false
|
||||
---
|
||||
|
||||
# 小程序端开发边界（防互窜）
|
||||
|
||||
在 **miniprogram/** 下新增、优化或编辑任何代码时，必须遵守以下约束：
|
||||
|
||||
## API 路径（强制）
|
||||
|
||||
- **允许**：仅使用以 `/api/miniprogram/` 开头的接口路径（与 soul-api 的 miniprogram 路由组一致）。
|
||||
- **禁止**：
|
||||
- 不得使用 `/api/admin/*`、`/api/db/*`（管理端专属）。
|
||||
- 不得使用未在 soul-api 的 miniprogram 组下注册的路径（如仅存在于 next-project 的接口）。
|
||||
- **请求方式**：统一通过 `getApp().request(url, options)` 发起，不在页面内直接写死 baseUrl 或使用 `wx.request` 拼管理端路径。
|
||||
|
||||
## 目录与职责
|
||||
|
||||
- 仅修改 **miniprogram/** 内文件（含 pages、components、utils、app.js 等）。
|
||||
- 不在此处实现或引用管理端逻辑；不在此处编写 soul-api 的 Go 代码或 soul-admin 的 React 代码。
|
||||
|
||||
## 参考
|
||||
|
||||
- 代码风格、业务逻辑与 API 对接细节见 **.cursor/skills/SKILL-小程序开发.md**。
|
||||
- 接口实现与路由分组见 soul-api 的 `.cursor/rules/soul-api-coding.mdc` 与 **.cursor/skills/SKILL-API开发.md**。
|
||||
|
||||
违反上述路径或职责边界即视为「互窜」，需纠正后再提交。
|
||||
33
.cursor/rules/soul-project-boundary.mdc
Normal file
33
.cursor/rules/soul-project-boundary.mdc
Normal file
@@ -0,0 +1,33 @@
|
||||
---
|
||||
description: Soul 创业派对项目整体边界与 Skill 索引，防止子项目互窜
|
||||
globs: ["**"]
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Soul 创业派对 - 项目边界与开发约束
|
||||
|
||||
## 项目组成
|
||||
|
||||
| 子项目 | 目录 | 用途 | 后端对接 |
|
||||
|--------------|---------------|--------------------------|------------|
|
||||
| 小程序 | miniprogram/ | 微信原生小程序 C 端 | soul-api |
|
||||
| 管理端 | soul-admin/ | React 管理后台 | soul-api |
|
||||
| API 后端 | soul-api/ | Go + Gin + GORM 接口服务 | - |
|
||||
| 预览/参考 | next-project/ | 仅预览，非当前线上后端 | 不依赖 |
|
||||
|
||||
- **线上约定**：小程序与管理端均只对接 **soul-api**；next-project 不参与当前线上联调与部署。
|
||||
|
||||
## 防互窜原则
|
||||
|
||||
1. **小程序**：只调 `/api/miniprogram/*`；不调 `/api/admin/*`、`/api/db/*`。详见 **soul-miniprogram-boundary.mdc** 与 **.cursor/skills/SKILL-小程序开发.md**。
|
||||
2. **管理端**：只调 `/api/admin/*`、`/api/db/*` 等管理端路径；不调 `/api/miniprogram/*`。详见 **soul-admin-boundary.mdc** 与 **.cursor/skills/SKILL-管理端开发.md**。
|
||||
3. **soul-api**：按使用方挂路由（admin/db vs miniprogram）；不在 miniprogram 组挂管理端专用接口，不在 admin/db 组挂小程序专属接口。详见 **soul-api-boundary.mdc**、**soul-api-coding.mdc** 与 **.cursor/skills/SKILL-API开发.md**。
|
||||
4. **next-project**：仅参考用；新增/优化功能以 miniprogram、soul-admin、soul-api 为准。详见 **.cursor/skills/SKILL-next-project仅预览.md**。
|
||||
|
||||
## 开发时
|
||||
|
||||
- 在 **miniprogram/** 下编辑 → 遵守 soul-miniprogram-boundary 并参考 **.cursor/skills/SKILL-小程序开发.md**。
|
||||
- 在 **soul-admin/** 下编辑 → 遵守 soul-admin-boundary 并参考 **.cursor/skills/SKILL-管理端开发.md**。
|
||||
- 在 **soul-api/** 下编辑 → 遵守 soul-api-boundary 与 soul-api-coding 并参考 **.cursor/skills/SKILL-API开发.md**。
|
||||
- 涉及「该接口给谁用」时，先确定使用方再写/改代码，避免路径混用或跨子项目逻辑互窜。
|
||||
- **每次修改/优化后**：按 **soul-change-checklist.mdc** 过一遍关联层检查，避免漏改；流程与思路见 **.cursor/skills/SKILL-变更关联检查.md**。
|
||||
@@ -1,25 +0,0 @@
|
||||
---
|
||||
description: 存客宝 AI 集成与项目开发工作流
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# 存客宝 AI 项目开发工作流
|
||||
|
||||
## 1. 前置工作流
|
||||
|
||||
每次对话开始时，**先用本机小模型全量读取并调用** `Z:\SynologyDrive\存客宝AI` 的能力，再开始后续开发。
|
||||
|
||||
## 2. 开发与验证
|
||||
|
||||
- **每次使用**时调用存客宝 AI，对当前项目进行验证与开发
|
||||
- 每次对话时，结合存客宝 AI 的**多功能同步讨论**来修改代码
|
||||
- 将上述流程同步更新到对应 Skill
|
||||
|
||||
## 3. 项目级 Skill 生成
|
||||
|
||||
开发过程中，需从存客宝 AI 抽取能力并生成针对本项目的 Skill：
|
||||
|
||||
1. 该 Skill 用于管理整个项目，应继承存客宝 AI 的相应功能，并结合本项目已有代码与架构
|
||||
2. **详细阅读**项目内所有代码
|
||||
3. 按你认为**最佳分工方式**，对项目代码的各个域进行模块划分
|
||||
4. 将生成的 Skill 命名为合适的中文名称，放在**项目根目录**下
|
||||
Reference in New Issue
Block a user