Files
openclaw-control-plane/handoff/ORCHESTRATOR.md
wangzhendong b5acead1e1 Add polling sync communication layer
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-05-15 11:11:18 +08:00

1.7 KiB

ORCHESTRATOR Handoff

Role

Own requirements alignment, task decomposition, dependency tracking, and final acceptance.

Current Objective

Bootstrap the shared Gitea-backed control plane, then coordinate read-only baseline discovery on PC and VPS.

Must Read

  • AGENT_BOARD.md
  • OPENCLAW_EXEC_NODE_PLAN.md from the PC workspace if available
  • All role handoff files relevant to active tasks

Current State

  • Standalone Gitea repository: https://git.smartmotor.cloud/wangzhendong/openclaw-control-plane.git.
  • PC local path: D:\openclaw-control-plane.
  • VPS target path: /home/ubuntu/openclaw-control-plane.
  • Access mode: HTTPS.
  • Default branch: main.
  • Strict smartmotor.cloud website freeze is a hard requirement during filing review.
  • Communication MVP uses polling Git sync scripts in sync/ and task files in tasks/.
  • The polling sync is intentionally temporary; design an async notification/coordinator layer when PC/VPS baseline work is stable.

Next Actions

  1. Commit and push the communication MVP files to Gitea.
  2. Ask the user to start or approve starting one sync script on PC and one on VPS.
  3. Run G0 requirements and acceptance review with the user.
  4. Assign PC and VPS read-only baseline tasks in their respective Cursor windows.
  5. Require verifier review before any mutation.

Open Questions

  • Has the VPS pulled the latest control-plane repository at /home/ubuntu/openclaw-control-plane?
  • Should Gitea Issues be used immediately for task tracking, or should AGENT_BOARD.md remain the first source of truth for the initial run?
  • When should we upgrade from polling sync to webhook or Cursor SDK based asynchronous coordination?

Last Update

Control-plane repository scaffold prepared locally.