# IMPLEMENTATION_STATUS

更新时间：2026-04-19 03:38 CST

## 当前真实状态

阶段判断：

- 海外单脑接管能力：约 `95%`
- 分布式检测真实执行能力：约 `88%~90%`
- 距离“可稳定上线并放心用后台发起检测”：约 `86%~89%`

## 本轮最新结论

这轮结论需要更新为三段：

- 接管与同步能力已经明显趋于完成
- 检测执行面当前没有持续产出
- 其中一处代码级风险已经完成最小修复，但尚未完成线上部署验证

## 当前证据拆分

### 1. 代码闭环

已经完成：

- `detect_result_projection` 支持 `recent_domain_events`
- 中央 ingest 会把逐条事件写入 `detect_run_events`
- `sync_agent` 会自动产出 `detect_result_projection`
- worker 控制消息新增 `request_id`
- worker 运行态心跳会补偿消费 pending 控制消息
- worker 收到并处理控制消息后会按 `request_id` 清理 pending 指令

本地代码验证已通过：

- `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`

### 2. 接管/同步闭环

当前已完成：

- `remote_access_ready = 3/3`
- `log_sync_state = full_capture`
- `mainland-controller-01` 的 `domaincheck-sync-agent` 已重启到新进程
- 首轮 `detect_result_projection` 推送成功过一次
- 中央已收到 mainland 首批 `domain_*` 事件

这说明：

- mainland 到中央的基础同步链是活的
- 结果投影链至少成功打通过一次

### 3. 检测执行闭环

当前未完成：

- 连续 40 秒观察窗口内：
  - `progress_percent` 不变
  - `items_completed` 不变
  - `items_running` 不变
  - `items_claimed` 不变
  - `items_pending` 不变
- mainland `domain_*` 事件数仍固定在 `10`
- 最新 mainland `detect_result_ingest` 仍停在 `5382`
- `activity-stream` 明确提示：
  - `近窗刚有吞吐 0 台`

这说明：

- 当前不是单纯“页面没刷新”
- 而是执行现场这段时间没有继续出结果

## 本轮新增硬证据

通过中央观测面、节点现场日志和远端 `domaincheck-worker` 日志，已确认：

- `mainland-controller-01` 现场日志显示：
  - `当前可用代理数: 0`
  - `最近结果: 刷新成功，可用 0 个`
- controller 新增远端日志显示：
  - 代理源拉取成功
  - 抽样校验后 `共 0 个可用代理`
  - 失败集中在：
    - `ProxyError@https://m.baidu.com`
    - `Unable to connect to proxy`
    - `ConnectTimeoutError`
- worker 新增远端日志显示：
  - `时光机检测 外部依赖异常，步骤降级继续执行`
  - 同时仍有 `域名检测完成`
  - 新收到的重复启动指令被忽略，因为任务已在运行
- 两台大陆节点 full capture 已开启，但源日志时间没有继续前进

这说明：

- 当前第一主阻塞更像 controller 代理池不可用
- worker 的时光机异常是客观存在的次级问题
- 不是控制面未接管
- 不是同步链未打通

## 本轮新增代码修复

本轮不是只停留在诊断，还补了一处运行态最小修复：

### 修复点 1：控制消息唯一标识

- 文件：
  - `domain-api/app/services/worker_control_service.py`
- 变更：
  - 每次 `send_worker_command(...)` 都附带 `request_id`
  - Redis `publish` 与 pending fallback 使用同一份消息体

### 修复点 2：worker 运行态补偿消费 pending 指令

- 文件：
  - `domainCheck/detect_worker.py`
- 变更：
  - 心跳线程每轮会补偿尝试消费 pending 控制消息
  - 解决“worker 在线但 pubsub 消息漏收，导致 pending 指令长期不被消费”的风险

### 修复点 3：worker 收到指令后确认清理 pending

- 文件：
  - `domainCheck/detect_worker.py`
- 变更：
  - worker 实际收到控制消息后，会按 `request_id` 清理对应 pending 指令
  - 避免修复后又产生重复回放

### 当前判断

这组修复解决的是：

- “检测启动已经发布，但 worker 可能静默漏收”的代码风险

这组修复还没有证明能够解决的是：

- `controller` 代理池校验后 `0 available` 的外部执行阻塞

所以当前最准确的状态是：

- 代码级控制链缺口已补上
- 运行态是否恢复，还要看线上节点拉代码重启后的观测结果

## 当前已闭合的问题

已闭合：

- 大陆 controller 无法 `pull_tasks`
- Detect 页面误判“大陆没跑”
- Detect 主统计口径不一致
- Runtime / Queue / Detect 主摘要不统一
- 中央逐条事件接收缺口
- `sync_agent` 自动产出结果投影缺口

## 当前唯一剩余问题

当前唯一主问题仍然是：

- 检测执行面停滞

但其下应拆成两个层次：

- 已补代码、待验证：
  - worker 控制消息补偿消费链
- 已确认现场阻塞：
  - controller 代理池可用性为 0
  - 因此没有持续产生新的 domain 级结果

换句话说：

- 现在不是逻辑未实现
- 不是中央映射失败
- 不是节点未接管
- 而是执行现场没有继续产出，且 controller 侧卡在代理校验失败

## acceptance 当前状态

最新接管验收结果仍然成立：

- `pbr-9ce5c85f17`：`onboarding.acceptance` 成功
- `pbr-389abd618c`：`onboarding.acceptance` 成功

旧的 `attention` run 依然是历史残留，但它们已经不是当前最真实的生产阻塞。

## 当前是否可以继续跑检测测试

当前结论：

- 可以继续做最小部署验证
- 也可以继续做执行恢复类排查
- 但还不能把当前状态视作“后台检测已经稳定恢复”

## 当前是否建议直接上线

当前结论：

- 不建议现在按“可稳定上线”判断

原因不是接管面，而是执行面：

- 三台节点都已接入
- 但当前任务没有持续吞吐
- controller 代理池全部验不过会直接影响检测产出
- 并且这轮刚补上的 worker 控制消息修复还没经过线上运行验证

## 当前优先级判断

最高优先级：

- `J2-检测执行停滞收口批`

当前不应继续推进：

- 新控制面功能
- 新模块
- 新页面
- 发布动作
- 与检测执行停滞无关的工作

## 完成下一轮后的预期

如果下一轮确认：

- 大陆节点已拉到这版控制消息修复
- `domaincheck-worker` 重启后稳定收新指令
- controller 代理池恢复可用
- `domain_*` 开始继续增长
- `items_completed` 和近窗吞吐重新前进

则整体可上线程度预计可回升到：

- `92%~94%`

在那之前，当前口径应保持保守。