yunke/docs/superpowers/plans/2026-09-08-management-batch-a-verification.md

# 批次A Task 0 核实记录：五项核实 + 回测名单

- **日期**：2026-09-09
- **方式**：`docker exec -i yunke-mysql-1 mysql -uyunke -pyunke yunke -e "<SQL>"`（容器名以 `docker ps` 实测为准，确认为 `yunke-mysql-1`）
- **用途**：本记录的全部结论直接约束批次A（数据底座）后续任务的实现细节；偏差处显式标注「影响 Task N」。任务编号引用 [2026-09-08-management-console-batch-a-data-foundation.md](./2026-09-08-management-console-batch-a-data-foundation.md)。
- **数据快照范围**：`stat_daily_staff` / `msg_daily_stats` 覆盖 20251024 ~ 20260907；`phone_call.start_call_time` 覆盖 2025-10-18 ~ 2026-09-05。

---

## ① 员工主数据（staff 表）

| 指标 | 实测 |
|---|---|
| staff 总数 | **41**（与计划假设 ≈41 一致） |
| `is_on_job=1` | 41（全部在职） |
| `wechat_account` DISTINCT user_id | 41 |
| `whatsapp_account` DISTINCT user_id | 20 |
| 微信幽灵账号（user_id 不在 staff） | **0** |
| WA 幽灵账号（补充核实） | **0** |
| `stat_daily_staff` DISTINCT user_id | 40（其 user_id 全部在 staff 内；员工 `FD685A5620184156BE75A8D73FB72F64` 无任何消息统计行） |

**结论**：账号表 → staff 无幽灵映射，`known_user_ids` 过滤（v2 §1.3 #11）零损耗，不会意外丢行。两个渠道的 account_map 产出 user_id 均能落到 staff。**无偏差，Task 5/6 按计划实现即可。**

---

## ② phone_call 列与单位

表结构关键列：`call_id`(PK)、`channel`、`start_call_time`(bigint)、`call_duration`(int)、`call_status`(int)、`incoming_call`(int)、`user_id`、`call_number`、`fetched_at`、`updated_at`。

### channel 分布

| channel | 行数 |
|---|---|
| `voice_call` | 2,504 |
| `wa_voice_call` | 686 |
| 合计 | **3,190**（与已知 3,190 条一致） |

### call_duration 单位：**秒**（确认）

| 指标 | 实测 |
|---|---|
| 总和 | 263,651 秒 = **73.24 小时**（对照已知约 73 小时，吻合） |
| 均值 | 82.65 秒（对照预期均值 ≈82 秒，吻合） |

### call_status × duration 交叉

| call_status | 行数 | duration=0 | duration>0 | 语义判定 |
|---|---|---|---|---|
| 1 | 1,508 | 31 | 1,477 | **接通**（含 31 条 0 秒即挂） |
| 2 | 1,682 | 1,682 | 0 | **未接通**（未接/拒接/取消，与方向无关） |

### incoming_call 分布

| incoming_call | 行数 | 语义 |
|---|---|---|
| 1 | 1,764 | 呼入 |
| 0 | 1,426 | 呼出 |

### start_call_time：**毫秒 epoch**（确认）

13 位整数；`FROM_UNIXTIME(x/1000)` 解出 max = 2026-09-05 16:00:55（合理近期），按秒解释则超范围。min = 2025-10-18。与 `message.timestamp` 毫秒同口径。

### call_number 形态（按 channel 完全可分）

- `voice_call` → 微信 ID：`wxid_*` 或自定义微信号（`csf7169708`、`yuanye751380`、`Maple_1988` 等）
- `wa_voice_call` → WA JID：`2348182388888@s.whatsapp.net` 等

### 与计划默认假设的偏差（重要）

1. **计划假设 #4「PhoneCall.channel 是通话类型（phone_call/voice_call）非消息渠道」不完全成立**：实测无 `phone_call`（蜂窝）值，且 `wa_voice_call` **能**从 channel 列判别 WA。计划 Task 5 注释「voice_call 行无法从列判别微信/WA」不成立。**影响 Task 5**：`_followup_exists` 可按渠道收窄——`voice_call` 只查该员工 wechat 账号的 1:1 消息、`wa_voice_call` 只查 whatsapp 账号（当前双渠道任一匹配的写法也不会错——wxid 不会撞 WA JID，仅多一次无效查询；收窄属优化非必需）。
2. `call_duration` 单位=秒、`start_call_time`=毫秒 epoch：**与计划默认一致，Task 5 无需换算**（`day_bounds_ms` 直接用）。
3. 接通判定：计划默认 `duration>0`。实测 `call_status=1 AND duration>0` = 1,477 行，`duration>0` 口径与之差 31 行（31 条接通但 0 秒，占 1.0%）。**影响 Task 5**：`answered=dur>0` 口径可用；若追求语义精确可改 `call_status=1`（含 0 秒接通），差异 ≤1%，实现时任选其一并在表注释写明。

---

## ③ customer 归属字段填充率

