张胜宇
e5b4d02b0d
merge: 集成投顾组 3 个提交（解除与「投顾模块清除」的冲突）+ 客服 Agent 重构收口
...
## 为什么要合并
远端 `origin/qyqy_develop` 领先 3 个提交（`5607751` / `2fe7d0c` / `74b7d00`：投顾需求与架构文档、
客户主动申报投顾方案 + 受理自动出草稿、方案交付落点与推荐依据 LLM 增强），而本地 `5d0becb`
按 `D4.4` / `D4.5`（CS-PURGE-2026-012/013）把投顾模块整体清除了。**两个目标不可兼得**：
远端新代码反向 import 已被清除的模块（`app.model.investment_goal`、
`app.service.product_recommendation_service`、`app.service.advisor_rollout_service`），
强行推进只会让两边都跑不起来。
**裁定：投顾组的新功能 > 本地的投顾清除。** 依据是 `D4.4` §0-②③ 自己写下的风险
——按名字清投顾会同时拆掉产品数据底座与 MVP 硬阻断，并失去"改 6 个底座文件时的对照组"。
本次合并因此**恢复投顾模块**；就代码面而言，`D4.4` / `D4.5` 的清除结果被本次合并取代
（留痕见 `开发文档\D1.6` §4.37）。
## 冲突怎么解的（12 处）
- **8 处 modify/delete 取远端**：`recommendations.py` / `product_recommendation_service.py` /
`employee-advisor/dashboard/{actions-module.js,dashboard.css,dashboard.js,index.html}` /
`tools/{check_portal_modules.py,grant_advisor_role.py}` —— 即"我删、远端改"，保留投顾文件。
- **3 处内容冲突取远端**：`app/main.py`（投顾 import 与 `include_router`）、
`common/api-client.js`（投顾端点表）、`tests/unit/api/test_portal_frontend.py`（4 条投顾前端契约）。
- **1 处取远端 + 保留我方**：`app/main.py` 解除冲突的同时，保留本轮的
`/customer-service-test` 挂载移除（该联调页与用例已随重构作废）。
## 因"取消清除"而必须回滚的语义改动（否则恢复出来的投顾代码跑不动）
- `app/service/agent/bootstrap.py`：恢复 `AdvisorAgent` 与 5 个投顾工具注册
（`query_investment_goal` / `analyze_portfolio` / `generate_asset_allocation` /
`recommend_products` / `compare_products`）；客服 Agent 注释按本轮口径保留。
- `app/core/config.py`：恢复 `advisor_rollout_enabled` / `advisor_rollout_customer_ids`。
- `app/static/portal/common/layout/app-shell.js`：恢复投顾工作台导航与 `advisor` 角色名。
- `tools/seed_test_rbac.py`：恢复"admin 取全量元组"的授权模型（保留远端新增的
9070-9074 权限码与客户侧 9071/9072 绑定）。
- `tools/portal_api_check.py`：恢复投顾实测用例（AD003/AD005/AD011/A047 与 `advisor_t` 登录），
并**新增判定**：被渲染的集合为空（0 条）时判 `SKIP` 而不是 `FAIL`
—— "没有行"与"字段没带"是两回事，混报会把排查方向带偏。
- `app/static/portal/common/api-client.js`：以远端为基准，重新叠加本轮的
**访客令牌 `Authorization` 优先**修复（浮窗访客身份稳定性）。
## 数据库夹具同步（代码恢复 ⇒ 夹具也要恢复）
- `tools/grant_advisor_role.py`：新建 `advisor` 角色并授权（实测 34 项权限）。
- `tools/create_test_user.py --id 9020 --username advisor_t --role advisor`：重建演示账号。
## 集成期发现并修掉的过期断言
- `tests/unit/test_advisor_migration_contract.py`：alembic 末端钉死值仍是
`20260914_baseline_auto_increment`，而远端新增了 `20260916_advisor_service_request`
⇒ 这条断言**在远端分支上本身就是红的**。本次把它更新到新末端并补了注释。
## 验证（本机实测）
| 门禁 | 结果 |
|---|---|
| `pytest -q`（全量，含集成） | **1909 passed / 3 skipped / 0 failed** |
| `ruff check app tools tests` | 20（远端分支 22，本地仅客服线基线 19） |
| `mypy app` | 2（= 既有基线） |
| `tools/portal_api_check.py` | 40 项：通过 35 / 失败 0 / 跳过 5 |
| `tools/e2e_smoke_test.py --read-only` | 31/31 |
| `_eval_harness/http_probe.py` | 11/11 succeeded |
| `_consistency.py` | GATE PASS |
| `_fe_boundary_http.py`（前端入参边界真机） | 全部符合预期 |
## 未做（如实登记）
- **投顾演示数据未灌**：`AD011` / `A047` 需要 `advisor_product_suitability_reference`
这类带 `source_url` + `document_sha256` 的证据行，而披露文件不在仓库里；
`tools/seed_advisor_demo.py` 明确"不编证据"（fail closed），故这两条按空集 SKIP。
- **客服线文档目录仍未入库**：`客服agent/`、`开发文档/`（权威副本在本机）与
`_chunks_report.txt`（本地构建产物）依旧排除在提交之外。
2026-09-20 14:52:35 +08:00
张胜宇
5d0becb67d
客服 Agent 重构收口：五出口决策链 + 知识库档位隔离 + 前端入参边界（答辩演示版本）
...
一、客服 Agent 智能增强（正面回应"不智能、动不动就转人工"）
- 决策链由 2 个出口扩到 5 个：E1 澄清 / E2 计算型 / E3 知识直返 / E4 证据约束生成 / E5 分级回退
- 转人工从"默认动作"降为最后一档 E5c，只保留 4 类白名单：
P0 反诈 / P1 账户与个人数据 / P2 写操作与争议 / 用户明确要求人工
- 46 条金标实测（修复前 → 修复后）：
转人工率 43.5% → 10.9%；出口准确率 45.7% → 100%；事实正确率 69.6% → 100%
禁忌违反 1 → 0；档位越权 / 无出处数字 / 误拒 四项零容忍全 0
- 安全不变量 INV-1~INV-5；零容忍规则未删，改的是挂载点
（输出侧字面黑名单 → 检索层档位隔离 + 判定层合规词表 + 输出守护）
二、知识库：档位单点化与物理隔离
- 新增 app/core/knowledge_tier.py 作为档位规则唯一落点（G-03），
knowledge_contracts.py 原定义块改为显式再导出（X as X，非副本）
- 档位过滤由 bool 默认值（fail-open）改为 tiers 必填集合（缺参即 TypeError）
- Milvus 侧四集合按 visibility 分区键物理隔离；双 schema 收敛为一套
- 新增 app/core/actor.py：访客三元组与匿名判定的唯一构造/判定点（G-01/G-01b）
- 新增 app/core/fund_fee_rules.py：费率计算纯函数
三、前端入参边界对齐（本轮 W11 新修，4 处"校验宽于存储"）
- message 加 max_length=8000（与浮窗 widget.js 的 maxlength 一致）
- session_id 加 1—64；idempotency_key 上限 128 → 64（对齐列宽 String(64)）
- feedback_type 加 max_length=32（对齐列宽 String(32)）
- 8 条路径参数补 min_length=1 + max_length=64 + 字符集正则
（{session_id} / {run_id} / {handover_id}）
- 改前超限值会落到 MySQL 才失败（500）；改后一律 422 AGENT_INPUT_INVALID + 字段级定位
- 新增 tests/unit/api/test_frontend_boundaries.py（33 例），含"端点表 ↔ OpenAPI 全量对照"
四、投顾模块整体清除（D4.4 / D4.5）
- 删除投顾相关 controller / schema / model / repository / service 及门户页面
- tools/portal_api_check.py 同步作废 AD003/AD005/AD011/A047 四条用例与 advisor_t 登录
（端点与账号均已不存在，此前稳定报 3 条假红）
五、验证（提交前实测）
- pytest -q：1856 passed / 2 skipped / 0 failed
- ruff check app tools tests：19（= 基线）；mypy app：2（= 基线）
- 前端接口契约体检 portal_api_check.py：38 项，通过 34，失败 0，跳过 4
- 全链路冒烟 e2e_smoke_test.py --read-only：31/31
- HTTP 全链路探针 http_probe.py：11/11 succeeded
- 跨文档一致性 _consistency.py：GATE PASS
- 真机边界复验 12 条：12/12 符合预期
六、纪律与文档
- 可改文件白名单 A-09（docs/46）与底座会签申请单 A-10（docs/47，组 1—组 4 全部受理）
- 零 DDL：未新增/修改任何表结构，89 张业务表与基线一致
- 证据留痕：docs/evidence/**（含 46 条金标 score、快照、清除与重建记录）
- 未提交（刻意排除，见提交说明）：仓库内 客服agent/ 与 开发文档/ 是 2026-09-16 前的
过期副本（Todolist 440 行 vs 权威 D2.1 1167 行），权威正本在仓库外；
_chunks_report.txt 是 tools/build_knowledge_chunks.py 生成的本地产物
2026-09-20 14:33:30 +08:00
lzf_0626
9490e5043b
记忆系统演示文档 + 修掉两处会让演示断链的真问题
...
## 新增：docs/演示用/记忆系统演示文档-2026-09-14.md
按"操作 → 看到什么 → 这体现什么"写，五个场景（探针看存储 / 记住一件事 / 谁能读谁读不到 /
画像版本与投影 / 停 Worker），每个场景配可复现命令与**实测输出**，另附建议顺序与时长、
六条问答话术、演示前自检清单、受控信号词表摘录。
配套两个新工具（都已实跑）：
- `tools/memory_demo_chain.py`：一键走完"客户说 → 候选 → 客户确认 → 管理员批准 →
记忆与画像自动收敛"，打印演示前后对比（实测 2 秒收敛）。
- `tools/memory_recall_demo.py`：同一客户换六个身份召回，当场看出"客户只读自己 /
员工要权限码+归属 / 运营读不到 / 管理员有权限码但没归属也读不到"。
## 修掉两处会让演示当场断链的问题（都是真机复现的）
1. **候选批准后画像字段不收敛**
`CustomerProfileCandidateService._promote` 只写画像快照、**不投**
`profile.rebuild_requested`，而 `user_facts` 与画像字段是 `ProfileAssemblyService`
的重建链路写的。后果：批准后记忆变 active、快照版本 +1，但**画像字段停在旧值**
（客户说"三年以内"，画像里还是"十年以上"），要等一次无关的重建才收敛 ——
而"客户说完 → 批准 → 画像变了"正是演示主线。
现补一条重建事件（走事件而不是就地重建：本方法所在事务还没提交，
另开 session 看不到刚写入的记忆）。
2. **画像快照的唯一键从来没起作用，而且埋雷**
`uk_profile_snapshot_current` 建在列 `current_customer_id` 上（不是 `is_current`），
但 `ProfileAssemblyService._write_snapshot` 旧行只置 `is_current=False`（不清该列）、
新行**不写**该列（实测 13 行该列全 NULL）。
后果：只要客户**先被重建过一次**，旧 current 行仍占着 `current_customer_id=9001`，
下一次"批准画像候选"就会撞 `Duplicate entry '9001' for key
uk_profile_snapshot_current` → **整次批准 500**（本次实测踩到）。
现按唯一键的真实语义写：清旧行的该列、新行显式写客户号。
（`ProfileGenerationService` / 候选路径本来就是这么写的，只有这一处没对齐。）
## 守卫
新增 `tests/integration/test_profile_snapshot_current_invariant_mysql.py`：
按真实顺序"先重建再批准候选"，断言 ① 只有一条 current 且它占着唯一键、
② 历史版本已归还该列、③ 批准不再 500、④ 批准投出了重建事件。
修复前这条用例会在第 ② 步失败。
## 验证
- `pytest tests/unit tests/contract` → 1490 passed, 2 skipped, 0 failed
- 新增集成用例通过；真机实测演示主线：候选 → verified → active → **2 秒内**
`user_facts` 与 `fin_customer_profile.investment_horizon` 都变成新值
- `mypy tools/memory_demo_chain.py tools/memory_recall_demo.py` → 0 错；ruff 全绿
## 文档
`docs/44-演示流程.md`：配套文档清单与"记忆链路"备选场景都指向新演示文档。
2026-09-15 00:55:44 +08:00
lzf_0626
076d786bc6
补齐客服转人工工单流：从"只能看"到"能推进"（基线状态机，不自行发明）
...
## 问题
`svc_handover_ticket` 的 DDL 与状态机在 `docs/02` §7.2 早就定好了
（pending → assigned → processing → resolved → closed，未解决可 cancelled），
但平台**只有 handover:read（只读队列）**：没有任何入口能改状态、assigned_to /
accepted_at / resolved_at / closed_at / resolution 五列**全库 0 非空**，
于是 40 张工单永远停在 pending —— 用户看到的就是"工单全都长一样"。
## 改了什么
后端：
- 新增 `app/service/customer_service_handover_action_service.py`：五个动作
（分配/接单/解决/关闭/取消），`SELECT ... FOR UPDATE` 锁单后判状态；
接单允许从 pending 自助接管（同时记受理人）；取消不写 closed_at（该列属 closed 状态）；
每次流转写一条 interaction_audit（handover.assigned/accepted/resolved/closed/cancelled）；
非法流转 409、坐席不存在 422、工单不存在 404；回包不含 customer_id/session_id。
- 只读服务保持只读（读侧与写侧是两条边界，单测守着"读侧不许长出写方法"），
但列表支持 `?status=` 六态筛选、详情补上受理人与流转时间（坐席侧路由信息，非客户数据）。
- `app/api/controllers/admin.py`：五个 action 端点 A049–A053
（assignments / acceptances / resolutions / closures / cancellations），
走 `ApiTransactionService.execute_in` —— 幂等记录与业务写入同事务、重复键回放。
- 权限：新增 `handover:write`（9069，只授 admin），已并进种子
`tools/seed_test_rbac.py`；配套幂等脚本 `tools/grant_handover_write_permission.py`。
前端（管理员工作台 · 转人工工单页）：
- 按状态给按钮（待处理→分配/直接接单、已分配→接单、处理中→解决、已解决→关闭、
未解决都可取消），加了状态筛选与"刷新"；摘要弹窗补上受理人与四个时间点、处置结论。
- api-client 注册五个端点；workspace.js 的 api-client 引用与页面自身的 ?v= 一并升版，
避免浏览器拿旧缓存（旧缓存里没有这些端点）。
冒烟与测试：
- `tools/e2e_smoke_test.py`：B 段建的测试工单由 F 段走完 分配→接单→解决→关闭 收尾
—— 既不再把测试件堆在 pending 队列里（此前每次冒烟攒一张），又让每次冒烟都覆盖一遍状态机。
总数 40 → 44 项，实测 44/44 全绿。
- 新增单测 24 条（状态机合法/非法路径、越权、坐席不存在、审计、视图不泄漏客户标识）
与一条真机集成用例（HTTP 十步 + 数据库侧审计证据 + 自动清理）。
- 读侧那条"详情不得返回 assigned_to"的旧断言按新口径更新，并写清为什么。
## 验证
- `pytest tests/unit tests/contract` → 1489 passed, 2 skipped, 0 failed
- 新增集成用例通过；`tests/integration` 全量跑时
`test_memory_extraction` / `test_run_cancellation_mysql` 两条偶发红 —— 单独跑都通过，
是 AGENTS.md 已登记的"常驻 Worker 抢队列"（跑验收前须先停 Worker）
- `tools/portal_api_check.py` → 41 项通过 39、失败 0
- `tools/e2e_smoke_test.py` → 44/44 全通过
- `python tools/check_rbac_seed_consistency.py` → 通过（种子 63 条权限）
- 真机 HTTP 实测：分配→接单→解决→关闭四步 200 且时间戳齐全；取消路径 200 且 closed_at 为空；
同键重发回放不二次推进；对已关闭工单再分配 409；风控账号处置 403
## 文档
`docs/44-演示流程.md`（场景 4/8 + 命令 + 44 项）、`docs/演示用/后端接口文档`（新增 §11.4b 与
A049–A053）、`docs/演示用/全功能流程-大白话版.md`（工单页签改"读写"+ 已知偏差）、
`AGENTS.md`（9066-9069 号段演进 + 冒烟 44 项）
2026-09-15 00:41:59 +08:00
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
yuancong_0626
2548c39c6b
袁聪的最后一次完善更新
2026-09-14 18:13:10 +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
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
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
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
lzf_0626
468ae0bd47
fix(admin): 激活意图不再归档同 Agent 的其他意图（风控 4 意图曾只剩 1 条生效）
...
两个相关的缺陷，都属于**静默失效**型。
1. `admin_service._transition_intent_config`（真正的 bug）
激活一个意图时按 `agent_type` 过滤旧 active 版本并归档，但唯一键是生成列
`active_key = concat(agent_type, ':', intent_code)` —— 同一 `agent_type` 下
**不同意图码本就允许并存**。于是激活 `general` 会把
`risk_overview` / `risk_search` / `risk_evidence` 一并归档：风控运行期只剩 1 条
active 意图，问"查看当前风险概览"被分到 `general`（confidence 0.5），
而**没有任何报错**。该函数自己的 docstring 写的正是正确行为，实现与它不符。
2. `tools/publish_risk_agent_config.py`（使脚本无法自愈）
按 `intent_code` 单键建 dict 收集现有意图，而列表**按 id 倒序**返回且同一意图码
有多个版本，于是**旧版本覆盖新版本**；取到 v1 后再"版本 +1"算出的正是已被占用的
v2，创建必然 409 IDEMPOTENCY_CONFLICT。现象是 4 条意图全部"创建失败"而库里
其实都有，`tools/seed_demo_data.py` 第 7 步因此必然失败。
修复后实测：
- 库里 4 个风控意图全部 active；
- 问"查看当前风险概览" → `intent=risk_overview`、`confidence=1.0000`
（修复前为 `general` / 0.5）；
- `tools/seed_demo_data.py` 10/10 步完成、退出码 0（修复前第 7 步退出码 1）。
回归测试：`test_activating_one_intent_does_not_archive_sibling_intents`。
已确认把修复回退后该用例**确实失败**（`['beta'] != ['alpha', 'beta']`），
不是永远通过的空测试 —— 原有用例盖不住这个缺陷，因为它建的第二个意图始终停在 draft、
从未激活过。
门禁：ruff 通过；mypy 250 文件 0 错；unit+contract 1381 passed / 0 failed；
integration 104 passed；e2e 冒烟 40/40。
2026-09-13 22:08:04 +08:00
yuancong_0626
a501060e50
merge: merge yc into qyqy_develop
2026-09-12 12:50:14 +08:00
yuancong_0626
91f5373cfb
袁聪的第三次提交，API接口完善
2026-09-12 12:20:01 +08:00
lzf_0626
441364437c
merge: 合并 ZSY 的客服 Agent 接入（访客身份、画像候选、转人工工单）—— PR #7
2026-09-12 12:05:25 +08:00
张胜宇
e85989b344
merge: integrate latest qyqy_develop (auth login + RBAC read) into ZSY branch
...
Incremental merge on top of ef701c8bbf623abbf623a
2026-09-12 10:37:53 +08:00
张胜宇
ef701c844c
merge: integrate ZSY customer service and profile capabilities
2026-09-11 22:31:51 +08:00
lzf_0626
5018f11843
增加投顾（advisor）角色；修正登录测试的错误假设；修投顾带入的 2 处文档重号
...
## 投顾角色
投顾线合并后，bootstrap.py 有 10 处 allowed_roles 引用 advisor，
financial_nl2sql_service.py:272 还硬编码检查 {"advisor","operator","admin","super_admin"}，
promotion_material_service.py:164 按 "advisor" in context.roles 走业务分支 ——
但 sys_role 里没有这个角色、sys_permission 里也没有投顾那 16 个权限码（种子只建到 9019）。
表现是所有投顾接口 403，而报错看起来像"权限配错了"，实际是角色根本不存在。
- tools/grant_advisor_role.py：建 advisor 角色（id=9004，避开种子的 9001-9003 重建范围）
+ 16 个投顾权限（id 9020-9035）+ 授权（advisor 拿 10 项工作流、admin 补齐 16 项）。
只增不删、可重复执行、带 --dry-run。
- tools/create_test_user.py：ROLE_IDS 加 advisor。
- 先跑 alembic upgrade head：补 21 张 advisor_* 表，业务表 68 → 89，审计通过。
权限划分：投顾工作流 10 项（read:self / generate:self / review / publish）给 advisor；
治理类 6 项（product-governance:*、profile-governance:*、asset-allocation:backtest）只给 admin。
review/publish 也给 advisor，与既有决策一致（此前已裁定不做双人复核）。
验证：advisor_t 登录 200，roles=['advisor'] data_scope=all 权限 10 项；
用它查 RBAC 清单得 403（没有 audit:read），边界正确。
⚠️ 与种子的冲突：seed_test_rbac.py 是 DELETE 重建语义，其
DELETE FROM sys_permission WHERE id BETWEEN 9001 AND 9099 会清掉本脚本建的权限。
要把投顾权限固化，应并进 seed_test_rbac.py 的 PERMISSIONS 常量。
## 修正登录测试的一个错误假设
test_issued_token_actually_works_on_a_real_endpoint 原本用客户的
/users/me/memory-profile 验证令牌可用，投顾合并后它返回 403。追下去发现**与令牌无关**：
那个接口对客户有业务前置"请先完成开户风险测评问卷"，而演示客户 9001 没有测评记录。
是我的测试选错了验证端点，把"业务前置未满足"误判成"令牌坏了"。
- 改用管理员令牌调 /api/v1/admin/roles（需要 audit:read，走完整鉴权链路），
并补一条反向对照：不带令牌必须 401，否则那个 200 说明不了令牌有效。
- 把那个业务前置单独写成一个用例，让后来者一眼看到条件，而不是反复怀疑令牌。
过程里我先按控制台乱码猜了两次失败原因，都不对；最后把响应抓成 UTF-8 文件才看到真实
消息。教训记下：不要读乱码猜消息。
## 修投顾带入的 2 处文档重号
21-投顾Agent迁移TODO.md → 30-…、22-投顾Agent灰度与回滚操作手册.md → 31-…
（沿用 NL 那次让号的先例：既有文档更早、引用更多；且这两份新文档没有被任何地方引用。）
文档守卫：40 份无编号冲突。
验证：ruff 干净 / mypy 228 文件 0 错 / 文档守卫 40 份无冲突 /
unit+contract 1207 passed（0 failed）/ integration 99 passed / 业务表 89 张。
2026-09-11 21:49:46 +08:00
lzf_0626
6812fbe317
B1：RBAC 只读查询接口（4 个）+ docs/05 登记 A035-A038
...
在此之前，权限只能靠脚本改，平台里**没有任何地方能看"谁能访问什么"**。
B1 先把"看得见"做出来：
- GET /api/v1/admin/roles 角色清单 + 权限数 + 在用人数
- GET /api/v1/admin/roles/{role_code} 角色详情
- GET /api/v1/admin/roles/{role_code}/permissions 权限清单（按权限码排序，
便于与各 Service 的 require() 对照）
- GET /api/v1/admin/users/{user_id}/roles 某人**实际解析出来**的角色/权限/数据范围
几个刻意的决定：
1. 权限码复用 `audit:read` 而不新增 `rbac:read`：这份清单本身就是审计材料，且复用是零数据
改动、立刻可用（新增权限码要先改 sys_permission，而它目前由 seed_test_rbac.py 以
DELETE 重建语义管理）。将来要细分再加，不冲突。
2. `/users/{id}/roles` 直接复用 IdentityService.resolve，不自己拼 SQL —— 那正是请求进来时
走的链路（status 检查、assigned_at/expires_at 时间窗、data_scope 取最高、客户分配）。
自己写一遍必然漂移，而"这里查出的权限"与"实际能用的权限"不一致比没有这个接口更糟。
测试里加了一条交叉验证：该接口的 roles/data_scope 必须与登录响应完全一致。
3. 停用账号返回**空权限集**而不是 404 —— 用户存在但拿不到权限，如实呈现比 404 更利于排障。
4. 角色详情与权限清单分开：权限为空的角色不该被误判成"角色不存在"。
5. 全部只读、不写审计（它们返回的就是审计材料本身），docs/05 §19 登记时审计列标"否"。
权限变更（提权/降权）仍无接口 —— docs/05 §19 已注明那不是遗漏，而是需要单独评审
（审计留痕 + 禁止自我提权 + 保护内置角色三条红线）。
另：确认了 load_context 对 sys_user_role.expires_at 是有过滤的（assigned_at<=now AND
(expires_at IS NULL OR expires_at>now)），我上一轮只读了半段 SQL 差点误报。
验证：ruff 干净 / mypy 185 文件 0 错 / 文档守卫 38 份无编号冲突 /
unit+contract 1140 passed / integration 98 passed（本批新增 8 个）。
2026-09-11 21:22:56 +08:00
lzf_0626
01ee68034d
新增登录接口：账号密码换访问令牌（POST /api/v1/auth/tokens）
...
背景：客户 / 员工 / 管理员三种身份此前无法区分。但区分逻辑其实早就完备 ——
bootstrap.py 里各 Agent 的 allowed_roles 一直是分开的（CustomerServiceAgent 只要
customer、RiskAgent 要 risk_operator/admin、PlatformProbeAgent 只要 admin），
唯独缺"怎么证明你是谁"；sys_user.password_hash 字段也一直存在，只是全是占位符
（种子写 'x'、worker 身份写 !worker-only-no-password-login!），从没写过真实密码。
实现：
- app/service/auth_service.py：bcrypt 校验 + 签发只含 sub 的 JWT + 审计。令牌里只放 sub
是刻意的：角色/权限/数据范围由 IdentityService 每次请求查库解析
（identity_repository.load_context），权限变更因此立即生效，现有鉴权链路一行未改。
- app/api/controllers/auth.py + app/api/schemas/auth.py：POST /api/v1/auth/tokens，
响应含 roles/data_scope 供前端决定进哪个界面（鉴权仍以库里实时数据为准）。
- tools/set_user_password.py：设密码（客户 123456 / 员工 666666 / 管理员 88888888）。
⚠️ 脚本与文档均标注"仅限演示环境"，这三种弱口令上线前必须更换。
- pyproject / requirements 加 bcrypt（cryptography 只用于 JWT，不提供密码哈希）。
安全约定（逐条有实现与测试）：失败不区分原因 —— 用户不存在/密码错/账号停用返回同一条
401，否则接口就成了账号枚举器；用户不存在时也跑一次 bcrypt 以抹掉时序差异；
成功与失败都写 interaction_audit（actor_id 可空正是为失败场景准备的）；绝不记录密码。
过程中踩到一个自己挖的坑：给登录路由挂了通用的 enforce_rate_limit，而它声明依赖
build_request_context ⇒ 变成"要登录先登录"，所有登录都 401。改为新增
enforce_login_rate_limit：按客户端 IP 独立限流（60 秒 10 次）、不依赖认证上下文。
集成测试据此调整：注入恒放行替身隔离跨用例的计数累积，同时保留一个恒超限用例验证闸门
确实会拦 —— 不能因为加了替身就把这道防线测丢。
接口登记：docs/05 §19 加 A034；并更新 §11 —— 那里原写"JWT 签发、刷新、注销由统一身份
认证模块负责，Agent 平台不重复实现"，现注明平台只做登录这一步，刷新/注销仍归该模块。
验证：ruff 干净 / mypy 183 文件 0 错 / 文档守卫 37 份无重号（此前因 docs/21 重号失败）/
unit+contract 1140 passed / integration 90 passed。
2026-09-11 20:43:21 +08:00
qyqy
7677aeaee1
merge: 并入同事的场外申购/推广/行情/NL2SQL 线（11 提交、334 文件）
...
冲突仅 3 个文件，全部取并集（双方都没有需要丢弃的改动）：
- app/main.py：import 双方路由（我方 knowledge_management + 同事的 offsite_fund/
promotion_material）；include_router 段本已自动合并
- app/service/agent/bootstrap.py：import 与工具注册均取并集
（query_customer_profile + query_financial_data 都注册）
- tests/integration/test_config_release_mysql.py：outbox 清理同时保留
架构师的 event_type 限定（防误删其它域 outbox 行）与同事新增的 peer_release_id
同事这轮带入：11 个 alembic 迁移（建 offsite_* / promotion_* 等表）、
场外申购与推广素材 Agent、financial NL2SQL 工具。
注意：本库尚无 offsite_*/promotion_* 表，跑相关测试前需要执行 alembic upgrade。
边界核对：同事的场外代码未写入场内交易表（fin_sim_order/fin_capital_flow/fin_cash_ledger），
符合 AGENTS.md 规则 8。
2026-09-11 18:56:26 +08:00
张胜宇
1eb04f28b1
test: fix mysql profile snapshot cleanup
2026-09-11 18:09:36 +08:00
yuancong_0626
3f7c5ca74f
merge: 同步 origin/qyqy_develop（风控扫描、知识检索、客服 Agent、协商等）
...
冲突处理：均为双方各自新增，按并集保留——
- .gitignore：本地 data/logs 忽略项 + 远端 .dsh-drop/
- app/core/config.py：offsite/promotion 与 risk_scan 配置项并存
- app/service/agent/bootstrap.py：场外/推介/风控/NL2SQL/知识检索 工具与 Agent 全部注册
- app/worker/__main__.py：场外邮件 Worker 接线 + runtime 关系服务/投影清理注入并存
收尾：新增 20260911_merge_risk_heads 收敛迁移双 head；按 docs/21 生成 config/jwt/dev 开发密钥。
2026-09-11 17:32:47 +08:00
yuancong_0626
61861cdef6
袁聪merge：合并分支
2026-09-11 17:26:18 +08:00
yuancong_0626
fd9598efdf
袁聪的第二次提交，项目已完整
2026-09-11 16:57:47 +08:00
张胜宇
ef098e6a4b
feat: complete customer service safety and handover flow
2026-09-11 16:11:30 +08:00
qyqy
cbd6de2721
Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-latest
...
# Conflicts:
# app/service/model_gateway.py
2026-09-11 15:38:11 +08:00
wangjianlong_0626
e4c4099aaa
wip: 客服Agent + RAG + 画像收尾（基于 6516ccb）
2026-09-11 14:46:40 +08:00
lzf_0626
15866d4564
风控写接口接入平台幂等（docs/25 P3 #22）
...
docs/05 §5.1 把"业务写接口"列为必须携带 Idempotency-Key 的接口，风控 6 个 POST
（手工扫描、确认接收、进入调查、关闭误报、完成结案、升级处理）此前一个都没带，
重复提交会二次驱动状态机。
复用平台的 api_request_receipt 与 ApiTransactionService，但新增 execute_in：原来的
execute 自己开 SessionFactory() 和 session.begin()，而 RiskActionService._finish
会在内部 commit，套进去就成了"内层提交外层事务"。execute_in 改为在调用方传入的
session 上读写幂等记录，幂等记录因此与业务写入同处一个事务（§5.2）。
scope 用实际路径（含 alert_no）而不是路由模板：§5.1 的幂等范围是
user_id + method + normalized_path + idempotency_key，把路径参数折成模板会让同一个键
在不同预警之间互相回放 —— 那是把两次不同资源的操作当成一次。
测试：单测加幂等透传替身与"缺键即 422"用例；新增
tests/integration/test_risk_idempotency_mysql.py，覆盖同键回放不重复执行、同键不同
正文 409、缺键/非 ASCII 拒绝，以及端到端"重复 POST 只调用一次处置逻辑"。
2026-09-11 14:12:56 +08:00
张胜宇
8e36a9941d
merge: preserve existing business features on new foundation
2026-09-10 17:26:52 +08:00
lzf_0626
6516ccb385
feat: 第二版——接口契约对齐 docs/05，修复静默故障与数据库基线
...
相对第一版 46fc976
2026-09-10 15:55:54 +08:00
yuancong_0626
5907fcd6d2
袁聪的第一次提交，包含nl2sql,行情数据,场外申购
2026-09-10 09:23:22 +08:00
Codex
b1497fd2c6
chore: initialize project repository
2026-09-09 21:55:37 +08:00
张胜宇
lzf_0626
yuancong_0626
wangjianlong_0626