docs(management): v2计划评审修正——引用定位/删减清单补全/口径表补活跃员工行

评审结论 Approved + 4 条 advisory 全部采纳：
- 降温频次定义/异常裁剪原则的引用从 v1 修正为上游整合计划
- 删减清单补 effective_sessions/activated_customer_count/cust_threads 更名说明
- 口径决议表补活跃员工(幽灵过滤)差异行

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

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

@@ -28,7 +28,7 @@
 |---|---|---|---|
 | 1 | **跨夜串丢失**：现有日切算法下「客户 23:00 发→员工次日 9:00 回」的首响样本整条丢失（Day1 串未闭合只计 threads；Day2 重起算时无客户消息不成串，员工回复落空段）。P90/24h 回复率系统性低估，而评分重度依赖这两项 | `app/storage/summary.py` `_thread_stats` 日切近似，docstring 自述「跨夜串归属日偏差」实为样本丢失 | fact 表**不挂写钩子**，由 4h 滚动+夜间全量任务用**跨日精确串算法**（按会话全历史计算）独立生成；写钩子零改动，`_thread_stats` 不改 |
 | 2 | **stat_daily_staff 是 friend+room 混合口径**：`sent/recv/threads/answered/fr` 五列聚合无 kind 过滤，群消息污染首响/回复率。v1 说「从 stat_daily_staff 拷贝」不可行 | `app/storage/staff_summary.py` `recompute_days` 聚合循环 | 宽表消息串类列从 msg_daily_stats 按 `peer_kind='friend'` **全量自算**（account_map 归并模式复用）；管理页与现有看板排行的数字差异属口径不同，各自标注 |
-| 3 | **「降温」定义冲突**：v1 §8.1 降温=频次低于个人基线；现有 churn/客户资产分层=距今天数区间。两套「降温」会并存打架 | `app/analytics/metrics.py` churn 三分法 | 一期生命周期 4 列统一用**现有距今天数口径**；频次基线降温后置二期；差异写入 metric-definitions |
+| 3 | **「降温」定义冲突**：上游整合计划（`2026-09-08-yunke-data-intelligence-management-plan.md` §8.1/§15）降温=频次低于个人基线；现有 churn/客户资产分层=距今天数区间。两套「降温」会并存打架 | `app/analytics/metrics.py` churn 三分法 | 一期生命周期 4 列统一用**现有距今天数口径**；频次基线降温后置二期；差异写入 metric-definitions |
 | 4 | **对账口径必须预写死**：fact（跨日精确）与 msg_daily_stats 三列（日切近似）即使 friend 口径也不相等，差集=跨夜闭合串 | 同 #1 | Task 2 验收断言：fact 样本集 ⊇ 日切被回串，差集=跨夜串；禁止相等断言 |
 
 ### 1.2 P2 级（性能/实现修正）
@@ -46,7 +46,7 @@
 | 8 | 员工主数据来源未核实 | 列入 Task 0 核实（organization 路由背后是独立员工表还是账号表派生） |
 | 9 | 幽灵员工 | account_map 映射不上的 owner（离职/异常账号），宽表生成时直接**过滤**，不进管理域员工列表（评分场景不适用 analytics 的「读侧标注」策略） |
 | 10 | 功能开关降级 | 现状单 admin 账号无角色可分，v1 Task 13 的「功能开关」是过度设计；改为**上线顺序控制**（本地先行→服务器后上），RBAC 二/三期（与 v1 §15 一致） |
-| 11 | fr_ms 边界 | 按 ts 排序保证非负；超长样本（>30 天）保留在 fact，评分按 v1 §6.5 异常裁剪原则处理 |
+| 11 | fr_ms 边界 | 按 ts 排序保证非负；超长样本（>30 天）保留在 fact，评分按异常裁剪原则处理（上游整合计划 §6.5「极端值不直接放大分数」）：>30 天样本参与分布展示，但不作为 0 分依据，单独列入超时明细 |
 | 12 | 五维分布图 | 一期只画 3 个可用维度（客户经营/服务质量/有效负载）+ 2 个「待数据」占位（行动执行/风险合规），不暗示完整五维 |
 
 ---
@@ -124,7 +124,12 @@ PK: (day, channel, user_id, metric_version)
   data_complete, computed_at
 ```
 
-**相对 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）。
+**相对 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）；
+- `effective_sessions` 不单列：v1 §6.3 工作负载视图的「有效会话」≡ cust_threads（1:1 有客户消息串的天级会话数），页面字段名从 cust_threads 映射；
+- `activated_customer_count` 一期不做：「有效激活」定义是 v1 §21 #4 未决口径（几轮互动/几天窗口），随二期频次基线生命周期一起定义；
+- `customer_threads` 更名为 `cust_threads`（与 msg_daily_stats/stat_daily_staff 现有列名对齐）。
 
 **metric_version 语义**：只影响**派生列**（分位/生命周期/通话跟进）；消息拷贝列与版本无关。算法演进时新版本并行落表不覆盖旧数据。
 
@@ -179,6 +184,7 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
 | 消息量/串/首响均值 | 1:1（friend-only） | friend+room 混合 | 服务质量语义要求 1:1 |
 | 首响分位 | 跨日精确串（fact） | 日切近似（跨夜丢失） | P90 正确性 |
 | 降温客户 | 距今天数区间（同 churn 页） | 同 | 一期统一，频次基线降温二期 |
+| 活跃员工 | 宽表口径（幽灵员工已过滤，§1.3 #9） | `_active_staff` 含映射不上的账号并读侧标注 | 评分场景不接受幽灵员工 |
 | 交互天数/日桶 | Asia/Shanghai 自然日 | 同 | 一致 |
 
 三方差异（管理页 vs 数据看板 vs 云客原版）在 metric-definitions 端点与页面口径说明中如实标注，不做静默差异。