Update runtime handoff after mainland deploy validation

docs/ops_center_runtime/TASK_BOARD.md

@@ -1,6 +1,6 @@
 # TASK_BOARD
 
-更新时间：2026-04-19 03:38 CST
+更新时间：2026-04-19 03:41 CST
 
 ## 当前主批次
 
@@ -18,7 +18,7 @@
 
 ## 本轮最新状态
 
-本轮在只读取证基础上，已经补了一处最小代码修复，但还没有完成线上节点拉代码后的运行验证。
+本轮已经完成“代码修复 -> 两台大陆节点部署 -> 运行态复查”的完整一轮验证。
 
 ### 已完成的最小修复
 
@@ -34,41 +34,52 @@
 - `unittest domain-api/tests/test_worker_control_service.py`
 - `python -m py_compile domainCheck/detect_worker.py domain-api/app/services/worker_control_service.py`
 
-### 仍未完成的事情
+### 已完成的线上验证
 
-- 大陆节点尚未基于这版修复完成拉代码并重启 `domaincheck-worker`
-- 因此这轮还不能把“检测停滞”完全归因成单一外部代理问题
-- 当前更准确的表述应为：
-  - `controller` 代理池可用数为 `0` 是已确认现场阻塞
-  - worker 控制消息存在“可能丢发布、pending 不被运行态补偿消费”的代码风险，现已本地修复，待线上验证
+- `mainland-worker-01`
+  - 已拉到 `main` 最新提交 `c33f4f1`
+  - 已重启 `domaincheck-worker`
+  - 启动后明确出现：
+    - `发现待执行 Worker 控制指令`
+    - `已接受检测启动指令`
+    - `开始执行远程检测任务`
+- `mainland-controller-01`
+  - 已拉到 `main` 最新提交 `c33f4f1`
+  - 已重启 `domaincheck-worker`
+  - 发现运行环境漂移：
+    - `/etc/default/domaincheck-worker` 中 `REDIS_PASSWORD` 为空
+  - 已最小修正该节点运行环境后再次重启
+  - 修正后明确出现：
+    - `Redis 连接成功: 127.0.0.1:6379`
+    - `已接受检测启动指令`
+    - `开始执行远程检测任务`
+
+### 本轮仍未完成的事情
+
+- 中央 `items_completed` 仍未在短观察窗口内继续增长
+- `mainland-controller-01` 仍然持续报：
+  - `代理已启用，但当前无可用代理`
+- 因此当前剩余阻塞已经进一步收紧到：
+  - controller 现场代理池没有可用代理
 
 ## 本轮最新复查结果
 
-本轮没有新增实现，只做了中央只读复查 + 节点现场日志取证 + 远端 `domaincheck-worker` 日志采样：
+本轮在完成修复部署后，中央与节点现场出现了新的运行证据：
 
 - 活跃任务仍是 `detect-20260417170546-96023e`
-- 三台节点都在参与：
-  - `mainland-controller-01`
-  - `mainland-worker-01`
-  - `overseas-control-01`
-- 但连续一个完整观察窗口内，任务进度没有前进：
+- `mainland-worker-01` 最新事件时间已经从旧窗口推进到：
+  - `2026-04-19 16:37:00`
+- `runtime/sync-summary` 最新记录已继续增长到：
+  - `id = 5491`
+  - `created_at = 2026-04-19 03:40:45`
+- 说明中央已经重新收到新的运行侧同步流量
+- 但短窗口内主进度仍未松动：
   - `completed = 21`
   - `running = 14`
   - `claimed = 34`
   - `pending = 931`
