# 主线任务验收总表

更新时间：2026-04-21

## 当前执行原则

当前先只做一件事：

- 跑通主任务流程
- 把 7 个大任务按“可测试、可验收”的标准推进
- 并发、代理、展示层、CPU 打满这类细节优化先封存，不再抢主线

当前不再把“性能抠点”当主目标。
后续额度恢复后，再继续做细节优化专项。

## 当前主线优先级

按下面顺序推进，不跳步：

1. 大任务 1 真实验收闭环
2. 大任务 2 controller 编排闭环
3. 大任务 3 统一结果状态机闭环
4. 大任务 4 本地控制状态 + syncer/finalizer 闭环
5. 大任务 5 固定 worker pool + 持续补位替换旧模型
6. 大任务 6 时光机一期接入标准步骤
7. 大任务 7 运营视角指标面板落地

## 7 个大任务当前状态

### 大任务 1
单步骤任务底座落地

目标：
先打通 `controller -> queue -> claim -> worker -> result -> controller` 的完整闭环。

当前状态：
- 已有较完整代码底座
- `single_step` / `step_code` 模型已基本成形
- 现在缺的是“真实运行验收”而不是继续堆骨架

本任务验收只认下面 5 件事：

1. controller 能生成 `baidu_check` 任务
2. worker 能拉到 `baidu_check` 任务并执行
3. worker 能回传标准化结果
4. controller 能更新本地步骤状态
5. worker 超时未回传时，任务会回收重投

当前结论：
- 代码方向已基本对齐
- 2026-04-20 已完成一轮 live 验收打钩：
  - `controller` 已生成 `single_step / detect_baidu_site` 任务（例：`job_id=6`, `job_code=step-20260420153527-9fc7b5`）
  - `worker` 已精准领取当前 `job_id` 并执行，不再被旧 `pipeline / sync / legacy fallback` 污染
  - `worker` 已回传标准化结果到 `detect_job_items.result_payload_json`
  - `controller` 已可按 `job_id` 定向执行 `process_pipeline`，并把结果落到本地 `domain_detections.baidu_site`
  - “超时/遗留未回传”链路已验证会被节点启动释放并重新领取执行（`job_id=5` 在遗留 `running` 后被重新释放、重新领取并完成）
- 当前主线结论：大任务 1 已达到“可验收通过”状态，可以继续把主精力切到大任务 2 / 3

### 大任务 2
pipeline 编排器落地

目标：
把“下一步跑什么”彻底收回 controller。

当前状态：
- 基础方向已落到 controller 驱动
- 还需要继续做“按后台勾选顺序推进 / 按域名属性跳过”的真实验收

本任务必须确认：
- 同一个域名不会在 worker 里串完整条链
- controller 是唯一推进者
- 勾选顺序变化能影响下一步投递
- 跳过规则生效

当前结论：
- 已进入可验收阶段
- 2026-04-20 已补上关键收口：
  - `single_step` 会话下，worker 只按当前 `job_id` 领取任务
  - `single_step` 会话下，旧的 `pipeline 推进 / sync pull / legacy fallback` 已被显式跳过
  - `process_pipeline` 已支持按 `job_id` 定向处理，方便 controller 精准推进当前步骤
- 2026-04-20 又补完一轮 live 验收：
  - `pass`：`detect_baidu_site` 完成后，controller 已为同一 `job` 创建下一步 `detect_360_site`
  - `skip`：一口价域名在 `detect_register + detect_baidu_site` 配置下，会直接解析到 `detect_baidu_site`
  - 同时修掉了一个真实阻塞点：`process_pipeline()` 事务内再开第二连接写 `detect_run_events` 会把 controller 自己锁住；现已改成同事务同 cursor 写事件
- 当前主线结论：大任务 2 的 controller 编排主干已可验收，剩下更多是扩步骤和补更细跳过规则

### 大任务 3
步骤结果判定与重试策略落地

目标：
统一 `pass / retry / black_hit / reject`。

当前状态：
- 结果结构、重试入口、黑名单终止方向已基本进入主链
- 还需要补 live 验收，重点是 TTL 回收、重投、终止规则

本任务必须确认：
- 外部失败会重投当前步骤
- 黑名单命中会终止后续步骤
- 非黑名单业务不通过按规则终止
- 不会出现同一步无限重试

当前结论：
- 代码已明显推进
- 2026-04-20 已完成 controller 侧 live 验收：
  - `retry`：`state=degraded` 会重投当前步骤，不推进下一步
  - `black_hit`：`state=blacklisted` 会终止后续步骤并结束当前 job
  - `reject`：`state=rejected` 会终止当前流程，不再重试
  - worker 侧也已补上业务失败 -> `rejected` 的结果态，不再把业务不通过和技术失败都混成 `failed`
- 当前主线结论：大任务 3 的统一结果状态机已基本闭环，可继续往大任务 4 / 5 推进

### 大任务 4
本地控制状态与海外主库同步落地

目标：
controller 本地维护高频状态，syncer 批量同步海外主库，finalizer 标记流程完成。

当前状态：
- 本地状态和部分同步链路已经在跑
- 已补上“最近完成任务快照也继续产出结果投影”
- 已补上结果导入后按 job_code 优先定位本地 job，并刷新本地 job 收尾状态
- syncer/finalizer 还缺少一轮 live 闭环验收

本任务必须确认：
- 高频链路不依赖 worker 频繁直写海外主库
- controller 本地状态完整
- 批量同步成功
- 流程完成状态准确

当前结论：
- 代码主链已进一步收口
- 2026-04-21 已确认 `detect_result_projection / runtime_projection` 在 `detect_sync_records` 中持续产出且状态为 `projected`
- 当前说明 syncer 主链已恢复，但“本地 job 收尾状态 + 主库最终账本完全一致”的终验还需要继续盯现场

