getDomain/domain-api/deploy/multi-region

domainCheck 跨地域部署入口

本文档对应当前推荐的最小可用部署形态：

• 国外 1 台：domain-web + domain-api + postgresql_main
• 大陆 1 台：redis + postgresql_runtime + scheduler + detect-worker

目标：

• 后台和 API 放国外
• 检测执行放大陆
• 后续新增大陆 Worker 时，不再改整体部署方式

如果当前已经不再只是“部署”，而是进入“海外单脑控制面统一驾驶 / 准备上线”阶段，建议先补看：

• docs/25_domainCheck_海外单脑控制面上线收口总表.md
• docs/23_domainCheck_终局运维架构设计_海外单脑控制面.md
• docs/24_domainCheck_NodeAgent协议与ReleaseHub设计.md
• docs/schemas/ops_driver_contract.md
• docs/schemas/ops_stack_diagnosis_contract.md

一、目录约定

统一使用：

/opt/domaincheck

仓库内部署入口：

• domain-api/deploy/multi-region/bootstrap_overseas.sh
• domain-api/deploy/multi-region/bootstrap_mainland.sh
• domain-api/deploy/multi-region/bootstrap_node_agent.sh
• domain-api/deploy/multi-region/build_node_agent_bootstrap_plan.sh
• domain-api/deploy/multi-region/init_ops_center_config.sh
• domain-api/deploy/multi-region/drive_ops_center.sh
• domain-api/deploy/multi-region/drive_release_hub.sh
• domain-api/deploy/multi-region/drive_ops_action.sh
• domain-api/deploy/multi-region/templates/domaincheck-node-agent.env.example
• domain-api/deploy/multi-region/templates/domaincheck-ops-center.env.example
• domain-api/deploy/multi-region/templates/domaincheck-worker.instance.env.example
• domain-api/deploy/multi-region/check_cluster.sh
• domain-api/deploy/multi-region/check_node_agent.sh
• domain-api/deploy/multi-region/check_ops_center_stack.sh
• domain-api/deploy/multi-region/check_go_live.sh
• domain-api/deploy/multi-region/check_release_hub.sh
• domain-api/deploy/multi-region/drive_ops_center.sh
• domain-api/deploy/multi-region/drive_release_hub.sh
• domain-api/deploy/multi-region/drive_ops_action.sh
• domain-api/deploy/multi-region/check_mainland_controller.sh
• domain-api/deploy/multi-region/check_mainland_worker.sh
• domain-api/deploy/multi-region/check_worker_participation.sh
• domain-api/deploy/multi-region/check_node_scene_log.sh
• domain-api/deploy/multi-region/check_ops_link_snapshot.sh
• domain-api/deploy/multi-region/check_temp_overseas_control.sh
• domain-api/deploy/multi-region/check_temp_link.sh
• domain-api/deploy/multi-region/check_temp_topology.sh
• domain-api/deploy/multi-region/simulate_cluster_node.py
• domain-api/deploy/multi-region/simulate_multi_region.sh
• domain-api/deploy/multi-region/prune_cluster_nodes.py
• domain-api/deploy/multi-region/prune_cluster_nodes.sh
• domain-api/deploy/multi-region/templates/*.env.example

一点五、海外单入口现在支持 Contract Preview 和门禁执行

从这版开始，海外机的统一入口不只是“直接执行动作”，还支持先看 contract：

cd /opt/domaincheck/domain-api

# 看 contract registry
bash domain-api/deploy/multi-region/drive_ops_center.sh contracts

# 直接预览某个 driver action
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-preview open_release_dialog

# 先按统一门禁解析某个 driver action
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-resolve enable_log_sync_key

# 按统一门禁执行某个 driver action
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-run enable_log_sync_key

# 单独查看远端日志回传当前状态
bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-check

# 一条命令完成：开启日志回传 + 复核状态 + 给出下一跳建议
bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover
bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover http://127.0.0.1:8100 full confirm cli/ops

# 一条命令完成：查看接管缺口 + 选首节点 + 生成接入方案 + 给出下一跳建议
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-check
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-recover

# 先读取 stack diagnosis 默认 next_step，再按统一门禁预览
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next

# 显式确认后，直接执行 stack diagnosis 当前默认下一步
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next run confirm

# 先看当前 driver 主线，再直接预览 / 执行 top recommendation
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed
bash domain-api/deploy/multi-region/drive_ops_center.sh activity-stream
bash domain-api/deploy/multi-region/drive_ops_center.sh activity-stream kind=ops_job status=running
bash domain-api/deploy/multi-region/drive_ops_center.sh activity-preview
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-preview
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-run

# 也可以显式指定某个 focus key，例如 runbook
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-preview runbook:release_progression
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-run runbook:release_progression

# 预览某条标准 runbook path，会自动带出主次动作
bash domain-api/deploy/multi-region/drive_ops_center.sh runbook-preview release_progression

# 按统一门禁执行某条标准 runbook path
bash domain-api/deploy/multi-region/drive_ops_center.sh runbook-run release_progression

# 直接预览 codex-brief 当前焦点动作
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-focus-preview

# 按 codex-brief 门禁规则尝试执行当前焦点
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-focus-run

# 对 guarded_auto 焦点显式确认后执行
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-focus-run focus-guarded confirm

这些命令背后统一走：

• GET /api/v1/ops/stack-diagnosis
• GET /api/v1/ops/contracts
• POST /api/v1/ops/driver-actions/preview
• POST /api/v1/ops/driver-actions/resolve
• POST /api/v1/ops/driver-actions/execute-resolved
• POST /api/v1/ops/codex-actions/resolve
• POST /api/v1/ops/codex-actions/execute

也就是说：

• 页面点“看契约”
• 海外 CLI 查“看契约”
• 后续海外 Codex 驾驶员判断“是否执行”

都开始复用同一套后端解释结果，而不是各自再推导一遍目标 API、执行链、request payload 和门禁规则。

当前推荐的海外单脑控制面起手顺序也已经固定：

cd /www/wwwroot/getDomain

# 1. 先看上线收口摘要
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-check http://127.0.0.1:8100 http://127.0.0.1:8100 summary

# 2. 再看总检详情
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-diagnosis

# 3. 再看驾驶主线
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-brief

补充说明：

• CLI 里 stack-diagnosis 和 stack-check 现在是同一条总检入口
• 推荐优先记忆 stack-diagnosis
  • 因为它和页面 API /api/v1/ops/stack-diagnosis、文档名称、值班口径保持一致

这 4 步现在分别对应：

• go-live-summary
  • 先回答“能不能继续收口 / 能不能继续发布”
• stack-diagnosis
  • 解释阻断原因、主处理车道、默认下一步、推荐命令
• driver-feed
  • 告诉页面 / CLI / Codex 当前最值得处理的驾驶主线
• codex-brief
  • 告诉海外 Codex 现在到底该自动执行、确认执行、还是只进 UI

补充一个非常关键的判读口径：

• 如果 env-audit 已经提示 runtime.runtime_may_need_restart=true
• 或 stack-diagnosis / go-live-summary 已经出现 runtime_build_schema_stale
• 但 stack-next 仍然优先给出 node_handover

这通常不代表“接管缺口比 API 重启更重要”，而是代表当前运行中的 domaincheck-api 还没有切到最新代码。此时应先执行：

bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-recover http://127.0.0.1:8100
bash domain-api/deploy/multi-region/check_ops_center_stack.sh http://127.0.0.1:8100 summary
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next

如果你怀疑当前不是业务链路问题，而是环境本身还有漂移，例如：

• Python 依赖没装全
• 当前机器缺 pytest / fastapi / uvicorn
• Node Agent env 文件缺失
• systemd 服务启停口径不一致
• runtime/build-info 的 route surface 还不完整

先不要直接进发布链，先跑：

bash domain-api/deploy/multi-region/drive_ops_center.sh env-audit
bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-check
bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-recover
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-recover

它会统一给出：

• 本机命令可用性
• Python 模块可用性
• env 文件存在性
• systemd 服务状态
• runtime/preflight
• runtime/readiness
• runtime/build-info
• 一份最终 status / headline / missing_items / tooling_items 收口摘要

一点六、单机多进程 Worker 起步方式

如果大陆执行机是高核大内存机器，而单个 detect_worker.py 进程还吃不满机器，可以先不要继续堆单进程线程数，优先改成“同机多实例 Worker”：

# 1. 复制实例模板，按实例编号准备独立 env
cp domain-api/deploy/multi-region/templates/domaincheck-worker.instance.env.example /etc/default/domaincheck-worker-a
cp domain-api/deploy/multi-region/templates/domaincheck-worker.instance.env.example /etc/default/domaincheck-worker-b

# 2. 为每个实例设置不同的 NODE_CODE
#    mainland-controller-01-a
#    mainland-controller-01-b

# 3. 启用 systemd 模板实例
cp domain-api/deploy/systemd/domain-worker@.service /etc/systemd/system/domaincheck-worker@.service
systemctl daemon-reload
systemctl enable --now domaincheck-worker@a
systemctl enable --now domaincheck-worker@b

注意：

• 同一台机器上的每个实例必须使用不同的 NODE_CODE
• 每个实例建议先用中等线程数压测，不要直接把单进程线程数拉到极限
• 这版控制指令已经支持按 NODE_CODE 定向，不同实例不会再一起响应同一条本地 Worker 指令

说明：

• missing_items 只保留真正影响部署或运行面的缺口
• tooling_items 用来提示当前机器缺少的本地辅助工具，例如 pytest
• Python 依赖会优先按实际运行时 .venv 判定，而不是只看当前 shell 的 python3
• 现在还会额外识别“本地仓库已支持新能力，但运行中 API 还是旧 build-info / 旧路由面”的部署漂移
• 重点信号：
  • runtime.repo_capability_drift
  • runtime.runtime_may_need_restart
  • recommended_actions

推荐理解为两层：

• env-audit
  • 看全量环境、依赖、systemd、build-info、route surface 漂移
• runtime-refresh-recover
  • 专门收口“仓库代码已更新，但运行中的 API 还是旧版本”这类上线前高频问题
  • 会先打印完整 env audit，再补一段固定的运行时刷新建议
  • 适合值班同事、海外 Codex、后台按钮统一作为“重启前最后确认入口”
• go-live-recover
  • 在 runtime-refresh-recover 之上，再顺序串起：
    • stack-diagnosis summary
    • stack-next
    • go-live-check summary
    • doctor-decision
  • 适合上线前最后一轮“一键复核”，也适合后续后台按钮直接接成固定恢复流

如果要把这轮上线前验证直接导出成可交接、可归档、可复核的一整包证据，可以直接执行：

cd /www/wwwroot/getDomain
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-export

它会在 runtime/ops-center-reports/go-live-bundles/ 下生成一份 bundle，至少包含：

• 00_env_audit.txt
• 01_go_live_check_summary.txt
• 02_go_live_summary.json
• 03_stack_diagnosis.json
• 04_driver_feed.json
• 05_codex_brief.json
• 06_release_launchpad.json
• 07_doctor_decision.json
• 08_doctor_export_stdout.txt
• manifest.json

其中 manifest.json 会统一标记：

• 环境审计是否已经给出 ready / attention / blocked
• 哪些报告成功
• 哪些报告超时
• 哪些接口当前还缺失
• 推荐优先阅读顺序

同时，bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-review 现在不再只看 “关键文件是否齐全”，还会继续核对：

• 02_go_live_summary.json
• 03_stack_diagnosis.json
• 04_driver_feed.json
• 05_codex_brief.json

这四份摘要里的 launchpad 收口字段是否一致，包括：

• launchpad_recommended_target_node_code
• launchpad_recommended_recovery_label
• launchpad_recommended_recovery_summary
• launchpad_onboarding_bootstrap_pending_nodes
• launchpad_onboarding_acceptance_ready_nodes

如果这些字段发生漂移，即使关键文件都存在，go-live-review.status 也会至少回到 attention， 防止把“局部摘要仍是旧运行态 / 导出时混入不同时间点数据”的 bundle 误判成可直接交付。

另外，从这版开始，driver-run enable_log_sync_key / enable_log_sync_full / disable_log_sync 执行完成后会自动追加一段 log sync post-check，直接回显：

• 当前是否开启
• 当前模式 key/full
• 当前参与节点数
• 当前已覆盖节点数
• 当前样本条数
• 当前缺口节点

也就是说，海外机不需要再手工补 curl /api/v1/ops/overview 去确认“按钮到底有没有真生效”。

如果你想把这条链路进一步做成“一步恢复流”，现在可以直接用：

• bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover
• bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover http://127.0.0.1:8100 full confirm cli/ops

这个组合入口会依次做三件事：

1. 执行 enable_log_sync_key/full
2. 自动复核当前 execution_scene.log_sync
3. 根据当前结果输出下一跳命令

下一跳建议会自动带出：

• scene-node-log
• log-sync-check
• doctor

也就是说，它已经从“能切开关”升级成“能把恢复动作和现场下钻串起来”的单入口。

Node Agent 接管链路现在也有对应的一步恢复流：

• bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-check
• bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-recover
• bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-export
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-onboarding http://127.0.0.1:8100 mainland-worker-01
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-recover http://127.0.0.1:8100 mainland-worker-01
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-recover http://127.0.0.1:8100 mainland-worker-01 confirm ops-center
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-bootstrap-preview http://127.0.0.1:8100 mainland-worker-01
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-bootstrap-run http://127.0.0.1:8100 mainland-worker-01 ops-center
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-acceptance-plan http://127.0.0.1:8100 mainland-worker-01
• bash domain-api/deploy/multi-region/drive_ops_center.sh node-acceptance-run http://127.0.0.1:8100 mainland-worker-01 ops-center

这个组合入口会依次做四件事：

1. 从当前 stack-diagnosis 找出首个接管缺口节点
2. 输出该节点当前 handover 状态
3. 自动生成该节点的 bootstrap plan
4. 再回显当前剩余接管缺口和下一跳建议

如果你希望直接把首个缺口节点的接管材料落成一份目录，而不是逐条复制终端输出，现在还可以直接执行：

• bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-export

它会统一导出：

• stack-first-gap-handover
• agent-gap-check
• node-onboarding
• node-bootstrap-plan
• node-bootstrap-preview
• node-acceptance-plan
• manifest.json

适合三种场景：

• 需要把首个接管缺口节点的落地材料交给现场同事
• 需要让海外 Codex / 后台按钮直接读取一份固定目录
• 需要把“为什么当前还没 ready”收敛成一份节点级证据包

其中 node-onboarding 是新增的节点级收口视图，它会把：

• 当前 handover 所处阶段
• 当前是否已经可以做 onboarding.acceptance
• 建议继续 bootstrap 还是切到 acceptance
• 验收应该走 remote-agent 还是 ssh

统一压成一份结果，而不是让值班同事自己在人脑里拼：

• node-handover
• node-bootstrap-plan
• onboarding.acceptance

如果节点已经进入 acceptance_ready，现在还可以继续走两步：

• node-acceptance-plan
  • 预览这次 onboarding.acceptance 会创建哪些验收子任务
• node-acceptance-run
  • 直接签发这轮接管验收 playbook，进入统一的 ops job / playbook run 轨道

而在还没进入 acceptance_ready 之前，也不再只有“生成本地 shell 方案”这一条路了：

• node-bootstrap-preview
  • 预览这次 onboarding.bootstrap 将创建的接入工单
• node-bootstrap-run
  • 直接签发接入 playbook，统一收进 ops playbook / ops job 体系

这样节点级链路就被拆成三层：

• node-bootstrap-plan
  • 适合要拿到落地脚本、env 内容、命令块的时候
• node-bootstrap-run
  • 适合要把接入动作纳入标准工单追踪的时候
• node-acceptance-run
  • 适合节点已经 ready 后做标准化验收的时候

如果你不想再自己判断当前该走哪一步，现在还有一个更高层入口：

• node-recover
  • 先读取节点当前 onboarding / handover 状态
  • 如果还在接入阶段，自动选择 node-bootstrap-run
  • 如果已经进入验收窗口，自动选择 node-acceptance-run
  • 不带 confirm 时只做决策预览；带 confirm 时直接执行

而且它已经支持兼容降级：

• 如果当前 API 还没有 /api/v1/ops/nodes/{node_code}/handover
  • 自动退回 stack-diagnosis
• 如果当前 API 还没有 /api/v1/ops/nodes/{node_code}/handover/bootstrap-plan
  • 自动退回 /api/v1/ops/agent/bootstrap-plan
• 如果当前 API 还没有 /api/v1/ops/nodes/{node_code}/onboarding
  • 自动退回 handover 兼容视图，再推导当前 onboarding 阶段

另外，Node Agent 安装脚本和 bootstrap 计划现在已经补了多目录口径兼容：

• 优先尝试 ${ROOT_DIR}/domainCheck/...
• 再尝试 ${ROOT_DIR}/domain-api/...
• 最后尝试 ${ROOT_DIR}/deploy/...

这样即使线上节点的实际部署根目录是 domainCheck 扁平包，而不是保留 domain-api 子目录，bootstrap 计划也不会因为安装脚本路径写死而直接失效。

也就是说，海外单入口不会再因为控制面版本过渡期少了某个节点级接口，就直接丢失接管能力。

另外，drive_ops_center.sh 现在输出的 condensed summary 也开始统一带上：

• payload 顶层 contract_navigation
• 当前焦点或当前选中项的 contract_navigation
• preview 返回里的 contract_key / contract_version / contract_primary_endpoint / preview_endpoint / schema_doc_path

也就是说海外单入口不只是“能跑命令”，而是已经能把“这一跳到底消费了哪份协议、该去哪个详情接口、该看哪份 schema 文档”一起打印出来，方便后续给 Codex 驾驶员或后台按钮做真正的协议驱动。

节点现场日志现在也有独立 drill-down 入口，适合在“参与节点在线但没样本”“日志只覆盖部分节点”“想直接盯某一台 worker/controller 现场”时使用：

cd /opt/domaincheck/domain-api

# 通过单入口调后端节点现场日志 API
bash domain-api/deploy/multi-region/drive_ops_center.sh scene-node-log http://127.0.0.1:8100 mainland-worker-01 120 key

# 或者直接走独立检查脚本，看原始返回 + 收口摘要
bash domain-api/deploy/multi-region/check_node_scene_log.sh http://127.0.0.1:8100 mainland-worker-01 120 full

另外，check_ops_plane.sh 现在不再只是顺序打印 overview / nodes / jobs / activity / launchpad 等原始返回，最后还会追加一段 [13/13] condensed summary，把下面这些跨面板判断统一收口成一份 JSON：

• overview 顶部推荐动作
• 现场日志观察 scene_log_observation
• managed nodes 当前需关注节点
• jobs / activity-stream 的运行态摘要
• release launchpad 推荐动作与 rollout preview
• latest release 当前状态
• policy preview sample 的门禁结论

而且这一份 condensed summary 现在还会带一组可直接执行的 recommended_commands，用于把“总检”直接串到“下一跳动作”：

• stack_diagnosis
• driver_feed
• driver_focus_preview
• driver_focus_run
• scene_log
• scene_log_direct
• node_handover
• node_bootstrap_plan
• delivery_queue
• release_launchpad
• release_preview_latest
• release_preview_latest_worker
• release_preview_latest_control
• jobs

在这之上，check_ops_plane.sh 现在还会继续收口两层真正适合自动驾驶消费的字段：

• operator_decision
  • 当前主处理车道，例如 observability / node_handover / release / ops_jobs / steady
  • 优先级
  • reason_code
  • summary
  • next_focus
  • primary_command_key
  • secondary_command_key
• next_actions
  • 已经按 primary_command_key / secondary_command_key 解引用好的下一跳命令
  • 页面按钮、海外 Codex 驾驶员、后续自动编排层可以直接消费，不需要再自己拼接命令

也就是说，现在海外单机执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_ops_plane.sh http://127.0.0.1:8100

不仅能看原始面板，也能在最后直接拿到一份适合：

• 人工值守快速判断
• 海外 Codex 驾驶员自动消费
• 后台后续接“一键总检 / 一键诊断”按钮

的总控摘要。

补充一点：

• 如果当前 overview 还没有直接带 driver_feed.scene_log_observation
• check_ops_plane.sh 也会自动从 execution_scene.log_sync + participation_summary 推导现场日志观察状态

所以即便线上还处在“overview 只有 execution_scene，没有 driver_feed”的阶段， 总检摘要里也依然会稳定给出：

• scene_log_observation.status
• scene_log_observation.status_label
• scene_log_observation.summary
• scene_log_observation.target_node_code
• scene_log_observation.focus_ref

避免海外单脑控制面因为接口层级差异而出现空白状态。

当前推荐的消费顺序也固定下来了：

1. 先看 operator_decision
2. 再看 next_actions.primary_command
3. 如果需要人工复核，再看 next_actions.secondary_command
4. 仍需下钻时，再结合 focus_refs 和 recommended_commands 进入细分面板

这样后续不管是：

• 海外单机人工值守
• 后台“一键诊断 / 一键处理”按钮
• 海外 Codex 作为智能驾驶员

都可以先消费同一份“主决策 + 下一跳”摘要，而不是每个入口各写一套判断逻辑。

同样的口径现在也已经补到了：

bash domain-api/deploy/multi-region/check_ops_center_stack.sh http://127.0.0.1:8100 summary

也就是说，check_ops_center_stack.sh 在以下两种情况下都会输出同一类增强摘要：

• 后端 /api/v1/ops/stack-diagnosis 已经可用
• 后端还没完全切到正式 contract，脚本退回本地兜底汇总

无论走哪条路径，最终 condensed stack summary 里现在都会补上：

• diagnosis.operator_decision
• diagnosis.next_actions
• diagnosis.recommended_commands

这样海外单脑控制面现在已经具备：

• check_ops_plane.sh
• check_ops_center_stack.sh

两条总检入口的统一主决策口径，后续页面、按钮、Codex 驾驶员都可以围绕这三层字段继续收口，不需要分别适配两套不同输出。

现在这套统一解释结果里，最推荐先消费的就是：

• GET /api/v1/ops/stack-diagnosis

因为它会先把：

• contract registry
• link snapshot
• overview
• managed nodes
• release launchpad
• recent playbook runs
• recent activity stream

收口成一份正式 diagnosis，再由 CLI / Codex / 页面继续下钻。

其中 stack-next 的定位是：

• 先读取 GET /api/v1/ops/stack-diagnosis
• 直接消费 diagnosis.next_step
• 再走 POST /api/v1/ops/driver-actions/resolve
• 或 POST /api/v1/ops/driver-actions/execute-resolved

这样海外单入口就不需要再人工从总检结果里抄 action_code，而是可以把“当前默认下一步”直接贯通到预览和执行。

其中：

• driver-preview / runbook-preview
  • 继续直接走 driver-actions/preview
• driver-resolve / driver-run / runbook-run
  • 现在走 driver-actions/resolve / driver-actions/execute-resolved
  • 对普通 driver action 和 runbook sequence 也复用同一套 gate
  • CLI 不再自己推断 直接执行 / 等确认 / 进入 UI / 阻断
• driver-focus-preview / driver-focus-run
  • 先读取 GET /api/v1/ops/driver-feed
  • 默认优先消费 top_recommendation
  • 也可显式指定 entry_key
  • 再统一走 driver-actions/resolve / driver-actions/execute-resolved
  • 会把 focus_ref / primary_focus_ref / secondary_focus_ref 一起透传到 resolve / execute-resolved
  • condensed summary 也会直接打印焦点落点，不需要再人工猜“当前该看哪个 release / execution scene”
  • 这样海外单入口已经能直接围绕“当前最该处理什么”工作，而不是先人工抄 action code
• 页面里的 overview driver recommendation / driver-feed
  • 现在优先走 driver-actions/resolve
  • 执行时走 driver-actions/execute-resolved
  • 由后端统一决定 直接执行 / 等确认 / 先复核 / 进入 UI / 阻断
• codex-focus-preview
  • 现在走 codex-actions/resolve
  • 由后端一次性返回 selected_entry + preview + gate
  • CLI 会保留并展示 selected_entry.focus_ref / gate.focus_ref / 顶层 focus_ref
• codex-focus-run
  • 现在走 codex-actions/execute
  • 由后端统一决定是 直接执行 / 等确认 / 先复核 / 进入 UI / 阻断

当前 codex-focus-run 的门禁规则也已经固定：

• safe_auto
  • 直接执行
• guarded_auto
  • 默认只输出审阅结果
  • 只有显式传 confirm 才执行
• resolve_first
  • 只给出阻断说明，不执行
• open_ui
  • 只给出 UI-only 提示，不执行
• blocked
  • 明确阻断，不执行

补充说明：

• driver / runbook-sequence
  • 仍然保留，作为低层直打执行接口的 legacy 调试入口
  • 更适合排查后端执行器本身，不适合作为日常自动驾驶入口
• 日常推荐优先使用：
  • driver-resolve
  • driver-run
  • runbook-run
  • codex-focus-preview
  • codex-focus-run

二、国外机器部署

在国外机器执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/bootstrap_overseas.sh /opt/domaincheck

脚本会：

• 创建运行目录
• 检查 Python 虚拟环境
• 安装 API 依赖
• 安装 systemd 服务模板
• 在 /etc/default/domaincheck-api 生成环境变量模板
• 给出后续启动命令

三、大陆机器部署

在大陆机器执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/bootstrap_mainland.sh /opt/domaincheck controller

如果后面新增纯 Worker 节点：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/bootstrap_mainland.sh /opt/domaincheck worker

其中：

• controller 表示这台机器承担 redis + runtime-db + scheduler + worker + sync-agent
• worker 表示这台机器只承担 detect-worker

脚本还会在大陆机器生成：

• /etc/default/domaincheck-worker

当前模板已内置同步相关占位配置：

• SYNC_PUSH_ENABLED
• SYNC_SOURCE_REGION
• SYNC_TARGET_REGION
• SYNC_TARGET_API_BASE_URL
• SYNC_SHARED_TOKEN
• SYNC_BATCH_SIZE
• SYNC_POLL_INTERVAL_SECONDS

建议把每台大陆节点自己的身份信息放在这里，而不是直接修改 service 文件正文：

• NODE_CODE
• NODE_REGION=mainland
• NODE_ROLE=control
  • 仅 controller 模板使用
• NODE_ROLE=worker
  • 仅纯 Worker 模板使用
• DB_*
• REDIS_*

四、当前脚本定位

当前入口脚本是第一版“标准化部署脚手架”，优先解决：

• 目录统一
• systemd 模板统一
• 节点环境变量入口统一
• 新增节点时操作步骤统一

当前仓库也已经补出了 Node Agent 的正式运行骨架：

• app.node_agent
• deploy/systemd/domain-node-agent.service
• domain-api/deploy/multi-region/bootstrap_node_agent.sh
• domain-api/deploy/multi-region/build_node_agent_bootstrap_plan.sh
• domain-api/deploy/multi-region/check_node_agent.sh

它的定位不是替代现有 bootstrap，而是为下一阶段“海外控制面统一接管大陆节点”提供正式执行器入口。

当前大陆 bootstrap 还会自动补齐一组最小 Python 依赖：

• fastapi
• uvicorn
• pydantic-settings
• psycopg2-binary
• redis

这样 domaincheck-sync-agent 在大陆 controller 节点上可以直接启动，不会因为 app.sync_agent 缺少 API 侧依赖而失败。

如果要在海外控制面直接为某台节点生成一份可复制执行的 Agent 接入方案，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/build_node_agent_bootstrap_plan.sh \
  http://127.0.0.1:8100 \
  mainland-worker-02 \
  mainland \
  worker \
  https://ops.example.com \
  /opt/domaincheck

它会直接请求：

• POST /api/v1/ops/agent/bootstrap-plan
• 现在也可以先用 GET /api/v1/ops/nodes/{node_code}/handover 看单节点接管详情
• 再通过 POST /api/v1/ops/nodes/{node_code}/handover/bootstrap-plan 生成节点级 bootstrap 方案

并输出：

• token 摘要
• /etc/default/domaincheck-node-agent 的完整 env 内容
• 一段可直接在目标节点执行的安装/启动命令块
• 一份完整可执行的 bootstrap-node-agent-<node_code>.sh 脚本内容
• 一段“写入 /tmp 并立即执行”的一键落地命令块
• 基础健康检查命令

也就是说，现在这份接入方案已经不是“给你一枚 token 自己拼命令”，而是标准化输出：

• env_content
• command_block
• bootstrap_script_content
• bootstrap_run_script_block
• health_check_block

后续无论是人工 SSH 粘贴执行、海外 Codex 远程接管，还是后台按钮化接入，都可以直接复用这一套产物。

如果当前节点已经能在集群心跳里看到，但还没有被正式纳管，现在还可以直接走控制面页面里的新闭环：

1. 打开 运维中枢
2. 在“托管节点”里找到状态为 仅运行态在线 / 未纳管 的节点
3. 点击 纳管接入
4. 补齐 SSH 信息后保存
5. 控制面会立刻生成 Node Agent 接入方案

这样“先看到节点，再纳管节点，再生成接入命令”已经收敛成一条固定流程，不需要再在多处入口之间来回切换。

当前脚手架还额外区分了“自动同步由谁跑”：

• 海外控制面：
  • domain-api
  • 负责接收 runtime/sync-ingest
• 内地 controller 节点：
  • domaincheck-sync-agent
  • 负责按轮询周期把本地最新投影推送到海外控制面

当前还不会自动安装数据库主从或自动创建跨地域同步链路。

原因：

• 当前项目仍处于单 Worker 改造向多 Worker 任务模型过渡阶段
• 真正的任务调度与跨地域结果同步需要后续代码配合落地
• 但当前已经预留同步配置模板与同步记录查询接口，便于后续接入 sync-service
• 当前控制面还会自动把运行态摘要写入 detect_sync_records
  • sync_type=runtime_projection
  • 仅在关键状态变化或达到最小采样间隔时写入
  • 作用是先把“同步观测面”跑起来，而不是替代最终的跨地域结果同步服务
• 当 SYNC_PUSH_ENABLED=true 且配置了 SYNC_TARGET_API_BASE_URL 后：
  • 大陆 domaincheck-sync-agent 会按 SYNC_POLL_INTERVAL_SECONDS 自动尝试推送：
    • 最新一条 runtime_projection
    • 当前积压的 detect_result_projection 批次
  • 目标控制面通过 POST /api/v1/runtime/sync-ingest 接收
  • 若配置了 SYNC_SHARED_TOKEN，接收端会校验 X-Domaincheck-Sync-Token
  • GET /api/v1/runtime/sync-summary 还会返回：
    • detect_result_batches 用于直接观察最近检测任务的结果同步是否已接收、仍待推送或发生失败

五、当前已落地能力

截至 2026-04-16，当前代码已经具备：

• 节点注册与心跳
• 运行态表自动初始化
• 集群节点状态接口
• 检测任务主表与任务项表
• 活跃任务摘要与任务详情接口
• Worker 小批量领取、租约续租、重启释放和过期回收

可验证接口：

curl http://127.0.0.1:8100/api/v1/runtime/status
curl http://127.0.0.1:8100/api/v1/runtime/readiness
curl http://127.0.0.1:8100/api/v1/runtime/cluster
curl http://127.0.0.1:8100/api/v1/runtime/sync-summary
curl http://127.0.0.1:8100/api/v1/runtime/sync-records?limit=10
curl http://127.0.0.1:8100/api/v1/detect/job/active
curl http://127.0.0.1:8100/api/v1/detect/jobs

也可以直接执行一键联调：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_cluster.sh http://127.0.0.1:8100

这条命令当前除了原始接口输出，还会额外给出一段压缩摘要，直接汇总：

• ready / attention / blocking
• 在线控制面 / Worker 数
• busy / stale / offline 节点
• 同步投影 / 接收计数
• 结果批次的：
  • synced
  • delivered
  • pushing
  • projected
• failed
• unsynced

如果要在大陆 controller 节点本机确认“这台机器本身是否已经具备 controller 身份”，还可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_mainland_controller.sh

这条命令会直接检查：

• /etc/default/domaincheck-api 是否存在
• NODE_ROLE=control 是否正确
• SYNC_PUSH_ENABLED / SYNC_TARGET_API_BASE_URL 是否已配置
• domaincheck-api
• domaincheck-worker
• domaincheck-sync-agent 是否已启用并处于运行态

如果要判断“在线 Worker 有几台”和“当前真正领任务执行的是哪台”是否一致，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_worker_participation.sh

这条命令会直接输出：

• detect_worker_nodes 当前在线节点概览
• 最新活跃任务的 claimed_by / status / count
• runtime/status 里的参与度摘要：
  • participation_summary
  • participating_nodes
  • non_participating_nodes
  • log_sync
• 一段压缩摘要 JSON，直接告诉你：
  • 真正执行/领任务的是哪些节点
  • 近窗刚有吞吐的是哪些节点
  • 在线但未参与的是哪些节点
  • 远端日志回传是否开启、来源节点有哪些、最近一次回传时间是什么

建议这样理解：

• 有效执行节点 代表当前在线、理论上可承接检测任务的节点，包含独立 worker，也可能包含 controller 兼跑
• 真正执行/领任务 才是当前这一刻真的在拿任务、跑任务的节点
• 在线但未参与 代表节点在线、可用，但这轮任务还没落到它身上
• 负载待确认 代表节点上报了负载或 busy，但还没观察到明确的已领/执行中/近窗吞吐证据，通常是快照同步窗口问题，不要直接判断为“正在干活”

如果要检查纯大陆 worker 节点自己的配置和服务状态，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_mainland_worker.sh

如果当前是“大陆 controller + 大陆 worker + 临时海外控制面”的联调拓扑，还可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_temp_topology.sh http://127.0.0.1:8100 http://152.53.37.118:8100

这条命令会同时汇总：

• 大陆控制面的 runtime/cluster
• 大陆控制面的 runtime/readiness
• 最新活跃任务到底由谁 claimed_by
• 临时海外控制面的 runtime/cluster

如果要专门检查新的 Release Hub / Rollout 引擎，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_release_hub.sh http://127.0.0.1:8100

它会输出：

• release launchpad
• 最新激活 release
• 最近 release 列表
• deploy.release.control / worker / custom 模板摘要
• 控制面 / Worker / 混合节点批量预检结果
• 当前 release 的 rollout 列表
• 主 rollout 详情
• 主 rollout 对应的 job 列表

如果你想直接从海外控制面命令行触发 Release Hub 的关键动作，而不是先打开页面，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 launchpad
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 preview-latest
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 preview-latest-smart worker
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 latest-package
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 smart-latest worker
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 preview-release 12 control
bash domain-api/deploy/multi-region/drive_release_hub.sh http://127.0.0.1:8100 smart-release 12 control confirm

这条脚本会统一走当前标准接口：

• GET /api/v1/ops/releases/launchpad
• POST /api/v1/ops/releases/from-package/latest/preview
• POST /api/v1/ops/releases/from-package/latest/smart-rollout-preview
• GET /api/v1/ops/releases/package-metadata/latest
• POST /api/v1/ops/releases/from-package/latest/smart-rollout
• POST /api/v1/ops/releases/{release_id}/smart-rollout-preview
• POST /api/v1/ops/releases/{release_id}/smart-rollout

并输出三段固定内容：

• 请求摘要
• 原始响应
• 压缩后的关键信息

另外现在 ops overview 也已经直接内嵌了：

• release_hub.launchpad

也就是说，页面里的运维中枢、check_ops_plane.sh、check_release_hub.sh、drive_release_hub.sh launchpad 已经统一复用同一套发布驾驶舱结论，不需要再分别猜“当前到底该发 Worker、补接管，还是先看 Rollout 阻断”。

如果你想进一步复用 OpsCenter 里的“驾驶动作”，而不是只限于 Release Hub，可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_action.sh \
  http://127.0.0.1:8100 \
  create_release_rollout_worker \
  '{"release_id":12}'

它会统一调用：

• POST /api/v1/ops/driver-actions/execute

所以后续无论是：

• 海外主机手工执行
• 海外 Codex 自动驾驶
• 后台按钮化封装

都可以复用同一套 driver action，而不是再写多份分叉逻辑。

当前 Web 后台也已经新增：

• /#/ops-center

这页就是海外控制面的运维中枢，后续节点纳管、任务审批、release rollout 推进都优先从这里进入。

如果想在命令行里快速看当前运维控制面的“总览 + 活动流 + Release 状态”，可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_ops_plane.sh http://127.0.0.1:8100

这条脚本现在会一并输出：

• top recommendation
• driver recommendations
• ops overview
• ops driver feed
• ops capabilities
• ops blueprint
• ops runbook
• ops nodes
• ops jobs
• ops activity stream
• release launchpad
• latest release
• policy preview sample

其中 ops runbook 里的 release_progression 现在也已经直接复用 release launchpad 结论，不再是另一套独立的默认 Release 判断。

另外，标准作业路径也已经有独立执行入口：

• POST /api/v1/ops/runbook/sequences/{sequence_key}/execute

这样页面里的“标准作业路径”不再直接自己拼 driver action，而是先走统一的 runbook sequence，再由后端决定当前该落到哪个具体动作。

如果只想先看“这条标准作业路径此刻会解析成什么动作、哪些节点、什么 payload”，现在也有独立解析入口：

• POST /api/v1/ops/runbook/sequences/{sequence_key}/resolve
• bash domain-api/deploy/multi-region/drive_ops_center.sh runbook-resolve release_progression

这样页面按钮、CLI、海外 Codex 驾驶员和未来自动调度器，都可以先 resolve 再决定是否 execute，不需要各自复制一套判断逻辑。

另外，当前 GET /api/v1/ops/runbook 返回的每条 control_sequence 里，也会直接附带：

• primary_resolution
• secondary_resolution

也就是说，海外控制面页面现在只拉一次 runbook，就能同时看到：

• 这条路径原本定义的标准动作
• 当前后端实际解析后的动作
• 当前目标节点
• 解析时间

这样前端不需要再为每条路径额外发一次 resolve 请求，标准作业路径的“展示”和“解析结果”也终于收成一份数据。

最近还补了一层“活动流和 runbook 打通”：

• GET /api/v1/ops/activity-stream

现在除了：

• playbook_run
• ops_job
• rollout

活动流里还会自动附带：

• runbook_sequence

它表示“当前标准作业路径此刻解析出的下一步动作快照”。

这样海外控制面在统一活动流里，不仅能看到最近执行回执，也能直接看到：

• 哪条固定路径当前最该进
• 它此刻收口成了什么动作
• 点进去会直接定位到哪张标准作业路径卡片

活动流里的 runbook_sequence 不是新的执行任务，而是驾驶层的“当前路径快照”，用于把“最近发生了什么”和“现在应该走哪条路径”收进同一条观察链路。

现在又继续往前收了一层正式入口：

• GET /api/v1/ops/driver-feed
• GET /api/v1/ops/codex-brief
• bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed
• bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-preview
• bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-run
• bash domain-api/deploy/multi-region/drive_ops_center.sh codex-brief

它会把三类信息统一压成一份“驾驶主线”：

• 当前优先建议
• 其余驾驶建议
• 当前标准作业路径

并明确区分两种执行器：

• executor_kind=driver_action
• executor_kind=runbook_sequence

这样页面、CLI 和未来海外 Codex 都不需要自己再拼“这是一条普通 driver action，还是应该重新走 runbook sequence 执行”，而是直接消费统一 contract。

其中 driver-feed 现在已经有稳定的消费口径：

• top_recommendation
  • 当前默认最该处理的一条驾驶建议
• driver_recommendations
  • 其余普通驾驶建议
• runbook_sequences
  • 当前适合进入的标准作业路径
• activity_focus
  • 当前值得优先关注的活动流焦点
• scene_log_observation
  • 当前现场日志回传是否已经能直接下钻到某台节点现场日志的统一观察摘要

同时，driver-feed.summary 现在也应继续固定带出：

• publish_ready
• publish_status
• publish_status_label

这样页面、CLI、海外 Codex 在只消费驾驶摘要时，也能直接区分：

• 当前只是“可继续收口 / 可继续联调”
• 还是“已经满足正式发布门禁”

而 driver-focus-preview / driver-focus-run 会按这套顺序自动选择目标：

1. 如果命令显式传了 entry_key，优先命中该项
2. 否则优先消费 top_recommendation
3. 如果 top_recommendation 为空，再退回 entries[0]

这样海外主机上的统一 CLI 已经不需要先人工抄：

• action_code
• sequence_key
• node_codes

只要盯住“当前最该处理的一条主线”，就能先预览 contract，再按门禁执行。

其中 scene_log_observation 这一块现在固定会给出：

• status
• status_label
• summary
• target_node_code
• focus_ref

这意味着海外 Codex、后台自动驾驶和人工值班都不需要再各自重算“当前该去看哪台节点的 scene log”， 直接消费这一个块即可。

同时，bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed 和 bash domain-api/deploy/multi-region/drive_ops_center.sh codex-brief 的 condensed summary 现在也会直接带出：

• summary.scene_log_status
• scene_log_observation.status
• scene_log_observation.target_node_code
• scene_log_observation.focus_ref

也就是说，就算不打开页面、不翻 raw JSON，海外机只看 CLI 摘要也能直接知道：

• 现场日志有没有开
• 是不是还在等样本
• 当前应该下钻哪台节点

在 driver-feed 之上，现在又补了一层专门给“海外 Codex / 自动驾驶器”消费的判断结果：

• codex-brief

它不会重新发动作，只负责把每条驾驶建议进一步分级为：

• auto_execute
• confirm_then_execute
• resolve_first
• open_ui
• blocked

并明确告诉消费方：

• 当前动作最终应打哪个 API
• 是直接执行 driver-action 还是走 runbook-sequence
• 当前是低风险设置动作、标准巡检动作、发布推进动作，还是只能进 UI 的阅读动作

同时，codex-brief.summary 现在也应继续固定返回：

• go_live_status
• publish_ready
• publish_status
• publish_status_label

这样海外 Codex 的第一轮判断不需要再自己把“能不能继续执行”和“能不能正式发版”混在一起。

这样海外 Codex、CLI 和后续后台“一键处理”都能共享同一份自动化判断，而不用各自再维护一套风险口径。

另外，codex-brief.focus 现在除了能回退到首条 entry、首条 activity_focus， 也能在“当前没有动作主线，但现场日志已经识别出明确节点目标”时， 直接回退到 scene_log_observation.focus_ref。

这样在“日志回传已开但样本还没形成”的联调现场里， 海外 Codex 不会卡在“没有动作可执行，也没有明确落点可看”的中间态。

如果想专门从命令行盯“哪些节点巡检没收口、谁该先处理”，可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_ops_inspection.sh http://127.0.0.1:8100

如果你不想记这么多脚本名，现在也可以直接只记一个统一入口：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh help

它是当前推荐的“海外控制面统一命令入口”，主要负责把多机联调、Release Hub 和 Driver 动作收敛成一套命令面。

常见用法：

# 在海外控制面本机打包/验包/查看最新发布包
bash domain-api/deploy/multi-region/drive_ops_center.sh release-package
bash domain-api/deploy/multi-region/drive_ops_center.sh release-verify
bash domain-api/deploy/multi-region/drive_ops_center.sh release-show
bash domain-api/deploy/multi-region/drive_ops_center.sh release-launchpad
bash domain-api/deploy/multi-region/drive_ops_center.sh release-preview
bash domain-api/deploy/multi-region/drive_ops_center.sh release-preview-smart worker

# 一次性看控制面总览 + release hub + inspection + participation
bash domain-api/deploy/multi-region/drive_ops_center.sh doctor http://127.0.0.1:8100 http://152.53.37.118:8100

# 只看海外单入口总检摘要
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-diagnosis http://127.0.0.1:8100 summary

# 直接落到首个接管缺口节点
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-first-gap-handover http://127.0.0.1:8100

# 查看单节点 handover 详情 / 直接生成节点级 bootstrap 方案
bash domain-api/deploy/multi-region/drive_ops_center.sh node-handover http://127.0.0.1:8100 mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh node-onboarding http://127.0.0.1:8100 mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh scene-node-log http://127.0.0.1:8100 mainland-worker-01 120
bash domain-api/deploy/multi-region/drive_ops_center.sh node-bootstrap-plan http://127.0.0.1:8100 mainland-worker-01

# 治理 Node Agent 回执队列
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-status mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-records mainland-worker-01 dead_letter
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-flush mainland-worker-01 20
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-replay mainland-worker-01 20
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-replay-record mainland-worker-01 event-ops-123-2
bash domain-api/deploy/multi-region/drive_ops_center.sh queue-discard-record mainland-worker-01 event-ops-123-2 "确认已人工归档"

# 走 Release Hub 标准接口
bash domain-api/deploy/multi-region/drive_ops_center.sh release-hub http://127.0.0.1:8100 latest-package
bash domain-api/deploy/multi-region/drive_ops_center.sh smart-latest http://127.0.0.1:8100 worker
bash domain-api/deploy/multi-region/drive_ops_center.sh smart-release http://127.0.0.1:8100 12 control confirm

# 走 Driver Feed 主线入口
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed http://127.0.0.1:8100
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-preview http://127.0.0.1:8100
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-run http://127.0.0.1:8100
bash domain-api/deploy/multi-region/drive_ops_center.sh driver-focus-run http://127.0.0.1:8100 runbook:release_progression

# 走 Driver Action 标准接口
bash domain-api/deploy/multi-region/drive_ops_center.sh driver http://127.0.0.1:8100 open_release_dialog
bash domain-api/deploy/multi-region/drive_ops_center.sh driver http://127.0.0.1:8100 create_release_rollout_worker '{"release_id":12}'

从这版开始，Node Agent 这组命令的 condensed summary 也开始直接给出“下一步标准命令”：

• node-handover
  • 会附带：
    • recommended_commands.bootstrap_plan
    • recommended_commands.delivery_queue
    • recommended_commands.node_agent_check
    • recommended_commands.ssh_hint
• node-bootstrap-plan
  • 会附带：
    • env / service / bootstrap script 路径
    • install command block 是否已生成
    • bootstrap run script block 是否已生成
    • repo_capability.supports_install_command_block / runtime_may_need_restart
    • 如果仓库代码已支持但接口返回仍旧，summary 会直接提示先执行 runtime-refresh-recover
    • 回头看 handover / delivery queue 的推荐命令
• node-onboarding
  • 会附带：
    • onboarding_stage
    • acceptance.status_code / execution_mode
    • 当前该继续 bootstrap 还是切到 onboarding.acceptance
• queue-status
  • 会附带：
    • recommended_commands.records
    • recommended_commands.flush
    • recommended_commands.replay
• queue-records
  • 会附带：
    • recommended_commands.queue_status
    • recommended_commands.replay

也就是说，海外主机现在不只是“能看到节点卡在哪”，而是看完摘要就能直接知道下一条标准命令该跑什么。

它的边界也刻意保持得很清楚：

• 不直接 SSH 执行远端 shell
• 不自己拼多套业务逻辑
• 只复用：
  • 现有检查脚本
  • drive_release_hub.sh
  • drive_ops_action.sh
  • 后端标准 API

这样后续无论是：

• 海外主机人工执行
• 海外 Codex 自动驾驶
• 后台按钮封装

都能共用一套动作语义，而不是各写各的。

回执队列这条线现在也已经正式纳入这套统一入口：

• 页面可以打开“回执队列治理”抽屉
• driver recommendation 遇到 dead_letter / retrying 会优先打开标准动作模板
• CLI 可以直接执行 queue-status / queue-flush / queue-replay / queue-discard-record

当前这组命令的设计边界也要明确：

• 所有动作都通过正式 ops job 下发
• 当前单条动作只面向 record_visibility=head_only 的可见头部记录
• CLI 不直接 SSH 到节点修改 pending / dead-letter 文件

如果希望海外控制面长期固定使用同一套默认地址和身份信息，推荐额外放一份配置文件：

bash domain-api/deploy/multi-region/init_ops_center_config.sh \
  /etc/default/domaincheck-ops-center \
  http://121.204.244.188:8100 \
  http://152.53.37.118:8100 \
  https://api.example.com

然后按实际情况改：

• OPS_ACTIVE_PROFILE
• OPS_PROFILE_NAMES
• OPS_MAINLAND_API_BASE_URL
• OPS_OVERSEAS_API_BASE_URL
• OPS_DEFAULT_CONTROL_PLANE_BASE_URL
• OPS_DEFAULT_REQUESTED_BY
• OPS_DEFAULT_ISSUED_BY
• OPS_REPORT_ROOT

如果要按环境切换，也可以在同一份文件里追加 profile 覆盖，例如：

• OPS_PROFILE_PROD_MAINLAND_API_BASE_URL
• OPS_PROFILE_PROD_OVERSEAS_API_BASE_URL
• OPS_PROFILE_PROD_DEFAULT_CONTROL_PLANE_BASE_URL

然后执行：

OPS_ACTIVE_PROFILE=prod bash domain-api/deploy/multi-region/drive_ops_center.sh config

配好以后，drive_ops_center.sh / drive_release_hub.sh / drive_ops_action.sh 都会自动读取它，不需要每次再手传 URL。

如果要把“发布打包链”也收进统一入口，不再额外记根目录脚本名，现在可以直接用：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh release-package
bash domain-api/deploy/multi-region/drive_ops_center.sh release-verify
bash domain-api/deploy/multi-region/drive_ops_center.sh release-show
bash domain-api/deploy/multi-region/drive_ops_center.sh release-prepare

其中：

• release-package 在当前控制面主机本机生成新的 release/latest_release.json
• release-verify 校验最新发布包与 .sha256.txt
• release-show 查看当前最新发布包摘要
• release-launchpad 一次性查看“最新包 / 最新 Release / Worker 与 Control 预检 / 推荐下一步”
• release-preview 仅预览“最新发布包如果导入为 Release，会是什么样”
• release-preview-smart 仅预览“最新发布包如果走 Worker / Control 智能 Rollout，会命中哪些节点、是否有阻断或待确认”
• release-prepare 打包并生成 final_release_report.json

如果只是为了快速生成契约文件、不想等 smoke 全量检查，也可以临时执行：

bash domain-api/deploy/multi-region/drive_ops_center.sh release-package skip-smoke

如果你准备真正发版，现在推荐先预览、再发布：

bash domain-api/deploy/multi-region/drive_ops_center.sh release-preview
bash domain-api/deploy/multi-region/drive_ops_center.sh release-preview-smart worker
bash domain-api/deploy/multi-region/drive_ops_center.sh publish-latest worker

publish-latest 现在也会先自动打印一次 preview-latest-smart 的预检结果，再继续走正式智能 Rollout。 如果只是想快速判断“现在是不是已经具备发版条件”，优先看 release-launchpad 就够了。

从这版开始，bash domain-api/deploy/multi-region/drive_release_hub.sh <base_url> launchpad 输出的 condensed summary 也会直接附带：

• launchpad.recommended_action_code
• launchpad.recommended_execution_mode
• launchpad.recommended_execution_mode_label
• launchpad.focus_ref
• worker_rollout_preview.execution_mode
• control_rollout_preview.execution_mode

也就是说，海外机只看摘要就能直接知道：

• 当前推荐先补什么动作
• 这次默认应该走 remote-agent、ssh 还是别的执行模式
• 焦点应该落在 release_launchpad、default_rollout_gate 还是后续 rollout

而 bash domain-api/deploy/multi-region/check_release_hub.sh 现在在最后也会多打印一段 condensed summary， 把：

• 当前 release
• launchpad 状态
• worker/control preview 可用性
• 在线 control/worker 节点
• rollout 数量

统一压成一份简报，方便海外值班和 Codex 自动驾驶先读摘要，再决定是否深入看 raw 输出。

如果你想把当前海外控制面的现场快照直接导出成一份交接包，而不是盯着终端刷大段 JSON，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh doctor-export

导出命令会安静落盘，并最终返回：

• report_dir
• meta_path
• manifest_path
• readme_path
• summary
• decision

导出目录默认包含：

• 00_ops_center_stack_summary.txt
• 01_ops_plane.txt
• 02_release_hub.txt
• 03_inspection.txt
• 04_participation.txt
• 05_topology.txt
• 06_contracts_registry.txt
• 07_driver_feed.txt
• 08_activity_stream.txt
• 09_codex_brief.txt
• 10_stack_next_preview.txt
• 11_driver_focus_preview.txt
• 12_activity_preview.txt
• 13_codex_focus_preview.txt
• 15_scene_node_log_<node_code>.txt
• meta.json
• manifest.json
• README.txt

其中 15_scene_node_log_<node_code>.txt 不是固定必有文件。 只有当 stack-diagnosis 已经识别出明确的 node_scene_log 焦点时，doctor export 才会自动追加这些节点级现场日志报告。

这样交接包不只是告诉你“该去看哪台节点”，而是会顺手把这些重点节点的现场日志摘要一起带出来。

其中最值得先看的就是 00_ops_center_stack_summary.txt，因为它会直接给出：

• stack_status
• issues
• next_step
• quick_commands

也就是“当前先处理什么、为什么、下一条命令是什么”。

如果你后面准备让海外 Codex 或后台自动驾驶先读“机器摘要”再决定下一步，优先看：

• manifest.json

而且现在 doctor-export 的终端返回里也会直接附带精简版：

• summary.ok
• summary.required_failures
• summary.required_failure_details
• summary.optional_unavailable
• summary.optional_unavailable_details
• summary.scene_log_reports
• decision.status
• decision.headline
• decision.recommended_commands

也就是说，很多场景下你连打开文件都不用，直接看命令返回就知道当前该先修什么。

它会先把整包报告压成一份统一摘要，包括：

• 哪些报告成功
• 哪些 required report 失败
• 哪些 optional preview 当前不可用
• 当前现场一共暴露出哪些 contract key
• 哪些 preview 已经真正落到了 contract preview

如果海外 Codex、未来后台自动驾驶、或者值班同事不想先翻整包文件，而是希望先拿一份“机器先判断后的结论”，现在可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh doctor-decision

它会自动先生成一份临时 doctor export，再只回传精简后的：

• report_dir
• manifest_path
• summary
• decision

其中 summary 现在除了 surface 可用性，也会继续带出 launchpad 收口口径：

• launchpad_recommended_target_node_code
• launchpad_recommended_recovery_label
• launchpad_recommended_recovery_summary
• launchpad_onboarding_bootstrap_pending_nodes
• launchpad_onboarding_acceptance_ready_nodes

而 decision.evidence 也会同步附带这 5 个字段，保证海外 Codex、后台自动驾驶、值班同事 在只消费 doctor-decision 的情况下，也能直接判断：

• 当前该优先收哪台节点
• 当前更像“还没 bootstrap 接入”还是“已经接入、等待 acceptance 收口”
• 是否还需要继续打开 driver-feed / codex-brief / release-launchpad 深挖

也可以直接对已经生成好的导出目录或 manifest.json 二次读取：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh doctor-decision /tmp/domaincheck-doctor-export-XXXXXX

如果当前只想诊断 mainland 控制面，不想因为默认 overseas 地址不可达而拖慢整次分析，也可以显式关闭 overseas 拓扑：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh doctor-decision http://127.0.0.1:8100 -

同样，doctor-export 和 doctor 也支持把最后一个 overseas 参数写成 -，表示本次跳过 topology。

另外，从这一版开始，控制面自己的 /health 和 runtime/status 也会直接带上运行指纹：

• build.source
• build.package_name
• build.generated_at
• build.commit_sha
• build.commit_ref
• build.manifest_path
• build.route_surface.surface_complete
• build.route_surface.missing_paths

这层不是为了展示漂亮，而是专门用来判断：

• 当前运行中的 API 到底是不是最新部署内容
• 当前实例到底有没有真正挂上 ops/contracts / stack-diagnosis / driver-feed / codex-brief
• 现在遇到的 404 到底是代码没写，还是服务实例没切到当前版本

这个入口的定位很明确：

• doctor-export
  • 面向“完整交接包 / 现场归档 / 人工深挖”
• doctor-decision
  • 面向“先让海外 Codex / 按钮编排 / 自动驾驶做第一轮分流判断”

现在 doctor 导出链本身也带了步骤级超时保护：

• 单个子报告卡住时，不会把整包导出拖死
• 报告文件仍会落盘
• manifest.json.summary.required_failures / optional_unavailable 会把超时或失败记录进去
• 这意味着海外 Codex 拿到的永远是“可判断的现场”，而不是“无结果的悬挂进程”

从现在开始，manifest.json 里不再只有“哪个文件失败了”，还会补一层统一故障语义：

• summary.required_failure_details[].reason_code
• summary.required_failure_details[].label
• summary.required_failure_details[].detail
• summary.optional_unavailable_details[].reason_code
• reports[].failure.reason_code
• reports[].failure.timeout

当前固定口径如下：

• ok
  • 该报告命令执行成功，且接口状态与结构化结果正常
• command_timeout
  • 子命令被步骤级超时保护终止
• command_failed
  • 子命令本身退出失败
• http_unreachable
  • curl 没拿到有效 HTTP 状态，通常是超时、连接失败、网络不通
• http_error
  • 接口返回了明确的 4xx / 5xx
• result_unparsed
  • 命令成功返回，但没有形成可消费的结构化 JSON
• report_missing
  • 导出阶段甚至没有落盘该报告文件

这样后面无论是海外 Codex、后台自动驾驶，还是人工值班，都不需要再靠猜：

• 是 API 真挂了
• 还是 contract route 没挂齐
• 还是 preview 本来就没有焦点
• 还是单个 report 只是超时

都能直接从 manifest.json 读出来。

同时，manifest.json.summary 也不再只是 surface 成功失败统计，而是固定继续保留 launchpad 的接管缺口摘要：

• review_status_hint
• review_headline
• env_audit_status
• launchpad_recommended_target_node_code
• launchpad_recommended_recovery_label
• launchpad_recommended_recovery_summary
• launchpad_onboarding_bootstrap_pending_nodes
• launchpad_onboarding_acceptance_ready_nodes
• launchpad_alignment.consistent
• launchpad_alignment.target_node_code_consistent
• launchpad_alignment.bootstrap_pending_consistent

这样导出包一旦落盘，后续无论是海外 Codex 二次读取、后台自动驾驶回放，还是人工交班， 都不需要重新翻 07_driver_feed.txt / 09_codex_brief.txt 才知道“下一台该接谁”。

如果 launchpad_alignment.consistent=false，说明：

• go_live_summary
• stack_diagnosis
• driver_feed
• codex_brief

这几份摘要里至少有一层还在消费偏旧或偏离的运行态；此时即使文件都齐，也不应把 bundle 直接当成可交付终稿。

因此后续海外 Codex / 后台自动驾驶如果只读取 manifest.json，也应该优先先看：

• manifest.json.summary.review_status_hint
• manifest.json.summary.review_headline
• manifest.json.summary.launchpad_alignment

这里的 required report 失败 现在口径也固定了：

• 不只是脚本 exit code 非 0
• 如果报告自身已经解析出了 http_status，但接口返回 4xx / 5xx
• 也会在 manifest.json.summary.required_failures 里记为失败

第二批最值得看的文件现在变成：

• 06_contracts_registry.txt
  • 看当前控制面到底暴露了哪些 contract
• 07_driver_feed.txt
  • 看当前主驾驶主线和每条 entry 对应哪份 contract
• 08_activity_stream.txt
  • 看当前活动流、筛选口径和每条 activity 对应哪份 contract
• 10_stack_next_preview.txt
• 11_driver_focus_preview.txt
• 12_activity_preview.txt
• 13_codex_focus_preview.txt
  • 看 preview 最终落到哪份 contract、哪个 endpoint、哪份 schema 文档

需要注意的是，后面这几份 preview 文件现在按“可选导出”执行：

• 即使当前没有可预览焦点，也会保留报告文件
• 文件末尾会带 command_exit_code=1
• 这不是导出失败，而是现场当时没有对应 focus / entry
• manifest.json.summary.optional_unavailable 里也会同步记录这些不可用预览

如果要从海外控制面直接为一台新节点生成 Node Agent 接入方案，现在也可以走统一入口：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-plan \
  http://127.0.0.1:8100 \
  mainland-worker-02 \
  mainland \
  worker \
  https://api.example.com \
  /opt/domaincheck

如果希望直接把接管计划导出到文件，留给异地同事执行或后续自动化系统消费，也可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-plan-export \
  /opt/domaincheck/domain-api/runtime/ops-center-reports/agent-plans \
  http://127.0.0.1:8100 \
  mainland-worker-02 \
  mainland \
  worker \
  https://api.example.com \
  /opt/domaincheck

它会返回：

• output_path
• meta_path

如果只是想在当前机器上快速检查本机 Node Agent 是否已安装、环境文件是否存在，也可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-check

这条脚本会重点输出：

• inspection overview
• condensed summary
• priority queue
• attention only
• participating problems only

如果当前还无法真正部署到大陆机器，也可以先在国外测试机上做“单机模拟多节点联调”：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/simulate_multi_region.sh http://127.0.0.1:8100

这条命令会临时模拟：

• mainland-controller-sim
• mainland-worker-sim-01

用于提前验证：

• runtime/readiness
• runtime/cluster
• 运行中心顶部的多机就绪度结论

结束时按 Ctrl+C，脚本会自动清理模拟节点记录。

如果测试服里已经残留了很久没心跳的旧节点记录，导致 runtime/readiness 一直被离线节点拖成 attention，可以先做清理：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/prune_cluster_nodes.sh --minutes 30 --dry-run
bash domain-api/deploy/multi-region/prune_cluster_nodes.sh --minutes 30

如果只想清理某个确定已经废弃的节点：

bash domain-api/deploy/multi-region/prune_cluster_nodes.sh --node-code mainland-worker-01

如果要判断大陆 Worker 是否已经真正接入，不要只看 systemctl，还要看：

• /api/v1/runtime/cluster 中是否出现对应 node_code
• last_heartbeat_at 是否持续刷新
• role / region 是否符合预期
• metadata.job_id / metadata.cycle_token 是否能在执行时出现
• summary.online_worker_nodes 是否大于 0
• summary.status_counts.busy 是否会在执行中增加

六、第二台大陆 Worker 接入建议

后续新增大陆 Worker 时，建议顺序为：

1. 拉最新代码到新大陆机器
2. 准备与主执行面一致的 Python 环境
3. 配置该节点自己的：
   • NODE_CODE
   • NODE_REGION=mainland
   • NODE_ROLE=worker
4. 执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/bootstrap_mainland.sh /opt/domaincheck worker

5. 启动后在国外控制面检查：

curl http://127.0.0.1:8100/api/v1/runtime/cluster

如果接口里出现新节点，并且心跳持续更新，说明节点接入成功。

如果是第二台及以上大陆 Worker，最少还要确认：

• NODE_CODE 与其它节点不重复
• 连接的是同一套大陆 Redis / runtime-db
• /etc/default/domaincheck-worker 已按该机器单独填写
• 若该机器不是 controller，则不要额外启 domaincheck-sync-agent

七、当前推荐联调命令

国外控制面建议至少保留下面这组命令：

curl http://127.0.0.1:8100/health
curl http://127.0.0.1:8100/api/v1/runtime/preflight
curl http://127.0.0.1:8100/api/v1/runtime/readiness
curl http://127.0.0.1:8100/api/v1/runtime/cluster
curl http://127.0.0.1:8100/api/v1/detect/status
curl http://127.0.0.1:8100/api/v1/detect/job/active
curl http://127.0.0.1:8100/api/v1/detect/jobs?limit=5

如需一次性确认控制面和执行面都接通，可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_cluster.sh http://127.0.0.1:8100

如需直接拿到“控制面 / 执行现场 / 远端日志回传 / 同步 / 下一步动作”的统一快照，可以执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_ops_link_snapshot.sh http://127.0.0.1:8100

如果要把“协议版本 / 控制面驾驶建议 / 节点托管状态 / ReleaseHub 门禁 / 最近 playbook run / 最近活动流”一次性收口成海外单入口总检，可以直接执行：

cd /opt/domaincheck/domain-api
bash domain-api/deploy/multi-region/check_ops_center_stack.sh http://127.0.0.1:8100

# 如果只想看最终收口，不想展开全量 JSON
bash domain-api/deploy/multi-region/check_ops_center_stack.sh http://127.0.0.1:8100 summary

这条总检入口的定位不是替代各类细分检查脚本，而是给海外控制面提供一个固定起手式：

1. 先确认 API 与 ops/contracts 已加载的是哪一版 contract
2. 再确认 link-snapshot / overview 当前推荐你先处理什么
3. 再看托管节点、Node Agent、回执队列是否健康
4. 最后确认 ReleaseHub 当前能不能进入正式 Rollout

当总检发现某一层异常时，再继续下钻：

• 协议注册表异常：check_ops_contracts.sh
• 控制面驾驶面异常：check_ops_plane.sh
• 节点托管 / 回执队列异常：check_node_agent.sh
• 发布门禁 / Launchpad 异常：check_release_hub.sh

check_ops_center_stack.sh 现在在最终 condensed stack summary 中还会额外产出统一诊断层：

• diagnosis.surface_status 当前总检表面层是否完整联通，典型值为 healthy / partial / broken
• diagnosis.automation_status 当前海外单脑自动化执行面是否真正可接管，典型值为 ready / attention / blocked
• diagnosis.stack_status 面向人和 Codex 的最终收口结论
• diagnosis.issues 已排序的问题清单，附带 code / severity / layer / commands
• diagnosis.next_step 默认下一步动作码、来源和推荐命令
• diagnosis.quick_commands 一组可以直接复制执行的收口命令

这意味着后续无论是：

• 海外 Codex 驾驶员
• 海外控制面按钮
• 人工终端排障

都可以先消费同一份 diagnosis，而不是再先人工判断“这次先跑哪个脚本”。

如果当前后端已经升级到新 contract，check_ops_center_stack.sh 会优先直接调用：

• GET /api/v1/ops/stack-diagnosis

只有当这个 endpoint 还未上线时，才会自动回退到本地聚合模式。

而 drive_ops_center.sh stack-next 不会回退到旧逻辑。

原因是它的职责不是“猜一个差不多的下一步”，而是严格消费 diagnosis.next_step 这份正式 contract。

所以如果你执行：

bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next

返回的是 404 Not Found，应直接理解为：

• 当前运行中的控制面 API 版本还没升级到支持 GET /api/v1/ops/stack-diagnosis
• 或代码已同步，但 domaincheck-api 还没重启

此时优先执行：

git status
bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-recover http://127.0.0.1:8100
curl -sS http://127.0.0.1:8100/api/v1/ops/stack-diagnosis

确认 endpoint 已存在后，再继续用 stack-next。

观察重点：

• 控制面节点心跳应持续刷新，而不是只在 API 启动时更新一次
• 大陆 Worker 节点在运行检测时应显示 busy
• detect/job/active 应能看到当前任务总量、完成量、节点分布和最近事件
• detect/jobs 可用于回看最近几轮任务是否正常收敛
• 当代理池暂时为空但允许直连时，检测控制页会显示 降级直连
• 当代理池为空且不允许直连时，检测会话阶段会显示 等待代理
• runtime/cluster.summary 中应能直接看出：
  • 当前在线控制面节点数
  • 当前在线 Worker 节点数
  • 当前 busy / stale / offline 节点清单
• runtime/sync-summary 中可直接查看：
  • 是否启用同步推送
  • 当前配置的源地域 / 目标地域
  • 最近同步记录和状态分布
  • 若当前还未接入真正的 sync-service，也应至少能看到：
    • runtime_projection
    • detect_result_projection
  • 接入自动推送后，还应能看到：
    • runtime_push
    • runtime_ingest
    • detect_result_ingest

大陆 controller 节点建议额外确认：

systemctl status domaincheck-sync-agent --no-pager -l

如果同步配置已填写完整，则期望：

• domaincheck-sync-agent 为 active (running)
• 海外控制面的 runtime/sync-summary 中能同时看到：
  • runtime_projection
  • runtime_push
  • runtime_ingest

七点五、上线前统一总检

如果当前已经进入“海外单脑控制面 + Node Agent + ReleaseHub”这条正式链路，建议在发版或切正式流量前固定先跑：

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-check http://127.0.0.1:8100 http://152.53.37.118:8100 summary

对应的正式 API 汇总入口是：

curl -s "http://127.0.0.1:8100/api/v1/ops/go-live-summary?base_url=http://127.0.0.1:8100"

CLI 脚本会优先读取这条 API；如果当前运行中的服务还没重启到最新版本，才会自动回退到本地聚合逻辑。

它会统一收口这些层面：

• stack-diagnosis
• contracts
• runtime-build-info / route_surface
• release-launchpad
• managed nodes / remote-agent ready
• overview / execution_scene / log_sync
• 本机 check_node_agent.sh 探针

返回里至少会给出：

• go_live_status
• blocking_reasons
• warnings
• launchpad_recommended_action_code
• launchpad_recommended_target_node_code
• launchpad_recommended_recovery_label
• launchpad_recommended_recovery_summary
• launchpad_onboarding_bootstrap_pending_nodes
• launchpad_onboarding_acceptance_ready_nodes
• next_step_action_code
• operator_lane
• operator_title
• log_sync_state
• log_sync_covered_nodes
• recommended_commands

现在推荐这样理解：

• blocking_reasons 只看真正阻断上线的项
• warnings 代表还能继续联调，但当前还不建议直接宣称“全部收口”
• launchpad_recommended_target_node_code / launchpad_recommended_recovery_label 代表 launchpad 已经明确告诉你“该收哪台节点、优先补哪一步”
• launchpad_onboarding_bootstrap_pending_nodes / launchpad_onboarding_acceptance_ready_nodes 用来快速判断当前是“还没接入”还是“已经接入但还没跑完验收”
• recommended_commands.next_step 就是当前最值得先跑的一条命令
• recommended_commands.log_sync_logs / recommended_commands.log_sync_inspection 用来补现场日志样本与参与节点观测闭环

建议把它当成正式上线前的固定起手式，而不是继续手动拼一组零散检查命令。

八、后续演进

后续会继续补：

• 运行库初始化脚本
• 节点配置模板
• 结果同步服务
• 多 Worker 调度服务模板

配套设计文档见：

• docs/16_domainCheck_多机检测与跨地域部署设计.md