AI260626/group_fqcd_jr
13
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
267 Commits 12 Branches 0 Tags
NL_develop
Commit Graph
114 Commits
Author SHA1 Message Date
wangjianlong_0626 1f62aca6f7 fix(seed): 当日行情重跑必须刷新 source_updated_at（修 503 FUND_QUOTE_UNAVAILABLE） 
真机实测到的缺陷：`tools/seed_sim_account_demo.py` 的 `_upsert_market_price()`
在"当天已有行"时直接 `return`，于是同一天重跑种子**不刷新 `source_updated_at`**。
行情是时效数据，过期后 `FundQuoteService` 返回
`503 FUND_QUOTE_UNAVAILABLE：产品 510300 行情已过期`，
连带 `T001` 仪表盘与 `T006` 持仓一起不可用（`T010` 权益不查行情，仍 200）。

表现极具误导性：**刚灌完种子能用，过十几分钟就 503** ——
看起来像行情适配器或缓存故障，实际根因在种子脚本。归因过程：
`memory_sync` / Redis / Milvus 全部正常，`fin_market_price` 里当天那行
`source_updated_at` 停在首次灌入时刻。

修法：把列值抽成共享 `values` 字典，当天已有行时 `update` 刷新全部行情列
（含 `source_updated_at`），不存在才 `insert`。
**幂等的正确含义是"不产生重复行"（`(product_id, trade_date)` 唯一），
不是"不更新值"。** 账户/持仓的"已存在则跳过"保持不变 ——
那是业务数据，不该被种子覆盖。

验证（本机，测试客户 9001 `cust_t`）：
- `python -X utf8 -m tools.seed_sim_account_demo --customer-id 9001` 正常
- `GET /api/v1/users/me/account/dashboard` → 200（修前 503）
- `GET /api/v1/users/me/holdings` → 200
- `GET /api/v1/users/me/entitlements` → 200

门禁：ruff `app tests tools alembic` 全过；`mypy app` 0 错（252 文件）；
`audit_schema.py` 90 张业务表无差异；文档编号/端点编号/RBAC 种子一致性全过。
 2026-09-12 17:32:24 +08:00
wangjianlong_0626 4766e3bd98 feat(benefit): 客户权益功能（T010）+ 修投顾迁移契约里写死 head 的脆弱断言 
## 1. 新增客户权益（用户端）

`GET /api/v1/users/me/entitlements`（T010，权限 `benefit:read:self`）：

- **层级**由 `fin_customer_profile.total_asset` **实时判定**
  （门槛来自 `knowledge/product/高净值客户服务规范.md`：
  金卡 50 万 / 白金 200 万 / 钻石 600 万 / 私行 1000 万；低于 50 万为普通客户）；
- **权益按层级累积展开**（文档原文"含全部下级权益，新增以下"）：
  金卡 9 条 / 白金 20 / 钻石 33 / 私行 54，各档已逐档实测；
- 返回**升级提示**（`next_tier`：下一层级与门槛），前端可直接渲染"再投 X 元升级"。

### 新增表 `fin_customer_benefit`（1 张）

层级 → 权益目录，54 条种子数据（`tools/seed_customer_benefits.py`，按 `benefit_code` 幂等）。

**基线合规证明**（规则 1/3/4）：只新增这一张表；**未**重命名/删除任何已有表；
**未**重命名/删除/复用任何已有字段，**未**改任何已有字段的类型、可空性或业务含义；
未改 `docs/00`。
复核：`tools/audit_schema.py` → `90 business tables, no missing or unexpected tables`。

### 两条设计取舍

1. **不落"某客户享有哪些权益"**：层级可算，权益由层级推出，两者都不落库。
   与 `docs/00` L159（不保留 `net_worth_flag`，因为可算）同一取向。
2. **权益只存各层新增条目**，累积由服务层 `tier_chain()` 展开 ——
   否则改一条权益要改四处，漏一处就出现"白金没有金卡权益"。

### 数据来源与一处刻意省略

逐条照抄知识文档，不新增文档里没有的权益。**私行那条
「7×24小时私人银行专线：400-XXX-XXXX 转 8」不写号码** ——
文档里是占位符，而对客号码的唯一来源是 `customer_service_rules.CONTACT_PHONE`
（本线此前修过"同一客服给客户两个不同号码"的缺陷）。把占位符抄进库等于再造一份假号码。

## 2. 修投顾迁移契约里写死的断言

