50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
把下面这段直接发给新的 Codex 就行：
|
||
|
||
```text
|
||
接手这个项目，请先不要发散，也不要先动展示层。你先完整阅读并基于现状继续推进主线。
|
||
|
||
项目路径：
|
||
`/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 真正参与检测，再谈细节优化。
|
||
```
|