| 指标 | 实测 |
|---|---|
| 总行数 | 16,339 |
| `user_id` 填充 | 16,339（**100%**） |
| `owner_account_id` 填充 | 16,339（**100%**） |
| `delete_flag=1` | 53 |

分渠道：wechat 7,040（owner 填充 7,040）/ whatsapp 9,299（owner 填充 9,299）。

### 两条归属路径一致性（全表校验，非抽样）

`customer.user_id` vs `owner_account_id → wechat_account.wx_id / whatsapp_account.uid → user_id`：

| 渠道 | 校验行数 | 一致 |
|---|---|---|
| whatsapp | 9,299 | 9,299 |
| wechat | 7,040 | 7,040 |

**结论**：两条路径 100% 等价、零冲突。生命周期归属覆盖面完整。**影响 Task 6**：默认 `owner_account_id → account_map → user_id` 路径确认可用；`customer.user_id` 列可直接当冗余等价路径使用（如需省一次 join，实测安全）。

补充观察（**影响 Task 3/6 的 peer 对齐**）：**微信侧主体是无后缀裸 ID，后缀形态是少数**。`customer.friend_id` 实测形态分布（全表）：

| 渠道 | 形态 | 行数 | 占比 |
|---|---|---|---|
| wechat | **无后缀裸 ID**（`a_515855826`、`a053136a` 等） | 6,779 | **96.3%** |
| wechat | `@openim` 后缀 | 261 | 3.7% |
| whatsapp | `@s.whatsapp.net` | 9,266 | 99.6% |
| whatsapp | `@lid` 后缀 | 33 | 0.4% |

`message.talker_id` 侧同查（行数口径）：wechat 裸 ID 844,287 / `@openim` 16,873 / `@chatroom` 17,003（群）；whatsapp `@s.whatsapp.net` 72,357 / `@lid` 4,284 / `@g.us` 9,439（群）。即：微信 peer 主键以裸 ID 为准、`@openim` 为少数共存；WA 侧基本全带后缀。Task 3 实现 peer 匹配时按实测形态对齐（两边原值相等才命中），不做猜测性截断/补后缀。

---

## ④ 群占比（msg_daily_stats，量化混合口径偏差）

| channel | peer_kind | 行数 | 消息量(send+recv) | 会话线程(cust_threads) |
|---|---|---|---|---|
| wechat | friend | 38,343 | 269,074 | 82,879 |
| wechat | room | 16,234 | 609,089 | 26,220 |
| whatsapp | friend | 11,673 | 77,994 | 14,178 |
| whatsapp | room | 866 | 8,086 | 1,402 |
| **合计** | | **67,116** | **964,243** | **124,679** |

占比汇总：

| 维度 | room 占比 | 说明 |
|---|---|---|
| 微信消息量 | **69.4%**（609,089/878,163） | 微信消息近七成来自群 |
| WA 消息量 | 9.4%（8,086/86,080） | WA 几乎纯 1:1 |
| 总消息量 | **64.0%**（617,175/964,243） | |
| 总会话线程 | **22.2%**（27,622/124,679） | |

**结论**：若现有看板首响/回复率不分 `peer_kind`，消息量维度被群污染 64%、线程维度 22%——污染主要来自微信侧（微信消息 69% 是群消息）。批次A `first_reply_fact` / `employee_metric_daily` 强制 `peer_kind='friend'` 过滤是必要的，不能沿用混合口径。

---

## ⑤ call_followup join 键（call_number ↔ message.talker_id，1:1 消息）

| channel | 分母（call_number 非空） | 命中（talker_id 匹配且非群消息） | 命中率 |
|---|---|---|---|
| `voice_call` | 2,504 | 2,378 | **95.0%** |
| `wa_voice_call`（补充核实） | 686 | 681 | **99.3%** |

**结论**：双渠道命中率均远超 50% 阈值，`call_followup_count` 一期**高置信**，无需降级标记、无需在口径中注记低置信。**影响 Task 5**：24h 跟进判定按计划实现。未命中成因已精确解释（复核补充）：`voice_call` 的 126 条未命中**恰好等于** `call_number` 带 `@chatroom` 后缀的 126 条群通话（实测这 126 条对 1:1 消息全部 0 命中——join 限定 `room_id` 为空，群通话本就不该匹配）；剔除群通话后 1:1 可匹配通话命中率为 **2,378/2,378 = 100%**。`wa_voice_call` 侧后缀分布为 `@s.whatsapp.net` 676 / `@g.us`（群）9 / `@lid` 1，未命中 5 条**全部为** `@g.us` 群通话（逐条列出验证）。

---

## 回测员工名单

选取依据：消息量/WA 量/活跃群排名 + 低样本端（见文末各候选分渠道数据）。覆盖：微信为主、WA 为主、群运营为主、高负载、低样本（前三类与高负载有合并）。

