AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
371 Commits 12 Branches 0 Tags
467d2b5169527f50623492830035b8daf972854f
Commit Graph
21 Commits
Author SHA1 Message Date
lzf_0626 467d2b5169 投顾可自助审核/发布自己生成的推荐方案（原先只有管理员能推进草案） 
## 现象与根因

投顾工作台生成推荐方案后，草案停在 `pending_review` 且投顾无法推进：

- 服务层 `review` / `publish` 都带 **`admin=True` 角色闸门**
  （`product_recommendation_service.py:286/317`），即使投顾角色**已经持有**
  `product-recommendation:review` / `:publish` 两个权限码也一律 403；
- 审核/发布端点只注册在 **admin 路由**下（`/api/v1/admin/advisor/...`），
  投顾侧根本没有对应入口；
- 投顾工作台也没有审核/发布按钮（`published-module.js` 原注释即写着
  "发布动作要求管理员，投顾侧只读"）。

于是业务上"让投顾自己审核"完全做不到，必须切管理员账号。

## 修法（三处配套，安全边界保留）

1. `app/service/product_recommendation_service.py`
   - `review` / `publish` 去掉 `admin=True`，**只按权限码判定**
     （`product-recommendation:review` / `:publish`，目前仅 advisor 与 admin 持有）；
   - `reviewer_user_id` 照旧如实落库，审计可追；
   - 注释写明：若要回到"四眼原则/管理员专属"，把 `admin=True` 加回即可。
2. `app/api/controllers/recommendations.py`
   - 新增投顾侧路由 `POST /api/v1/advisor/recommendations/{id}/reviews`
     与 `.../publications`（与 admin 路由调用同一服务方法）。
3. 前端
   - `common/api-client.js`：注册 `ADVISOR_REVIEW_RECOMMENDATION` /
     `ADVISOR_PUBLISH_RECOMMENDATION`；
   - `employee-advisor/dashboard/actions-module.js`：结果区在拿到 `content_id` 后
     给出「审核通过 / 驳回 / 发布给客户」按钮（结果区是 `innerHTML` 重建的，
     所以每次渲染后重新绑定）；审核通过后就地换成「发布给客户」；
   - `published-module.js`：监听 `advisor:published-refresh`，发布成功后列表自动刷新。

## 未放宽的部分（有意保留）

- **管理面复核队列** `GET /api/v1/admin/advisor/pending-contents` 仍为
  `admin=True` 专属 —— `tests/integration/test_advisor_review_queue_mysql.py`
  里"投顾读不到该队列"的断言**未改动**；
- 客户/风控/运营角色不持有这两个权限码，因此不受影响。

## 验证（真实 HTTP，9020 身份）

```
① 生成推荐方案（客户 9001）→ content_id=19, pending_review
② 投顾自助审核通过          → HTTP 200 status=approved     （改前 403）
③ 投顾自助发布              → HTTP 200 status=published
④ 已发布列表                → 含 id=19 ✅
```

新增回归测试 `test_advisor_can_review_and_publish_own_recommendation`
（客户缺测评/目标时 `pytest.skip` 并说明是数据前置，不误判为权限失败）。

## 门禁

- `pytest tests/unit tests/contract` → 1458 passed；
- `pytest tests/integration` → 111 passed + 1 例
  `test_worker_runtime_mysql::...repeat[False]` 失败，**经复跑确认是 AGENTS.md 记载的
  "常驻 Worker 抢队列"，停掉常驻 Worker 后该用例 2 passed**，与本次改动无关；
- `ruff` 干净；三个 JS 文件 `node --check` 通过。
 2026-09-14 23:27:44 +08:00
lzf_0626 e6147bb6ec 推介材料：中文文件名让上传请求头非法 → 两个附件都"网络连接失败"（服务端一条记录都没有） 
## 现象

上传 `业绩数据1.xlsx` 与 `基金经理1号王建龙.png`（扩展名都在白名单内）：
页面提示 `业绩数据文件上传失败：网络连接失败；基金经理照片上传失败：网络连接失败`，
而库里、盘上、审计里**都没有任何上传痕迹**。

## 排查与根因

