张胜宇
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
62501747a6
新增 sys_user 认证现状探查（判断"账号密码登录"可行性）
...
tools/probe_auth_state.py：只读统计 sys_user 的 status / user_type 分布与 password_hash
的格式特征（只输出前缀与长度，不输出完整值）。
结论（docs/evidence/auth-state.json）：库里 5 个用户，password_hash 全是占位符 ——
4 个是 'x'（tools/seed_test_rbac.py 写入），1 个是 '!worker-only-no-password-login!'
（alembic 迁移写入的哨兵值，名字本身就表明"不用于密码登录"）。
has_real_password_hash = false。
⇒ 在本项目做"账号密码换令牌"不是"加个端点"的事：没有密码可校验，等于要新建一套密码体系
（选算法 + 加依赖 + 定义写入流程 + 改上游数据），而 password_hash 是基线已有字段
（规则 4：不得改变既有业务含义）。docs/05 §11 也已明确该职责属统一身份认证模块。
顺带记录一个数据质量问题：user_type 取值不统一（employee / 员工 两种写法并存）。
2026-09-11 20:30:27 +08:00
lzf_0626
3029d0ca9f
更新 release-state 证据：画像工具白名单已补发（release 254 active）
2026-09-11 20:24:07 +08:00
lzf_0626
927a6fecc0
评审 NL_develop 交付说明：三个环境前提必须先对齐
...
产出 docs/NL_develop交付说明-评审意见.md（可直接转给组员），以及一个只读探查工具
tools/probe_knowledge_collections.py（Milvus 集合 schema 与行数）。
核查中发现的硬矛盾，都有可复核的证据：
1. 配置库不是同一个。对方说 active=216、合并前生效版本是 186；我这边实测 active=201，
最近 5 条 id 就是 201/198/197/196/195 —— release.id 自增，同库不可能一边 216 一边 201。
所以他以为已发布的 customer_service:faq=[search_knowledge, query_customer_profile]
在这边并不存在，而他的画像出口复用的正是这个 key ⇒ 合并后被 ToolExecutor 失败关闭。
同理他说的 fund_query_demo:fund_quote 缺失，我这边是存在的。
2. Milvus 也不是同一个。对方说现库字段是 knowledge_id/snippet、无 visibility、行数
106/177/73；我这边实测是 doc_id/content/chapter/section/.../visibility 共 15 个字段、
行数 125/297/214，且与 knowledge_search_service.py 的 OUTPUT_FIELDS 逐字一致。
他这次的字段映射改动（doc_id→knowledge_id）在这边会直接报 field knowledge_id not
exist，把客服知识检索整条打挂 —— 比他自述的"关闭 visibility 隔离"严重得多。
建议不是 A/B/C 三选一，而是第四种：运行时探测字段名，两套 schema 都能跑。
3. 解释器不同。他用 .venv（项目里不存在，那是他机器上的 gitignore 目录），约定是
D:\conda\envs\jr_py313。所以"mypy 151→181"跑不到本基线 —— 这边是 138 文件 0 错。
另指出：docs/26-JWT密钥管理与轮换.md 会与已存在的 docs/21-JWT密钥管理与轮换.md 重复，
建议并入 21；驳回删除 docs/04/06/10/13/99。
四项待裁决的答复：同意 agent_type 方案（要求补审计）；字段映射改为运行时探测；
驳回删除编号文档；26 并入 21。
2026-09-11 16:51:52 +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
lzf_0626
c11e56c7aa
同步 docs/24 的过期状态；登录端点不改（docs/05 明确平台不实现）
...
docs/24 是客服阶段的总结，正文保留为当时的事实，本次做两件事：
1. 刷新"当前状态"表的数字：mypy 113→137 文件、unit+contract 497→664、
integration 29→33、active 发布 181(5 项)→201(10 项：9 条 agent_tools + 1 条客服
闲聊提示词)。数字由 tools/probe_release_state.py 只读查库得到，证据留档
docs/evidence/release-state.json。
2. 追加第七节"后续更新"，记录阶段总结写完之后的变化：两件待决策事项已落地（闲聊
提示词已按继承语义发布、适当性两侧口径复核通过）、风控合并后的处理要点、以及
三个仍然开着的口子（热线占位符、like %% 全表扫、offset 游标并发跳行）。
登录端点：**不改**。docs/05 §11 明确"JWT 签发、刷新、注销由统一身份认证模块负责，
Agent 平台不重复实现"，本平台只做校验（app/core/security.py）。第五节第 8 条据此改写，
同时把第 7 条"风控尚未启动"标记为已完成。
顺带修正"已知缺口"里的一条：列表接口的 next_cursor/has_more 风控侧已补齐，客服侧仍待办。
2026-09-11 14:26:17 +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
df96275ab5
给 trigger_rule_codes 加 JSON 多值索引；登记 P3 处理结果（docs/25 P3 #21）
...
实测确认 #21 描述准确：fin_risk_alert 只有 11 个普通 BTREE 索引 + 主键 + alert_no
唯一键，规则命中的 JSON_CONTAINS 查询 EXPLAIN 为 type=ALL、possible_keys=NULL，
即全表扫。MySQL 8.0.27 支持多值索引，故新增迁移 20260911_risk_rule_index：
ADD INDEX idx_fin_risk_alert_trigger_rule_codes
((CAST(`trigger_rule_codes` AS CHAR(16) ARRAY)))
迁移幂等（先查 information_schema.STATISTICS），upgrade/downgrade 往返已验证。
生效后 EXPLAIN 变为 access_type=range 且 key 命中该索引，原始证据留档在
docs/evidence/risk-index-probe.json（由 tools/probe_risk_index.py 生成，只读探查）。
只解决一半，另一半如实记为限制：若干 like(f"%{keyword}%") 全表扫无法用 B-tree 索引，
根治需全文索引 + 中文分词组件（部署依赖），本轮不做。
revision 名刻意压到 32 字符以内 —— alembic_version.version_num 是 VARCHAR(32)，
超长会在写版本号时报 1406，而 DDL 是非事务的，那时索引已经建好了。
docs/25 追加"P3 处理结果"表，逐条登记 17-25 的状态：#19 是协议级重做（keyset 分页）
不单方面改，#21 部分修复，#25 前半段不成立，其余已修。
2026-09-11 14:19:05 +08:00
张胜宇
24f75636a0
feat: add knowledge import preflight
2026-09-10 20:22:53 +08:00
张胜宇
a789872c79
test: record pre-migration workspace evidence
2026-09-10 17:11:52 +08:00
lzf_0626
6516ccb385
feat: 第二版——接口契约对齐 docs/05，修复静默故障与数据库基线
...
相对第一版 46fc976
2026-09-10 15:55:54 +08:00
张胜宇
lzf_0626