diff --git a/docs/superpowers/plans/2026-09-08-management-batch-a-verification.md b/docs/superpowers/plans/2026-09-08-management-batch-a-verification.md
index b79bc1f..c6e118f 100644
--- a/docs/superpowers/plans/2026-09-08-management-batch-a-verification.md
+++ b/docs/superpowers/plans/2026-09-08-management-batch-a-verification.md
@@ -372,3 +372,40 @@ action_counts 内部：`unreplied(hours=2)` **2.38s**；`churn(real,30d)` 0.12s
 | 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/敏感词扫描的真实活跃量级须在服务器侧（夜间链已跑）观察 |