`tests/unit/test_advisor_migration_contract.py` 原先断言

```python
assert script.get_heads()[0] == "20260911_merge_adv_risk_heads"
```

那是"投顾迁移刚加完那一刻"的快照 —— 本 PR 一新增迁移（`20260912_customer_benefit`）
它就变红，**而红的原因与投顾链的对错无关**：断言测到的是时间，不是契约。

原意是"投顾链接在这条主链上、没另起分支"。改为断言**投顾链尾是当前 head 的祖先**
（链尾从 `ADVISOR_FILES[-1]` 派生，不写死），既保住原意又不受后续迁移影响。
`len(script.get_heads()) == 1`（链不分叉）与"投顾文件首尾相接"两条原样保留。

## 3. 顺带发现的既有缺口（**不在本次改动范围**）

`app/api/controllers/trading.py` 的 **T001–T009 未调用 `AuthorizationService.require`**：
`docs/05` §19 为它们登记了权限码（`account:read:self` / `trade:order:*` / `holding:read:self`），
但代码只做认证 + 开户测评门槛，**没有执行 RBAC 权限检查**。
对照：仓库里 **26 个 service** 都调了 `require`，`trade_service` 不在其中。

本线的 T010 **按正确做法实现**：`CustomerBenefitService.entitlements_for` 先鉴权再读数据，
且**鉴权在读取客户资产之前**（有测试断言"拒绝时未查库"）。
T001–T009 如何补，需架构师定口径后另行处理。

## 4. 文档

- 新增 `docs/41-客户权益功能说明.md`：表登记 + 基线合规证明 + 分层口径 + 累积规则 +
  数据来源 + 权限 + 与仪表盘的关系 + 上述缺口
- `docs/05` §19 登记 T010，并**单独注明它引入了新表**（避免被误读为
  "T 段数据库零变更"的一部分）
- `AGENTS.md` 表数 89 → **90** 张业务表

## 验证

- `pytest tests/unit/service/test_customer_benefit_service.py` → **20 passed**
  （含边界：499999.99 不是金卡、500000 整是金卡、1000 万整是私行；累积条数；升级提示；
  鉴权先于读数据）
- 全量 `pytest tests` → `2 failed, 1469 passed, 1 skipped`
  （2 个失败为既有环境项：httpx 把中文序列化成 `\uXXXX`，非本次引入）
- `ruff check app tests tools alembic` → `All checks passed`
- `mypy app` → **0 错 / 252 文件**
- 真机：`GET /users/me/entitlements` → `200`；各档分层与累积条数逐档实测通过
- `audit_schema.py` → 90 张业务表无缺失/意外；文档守卫 55 份无编号冲突；
  端点编号无重复；RBAC 种子一致性通过
 2026-09-12 17:24:37 +08:00
wangjianlong_0626 37926e1c88 Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-colleague 2026-09-12 16:39:39 +08:00
lzf_0626 6155f4589e feat(portal): 按风控前端合并约束重写风控工作台 
- 概览五指标（总量/等级/待处理/超时/重点预警）
- 预警队列：每页 5 条、风险等级优先、8 项筛选、游标分页、稳定行高与省略号
- 预警详情弹窗：23 个 alert 字段 + 客户信息 + 五个处置动作
- 处置：确认接收（二次确认）/进入调查/关闭误报（必填理由）/结案（必填结论）/升级（必填原因）
- 八类证据（customers/products/transactions/capital_flows/holdings/login_records/
  alerts/notifications）+ 五项筛选；注意是 holdings 不是 positions
- 通知记录、日报 SSE 流式生成 + 内容编辑 + 多邮箱发送
- 新增 Toast + 模态框，替换全部 17 处原生 alert（17- 文档明令禁止原生弹窗）
- 风险等级筛选值改用 高/中/低（预警对象用「高」，概览 levels 用「高风险」，口径不一致）
 2026-09-12 16:30:54 +08:00
lzf_0626 6e916aab03 Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop 2026-09-12 16:08:39 +08:00
lzf_0626 76923d7e8b fix(portal): 补齐写操作的必填 body（风控升级/解决、场外六个写接口） 
- 风控：escalations 要 reason、resolutions 要 resolution（字段名不同），
  且真实顺序是 先确认接收 才能升级/解决（否则 409 请先确认接收预警）
- 场外：六个写接口都必填 operator_id（防伪校验，须等于当前登录用户），
  confirmations 还要 decision(中文枚举)、notifications 还要 notification_type、
  recalculate 要 fund_code+application_date；门户自动带当前 user_id
