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 项）
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 的端点表登记。