Files
lzf_0626 eb89ffd0b4 按需造数据:给指定客户建持仓,并保证产品有可查的最新净值
## 需求

产品 15911、客户 10001 / 10002;最终要能查到这两户持有 15911 的持仓,
以及 15911 的最新净值。

## tools/seed_custom_holdings.py(新)

参数化脚本,不写死这次的代码与账号。手工写 SQL 会连踩一串坑,每一条都在本仓库真实发生过:

1. `fin_*` 的 `id` 列**没有 AUTO_INCREMENT**,不显式给 id 就报
   `Field 'id' doesn't have a default value`;
2. `fin_holding.shares` / `current_value` 文档标注为"生成列",实测是普通 NOT NULL 列,
   不写插不进去;
3. 只建 `sys_user` 不绑角色 -> 登录成功但查持仓 403;
4. 只建用户不设密码 -> `password_hash` 是占位符,**根本登不进来**;
5. 净值散在三处(`fin_product.current_nav`、`fin_nav_history` 最新一条、
   `fin_market_price.close_price`),只写一处就会"产品页有净值、持仓页市值为空";
6. 往 `fin_market_price` 写"今天"的编造行情会**盖住真实行情** —— 下单按 `trade_date DESC`
   取,编造行排在前面,过了 `MAX_QUOTE_AGE`(15 分钟)整个产品就一律 503
   (周末尤其明显)。

脚本把这些一次做对,并保证上面第 5 条的三处严格一致(持仓市值恒等于 数量 x 最新净值)。

## 开户风险测评:走接口,不插表

这是这次最关键的发现。数据都建好之后,客户能登录,但访问 T001 / T006 一律 403,
报的是 `AGENT_PERMISSION_DENIED`「请先完成开户风险测评问卷」——
那是合规前置(`app/api/dependencies/auth.py` 的 `OnboardingRequiredError`),
不是 RBAC 没配好,两者表象一模一样,很容易查错方向。

`RiskQuestionnaireService.is_required` 只查 `fin_risk_assessment.valid_until > now`,
所以插一行就能过检查。**没有那样做**:插表不会生成画像快照、画像标签和记忆同步事件,
而投顾分析、适当性检查、Agent 对话都要读那些。改走真实接口
`POST /api/v1/onboarding/risk-questionnaire/submissions`,让业务链路自己把关联数据建全。

内置 13 题答案按 `_SCORE_RULES` 折总分 46 -> C4 成长型(产品是 R3,C4 有余量)。
等级**不从接口读**:提交返回里故意没有它(`_SCORE_RULES` 是服务端机密,注释写明
never included in customer responses),所以从库里读回并打印。实测读到 C4 / 46 分,
与手算完全吻合。

## 实测(接口层,不只是查库)

- P001 访客产品列表:21 个产品,★ 命中 15911,`current_nav=1.000000`
- P002 净值走势:30 个点,最近 3 条 2026-09-10 / 09-11 / 09-14
- 10001 / 10002 登录 -> T001 资产看板 200:总资产 101000.00、总市值 1000.00
- 10001 / 10002 -> T006 持仓 200:15911 数量 1000、最新价 1.000000、市值 1000.00
- 幂等复核:第二次执行不重复建记录、不覆盖持仓数量、不重复提交测评、不重置密码
- `ruff check app tests tools alembic hq.py` -> All checks passed

## 已知限制

产品代码 `15911` 是 **5 位**,而系统现有 20 个产品**全是 6 位**,且下单要求行情落在
`FundQuoteRuntimeConfig.allowed_codes`(六位数字)白名单里。
所以它**能建、能查持仓、能查净值,但不能下单**。
若是笔误,用 `--product-code 159911` 重跑即可。
2026-09-14 10:03:07 +08:00
..
2026-09-11 17:26:18 +08:00