zt-closet-backend/.codebuddy/plans/README_补充业务流程章节_75c77671.md

name, overview, todos

name	overview	todos
README 补充业务流程章节	在 README 中新增"业务流程"章节，以产品级业务视角梳理端到端业务闭环（用户旅程、衣物生命周期、穿搭与社区、衣柜分享、交易与权益、AI 推荐、通知触发），用 mermaid 流程图 + 状态机 + 业务规则描述，与已有的"核心业务调用流程"（接口时序视角）互补不重复。	id content status explore-business-rules 使用 [subagent:code-explorer] 读取 service 层与常量定义，产出 7 个业务域的规则事实清单 completed id content status dependencies write-flow-overview-lifecycle 在 README"配置说明"后插入"## 业务流程"章节：总览图、衣物生命周期、穿搭与社区、衣柜分享四节 completed explore-business-rules id content status dependencies write-flow-trade-ai-notify 继续撰写交易与权益、AI 推荐、通知触发规则三节，并与"核心业务调用流程"互链 completed write-flow-overview-lifecycle id content status dependencies proofread-business-flows 全文校对：枚举与周期和代码一致、mermaid 语法与层级正确、既有章节未被破坏 completed write-flow-trade-ai-notify

用户需求

在已完成接口调用逻辑文档的基础上，进一步把"业务流程"写入 README.md，让读者能从业务视角理解系统：各业务域如何闭环流转、有哪些状态机与业务规则、关键动作如何触发下游变化。

内容要求

• 新增独立二级章节"## 业务流程"，放在"配置说明"之后、"API 概览"之前（先懂业务、再懂接口的阅读顺序）。
• 与已有"核心业务调用流程"（接口时序视角，5 条 sequenceDiagram）明确分工：新章节讲"业务上发生了什么"（状态机、业务规则、mermaid flowchart），已有章节讲"接口怎么调"；两章互相引用、不重复内容。
• 覆盖 7 个业务域：用户旅程总览、衣物生命周期、穿搭与社区、衣柜分享、交易与权益、AI 推荐、通知触发规则。
• 所有枚举值、周期、数值必须以代码为准，不得臆测；中文撰写，风格与现有 README 一致；其他章节保持不变。

交付物

仅修改 /root/zt-closet-backend/README.md。

撰写方案

事实来源

• 业务规则事实以 internal/service/ 下 16 个 service 文件为准（用户注册额度初始化、衣物上传扣额/回退、穿搭公开审核、衣柜分享规则、订单支付/过期/退款链路、权益补偿任务、AI 推荐扣额与转正、通知触发点、运势生成调度）。
• 枚举与常量以 internal/service/constants.go、pkg/errcode、global/setting.go 为准；已确认的枚举清单（衣物处理状态 1-5、穿搭审核 1-3、分享状态 1-4、订单状态 1-5、退款状态 0-3、额度类型 1-4、流水变更类型 1-6、商品类型 1-5、通知类型 1-3）直接复用。
• 与既有章节一致性：插入位置锚定"## API 概览"标题前；新章节末尾与"核心业务调用流程"互链引用。

章节结构（## 业务流程 下的 7 个三级小节）

1. 业务流程总览：一张 flowchart 描绘端到端用户旅程（登录注册 → 上传衣物 → AI 识别入库 → 衣橱管理 → 创建穿搭 / AI 推荐 → 社区公开与互动 → 额度不足购买商品 → 权益到账）。
2. 衣物生命周期：上传校验（扩展名/magic bytes/大小）→ 扣上传额度 → 排队(3) → 抠图(1) → 分类(2) → 成功(4)/失败(5) 状态机 → 用户修正 15 维属性 → 删除回退额度；配状态机图 + 编号步骤。
3. 穿搭与社区：创建穿搭（1~10 件衣物）→ 公开（is_public=2 进入社区）→ 审核状态机（1 待审核/2 通过/3 不通过）→ 通过后可见 → 其他用户点赞/收藏 → 触发点赞通知。
4. 衣柜分享：部分衣物分享 / 全量快照分享 → 生成分享链接 → 访客查看分享详情 → 取消 / 到期自动过期状态机（1 正常/2 已取消/3 已过期/4 已封禁）。
5. 交易与权益：选购商品（5 类）→ 创建订单（15 分钟有效期）→ 微信支付回调 → 发放权益（会员/额度）→ 订单超时过期（后台每分钟扫描）→ 退款与额度回收 → 发放失败自动补偿（benefit_compensation 任务）。
6. AI 推荐：扣减 AI 额度 → 大模型结合星座运势 + 衣橱衣物生成 → 落库"待用户保存"(status=3) → 用户确认保存转正式穿搭；额度不足（80000/90401）与生成失败的处理。
7. 通知触发规则：点赞通知（点赞时发给被赞用户）、订单通知（支付成功/退款等状态变化时）、系统通知的触发源；未读(1) → 已读(2) 流转与未读数统计。

图表规范

• 每节至少一张 ```mermaid 代码块（flowchart 或 stateDiagram），节点文案使用枚举原值（如"4 成功"），避免与代码不一致的表述。
• 编号步骤紧随图表之后，每条流程 3~6 步；关键业务规则（额度扣减/回退、幂等、审核、补偿）以加粗或列表强调。
• 篇幅控制：总览图一张紧凑流程图；各节图表节点数控制在 10 个以内；复用既有枚举表，不在新章节重复大表格。

防回归

• 插入位置唯一锚点：## API 概览；不改动其他章节内容。
• 新增章节内标题层级为 ###，不破坏既有目录结构；完成后用标题搜索与 mermaid 语法检查验证。

推荐扩展

SubAgent

• code-explorer
• 用途：读取 internal/service/ 下 16 个 service 文件与 constants.go、errcode、setting，提取业务流程撰写所需的业务规则事实（额度初始化与扣减回退时机、穿搭审核状态机、分享过期判定、订单与权益补偿链路、通知触发点、运势调度等）。
• 预期结果：输出一份按业务域组织的规则事实清单（含具体常量数值、周期、触发条件、状态流转），作为撰写"业务流程"章节的唯一事实依据，确保不臆测。