1. API 是健康的（`/portal/` 200、129 条路由在、8000 正常监听）；
2. `api_client` 里 "网络连接失败" 的触发条件是 **`fetch` 抛了非超时的异常**（超时会显示"请求超时"）；
3. **`api_request_receipt` 里没有任何上传记录** —— 同一时段的建任务/存资料/生成三条都有 receipt
   （连"生成未通过合规校验"这种业务失败也落 receipt）⇒ **上传请求根本没到应用**；
4. `promotion.js` 给上传传的幂等键是 `` `${taskNo}-${type}-${file.name}-${file.size}` `` ——
   **把中文文件名拼进了 HTTP 头 `Idempotency-Key`**；
5. HTTP 头值只能由 ≤0xFF 的码点组成：实测同一请求用标准客户端发送时抛
   `UnicodeEncodeError: 'ascii' codec can't encode characters in position 34-45`；
   浏览器更严格，`fetch` 在**构造请求头时直接抛 `TypeError`**，请求一个字节都没发出去，
   却被 `api-client.js` 的 catch 包装成"网络连接失败"——**"参数非法"伪装成了"网络故障"**。
6. 反证：换成纯 ASCII 的幂等键，同两个文件、同一端点**立刻 200 成功**
   （attachment_id=67/68，`performance_summary` 正常返回）。

## 修法

1. `employee-operations/promotion/promotion.js`
   - 新增 `asciiOnly()` / `uploadKey()`：幂等键改为 `任务号-类型-字节数-最后修改时间`
     （**刻意不用文件名** —— 中文名即非法头值），纯 ASCII 且同一文件重传得到同一键（幂等回放）；
2. `common/api-client.js`
   - 对幂等键做**前置校验**（平台规范：16-128 位可打印 ASCII），不满足时抛
     `IDEMPOTENCY_KEY_INVALID` 并**带上端点与键值** —— 下一次这类问题 10 秒可定位，
     不必再从"网络故障"倒推。

## 验证

- 从源文件抽出 `asciiOnly`/`uploadKey` 用 Node 断言：中文文件名 → 键全 ASCII 且通过校验、
  同一文件两次同键、不同文件不同键、任务号含中文也被转义、旧写法会被拦下（全部通过）；
- `node --check` 两个文件通过；
- 真实 HTTP（带令牌、真实文件）验证：ASCII 键 → **HTTP 200**，中文键 → 客户端抛 `UnicodeEncodeError`；
- 该账号的两个附件已成功入库（id=67/68），业绩摘要 = `as_of_date 2025-12-31 /
  history_months 23 / product_return 17.1% / max_drawdown -1.15%`；
- `pytest tests/unit tests/contract` 全绿。
 2026-09-14 22:36:49 +08:00
lzf_0626 ae7a89f33d 投顾工作台：修推荐结果渲染（幂等响应形状归一）+ 对齐门户版式规范 
投顾页「生成推荐方案」拿不到产品的根因：该端点标了 idempotent，浏览器必带
Idempotency-Key，而后端此时返回的是 {data:{content_id, status, plan:{...}}, meta}
—— 真正的文档嵌在 data.plan 里。此前前端只处理了不带键时的裸文档形状。

- api-client：ADVISOR_RECOMMEND 撤掉 raw（带幂等键时确为信封，需正常解包）；
  ADVISOR_ALLOCATION / ADVISOR_ANALYSIS 保留 raw（不标幂等，返回裸文档）
- actions-module：新增 normalizeRecommend()，把「信封 + plan 嵌套」与「裸文档」
  两种响应归一成一种形状；结果卡片显示方案编号与待审核状态
- 投顾页：hero 大图 + 4 张概览指标卡 + 左栏/主区两栏构图
- 投顾页：页头常显「退出登录」按钮；新增风评预警数、快捷问句按钮
- 投顾页：动作名统一为「生成推荐方案」（对齐软件需求文档 5.4 ⑦）
- 管理台「待审投顾内容」空态文案同步改名
- 前端模块相对 import 加 ?v= 版本号：改文件内容而 URL 不变会被浏览器缓存挡住
 2026-09-14 22:17:39 +08:00
