AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
101 Commits 12 Branches 0 Tags
b5b068065fe5fbc0c8dc123fb0c976c6c69aced7
Commit Graph
53 Commits
Author SHA1 Message Date
zhangshy beb67f0a26 优化奶龙字段语义理解 2026-09-11 19:37:26 +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
lzf_0626 5bbf8481ef Merge pull request '信封补齐、适当性矩阵修正与 Worker 失败原因落库' (#5) from qyqy_develop_1 into qyqy_develop 
合并 qyqy_develop_1 第三轮工作：meta 信封补齐与公共化、适当性按第十二条匹配矩阵、Worker 失败原因区分固定文案与异常消息。
 2026-09-11 16:42:29 +08:00
zhangshy a122f7afba 修复风控预警记录查询与准备脚本 2026-09-11 16:40:15 +08:00
lzf_0626 fcd3eaadd6 Merge origin/qyqy_develop：风控时间口径补齐 + Agent 截断提示 
组员的 4 个提交（相对 c11e56c）：

- 4b0c148 把我这边的风控 P3 收尾与适当性豁免额度合并进 qyqy_develop（PR #4）
- 2ebe438 docs: 增加风控 Agent 工具白名单与意图配置
- 5102eaa Merge origin/qyqy_develop into RM2_develop
- d2cdbba 修复风控时间口径与 Agent 截断提示

自动合并零冲突，两侧的改动是互补而非重叠：

- 时区：我在 list_alerts 做了 from_local，他补的是 list_evidence 与通知列表；
- 截断：我加了 data_truncated / evidence_truncated，他在 risk_agent 的 system prompt
  里加了第 10 条 —— 这些标记出现时不得按全量证据下结论。方向是一致的。

验证：ruff 干净 / mypy 138 文件 / 703 unit+contract（+6，组员新增的用例）/
33 integration，均在合并后的工作树上跑过。
 2026-09-11 16:33:55 +08:00
lzf_0626 8b8883ccca Worker 失败原因不再只留类名：区分"可落库的固定文案"与"异常消息" 
起因是查 Worker 运行状态时发现库里 373 条死信的 last_error 全是裸的 "ValueError"
（工具 tools/probe_worker_state.py，证据 docs/evidence/worker-state.json）。
dispatch（run not found）、dispatch_run_completed、dispatch_memory_extraction、
dispatch_profile_rebuild 抛的都是 ValueError，只记类名等于把"哪一处失败"也一起丢了。

但"直接存 str(exc)"是错的：tests/unit/worker/test_outbox_worker.py 那条
RuntimeError("credential=do-not-log") 断言异常消息不得落库 —— 它可能含凭据、SQL 或
客户标识。第一版改动就是这么写的，被这个测试当场拦下（这测试写得值）。

折中：

- 新增 OutboxHandlerError（继承 ValueError，这些失败本就是 ValueError 语义，保持
  继承关系才不会改动既有的 except ValueError 行为与断言）。它的 reason 由代码写死、
  不含任何请求数据，因此可以落库；
- safe_error_text：OutboxHandlerError → "类名: 固定文案"（截断 500 字符），
  其余异常 → 仍只记类名；
- runtime.py 的 5 处 handler 失败改抛 OutboxHandlerError。

测试：新增"固定文案落库"用例；并把既有用例的断言收紧为 last_error == "RuntimeError"
（原先只断言"不含 do-not-log"，太松，漏掉的情况测不出来）。

顺带产出 tools/probe_worker_state.py（只读）：outbox / agent_run 各状态计数、按事件
类型分组、死信原因聚合。当前环境实测 pending 347、dead 373、published 410、
agent_run 无 queued/running。

门禁：ruff 干净 / mypy 138 文件 / 697 unit+contract / 33 integration。
 2026-09-11 16:28:19 +08:00
zhangshy d2cdbbac01 修复风控时间口径与Agent截断提示 2026-09-11 15:25:45 +08:00
lzf_0626 8d79bd9767 补齐三个成功响应缺失的 meta 信封；信封实现抽为公共（docs/05 §3.3） 
"缺 meta"很容易被误判成"有"：X-Trace-ID 是**响应头**（中间件加），和 body 里的
meta.trace_id 是两件事；错误响应一直有 meta（异常处理器统一加），漏的只有成功路径。

核到三个端点在把 service 的内部结构直接当响应体返回：

- GET /conversations/{session_id}/messages → 裸 {"data": [...]}，meta 整个缺失，
  游标也没地方放（§3.3 要求列表的 data 为纯数组、next_cursor/has_more 进 meta）
- POST /conversation-messages/{id}/feedback → 同样没有 meta
- GET /knowledge-references/{token} → 直接返回资源对象

改动：

- 新增 app/api/views/envelope.py，把 envelope / list_envelope 抽成一份公共实现，
  风控链路改为复用它 —— 同一份契约写两遍的结果就是其中一处漏了 meta。
- ConversationService.messages 改为返回内部结构 {items, next_cursor, has_more}，
  用 limit + 1 判断 has_more：只看"取满没取满"会把恰好等于 limit 的最后一页说成
  还有下一页。next_cursor 取本页最后一条的 message_id —— 游标语义是"取更旧的一页"，
  天然可续，集成测试本来就是这么翻页的。
- Controller 统一套信封，data 仍是数组、字段名不变，前端不需要改。

测试：新增 tests/unit/api/test_response_envelope.py，断言 set(body) == {"data","meta"}
（多或少一个顶层字段都会红），并覆盖 has_more / next_cursor / trace_id；
另更新两处既有断言（limit 20→21、feedback 返回裸对象）。

门禁：ruff 干净 / mypy 138 文件 / 696 unit+contract / 33 integration。
 2026-09-11 15:21:36 +08:00
lzf_0626 575b4c2baa 客服适当性改按第十二条匹配矩阵（更正我上一轮的复核结论） 
你说得对：C ≥ R 是风控的口径，客服要走政策原文的矩阵。

上一轮我复核后说"两边一致、无需改动"是错的 —— 我只对比了政策文本与
SuitabilityService，漏了第三个东西：客服自己的知识库。POL-AST-012 就是第十二条矩阵
原文，而客服为 C1-C5 补的「能买什么产品」问答答案直接取自该矩阵（docs/24 第二节）。
于是同一个客服 Agent 对同一个问题给出相反答案：

  问"C1 能买什么产品"   → 知识检索答 R1、R2 可买（矩阵口径）
  问"C1 能买这只 R2 吗" → 适当性出口答不能购买（严格 C ≥ R）

政策冲突的精确位置也不是"矩阵 vs 硬匹配"，而是第十四条**第 1 款与它自己的第 2、3 款**
矛盾：第 2 款说"低于一个等级以上"才拒绝（C1→R2 只低 1 级，够不上"以上"），第 3 款禁止
C1 买 R3+、C2 买 R4+（R2 不在禁止列表）。矩阵与第 2、3 款三方一致，孤立的是第 1 款。

改动：

- suitability_service.py 新增 MATRIX_ALLOWED / MATRIX_NEEDS_DISCLOSURE，_decide 由
  "C < R 即拒绝"改为按矩阵：C1→R2、C2→R3 直接可买；C3→R4、C4→R5 走第十五条豁免档
  （reason_code=SUITABLE_WITH_DISCLOSURE，强制揭示 + 确认 + 录音）；低两级及以上仍拒绝。
- 客服话术分档：越级档不再说"在您的风险承受能力范围内" —— 那句只对 C ≥ R 成立，
  用在 C1 买 R2 上会让客户以为自己的测评本来就覆盖这只产品。
- 风控侧不动，保留 C ≥ R：它要发现的是"越级成交且留痕不全"，这个差异是有意保留的。

测试：新增逐格对照政策原文的 25 格矩阵用例、豁免档用例、话术分档用例（+29）。
docs/25 第七节 #1 与 docs/24 第七节同步更正，包括写明我上一轮那个结论错在哪。

门禁：ruff 干净 / mypy 137 文件 / 693 unit+contract / 33 integration。
 2026-09-11 14:47:08 +08:00
lzf_0626 ff681df143 落地第十五条豁免额度校验；登记三处业务裁定 
一、第十五条豁免规则（docs/25 第七节 #2，业务裁定：实现）

政策原文：C3→R4 签署风险揭示书后**可买**，但单只 R4 持仓不超过总资产 20%；
C4→R5 同理，上限 10%。越级购买本身不是违规，超出额度才是 —— 原先扫描侧只看
"留痕是否齐全"，于是"签了字但买超额度"这种明确违规没有预警；研判侧也把豁免的
前提条件（留痕齐全）当成了结论，直接判"疑似误报"。

- 扫描侧：新增 EXEMPTION_LIMITS 与 RiskRuleEngine._exemption_state，核算
  "单只持仓 / 总资产"并写进证据快照；触发条件改为
  gap > 0 and (missing_trace or 超出额度)。
- 研判侧：_assess_rw007 先判额度再判留痕。超限 → 证据支持风险；留痕齐全且在额度
  内 → 疑似误报；留痕齐全但快照缺总资产/持仓 → 继续复核。

数据前提（tools/probe_exemption_data.py，证据见 docs/evidence/exemption-data-probe.json）：
库内 fin_customer_profile 仅 1 行且 total_asset = 0.00、fin_holding 0 行、无任何申购
交易 —— 这条规则当前不会被触发，与 behavior_score 同源（画像与持仓由本项目之外的
流程写入）。因此刻意不把"算不出来"当成"超限"：拿 0 去算会让每一笔 C3→R4 都变成违规，
豁免规则反倒成了误报源。上游把数据写入后无需再改代码即可生效。

二、三处业务裁定（此前挂在"待裁定"）

- 模型网关 chat + tools 入口：本轮不补，按基座能力缺口记录。它要贯穿
  ModelGateway → … → BaseAgent 整条链路，属公共契约变更，演示联调期影响面大于收益。
- exclude（关闭误报）是否必须先"调查中"：保持现状，不加门禁。
- 政策冲突：以第十四条 C ≥ R 为准；客服侧 check_suitability 复核后确认本来就按
  C ≥ R 实现，无需改动。

三、其他

- 新增 tests/unit/service/test_risk_judgement_rw007.py（6 例）与扫描侧 4 例。
- 风控文档 03/05 同步 RW-007 的豁免额度条件与研判口径。
 2026-09-11 14:24:45 +08:00
lzf_0626 661b17c244 风控全量查询封顶并在响应里标注截断（docs/25 P3 #20） 
预警详情里的资金流水/持仓/登录记录、以及日报的四组预警都是"一次性取全量"。某个客户
的历史数据一旦异常膨胀，单次响应就能把内存和连接拖垮；登录记录此前更是连时间窗都
没有。

处理原则是"封顶但**不静默**"：详情证据每类最多 200 条、日报每组最多 5000 条，用
`limit + 1` 多取一行判断是否真被截断（只看"取满没取满"会把恰好等于上限的正常数据
误报成截断），被截断时：

- 详情新增 `evidence_truncated: string[]`，列出被截断的证据类型；
- 日报新增 `data_truncated: bool` —— 日报的 daily_alert_count 等数字直接来自行数，
  静默截断等于给出一份看起来正常、实际少统计的日报，那比报错更难发现。

`scalars(...)` 统一用 `list(...)` 而不是 `.all()`，实现不再依赖 ScalarResult 的专有方法。

新增 tests/unit/repository/test_risk_repository_limits.py（3 例，用 literal_binds
编译 SQL，确保断言看到的是 201 而不只是"有 LIMIT"），并补日报与详情的标记用例；
风控文档 06 同步登记两个新字段与写接口的幂等要求。
 2026-09-11 14:16:07 +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
lzf_0626 790518114b 风控 SSE 内容协商与鉴权时序；docs/05 补齐 413 与风控入口（docs/25 P3 #23 #24 #25） 
#23：413 是上传超限的标准语义，前端文档（风控业务演示文档 17）也已按 413 做提示
映射，所以不把代码降成 422，而是在 docs/05 §3.5 状态码表补登 413 —— 契约以"补齐"
而不是"改动"的方式对齐。

#24：/api/v1/risk/daily-report/stream 此前既不校验 Accept，又把鉴权留在 async
generator 内部。后者更隐蔽：StreamingResponse 已经返回、响应头已经发出，403 只能
变成"200 + 半截流"。现在 controller 先 await service.authorize(context) 再判定
Accept，顺序与 §6.4 一致（鉴权先行，不用状态码差异做探测）。SSE 协商逻辑抽到
app/api/dependencies/negotiation.py，与 /agent-runs/{run_id}/events 共用同一口径，
避免同一种客户端在一个端点上 200、另一个端点上 406。

#25：复核后确认前半段不成立 —— §19 末尾写明业务域接口由各自业务文档登记，风控 15 条
端点已在 06-模块接口与字段映射.md 逐条登记。真问题是 §12 表里写的
/api/v1/risk-scans/**、/api/v1/risk-alerts/** 与实际实现 /api/v1/risk/** 不符，
按实际实现更新 §12 并加说明；顺带把风控文档里 /daily-report/mail 的权限从
"按主项目邮件策略执行"改为实际的 risk:report:mail。

新增 tests/unit/api/test_risk_stream_negotiation.py（7 例）。
 2026-09-11 14:08:55 +08:00
lzf_0626 a572c09a5c 风控列表游标绑定用户与查询条件（docs/25 遗留 P3） 
docs/05 §3.8 要求游标绑定用户、查询条件、排序字段和方向，此前实现只把 offset
用 base64 包了一层：任何登录用户拿到别人的游标都能继续翻，换个筛选条件也能继续翻
（偏移量对不上就静默返回错页）。现在游标里携带 SHA-256 指纹：

- 指纹口径 = user_id + data_scope/customer_ids + 查询条件（排除 limit/cursor）
- 刻意排除 limit：它是分页参数、不是查询条件，算进去只会让翻页时改页大小失效
- /evidence/{source} 的 source 是路径参数，单独并入指纹，否则 customers 的
  游标能直接拿去翻 products
- 指纹不符一律 InvalidCursorError -> 400 INVALID_CURSOR（docs/05 §3.6）

新增 2 个单测：换用户/换筛选/换 data_scope 失效、改 limit 仍有效、
不同证据类型游标不互通。
 2026-09-11 14:05:37 +08:00
lzf_0626 e8b075bc7f fix(risk): 列表接口的信封对齐 docs/05 §3.3——游标从 data 挪到 meta 
docs/05 §3.3 的列表样例是 data 为**纯数组**、
ext_cursor 与 has_more 放在 meta 里，
并明确「业务接口不得增加其他顶层字段」。而 RiskQueryService._page 返回的
{items, next_cursor, has_more} 被**整体塞进 data** —— 游标因此出现在**业务数据**里，
meta 只剩 trace_id，两处都不符合契约。

改动：
- 新增 _list_envelope(page, context)：把 _page 的结构拆成 data = items、
  meta = {trace_id, next_cursor, has_more}。**service 侧不动** —— 它继续返回那个内部
  结构，只是不再直接当 data 用。
- 3 个列表端点改用它：/alerts、/evidence/{source}、/notifications。
  非列表端点（overview、详情、各类写操作）保持原样，不带游标。

**影响调用方**：这是接口形状变更。组员若写了前端读 data.items，需要改成读 data、
并从 meta 取分页元数据。改动依据是 docs/05 这个唯一权威接口文档（§20 也要求实现与
文档同步）。**合并时要提醒组员。**

**实测**（9002 身份）：
- /alerts?limit=2 → 顶层键 ['data','meta']、data 是 list（2 条真实数据）、
  meta 键 ['has_more','next_cursor','trace_id']
- /evidence/customers 与 /notifications 同形状
- 对照 /overview（非列表）→ meta 只有 trace_id、不带游标

**测试**：3 处断言从 data["items"] 改为 data；/notifications 那处补上对 meta 的断言；
新增 test_list_endpoints_follow_the_documented_envelope，直接断言"data 是纯数组、
meta 恰好三个键、顶层恰好 data/meta"，把 §3.3 的契约钉住。

过程里踩了两个自己的坑：① 忘了 rom typing import Any（与 customer_service.py 同一失误，
被 ruff/mypy 当场抓住）；② 漏了 /evidence/{source} 这个列表端点，是测试先失败才发现的。

ruff / mypy(136 文件) / 640 unit+contract / 29 integration 全绿。
 2026-09-11 14:01:16 +08:00
lzf_0626 3ab7f33d64 fix(risk): 预警行带出 close_reason，日报的"误报原因"不再是空 
docs/25 P2。核实确认报告准确，而且这一处缺口造成两个症状：

_alert_row 是**列表 / 详情 / 日报共用**的行构造器
（risk_repository.py:174 / :276 / :321），而它的字段列表里没有 close_reason。于是：

- 日报的"误报原因"分布恒为"未填写"
  （risk_daily_report_service.py:139 用 item.get("close_reason") or "未填写"）；
- :243 的明细里同一字段同样拿不到值。

断的是"关闭误报时写入原因"这条链路的**下半段**：risk_action_service.py:70 把原因赋给
lert.close_reason、也确实存进了库（app/model/fund.py:368 有该字段），只是读取时没带出来。

修法是一行：在 _alert_row 里补上 close_reason。三个调用点同时受益；读取方都是风控侧
接口（需要 risk:alert:read），不涉及客户可见面。

新增 tests/unit/repository/test_risk_alert_row_close_reason.py（2 条）：关闭原因出现在行里；
未关闭时为 None 但**键必须在** —— 读取方靠 or "未填写" 兜底，键一旦缺失就永远只能走
兜底分支，那正是修复前的状态。

ruff / mypy(136 文件) / 639 unit+contract / 29 integration 全绿。
 2026-09-11 13:51:37 +08:00
lzf_0626 b241059c2a fix(risk): 合并预警的嵌套证据在研判入口摊平，RW-003 不再一律降级 
docs/25 P2。核实后比报告描述的更麻烦一点：合并后的 evidence_snapshot 只留
product_id 与 merged_alerts，**各条规则原有的证据键被塞进了嵌套结构**
（risk_scan_service._merge_same_transaction_alerts:398-404）。而各研判函数读的是
**顶层键**（snapshot.get("ratio") 之类），于是合并过的预警一律读不到证据、降级成
"缺证据无法复核" —— 合并本来是为了少几条噪音，结果把这些预警的研判全废了。

修法：在**研判入口统一摊平**，而不是让每条规则各自去认嵌套结构。

- 新增 _flatten_merged_evidence(detail)：顶层已有的键优先（来自 priority_score 最高的
  主预警），再按顺序补入各子条目 evidence 里的键；merged_alerts 本身保留，
  可追溯性不受影响；非合并结构原样返回。
- 列表级（_assess_list_rule）与详情级（_assess_detail_rule）两个入口都调用它，
  所有规则（RW-003/007/012/015/018）一并受益。

新增 tests/unit/service/test_risk_judgement_merged_evidence.py（5 条）：非合并结构原样返回、
嵌套键被抬到顶层、冲突时顶层优先、多子条目全部抬平，以及**报告症状的回归** ——
对比"没有 ratio"与"ratio 藏在 merged_alerts 里"两种输入，摊平后 RW-003 的研判结果
不再相同（原先两者都会降级成同一句话）。

ruff / mypy(136 文件) / 637 unit+contract 全绿。
 2026-09-11 13:49:57 +08:00
lzf_0626 c1f043684c fix(risk): RW-012 研判补上"≥3 倍历史均值"复核，顺带修一处除零 
docs/25 P2。核实后发现**根因不在研判侧偷懒，而在快照缺数据**：

- 扫描侧生成 RW-012 要求 verage > 0 且 amount >= average * 3（risk_scan_service.py:224）；
- 研判侧 _assess_rw012 只看了年龄、金额、非常用设备，**完全没核均值** —— 于是达不到
  3 倍的交易也会被判"证据支持风险"。它自己的建议文本写着"继续核实一年期历史交易均值"：
  作者知道该看，只是当时确实没有数据可看。
- 原因：扫描侧写进快照的只有 product_id / age / device_id，**没有均值**
  （对比 RW-003 在 :124 就写了 ratio）。

**两侧一起改**：

1. 扫描侧补写 verage_amount 与 
atio（用 ratio 与 RW-003 的快照风格保持一致）。
2. 研判侧据此复核：
atio 缺失 → CONTINUE_REVIEW（"无法复核 3 倍门槛"，
   不再顺着"非常用设备"定案）；
atio < 3 → SUSPECTED_FALSE_POSITIVE；否则走原有逻辑。
3. **顺带修一处除零**：verage == 0 时 mount < 0*3 恒为 False，会一路走到
   mount / average 直接崩。改为同时挡住 verage_amount <= 0。

新增 tests/unit/service/test_risk_judgement_rw012.py（3 条）：ratio 缺失时不落到风险成立、
ratio < 3 判误报并给出倍数、ratio >= 3 继续往下走。三个用例都停在登录记录判断之前，
不必构造复杂的登录证据。

ruff / mypy(136 文件) / 632 unit+contract / 29 integration 全绿。
 2026-09-11 13:48:08 +08:00
lzf_0626 85a1b33eff fix(risk): RW-018 研判的两个口径缺陷——列表级不再无条件放行，详情级与扫描侧对齐 
docs/25 P2。核实后发现这两条其实是**同一处的两个表现**，所以一起修。

**① 列表级无条件放行**
_assess_list_rule 收到 item 参数**却完全不看它**，对 RW-018 一律返回"可考虑放行"，
连理由文本都是硬编码的"现有摘要显示交易来自有效定投工单"。于是渠道不匹配、或证据里
根本没有工单信息的预警，在列表层就被标成可放行 —— 而列表正是风控专员最先看到的一屏
（详情层另有判断，但那要等人点进去）。

现在按 item["evidence_snapshot"]["channel"] 判断。快照里确实有渠道：扫描侧写入了它
（risk_scan_service.py:308），列表行也带出了整个 snapshot（risk_repository.py:955），
所以这个校验是可行的，此前只是没做。

**② 详情级与扫描侧口径不一致**
扫描按 work_order.channel in {"定投", "自动定投"} 生成预警（risk_scan_service.py:294），
详情级却只认 "定投"。于是"自动定投"的预警会出现**"扫描认为有效、详情认为未确认"**的
自相矛盾。

抽出 DIRECT_INVESTMENT_CHANNELS = frozenset({"定投", "自动定投"}) 作为唯一口径，
列表级与详情级都改用它；改这份常量即同时影响两侧。

新增 tests/unit/service/test_risk_judgement_rw018.py（6 条）：常量覆盖扫描侧全部渠道、
列表级在无渠道 / 渠道不符时**不得**放行、两个合法渠道在列表级与详情级都放行、
详情级对无关渠道不放行。

ruff / mypy(136 文件) / 629 unit+contract 全绿。
 2026-09-11 13:45:51 +08:00
lzf_0626 0d3447bde4 fix(risk): 日报邮件端点补上授权校验——它此前是风控里唯一没有校验的端点 
**问题**：POST /api/v1/risk/daily-report/mail 原先只取 context 做 401 判定，
**没有任何授权校验**；RiskDailyReportMailService.send 既拿不到 context、也不调用
AuthorizationService。收件人、标题、正文**全部由客户端决定** —— 一旦运维开启 SMTP
（RISK_DAILY_REPORT_MAIL_ENABLED），它就是一个未授权的邮件发送器。
默认关闭（ENABLED 默认 false + DRY_RUN 默认 true）让它至今没出事，但那不是可依赖的保护。

**改动**：
- send 改为 async 并接收 context，入口处 wait AuthorizationService.require(
  context, "risk:report:mail")。校验放在 **service 层**而不是 controller —— 本项目风控
  端点的授权一律落在 service（risk_query / risk_action / risk_scan 等都是这样），
  controller 只负责取 context；这个端点是唯一的例外，现在补齐。
- controller 相应改为 wait ...send(..., context=context)。
- 权限 
isk:report:mail 已在上一轮随另外三个一起创建并授予 risk_operator 与 admin。

**实测**：
- 9002(risk_operator) → **200** + {"status":"disabled","recipient_count":1}（默认关闭）
- 9001(customer)      → **403** AGENT_PERMISSION_DENIED「缺少操作权限」

**测试**：3 个既有用例改为 async 并传入带权限的 context；**新增**
	est_mail_service_requires_the_permission，断言无权限身份必须被拒 —— 钉住本次修复。

ruff / mypy(136 文件) / 623 unit+contract / 29 integration 全绿。
 2026-09-11 13:39:50 +08:00
lzf_0626 24de6c34f7 fix(risk): 扫描健壮性——脏数据不再中断整批，调度器重启后仍会执行 
docs/25 P0 的后两项，都属于"风控看起来在工作、其实没在跑"那一类。

**② 一条脏数据中断整批**
_level_value 原先直接 int(level.replace(prefix, ""))：等级字段只要有一条不是
R1-R5 / C1-C5（例如写了「中风险」），就抛 ValueError 并冒到 scan() 的兜底 → **整批
rollback**，本次扫描前面已经生成的预警全部作废。数据脏属于运维问题，不该升级成
"整个风控停摆"。

改为返回 int | None；调用点跳过该条并记 warning（带上 transaction_id 与两个原始值，
便于运维直接定位）。顺带把 
eplace 换成 
emoveprefix：原先 "R2R" 会被错当成 2，
现在只去掉开头那一个前缀字符。

**③ 调度器重启后永不执行**
last_run_at 只存在内存里，重启后为 None，而 _is_due 此时返回
config.run_immediately（默认 False）⇒ 重启后 _is_due 恒为假，**调度器形同虚设，
而且没有任何告警**。

改为"从未跑过即视为 due"：多跑一次的最坏后果是重复扫描，而扫描每条规则都先 _exists
查重、外层还有 MySQL 级锁；反过来"不跑"的后果可能是永远不跑。
config.run_immediately 不再承担"首次是否执行"的语义（它原本想表达"启动后别马上跑"，
但那与"永远不跑"在实现上无法区分），字段保留以免破坏既有配置。

新增 tests/unit/service/test_risk_scan_robustness.py（6 条）：脏数据返回 None 而不抛异常、
R2R 不被过度剥离、首次必 due（哪怕 run_immediately=False）、以及间隔前后的判定。

ruff / mypy(136 文件) / 622 unit+contract / 29 integration 全绿。
 2026-09-11 13:35:58 +08:00
lzf_0626 d331c817ac fix(risk): 通知创建失败必须能被区分出来，不再静默返回 0 
docs/25 P2「通知失败被吞」。核实后要把定性说得更准一点：它**有** logger.exception，
不是完全静默；问题在于 _create_notifications 失败时 
eturn 0，而"无需通知"
（没有高风险预警、或通知功能关闭）也返回 0 —— 调用方只拿到一个 notification_count，
**分不清"本来就不用通知"和"高风险通知创建失败"**。

风控里这个区别很要紧：通知没发出去等于处置链路的第一环断了，而扫描依旧报"完成"。
这与同一批缺陷里的"定时扫描重启后不再执行"是同一性质 —— 看起来在工作、其实有一环没跑。

改动：
- _create_notifications 返回 (条数, 失败原因)，失败原因非空即代表出了问题。
- scan() 在有失败时于返回体里带上
otification_failure，并把 message 改成
  "规则扫描完成，但高风险通知创建失败"，让上游与运维都能直接看到。
- **失败仍然不回滚预警**：预警已经生成、比通知重要，不该因为通知写失败就丢掉。

新增 tests/unit/service/test_risk_scan_notification.py（4 条），其中一条专门断言
"两种 0 必须可区分" —— 那是本次修复的全部意义。

ruff / mypy(136 文件) / 616 unit+contract 全绿。
 2026-09-11 13:33:41 +08:00
lzf_0626 e017bcc9bb fix(platform): 配置告警覆盖全部受 release 约束的表，并提供生效快照能力 
**问题**：上一轮加的"配置丢失告警"只比对 platform_config_item，而受 config_release
整版本替换影响的表有**三张**（按 information_schema 核对）：platform_config_item /
prompt_template_version / model_routing_rule。这个盲区造成过真实后果 —— 客服闲聊提示词
挂在 release 174，active 变成 181 后 load_active_prompt 读不到，而 Agent 侧有逐字段
兜底、回落到代码默认值，于是功能看着正常、没人发现、**一行告警都没有**。

**改动**（均在 app/service/config_release_service.py）：

1. 新增 RELEASE_SCOPED_TABLES：三张表 + 各自的**逻辑键**。逻辑键不含 release_id、
   不含自增 id、也**不含 version** —— 同名提示词在不同版本里可以用不同 version，
   那仍是同一份配置。清单是穷举的，并注明漏掉任何一张的后果都是静默失效。

2. 新增 effective_snapshot()：读当前生效版本在**全部三张表**里的内容，每行已剥掉
   id / 
elease_id（见 NOT_PORTABLE_COLUMNS），可直接作为新版本的写入载荷。
   发布脚本应先取它、再追加本次变更，这样"漏继承"就从"每次靠人记得"变成结构上不容易漏。

3. _warn_dropped_items 改为逐张表比对，告警里带上表名。

model_routing_rule 没有 ORM 映射，用原生 SQL 处理；它当前 0 行，但纳进来才不会将来
配了又漏。

测试：新增一条专门锁住"提示词被丢掉时也要点名"（那正是这次的盲区），并把 fake session
改成按表 + release 返回行 —— 第一版 fake 不分表，查提示词表时会拿到配置项的行、
报 KeyError，虽然真实代码是按表查的，但 fake 不真实就盖不住问题。

ruff / mypy(136 文件) / 612 unit+contract 全绿。
 2026-09-11 13:25:00 +08:00
lzf_0626 edc0c43245 test(base): 造只读探针端到端验证工具拒绝，并修掉它暴露的一个死分支 
**为什么造探针**：ToolExecutor 的四种拒绝在真实链路上很难安全触发——要么改客服、风控的
生效配置，要么动 RBAC，两条路都会影响正在工作的 Agent。platform_probe 是个只读、无副作用
的探针：它只声明 probe 一个意图（所以意图分类只可能返回它）、没有发布工具白名单
（天然处于"未配置"状态）、工具只回显参数不碰业务数据。

**它立刻查出一个死分支**：探针报的是「工具不在当前意图白名单」，而不是我新加的
「该意图未配置工具白名单」。原因是 governance.resolve 会为每个 supported_intents
**预填条目**（governance.py:55-61），未配置时得到的是**空元组**——所以
intent not in configured_tools 在运行期**永远不成立**，那个分支是死代码。

单元测试没能发现它，因为我在测试里手工构造了 configured={}，而真实链路不产生这个形状。
**这正是端到端测试的价值**：单元测试验证的是我设想的形状，端到端验证的是真实形状。

修法：改判"白名单为空"而非"缺键"，文案改为"该意图的工具白名单为空"，并注明经过 governance
装配后"完全没配"与"配了空列表"无法区分、也不假装能区分（两者运维动作相同）。新增一条按
**真实形状**（{"faq": ()}）构造的用例把它锁住。

实测：探针调用 → failed / AGENT_PERMISSION_DENIED，stderr 为
ForbiddenAgentError: 该意图未配置工具白名单（tool_executor.py:108）。

ruff / mypy(136 文件) / 611 unit+contract 全绿。
 2026-09-11 13:10:04 +08:00
lzf_0626 38a9bc8285 fix(platform): 配置发布激活时点名"将被丢掉的配置项" 
config_release 是**整版本替换**语义：激活新版本后，旧版本的配置项全部不再生效。
所以新版本只要漏了某项，它就是**无声消失**的——agent_tools 里的工具白名单一少，
相关 Agent 的工具就被 fail-closed 拒掉，而现场表现只是"客服/风控什么都答不了"，
没人会想到是发布配置少了一条。

本项目已经两次靠"发布前手工继承"规避（客服与风控的发布脚本里各写了一遍继承逻辑），
说明这个风险真实且反复出现。

改为在 activate 时先比对"被取代版本的配置项"与"新版本的配置项"，把将被丢掉的逐条
写进 warning 日志。**不阻断激活**——有时确实是要主动撤下某项配置，拒绝会让正常运维
做不了事；这里要的是"事后能查到是谁把它弄没的"。

新增 tests/unit/service/test_config_release_dropped_items.py（3 条）：丢项时点名、
完整继承时无噪音（否则运维会习惯性忽略这条日志）、首个版本不报丢项。

ruff / mypy(135 文件) / 610 unit+contract 全绿。
 2026-09-11 13:01:58 +08:00
lzf_0626 a7ac1b6a1c fix(platform): 让"工具用不了"的三种原因可区分，并消掉选端点的隐式顺序依赖 
基座层面的两处缺陷，都属于"静默失败"——排查成本高，且本项目已经各踩过一次。

1. tool_executor.py 的拒绝原因原先无法区分：
   - "意图压根没发布白名单"与"白名单里没这个工具"共用一句「工具不在当前意图白名单」，
     运维不知道该去补发布配置、还是改白名单内容（客服与风控的意图码都要求三处对齐，
     两次都因此多花排查时间）；
   - 权限与角色两处只说「缺少工具权限」，不说是哪一个。
   现在四种情况各有独立 message，各自指向不同的处置动作。

   同时把**审计与异常分离**：白名单内容、权限码、角色集属于内部配置，只写进审计；
   异常 message 会随 API 响应返回给调用方，保持通用、不泄漏配置。

2. model_gateway.py 的 TASK_CAPABILITY 补齐风控的几处 task_type
   （risk_agent_chat / risk_analysis / risk_script / risk_summary / daily_report_suggestion）。
   它们要的都是文本生成端点；不登记就会落到"未映射 → 返回全部 active 端点"的分支，
   而能否选对端点取决于 model_endpoint_config 的**行顺序**——实测风控能跑通，仅仅因为
   deepseek-flash(id=3) 恰好排在 qwen-embedding(id=5) 前面。这个隐式依赖现在消掉了。
   未登记的 task_type 仍退回全部端点（保持原有保守策略：让故障表现为调用失败而不是
   解析为空），但会记 warning，不再静默。

新增 tests/unit/service/test_tool_executor_denials.py（4 条），锁住"四种拒绝可区分"
与"内部细节只进审计、不进 message"。

ruff / mypy(135 文件) / 607 unit+contract 全绿。
 2026-09-11 13:00:23 +08:00
lzf_0626 b3da1b65ed fix(risk): 修正风控的时区缺陷——凌晨规则与日报日界 
docs/25 P1 #6。根因是"库内存 UTC naive"这个约定在**业务判断层**没被遵守，
而展示层其实已经是对的（risk_daily_report_service.py:418 按配置时区转换）。

1. 新增 app/core/timeutil.py 作为统一换算入口：约定库内 UTC naive，提供
   local_hour / local_date / local_day_bounds（后两者用于查库时必须返回 UTC naive，
   否则区间与库内值整体错开 8 小时），带时区的入参按其自身时区解释。
2. risk_scan_service.py:248：0 <= confirmed_at.hour < 6 → local_hour(...)。
   原先 [0,6) UTC 被当成"凌晨"，实际是北京时间 08:00-14:00，整条
   「凌晨时段小额操作」规则判的是上午。
3. risk_judgement_service.py:238/243：判断**与展示**都换算。展示不改的话，
   风控专员看到的时刻与直觉差 8 小时，无法与客户核对。
4. risk_daily_report_service.py:89：日界改用 local_day_bounds（按北京时间自然日，
   再折回 UTC naive）。原先按 UTC 日期切日，北京 08:00 前生成的日报统计窗口跨零点。

测试：
- 新增 tests/unit/core/test_timeutil.py（8 条），含"UTC 凌晨 0-6 点不是北京凌晨"
  这一缺陷复现，以及"日界必须返回 UTC naive"。
- 改写 test_risk_scan_service.py::test_night_small_trade_boundaries：它原本就拿
  UTC 小时构造数据（写 0 点/6 点），等于在测北京 08:00/14:00；语义一并修正为
  北京 00:00（含）与 06:00（不含）两个边界，三个边界场景保持不变。

ruff / mypy(135 文件) / 603 unit+contract 全绿。
 2026-09-11 12:50:52 +08:00
zhangshy 870fd0d44e Merge branch 'RM2_develop' into qyqy_develop 2026-09-11 11:44:51 +08:00
zhangshy 6911dd98a7 fix: 修复证据上传审计并补充前端操作提示要求 2026-09-11 11:42:53 +08:00
zhangshy aad3005830 Merge branch 'RM2_develop' into qyqy_develop 2026-09-11 11:25:24 +08:00
zhangshy 47056792eb fix: 规范预警详情客户编号映射 2026-09-11 11:24:22 +08:00
zhangshy 1673816c4f Merge branch 'RM2_develop' into qyqy_develop 2026-09-11 11:12:43 +08:00
zhangshy c7c6736c54 fix: 修复日报模型装配并统一本地时间格式 2026-09-11 11:10:33 +08:00
lzf_0626 478b64e4d7 Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop_1 
# Conflicts:
#	app/service/agent/bootstrap.py
 2026-09-11 10:43:08 +08:00
zhangshy ecd0627396 feat: 调整通知接口字段并补齐风控配置清单 2026-09-11 10:35:24 +08:00
zhangshy c2178a985d feat: 增加风控定时扫描 Worker 与环境配置 2026-09-11 09:49:21 +08:00
lzf_0626 c369a919c6 test(customer-service): 用格式矩阵把 _topic_of 的第四、五口咬痕也堵上 
方案 A：把每种出口的**真实产出**都过一遍 _topic_of。谁再改回答格式或加出口，测试立刻红，
而不是等客户实测先撞上——它已经咬了三次，三次都是客户先发现的。

写这个矩阵当场又抓出两个真 bug：

1. 整节块的主语带着章节号（"2.1 南方季季盈90天"）。下游 _product_risk_level 要求产品名
   是该块标题或正文的**子串**，带编号就永远匹配不上——适当性查询会静默失败、退化成转人工。
   这是真故障，不是洁癖。
2. 政策条款的主语是"第十二条 投资者与产品匹配矩阵"；整节块去掉标题行后剩下的表格行
   （"| C1保守型 | ✅ 可购买 |"）也会被当成主语。

修法：剥掉开头的章节号；排除以"|"开头的表格行；排除"第X条"开头的条款标题。

矩阵覆盖全部四个出口：知识直返（行级块/整节块/FAQ/政策四种形状）、适当性裁决（四种话术，
真调 _suitability_text 而非手写样例）、引导人工（兜底话术取不出主语是对的）、
闲聊（无产品实体，取不出也是对的）。
 2026-09-10 22:53:29 +08:00
lzf_0626 8b1ed70916 fix(customer-service): 自述等级的说明行不能挡住产品名 
实测连问「季季盈90天起投多少」→「C3 客户能买它吗」→「那我能买它吗」，第三问转人工。
原因是上一步刚加的客户自述等级说明（"您提到自己是 C3。…以您在公司留存的测评结果为准"）
占了回答首行，而 _topic_of 只看首行，产品名被挤到第二行，追问于是丢掉了指代对象。

这是 _topic_of 第三次因为"只认固定格式"而咬人（前两次：FAQ 的"问"字、适当性回答没有
冒号）。改成遍历回答前四行、逐行尝试解析，并把单行解析抽成 _topic_in。

同时补上自述等级时的依据说明：客户说"我是 C3"而系统答"您没有测评结果"，在他眼里是
矛盾的，必须点明判断以档案为准、不以自述为准。自述等级只用于这一句说明，**绝不**参与
裁决。拒绝后的指引也从"联系客户经理或拨打热线"改成"请先完成风险测评"。

新增三条单测：自述等级识别（含小写）、自述说明行占首行时仍能取到主语、
"为 R2"开头说明前面没有产品名时返回空。
 2026-09-10 22:48:56 +08:00
lzf_0626 c564494f84 fix(customer-service): 追问适当性结论时不能丢掉产品名 
实测三连问：「季季盈90天起投多少」→「C1 客户能买它吗」→「那我能买它吗」，
第三问转人工。原因是 _topic_of 不认识适当性回答的格式——它那一行是
"南方季季盈90天为 R2（中低风险），与您当前的风险测评结果不匹配…"，
既没有冒号也不是标题行，于是被判成"取不出主语"，第三问就失去了指代对象。

补上这种格式：产品名在"为 R{1-5}"之前，且必须在冒号判断**之前**匹配（那一行没有冒号）。
以"为 R2"开头的行说明前面没有产品名，返回空串，而不是把等级本身当成主语。

修好后第三问给出与第二问一致的结论，这是对的：裁决是确定性的，同一个客户问同一只
产品，结论就该一样。新增两条单测钉住这两种情形。
 2026-09-10 22:46:31 +08:00
lzf_0626 958fd62d64 test(customer-service): 锁住适当性出口的每条分支 
这个出口会给出"能不能买"的结论，写错一条就是误导客户，所以把话术与取数逻辑都用
单测钉住（14 条）：

- 话术：允许购买时报出产品等级与客户等级；需签揭示书/双录时明说；**拒绝时不下断言**
  （原因可能是等级不匹配、测评过期或未测评，统一说成"超出承受能力"是错的）；
  档案里没有测评结果时写"您目前没有在有效期内的风险测评结果"而不是"您的等级为未记录"；
  有效期截成日期。
- 产品名来源：只从上一轮回答的主语取，客户问句不算数，上一轮是兜底话术时返回空
  （调用方据此转人工，而不是瞎猜一个产品）。
- 产品风险等级：只认"风险等级"那一行；命中别的产品的等级行必须放弃（否则拿别人的
  等级给客户做裁决）；C1 的 FAQ 里"可购买 R1、R2"那种列举必须拒绝；检索降级或工具
  抛异常时返回 None 而不是一个等级——那会让裁决建立在"其实没查到"之上。
 2026-09-10 22:43:18 +08:00
lzf_0626 ee9de1b520 fix(customer-service): FAQ 型回答不能把"问"字当成追问的主语 
给 C1-C5 补 FAQ 之后暴露的连带问题：FAQ 型回答的首行是"问：C1 客户能买什么产品?"，
_topic_of 取冒号前的内容会拿到一个孤零零的"问"字，客户追问时检索词被污染成
"问 那它能买基金吗"。

改为"问"/"答"这类纯标签直接判为取不出主语，退化成只查当前这一句。

另附一条实测结论（**没有改代码**）：在 FAQ 型回答之后追问「那它能买基金吗」仍会转人工，
这是安全且合理的——上一轮回答里没有可指代的产品实体，而"C1 能不能买基金"本身取决于
那只基金的风险等级，知识库没有、也不该有这种一概而论的答案。按金融场景的原则，
"答不了"好过"答错"。
 2026-09-10 22:35:17 +08:00
lzf_0626 a7135d2549 test(customer-service): 补交检索问句的断言更新 
把检索问句从"拼上一轮原话"改成"只补产品名"时同步更新了本文件，但漏了提交。
新增的断言锁住两件事：上一轮的问句原话一个字都不能进检索词（拼整句会让检索词变宽、
只能命中粗粒度的整节块），以及上一轮是兜底话术时取不出主语应退化为只查当前这一句。
 2026-09-10 22:29:28 +08:00
lzf_0626 4c2b147793 feat(knowledge): 产品知识拆到表格行级，并按问句选粒度 
问题（客户实测反馈）：同一会话里问「季季盈90天起投多少」和「那它风险高吗」，两次回答
**一模一样**——都是整个产品小节的表格。客户问的是风险，收到的是整张说明书，看起来像
客服没听懂问题。

根因是切分粒度：原来"一个叶子标题 = 一块"，产品手册里就是整个产品小节（表格 + 说明）
成一块。这既让两个不同的问题命中同一块，也让整节几百字的向量成了"整节的混合语义"，
与"起投多少"这种具体小问题相似度天然偏低（实测该问句向量 top1 仅 0.6291，够不到 0.75
硬门槛，只能靠与次优的差值勉强通过）。

改动三处：
1. 切分：Markdown 表格的每一行额外生成一个**自解释**的小块（"南方季季盈90天：起投金额
   1万元"），挂在父块 doc_id 下（PROD-007-04），父块照旧保留。知识块 160 → 631。
   效果：该问句的命中分从 0.6291 升到 0.869，命中的正是"起投金额"那一行。
2. 检索：命中行级子块时把它的整节父块一并带回（分数按 0.9 折算），供调用方按问句选粒度。
   整节块保底占最后一个名额，且不参与 top1/top2 判定——实测它挤到第 2 位会把 gap 从
   0.090 压到 0.076，几乎跌破 0.07 的转人工门槛。
3. 客服：命中的是行级子块时，看问句与子块标签是否真的对得上——「起投多少」对「起投金额」
   对得上，用那一行；「介绍一下」对不上，换成整节。

过程中两次判据写错并已修正（都固化进了测试）：用"含连字符"认子块时，整节块自己的编号
PROD-901 被误判成子块；用"不含两位数字后缀"认整节块时，FAQ 块全被误判成整节块排到后面，
把正确答案挤出 top1、害得「基金赎回几天到账」转人工。

验证：起投/管理费等字段问法给出聚焦的单行答案；"介绍一下"给出整节；FAQ 与政策问法不受
影响（换话题、指代追问等此前修好的场景复测通过）；
ruff / mypy(113 文件) / 468 unit+contract / 29 integration 全绿。
 2026-09-10 22:29:23 +08:00
lzf_0626 a6c09fa3c4 fix(customer-service): 检索问句只在客户这一句说不清楚时才带上文 
实测的答非所问：同一会话先问「季季盈90天的起投金额是多少」，再问「基金赎回几天到账」，
第二问答出的是季季盈的产品介绍。原因是 _search_query 无条件把上一轮客户问题拼进检索词，
客户换话题时旧话题的检索结果被带了回来。在金融场景里这比"引导转人工"糟得多：客户问 A
得到 B 的答案会直接失去对客服的信任，而"答不了"至少是诚实的。

改为只在两种真正需要上文的情况下拼接：句子里有明确指代词（"这个产品""该基金"），
或短到不构成完整意图（"那它风险高吗"只有 6 个字）。指代词刻意不收单字"它/他"——中文里
"其他产品"会被误判，而这类短句已经由长度规则覆盖。

验证：换话题场景第二问回到 FAQ-0016 的到账时间，指代追问仍命中季季盈产品块；
ruff / mypy(113 文件) / 457 unit+contract 全绿。
 2026-09-10 22:17:34 +08:00
lzf_0626 570493e71c feat(knowledge): 知识检索增加产品名的字面兜底召回 
问题：客户问「季季盈90天的起投金额是多少」会被引导到人工客服，而知识库里明明有答案。
实测根因不是阈值拍错了，而是专有名词在 embedding 空间里不占优势——该问句的向量 top1
只有 0.6291，够不到 0.75 硬门槛，只能靠与次优的差值勉强通过；而同一次查询用
title like "%季季盈%" 是唯一命中 PROD-007。既然客户已经说出了产品名，就不该再赌相似度。

做法（三条边界都是实测逼出来的，不是设想）：
1. 只对产品集合做字面匹配。客户问「季季盈90天的起投金额是多少」与通用 FAQ 标题
   「基金起投金额是多少?」有 7 个字连续重合；把 FAQ 纳入字面匹配会让它和真正的产品块
   一起拿到满分、差距归零，反而又退化成"转人工"。
2. 字面命中只在向量结果不够确定时采用。客户问「基金赎回几天到账」时向量已给出正确答案
   （FAQ-0016 得 0.8060），但手册章节标题「5.2 基金赎回流程」与问句也有 4 个字连续重合，
   无条件采纳会把"操作步骤"顶掉客户真正问的"到账时间"。
3. 重叠门槛取 6 字而不是 4 字："基金赎回"这类业务动作词正好 4 字，会骗过 4 字门槛；
   产品名（"南方季季盈90天"）更长，6 字能同时保住产品名、挡住动作词。

未改动任何转人工判定阈值；VECTOR_CONFIDENT_SCORE 与 Agent 的 HIGH_SCORE 由单测锁定一致，
避免两处各自漂移出"谁都答不出来"的死角。

验证：季季盈类问法由"转人工"变为正确答出，基金赎回问法仍答 FAQ-0016；
ruff / mypy(113 文件) / 453 unit+contract / 29 integration 全绿。
 2026-09-10 22:15:50 +08:00
zhangshy a94d5c754d feat: 迁移奶龙风控业务模块与演示文档 2026-09-10 21:03:44 +08:00
lzf_0626 2c5ef35d18 chore: 删除退役的旧 JWT 密钥，同步过时引用并记录登录接口决策 
1. 删除 config/jwt/jwt-private.pem 与 jwt-public.pem（旧密钥，配置已不再指向）。
   删除后复跑全量门禁以确认没有残留依赖：ruff 通过、unit+contract 447 passed、
   acceptance_check --production 7 PASS、demo_agent_e2e 9/9 PASS。
2. 修掉 4 处引用旧密钥路径的地方（它们会在删除密钥后直接失败或误导接入方）：
   - tests/unit/core/test_security.py 的三处硬编码路径改为单一常量 DEV_KEY_DIR，
     否则删除旧密钥后该测试会因读不到文件而失败；
   - tools/demo_agent_e2e.py 的 docstring 前置条件；
   - docs/09 的配置示例；docs/19 的手工自签说明（改为指向配置项与
     tools/generate_jwt_keys.py）。
3. docs/21 记录旧密钥已删除，并注明删除后已复跑验证无残留引用。
4. docs/19 未解决项新增第 5 条：无登录接口属于**有意识的推迟**（等业务 Agent 开发阶段
   结束后再补），写明补的时候只需动签发侧、验签侧与身份解析侧都不需要改，
   并附上当前私钥边界的实测结论（无法伪造不存在的用户、无法使用已禁用账号）。
 2026-09-10 18:18:00 +08:00
lzf_0626 6516ccb385 feat: 第二版——接口契约对齐 docs/05，修复静默故障与数据库基线 
相对第一版 46fc976 的完整变更。组员迁移对照表见 docs/20。

一、对外契约对齐 docs/05（破坏性，共 4 处，组员需按 docs/20 调整）
1) 配置发布端点改为文档规定的复数资源名：submit→validations、
   approve→reviews（需 body decision）、activate→activations、
   rollback→rollbacks；第一版这 4 个动词式路径 docs/05 从未定义过。
2) 错误码由 8 个笼统码改为 15 个具体语义码（FORBIDDEN→AGENT_PERMISSION_DENIED、
   UNAUTHORIZED→AUTHENTICATION_REQUIRED、CONFLICT→RESOURCE_VERSION_CONFLICT、
   RESOURCE_NOT_FOUND→RUN_NOT_FOUND/SESSION_NOT_FOUND 等），
   输入类错误状态码 400→422。
3) POST /api/v1/agent-runs 与 GET /api/v1/agent-runs/{run_id} 统一为
   {data, meta} 信封（data 内字段名与语义未变）。
4) 错误响应体统一为 {error:{code,message,retryable,field_errors}, meta:{trace_id}}，
   不再返回 FastAPI 默认的 {"detail": ...}。

二、数据库基线与约束
新增 39 张表的基线迁移（链根）与联合唯一键纠偏（4 张表、删 8 增 4，幂等收敛）；
撤下 config_release 的双人复核 CHECK（应用层已允许自审，审核节点保留，
自审如实写入 reviewer_id）；记忆 active key 生成列与唯一键；
activate 开始记录 supersedes_release_id 使版本链可追溯。
docs/00 基线未修改，未重命名或删除任何表与字段。

三、修复会静默出错或无报错的缺陷
- 跑完集成测试后平台会静默失去生效配置：清理只删自己创建的版本，却没有恢复被它
  顶成 superseded 的原生效版本，且审计一并删除因而完全无痕，表现为所有工具被拒
  但没有任何报错。已修清理逻辑并加恢复。
- Worker 单轮异常导致进程退出；记忆抽取调用方的“事务已开始”异常；
  召回缓存丢失 degraded 标记；连接时区未生效导致 created_at/updated_at 差 8 小时；
  .env 与 os.getenv 密钥来源分裂导致“没有可用的已批准模型端点”。
- 记忆信号识别漏判与跨键误命中；SSE 未带 Accept 的协商行为。

四、功能补齐
记忆链路 P1/P2/P3（抽取、受控词表、召回与缓存、生命周期级联及投影事件）、
fin_* 场内交易只读 ORM 层、agent_intent_config 状态流转并在运行期真正生效、
限流（Redis 固定窗口、故障一律放行）、游标校验、trace_id 中间件、
示例业务 Agent fund_query_demo 与一键端到端验证脚本，以及审计/指纹/迁移状态工具。

五、文档与验证
新增 docs/19（业务 Agent 接入实操）、docs/20（第一版迁移指南）与 docs/evidence 证据；
docs/01/02/06/08/09/17 同步实现现状。

验证结果：ruff 通过、mypy 103 文件无错、unit+contract 447 passed、
integration 29 passed、acceptance_check --production 7 PASS、
demo_agent_e2e 9/9 PASS（含失败关闭反证）。
 2026-09-10 15:55:54 +08:00