docs(management): v2补通话小表决议——phone_call.channel是通话类型非消息渠道,渠道维宽表会双计

计划阶段发现:PhoneCall.channel ∈ {phone_call,voice_call}(models.py docstring
自证 calls are not tied to a messaging channel),v2把通话四列放进
(day,channel,user)宽表在channel=all聚合时双计。拆出employee_call_daily
(day,user_id)独立小表;§1.2补#9,P3重排#10-#14,§3改6张表,§4链路更新

docs/superpowers/plans/2026-09-08-yunke-management-console-implementation-v2.md

@@ -39,16 +39,17 @@
 | 6 | 周期分位数若 Python 拉全窗口 fact 行（月窗最坏 ~8 万行 ≈10MB 传输）不可取 | 改 SQL 窗口函数 `PERCENT_RANK() OVER (PARTITION BY user_id ORDER BY fr_ms)`（MySQL 8.4 / SQLite 3.25+ 双方言支持），传输降为员工数×2 行 |
 | 7 | fact 4h 增量成本 | 滚动 3 天=近 3 天活跃会话**全历史重算**（最大 friend 会话 5.2 万条 ≈1-2s × 几十活跃会话，4h 一次可接受）；一期取简单正确，预留「尾部增量」优化（历史已闭合串不变） |
 | 8 | full_sync_all.sh 步数变化 | 12→**14** 步：第 13 步 fact 全量重建、第 14 步宽表全量重建（宽表必须在 fact 之后） |
+| 9 | **通话列渠道错位**：v2 初稿把通话四列放进 (day, channel, user) 宽表，但 `phone_call.channel` 是**通话类型**（phone_call/voice_call）非消息渠道（models.py docstring 自证「calls are not tied to a messaging channel」）——channel=all 聚合时通话四列双计 | `app/db/models.py` PhoneCall 定义（批次A计划定案） | 通话拆出独立小表 `employee_call_daily`（day, user_id 主键，无渠道维），宽表删去通话四列 |
 
 ### 1.3 P3 级（补充明确/简化）
 
 | # | 项 | 结论 |
 |---|---|---|
-| 9 | 员工主数据来源未核实 | 列入 Task 0 核实（organization 路由背后是独立员工表还是账号表派生） |
-| 10 | 幽灵员工 | account_map 映射不上的 owner（离职/异常账号），宽表生成时直接**过滤**，不进管理域员工列表（评分场景不适用 analytics 的「读侧标注」策略） |
-| 11 | 功能开关降级 | 现状单 admin 账号无角色可分，v1 Task 13 的「功能开关」是过度设计；改为**上线顺序控制**（本地先行→服务器后上），RBAC 二/三期（与 v1 §15 一致） |
-| 12 | fr_ms 边界 | 按 ts 排序保证非负；超长样本（>30 天）保留在 fact，评分按异常裁剪原则处理（上游整合计划 §6.5「极端值不直接放大分数」）：>30 天样本参与分布展示，但不作为 0 分依据，单独列入超时明细 |
-| 13 | 五维分布图 | 一期只画 3 个可用维度（客户经营/服务质量/有效负载）+ 2 个「待数据」占位（行动执行/风险合规），不暗示完整五维 |
+| 10 | 员工主数据来源未核实 | 列入 Task 0 核实（默认 = `staff` 表，user_id 主键 + is_on_job，models.py 已有） |
+| 11 | 幽灵员工 | account_map 映射不上的 owner（离职/异常账号），宽表生成时直接**过滤**，不进管理域员工列表（评分场景不适用 analytics 的「读侧标注」策略） |
+| 12 | 功能开关降级 | 现状单 admin 账号无角色可分，v1 Task 13 的「功能开关」是过度设计；改为**上线顺序控制**（本地先行→服务器后上），RBAC 二/三期（与 v1 §15 一致） |
+| 13 | fr_ms 边界 | 按 ts 排序保证非负；超长样本（>30 天）保留在 fact，评分按异常裁剪原则处理（上游整合计划 §6.5「极端值不直接放大分数」）：>30 天样本参与分布展示，但不作为 0 分依据，单独列入超时明细 |
+| 14 | 五维分布图 | 一期只画 3 个可用维度（客户经营/服务质量/有效负载）+ 2 个「待数据」占位（行动执行/风险合规），不暗示完整五维 |
 
 ---
 
@@ -71,7 +72,7 @@
 
 ---
 
-## 3. 数据库设计：5 张新表
+## 3. 数据库设计：6 张新表
 
 ### 3.1 `first_reply_fact` 首响事实表（本设计新增）
 
@@ -122,12 +123,19 @@ PK: (day, channel, user_id, metric_version)
 生命周期 4 列（距今天数口径，当日持有客户状态分布，按 customer 当前归属）:
   new_customer_count, cooling_customer_count,
   dormant_customer_count, reactivated_customer_count
-通话 4 列（phone_call 按 user_id+day 直聚，user_id 已是员工 ID 无需转换）:
-  call_count, call_seconds, answered_call_count, call_followup_count
 元数据:
   data_complete, computed_at
 ```
 
+**通话小表 `employee_call_daily`**（§1.2 #9 拆出，无渠道维）：
+
+```text
+PK: (day, user_id)
+列: call_count, call_seconds, answered_call_count, call_followup_count, computed_at
+数据源: phone_call 按 user_id+start_call_time 日聚合；接通=call_duration>0；
+        followup=通话后 24h 内该员工任一账号对该客户有消息（Task 0 核实 join 键）
+```
+
 **相对 v1 的删减与更名**：
 
 - 6 列可派生不落：`reply_2h/24h_count`、`unreplied_2h/24h_count`（fact 表 fr_ms≤阈值计数 + cust_threads 派生）、`first_reply_count/first_reply_sum_ms`（≡ threads_answered/fr_sum_ms）；
@@ -170,7 +178,8 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
       │
       └─→ employee_metric_daily             [新 storage/employee_metrics.py：
              msg 计数(msg_daily_stats,friend) + 串类/分位(fact 同源)
-             + customer 生命周期 + phone_call]
+             + customer 生命周期]
+phone_call → employee_call_daily              [通话小表，无渠道维，§1.2 #9]
               → 期聚合/四对比（上期/个人基线4周/团队中位数）
                   → 试算评分 + 异常规则      [management/]
                       → 周/月快照（不可变）  [management/snapshots]