docs(plan): 记录 P1a 生产上线结果与首轮数据结论

按施工单三段走完并验证：调度器启动、手动 50 条观察无风控、启用后调度器自动
接管（12:27:26 跑完 200 条 / 22 秒 / next_run_at 按 tick 推进）。

记录两点供后续参考：
- 上线过程中抓到两个只有生产才暴露的问题（MySQL 不认 NULLS FIRST、compose 的
  environment 是显式列表导致 .env 新增变量传不进容器），均已在 C.2 记档；
- 首轮 100% invalid 属正常且是价值所在：选行「从没检测过的优先」，而积压的
  1,897 条多为 2026-08-04 批量导入、从未尝试登录、CK 已两个月的陈旧账号，
  斗鱼侧统一回「用户未登录」，非风控。客服页会突然出现大批失效账号，属预期。

docs/自动化与资料收集规划.md

@@ -365,6 +365,25 @@ lookup_order(order_no) -> {
 > `tests/test_automation_ck_health.py`（22 条）。
 > 端到端已用 3 个真实账号验证：巡检结果与直接检测逐条一致，且 `cookie` / `status` / `message` / `attempt_status` 全程未变。
 
+**生产上线记录（2026-10-02）**
+
+按三段走完，全部通过：
+
+| 段 | 动作 | 结果 |
+| --- | --- | --- |
+| ① | `AUTOMATION_ENABLED=true` + 重启 | 容器内变量生效，日志「自动化调度器已启动，tick=300s」 |
+| ② | 手动跑一轮（每轮 50 条，作业开关仍关） | `success`，50 条 / 7 秒，**斗鱼无风控反应**（无验证码、无频控、无超时） |
+| ③ | 每轮 200 条 + 打开作业开关 | 调度器自动接管：12:27:26 → 12:27:48 跑完 200 条（22 秒），`next_run_at` 按 tick 推进到 +5 分钟 |
+
+**上线过程中抓到（并已修）两个只有生产才会暴露的问题**，都已在 §C.2 记档：
+
+1. `NULLS FIRST` 在 SQLite 合法、**MySQL 报 1064** → 改用 `col IS NULL DESC`，并加了一条按 MySQL 方言 `compile()` 的回归测试；
+2. compose 的 `environment:` 是**显式列表**，只写 `.env` 不会传进容器 → `AUTOMATION_ENABLED` 起初根本没生效（顺带发现早先写入的 `ORDER_SITE_*` / `OSS_*` 也全都没传进去）。
+
+**首轮数据结论（供客服侧预期管理）**：前几轮 100% `invalid` 属正常且正是价值所在 —— 选行是「从没检测过的优先」，而积压的 1,897 条未检测记录里大部分是 **2026-08-04 一次性批量导入、`attempt_status` 为空（从未尝试登录）**、CK 已放两个月的陈旧账号。错误信息统一是斗鱼侧的「用户未登录」，不是风控。按 200 条/5 分钟，约 5.4 小时扫完全库积压后进入稳态。
+
+> **注意**：巡检会把这些陈旧账号的 `ck_check_status` 从空翻成 `invalid`，客服在「CK 检测与重登」页会突然看到大批失效账号 —— 这是预期行为，不是故障。
+
 ### 7.2 数据模型（迁移 1 个，P1a/P1b 共用）
 
 **新表 `automation_jobs`**