yuancong_0626 2548c39c6b 袁聪的最后一次完善更新 2026-09-14 18:13:10 +08:00
张胜宇 f5d1b24618 merge qyqy_develop and retain risk review updates 2026-09-14 01:41:02 +08:00
yuancong_0626 295be972d2 Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop 2026-09-14 01:23:32 +08:00
lzf_0626 daf73a2865 fix(portal): 照接口逐条核对前端，修掉 5 处「照着表结构写、看着像对」的缺陷 
做法：把前端 `api-client.js` 注册的端点**按前端完全相同的方式**（同样的路径、参数、
身份）逐个调用，再拿真实返回去核对前端 render 用到的字段。
**这类问题纯读代码看不出来** —— 只有把真实返回和期望字段摆在一起才会暴露。

## 1. 知识库功能实际是坏的（K002 / K003 是裸信封）

`K002` 的成功体是 `{knowledge_ids, filename, chunk_count}`、`K003` 是 `{items, count}`，
**都没有 `data` 信封**。而 `request()` 默认取 `payload.data`（undefined），于是：

- 上传后前端显示「已入库 **0** 块」，而库里其实切了 23 块；
- 列表永远显示「知识库为空」。

端点表里标 `raw: true` 后（与 `V001` 同一做法）两者都正常。
实测：上传 4805 字符的产品手册 → 切 23 块并出现在列表里。

## 2. 委托/成交详情页有 5 行永远显示「--」

前端按 `fin_sim_order` / `fin_transaction` 的**建表字段**写了 `quote_source`、
`nav`、`fee_rate_snapshot`、`confirmed_at`、`auto_confirmed` ——
但这些字段**接口的返回视图没有带**（表里有、返回里没有）。已按实际返回重写字段表，
并在注释里写明"以接口返回为准，不要照表写"。

## 3. 配置项与路由规则的**编辑功能不可能成功**（接口缺口）

`PUT` 硬性要求 `If-Match`，校验的是该行内容的 digest；而这两个资源是 `detail=False`
—— **没有任何端点能返回这个 digest**（列表的 `meta` 只有 trace_id）。
乐观并发在"读不到版本"的前提下等于死锁：**首次编辑必然 409**。
（配置发布能用，是因为它有详情端点 `A003`。）

- 新增详情端点 `A048` / `A049`（`detail=True`），已登记 `docs/05` §19；
- 前端编辑前先 GET 详情取 etag，再带 `If-Match` 提交。
- 实测：编辑配置项与路由规则均 200；**不带 `If-Match` 仍返回 409**，
  说明乐观并发没有被削弱。

## 4. 路由规则表单**必然提交失败**

前端固定写 `max_attempts: 2` 且 `fallbacks: []`，而后端要求
`max_attempts ≤ 端点总数`（主 + 兜底）→ 422「重试次数超过端点数量」。
改为 `1` 并注明约束。

## 5. 主端点手填 ID 会 422

后端对不存在/未激活的 `primary_endpoint_id` 直接 422「模型端点不存在或未激活」。
把输入框改成**下拉**，只列 `status='active'` 的端点（数据复用已有的端点列表）。

## 顺带

- `apiClient` 增加 `del()` / `put()`：发出的方法一直由端点表决定，所以 `post('K004')`
  也能发 DELETE —— 语义太绕，现在意图与行为一致。
- 清理了测试期间上传的 31 条知识残留（客服会检索到它们），库内恢复到 23 条产品手册。

## 关于"逐条核对"的方法论

前两轮跑出来的 9 个和 5 个"失败"里，**多数是我测试脚本自己的假设错了**，不是前端问题：
`T001` 是 `{account, summary}` 嵌套、`RK002` 的字段叫 `risk_level`、
`RK002/RK004/RK005` 的 limit 上限是 5/10/10（前端传的正是 5/10/10）、
`AD011/A002/A047` 的 data 是裸 list。每一处都回到前端源码确认后才下结论 ——
**先把"我以为"改成"代码里写的"**，否则报告出去的就是假 bug。

验证：unit+contract **1397 passed**；integration **110 passed**；ruff 通过；
mypy 251 文件 0 错；§19 现 93 个端点无重复；e2e 冒烟 **40/40**。
前端等价测试：只读 31 项全绿、写操作（含 ETag 链路）9 项 8 绿 1 项因测试数据过短。
 2026-09-14 01:19:22 +08:00