- 实测：recalculate 200 code=0；不传 operator_id 必得 422（证明该字段必须）
- 清单 §3/§4 更新为实测结果并列出各写接口的必填字段表
 2026-09-12 16:08:38 +08:00
ZSY_merge e25296f30a merge: integrate origin/qyqy_develop (552055ee) 2026-09-12 16:05:24 +08:00
lzf_0626 552055ee2d fix(portal): 修风控预警列表 422（limit 上限是 5，改为不传）；运营邮件改用 page/page_size；审计 limit 钳制到 1-100 
- risk/alerts 传 limit=20 会 422 query.limit<=5，导致整张表格渲染不出来、
  行内确认/升级/解决按钮随之消失 —— 这正是验收清单 3-3/3-6~3-9 看不到功能的原因
- 实测列表返回 2 条预警；处置接口有状态前置条件（409 = 当前状态不允许）
- 清单 3-3/3-6 更新为实测结果并写明 limit 上限与状态机约束
 2026-09-12 16:03:22 +08:00
ZSY_merge_bot 4c651ccce1 merge: integrate latest origin/qyqy_develop (frontend acceptance checklist + portal flow wizard) 2026-09-12 15:58:08 +08:00
张胜宇 ebc3fe4cbe feat(§T): 账户看板 + 场内模拟交易 9 端点（用户自助首版） 
新增 §T 用户自助段（docs/05 §19 新号段 7 个 = A×40/C×7/K×4/M×4/O×3/R×4/T×9）：

- T001 GET /api/v1/users/me/account/dashboard  — 账户/资金/持仓/盈亏汇总

- T002 POST /api/v1/users/me/orders  — 委托提交（首版 market 立即全额成交）

- T003 / T004 / T005  委托列表/详情/撤单

- T006 GET /api/v1/users/me/holdings  — 持仓列表（含市值/盈亏/当日盈亏）

- T007 / T008  成交记录列表/详情

- T009 GET /api/v1/users/me/cash-ledger  — 资金账本

要点（与 docs/00 §6.6 一致）：

- 首版市价委托立即全额成交，不实现撮合队列/部分成交；T005 撤单首版对任何在场委托返回 ORDER_NOT_CANCELLABLE (409)

- 价格来源复用 base FundQuoteService；service 层不二次封装（满足 AGENTS 第 2 条）

- 首版风控 3 条硬性：产品可交易、客户适当性、持仓比例上限（fin_market_price 缺失或过期 → 拒绝买入）

- 数据库零修改：10 张 fin_* 表全部 docs/00 既定，本批 PR 改列类型与可空性均 0；底座实际偏差（id 无 AUTO_INCREMENT、所谓'生成列'是普通 NOT NULL）由 service _next_id / 业务派生值补偿

注册 API：9 端点均注册进 app.main；user=9001(cust)'s id 写账

权限码（tools/seed_test_rbac.py 同步登记 + CUSTOMER 全量）：

  9047 account:read:self

  9048 trade:order:create

  9049 trade:order:read

  9050 trade:order:cancel

  9051 holding:read:self

  9052 trade:txn:read

错误码（app/core/errors.py + docs/05 §3.6 + tests/unit/core/test_errors.py DOCUMENTED 三方同步）：

  404 ACCOUNT_NOT_FOUND / ORDER_NOT_FOUND

  409 ORDER_NOT_CANCELLABLE

  422 INSUFFICIENT_FUNDS / INSUFFICIENT_HOLDING / HOLDING_RATIO_EXCEEDED / SUITABILITY_MISMATCH / PRODUCT_NOT_TRADABLE

  503 FUND_QUOTE_UNAVAILABLE（可重试）

新增：app/api/controllers/trading.py / app/api/schemas/trading.py / app/service/trade_service.py / tools/seed_sim_account_demo.py / tests/unit/service/test_trade_service.py(unit×8) / tests/contract/test_trading_endpoint_contract.py(contract×11)

修改：app/main.py(挂载 controller) / app/core/errors.py(10 新异常类) / tools/seed_test_rbac.py / docs/05-接口文档.md(§19 T001-T009 + §3.6 9 新码) / tests/unit/core/test_errors.py(DOCUMENTED 同步)

门禁：pytest tests/unit tests/contract 1313 passed (+19 新增) / ruff all clean / 三道守卫全过
 2026-09-12 15:50:37 +08:00
