AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
164 Commits 12 Branches 0 Tags
39f261da1478839286f1258fa9406aee4766ee64
Commit Graph
63 Commits
Author SHA1 Message Date
lzf_0626 0358ea519f 投顾演示数据准备脚本：配好测评与归属，方案那步如实报告卡在证据来源 
投顾线合并后 21 张 advisor_* 表全空，导致 published 返回 []、投顾 customer_ids 为空、
客户画像因缺测评返回 403。本脚本按依赖顺序补能自己造的那几样：

1. 产品目录：调 tools/import_hq_test_products.py 取真实行情（实测 19 个 ETF/LOF）；
2. 客户风险测评：给 9001 补一条 C5、有效期一年（answers 里注明是演示数据）；
3. 客户-投顾归属：9001 → 9020（assigned_at 往前留 5 秒，避开 DATETIME(0) 舍入陷阱）。

**方案那步不配** —— 缺的是证据来源不是技术：authoritative_tradable_products 是
fail closed 的（Missing or unverified evidence excludes a product），而造
advisor_product_suitability_reference 必须带 source_url 与 document_sha256，也就是真实的
销售适当性披露 / 基金合同文件（import_product_governance_reference.py 的两个 CSV，
不在仓库里，属环境数据）。脚本**不伪造这两个字段**（证据链红线），只检查并打印真正的解法。

实测：cust_t 的 /users/me/memory-profile 由 403 变 200（测评生效）；admin 视角看 9020 的
customer_ids = ["9001"]（归属生效）；advisor 的 published 仍为 []（符合预期，尚无方案）。

⚠️ 顺带发现一处口径不一致：画像 fin_customer_profile.investor_type 是 C2，而新补的测评是
C5 —— 前者决定画像展示、后者决定适当性裁决，两者会同时出现在界面上。演示前需要统一
（要么把测评改成 C2，要么把画像也改成 C5）。
 2026-09-12 10:34:28 +08:00
lzf_0626 306a514316 修正登录测试台的探针：投顾那个按钮其实该是客户视角 
/api/v1/advisor/recommendations/published 的语义是"**我（客户）自己**已发布的方案" ——
服务端按 `customer_id == 调用者 user_id` 过滤（权限码 `product-recommendation:read:self`
的 `:self` 正对应这一点），所以**投顾调它必然为空**：筛的是 customer_id = 投顾自己的 id。
把它标成 customer 角色，免得再用投顾账号点它、然后怀疑权限。

查证过程中确认了三处数据空缺（投顾合并后那 21 张 advisor_* 表是新建的）：
- client_facing_content = 0 行（没有任何投顾方案）
- sys_customer_assignment = 0 行（投顾没绑定任何客户，故 customer_ids 为空）
- fin_risk_assessment 里没有 9001（客户画像的前置"完成开户风险测评问卷"未满足）
 2026-09-11 22:28:32 +08:00
lzf_0626 636892c8b1 登录测试台支持投顾：快捷按钮 + 只读探针 
- 快捷填充加 advisor_t / abc12345；
- 探针加「已发布投顾方案」（GET /api/v1/advisor/recommendations/published），按 advisor 角色启用。

实测同一接口的对照：投顾令牌 200（data: []），客户令牌 403 —— 权限边界正确。
 2026-09-11 21:50:39 +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 c4a73b735e Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop 
# Conflicts:
#	app/main.py
 2026-09-11 21:41:04 +08:00
lzf_0626 e29fce4012 新增登录测试台：一个记事本级别的前端，用来在浏览器里验证登录 
tools/login_console.py —— 浏览器打开 http://127.0.0.1:8099 即可测。

与 chat_console.py 的关键差别：**它走真实登录接口**（POST /api/v1/auth/tokens）拿令牌，
而不是自己签。chat_console 是当初还没有登录接口时的权宜做法，这个测的是真链路。

页面能做的：
- 三个快捷填充按钮（客户 cust_t/123456、员工 risk_t/666666、管理员 admin_t/88888888）；
- 登录后显示用户、角色标签、data_scope、令牌有效期（令牌只显示前 24 字符）；
- 按角色列出可调的**只读**接口按钮（我的画像 / 风控概览 / 预警列表 / 角色清单 /
  管理视角看某人的身份），一眼核对"登录给的 roles"与"接口实际放行"是否一致；