yuancong_0626 abbfb6eddd 合并yy并同步远程qyqy_develop 2026-09-14 01:11:07 +08:00
yuancong_0626 7a49a1c2c8 袁聪的前端调修 2026-09-14 01:07:43 +08:00
lzf_0626 e31420df29 feat(portal): 补齐四个前端缺口——客户详情、知识库管理、配置项与路由编辑 
先审计了全部 **141 个后端端点**：前端注册 68 个，注册的**全部有效**（没有一个打不通）。
本提交补的是其中真正影响可用性的四类。

## 1. 客户端：委托详情（T004）与成交详情（T008）

两个接口后端一直存在，但订单页 / 成交明细页**只接了列表（T003 / T007）** ——
客户点不进任何一条记录，看不到成交价、费用构成、确认时间与行情来源。

改为**行内展开**（点「详情」在原行下方展开，再点收起），不跳页：

- 复用新加的公共样式 `.list-detail`（`common/customer-list.css`），两页共用而不各写一份
- 详情取不到时**不整页报错**：列表本身是好的，只恢复按钮并记一次错误

## 2. 管理员：知识库管理（K002 / K003 / K004）

客服的**全部回答都来自已入库的知识**，而此前**没有任何页面能管理知识库** ——
只能靠命令行脚本 `tools/seed_knowledge_demo.py` 灌数据，管理员既看不到也改不了。

新增「知识库」标签页：文档列表 + 上传（.txt/.md/.docx）+ 失效。两处要点：

- **K003 的成功体是裸的** `{items, count}`、**没有 `data` 信封** ——
  `request()` 仍会去取 `payload.data`（那是 undefined），所以列表要两面都兜，
  否则永远显示"知识库为空"、而库里其实有数据；
- 上传是 **JSON + base64**，不是 multipart（一期契约如此，见 `knowledge_management.py`）。

## 3. 管理员：配置项与模型路由（A001 / A008–A010 / A018–A020）

此前只能对**已存在**的版本走"校验→审核→激活"，**既不能新建版本、也不能往里加配置项**
—— 新建的版本永远是空的、校验必然失败；模型路由规则同样既看不到也改不了。

- 新增「新建配置版本」表单（版本号 / 标题 / 变更说明）
- 每个版本加「内容」按钮（**与状态无关**：草稿阶段就要能加，否则版本永远空）→
  展开该版本的**配置项**与**模型路由规则**，两者都支持新增与编辑
- 配置项的「值」按 JSON 输入并在前端校验：与其让后端 422，不如就地拦住并说清哪里不对
- `fallbacks` 暂不在界面编辑（提交空数组），需要时用接口补

这些端点**都已在 `docs/05` §19 有编号**，直接复用，无需新增编号。

## 4. 两个"死端点"查证后**保留**

初查发现 `RK013`（风控日报非流式，已被 RK014 流式取代）与 `ADVISOR_GOAL`
（投顾自己的目标；投顾是员工、没有目标 → 永远 404）注册了却无人调用，一度删除。
但 `tests/unit/api/test_portal_frontend.py` 立刻失败 —— 它把"页面会用到的端点"
固定成一张清单，**注册与调用是两件事**。已恢复注册，并就地注明它们当前无人调用、
但受契约保护。

顺带发现：**`RK013`–`RK015`（风控日报）也不在 §19**，与投顾 AD 段原先的情况相同，
属文档缺口（未在本提交内补）。

## 辅助改动

`apiClient` 增加 `del()` 与 `put()`：真正发出的方法一直由端点表里的 `method` 决定，
所以 `post('K004')` 也能发出 DELETE —— 但读代码的人会以为发的是 POST。
现在意图与行为一致。

验证：unit+contract **1397 passed**（含前端契约 37）；integration **110 passed**；
ruff 通过；mypy 251 文件 0 错；e2e 冒烟 **40/40**；相关页面与静态资源全部 200。
 2026-09-14 00:51:13 +08:00
lzf_0626 de55c5c60c feat(advisor): 登记 17 个投顾端点并补管理员复核入口（A047 待审队列） 
## 1. docs/05 §19 补登 17 个投顾端点

这批端点此前**只存在于代码中**，§19 一条都没登记；而 §12 写的入口
`/api/v1/advisory-plans/**` 与实际路径 `/api/v1/advisor/**` 也不符（已修正）。

