lzf_0626
5b97475950
## 现象
"单据核对与运营动作"里的单据信息全是 `--`：
```
20260914-001-A01
subscription · -- · --
申请日期 -- 申购金额 / 赎回份额 -- / --
机构 -- 基金代码 --
```
而 OCR 识别字段里这些值都**有**（基金代码 15911 / 申请日期 2026-09-11 /
申购金额 5000.00 / 机构 星澜财富服务中心）。所以不是"没保存"，是**渲染时取错了数据源**。
## 根因：同一个单据，两个接口给的不是同一份字段
| 接口 | `attachments[].documents[]` 的字段 |
|---|---|
| `GET /mails/{id}`（`_mail_detail`） | **只有摘要 4 个键**：`task_id` / `document_type` / `status` / `operator_decision` |
| `GET /mails/{id}/recognition-fields`（`_recognition_payload`） | **全部标准化字段**：`fund_code` / `fund_name` / `application_no` / `application_date` / `agency` / `subscription_amount_yuan` … |
`renderDocuments()` 渲染单据 kv 用的是 `state.documents`，而 `loadMail()` 只从
**邮件详情**那一份构建它 ⇒ 标准化字段根本不在对象里，只能显示 `--`。
前端其实**已经有** `syncDocumentsFromRecognition()` 想做这件事，但 `loadMail()` 里
是「先 `syncDocumentsFromRecognition(...)`、紧接着又用邮件详情重建 `state.documents`」
—— 合并结果被后一行覆盖掉了（这也是保存识别字段后那次同步没生效的原因）。
## 修法
1. `loadMail()`：构建完 `state.documents`（邮件侧摘要）之后**再调用一次**
`syncDocumentsFromRecognition(state.recognition)`，把识别侧的标准字段合并进来；
2. `syncDocumentsFromRecognition()` 由"整段替换"改为**逐条按 `task_id` 合并**：
- 两侧都有 → 识别侧字段优先，摘要里独有的键（`status` / `operator_decision`）保留；
- 只有摘要侧 → 原样保留（不因为识别接口没提到就丢单据）；
- 只有识别侧 → 也补进来（例如刚生成、摘要还没刷新）；
- 识别接口无 attachments（请求失败等）→ 早退，**不清空**已有单据。
## 验证
`node --check offsite.js` 通过；并用 Node **从源文件抽出该函数**（不另抄一份逻辑）灌入
线上两个接口的真实载荷形态，6+4+3+1 项断言全部通过：
- 摘要 + 识别侧全字段 → `fund_code=15911` / `application_date=2026-09-11` /
`agency=星澜财富服务中心` / `subscription_amount_yuan=5000.0000`，且
`status=planned`、`operator_decision=未处理` 未被覆盖，`attachment_id` 已补上；
- 识别接口返回空 → 邮件侧摘要仍在；
- 邮件侧独有单据保留、识别侧独有单据出现。
前端相关测试：`tests/unit/api/test_portal_frontend.py` → 45 passed, 1 failed
（仍是组员在改的投顾页，与本次无关）；`pytest tests/unit/api -k "offsite or operations"`
→ 1 passed。
## 说明：为什么没改后端
也可以让 `_mail_detail` 直接带上标准化字段，但那会改动已被文档化的接口载荷形状；
而前端本来就有合并函数、意图明确（`save-ocr` 路径早就在调用它），
因此按"恢复原有意图 + 按 task_id 正确合并"来修，零接口契约风险。
Portal 路由与角色映射
正式门户使用原生 JavaScript、原生 CSS 与同源 fetch，静态资源统一从 /static/portal/ 加载。
| 路由 | 角色 | 数据源 |
|---|---|---|
/portal/guest/home/ |
访客 / 全部 | P001（推荐位取前 3 只） |
/portal/guest/products/ |
访客 / 全部 | P001 |
/portal/guest/product-detail/?code= |
访客 / 全部 | P001（不含历史净值曲线） |
/portal/customer/login/ |
未登录客户 | A034 |
/portal/customer/dashboard/ |
customer / admin | T001、T002 |
/portal/customer/holdings/ |
customer / admin | T006 |
/portal/customer/profit-loss/ |
customer / admin | T001 |
/portal/customer/orders/ |
customer / admin | T003 |
/portal/customer/transactions/ |
customer / admin | T007 |
/portal/customer/cash-ledger/ |
customer / admin | T009 |
/portal/customer/risk-questionnaire/ |
customer | ONB001、ONB002 |
/portal/employee-console/login/ |
未登录员工 / 管理员 | A034 |
/portal/employee-console/workspace/ |
admin / super_admin | A002-A006、A012、A033、A035-A040、客服转人工管理接口 |
/portal/employee-risk/dashboard/ |
risk_operator / admin / super_admin | /api/v1/risk/**、R001-R003 |
/portal/employee-advisor/dashboard/ |
advisor / admin / super_admin | /api/v1/advisor/recommendations/published（本人 + 名下归属客户的已发布交付物） |
运营账号默认进入 /portal/employee-operations/offsite/ |
operator / admin / super_admin | /api/v1/offsite-fund/mails、/api/v1/offsite-fund/mailbox-status |
投顾页的数据口径：接口按「本人 +
sys_customer_assignment里名下归属客户」过滤，且同时覆盖investment_goal_book（方案书，发布后review_status='published'）与advisor_recommendation_plan（推荐方案，审核后review_status='approved'）两类内容。 方案书的审核与发布都要求管理员（investment-goal:review/publish都带admin=True）， 投顾自己发不出来 —— 这是有意设计的复核环节，不是缺陷。
客服浮窗由公开首页、基金产品页和客户工作台统一挂载。访客使用 /api/v1/visitor-tokens
获取短期令牌（角色 visitor，权限只有 agent:run + knowledge:query），因此必须走
query_knowledge 这个工具名；登录客户走 search_knowledge。两者都要出现在发布配置的
agent_tools/customer_service:<intent> 白名单里，缺哪一条，对应人群就一问即失败。
公开产品数据来自 GET /api/v1/products（编号 P001，见 docs/05 §19），
产品与净值取自 fin_product（status='上市'）、行情取自 fin_market_price 的最新一行。
访客页面通过 common/visitor-token.js 取短期访客令牌后调用；该文件是访客令牌的唯一实现
（客服浮窗也用它），不要在页面里另写一份，否则存储 key 与过期判断迟早不一致。
公开产品数据不得与登录后的真实账户数据混用。
三点口径（改前端前先读）：
change_pct可能是null（行情只同步过一个交易日时算不出涨跌）。 调用方必须显示"暂无"，不得当成0——formatPercent收到null会渲染成+0.00%， 那等于告诉客户"今天平盘"。- 历史净值曲线没有数据源：
fin_nav_history目前 0 行，详情页因此不画走势图， 并显式说明"尚未接入"。此前那条曲线是 mock 里 12 个编造点位 —— 走势图最容易被当成真数据。 - 产品级披露在
common/product-notes.js（如 510300 的"同指数参考产品，非本公司发行"）。fin_product没有这个字段，所以它留在前端；新增需要披露的产品时改那一份。 凡渲染公开产品的页面都要挂data-source-notice说明数据来源。
客户页面均由 common/auth.js 执行入口守卫，接口路径只在 common/api-client.js 的端点表登记。