-- mainland `domain_*` 事件仍停在 `10` 条，没有继续增长
-- 最新 mainland `detect_result_ingest` 仍是：
-  - `id = 5382`
-  - `created_at = 2026-04-19 03:10:14`
-- `activity-stream` 已明确显示：
-  - `近窗刚有吞吐 0 台`
-- 新增日志采样结果：
-  - `mainland-controller-01`
-    - 代理源拉取成功
-    - 代理校验后 `共 0 个可用代理`
-  - `mainland-worker-01`
-    - 时光机依赖异常会降级继续执行
-    - 收到重复启动指令时会忽略
+- controller 现场最新日志已收紧为：
+  - `代理已启用，但当前无可用代理`
 
 ## 关键证据
 
@@ -182,7 +193,7 @@
 - 也不是“日志回传没回来”
 - 而是执行进程这段时间确实没有继续产生日志
 
-### 证据 7：worker 控制消息补偿链已补上代码缺口
+### 证据 7：worker 控制消息补偿链已在线上验证生效
 
 之前运行态存在一个真实风险：
 
@@ -198,7 +209,10 @@
 - worker 心跳会主动补偿消费 pending 指令
 - worker 真正收到并处理后，会按 `request_id` 清理 pending
 
-这一步已经消除了“控制消息可能被静默漏掉”的代码风险，但还需要线上部署后再观察真实任务是否恢复推进。
+这一步现在已经不再是“待部署假设”，而是已被线上日志确认生效：
+
+- `mainland-worker-01` 已从 pending 指令恢复执行
+- `mainland-controller-01` 在修正 Redis 环境后，也已重新接受并执行 `start_detection`
 
 ## 当前结论
 
@@ -206,10 +220,10 @@
 
 - 接管链路已基本完成
 - 同步链路已至少成功贯通一次
-- 当前主阻塞依旧是检测执行面停滞
-- 其中已确认的现场问题有两个层次：
+- 当前主阻塞仍是检测执行面没有恢复到“持续产出”
+- 但代码级控制链缺口已经闭合
+- 当前唯一剩余现场阻塞可以收紧为：
   - `mainland-controller-01` 代理池可用性为 `0`
-  - worker 控制消息补偿链之前存在代码缺口，现已本地修复，待部署验证
 - worker 侧时光机异常仍是次级噪音，不应继续放大
 
 ## 下一步唯一主批次
@@ -218,10 +232,10 @@
 
 本批次唯一目标：
 
-- 先把控制消息补偿修复部署到线上 worker
-- 再复查检测任务是否恢复推进
-- 若仍停滞，再把剩余问题继续收紧到 controller 代理池可用数为 0
-- 全程不做任何功能扩展
+- 保持当前不扩功能
+- 只围绕 controller 代理池可用性为 `0` 做收口
+- 继续观察修正后的 controller 是否开始产出 domain 级结果
+- 若仍无结果增长，则只给出代理层最小补救路径
 
 ## 候选批次
 
@@ -258,16 +272,14 @@
 
 下一轮唯一应该继续做的事情：
 
-- 只做最小部署与运行态收口：
-  - 大陆节点拉取最新代码
-  - 重启 `domaincheck-worker`
-  - 复查 `/api/v1/detect/job/active`
-  - 复查 `/api/v1/runtime/sync-summary`
-  - 复查 controller / worker `scene-log`
-  - 必要时追加 `domaincheck-worker` 运行日志取证
+- 只做 controller 代理收口：
+  - 继续复查 controller `domaincheck-worker` 日志
+  - 观察是否从 `当前无可用代理` 转为有可用代理
+  - 继续复查 `/api/v1/detect/job/active`
+  - 继续复查 `/api/v1/runtime/sync-summary`
+  - 继续复查 recent domain events 是否出现 controller / 新 completed
 - 唯一判断问题是：
-  - 修复部署后，任务是否重新推进
-  - 若仍不推进，是否只剩 controller 代理池 `0 available` 这一条主阻塞
+  - controller 代理池恢复后，completed 是否开始继续增长
   - 是否仍是 `近窗吞吐 0`
   - 是否仍是 `controller 可用代理数 0`
   - 代理恢复后 `domain_*` 是否重新增长