文档：审查报告入库 + 全量校对补注

## 新入库（`docs/演示用/`）

- `代码库全面审查报告-2026-09-14.md`
- `代码修改方案-2026-09-14.md`
- `记忆系统排查报告-2026-09-14.md`
- `记忆系统修复文档-2026-09-14.md`
- `文档一致性审计报告-2026-09-14.md`
- `多Worker接入方案-2026-09-14.md`

## 全量校对（32 个既有文档 + `AGENTS.md`）

跨 39 个文件、**1125 insertions / 148 deletions**。

⚠️ **这批改动同样不是本次会话写的**。我抽样核对过性质：是**实质内容补充**而不是
格式/换行转换。例如 `docs/44-演示流程.md` 新增两条"2026-09-14 补注"：

- `启动金融Agent平台.bat` 只在**桌面**上，仓库里只有 `启动平台.bat` 这一份
  （两份由同一个 `tools/make_launcher_bat.py` 产出，改完 `start.ps1` 重跑它一起更新）；
- `advisor_t`(9020) 与 `offsite_t`(9006) **不在 `tools/seed_test_rbac.py` 的演示用户里**
  （那里只有 `cust_t`/`risk_t`/`admin_t`/`review_t` 四个），由 `grant_*.py` 系列创建，
  **重跑种子不会重建它们** —— 换机器时这两个账号登录失败，要先查 `sys_user` 有没有这两行，
  而不是查密码。

这两条都是对的地方，与我这一路踩到的现象一致（我确实用到了 `advisor_t`/`offsite_t`）。

**我没有逐字审阅全部 39 个文件**，只抽样确认了改动性质与规模。若其中有需要复核的段落，
请指明文件，我逐处核对。

docs/superpowers/handoff/2026-09-11-交接文档-客服Agent与RAG收尾.md

@@ -2,6 +2,30 @@
 
 > 本文是**给下一个接手 AI 的唯一入口**。读完本文 + `AGENTS.md` 的「📖 接手先读」索引，即可开工，**不需要**再翻历史过程台账。
 > 本文所有数字都是 **2026-09-11 实测**，不是估计；每条结论都附了复现命令。
+>
+> ---
+> ## ⚠️ 2026-09-14 复核：三处已变，读正文前先看这里
+>
+> **1. 分支指针已前进。** 本文（含 §6）写的 `origin/NL_develop = fb7d2f7` 是 2026-09-11 的状态；
+> **该远端分支此后又推进了 10 个提交**（现为 `1f62aca`）。引用提交号前请先 `git log --oneline -1 origin/NL_develop` 自查，
+> 不要照抄本文的 SHA。**主集成分支仍是 `qyqy_develop`**（ZSY 的客服接入线已由 PR #7 合入，见 `docs/36`）。
+>
+> **2. 测试基线数字在本文内部就不一致（已知缺陷）。** 本文出现**三个**不同的通过数：
+> - §0 第 16 行：`1 failed, 1013 passed, 2 skipped`
+> - §4 第 142 行：`1 failed, 804 passed, 2 skipped`
+> - §7 第 249 行：`804 passed / 52 表 / mypy 151`
+>
+> 原因是「合并前」与「合并后」两次实测被混写。**以 §0 的 `1013 passed`（合并后口径）为准**；
+> 且用例数此后仍在增长（不得据此判断"测试变少了"）。**当前基线一律重跑取数，不要引用本文数字。**
+>
+> **3. §0 末尾列的两个最大遗留，现在都已解决：**
+> - ① ~~`memory_sync_outbox` 没有消费者~~ → **已闭环**：`app/worker/runtime.py` 的
+>   `consume_profile_projections()`（L551）已在 Worker 主循环（L523）消费，milvus / neo4j 两个
+>   handler 都在；详见 `docs/37` / `docs/38`。
+> - ② ~~Redis 密码没配~~ → 已配置（`AGENTS.md` §E 与 `start.ps1` 的健康检查里含 Redis）。
+>
+> **4. 表数口径**：本文 §4/§7 的「52 表」是当时值；现为 **90 张表 = 89 张业务表 + `alembic_version`**
+> （场内 51 + 场外/推广 17 + 投顾 21），核验用 `tools/audit_schema.py`。
 
 ---
 
@@ -10,6 +34,7 @@
 > ⏱ **2026-09-11 第二次更新（合并完成后）**：本节已按最终状态重写，§6 的 Git 状态也已更新。
 > 你的工作**已推送**到远端个人分支 `NL_develop`（`fb7d2f7`），并已包含架构师当时最新的
 > `qyqy_develop`（38 个新提交）。**接手请从这条分支开始，不要再用 `6516ccb`。**
+> （⚠️ 分支此后又前进到 `1f62aca`，见文件头 ⚠️ 块。）
 
 - 分支：**`NL_develop`**（个人分支，从架构师的 `qyqy_develop` 拉出）→ PR 合回 `qyqy_develop`。
 - 本次交付的线：**客服 Agent（`CustomerServiceAgent`）+ RAG 知识检索 + 画像工具 + 知识库管理三端点**。
@@ -140,6 +165,7 @@
 # 全量测试（约 25 秒）
 .\.venv\Scripts\python.exe -m pytest -q
 # 期望：1 failed, 804 passed, 2 skipped
+# ⚠️ 804 是"合并前"的实测；合并后 §0 记的是 1013 passed。两者不矛盾，是两次快照。
 
 # 建表基线审计（证明没动 docs/00 基线）
 .\.venv\Scripts\python.exe tools\audit_schema.py
@@ -246,7 +272,9 @@ e4c4099 wip: 客服Agent + RAG + 画像收尾（基于 6516ccb）    ← 用户
 ## 8. 建议的接手顺序
 
 1. 读本文 + `AGENTS.md`。
-2. 跑 §4 的三条命令，确认基线（804 passed / 52 表 / mypy 151）。
+2. 跑 §4 的三条命令，确认基线（~~804 passed / 52 表 / mypy 151~~）。
+   ⚠️ 2026-09-14：这三个数都过期了——用例数已增长，表数现为 **90 张 = 89 业务 + `alembic_version`**。
+   **基线一律重跑取数**，别引用旧数字。
 3. 起 Milvus + 确认 `fin_*` 三集合有向量（§3 的数）。
 4. 从 §5 的 **第 1 条**（`memory_sync_outbox` 消费者）开始动手 —— 它是最明确、最有价值的一块。
 5. 任何"写 Milvus / 删 Milvus"的断言都要**轮询**；任何"工具能调通"的断言都要**真机跑一次**