测试服上海世纪公园显示「193 位在岗」,而同规模的其他诊所都是 32–43。产品指认
康慧捧是别家诊所的人 —— 查下来正是如此,而且是普遍现象。

① **名册闸**(agent-roster.service.ts)
   拆开看这 193 人:19 个做了 15,476 条(95.8%),**98 个只有 1 条**、63 个 2–5 条;
   161 人(83%)全年合计 296 条,占 1.8%。按主场分:**160 人主场在别家诊所**,
   他们在这儿总共只有 330 条(康慧捧:主场 3,799 条在另一家,这儿 3 条)。
   医生/护士/前台偶尔被记成一次回访负责人,就进了名册。
   ⚠️ 危害不止那张表不好看:`rosterCount` 直接进默认批次估算
     (在岗人数 × 每天几通 × 时效)—— 193 × 15 = 2,895,比真实规模大一个数量级。
   ⇒ 判据改成「本诊所回访量占个人总量 ≥20%,**或**本诊所 ≥20 条」。
   ⚠️ 两条取或,缺一不可:只用占比会挡掉 13 个在某诊所做了 50+ 条但个人总量更大的
     真客服;只用绝对量对小诊所和新人不公平(那正是"名册不是白名单"要护的人)。
   ⚠️ 分母是**跨诊所**总量,⛔ 不是本诊所的 —— 否则占比恒为 100%,整道闸失效(已锁测试)。
   ⭐ 实测:世纪公园 193 → 34(25 个靠量进、9 个靠占比进),康慧捧被挡掉;
     其余诊所各减 1–6 人,每家留下的名册仍覆盖本诊所 **98% 以上**的回访量。
   ⚠️ 闸只改"建议给谁",⛔ 没改"能分给谁":被挡掉的人走 extraUserIds 照样能被点名,
     姓名由 namesAnywhere 兜底、inRoster=false。rosterNote 的措辞跟着判据一起改。

② **「另有 N 人算不出档位」数错了**(cohort-attributes.service.ts)
   界面写 50,去重只有 42 —— 50 是把 8 个治疗行的 unknown **竖着相加**得来的,
   一个患者有几个治疗项就被数几次,而那句话写的是「人」。
   本方法开头那条口径(「矩阵按患者去重」「⛔ 别让主管一对数就觉得系统在骗他」)
   讲的正是这件事,偏偏这行汇总自己踩了。
   ⇒ 改成 GROUPING SETS 多取一组跨标签去重行。⚠️ 必须与各格**同一次查询**算:
     分两次就是两个 NOW(),边界人群会在两个时刻落进不同档,差额又对不上。
   ⚠️ 话里补一句「那一列竖着加会大于这个数」—— 不写清楚,主管一相加还是对不上,
     那只是换了种方式让他不信任这个数。

📌 顺带定案:**咨询不算到诊**(产品定)。那 42 人名下只有 diagnosis_record +
   consultation_record、**一条 encounter/病历都没有**,末诊为空是对的,不是漏算。
   ⛔ 不改末诊口径(schema 上写死的 encounter + 治疗 + 挂号 + 病历 并集)。

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