docs(management): v2计划复核收尾——评审确认后修4处文档级问题

评审代理逐案例推演确认P1#5同源修正算法成立(Approval维持)，遗留修正：
- §1.1#2修正列更新(串类三列由fact同源输出,不再说全量自算)
- §1.1#5去掉'>100%'夸大表述(单向低估,不可达)
- §9对账点限定消息计数列(串类列禁止相等断言)
- Task0口径只记录文档,配置落库归Task3种子CLI
- P2/P3行号全局重排(#6-#13),交叉引用同步
- §3.2负载列补数据源标注;时效说明措辞精确化

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

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

@@ -27,28 +27,28 @@
 | # | 问题 | 证据 | 修正 |
 |---|---|---|---|
 | 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 归并模式复用）；管理页与现有看板排行的数字差异属口径不同，各自标注 |
+| 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 归并模式复用）；串类三列由 fact 模块同源输出（见 #5）；管理页与现有看板排行的数字差异属口径不同，各自标注 |
 | 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 样本集 ⊇ 日切被回串，差集=跨夜串；禁止相等断言 |
-| 5 | **回复率分子分母必须同源**：v2 初稿宽表串类列（cust_threads 等）取自 msg_daily_stats 日切聚合，而回复率分子取自 fact（跨日）——多日未回串使日切分母膨胀，回复率被低估甚至 >100% | 本轮复查发现（#2 修正的连带遗漏） | 宽表串类三列改由 fact 计算模块**同源输出**（按串末条归属日的 threads/answered/fr_sum）；msg_sent/recv 与 active_friends/rooms 与串算法无关，仍取 msg_daily_stats |
+| 5 | **回复率分子分母必须同源**：v2 初稿宽表串类列（cust_threads 等）取自 msg_daily_stats 日切聚合，而回复率分子取自 fact（跨日）——多日未回串使日切分母膨胀，回复率被系统性低估 | 本轮复查发现（#2 修正的连带遗漏） | 宽表串类三列改由 fact 计算模块**同源输出**（按串末条归属日的 threads/answered/fr_sum）；msg_sent/recv 与 active_friends/rooms 与串算法无关，仍取 msg_daily_stats |
 
 ### 1.2 P2 级（性能/实现修正）
 
 | # | 问题 | 修正 |
 |---|---|---|
-| 5 | 周期分位数若 Python 拉全窗口 fact 行（月窗最坏 ~8 万行 ≈10MB 传输）不可取 | 改 SQL 窗口函数 `PERCENT_RANK() OVER (PARTITION BY user_id ORDER BY fr_ms)`（MySQL 8.4 / SQLite 3.25+ 双方言支持），传输降为员工数×2 行 |
-| 6 | fact 4h 增量成本 | 滚动 3 天=近 3 天活跃会话**全历史重算**（最大 friend 会话 5.2 万条 ≈1-2s × 几十活跃会话，4h 一次可接受）；一期取简单正确，预留「尾部增量」优化（历史已闭合串不变） |
-| 7 | full_sync_all.sh 步数变化 | 12→**14** 步：第 13 步 fact 全量重建、第 14 步宽表全量重建（宽表必须在 fact 之后） |
+| 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 之后） |
 
 ### 1.3 P3 级（补充明确/简化）
 
 | # | 项 | 结论 |
 |---|---|---|
-| 8 | 员工主数据来源未核实 | 列入 Task 0 核实（organization 路由背后是独立员工表还是账号表派生） |
-| 9 | 幽灵员工 | account_map 映射不上的 owner（离职/异常账号），宽表生成时直接**过滤**，不进管理域员工列表（评分场景不适用 analytics 的「读侧标注」策略） |
-| 10 | 功能开关降级 | 现状单 admin 账号无角色可分，v1 Task 13 的「功能开关」是过度设计；改为**上线顺序控制**（本地先行→服务器后上），RBAC 二/三期（与 v1 §15 一致） |
-| 11 | fr_ms 边界 | 按 ts 排序保证非负；超长样本（>30 天）保留在 fact，评分按异常裁剪原则处理（上游整合计划 §6.5「极端值不直接放大分数」）：>30 天样本参与分布展示，但不作为 0 分依据，单独列入超时明细 |
-| 12 | 五维分布图 | 一期只画 3 个可用维度（客户经营/服务质量/有效负载）+ 2 个「待数据」占位（行动执行/风险合规），不暗示完整五维 |
+| 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 个「待数据」占位（行动执行/风险合规），不暗示完整五维 |
 
 ---
 
@@ -115,7 +115,7 @@ PK: (day, channel, user_id, metric_version)
   msg_sent, msg_recv
 串类列（fact 计算模块同源输出，跨日精确、按串末条归属日——与回复率分子同口径）:
   cust_threads, threads_answered, fr_sum_ms
-负载列:
+负载列（msg_daily_stats，friend/room 分行天然区分）:
   active_friends（1:1 distinct 客户）, active_rooms（distinct 群）
 首响日值（趋势图用，从 fact 算）:
   first_reply_p50_ms, first_reply_p90_ms
@@ -137,7 +137,7 @@ PK: (day, channel, user_id, metric_version)
 
 **metric_version 语义**：只影响派生列（生命周期/通话跟进的算法口径）；消息计数与串类事实列与版本无关。默认值 `v1`，算法演进时新版本并行落表不覆盖旧数据。
 
-**时效说明**：宽表内消息计数列随写钩子近实时（msg_daily_stats），串类列随 fact 重算（4h/夜间）——同表两种时效；computed_at 取宽表生成时间，data_complete 标注 fact 是否已覆盖当日。
+**时效说明**：消息计数列的源数据（msg_daily_stats）随写钩子近实时更新，串类列的源数据（fact）随 4h/夜间重算更新——两类列的上游时效不同，但宽表行统一随 4h/夜间重算落库；computed_at 取宽表生成时间，data_complete 标注 fact 是否已覆盖当日。
 
 **评分用周期值的计算来源**（不在宽表存储）：周期 P50/P90、2h/24h 回复率一律从 fact 表精确计算（SQL 窗口函数），宽表日值仅供趋势展示。
 
@@ -191,7 +191,7 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
 | 消息量/串/首响均值 | 1:1（friend-only） | friend+room 混合 | 服务质量语义要求 1:1 |
 | 首响分位 | 跨日精确串（fact） | 日切近似（跨夜丢失） | P90 正确性 |
 | 降温客户 | 距今天数区间（同 churn 页） | 同 | 一期统一，频次基线降温二期 |
-| 活跃员工 | 宽表口径（幽灵员工已过滤，§1.3 #9） | `_active_staff` 含映射不上的账号并读侧标注 | 评分场景不接受幽灵员工 |
+| 活跃员工 | 宽表口径（幽灵员工已过滤，§1.3 #10） | `_active_staff` 含映射不上的账号并读侧标注 | 评分场景不接受幽灵员工 |
 | 交互天数/日桶 | Asia/Shanghai 自然日 | 同 | 一致 |
 
 三方差异（管理页 vs 数据看板 vs 云客原版）在 metric-definitions 端点与页面口径说明中如实标注，不做静默差异。
@@ -233,7 +233,7 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
 
 | 任务 | 内容 | 相对 v1 的变化 | 估时 |
 |---|---|---|---|
-| Task 0 | 口径冻结：回测员工名单（3-5 名覆盖微信为主/WA 为主/群为主/高负载/低样本）+ 默认配置落库 + **五项核实**（phone_call 表结构与客户标识 join 键、call_followup 多账号语义——员工任一账号跟进即算、customer 归属字段与换人规则、员工主数据来源、群占比抽样量化混合口径偏差） | 默认值已确认，工作量缩减 | 0.5 天 |
+| Task 0 | 口径冻结：回测员工名单（3-5 名覆盖微信为主/WA 为主/群为主/高负载/低样本）+ 默认口径记录成文档（配置落库在 Task 3 种子 CLI，本任务不改代码）+ **五项核实**（phone_call 表结构与客户标识 join 键、call_followup 多账号语义——员工任一账号跟进即算、customer 归属字段与换人规则、员工主数据来源、群占比抽样量化混合口径偏差） | 默认值已确认，工作量缩减 | 0.5 天 |
 | Task 1 | 5 张表模型 + migration + 模型冒烟测试 | 6→5 张表；核实项前置完成 | 1-1.5 天 |
 | Task 2 | fact 独立计算模块（跨日精确算法，同源输出每日串聚合供宽表）+ 宽表生成（消息计数 friend 自算+串类取 fact+生命周期+通话）+ 生命周期共享函数提炼（analytics 调用点不动）+ 两条回填 CLI | **删除「_thread_stats 兼容扩展」**（不再需要）；验收含对账判据（§1.1 #4/#5）+ 写钩子零改动确认 | 2.5-3.5 天 |
 | Task 3 | scoring.py：归一化/四对比/样本保护 + 配置校验 + **默认配置 v1.0 种子落库**（受控 CLI，Task 11 快照的前置依赖） | 含 100/70 归一试算逻辑 | 2 天 |
@@ -278,7 +278,7 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
 - 下钻白名单：非法 metric_code 拒绝；
 - 幽灵员工过滤：映射不上的 owner 不进宽表。
 
-**数据核验**（3-5 名回测员工，覆盖微信为主/WA 为主/群为主/高负载/低样本）：抽查 3 日期消息与活跃客户、20 个首响串（对照 fact 明细）、10 个待回复客户、5 条通话后跟进、生命周期变化、评分展开明细；对账点增加宽表 1:1 列 ↔ msg_daily_stats friend 聚合。
+**数据核验**（3-5 名回测员工，覆盖微信为主/WA 为主/群为主/高负载/低样本）：抽查 3 日期消息与活跃客户、20 个首响串（对照 fact 明细）、10 个待回复客户、5 条通话后跟进、生命周期变化、评分展开明细；对账点增加宽表消息计数列（msg_sent/msg_recv）↔ msg_daily_stats friend 聚合——**串类列禁止相等断言**（口径差异见 §1.1 #4/#5）。
 
 **性能验收**（v1 §16.5 全部目标基础上追加）：员工列表服务质量视图 30 天窗（含 fact 窗口函数分位）p95 ≤ 1.5s。
 
@@ -306,4 +306,4 @@ message（按会话全历史，跨日精确算法）        [新 storage/first_r
 - API 通用响应约定全文：v1 §12.4；
 - 前端可视化规范全文：v1 §13.4；
 - 验收标准：v1 §19；
-- 灰度顺序/影子考核/回滚：v1 §20（其中「功能开关」按本文 §1.3 #10 替换为上线顺序控制）。
+- 灰度顺序/影子考核/回滚：v1 §20（其中「功能开关」按本文 §1.3 #11 替换为上线顺序控制）。