### 大任务 5
worker 池化与持续补位调度落地

目标：
真正替掉“批量认领 + 批量等待”的旧模型。

当前状态：
- 已经做了多轮并发热路径优化
- 已进一步压缩 executor 内部 backlog，补位更接近固定槽位模型
- 但还需要一轮 live 运行观察 claimed/running 曲线，确认旧的批量认领惯性已被压住

本任务必须确认：
- 活跃槽位稳定贴近配置上限
- 并发不再大起大落
- 吞吐明显提升
- 调度器自耗下降

当前结论：
- 这是主线里仍然偏重的未完项
- 2026-04-21 已继续做现场修正：
  - `claim_detect_job_items()` 已显式排除空 `step_code` 的 legacy 项，避免 worker 从标准队列入口继续误吞旧 whole-domain 项
  - `mainland-controller-01 / 121.204.244.188` 与 `mainland-worker-01 / 121.204.244.248` 均已确认在真大陆节点参与执行
  - 海外控制面 `queue_health / dashboard` 已补上“读取大陆 runtime/debug 近窗执行流”的兜底口径
  - 当前首页已能看到真实近窗吞吐，例如 `10-15 项/分钟` 量级、并能拆到 controller/worker 两个节点
- 当前主线判断：
  - “高 claimed 假活跃”问题已继续缓解
  - “活吞吐不可见”问题已明显改善
  - 但“总 completed 账本持续增长”和“running 贴近线程上限”仍未彻底验收，所以大任务 5 仍未签字通过

### 大任务 6
时光机一期流程落地

目标：
时光机按“最近 5 年”方案接成标准步骤任务。

当前状态：
- 现有项目里已有时光机相关检测逻辑
- 但还没有完全按标准步骤任务方式接进新 pipeline 验收

本任务必须确认：
- wayback 作为标准步骤任务接入
- 最近 5 年快照策略稳定
- 返回标准化结果
- controller 能把它当普通步骤推进/终止

当前结论：
- 2026-04-21 已落代码并通过测试：
  - `detect_wayback` 已作为标准 `single_step` 步骤接入 controller / worker 主链
  - 时光机一期已按“最近 5 年 + 命中即停”策略落地到 payload 和 detector
  - 焦点测试已通过
- 但还缺 live 现场验收：
  - 真实任务投递
  - worker 执行
  - 标准化结果回传
  - controller 按普通步骤推进/终止
- 当前主线结论：大任务 6 已进入“代码落地完成、待现场验收”状态

### 大任务 7
运营视角指标与验收面板落地

目标：
让后台能判断“有没有跑起来、卡在哪一步、多久跑完”。

当前状态：
- 后端已有部分 runtime / detect status / debug event 统计基础
- 但完整的运营视角指标面板还没有完全落地验收

本任务必须确认：
- 每步骤队列数
- 每步骤吞吐
- 每分钟完成量
- 当前 pipeline 分布
- 重试数 / 黑名单数 / 失败数
- 预估剩余时间

当前结论：
- 2026-04-21 已落地首页最小运营面板，并补了第二层口径修正：
  - `completed / pending / running` 已切到“全活跃任务累计口径”
  - `步骤队列 / 节点吞吐 / 重试压力 / 有效执行节点` 已可直接展示
  - `ETA` 在无真实近窗完成量时会显示“待计算”，避免误报 0 小时
  - 2026-04-21 又补上“大陆 runtime/debug 近窗执行流”兜底：
    - `active_job` 已可显示 `runtime_job_code`
    - `processed_per_minute / completed_recent / node_throughput / step_queue` 已能贴近大陆真实执行
    - 首页已能直接区分 `db_job_code` 与 `runtime_job_code`
- 当前结论：大任务 7 已进入“可运营分析并能指导现场排障”阶段，但仍需继续把“总 completed 账本”和“最终验收面板”完全统一

## 现在只做什么

当前只盯主线，不跑偏：

1. 把大任务 1 做成可真实验收
2. 验收过后立刻推进大任务 2
3. 再按顺序推进 3、4、5、6、7

如果某个问题只是：

- CPU 没吃满
- 某个 timeout 还能再抠
- 代理池还能更激进
- 页面还能再改得更好看

都先不打断主线。

## 已封存的细节优化 backlog

下面这些不是不做，而是先封存：

### A. 并发/调度优化

- 固定 worker pool 彻底替换旧批量认领模型
- claimed 回弹继续压缩
- executor 内部排队继续收紧
- 活跃 running 继续往上抬
- controller / worker 双节点吞吐平衡

### B. DB 往返优化

- 继续合并 `domains` 表高频更新
- 继续减少 `mark_running / finalize` 这类必要写库点开销
- 能走 Redis 或本地状态的尽量不走高频 DB

### C. 外部请求链路优化

- 代理失败后的重试链继续压缩
- 直连失败后回代理的等待窗口再收紧
- 无代理窗口等待策略再优化
- 外部请求 timeout 再按真实成功率调优

### D. 代理池策略优化

- 代理池刷新频率与补位策略继续增强
- 失败代理淘汰与新代理拉取节奏继续优化
- 控制“不过度预验证”和“不过度浪费线程”之间的平衡

### E. 运营展示层优化

- 更细的 runtime 面板
- ETA / 每分钟吞吐更精细展示
- 日志窗口布局继续优化
- 非主线的页面交互增强

## 接下来执行口径

接下来统一按这个口径推进：

- 先验收主流程
- 再补主流程缺口
- 性能细节先记账，不抢主线
- 每做完一个大任务，就给出“是否验收通过”的明确结论

一句话定调：

当前阶段不是“继续无限抠并发”，而是“先把 7 个大任务按主线流程逐个打通并验收”。