- **A041–A046**：管理员治理（配置回测、画像标签与漂移复核、推荐方案审核与发布）
- **AD001–AD011**：投顾自用。**新开 `AD` 号段**的理由：它与 A 段是两个不同的权限面
  —— A 段是 `/api/v1/admin/**` 管理面，AD 段是 `/api/v1/advisor/**` 投顾自用；
  混在一个号段里，"这条到底谁能调"就得逐条去读权限列。
- 另加 AD 段说明块：`investment-goal` 的两套权限码（`...:self` / `...:customer`）、
  AD006/AD007 虽在投顾路径下却要求 `admin`、灰度开关 `enforce_advisor_rollout` 前置、
  幂等范围（AD008/AD009 无幂等头）、以及 404/409 的失败口径。

§19 现为 **90 个端点 / 9 个号段**，无重复。

## 2. 管理员复核入口 + A047 待审队列

**发现一个让审核链路不可达的缺口**：`review` / `publish` 都要求调用方先拿到键
（推荐方案是 `content_id`、方案书是 `goal_no`），而此前**没有任何端点能列出待审内容**
—— 管理员拿不到键，投顾生成的东西就永远停在待审状态。

- 新增 `GET /api/v1/admin/advisor/pending-contents`（编号 **A047**）：一次返回两类待审内容。
  两类内容的"待审"取值不同（推荐方案 `pending_review`、方案书 `pending`），
  只判其中一个会整类漏掉，所以用 `PENDING_STATES` 一并匹配。
- **为方案书一并查出 `goal_no`** —— 它的审核/发布端点（AD006/AD007）按 `goal_no` 寻址，
  只给 `content_id` 的话管理员拿到列表也调不动。已由 integration 测试守住这一点。
- 管理员工作台新增「投顾复核」标签页：列出待审内容，支持审核通过 / 驳回 / 发布；
  前端按 `content_type` 自动选择端点、寻址键与载荷
  （方案书发布要 `{publish: true}`，推荐方案发布不读 body）。
- 发布前校验状态：未审核通过不允许发布，与 `publish_book` 的 `IllegalState` 一致。

## 3. ⚠️ 同时发现：投顾的三个分析功能对投顾本人不可用

`ProductRecommendationQuery` **没有 `customer_id`** 字段，而 `generate` 用的是
`int(context.user_id)`（`product_recommendation_service.py:69`）—— 即**把投顾自己**
当成了服务对象。投顾是员工、没有风险测评与持仓，于是实测：

    POST /api/v1/advisor/recommendations   → {"status": "profile_required"}
    POST /api/v1/advisor/asset-allocation  → {"status": "profile_required"}

**组合分析、资产配置、生成推荐草案这三个功能，投顾调用必然拿不到结果。**
这是"投顾功能很奇怪"的直接来源之一。修它要改接口契约（加 `customer_id`、
并确定"投顾能对哪些客户生成"的权限口径），属产品决策，未在本提交内改动。

验证：unit+contract **1397 passed**；新增 integration 用例 2 passed；ruff 通过；
mypy 251 文件 0 错；A047 实测管理员 200（带出方案书的 `goal_no`）、投顾 403。
 2026-09-14 00:17:46 +08:00
lzf_0626 421fed8569 feat(advisor): 补全投顾流程入口（确认目标 → 查看方案书），并修复页面缺缓存版本 
## 1. 投顾流程此前是断的

投顾工作台只有 4 个「生成草案」操作 + 1 个只读列表，而**确认目标**与**查看方案书**
这两个端点虽然存在却**没有入口** —— 于是目标永远停在 `pending_confirmation`、
方案书永远停在 `pending`。

实测客户 9001 正是如此：`confirmed_at: null`、方案书 `review_status=pending`。
而「录入客户目标」成功后的提示是"已提交，等待确认与审核"，**没有下一步可点**。

改动：

- 新增操作卡「目标确认与方案书」：输入客户 ID → 查询目标 → 显示目标状态、
  方案书状态、收益区间 / 回撤 / 期限 / 基准 / 确认时间 → **确认目标** / **查看方案书**。
- **录入目标后自动跳到目标状态页**，把确认按钮摆在眼前，而不是停在"已提交"。
- `ADVISOR_CONFIRM_GOAL` / `ADVISOR_GOAL_BOOK` 补登记进 `api-client.js`
  （`ADVISOR_CUSTOMER_GOAL` 早已注册却从未被使用）。