| # | user_id | 名字 | 覆盖类型 | 关键数据（20251024~20260907） |
|---|---|---|---|---|
| 1 | `369D257EEC9A4357935FDE19DDD99CAA` | 王云青 | **高负载 + 群运营为主 + 微信为主**（合并） | 消息量 #1（162,740：微信 162,371 / WA 369）；活跃群 #1（4,036）；通话 431+9 |
| 2 | `9C0B195A2C234C829FF507E011B4B460` | 田瑞志 | **WA 为主** | WA 消息 9,986 / 总 11,597 = 86%；WA 通话 28 |
| 3 | `F99F6557C2904A7E8F4C5A3BD8A597A1` | 张士蓓 | **双通道混合**（WA 量 #1，群 #2） | 微信 91,936 + WA 12,529；活跃群 2,273；通话最多（471 微信 + 97 WA） |
| 4 | `DC48798A5EA24DBB8B31A89CB858E08B` | 15639270965 | **纯微信无 WA 行**（验证 WA 缺失路径） | 微信 78,680，`stat_daily_staff` 无 whatsapp 行；通话 3 |
| 5 | `946C08639BF84DFEBBF5EC2A607AE1FA` | 18539430257 | **低样本**（验证空数据路径） | 消息 8 条，无群、无通话、无 WA |

> 名单中的 #1/#3 建议作为 Task 8「本地全量回填实测」的 2 名回测员工（数据最厚、双通道+通话+群全齐）。

---

## 偏差汇总（对后续任务的约束清单）

| # | 偏差/确认 | 影响 |
|---|---|---|
| 1 | `phone_call.channel` 实测仅 `voice_call`（微信）/`wa_voice_call`（WA）两值，**无蜂窝 `phone_call` 值**；channel 可判别渠道，计划「无法从列判别微信/WA」结论修正 | Task 5（followup 可按渠道收窄，属优化非必需） |
| 2 | `call_duration` 单位=**秒**（263,651s=73.24h≈已知 73h）；`start_call_time`=**毫秒 epoch** | Task 5（默认口径正确，无需换算） |
| 3 | 接通判定 `dur>0` vs `call_status=1` 差 31 行（1.0%），前者少计 31 条 0 秒接通 | Task 5（任选其一，注释写明） |
| 4 | `customer.owner_account_id` 填充 **100%**，与 `user_id` 列全表 100% 等价 | Task 6（默认 owner 路径确认；可直接用 user_id 列省 join） |
| 5 | 微信侧 peer ID **主体为无后缀裸 ID**（customer.friend_id 6,779/7,040=96.3%；message.talker_id 行数口径 844,287 裸 vs 16,873 `@openim`），后缀形态（`@openim` 等）为少数；WA 侧基本全带后缀（`@s.whatsapp.net`/`@lid`） | Task 3/6（peer 对齐按实测形态原值匹配，勿截断/勿补后缀） |
| 6 | 群消息占总消息量 64%（微信侧 69%） | Task 3/6（friend 过滤必须，佐证 spec 口径） |
| 7 | call_number↔talker_id 命中率 voice_call 95.0% / wa_voice_call 99.3% | Task 5（call_followup_count 高置信，不降级） |
| 8 | staff 41 行无幽灵账号；`stat_daily_staff` 仅 40 名员工有行 | Task 5/6（known_user_ids 过滤零损耗） |

---

# 批次A回填实测与对账（Task 8，2026-09-09）

- **环境**：本地 Docker MySQL（`yunke-mysql-1`），数据快照同上（stat/msg 覆盖 20251024~20260907）。
- **方式**：Task 7 真机全量回填后本任务只读对账抽查（未重跑回填）；对账前全库同源校验复验一次，确认库状态即 Task 7 收尾状态。

## 1. 回填实测汇总（Task 7 真机数字，Task 8 复验）

| 项目 | 实测 |
|---|---|
| `first-reply-facts` | 11,020 会话 → **68,476** fact 行，**72s**（冷） |
| `employee-metrics` | **12,371** 宽表行（day×channel×user）+ **1,163** 通话行（**314** 天并集），**71s** 冷 / 36s 热 |
| 幂等复跑 | 两命令复跑结果一致（delete+insert 语义，无重复无漂移） |
| 全库同源 | `SUM(employee_metric_daily.threads_answered)` = **68,476** ≡ fact 行数（Task 8 复验通过） |
| 孤儿检查 | 宽表/通话表 user_id 不在 staff = **0**；fact 账号不在对应渠道账号表 = **0**（Task 8 复验通过） |
| 通话日并集修复 | `employee_call_daily` 覆盖 **314** 天（修复前 306）：8 个消息空窗日找回 27 通话 / 13 接通 |

## 2. 对账抽查（2 员工 × 3 日期 × 三组）

员工取自本文回测名单：**王云青** `369D257EEC9A4357935FDE19DDD99CAA`（#1，高负载+群运营，混合口径差异最大场景；1 微信 + 2 WA 账号）、**田瑞志** `9C0B195A2C234C829FF507E011B4B460`（#2，WA 为主；1 微信 + 2 WA 账号）。日期 20260815 / 20260801 / 20260601（近/中/远）。跨渠道员工按 channel 分别对账（①②组逐渠道逐日须一致）。

