Update runtime handoff after mainland deploy validation

docs/ops_center_runtime/IMPLEMENTATION_STATUS.md

@@ -1,6 +1,6 @@
 # IMPLEMENTATION_STATUS
 
-更新时间：2026-04-19 03:38 CST
+更新时间：2026-04-19 03:41 CST
 
 ## 当前真实状态
 
@@ -12,11 +12,12 @@
 
 ## 本轮最新结论
 
-这轮结论需要更新为三段：
+这轮结论需要更新为四段：
 
 - 接管与同步能力已经明显趋于完成
-- 检测执行面当前没有持续产出
-- 其中一处代码级风险已经完成最小修复，但尚未完成线上部署验证
+- worker 控制消息补偿链已经完成线上验证
+- controller 运行环境漂移已经被现场修正
+- 当前唯一剩余主阻塞已经收紧到 controller 代理池无可用代理
 
 ## 当前证据拆分
 
@@ -36,6 +37,17 @@
 - `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`
 
+线上运行验证也已经出现正向证据：
+
+- `mainland-worker-01`
+  - 启动后发现待执行控制指令
+  - 接受 `start_detection`
+  - 开始执行远程检测任务
+- `mainland-controller-01`
+  - 修正 Redis 环境后
+  - 重新接受 `start_detection`
+  - 开始执行远程检测任务
+
 ### 2. 接管/同步闭环
 
 当前已完成：
@@ -55,16 +67,14 @@
 
 当前未完成：
 
-- 连续 40 秒观察窗口内：
-  - `progress_percent` 不变
-  - `items_completed` 不变
-  - `items_running` 不变
-  - `items_claimed` 不变
-  - `items_pending` 不变
-- mainland `domain_*` 事件数仍固定在 `10`
-- 最新 mainland `detect_result_ingest` 仍停在 `5382`
-- `activity-stream` 明确提示：
-  - `近窗刚有吞吐 0 台`
+- 短观察窗口内：
+  - `progress_percent` 仍是 `2.1`
+  - `items_completed` 仍是 `21`
+  - `items_claimed` 仍是 `34`
+  - `items_pending` 仍是 `931`
+- 中央 recent events 已刷新到更晚时间
+- `runtime/sync-summary` 最新记录已继续增长
+- 但 completed 尚未继续上涨
 
 这说明：
 
@@ -86,14 +96,29 @@
     - `Unable to connect to proxy`
     - `ConnectTimeoutError`
 - worker 新增远端日志显示：
-  - `时光机检测 外部依赖异常，步骤降级继续执行`
-  - 同时仍有 `域名检测完成`
-  - 新收到的重复启动指令被忽略，因为任务已在运行
+  - `发现待执行 Worker 控制指令`
+  - `已接受检测启动指令`
+  - `开始执行远程检测任务`
+  - 说明线上补偿消费链已真正工作
+- controller 新增远端日志显示：
+  - 初次重启后：
+    - `Authentication required`
+    - `maximum recursion depth exceeded`
+  - 进一步排查确认：
+    - `/etc/default/domaincheck-worker` 的 `REDIS_PASSWORD` 为空
+  - 修正后再次重启：
+    - `Redis 连接成功: 127.0.0.1:6379`
+    - `已接受检测启动指令`
+    - `开始执行远程检测任务`
+  - 后续日志继续收紧到：
+    - `代理已启用，但当前无可用代理`
 - 两台大陆节点 full capture 已开启，但源日志时间没有继续前进
 
 这说明：
 
-- 当前第一主阻塞更像 controller 代理池不可用
+- worker 控制消息链不再是主阻塞
+- controller Redis 环境漂移也不再是主阻塞
+- 当前第一主阻塞已经进一步收紧到 controller 代理池不可用
 - worker 的时光机异常是客观存在的次级问题
 - 不是控制面未接管
 - 不是同步链未打通
@@ -132,14 +157,11 @@
 
 - “检测启动已经发布，但 worker 可能静默漏收”的代码风险
 
-这组修复还没有证明能够解决的是：
-
-- `controller` 代理池校验后 `0 available` 的外部执行阻塞
-
 所以当前最准确的状态是：
 
 - 代码级控制链缺口已补上
-- 运行态是否恢复，还要看线上节点拉代码重启后的观测结果
+- 线上部署验证已通过
+- 但 `controller` 代理池校验后 `0 available` 的现场阻塞仍然存在
 
 ## 当前已闭合的问题
 
@@ -156,15 +178,14 @@
 
 当前唯一主问题仍然是：
 
-- 检测执行面停滞
+- 检测执行面没有恢复到持续产出
 
-但其下应拆成两个层次：
+但现在已经不需要再拆成“代码待验证”和“现场阻塞”两层。
 
-- 已补代码、待验证：
-  - worker 控制消息补偿消费链
-- 已确认现场阻塞：
-  - controller 代理池可用性为 0
-  - 因此没有持续产生新的 domain 级结果
+当前唯一剩余现场阻塞就是：
+
+- controller 代理池可用性为 0
+- 因此没有持续产生新的 domain 级结果
 
 换句话说：
 
@@ -186,9 +207,9 @@
 
 当前结论：
 
-- 可以继续做最小部署验证
-- 也可以继续做执行恢复类排查
-- 但还不能把当前状态视作“后台检测已经稳定恢复”
+- 可以继续做最小运行态排查
+- 但不需要再优先验证 worker 控制消息链
+- 当前还不能把状态视作“后台检测已经稳定恢复”
 
 ## 当前是否建议直接上线
 
@@ -199,9 +220,9 @@
 原因不是接管面，而是执行面：
 
 - 三台节点都已接入
+- worker / controller 都已重新接上控制链
 - 但当前任务没有持续吞吐
 - controller 代理池全部验不过会直接影响检测产出
-- 并且这轮刚补上的 worker 控制消息修复还没经过线上运行验证
 
 ## 当前优先级判断
 
@@ -221,8 +242,6 @@
 
 如果下一轮确认：
 
-- 大陆节点已拉到这版控制消息修复
-- `domaincheck-worker` 重启后稳定收新指令
 - controller 代理池恢复可用
 - `domain_*` 开始继续增长
 - `items_completed` 和近窗吞吐重新前进