- 404「当前投资目标不存在」按**正常情况**处理（给下一步提示），不当故障报警。

⚠️ **审核与发布不在此范围**：`review_book` / `publish_book` 都要求 `admin=True`
（见 `investment_goal_service`），那是管理员的动作，投顾侧到"确认 + 看方案书"为止。
方案书仍会停在 `pending`，除非管理员侧也补上入口。

## 2. 9 个页面的 script 标签缺缓存版本参数

投顾工作台的 script 是 `dashboard.js`（**没有 `?v=`**），另有 8 个页面同样如此
（客户的持仓/下单/流水/盈亏/测评/成交明细、管理员工作台、运营工作台）。
浏览器会一直用缓存的旧 JS —— **改了代码也看不到效果**，这是"功能很奇怪"的一部分。

已统一补上 `?v=20260913`，投顾页的 js/css 提到 `-2`。

## 3. 过程中我损坏过 8 个文件，已恢复

第一次批量补版本参数时我用了 PowerShell `Get-Content -Raw` + `Set-Content`：
**PS 5.1 默认按 ANSI/GBK 读**，把 UTF-8 中文读成乱码再写回
（`角色与权限` → `瑙掕壊鏉冮檺`）并写入 BOM。`tests/unit/api/test_portal_frontend.py`
的断言当场抓到了它（找不到「角色与权限」）。

已 `git checkout` 恢复全部 8 个文件，改用 Python 重做（显式 UTF-8、不写 BOM、
保持原换行），现在每个文件的改动都是 **1 增 1 删**。

验证：`tests/unit/api/test_portal_frontend.py` 35 passed；unit+contract **1395 passed**；
ruff 通过；mypy 251 文件 0 错；确认目标实测 200
（`pending_confirmation` → `confirmed`，写入 `confirmed_at`），
重复确认被状态机以 409 拒绝。
 2026-09-13 23:56:27 +08:00
lzf_0626 7208713c17 feat(portal): 接入历史净值，产品详情页恢复真实走势图 
`fin_nav_history` 一直是**空表**，所以产品详情页画不出走势图 —— 此前那条曲线是
前端 `mock-data.js` 里编的 12 个点位，接入公开产品接口时把它去掉了
（走势图最容易被当成真实业绩），页面改为显示"尚未接入"。本次补上完整链路。

## 1. 取数（app/infrastructure/fund_market_adapter.py）

新增 `fetch_nav_history()`：东方财富历史净值接口（`api.fund.eastmoney.com/f10/lsjz`）
分页取序列。

- **为什么不复用 `fetch_kline`**：它走 `push2his.eastmoney.com`，
  该域名在本环境实测连接被拒（`RemoteProtocolError`）；
- **为什么不复用 `hq.get_southern_fund_nav_history`**：那个函数校验**南方基金白名单**，
  而 `fin_product` 里有非南方基金的产品（510300 是华泰柏瑞的），调它会直接 `ValueError`。

⚠️ 实现里踩到一个坑：接口**会忽略请求中的 `pageSize`**（实测固定每次返回 20 条）。
最初按硬编码的 30 判断"是否最后一页"，于是 `len(items) < 30` 永远成立、只取到第一页 ——
走势图看上去"有数据"，其实只有最近 20 天，而且毫无报错。
改为按首屏**实际条数** + `TotalCount` 推算页数后，同样区间取到 124 条。

## 2. 落库（tools/sync_nav_history.py，新增）

写入 `fin_nav_history`，按 `(product_id, nav_date)` 幂等 upsert。
实测：20 只产品 / **2513 行** / 2026-03-17 ~ 09-13；重跑**新写入 0 行**。

## 3. 接口（P002）

`GET /api/v1/products/{product_code}/nav-history`，编号 **P002**，已登记 `docs/05` §19。
鉴权口径与 P001 相同（要求有效令牌、不校验权限码，访客令牌可用）；`days` 有界 1–365。

**表为空时返回 `count=0` 与空数组，而不是报错** —— 调用方据此显示"尚未接入"，
**不得回退到编造曲线**。产品不存在或未上市 → `404`（否则前端分不清"没有数据"
和"没有这只产品"）。

## 4. 前端

