group_fqcd_jr

Files

T

Windows 2fe7d0c506 feat(投顾): 客户主动申报投顾方案 + 投顾受理自动生成方案草稿

客户在自己主页提交申报 → 投顾工作台受理 → 自动跑既有推荐逻辑生成一份待审核草稿 →
投顾再走既有的「审核通过 → 发送给客户」。补上原先「客户只能被动等方案」的缺口。

后端
- 新增表 advisor_service_request（本轮新建，带 AUTO_INCREMENT）+ 迁移
  20260916_advisor_service_request（幂等：先查表再建，兼容本库 alembic 指针滞后）
- 新增 AdvisorServiceRequestService：create / list_mine / queue / review
  · 申报前置：风险测评必须存在且未失效（FM-03，12 个月），服务端判
  · 队列复用 ProductRecommendationService._visible_customer_ids（本人 + 归属），待受理排前
  · 受理即调用推荐逻辑生成草稿并把 content_id 回填；生成前置失败给出人话原因并保持待受理
  · 「已发送客户」不落库，由关联方案 published_at 推导，避免两处状态各写各的
- 权限码 9071-9074（客户 write/read:self、投顾 read/review），已进种子与授权工具

前端
- 投顾工作台新增「客户申报」面板（受理 / 驳回，驳回理由客户可见）
- 客户页新增申报表单（金额/期限/风险偏好/备注）与「我的申报」列表

客户自助路由刻意不挂投顾灰度闸门：那是投顾业务的灰度，客户提交自己的申请不该被它拦下。

2026-09-16 18:17:46 +08:00

controllers

feat(投顾): 客户主动申报投顾方案 + 投顾受理自动生成方案草稿

2026-09-16 18:17:46 +08:00

dependencies

修复权限拒绝变 500、访客令牌无限流，并让两处测试跟上代码

2026-09-14 20:14:50 +08:00

schemas

补齐客服转人工工单流：从"只能看"到"能推进"（基线状态机，不自行发明）

2026-09-15 00:41:59 +08:00

views

补齐三个成功响应缺失的 meta 信封；信封实现抽为公共（docs/05 §3.3）