判定标准：**①组（消息计数列 ↔ msg_daily_stats friend 聚合）与 ②组（串类列 ↔ fact 行数）必须逐日一致；③组（宽表串类 cust_threads ↔ 日切 stat_daily_staff.cust_threads）允许差异，差值=跨夜串归属效应。**

### 王云青

| 渠道 | 日期 | ① mds sent/recv | ① 宽表 sent/recv | ① 判定 | ② fact 行 | ② 宽表 answered | ② 判定 | ③ 宽表 threads | ③ 日切 threads | ③ 差值 |
|---|---|---|---|---|---|---|---|---|---|---|
| wechat | 20260601 | 186 / 177 | 186 / 177 | ✅ | 76 | 76 | ✅ | 76 | 121 | 45 |
| wechat | 20260801 | 0 / 38 | 0 / 38 | ✅ | 0 | 0 | ✅ | 0 | 16 | 16 |
| wechat | 20260815 | 0 / 23 | 0 / 23 | ✅ | 0 | 0 | ✅ | 0 | 17 | 17 |
| whatsapp | 20260601 | （无行） | 0 / 0 | ✅ | （无行） | 0 | ✅ | 0 | （无行） | — |
| whatsapp | 20260801 | 0 / 1 | 0 / 1 | ✅ | 1 | 1 | ✅ | 1 | 1 | 0 |
| whatsapp | 20260815 | 0 / 4 | 0 / 4 | ✅ | 1 | 1 | ✅ | 1 | 2 | 1 |

### 田瑞志

| 渠道 | 日期 | ① mds sent/recv | ① 宽表 sent/recv | ① 判定 | ② fact 行 | ② 宽表 answered | ② 判定 | ③ 宽表 threads | ③ 日切 threads | ③ 差值 |
|---|---|---|---|---|---|---|---|---|---|---|
| wechat | 三日期均 | （无行） | 0 / 0 | ✅ | （无行） | 0 | ✅ | 0 | （无行） | — |
| whatsapp | 20260601 | 1 / 1 | 1 / 1 | ✅ | 1 | 1 | ✅ | 1 | 1 | 0 |
| whatsapp | 20260801 | （无行） | 0 / 0 | ✅ | （无行） | 0 | ✅ | 0 | 2 | 2 |
| whatsapp | 20260815 | （无行） | 0 / 0 | ✅ | （无行） | 0 | ✅ | 0 | （无行） | — |

注：「无行」= 源表该 (渠道, 日) 无该员工数据，宽表记 0/0——一致。20260601 无 WA 数据未换日期：田瑞志 whatsapp 该日恰好有 1 条收发（对账有效），王云青 whatsapp 全期仅 369 条消息、无行属真实分布。

**结论：①②组 12/12 逐日全部一致（含渠道拆分）；③组宽表全部 ≤ 日切值。**

## 3. 跨夜串差值观察（③组差异解释）

- **归属语义**：宽表串按「串末条客户消息所在上海自然日」归属（`first_reply_facts.compute_conversation`）；日切表按「当日有客户消息的 peer 数」计。串末条必在归属日当天 ⇒ 结构上保证 ③组逐日 宽表 ≤ 日切，差值=归属到其他日终了的跨夜/多日串。
- **差值形态**：王云青 wechat 三日差 45/16/17——该员工深夜消息多（20260801/15 发送 0、仅收 38/23 条，客户消息跨零点后串归属顺延）；whatsapp 差 0/1。田瑞志 whatsapp 20260801 差 2（2 个 peer 当日来消息但串末条在次日）。
- **串未丢失验证**：王云青 wechat 全期 宽表 12,055 threads（11,930 answered，314 天）vs 日切 20,981（14,647 answered，312 天）——串模型把多日串折叠为 1（比值 57.4%），且抽查 20260814~31 逐日，日切 17 线程的 20260815 对应串终落在真实结束日（0819=8、0821=10、0828=9），无凭空丢失。
- 另：宽表 `cust_threads ≥ threads_answered`（如王云青 wechat 20260602 = 54/52）——未闭合尾串计入分母不产 fact 样本，与算法注释一致。

## 4. 批次A验收清单（Task 8 收尾核对）

| # | 项 | 状态 | 依据 |
|---|---|---|---|
| 1 | 6 张表本地存在，migration 幂等 + downgrade 干净 | ✅ | Task 2（迁移 `b7c8d9e0f1a2`，alembic head 实测一致；表实测在库：first_reply_fact / employee_metric_daily / employee_call_daily / employee_score_config / employee_score_snapshot / management_followup） |
| 2 | first-reply-facts 全量回填成功且复跑幂等 | ✅ | Task 7（本文 §1） |
| 3 | employee-metrics 全量回填成功且复跑幂等 | ✅ | Task 7（本文 §1） |
| 4 | 跨夜串判别测试通过 | ✅ | Task 3（test_first_reply_facts.py 恰 12 例，Task 8 复跑全绿；含跨夜/多日串/同毫秒并列） |
| 5 | friend-only 口径判别测试通过 | ✅ | Task 6（test_all_friend_pairs_only_friend + 宽表 friend 过滤判别例） |
| 6 | 同源判别测试通过 + 全库 SUM 验证 | ✅ | Task 3/6；全库 68,476 ≡ 68,476（本文 §1 复验） |
| 7 | 幽灵员工过滤测试通过 | ✅ | Task 5/6；孤儿=0（本文 §1 复验） |
| 8 | 对账抽查 ①②一致、③差异可解释 | ✅ | 本文 §2/§3 |
| 9 | 全量测试套件绿 | ✅ | **653 passed in 62s**（Task 8 本机实跑，2026-09-09） |
| 10 | 核实文档完整 | ✅ | 本文补齐 |
| 11 | 写钩子零改动 | ✅ | 批次A全部 17 个 commits（27f91e5→0fce21a）逐一核查，无一触碰 storage/summary.py、storage/repos.py（repos.py 最近一次改动 d428953 属 customer_account_link 工作线，先于批次A） |

