按诊所补摄的三步里,前两步(cold-import / recompute-persona)都能用 --clinics 收窄,
只有 plans 是全量:每批 patientsHit 26-29 万、耗时 1h50m,其中约 1h43m 花在 selectHits
全表扫。今晚四批补摄,plans 一项就吃掉约 7 小时,而 90%+ 的扫描结果是 unchanged。

本次给 recompute-plans 加 --clinics=<orgId,...>,口径与 cold-import / recompute-persona
完全一致(patient_transactions.clinic_id 反查患者),把 selectHits 收窄到子集。

⚠️ 关键点:收窄命中集**必须同步收窄关闭步骤**。runAllForHost 第 3 步会扫全租户的
active+assigned,凡患者不在本轮命中集就判定"信号消失"关掉,挂在客服名下的还各记一条
auto_release。只收窄 selectHits 不收窄关闭 = 一条命令清空整个召回池。故 runAllForHost
新增 patientIds 入参时,两处一起收窄;关闭侧用内存 Set 过滤而非 SQL in(),避开 PG
32767 bind 上限(子集动辄数万)。

⚠️ SQL 形式踩坑:子集过滤写 `IN (SELECT … unnest(array))` 而非 `= ANY(array)`。
结果等价但代价差一个数量级 —— 后者让规划器转去嵌套循环,而本 SQL 带 gap lateral join
每行代价很高。本地实测(30000 患者库 / 子集 5825 人 / 11 个子场景):
  = ANY(array)          53.6s  ← 比全量 42.3s 还慢,perio_no_srp 一个就 35.5s
  IN (SELECT unnest())  10.2s  ← 命中数逐个相同,快 4.2 倍
细节写进 treatment-initiation-recall.scenario.ts 注释,改那行前先按同口径量一遍。

本地验证(jvs-dw 30000 患者 / 18591 active + 283 assigned):
  - 子集跑(5825 人):patientsHit 2552,plansClosed 0,duration 9.8s
    范围外 active 16317 / assigned 278 —— 跑前跑后逐字相同,一条没动
    (没有护栏的话这 16595 条会被全部关掉,plansClosed=0 就是护栏生效的证据)
  - 全量跑:patientsHit 19147,日志标 (全量),行为与改动前一致,无回归
  - 重复跑幂等:第二次 created=0 superseded=0 closed=0

⚠️ --clinics 只用于「补摄后立刻补计划」,**不能替代日常全量**:召回是时间驱动的,
数据一个字没变、沉默时长跨过阈值也该出计划,收窄就等于其余诊所当天不评估。
定时全量照跑,这个参数只省掉补摄后的那一次全扫。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>