项目初始化

02-用户侧流程/README.md

@@ -0,0 +1,9 @@
+# 用户侧流程
+
+本目录聚焦用户在微信小程序中的核心业务链路。
+
+## 包含内容
+- `用户报名参赛流程.md`
+- `支付流程.md`
+- `退款流程.md`
+- `消息通知与触达流程.md`

02-用户侧流程/支付流程.md

@@ -0,0 +1,47 @@
+# 支付流程
+
+## 1. 文档目标
+规范报名支付、订单生成、支付回调和支付成功后的状态同步逻辑，作为订单中心和小程序支付接入的依据。
+
+## 2. 参与角色
+| 角色 | 职责 |
+| --- | --- |
+| 用户 | 提交报名并完成支付 |
+| 微信小程序 | 拉起支付、展示支付结果 |
+| 后台 API | 创建订单、发起支付、处理回调 |
+| 支付渠道 | 执行实际扣款并回调支付结果 |
+
+## 3. 主流程
+1. 用户提交报名信息后，系统生成报名单与待支付订单。
+2. 后台 API 调用支付能力生成支付凭证。
+3. 小程序拉起微信支付。
+4. 用户完成支付。
+5. 支付成功后，支付渠道回调后台。
+6. 系统校验回调并更新订单、报名状态。
+7. 向用户发送报名成功通知。
+
+## 4. 异常分支
+- 支付取消：订单保持待支付或按规则关闭。
+- 支付失败：允许用户重新支付。
+- 超时未支付：系统自动关闭订单。
+- 回调异常：进入补偿与人工排查机制。
+
+## 5. 关键状态
+| 对象 | 状态 |
+| --- | --- |
+| 订单 | 待支付 / 已支付 / 已关闭 |
+| 报名单 | 待支付 / 已报名 / 已取消 |
+
+## 6. 风控与审计要求
+- 支付回调必须验签。
+- 重复回调需幂等处理。
+- 订单金额、支付单号、操作日志需完整留存。
+
+## 7. 关联文档
+- `退款流程.md`
+- `../04-平台治理流程/状态流转总表.md`
+
+## 8. 待确认事项
+- 平台抽佣时点：支付成功即抽佣，还是结算时扣除。
+- 商户结算周期：实时 / T+1 / 周结。
+- 是否支持合单支付或多人一单。

02-用户侧流程/消息通知与触达流程.md

@@ -0,0 +1,38 @@
+# 消息通知与触达流程
+
+## 1. 文档目标
+定义平台在关键业务节点的通知触达方式、模板归属和发送规则，保证用户、商户与平台运营能及时收到关键消息。
+
+## 2. 触达对象
+- 用户
+- 商户管理员/子账号
+- 平台审核员/运营管理员
+
+## 3. 触发场景
+| 场景 | 接收人 | 建议渠道 |
+| --- | --- | --- |
+| 报名成功 | 用户 | 小程序订阅消息 / 站内消息 |
+| 支付成功 | 用户 | 小程序订阅消息 |
+| 退款成功 | 用户 | 小程序订阅消息 / 短信 |
+| 赛事审核通过/驳回 | 商户 | 站内消息 / 邮件（如后续支持） |
+| 商户入驻审核结果 | 商户 | 站内消息 / 短信 |
+| 比赛开始前提醒 | 用户 | 小程序订阅消息 |
+| 成绩发布通知 | 用户 | 小程序订阅消息 |
+| 异常工单提醒 | 平台运营 | 管理后台待办 / 邮件（如后续支持） |
+
+## 4. 通知流程
+1. 业务事件发生。
+2. 后台 API 写入通知任务。
+3. 根据消息模板与用户授权情况选择发送渠道。
+4. 发送结果回写日志。
+5. 失败消息进入重试或人工补发机制。
+
+## 5. 控制点
+- 重要消息必须支持发送记录查询。
+- 模板内容应支持参数化。
+- 对高频通知做频控，避免骚扰用户。
+
+## 6. 待确认事项
+- 是否接入短信通道。
+- 是否支持站内信中心。
+- 是否需要给商户和平台发邮件通知。

02-用户侧流程/用户报名参赛流程.md