lzf_0626 2525fbdad9 feat(portal): 推广材料补成完整流程向导，并改为按 body.code 判成败 
- 投顾视图：创建 -> 补结构化输入(含七项费率) -> 生成 -> 投递 -> 查询
  生成后自动把 material_version_id 填进投递框
- 管理员视图：新增推广材料审核（promotion:review 只给管理员，职责分离）
- 统一结果渲染改看 body.code：本平台业务失败也返回 HTTP 200
  （生成失败是 HTTP 200 + code=422 + '材料内容未通过合规校验'）
- 输入骨架刻意不预填业绩（performance_info 有 show_* 开关可关），
  费率填占位文本以便跑通流程；真实材料必须换成真实值
 2026-09-12 15:45:09 +08:00
lzf_0626 615032ab00 fix: 修 POST /api/v1/conversations 的 MissingGreenlet（会话建不出来导致转人工 404） 
- public_platform_service: 创建 ConversationSession 时显式赋值四个 server_default 时间列，
  否则 flush() 后需回读数据库生成值，在 async session 里以同步属性访问触发
  MissingGreenlet，接口 500，连带转人工一直报会话不存在
- portal: 客服改用 C001 真实建会话；转人工改传 reason_code/reason_detail（原 reason 属额外字段 422）
- portal: 投顾查客户投资目标走 customers/{id} 变体
- seed/grant: 补 investment-goal:{read,write,confirm}:customer 三个动态拼出的权限码
  （data_scope=own_customers，投顾只看名下客户）
 2026-09-12 15:37:36 +08:00
lzf_0626 bfd622b592 feat: 统一登录门户（按角色分流五套工作台）+ 补齐权限覆盖缺口 
- tools/portal.py：客户/风控/运营/管理员/投顾五个工作台，走真实登录与真实接口
- 新增 6 个此前从未建过的权限码（promotion:* 4 个 / financial:nl2sql:read / probe:read），
  它们让推广材料与金融 NL2SQL 两条线对所有角色都是 403
- 投顾权限 10 → 25 项：补投资目标创建确认、agent:run、行情、知识检索、客户画像、推广材料
- 运营补 financial:nl2sql:read；create_test_user.py 不再硬编码角色 id（改按 role_code 查库）
- portal 的写请求补 Idempotency-Key 头（漏了会被 AGENT_INPUT_INVALID 拒）
- 新增 tools/check_permission_coverage.py 做权限对账
 2026-09-12 15:21:34 +08:00
lzf_0626 c8d5fe11dc feat: 新增平台功能测试台（自动覆盖 docs/05 §19 全部端点 + 一键只读冒烟 + 按身份测权限） 2026-09-12 14:57:17 +08:00
wangjianlong_0626 aa3f9f9b3d Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-colleague 2026-09-12 14:48:45 +08:00
zhangshy 5634fdc023 完善风控登录权限和模型能力配置 2026-09-12 14:43:05 +08:00
Windows 026fec7514 Merge remote-tracking branch 'origin/qyqy_develop' into lzl_qyqy_integration 2026-09-12 14:41:13 +08:00
Windows 9c6f839a6e feat: add advisor demo environment bootstrap 2026-09-12 14:40:53 +08:00
wangjianlong_0626 8cb75992e6 Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-colleague 2026-09-12 14:21:34 +08:00
wangjianlong_0626 451aa4e915 fix(profile): ProfileAssemblyService 漏写 current_customer_id（唯一键失效的另一处） 
## 现象（2026-09-12 端到端跑通后查数据时发现）

客户 9102 的画像快照状态**彼此矛盾**：

| version | is_current | current_customer_id |
|---|---|---|
| 2 | `0` | `9102` ← 清旧时没清空 |
| 3 | `1` | `NULL` ← 建新时没写入 |

## 根因

`ProfileAssemblyService._write_snapshot` 把 `current_customer_id` **当成了生成列**：

- 方法 docstring 原文写着"唯一键 `uk_profile_snapshot_current` 建立在**生成列** `current_customer_id` 上"
- 因此两处都不赋值（以为 DB 会自动填）

**但该列不是生成列** —— `alembic/baseline_generated.sql` 与真实库都是**普通可空列 + 唯一键**，
`app/model/profile.py` 的模块 docstring 第 2 条已明确："当前版本必须由写入方**显式写入**客户 ID
（历史版本写 NULL），才能保证「每个客户最多一条当前快照」"。