- 把真实状态码与响应 JSON 原样摊在页面上，并写明 401 涵盖三种原因、429 是登录限流。

实现上不动 app/ 一个字节：内层用 create_app()，本进程只做两件事 —— 提供静态页、
把 /api/* 同源转发（httpx.ASGITransport 进程内调用，不起第二个服务）。同源转发避开 CORS，
也免得浏览器直连主服务；只监听 127.0.0.1，私钥始终留在服务端。

实测：页面 200；通过代理用 admin_t 登录拿到真实 JWT（sub=9003）；错密码 401。

顺带说明一条边界变化：docs/24 当初拒绝"给底座加 dev token 端点"，理由是那种端点等于把
**任意身份**开放给任何能访问服务的人。现在有了密码校验，浏览器拿令牌不再等于
"谁都能冒充任何人"，那条顾虑已消除 —— 所以这个页面不是绕过安全设计，而是设计补齐后的正常用法。
 2026-09-11 21:26:45 +08:00
lzf_0626 edd8c53c3a 修正 create_test_user 里写反的理由：sys_user_role 有唯一键，先清后插是为了支持改角色 2026-09-11 21:17:49 +08:00
Windows bbf623a464 merge: integrate advisor capabilities on latest qyqy base 2026-09-11 21:03:58 +08:00
lzf_0626 b1429aa364 登录接口配套：加人工具 + 给组员的转交文档（docs/29） 
- tools/create_test_user.py：一条命令建"可登录的测试账号"（用户 + 角色 + bcrypt 密码），
  并用 IdentityService.resolve 打印**真实解析结果**。sys_user / sys_user_role 没有 ORM
  模型、全靠裸 SQL，手写容易漏必填字段；更要紧的是 assigned_at 那个静默陷阱（见下）。
  重复执行同一 --id 是覆盖语义，改角色也用它。
- tools/set_user_password.py：hash_password 改从 auth_service 取，消除第二份实现。
- app/service/auth_service.py：新增 hash_password，与 verify_password 放在一起，
  让"写密码"和"校验密码"永远同一套算法。
- docs/29-Agent组员登录接口使用说明.md：给组员的转交文档（接口契约、加人步骤、
  前端接入示例、常见问题、当前边界）。

文档里专门写清三条最容易踩的：

1. 登录用 username 而不是用户 id —— 演示账号是 cust_t / risk_t / admin_t，
   不是 9001/9002/9003。这条不写明，联调时一定有人按 id 试。
2. sys_user_role.assigned_at 的 DATETIME(0) 毫秒舍入陷阱：落在未来会让账号
   "登录成功但 roles=()"，**不报错**。create_test_user 统一往前留 5 秒。
3. roles / data_scope 只用于前端分流界面，不是权限凭证 —— 鉴权每次请求查库解析，
   所以权限变更立即生效，前端也不该拿它们做安全判断。

另：create_test_user 的 ON DUPLICATE KEY UPDATE 用 MySQL 8.0.19+ 的 `AS new` 别名语法，
避开已弃用的 VALUES()（实测本机 8.0.27 会打弃用警告）。

验证：文档守卫 38 份无编号冲突 / ruff 干净 / mypy 183 文件 0 错 /
登录集成测试 10 passed。
 2026-09-11 20:50:41 +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
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 f09ea9e988 Merge origin/NL_develop：客服画像出口、知识管理三端点、合规语境与知识向量链路 
NL 线（含其并入的袁聪场外/推广域）。唯一冲突是 .gitignore —— 双方都往同一区域加了
.workdir/，取对方版本（他的更完整，含 .tmp/ 与说明），顺带修掉我之前用
Add-Content -Encoding utf8 造成的编码混合（read 工具当时报 invalid UTF-8）。

合并后修的问题 —— 都不是"改别人业务逻辑"，是让门禁能绿：

1. 缺运行依赖 python-docx。document_parser.py 解析 .docx 用它，但 requirements.txt 与
   pyproject.toml 都没声明 —— 别人环境跑知识入库会直接
   ModuleNotFoundError: No module named 'docx'。已补声明。
2. ruff 7 项：其中 tests/conftest.py 的 F821 Undefined name 'Path'（他的 tmp_path 修复
   写了字符串注解 "Path" 却漏 import，运行时不求值所以没炸，但 mypy/ruff 会抓）、
   tools/publish_customer_service_config.py 的 F841 inherited_keys 死变量（他改同 key
   覆盖、换成 inherited_only 后忘删旧的）、3 处 E501，另 2 项 ruff --fix 自动修复。
3. 合规基线种子未跑：integration 的 test_compliance_seed_mysql 4 个用例要求
   agent_negative_word 有 7 条 active 且已复核、agent_reply_template 覆盖 6 场景。
   跑 tools/seed_compliance_baseline.py（11 条 active 规则 / 6 个场景模板）后 80 passed。

验证：ruff 干净 / mypy 180 文件 0 错 / unit+contract 1140 passed /
integration 80 passed / 表数 68（alembic 已在 20260911_merge_risk_heads）。

唯一失败 tests/unit/repository/test_fund_readonly_contract.py 是双方一致的既有缺陷：
它断言 Base.metadata 里的 fin_* 表集合，而实测为空集 —— 即该测试依赖别的测试先导入模型的
副作用，单独跑必失败。NL 方也明确"不修不报"，此处照办，仅记录。
 2026-09-11 20:22:59 +08:00
lzf_0626 9957ddc191 Merge pull request 'NL_develop 评审答复与画像白名单补发脚本' (#6) from qyqy_develop_1 into qyqy_develop 
合并 qyqy_develop_1 第四轮工作：NL_develop 评审答复、画像工具白名单补发脚本、docs/08 §8。
 2026-09-11 19:58:29 +08:00
Windows fbb1171a45 feat: add quote sync command 2026-09-11 19:51:51 +08:00
lzf_0626 6c09cdecbd 新增补发画像工具白名单的脚本（dry-run + 合并前防呆） 
tools/publish_profile_tool_whitelist.py：把 query_customer_profile 加进
customer_service:faq，供 NL_develop 合并后在本环境补发配置。

关键设计都来自这轮评审核实到的事实：

1. 继承走 ConfigReleaseService.effective_snapshot()，一次拿全三张受管表
   （platform_config_item / prompt_template_version / model_routing_rule）。
   既有的两个 agent_tools 发布脚本都绕开它、自己写 SQL 只查第一张 —— 用它们发版
   会把 201 里那条客服闲聊提示词一起清掉，而 Agent 侧有兜底、功能看着正常、没有告警
   （这个事故在本项目真实发生过一次）。
2. 同 key 覆盖：继承项里的 customer_service:faq 必须被本次新值覆盖，否则旧值
   ["search_knowledge"] 会被 admin 端校验拦下、整次发布失败。
3. 提示词搬运重分配 version（唯一键含 version），并按 PromptPayload 的 9 个字段挑字段、
   归一化 input_schema/output_schema —— 漏带就是静默丢失。
4. 前置防呆：admin 端校验「配置 ⊆ 代码 allowed_tools」（admin_service.py:219-220），
   合并前跑必然 422，而报错只有"配置超出 Agent 工具上限"。脚本先查代码上限：
   dry-run 给警告后继续预览，正式跑直接中止。
5. JSON 列归一化：SELECT * 读出来的 JSON 列可能是字符串，不解析会静默走进
   "生效版本里没有该 key"的分支（本脚本第一版就是这么错的，诊断打印才定位到）。

实测：--dry-run 打印 9 条配置项 + 1 条提示词（v2→v3 重分配）与唯一变化；
正式跑因代码尚未合并而中止，未产生任何写入。
 2026-09-11 19:51:44 +08:00
Windows b6429e0e9c feat: add advisory product comparison tool 2026-09-11 19:20:32 +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
Windows 930dd59d67 feat: complete advisory market data refresh pipeline 2026-09-11 18:39:57 +08:00
Windows 95633188f1 test: extend advisor e2e fixtures 2026-09-11 17:59:47 +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
Windows 3e4f21388c test: complete advisor full-stack acceptance record 2026-09-11 17:19:40 +08:00
yuancong_0626 fd9598efdf 袁聪的第二次提交，项目已完整 2026-09-11 16:57:47 +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 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
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
qyqy 395bad25b7 fix(knowledge): 检索服务适配现库集合 schema、发布对齐的工具白名单、免责声明只由治理层注入 
合并暴露的三个真机问题（单测全绿但线上必挂）：

1. 检索服务字段名与现库集合不符 -> 静默零召回
   架构师那套按 load_knowledge_milvus.py 的 schema 读 doc_id/content/chapter/section/
   visibility，而现库三集合的真实字段是 knowledge_id/title/snippet/tags/version/intent。
   Milvus 对不存在的字段直接报错 -> 三集合全失败 -> degraded -> 客服一律转人工。
   改法：只改读取侧，用 _FIELD_ALIASES 映射；KnowledgeHit 对外形状不变（下游与测试不动）。
   代价已注明：没有 visibility 字段 -> 检索层内部资料硬隔离失效（现库 356 行均为对外知识）。

2. 发布白名单与代码上限不匹配 -> AGENT_PERMISSION_DENIED
   active 版本白名单是 query_knowledge，而合并后代码上限是 search_knowledge/check_suitability/
   query_customer_profile -> 交集为空 -> 所有知识问题 failed。
   改法：publish_customer_service_config.py 补 PROFILE_TOOL 进 faq 白名单，并让同 key 的
   继承项被本次定义覆盖（旧值原样继承会被子集校验 422 拒掉整次发布）。已激活版本 216。

3. 免责声明重复出现
   Agent 自己拼一句 + 治理层追加权威话术 -> 客户看到两条。改为只由治理层注入
   （话术属发布配置，改文案不该改代码）。风控等内部 Agent 不注入（结构化输出不被污染）。

测试：934 passed / 1 failed（test_fund_readonly_contract 既有空集缺陷，与本线无关）
真机：知识问答两问 succeeded 且只带一条声明；画像问答 succeeded；知识库三端点全绿
 2026-09-11 15:27:16 +08:00
zhangshy d2cdbbac01 修复风控时间口径与Agent截断提示 2026-09-11 15:25:45 +08:00
wangjianlong_0626 e4c4099aaa wip: 客服Agent + RAG + 画像收尾（基于 6516ccb） 2026-09-11 14:46:40 +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
lzf_0626 deeee9bb01 fix(risk): 补齐风控缺失的三个 RBAC 权限——写操作与扫描原本全是死的 
**发现**（由"给邮件端点加权限"这个任务引出来的）：风控 service 层声明了四个权限码，
而 sys_permission 表里只有一个。

| 权限码 | 用途 | 原先状态 |
|---|---|---|
| risk:alert:read  | 查询 / 研判 / 日报 / 通知 | 已存在，正常 |
| risk:alert:write | 处置 / 证据归档 | **不存在** → 6 处调用全被拒 |
| risk:alert:scan  | 规则扫描 | **不存在** → 扫描端点调不了 |
| risk:report:mail | 日报邮件 | **不存在**（本次新增） |

失效表现是 ForbiddenAgentError，而**只读查询一切正常** —— 所以很容易以为"风控能用"，
直到去点处置按钮才发现。这与 risk:alert:read 当初缺失是同一类问题，只是面更广。

**改动**：把早先那个只建一条权限的脚本改造成覆盖四个，并授权给 risk_operator 与 admin
（风控 Agent 的 allowed_roles 两个都声明了，只给其中一个会让另一个"声明了却用不了"）。
data_scope 取 all —— 风控要处理全部客户的预警，且多个 service 按
context.data_scope == "all" 决定是否放行全量。脚本更名为 grant_risk_permissions.py。

**实测**（9002 risk_operator）：
- POST /risk/alerts/scan → **200**「规则扫描完成」（原先必被拒）
- POST /risk/alerts/ALDEMO0002/acknowledgements → **409**「只有待处理预警可以确认接收」
  —— 不是 403，说明**权限已通过**、卡在业务状态（该预警是"调查中"），属正当拒绝
- 对照组：customer 调扫描 → **403 缺少操作权限**，边界未放松

顺带发现：这个 409 复用了错误码 RUN_NOT_CANCELLABLE，语义不符 —— 属 docs/25 里已记的一项。
 2026-09-11 13:37:30 +08:00
lzf_0626 8283f6ab69 feat(customer-service): 把闲聊提示词补回生效版本，并修掉发布脚本的两个坑 
**背景**：提示词配过（挂在 release 174），但 174 已被取代，而 load_active_prompt 是先定位
active 版本、再按 release_id 查的 —— 于是读不到，Agent 回落到代码默认值。功能看着正常
（_chitchat_prompt 有逐字段兜底），所以一直没人发现，也没有任何告警。

发布脚本原先有两个坑，这次一并修掉：

1. **version 写死为 1**。prompt_template_version 的唯一键是 (prompt_code, version)，
   客服那条已经占了 v1，照搬旧行会主键冲突。改为取现有最大值 +1（本次自动分到 v2）。
2. **继承只读 platform_config_item**。改用 ConfigReleaseService.effective_snapshot()，
   它覆盖全部三张受管表；并且做**字段名映射**（库的 config_key → API 的 item_key、
   value_json 归一化）—— 快照行是库的形状，直接 POST 会 422。

实测：
- 发布走路径二（路径一如预期被状态机拒：409 RUN_NOT_CANCELLABLE「只能修改草稿发布版本」）
- 新版本 201 继承 9 条配置项、一条没丢；提示词 v2 随之生效
- load_active_prompt 现在返回 release_id=201 / version=2（此前为 None）
- 闲聊链路：status=succeeded、intent=chitchat，回答「您好，我是南方科技智能客服，
  想了解基金、理财还是账户服务？」—— 简洁、自然引导到业务，符合提示词要求

提示词正文与代码默认值**刻意保持一致**：发布前后行为不变，变的只是"能不能改"
（改话术从此要经审核并留痕）。Agent 侧仍保留代码默认值作为兜底。

ruff / mypy(136 文件) / 612 unit+contract / 29 integration 全绿。
 2026-09-11 13:26:43 +08:00
Windows 281e76e4b1 feat: add advisor portfolio analysis 2026-09-11 13:20:09 +08:00
Windows 60c4a49b9b feat: migrate advisor investment goals 2026-09-11 13:11:58 +08:00
lzf_0626 cdbd85b27c test(platform): 端到端验证配置项丢失告警，并把它收成可复用的回归工具 
上一轮加了"激活时点名将被丢掉的配置项"之后，我只用 caplog 验证了方法本身，
**没有跑过真实激活**——这一步把缺口补上。

tools/verify_config_drop_warning.py 走完整的"创建 → 加配置项 → 提交复核 → 审核 → 激活"
状态机，发三个版本：

- A：把当前生效配置项原样复制  → 一条不少，无告警（不产生噪音）
- B：去掉 agent_tools/risk:general → 告警 1 条并**精确点名**该配置项
- C：把完整的那份再发一次      → 恢复原状，无告警

跑完校验生效配置项与起点一致，避免把环境留在"少一条"的状态。

实测结果：A 告警 0 条 / B 告警 1 条且点名 agent_tools/risk:general / C 告警 0 条；
起点与终点均为 9 条配置项，环境已复原。
 2026-09-11 13:05:33 +08:00
lzf_0626 554fbbcaab fix(identity): data_scope 不能写死 self——它让所有"看全量"的路径失效 
实测发现：9002(risk_operator) 与 9003(admin) 都持有 all 级权限
（permission_scopes 里 audit:read='all'、risk:alert:read='all' 等），
但 context.data_scope **永远是 'self'**——identity_repository.py 第 47 行把它写死了，
而上面第 34-39 行刚算出每个权限的 scope 并取了最高（rank 表都写好了）。

后果：凡按 context.data_scope == "all" 判断能否看全量的路径全部走不通
（risk_query_service.py:198、risk_analysis_service.py:126、
risk_evidence_archive_service.py:218、risk_action_service.py:212），
风控专员拿着全量权限却查不到任何预警——这是上一轮三个工具"都返回空"的真正原因。

改为取该身份所有权限里的最高范围。没有 all 权限的角色行为不变
（实测 9001 customer 的 data_scope 仍是 self），因此不放松任何既有边界。

另加 tools/seed_risk_alert_demo_data.py：造 3 条演示预警覆盖三个只读工具的读路径
（高危待处理 / 中危调查中 / 低危已闭环），字段取值照 risk_scan_service.py:312-333 的
_build_alert 抄、状态用 OPEN_STATUSES，时间按库内约定存 UTC。注意该表 id 非自增，
所以脚本手工生成 id。

实测（9002 身份）：
- 查看当前风险概览 → 未闭环 2 条、高危 2 条、待处理 1 条，含高优先级清单与证据摘要
- 查询高风险预警   → 2 条明细，命中 RW-002/003/007/012/015，附只读复核草案
- 查询 ALDEMO0001 的证据 → 完整快照事实 + 客户维度，并主动指出证据缺口
客服回归：9001 身份行为不变。
 2026-09-11 12:54:51 +08:00
Windows 291cb7b58f feat: add advisor product evidence intake 2026-09-11 12:47:01 +08:00
lzf_0626 39c7ab51f4 feat(risk): 发布风控配置并补齐缺失的 RBAC 权限 
修 docs/25 里的 P0：风控的意图配置与工具白名单一条都没发布，而白名单是失败关闭的，
导致任何工具调用都被拒。按组员交付的《20-Agent工具白名单与意图配置》补齐。

1. tools/publish_risk_agent_config.py：导入 4 条 risk 意图配置（id=61-64，active）与
   4 条 agent_tools 白名单（risk_overview / risk_search / risk_evidence / general）。
   发布版本 id=188 active，并且**继承了现有 5 条配置项**——config_release 是整版本替换
   语义，不继承会把客服的 4 条白名单和示例 Agent 的 fund_query_demo:fund_quote 静默清空。

2. tools/grant_risk_alert_read_permission.py：补齐 risk:alert:read 权限。
   实测发现这条权限在 sys_permission 里**根本不存在**，连 risk_operator 角色也没有，
   所以任何身份调用风控工具都会拿到"缺少工具权限"。交付文档第 116 行正把这一项列为
   接入前置条件。权限匹配实际用 permission_code 全串（identity_repository.py:25-37），
   resource/action 只是元数据（照 fund:quote:read 的拆法）；data_scope 取 all，因为
   risk_query_service.py:194、risk_analysis_service.py:126 等按 context.data_scope == "all"
   决定是否放行全量数据。只授权 risk_operator，不动 admin（交付文档只要求前者）。

验证（以 9002 risk_operator 身份实测）：
- "查看当前风险概览" → status=succeeded、意图 risk_overview、工具真实返回数据
- "查询高风险预警"   → status=succeeded、意图 risk_search
修复前两者均为 failed + ForbiddenAgentError: 缺少工具权限。
 2026-09-11 12:18:34 +08:00
Windows 9ed536e206 feat: migrate advisor database schema to qyqy base 2026-09-11 12:16:06 +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
lzf_0626 33fbb0eb01 feat(customer-service): 接入适当性裁决，回答"我这个等级能不能买它" 
客户实测反馈：「c1客户能买它吗」答的是 C1 的通用规则，没回答"能不能买季季盈90天"。
根因是这个问题需要**组合两个事实**——产品的风险等级（R2）与客户档案等级能不能匹配——
而检索只能给出"最像的那段原文"，给不出结论。基座早就有了 check_suitability 裁决工具，
接口留好了但客服没接线（这个项目里第三次遇到同一类情况）。

改动三处：
1. 新增 suitability_check 意图，意图码三处对齐（AgentDefinition.supported_intents、
   agent_intent_config 的 active 行、发布版 agent_tools 白名单）。
2. 新出口 _answer_suitability：产品风险等级**从知识库查出来**（不猜、也不采信问句里
   出现的"R2"字样），产品名只取上一轮回答里的主语（来自知识块字段，可信），客户等级
   交给 check_suitability 按档案解析——**不采信客户自称**。任何一步拿不到确定值就转人工：
   这个出口会给出"能不能买"的结论，宁可答不了也不能答错。
3. 发布脚本加意图注册与工具白名单，并做成幂等（重跑不会因为"已经审过了"而 409）。

实测：意图正确路由到新出口，裁决链路走通。9001 因为在 fin_risk_assessment 里没有测评
记录，系统给出"暂时无法购买 + 您目前没有在有效期内的风险测评结果"——这正是适当性管理
要求的行为，不是故障：不能卖给一个没有有效测评结果的客户。措辞也据此改过，不写
"您的等级为未记录"这种客户看不懂的句子。

顺带修了前端一处误导标记：它用"是否含客服热线"判断"已引导人工"，而正常的适当性回答
里也会建议拨打客服热线，于是"已经给出结论"被误报成"已引导人工"。
 2026-09-10 22:42:17 +08:00
lzf_0626 7b3a72860c feat(knowledge): 为 C1-C5 各补一条「能买什么产品」的问答 
客户实测反馈：「C1 客户能买什么」被引导到人工客服，而知识库里其实有答案。
实测分数：这条问句 top1 只有 0.5633、与次优差 0.0236（低于 0.07 门槛）→ 转人工；
而「C1 保守型客户可以买哪些风险等级的产品」是 0.7794，过了 0.75 硬门槛、能答。
根因是客户与知识库的用词鸿沟：客户说「C1 客户」，知识块标题写的是「C1 保守型」。
短问法少了"保守型"这个锚点就差 0.19 分——而客户不知道 C1 就等于保守型，这正是他要问的。

按 A 方案（数据问题用数据解决）为 C1-C5 各补一条 FAQ，答案全部取自
《个人投资者适当性管理指南》原文，不自行编写：
- 第十二条投资者与产品匹配矩阵（各级别可购买的产品风险等级）
- 第十四条硬匹配规则的跨级禁止要求
- 第十五条豁免规则（C3 买 R4、C4 买 R5 的签署揭示书与持仓上限）

知识块 631 → 636。同时修正 load 脚本自检里过时的期望：这句话现在命中 FAQ 而非
POL-AST（两者是同一份内容，只是 FAQ 的问句措辞更接近客户口语）。

验证：C1-C5 六个等级的「能买什么」问法全部直接回答、无一转人工；
ruff / mypy / 468 unit+contract 全绿。
 2026-09-10 22:34:20 +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 07a922fa36 feat(tools): 新增本地客服控制台（可聊天的调试前端） 
为什么做成独立进程而不是给底座加接口：底座目前没有登录接口（按计划推迟）。
任何让浏览器直接拿到令牌的做法——无论是一个 dev token 端点还是把私钥下发前端——
都等于把"任意身份"开放给任何能访问服务的人。控制台把令牌签发与调用全部留在
服务端进程内（私钥不出进程），底座代码零改动、也没有新增任何后门路由。

- GET /：返回聊天页；POST /api/chat：受理 agent-run 并驱动本进程执行
- 页面展示识别出的意图与是否引导人工，便于观察路由结果
- 同一 session_id 连续对话，用于验证短期记忆（多轮指代）生效
 2026-09-10 22:06:43 +08:00
lzf_0626 89f889b350 feat: 图投影对账（数据层）并补运维工具，第 2 步收尾 
与既有 `ProjectionReconciliationService` 的分工（两者互补，不是重复实现）：
· 那个服务做**事件层**对账：哪些投影事件还没投递、需要重放；
· 本次新增的是**数据层**对账：投递完成之后，图里的内容与权威画像是否一致
  （投影漏投、记忆失效后未清理、图库故障都会造成漂移）。

实现 `ProfileGraphProjectionService.reconcile_customer`：
· 从 user_facts 与持仓算出"应有的边"，从图中读出"实际的边"，求差集得到 missing
  （画像有、图里没有）与 orphaned（图里有、画像已无）；
· 图是投影、MySQL 是唯一真相，因此差异一律**以画像为准**：missing 补写、orphaned 删除，
  而不是反过来去改画像；
· `repair=True` 时修复，并**修复后重新核对**再回报——不凭"操作没报错"就宣布修好了；
· 删除边前对关系名做白名单校验：关系名读自图中既有边，属外部数据，
  必须过白名单才允许拼进 Cypher。

新增 tools/reconcile_graph.py：支持单客户与 `--all`、可选 `--repair`，退出码可直接用于巡检。

顺带修掉一处日志噪音：读边时原用 `coalesce(t.tag_key, t.product_code, ...)`，会引用当前
图中尚不存在的属性名，Neo4j 每次执行都抛 UnknownPropertyKeyWarning，把日志刷成噪音。
改用 `properties(t)` 后在应用侧按键取值，功能不变、日志干净。

实测（人为制造漂移再修复）：
· 初始对账 一致=True、应有 2 条 / 实际 2 条；
· 删掉图中的 HAS_GOAL 边后 一致=False，缺失被准确报出；
· repair=True → 已修复=True、一致=True、缺失为空；
· 复验 一致=True，图中恢复 HAS_GOAL 与 PREFERS 两条关系；
· tools/reconcile_graph.py 单客户与 --all 均 EXIT=0，输出无警告；
· ruff 通过、mypy 112 文件无错。
 2026-09-10 21:55:03 +08:00