---

# 批次B冒烟（Task B5，2026-09-09）

经营管理后台六端点真机冒烟 + 性能初测。回测员工王云青 `369D257EEC9A4357935FDE19DDD99CAA`（#1 高负载+群运营），窗口 30 天 `20260810~20260908`。

## 0. 环境与启动方式

- **基线**：`pytest tests/ -q` → **721 passed in 60.9s**（批次B收尾后全绿）。
- **后端启动**：docker 无 `yunke-backend/frontend-1` 容器；冒烟前 8000 端口空闲（连接拒绝，无常驻进程）。本任务自起：`yunke-server/.venv/Scripts/python.exe -m uvicorn app.api.main:app --port 8000`（无 `--reload`），`GET /api/health` → `{"status":"ok"}`；`openapi.json` 含 management 路由（grep 命中）确认新代码已加载。
- **鉴权模式**：`.env` 中 `API_TOKEN=`（空值）→ 鉴权中间件 no-op，**免鉴权直接 curl**（无 Authorization 头）。
- **进程处置**：uvicorn 留跑供用户查看，Git Bash PID **2423**（`kill 2423` 关闭；或任务管理器结束对应 python.exe）。

## 1. 六端点结果（HTTP 码 × 耗时 × 大小）

首次访问含冷启动（连接池/查询编译/InnoDB 冷缓存），dashboard 另测暖态三次：

| 端点 | HTTP | 首次耗时 | 暖态耗时 | 大小 | 判定 |
|---|---|---|---|---|---|
| `/api/management/dashboard` | 200 | 12.03s | **2.92 / 2.39 / 2.18s** | 22,309B | ⚠️ 超 1.5s 目标（慢段定位见 §2） |
| `/api/management/employees?page_size=50` | 200 | 0.34s | 0.30 / 0.31s | 58,865B | ✅ ≤1.5s |
| `/api/management/employees/{王云青}` | 200 | 0.40s | — | 4,739B | ✅ |
| `…/metrics?section=service` | 200 | 0.40s | — | 4,655B | ✅ |
| `…/drilldown?metric_code=first_reply_p90` | 200 | 0.016s | — | 5,268B | ✅ |
| `/api/management/metric-definitions` | 200 | 0.005s | — | 4,081B | ✅ |

## 2. dashboard 慢段定位（分段实测，不做优化——决策归批次F）

用 app 同一 session 复放 dashboard 组装流水线逐段计时（合计 2.685s ≈ 暖态端点耗时）：

| 段 | 耗时 |
|---|---|
| load_score_config | 0.044s |
| assemble_employees（评分+异常，2 窗聚合） | 0.262s |
| wide_daily_rows / call_daily_rows | 0.007s / 0.002s |
| service_daily_trend | 0.032s |
| data_as_of | 0.009s |
| **action_counts（unreplied+churn+sensitive）** | **2.328s** |

action_counts 内部：`unreplied(hours=2)` **2.38s**；`churn(real,30d)` 0.12s；sensitive count 0.005s。unreplied 再拆：候选窗口函数查询（row_number over 67,116 行 friend 分区 → 3,123 候选）仅 **0.10~0.16s**；>500 候选走「仅本页决赛圈」分支无 N+1，但**单条尾部消息点查耗时 1.7~1.9s**。EXPLAIN 实证：`channel=None`（全平台）时无法使用 channel 打头的全部索引（`ix_message_channel_owner_talker_time(channel,owner,talker,timestamp)` 等），优化器退化到 `ix_message_room`（`room_id IS NULL/''`）→ **扫 378,202 行 + filesort**（message 表 96.4 万行）。

优化方向（供批次F选择）：① 查询改写按渠道 UNION/`channel IN (…)` 绑定前缀走现有索引；② 补 `(owner_account_id, talker_id, timestamp)` 无 channel 前缀索引；③ dashboard 对 action_counts 做短 TTL 缓存。除 unreplied 外全链路 <0.5s，达标无压力。

## 3. 合理性抽查

