docs: 标注 v2 文档与现行代码漂移(以 schema/代码为准)

architecture-v2 / db-design-v2 / three-layer-model / design-v2 顶部加「代码漂移修订」区块:
Platform→Host(hostId)、AI Gateway/Dify→AiCall 多 provider、post_treatment_recall→
treatment_initiation/aftercare_recall、plan_summaries 3→4 type、persona 4→16 feature。

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/architecture-v2.md

@@ -15,6 +15,18 @@
 
 ---
 
+## ⚠️ 代码漂移修订(2026-06-16,以下以 schema/代码为准)
+
+本文成稿较早,以下术语**已被真实代码取代**,阅读时按右列理解:
+
+| 本文写的 | 现行代码(真理源) |
+|---|---|
+| `Platform` / `platformId` / "宿主注册表 platforms" | **`model Host` / `hostId`**,schema 已无 `platformId`;隔离基线 = `hostId + tenantId` |
+| "AiCall 框架 → DeepSeek V4 Pro 直连" / "AI Gateway → Dify" | **AiCall 框架**(`ai-call-runner.service.ts` + `core/ai-provider.service.ts`)按 `deepseek-*`/`gemini-*`/`qwen*` 前缀**多 provider 路由**;摘要类默认 Qwen;代码中无 Dify |
+| 召回 scenario = `post_treatment_recall`(4 子场景) | `treatment_initiation_recall`(启治召回,K00–K09 子场景)+ `treatment_aftercare_recall`(疗效保障);scenario 规则为应用层常量 + `canonical-codes.ts` 字典 |
+
+---
+
 ## 设计初衷
 
 架构设计要同时满足三个目标:

docs/db-design-v2.md

@@ -20,6 +20,23 @@
 
 ---
 
+> ---
+> ## ⚠️ 代码漂移修订(2026-06-16,以下以 schema/代码为准)
+>
+> 本文 v2.0/v2.1 主体仍沿用早期术语,以下几处**已被真实代码取代**,阅读时按右列理解:
+>
+> | 本文写的 | 现行代码(真理源) |
+> |---|---|
+> | `Platform` 表 / `platformId` / `platform_id` | **`model Host` / `hostId`**(schema 已无 `platformId`,52 处 `hostId`)。隔离基线 = `hostId + tenantId` |
+> | "AI Gateway → Dify" / 必走网关 | **AiCall 框架**(`apps/pac-service/src/modules/ai/ai-call-runner.service.ts` + `core/ai-provider.service.ts`),按 `deepseek-*` / `gemini-*` / `qwen*` 前缀路由 provider;**代码中无 Dify** |
+> | `agent_invocations.gatewayProvider` / `workflowId`(Dify 语义) | 字段名保留,语义为 AiCall 的 provider / callKey;摘要类(plan_summaries)默认走 **Qwen** |
+> | `plan_summaries` per-plan × **3** type | per-plan × **4** type — 新增 `recall_history`(历史联系一句话摘要,`SummaryType.RECALL_HISTORY`) |
+> | §12 raw SQL `followup_plans_one_open_per_scenario`(含 scenario) | 已改 **patient 级** single-open(§10.3 正确;§12 SQL 片段是旧稿,以 §10.3 + 实际 migration 为准) |
+> | scenario = `post_treatment_recall`(4 子分支) | `treatment_initiation_recall`(启治召回,canonical code K00–K09 子场景,union-find 牙位合并)+ `treatment_aftercare_recall`(疗效保障)。详见 `docs/algorithm/potential-treatment-recall-flow.md` + `canonical-codes.ts` |
+> | persona "v1 起步 4 个 feature" | 实际 **16 个 feature** 全规则路径已落地(`packages/types/src/persona-feature-specs.ts`) |
+>
+> ---
+
 ## 目录
 
 - [一、业务定位:PAC 三层模型](#一业务定位pac-三层模型)

docs/design-v2.md

@@ -10,6 +10,8 @@
 > - API Pool 1 事实层细化为**双表模型**(`patient_transactions` 账本 + `patient_facts` 版本流)
 > - Persona 起步特征明确为 4 个(value / treatment_chain_status / recall_risk / do_not_contact_status)
 > - 一期 scenario 在 [scenarios/post_treatment_recall.md](scenarios/post_treatment_recall.md) 细化为**一个 scenario 内 4 个子分支**(根管未戴冠 / 正畸中断 / 种植年度复查 / 牙周维护期)
+>
+> **⚠️ 代码漂移修订(2026-06-16,以代码为准):** 一期实际主战场已演进为 `treatment_initiation_recall`(启治召回,canonical code K00–K09 子场景,union-find 牙位合并)+ `treatment_aftercare_recall`(疗效保障),非本文写的 `post_treatment_recall` 4 子分支;Persona 实际落地 **16 个 feature**(非起步 4 个);LLM 走 **AiCall 框架多 provider**(deepseek/gemini/qwen),无 Dify;隔离字段为 **`hostId`**。
 > - 接入路径标准化为 Pull + Push 双通道,详见 [host-integration.md](host-integration.md)
 > - 验收口径第 10 条补充"双表模型 + 版本流" 落地具体表名
 

docs/three-layer-model.md

@@ -3,6 +3,8 @@
 > Patient Facts(事实)→ Persona(画像)→ Follow-up Plan(召回计划)
 > 单向数据流 + 版本化推断 + 横切审计账本
 
+> **⚠️ 代码漂移修订(2026-06-16,以代码为准):** 图中 `LLM Provider` 注释"v1 = DeepSeek 直连"已扩展为 **AiCall 框架多 provider 路由**(deepseek/gemini/qwen,摘要类走 Qwen),无 Dify;`plan_summaries` 由 3 type 增至 **4 type**(新增 `recall_history`);隔离基线字段为 **`hostId`**(非 `platformId`)。
+
 ---
 
 ## 一张图