后果：唯一键**形同虚设**（多个 NULL 不冲突）⇒ 不变式失效；且旧版本残留的值
一旦与新版本补上的值相同，就会**直接撞唯一键**。

> 这与本线先前修的 `CustomerProfileCandidateService._write_profile_snapshot` 是**同一个缺陷的另一处**
> —— 当时只找到一处，这次是靠真实链路跑出数据后核对才暴露出来。

## 改动

`app/service/profile_assembly_service.py`：

- 旧版本：`is_current = False` 的同时 `current_customer_id = None`
- 新版本：`is_current=True` 的同时 `current_customer_id=customer_id`
- 订正方法 docstring 的错误认知（"生成列"→ 普通可空列 + 唯一键），并写明后果

## 已有数据订正

新增 `tools/fix_profile_snapshot_current.py`（**默认 dry-run**、幂等、`--apply` 才提交）：

1. 先清空 `is_current=0` 却残留值的行
2. 再补写 `is_current=1` 却是 NULL 的行
3. **顺序要紧**：反过来的话第 2 步会与残留值撞唯一键

本机实测：清空 1 行、补写 1 行，复核两类异常均归零。

## 验证

- `mypy app` → 0 错 / 245 文件
- `pytest tests`（全量）→ `2 failed, 1418 passed, 1 skipped`
  （2 个失败为既有环境项：httpx 把中文序列化成 `\uXXXX`，非本次引入）
- 端到端：真实对话 → 记忆抽取 → `memory_unit` 落库已实测通过（客户 9102
  `preference:risk_level = "低风险"`，候选态）
 2026-09-12 14:20:38 +08:00
lzf_0626 c8cdc06e80 Merge remote-tracking branch 'origin/qyqy_develop' into qyqy_develop 2026-09-12 14:18:06 +08:00
lzf_0626 ffbcc229c2 fix: 删掉 NL 合并后残留的未使用变量 role_ids（ruff F841） 2026-09-12 14:17:42 +08:00
Windows 050eedac68 Merge remote-tracking branch 'origin/qyqy_develop' into lzl_qyqy_integration 2026-09-12 14:16:27 +08:00
Windows 54fadb3a99 Merge branch 'qyqy_develop' of http://47.106.207.27:3000/AI260626/group_fqcd_jr into lzl_qyqy_integration 
# Please enter a commit message to explain why this merge is necessary,
# especially if it merges an updated upstream into a topic branch.
#
# Lines starting with '#' will be ignored, and an empty message aborts
# the commit.
 2026-09-12 14:15:43 +08:00
wangjianlong_0626 f7b35006ff Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-colleague 2026-09-12 14:06:18 +08:00
yuancong_0626 fedbf5a3ef merge: sync latest origin/qyqy_develop before push 2026-09-12 13:16:57 +08:00
wangjianlong_0626 cbca2cccbb Merge remote-tracking branch 'origin/qyqy_develop' into nl-merge-colleague 2026-09-12 13:15:33 +08:00
wangjianlong_0626 57677f6554 merge: 合并主干 qyqy_develop（PR #7 之后）并对齐两套投影实现 
共同祖先 bbf623a；主干 54 个提交、118 个文件；本线 25 个文件；9 个冲突文件。
主干这次把 **ZSY 的整条投影实现合进来了（PR #7）**，而本线此前的提交正是
移植并修正同一套代码 —— 因此冲突的本质是"同一功能两份实现并存"，取舍错了会把
已修好的缺陷又带回来。逐项取舍与理由见 `docs/39-主干合并对策记录.md`。

## 取舍（9 个冲突）

取本线：
- `app/infrastructure/milvus_profile_projection.py` —— 主干是 ZSY 原版，含两处必炸点：
  ① `customer_id` 要求 int 而本仓所有生产者都写 `str` ⇒ 每个事件必然失败；
  ② 不可投影的 `memory_key` 直接 raise ⇒ 一条 `constraint:` 记忆毒死整客户整批。
  本线版已放宽为「接受纯数字字符串」与「跳过并留痕」。
- `memory_sync_outbox_worker.py` / `conversation_privacy.py` / `risk_questionnaire.py`
  —— 代码逐行一致，仅注释与说明文字详略不同（`risk_questionnaire.py` 两边**独立做了
  完全相同的修复**，都改成 re-export `app.model.profile`）。
- 两个投影测试文件 —— 本线是他那份的**超集**（4→10、4→5 例，包含他全部用例）。