详情页按序列画 SVG 折线，期数标题改为动态（"近 N 个交易日"）。
表为空时仍显示"尚未接入"占位，并补上此前缺失的 `.detail-chart__empty` 样式。
`product-detail.js` / `.css` / `index.html` 的缓存版本参数一并 bump 到 `-7`。

## 5. 演示数据

`tools/seed_demo_data.py` 增加第 5 步「历史净值」（现 **11 步**），
否则换台机器演示时走势图又会是空的。

验证：P002 实测 515450 / 510300 各 120 个净值点；ruff 通过；mypy 251 文件 0 错；
unit+contract 1391 passed；integration 108 passed；e2e 冒烟 40/40。
 2026-09-13 23:38:13 +08:00
张胜宇 5929eb151b merge: integrate latest qyqy_develop changes 2026-09-13 23:10:46 +08:00
张胜宇 3325232e2a feat(portal): complete advisor workspace operations 2026-09-13 23:04:35 +08:00
lzf_0626 9cb0f6e474 feat(portal): 公开产品接口（P001）落地，访客三页改读真实数据 
访客首页推荐、产品列表、产品详情此前读的是前端手写的
`app/static/portal/common/mock-data.js`：只有 8 只，且**其中 6 只根本不在
`fin_product` 里**（159915 / 512100 / 513100 / 511360 / 159645 / 159925），
还把海富通的 `511360` 标成"南方短融ETF"、把 `510500` 净值写成 6.742（真实 7.6027）。
`README.md` 把它记为"公开产品 HTTP 接口尚未实现"的临时方案。

## 接口

新增 `GET /api/v1/products`（编号 **P001**，已在 `docs/05` §19 总目录与 §19 说明中登记）：

- **要求有效令牌但不校验权限码**：访客令牌的角色是 `visitor`、不带任何权限，
  这与 `/api/v1/agent-runs`、`/api/v1/conversations` 面向访客的口径一致；
  产品信息本身是公开信息。数据面只暴露 `fin_product`（`status='上市'`）与
  `fin_market_price` 的最新一行，**不含任何账户/客户字段**（由 integration 测试守着）。
- 字段与 `mock-data.js` 对齐，因此前端渲染与筛选逻辑**一行未改**。
- `change_pct` **可能是 `null`**：当日涨跌需要两个交易日的收盘价，行情只同步过一天时
  算不出来。前端对 `null` 显示"暂无" —— `formatPercent(null)` 会渲染成 `+0.00%`，
  那等于对客户说"今天平盘"，是编出来的结论。

## 前端

- 新增 `common/visitor-token.js`：访客令牌的**唯一实现**（这段逻辑原先只写在客服浮窗里，
  现在四处要用；复制四份的话存储 key 与过期判断迟早不一致）；`widget.js` 改为复用它。
- 新增 `common/product-notes.js`：产品级披露文案。510300"非本公司发行"那条是**合规披露**，
  不能随 mock 一起删掉。
- 三个访客页改读接口，并显式区分 loading / error 状态。
- **删除 `common/mock-data.js`**。
- 产品详情页**不再画走势图**：`fin_nav_history` 目前 0 行，此前那条曲线是 mock 里
  12 个编造点位 —— 走势图最容易被当成真数据，宁可不画，并显式说明"尚未接入"。

## 顺带修正

`min_amount` 在库里全是 0.00（那本是场外"最小认购金额"的概念，对场内按手交易的 ETF
不适用），页面不再显示"¥0.00"（会被读成零元起购），改为"1 手（100 份）起"。

验证：接口实测 `count=20`；ruff 通过；mypy 251 文件 0 错；unit+contract 1387 passed；
integration 106 passed；e2e 冒烟 40/40。
 2026-09-13 22:57:48 +08:00
zhangshy 522c9b19fe Merge remote-tracking branch 'origin/qyqy_develop' into RM2_develop 2026-09-13 21:09:09 +08:00
zhangshy 09c80575b7 延长风控手动扫描前端超时 2026-09-13 21:08:57 +08:00
张胜宇 e3c316aafb Enforce trading authorization and suitability checks 2026-09-13 19:24:59 +08:00
张胜宇 e740a58e9d 前端2 2026-09-13 18:31:38 +08:00
张胜宇 e38ece32bf 前端提交 2026-09-13 15:56:54 +08:00