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。
• 数据快照范围：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