两边合并：
- `app/worker/runtime.py`：`__init__` 两边各加一个参数，都要。
- `app/service/agent/implementations/customer_service.py`：import 取并集；
  `COMPANY` 取主干的「奶龙基金责任有限公司」（"奶龙"是本项目实际品牌名，主干多处出现），
  `HOTLINE`/`SERVICE_HOURS` **取本线的修复**（主干仍是占位符 `400-XXX-XXXX`，
  本线已改为引用 `customer_service_rules` 的唯一来源 —— 这是 A1 缺陷修复，
  否则同一客服给客户两个不同号码）。
- `AGENTS.md`：表数/Agent 清单取主干（90/89、7 个 Agent），本线的
  `-X utf8` 与两条 outbox 易错点保留，测试基线按合并后实测重算。

## 消费端只保留一套（本次最重要的一处）

合并后曾出现**两套消费者读同一个 `memory_sync_outbox`**：`__main__.py`（PR #7）
与 `runtime.consume_profile_projections()`（本线），而**两者的 neo4j handler 不同**
—— 前者用 ZSY 的 `Neo4jProfileProjection`（按客户各建私有节点），
后者用主干 `ProfileGraphProjectionService`（共享 tag 节点、只投影已确认事实）。
同一事件被谁领到结果不定，等于"同一事实在图里有两种说法"，正是**方案 A 要避免的状态**。

现只保留 runtime 那一套（带 `memory_sources` 兜底、neo4j 复用主干服务），
删除 `__main__.py` 的重复接线；装配入口职责仍在该文件（注入 `relationships` /
`projection_cleaner`），Milvus 客户端由 `bootstrap` 工厂惰性构造、缺配置时显式降级。

副作用：`app/infrastructure/neo4j_profile_projection.py` 不再被生产代码引用，成为
**死代码**（本线未删，属架构师线，其单测仍在）—— 待架构师决定删或明确分工。

## 顺带修掉的 3 个继承缺陷（主干同样存在，PR #7 后未整套复跑故未发现）

1. `tools/seed_test_rbac.py` **少建 `review_t`（9004）账号** —— 两个集成测试都依赖它
   （"账号存在但无权限应返回 200 空集而非 404"、`PLACEHOLDER_ACCOUNTS`）。
   同时把用户↔角色绑定从 `zip(..., strict=True)` 改为**显式配对表**：原写法隐含
   "USERS 与 ROLES 一一对应"，一加不绑角色的账号就 ValueError、整个种子跑不完
   （commit 在最后，外部表现是"什么都没发生"）。
2. `CustomerProfileCandidateService._write_profile_snapshot` **漏写 `current_customer_id`**
   —— 该列不是生成列而是普通可空列 + 唯一键 `uk_profile_snapshot_current`，
   不写则唯一键形同虚设（多个 NULL 不冲突），且旧当前版本也没清该列、补写就会撞键。
   现旧值置 None、新值显式写入（与 `ProfileGenerationService._clear_current` 一致）。
3. 集成测试前置未记录 —— 13 个登录/RBAC 用例因 401 而红，实为"测试账号不存在"，
   跑 `seed_test_rbac.py` + `set_user_password.py` 后转绿；已在 `AGENTS.md` 记明，
   避免被误判成代码缺陷。

## 文档

- 新增 `docs/39-主干合并对策记录.md`（逐文件取舍 + 理由 + 遗留）
- `docs/37` 订正一处过时说法：曾写 `current_customer_id` 无人使用且故意不映射，
  实际 `app/model/profile.py` 已映射且有人使用（详见该文档 §6.2 的订正块）
- 文档编号：主干已占 29–36，本线两份文档让号至 `docs/37`、`docs/38`

## 验证（合并后实测）

- `pytest tests`（全量）→ `2 failed, 1396 passed, 2 skipped`
- `pytest tests/integration` → `102 passed, 1 skipped`（修上述 1、2 后从 15 failed 归零）
- `mypy app` → `Success: no issues found in 245 source files`
- `tools/audit_schema.py` → 89 张业务表无缺失/意外（未改动任何表结构）
- `tools/check_authoritative_docs.py` → 52 份文档无编号冲突
- `tools/check_rbac_seed_consistency.py` → 通过

那 2 个失败是既有环境项（`test_offsite_document_recognition_adapter.py` 断言请求体
中文原文而 httpx 序列化成 `\uXXXX`），与本次合并无关。
 2026-09-12 13:14:57 +08:00