- **employees 列表**：`total=41`/rows=41（=本文① staff 总数 ✓）。**王云青行与宽表 SQL 聚合逐字段全等**：msg_sent=111 / msg_recv=1003 / cust_threads=89 / threads_answered=57 / fr_sum_ms=698,140,844、days_with_data=29。数量级说明：「千级」预期对应全期全口径（全期 162,740 条消息/12,055 串，群聊为主）；本窗 friend 口径 recv=1003 千级 ✓，sent=111 为真实分布——同窗全口径 recv≈2.0 万（stat_daily_staff 实测） vs friend 1,003，差额几乎全是群消息；cust_threads=89 是串模型多日串折叠（本文 §3 已验证折叠比 57.4%）+本窗 friend 活动偏低。
- **dashboard kpis**：active_employees=**40**（~40 ✓，=本文① stat 有数员工数）、active_customers=2,195、msg_total=42,422、cust_threads=9,330、answered=8,460、call 263/接通 113；lifecycle new/cooling/dormant/reactivated=231/1,432/3,353/145。**anomalies=28（critical 3 / warning 25）**，首条 `reply_p90_worsened` critical：P90 324.98min vs 基线期 18.06min（+1700%，样本 62、涉及 51 客户）。dimension_summary：risk/action 全 41 pending（批次C接线，符合预期），service scored 27/insufficient 4/pending 10、均分 56.0。趋势 30 点，末日 20260908 全零——数据止于 20260907（本文快照范围），边界正确。
- **detail（王云青）**：`score.trial=true` ✓、grade=**E**（total=39，scored 非 insufficient）、dimensions：risk/action **pending** ✓（批次C）、service 47.8 / customer 0.0 / workload 100；含 accounts/prev/baseline/anomalies。
- **metrics section=service**：数值与宽表窗聚合一致 + trend 30 点 ✓。
- **drilldown first_reply_p90**：total=**57**=该员工账号窗内 fact 行数（=threads_answered ✓）。首行 fr_ms=**498,242,238ms≈5.8 天**——超「分钟~小时」预期，但与源表全等（fact MAX 同值）；窗内全库更极端值达 1,617,406,247ms≈18.7 天（thread_end 08-14 → reply 09-02，沉睡客户复活串），属真实数据形态非计算缺陷。该员工 p50=97,153ms（1.6min）/p90=1,651,758ms（27.5min）分钟级 ✓。极值是否 winsorize/封顶归批次F口径决策。
- **metric-definitions**：19 项定义（msg_sent…call_followup_rate）+ score_config + caliber_notes，`config_source="db"`（评分配置 v1.0 种子生效 ✓）。

**结论：六端点全 200、数据与库逐字段可对；唯一性能缺口=dashboard 的 unreplied 行动计数（channel 无前缀索引可用），暖态 2.2~2.9s，其余端点全部达标。**

## 4. 批次B遗留观察项归档（终评补录，2026-09-09）

| # | 项 | 归档 |
|---|---|---|
| 1 | call_band 样本基数：band 类指标样本量取 active_friends（规格字面），WA 通话量上来后"通话多客户少"员工会被误标 insufficient——当前数据零影响（实测 calls≥1 且 af<10 仅 5 人且 calls≤5，怎么选都不足）；归批次F回测前一行修正（sample_basis 字段或按源指标取样本） |
| 2 | 配置源名唯一性：两个 code 指向同一源指标会使 employees comparisons 键静默覆盖——已在 validate_config 加源名唯一校验+测试（批次B终评闭环），默认配置六个源名互异不受影响 |
| 3 | dashboard 性能（2.2~2.9s，unreplied channel=None 无前缀索引）与 fr_ms 天级极值 winsorize：见上文 §2/§3，决策归批次F |

---

# 批次D走查与验收（Task D4，2026-09-10）

批次D收尾：员工总览（b72e957）+ 员工详情（5776175）+ 驾驶舱环比/异常跳员工闭环（422a726，前置接口/时间预设 ddeda3f）。Playwright 真机七步全链路走查 + v1 §19.1 员工子集与批次D验收清单逐项核对。环境：后端 uvicorn 8000（免鉴权）+ 前端 vite dev 5173，视口 **1366px**。

## 0. 四门禁（全绿）

| 门禁 | 结果 |
|---|---|
| 后端 `pytest tests/ -q` | **723 passed** in 65.29s |
| 前端 `npm run build` | ✓ built in 1.03s（exit 0） |
| 前端 `npm run test`（vitest） | Test Files 2 passed / **Tests 23 passed** |

## 1. 七步动线走查记录（数字为真机实测，关键值已对 API 复核）

**① 驾驶舱默认近30天（20260812~20260910）**：三 KPI 卡环比箭头 ✓（客户端自 prev_kpis 按 (cur-prev)/prev 计算，API 复核数值吻合）——全渠道：活跃客户 **1,992人 ↓12.6%**（prev 2,278）/ 活跃员工 **40人 →0.0%**（40/40）/ 消息量 **37,742条 ↓21.0%**（prev 47,749）；切微信：**979人 ↓25.3% / 40人 ↑2.6% / 27,949条 ↓29.6%**。方向与量级合理（等长紧邻前窗）。

