宿主自己已建复杂病例、客服/咨询师在推进的患者,PAC 不该再发起召回:
两边同时联系同一个人,患者体验差,也显得两个系统各说各话。

【落点】patient_profiles.host_follow_up_active(canonical: hostFollowUpActive),
与 do_not_contact / deceased 并列在②合规硬过滤,但性质不同:
  合规闸  = 法务/风险,永久,需人工解除
  跟进闸  = 协作分工,临时,宿主停止跟进即回池

判定用 `IS NOT TRUE` 而非 `= false` —— 该列可空,NULL 表示宿主未提供该信号
(如 jvs-dw 暂未接入),不能因 NULL != false 把这些患者全挡在池外。

【FRIDAY 侧口径】customer_basic_info 新增 inline 列 active_complex_case_count =
该患者未删除且 case_stage ∈ {待跟进,已咨询,已预约,诊疗中} 的 complex_case_info 条数;
已成单(需求已闭环)/ 暂停跟进(宿主已停手)不计,交还 PAC 召回。

为什么由宿主算而非整表推 complex_case_info:
  1. case_stage 的码→中文映射不在库里(column_comment 只写「病例阶段:」值为空),PAC 无从翻译
  2. 一患者可有多条病例,PAC 要的是患者粒度聚合结论
  3. 与既有 inline 纪律一致(同 contacts_tel / std_code / class_name)

⚠️ 两处待 FRIDAY 确认,确认前不启用该闸:
  ① 列名 active_complex_case_count 是 PAC 建议名(源表无此列,属新定义);
     宿主若另有习惯叫法以宿主为准 —— 契约纪律是列名随宿主
  ② complex_case_info.is_del 注释写「未删除1/已删除0」与惯例相反,实际数据 0/1 都有,
     取数前须确认哪个值代表未删除,否则计数整体反掉

顺手修一处已与线上代码矛盾的文档:customer_referee_circle.referee_relationship
的方向说明还是旧的「本行 customer 是 referee 的 X」,而 a38f1b60 已按源库年龄实测
改成同向直译。文档同步为「本行 referee 是 customer 的 X」。

本次仅文档,无代码/schema 改动。

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