yuancong_0626 a0a489a055 chore: preserve RBAC seed consistency checks 2026-09-12 13:03:16 +08:00
张胜宇 c5adf01603 test: 补端点编号守卫与权限判定的 HTTP 层用例 
补两道守卫，覆盖 2026-09-12 那次合并评审暴露出来的两个盲区。

一、`docs/05` §19 端点编号唯一性（新增 `tools/check_docs_endpoint_ids.py`）
- 背景：`tools/check_authoritative_docs.py` 只校验 `docs/` 的**文件名编号**，不校验
  §19 的**端点编号**。两条线各自新增端点时都占了 `A034`/`A035`，合并后 §19 同时
  存在两个 `A034` 与两个 `A035`，而文档守卫照样通过 —— 编号复用会静默遗留。
- 口径要点：**不枚举前缀白名单**，前缀从数据里归纳后连同数量一起输出。同一件事上
  还踩过一次"扫描正则写成 `[AMKCS]`，漏掉 `O`/`R` 两段，把 62 个端点报成 55 个"——
  漏掉的号段一旦被复用，脚本仍会报"重复 0"。所以覆盖报告会打印
   `62 个端点编号 / 6 个号段（A×40、C×7、K×4、M×4、O×3、R×4）`，让漏扫本身可见。
- 只读、不依赖任何环境变量（纯解析文档），可在裸检出环境直接跑。

二、端点权限判定的 HTTP 层用例（新增 `tests/unit/api/test_permission_enforcement.py`）
- 背景：既有用例都通过 `build_request_context` 覆写注入**已经带好权限**的上下文，
  只覆盖"有权限能通"，覆盖不到"缺权限必须被拒"。而"权限码在库里根本不存在"这类
  环境数据问题（本次三个新权限码）恰恰只会在这一层暴露：权限判定发生在身份解析之后，
  服务层测试自己构造 `RequestContext`，权限字段由测试塞入，所以全绿也照样漏。
- 覆盖客服二期三个权限码对应的 5 个端点：
  `handover:read`（工单列表/详情）、`memory:candidate:review`（候选列表/审核）、
  `memory:candidate:confirm`（用户确认）。
- 正反双向断言：缺权限 → 必须 403 且错误码为 `AGENT_PERMISSION_DENIED`；
  带权限 → **不能**再是 403（这一条把端点要求的权限码钉住，改动即红）。
- 只替换两处边界：`build_request_context`（跳过 JWT 与身份库）与
  `AuthorizationService` 的审计落库（内存替身）；真实路由、真实权限判定与真实 403 信封。
- 已做反向验证：给一个不存在的权限码时，5 个端点全部被拒（403），确认正向断言非空过。

验证（隔离 worktree，基线 `origin/qyqy_develop` = 4d8edb4）：
pytest tests/unit tests/contract -> 1294 passed, 2 skipped, 0 failed；
ruff check app tests tools alembic 全通过；mypy app 244 源文件 0 错；
check_authoritative_docs（50 份文档无撞号）与本脚本均通过。
 2026-09-12 12:57:16 +08:00
yuancong_0626 a501060e50 merge: merge yc into qyqy_develop 2026-09-12 12:50:14 +08:00
lzf_0626 4d8edb4b7f chore: 号段一致性自检固化为 tools 脚本并纳入门禁；AGENTS.md 更新主分支口径、Agent/工具清单与测试基线 2026-09-12 12:29:20 +08:00
lzf_0626 4cc0ecdea9 fix: 种子改用 UPSERT 建用户且不覆盖密码，解除投顾 FK 导致的跑不通；记录 RBAC 对齐最终状态 2026-09-12 12:22:32 +08:00
yuancong_0626 91f5373cfb 袁聪的第三次提交，API接口完善 2026-09-12 12:20:01 +08:00
Windows 3751891574 Merge branch 'qyqy_develop' of http://47.106.207.27:3000/AI260626/group_fqcd_jr into lzl_qyqy_integration 2026-09-12 12:10:41 +08:00
Windows f094cbeae1 fix: harden advisor market history dual-source sync 2026-09-12 12:10:10 +08:00
lzf_0626 cdb2de3e45 chore: 权限号段根治——9041-9046 并进种子；修正 grant 脚本与种子 9020-9034 的 id 映射冲突 2026-09-12 12:09:55 +08:00
lzf_0626 441364437c merge: 合并 ZSY 的客服 Agent 接入（访客身份、画像候选、转人工工单）—— PR #7 2026-09-12 12:05:25 +08:00
lzf_0626 ade5e0c085 回复 ZSY 的底座扩展确认 v2：逐行核验两句确认；指出 docs/05 端点编号撞车、三个新权限未随代码合并；补权限种子脚本 2026-09-12 11:46:47 +08:00
wangjianlong_0626 8a0cbab636 fix(memory-projection): 订正 outbox 取值口径并接通画像投影链路 
背景：memory_sync_outbox 这条链此前**完全没有消费者**，且生产端照 docs/00 §6.4.6
写成大写 MILVUS/NEO4J + 中文「待处理」，而消费端按 target_store 的**值**分派 handler、
且只领 status in {pending, failed} —— 两个条件都不满足，事件任何消费者都领不到、
永久滞留且不报错（唯一键 (event_uuid, target_store) 对大小写无约束，MySQL 也不报错）。
根因是代码与测试都硬编码字面量，所以测试跟着一起错、谁也没拦住。