**② 异常卡员工名 → 员工详情**：点微信异常榜员工名链接（落点须为 a.el-link；整行点击触发行下钻抽屉，属预期交互）→ 落地 `/management/employees/18B5EE6B1AD94B15A5CD1CDABCECAB96?channel=wechat&start=…&end=…`（驾驶舱当前筛选 query 随行 ✓）。

**③ 员工详情（朱晨曦，综合 21/E）**：五维条 **3 实 + 2 待数据**——合规风险/行动执行 pending 灰条占位，服务质量 0 分/客户经营 0 分/有效负载 100 分（API dimensions 逐项一致；行序随接口返回序，见遗留①）。四对比表（当前/上期/基线/中位）✓（cust_threads 62/114/107+中位）。服务质量页签双折线渲染（canvas 1074×300）→「查看超时明细」→ 首响P90 抽屉 **Total 11** → 点行进聊天：**17 条消息**，时间线与所点明细行吻合（客户 08-31 11:59:12 → 回复 17:24:11 ≈ 5小时24分）。

**④ 客户经营页签**：返回列表再进 → section=customer →「沉睡客户名单」抽屉 **Total 89** ✓。

**⑤ 员工总览对比**：勾选 2 人 → 对比抽屉并列两列指标 ✓（2-5 人为按钮启用门槛），关闭复原。

**⑥ 排序+翻页+CSV（微信渠道）**：综合分降序（服务端 sort）——第 1 页 **55→21**（林峰 55 领头），第 2 页 **11 / 1 / 其余「--」**（18 人 insufficient_sample **空值排尾** ✓）。导出 CSV：**3 行口径前言**（口径/窗口+渠道/试算版本）**+ 表头 + 41 行数据**，toast「已导出 41 条」。

**⑦ 控制台与持久化**：走查全程 console **0 errors**；修复遗留告警后（见 §3）全新加载 **0 warnings**。刷新保持 ✓——列表 view=service 刷新还原（Total 41）、详情返回后 section=service 还原。

**附**：9 档时间预设逐一真机核验：今日 0910~0910 / 昨日 0909 / 近7 0904~0910 / 近30 0812~0910 / 本周 0907~0910（周一周首 ✓）/ 上周 0831~0906 / 本月 0901~0910 / 上月 0801~0831 / 自定义 0901~0907。1366px 驾驶舱与员工总览双页截图目检：KPI 3×2 网阵、双趋势图、表格列均无塌陷/无横向溢出。

## 2. 验收清单核对

**v1 §19.1 员工子集（6 项）**

| # | 项 | 状态 | 依据 |
|---|---|---|---|
| 1 | 能查看所有员工多维状态 | ✅ | total=41（API=列表=CSV 行数三方一致）；四视图（管理概览/工作负载/服务质量/客户经营）切换正常 |
| 2 | 任一分数可展开为指标/公式/样本/事实 | ✅ | 表头「?」→ 指标口径抽屉（19 项定义+公式+样本）；行/详情下钻按钮 → 事实明细 → 聊天原文（§1 ③） |
| 3 | 四对比 | ✅ | 详情四对比表逐列可见（§1 ③：62/114/107/中位） |
| 4 | 样本不足不评分 | ✅ | 18 人 insufficient_sample 综合分显「--」（§1 ⑥），CSV 同口径 |
| 5 | 异常两次点击进事实 | ✅ | 异常卡员工名（第1击）→ 详情下钻按钮（第2击）→ 事实明细/聊天 |
| 6 | 默认排序非总分/消息量榜 | ✅ | 默认 sort_by=anomaly_severity（异常严重度优先） |

**批次D验收清单（5 项）**

| # | 项 | 状态 | 依据 |
|---|---|---|---|
| 1 | 员工总览：41 人四视图/服务端排序分页/keyword/对比 2-5 人/CSV 含口径注释 | ✅ | §1 ⑤⑥；CSV 前言 3 行 |
| 2 | 员工详情：五维条 3+2 占位/五页签懒加载/四对比/评分明细可展开/下钻进抽屉/账号跳聊天 | ✅ | §1 ③④；页签懒加载+loaded 缓存+section URL 还原 |
| 3 | 驾驶舱：三 KPI 环比箭头/异常卡可跳员工详情 | ✅ | §1 ①②（闭环打通） |
| 4 | 时间预设全套 9 档 | ✅ | §1 附 |
| 5 | URL 全参数保持；四门禁绿；后端仅 dashboard 一处小改且测试补齐 | ✅ | §1 ⑦ + §0；后端改动=dashboard prev_kpis（D3，随测试提交） |

## 3. 走查发现并修复（随本任务提交）

| 问题 | 修复 |
|---|---|
| `AnomalyList.vue` 员工链接 `:underline="false"` 触发 Element Plus 废弃 API 告警——驾驶舱每次加载刷 **31 条** `[el-link] underline boolean deprecated`（异常榜每行一条） | 改 `underline="never"`（string API）；修复后全新加载 0 errors 0 warnings |

## 4. 遗留观察项（不阻塞）

