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

## 新入库（`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/22-四大Agent流程实现拆解.md

@@ -2,10 +2,24 @@
 
 > 输入：`智能客服Agent专项设计方案`(v1.3, 1664 行)、`基金运营流程`、`风控模块详细业务流程`、`投资顾问流程`。
 > 目的：在动手前说清「哪些能直接用底座、哪些要新写、哪些必须你们先定」。
+>
+> ---
+> ## ⚠️ 本文是**开工前评估稿**（2026-09-09），多处结论已被实现推翻
+>
+> **保留此文是为了留"当时怎么判断的"证据，不要用它判断当前进度。** 下列三处已作废：
+>
+> | 本文原话 | 当前实际 |
+> |---|---|
+> | 「底座的 **52 张表**」 | **90 张表 = 89 张业务表 + `alembic_version`**（场内 51 + 场外/推广 17 + 投顾 21） |
+> | §3 表里「基金运营（场外）＝**无场外表**」 | **已建 17 张**（`offsite_*` / `promotion_*`），见 `docs/28` |
+> | §5「**必须新建场外一组表**」 | **已建成**；且对应 Agent 已注册（`OffsiteFundAgent` / `PromotionMaterialAgent`），接口已挂载 |
+> | §5.2 核对规则按**金额**（「单日申购金额上限」「赎回金额 vs 可用金额」） | 实现改为**份额口径**：单笔申购上限＝份额 **10%**、巨额赎回＝份额 **20%** |
+>
+> **当前状态以 `docs/验收与审计/phase1-acceptance-report.md` 为准。**
 
 ## 0. 一句话结论
 
-**能实现。** 决定性原因是：**底座的 52 张表与这几份流程的设计高度吻合**，
+**能实现。** 决定性原因是：**底座当时的 52 张表与这几份流程的设计高度吻合**，
 绝大部分工作是「填 Service / Agent 逻辑」，而不是「重建表结构」——后者才是真正贵的部分。
 
 举几个直接对上的例子（均为实际字段名）：
@@ -33,7 +47,7 @@
 | **智能客服** | 全部就绪 | 覆盖最好（意图/知识/转人工/负面词/模板/会话） | 三集合知识检索、客服 Agent 本体、脱敏工具、状态机 | 中 |
 | **投资顾问** | 全部就绪 | 适当性已实现；组合/报告无 | 策略配置、组合构建、报告生成、审核签发流 | 中 |
 | **风控监测** | 全部就绪 | **几乎为零**（`risk_alert` 仅 4 处命中，多为 ORM） | **规则引擎**、扫描服务、预警处置 API、日报、邮件 | 大 |
-| **基金运营（场外）** | **无场外表** | 无 | 需新建独立表 + 单据解析 + 核对规则 | 大（且缺样本） |
+| **基金运营（场外）** | ~~**无场外表**~~ **已建 17 张**（`offsite_*`/`promotion_*`） | 已注册 `OffsiteFundAgent` | 单据解析 + 核对规则 | 已落地 |
 
 ## 2. 智能客服 Agent
 
@@ -127,13 +141,15 @@
 底座 15 张 `fin_*` 全是**场内模拟交易**；运营流程是**场外申购赎回**，
 而 `AGENTS.md` 明确「场外基金运营流程独立，不得写入场内交易表」
 → 因此**必须新建场外一组表**，不能复用场内表。
+→ ✅ **已完成（2026-09-14）**：场外/推广 17 张表已建（`offsite_*` / `promotion_*`），
+   逐表登记见 `docs/28-场外与推广域数据表登记.md`。
 
 流程本身可拆成三段：
 1. **单据采集与解析**：从运营邮箱取中国结算邮件 → 解析申购/赎回单扫描件 → 关键字段提取 + 格式校验。
    涉及邮件收取（另一处 SMTP/IMAP 缺口）与文档解析（底座无此能力）。
-2. **核对规则**（文档已给全字段）：申购后单一持有比例上限、单日申购金额上限、金额格式（两位小数/万元）、
-   日期格式、巨额赎回、赎回金额 vs 可用金额、最低申购金额、是否在开放期、反洗钱嫌疑。
-   其中 `fin_product.single_investor_max_holding_ratio / min_amount / open_period_start/end` 已就绪，**但场外产品需要独立表**。
+2. **核对规则**（文档已给全字段；⚠️ **实现已改为份额口径**）：申购后单一持有比例上限、~~单日申购金额上限~~ **单笔申购份额上限（10%）**、金额格式（两位小数/万元）、
+   日期格式、~~巨额赎回（金额）~~ **巨额赎回（份额 20%）**、~~赎回金额 vs 可用金额~~、最低申购金额、是否在开放期、反洗钱嫌疑。
+   其中 `fin_product.single_investor_max_holding_ratio / min_amount / open_period_start/end` 已就绪，**场外产品使用独立表**。
 3. **人在回路**：NL2SQL 确认 → 汇总统计 → 是否上报风控 → 是否给资金清算岗 → 回单给中国结算。
 
 ⚠️ **文档自己写了「待工作：不同的申购赎回单子，以作实际操作案例」** —— 也就是说**缺样本数据**。