getDomain/docs/codex接手.md

把下面这段直接发给新的 Codex 就行：

接手这个项目，请先不要发散，也不要先动展示层。你先完整阅读并基于现状继续推进主线。

项目路径：
`/www/wwwroot/getDomain`

必须先看这几份文档：
1. `docs/ops_center_runtime/HANDOFF_20260420_1920.md`
2. `docs/base.md`
3. `docs/test.md`

这次接手的硬性要求：
1. 先以 `docs/ops_center_runtime/HANDOFF_20260420_1920.md` 为准建立上下文。
2. 不要把当前这台机器当成真正的 mainland controller。
3. 当前工作机是海外 12 核测试控制面，真正的 `mainland-controller-01` 是 `121.204.244.188`。
4. 不要再优先动页面、展示层、面板文案。
5. 不要用破坏性 git 命令，不要回滚现有脏工作区改动。
6. 新增或修改代码前，先确认你改的是主线瓶颈，而不是辅助功能。

当前已经确认的事实：
1. 真正的 `mainland-controller-01` 已重新对正。
2. controller 的 node-agent 身份上报已经修好，现在控制面里应显示：
   - `agent_hostname = mainland-controller-01`
   - `agent_ip = 121.204.244.188`
3. controller 远端发布链已经成功跑通过一次。
4. 当前真正吃任务的是 `mainland-controller-01`。
5. `mainland-worker-01` 目前是 agent 在线，但检测没有真正参与，现象是本地检测态里出现 `127.0.0.1:5432 connection refused`。
6. 当前主线已经不是“节点身份问题”，而是“真 controller 吞吐”和“worker 恢复”。

你接手后只做两条主线：
1. 恢复 `mainland-worker-01`，让它重新进入可参与检测状态。
2. 继续压 `mainland-controller-01` 的真实吞吐，只盯 `claimed -> running -> completed` 的推进，不回展示层。

你要避免的坑：
1. 不要再把本机当成 `mainland-controller-01`。
2. 不要优先用本机 Python service 入口直接造 deploy job，优先通过运行中的 API HTTP 接口。
3. 不要把 `job 332` 这种“node-agent 重启自己导致状态未优雅回写”的现象直接误判为真正失败。
4. 不要跑偏到 UI、导出、日志窗口样式这些支线。

你开始后先做这三件事，再继续动手：
1. 复述你理解的当前真实环境拓扑。
2. 复述当前两条唯一主线任务。
3. 给出你准备先验证的 3 个现场指标，再开始执行。

目标只有一个：
先把主流程和真实并发跑起来，让 controller 真机和 worker 真正参与检测，再谈细节优化。