docs(口径): 钉住预约成功率的分母 —— 不筛结果项，未接通也算他打过

产品确认（2026-08-22）：分母判据只有一条——**他有没有真打**。
所以「没进展」那一桶（未接通 / 待跟进 / 需要找医生 / 已发短信 / 改约）
照样进分母：打了没人接，那也是打了。

⚠️ 未接通往往占分母的大头，所以这个数读的是「触达 × 转化」合起来的效率，
⛔ 不是"聊上了的人里谈成几成"。⛔ 别为了好看把 keep 组从分母里摘掉——
那会变成另一个指标，而名字没变。

唯一不在分母里的是「没有结果」：那些单一条执行记录都没有，天然不在
plan_executions 里，不需要额外排除。

代码一行没动，只是把这条决定写进 schema 注释 + 加一条回归（分母 SQL 里
出现 outcome 就红）。

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

apps/pac-service/tests/booked-vs-scheduled-next.spec.ts

@@ -139,6 +139,23 @@ describe('③ 主管工作台:退回率 → 预约成功率', () => {
     expect(SVC).not.toMatch(/^\s+handled,$/m);
   });
 
+  /**
+   * 🔴 **分母不筛结果项**(2026-08-22 产品确认)——判据只有一条:他有没有真打。
+   *   「没进展」那一桶(未接通 / 待跟进 / 已发短信…)照样进分母:打了没人接,那也是打了。
+   *   ⚠️ 未接通往往占大头,所以这个数是「触达 × 转化」合起来的效率。
+   *   ⛔ 别为了"好看"把 keep 组从分母里摘掉 —— 那会变成另一个指标,而名字没变。
+   */
+  test('⭐⭐ 分母 ⛔ 不筛 outcome —— 未接通也算他打过', () => {
+    const q = SVC.slice(
+      SVC.indexOf('const done = await this.prisma.$queryRaw'),
+      SVC.indexOf('窗口内「分到了多少」'),
+    );
+    expect(q).toContain('count(DISTINCT plan_id)');
+    expect(q).toContain('FROM plan_executions');
+    // ⛔ 一旦这里出现 outcome,分母就不再是"他打过的"了
+    expect(q).not.toContain('outcome');
+  });
+
   test('⭐ 列头写「近 N 天预约成功率」,跟着切换器走', () => {
     expect(TEAM).toContain('近 {days} 天预约成功率');
     expect(TEAM).toContain('近 {days} 天已处置');

packages/types/src/schemas/plan-assignment.ts

@@ -1253,6 +1253,15 @@ export const AgentWorkloadRowSchema = z.object({
    *   ⛔ 原来这一列叫「完成」,而批次表那一列叫「已处置」 ——
    *   同一屏上两个词指同一件事,主管只能猜。而且「完成」听起来像"做成了",
    *   这正是整套口径反复要避免的读法。
+   *
+   * 🔴 **它同时是「预约成功率」的分母,⛔ 不筛结果项**(2026-08-22 产品确认)。
+   *   判据只有一条:**他有没有真打**。所以「没进展」那一桶(未接通 / 待跟进 /
+   *   需要找医生 / 已发短信 / 改约)照样进分母 —— 打了没人接,那也是打了。
+   *   ⚠️ 未接通往往占分母的大头,所以这个数读的是「**触达 × 转化**」合起来的效率,
+   *     ⛔ 不是"聊上了的人里谈成几成"。⛔ 别为了"好看"把 keep 组从分母里摘掉:
+   *     那会变成另一个指标,而名字没变。
+   *   ⚠️ 唯一不在分母里的是「没有结果」—— 那些单**一条执行记录都没有**,
+   *     他压根没打,自然也不该算进"他打过的"。
    */
   done: z.number().int(),
   /// 窗口内主动退回的条数(走账本,⛔ 不读 followup_plans.release_reason —— 那是当前值会被清)