# OpenClaw Agent Control Board

> Source of truth for multi-agent work across the Windows PC workspace and the VPS `/opt/service` workspace.

## Mission

Bring the Windows 11 always-on PC, Tencent Cloud VPS OpenClaw Gateway, phone Control UI, optional Tailscale path, and later channels such as QQ into a controlled multi-device OpenClaw workflow.

## Current Decision

- Shared mechanism: use the VPS Gitea repository as the durable sync point.
- Repository mode: standalone Gitea repository `openclaw-control-plane`.
- Repository URL: `https://git.smartmotor.cloud/wangzhendong/openclaw-control-plane.git`.
- Authentication mode: HTTPS access from both the Windows PC and VPS.
- Default branch: `main`.
- PC control-plane path: `D:\openclaw-control-plane`.
- VPS control-plane path: `/home/ubuntu/openclaw-control-plane`.
- Secrets policy: no password, token, API key, or `OPENCLAW_GATEWAY_TOKEN` may be written into repo files, handoffs, evidence, or chat.
- Frozen website policy: strict freeze during ICP/public-security filing review. Agents must not change the `smartmotor.cloud` homepage, content reachable from homepage links, static assets, Nginx routing, bind mounts, container images, or `/opt/services/docker-composite.yml` entries that could alter public website output.
- Communication MVP: use Git-backed polling sync scripts under `sync/` plus task files under `tasks/`. This reduces manual pull/push but is not the final async-notification design.
- Sync-health monitoring: CORRECTION monitors tracked heartbeat and error files under `sync-state/`; no separate sync monitor agent is used at this stage.
- Future communication target: when the baseline path is stable, design an event-driven coordinator using Gitea webhooks, Gitea Issues, OpenClaw events, or Cursor SDK agent orchestration.

## Agent Roles

| Role | Scope | May Write |
|---|---|---|
| ORCHESTRATOR | Requirements alignment, task split, dependency tracking, final acceptance | `AGENT_BOARD.md`, `handoff/ORCHESTRATOR.md` |
| PC_EXECUTOR | Windows PC, Tailscale, OpenClaw CLI/node, local service install | `handoff/PC_EXECUTOR.md`, `evidence/pc-*`, `rollback/pc-*` |
| VPS_EXECUTOR | VPS `/opt/service`, Gateway, Docker stack, Nginx, Gitea, approvals | `handoff/VPS_EXECUTOR.md`, `evidence/vps-*`, `rollback/vps-*` |
| PC_VERIFIER | Independent read-only validation of PC executor results | `handoff/PC_VERIFIER.md`, `evidence/verify-pc-*` |
| VPS_VERIFIER | Independent read-only validation of VPS executor results | `handoff/VPS_VERIFIER.md`, `evidence/verify-vps-*` |
| CORRECTION | Detect drift, sync-health failures, conflicts, unsafe changes, missing evidence, and rollback needs | `handoff/CORRECTION.md`, `tasks/T7-correction-monitor.md` |

## Quality Gates

| Gate | Required Evidence | Owner | Status |
|---|---|---|---|
| G0 Requirements aligned | User-approved mission, roles, and acceptance criteria | ORCHESTRATOR | Done |
| G1 Baseline discovered | PC and VPS read-only status snapshots accepted by independent verifiers | PC_EXECUTOR, VPS_EXECUTOR, verifiers | Done |
| G2 Gateway/node pairing ready | PC `node run` evidence and VPS approval evidence | PC_EXECUTOR, VPS_EXECUTOR | Pending |
| G3 Execution smoke test | Harmless command result proves execution came from the PC node | PC_VERIFIER | Pending |
| G4 Persistent service verified | `node install/start/status` and reboot survival evidence | PC_VERIFIER, CORRECTION | Pending |
| G5 Security posture reviewed | Secrets absent, public exposure avoided, least-privilege notes captured | VPS_VERIFIER, CORRECTION | Pending |

## Active Tasks

| ID | Task | Owner | Depends On | Status |
|---|---|---|---|---|
| T0 | Create local control-plane scaffold | ORCHESTRATOR | None | Done |
| T1 | Create standalone Gitea repo for this control plane | User + ORCHESTRATOR | T0 | Done |
| T2 | Sync this scaffold to Gitea and open on PC/VPS Cursor | ORCHESTRATOR + VPS_EXECUTOR | T1 | Done |
| T2.1 | Add polling sync and task-file communication MVP | ORCHESTRATOR | T2 | In Progress |
| T3 | Run read-only PC baseline discovery | PC_EXECUTOR | T2.1 | Accepted |
| T4 | Run read-only VPS baseline discovery | VPS_EXECUTOR | T2.1 | Accepted |
| T5 | Verify PC baseline before any PC change | PC_VERIFIER | T3 | Accepted |
| T6 | Verify VPS baseline before any VPS change | VPS_VERIFIER | T4 | Accepted |
| T7 | Monitor drift, sync-health failures, conflicts, unsafe changes, and missing evidence | CORRECTION | G0 | Claimed |

## Acceptance Criteria Draft

- The PC can act as an OpenClaw execution node connected to the existing Gateway.
- The Gateway continues to coexist with Nginx, Gitea, Confluence, and Postgres on the VPS.
- The existing `smartmotor.cloud` website content remains unchanged during filing review, including homepage content and linked content reachable from the homepage.
- No PC service port is exposed directly to the public internet.
- Tailscale is optional for the OpenClaw public Gateway path, but available for safer device-to-device operations.
- Phone can be used as a control client after the execution path is stable.
- Later QQ or other channels are added only after the Gateway/node path is verified.

## Operating Rules

- Agents must read this file before doing work.
- Executors must not accept work outside their named scope.
- Executors must not validate their own work as complete.
- VPS-related agents must treat the `smartmotor.cloud` website defined by `/opt/services/docker-composite.yml` as frozen: no edits to homepage content, linked page content, routing, static assets, bind mounts, container images, or Nginx rules that could alter what public visitors see.
- Polling sync scripts are convenience automation only. If they report conflict, authentication failure, or unexpected files, stop and let CORRECTION review.
- Sync scripts must publish non-secret heartbeat/error status under `sync-state/`. Heartbeat older than 2 minutes is warning; older than 5 minutes is blocked.
- Task files under `tasks/` are the agent-to-agent work contract. Chat messages are not the source of truth.
- Any system-level change requires a rollback note before execution.
- Any blocking issue must be recorded in the relevant handoff file and surfaced to ORCHESTRATOR.