@@ -0,0 +1,54 @@
+# 用户报名参赛流程
+
+## 1. 适用角色
+- 用户（微信小程序）
+- 后台 API
+- 商户（间接受影响）
+
+## 2. 前置条件
+- 用户已完成微信授权登录。
+- 赛事已发布且处于“可报名”状态。
+- 对应组别/场次仍有余量。
+
+## 3. 主流程
+1. 用户进入小程序首页或赛事列表页。
+2. 浏览赛事详情，查看时间、地点、费用、组别、规则。
+3. 选择组别/场次并填写报名信息。
+4. 系统校验报名资格、库存、报名截止时间。
+5. 生成待支付报名单与订单。
+6. 用户完成微信支付。
+7. 系统回写支付结果，报名状态变为“报名成功”。
+8. 用户在“我的报名”中查看订单、参赛码、赛事通知。
+
+## 4. 异常分支
+- 超过报名截止时间：禁止提交。
+- 赛事名额已满：提示不可报名，可加入候补（若后续支持）。
+- 支付失败：保留待支付状态一段时间，支持重新拉起支付。
+- 赛事被下架/关闭：已下单但未支付的订单需自动关闭。
+
+## 5. 关键状态
+| 对象 | 状态 |
+| --- | --- |
+| 报名单 | 待支付 / 已报名 / 已取消 / 已退款 |
+| 订单 | 待支付 / 已支付 / 已关闭 / 已退款 |
+| 用户参赛资格 | 未获得 / 已获得 / 已核销 |
+
+## 6. 关键数据字段
+- 用户ID
+- 赛事ID
+- 组别ID
+- 报名人姓名/手机号
+- 证件或身份校验信息（如后续需要）
+- 支付金额
+- 报名时间
+
+## 7. 与系统的交互点
+- 用户中心：登录态、手机号授权
+- 订单系统：创建订单、支付回调
+- 消息通知：报名成功通知、赛前提醒
+- 成绩系统：赛后可查看成绩与排名
+
+## 8. 待确认事项
+- 是否允许代他人报名。
+- 是否支持多人一单或团体统一报名。
+- 报名成功后是否允许用户主动取消。

02-用户侧流程/退款流程.md

@@ -0,0 +1,49 @@
+# 退款流程
+
+## 1. 文档目标
+明确用户、商户、平台在退款场景下的申请、审核、回调和状态同步逻辑，避免后续资金链路和责任归属不清。
+
+## 2. 常见退款场景
+- 用户在允许时间内主动取消报名。
+- 商户因赛事关闭、延期、名额调整发起退款。
+- 平台因异常订单、重复扣款、风控问题发起退款。
+
+## 3. 参与角色
+| 角色 | 职责 |
+| --- | --- |
+| 用户 | 提交退款申请、查看退款进度 |
+| 商户 | 审核或发起退款、处理赛事关闭场景 |
+| 平台运营 | 处理异常退款、争议退款、人工复核 |
+| 后台 API | 校验条件、创建退款单、接收回调 |
+| 支付渠道 | 执行实际退款并回传结果 |
+
+## 4. 主流程
+1. 发起退款申请。
+2. 系统校验退款资格、退款金额与责任方。
+3. 创建退款单并进入“待处理”或“退款中”状态。
+4. 调用支付渠道提交退款。
+5. 接收退款回调并更新状态。
+6. 同步更新订单状态、报名状态，并通知用户。
+
+## 5. 异常分支
+- 超出退款时限：拒绝退款。
+- 已核销/已参赛：按规则禁止或需人工处理。
+- 支付渠道退款失败：进入人工复核。
+- 重复退款申请：幂等拦截。
+
+## 6. 状态流转
+| 对象 | 状态 |
+| --- | --- |
+| 退款单 | 待处理 / 退款中 / 退款成功 / 退款失败 / 已关闭 |
+| 订单 | 已支付 / 已退款 / 部分退款（如后续支持） |
+| 报名单 | 已报名 / 已取消 / 已退款 |
+
+## 7. 关键控制点
+- 退款必须记录申请人、审批人、处理时间和原因。
+- 金额计算规则要可追溯。
+- 与支付渠道交互必须幂等与验签。
+
+## 8. 待确认事项
+- 是否允许部分退款。
+- 是否支持按退款责任方区分手续费承担。
+- 用户退款是否都需要商户审核。