订正
- profile_generation_service：取值改为全仓一致的小写（milvus/neo4j/upsert/pending）
- 测试改为引用常量并断言消费端契约，不再硬编码（硬编码是本次跑偏的直接原因）
- 新增契约回归测试：断言大写值分派不到 handler、会进死信，谁改回大写立刻红
- 新增 tools/normalize_memory_sync_outbox.py：订正历史脏行（默认 dry-run、幂等）

接通投影链路（此前零消费者）
- 新增 Milvus 集合 user_long_term_memory_v1 及建集合工具（幂等、不覆盖已有集合）
- 新增 MilvusProfileProjection / MilvusProfileVectorClient，并修掉移植带来的两处必炸点：
  customer_id 由「必须 int」放宽为接受数字字符串（本仓所有生产者都写 str，
  不放宽则每个事件必然失败）；不可投影的 memory_key 由「整批 raise」改为跳过留痕
  （否则一条 constraint: 记忆毒死该客户整批，而受控词表 13 个键里有 7 个不满足前缀）
- 新增 MemorySyncOutboxWorker（领取/指数退避/死信骨架保留原样）并接入 WorkerRuntime
- milvus → 向量投影；neo4j → 复用主干 ProfileGraphProjectionService（方案 A，
  不引入第二套投影，避免同一事实在图中两种说法、违反主干既有的只投影已确认事实的不变式）
- 生产端从 memory_unit(status=active) 组装 memory_sources，随事件带上确定快照
- 前置移植 conversation_privacy：写外部存储前脱敏手机号/证件号/银行卡等

验证
- 新增 17 个单测；全量 2 failed, 1307 passed, 2 skipped
  （2 个失败为既有环境项：断言请求体中文原文而 httpx 序列化成 \uXXXX，非本次引入）
- mypy app → 0 错（227 文件）；audit_schema → 89 张业务表无缺失/意外，未改动表结构
- 真机：真实 embedding(1024 维) + 真实 Milvus 写入并回读通过
- 整合链路（测试记忆 → 生产端组装 → outbox → 消费端投递 → Milvus 回读）通过，
  且 MySQL 已回滚、Milvus 无残留

文档
- 新增 docs/32-记忆投影链路实现说明.md：真实口径、根因、契约与验证证据（供接手）
- AGENTS.md：新增该易错点；新增 Windows 中文输出乱码的正确命令（-X utf8）；
  校正测试基线与 mypy 文件数

未做：未改 docs/00 基线、未动数据库迁移、未改投顾线代码、未启动常驻 Worker。
遗留：投顾线两处生产者的 payload 缺 memory_sources，会被消费至死信，待架构师确认是否投影。
 2026-09-12 10:45:40 +08:00
张胜宇 e85989b344 merge: integrate latest qyqy_develop (auth login + RBAC read) into ZSY branch 
Incremental merge on top of ef701c8, which already integrated the earlier qyqy base bbf623a. qyqy_develop only added commits on top of bbf623a, so this merge is conflict-free. Incoming: account/password login (POST /api/v1/auth/tokens), RBAC read-only query API, rate limit dependency, login test console and user management tools. Additive changes in app/main.py, requirements.txt and pyproject.toml from both sides are all preserved. ZSY side capabilities (visitor tokens, customer service agent, knowledge retrieval, profile projection) are unchanged.
 2026-09-12 10:37:53 +08:00
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
张胜宇 ef701c844c merge: integrate ZSY customer service and profile capabilities 2026-09-11 22:31:51 +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