wangzhendong/openclaw-control-plane
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add polling sync communication layer

Browse Source 
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
wangzhendong
2026-05-15 11:11:18 +08:00
parent 42181b9965
commit b5acead1e1
11 changed files with 481 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
handoff/ORCHESTRATOR.md
View File

@@ -22,18 +22,22 @@ Bootstrap the shared Gitea-backed control plane, then coordinate read-only basel
- 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 this path correction to Gitea.
2. Run G0 requirements and acceptance review with the user.
3. Assign PC and VPS read-only baseline tasks in their respective Cursor windows.
4. Require verifier review before any mutation.
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