| # | 项 | 归档 |
|---|---|---|
| 1 | 五维条行序随接口返回序 | 合规风险/行动执行（待数据）排在三实维之前——非固定语义序；批次E 接线 risk/action 后自然消解，如需固定序前端按 dim 顺序数组排即可 |
| 2 | 走查任务字面 Step6 措辞偏差 | 「切视图服务质量→点综合分列排序」按字面不可执行（综合分列仅管理概览视图有）；实际动线=管理概览排序→切服务质量视图导出，已按实际动线完成走查 |
| 3 | 空值显示 `-` 与 `--` 混用 | format.ts 的 formatMsDuration/formatRatio 按各自注释约定 null 显 `-`，员工总览本地数值/比率格式化显 `--`——同表跨列观感不一；纯观感项，批次E 顺手统一即可 |

---

# 批次F-调度接入验证（Task F3，2026-09-10）

F1（`_analytics_tick` 段2 管理域滚动，0dc5993）/ F2（夜间链管理步，2ac63e3）已提交后，本地真机直调 tick 验证 + 本地 scheduler 镜像重建。方法：临时脚本（已删）按 tests/test_scheduler_analytics_tick.py 的构造方式 `SyncScheduler(engine=create_async_engine(get_settings().db_url), session_maker=...)`，不 start、只 `await scheduler._analytics_tick()`，对六个上游函数挂计时包装（与测试 monkeypatch 同一延迟 import 打点位），连跑两次。

## 1. tick 两段实测（本地真机库，连跑两次）

| 段 | 内容 | 第1次（冷） | 第2次（暖） |
|---|---|---|---|
| 总计 | `_analytics_tick` 全程 | **2.78s** | **0.74s** |
| 段1 | recompute_days（staff 滚动3天） | 0.86s | 0.15s |
| 段1 | scanner.run_incremental（敏感词增量） | 0.14s | 0.02s |
| 段2 | pairs_active_in_days（fact 活跃对发现） | 0.04s | 0.02s |
| 段2 | recompute_pairs（fact 重算） | 0.00s | 0.00s |
| 段2 | recompute_metric_days（宽表滚动3天） | 1.51s | 0.52s |
| 段2 | recompute_call_days（通话滚动3天） | 0.22s | 0.02s |

（段值不含各自 session.commit；日志输出：`staff_days=0 scanned=10 hits=0` + `mgmt fact_pairs=0 wide_rows=168 call_rows=0`，两次一致。）

- **远低于 <60s 预算**。本地镜像已停同步 7 天，滚动窗（0908~0910）内无消息/通话活动——`staff_days=0`、`fact_pairs=0`、`call_rows=0` 属停同步后的数据真空而非缺陷；`wide_rows=168`= 3 天 × 56 行/天（39 员工，wechat 38 + whatsapp 18 行/天，双渠道员工两行），宽表对零活跃员工照常出零值行。段2 主成本=宽表重算，随员工数×天数扩展而非会话数，服务器侧活跃会话数百的形态下同量级。
- **幂等 ✓**：三表行数跑前 fact=68,476 / wide=12,371 / calls=1,163 → 第1次后 68,476 / **12,539** / 1,163 → 第2次后 68,476 / 12,539 / 1,163。wide 的 +168 为首跑补齐：0908~0910 三天行在表内原本不存在（本地夜间链停摆 7 天没写过），第1次 DELETE+INSERT 补齐后第2次行数纹丝不动——滚动窗语义下幂等成立。

## 2. 本地 scheduler 容器重建（范围仅本地；服务器镜像 2026-09-09 已重建不碰）

- `docker compose up -d --build scheduler`：镜像 `yunke-scheduler:latest`（`ded96dfc9625`，2026-09-10 构建）重建成功，容器 recreate + 起来。
- 冒烟：`docker exec yunke-scheduler-1 python -c "import app.sync.scheduler"` → ok；容器日志确认 **4 个 job 全注册**——3×`_safe_page_run`（full/messages/full-history）+ **`SyncScheduler._analytics_tick`（F1 新 job 已进夜间/4h 链）**，"Scheduler started" 正常。
- **调度状态**：验证完即 `docker stop`——重建前容器本就 Exited 7 天（本地不跑调度，避免与服务器调度器双跑同刷云客触发风控），维持 stopped 现状；容器已绑新镜像，用户随时 `docker compose start scheduler` 即以新代码上线。mysql/redis 未动。

## 3. 已知边界（归档）

| # | 项 | 说明 |
|---|---|---|
| 1 | phone_call 未进页面同步链 | 通话小表（employee_call_daily）暂从既有静态源重生成——本地 call_rows=0 即此边界的体现；审计 P0-5 由并行会话领地，不在此处理 |
| 2 | 补同步历史日期 | tick 只滚动当日+前2天；更早日期的修正由夜间全量（full_sync 汇总/管理步）覆盖语义兜底 |
| 3 | 本地数据真空 | 本地镜像停摆 7 天，0908~0910 无消息/通话——fact/敏感词扫描的真实活跃量级须在服务器侧（夜间链已跑）观察 |