docs(refactor): 纠正 §4.4 框架 — 非独立隔离策略,是换槽位在查询层的对应

澄清:无独立隔离策略,一切由数据范围控制;现状隔离=代码 where(tenant_id),
非 RLS/非 schema。brand 从 tenant_id 槽搬到 source_unit 槽后,品牌隔离的
where 判别列随之 tenant_id→source_unit。数据范围两粒度:plan 按诊所、
患者按品牌(source_unit),同源于 org 位置。默认本品牌(复刻现状),P1 可配置。

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

docs/tenant-group-org-model-refactor.md

@@ -93,12 +93,21 @@ cohort:
 
 > 顺带:`pull.orchestrator.ts:160` 的 `t_default/t_demo` 另一套约定,一并收口到 slug。
 
-### 4.4 隔离保持(合 tenant 后,补 source_unit 默认过滤的少数面)
-合并后,**plan 列表仍靠 clinic 过滤隔离**(用户 clinicIds 是本品牌诊所);但**不按 clinic 过滤的面**会泄漏到另一品牌,需补 `source_unit` 默认过滤(= 只看本品牌,复刻现状):
-1. **患者搜索 / 列表**(`patient.service.ts`)— 按 (host,tenant) 查,不带 clinic;
+### 4.4 数据范围:换槽位在查询层的对应(非新策略、非 RLS)
+
+> **没有独立"隔离策略"。** 现状隔离 = 纯代码 where(`WHERE tenant_id=scope.tenantId`,~33 处;schema 无 RLS、无 `$extends`,UNIQUE 只管身份)。
+> brand 从 tenant_id 槽搬到 source_unit 槽(§2),那么**"按品牌隔离"的 where 判别列也跟着 `tenant_id` → `source_unit`** —— 同一条 where,换个列名,不是新机制。
+
+**数据范围有两种粒度,都来自 org 位置:**
+- **plan** 绑诊所 → 范围用 `clinicIds`(现状已有);
+- **患者**不绑单诊所 → 范围用**品牌 `source_unit`**。
+
+具体:scope 加 `sourceUnits: string[]`(用户所属品牌,登录派生,与 clinicIds 并列同源)。合并 tenant 后,**今天靠 `tenant_id=品牌` 隔离、但不按 clinic 过滤的面**,把判别列换成 `source_unit IN scope.sourceUnits`:
+1. **患者搜索 / 列表**(`patient.service.ts:54` 等)— 现 `where:{hostId,tenantId,…}`,改 `tenantId=集团 + sourceUnit IN …`;
 2. **召回池 NULL-clinic 工单**(`buildListWhere` pool 的 `targetClinicId IS NULL` 分支);
-3. **按 id 直取患者/plan 的 guard**(`plan.service.ts:353` 等 `tenantId===scope.tenantId` 校验,补 source_unit)。
-> scope 加一个 `sourceUnits: string[]`(用户所属品牌,登录派生);默认过滤 `IN sourceUnits`。
+3. **按 id 直取患者/plan 的 guard**(`plan.service.ts:353` 的 `tenantId===scope.tenantId`,加 source_unit)。
+> plan 列表本就按 clinic 过滤(用户 clinicIds 是本品牌诊所),已隔离,source_unit 于此冗余、可不加。
+> 默认 `sourceUnits` = 用户本品牌(复刻现状);**P1 让它可配置**(集团可开跨品牌)。
 
 ### 4.5 迁移(一次性,可逆)
 1. 加 `patients.source_unit`(nullable);