 张胜宇
|
f5d1b24618
|
merge qyqy_develop and retain risk review updates
|
2026-09-14 01:41:02 +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 |
|
|
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
|
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 |
|
|
张胜宇
|
3325232e2a
|
feat(portal): complete advisor workspace operations
|
2026-09-13 23:04:35 +08:00 |
|
|
张胜宇
|
e740a58e9d
|
前端2
|
2026-09-13 18:31:38 +08:00 |
|
|
张胜宇
|
e38ece32bf
|
前端提交
|
2026-09-13 15:56:54 +08:00 |
|