Multi-server execution and the full Desktop

Design detail moved from the roadmap. Status: Planned; MN0 is a Source candidate.

Multi-server worker execution within one control domain

flowchart TD
    Desktop[Full Desktop app - text and voice] --> API[Authenticated master VPS API]
    CLI[Manual CLI or public SDK] --> API
    Voice[Optional coordinator brain] --> API
    API --> Control[Master VPS Control Node and Swarm services]
    Control <--> Store[Durable state, evidence and receipts]
    Control --> Local[VPS-local supervisor and Maia workers]
    Control --> Laptop[Desktop computer - enrolled execution supervisor]
    Laptop --> LW[Local-to-user Maia workers]
    Laptop --> Events[Authenticated observation ingress]
    Control -->|Fenced assignments| A[Server A execution supervisor]
    Control -->|Fenced assignments| B[Server B execution supervisor]
    A --> WA[Maia workers]
    B --> WB[Maia workers]
    Local --> Events
    A --> Events
    B --> Events
    Events --> Store
    Store --> Views[Authorized snapshots and updates]
    Views --> Desktop
    Views --> CLI
    Views --> Voice

• Use the existing Maia Node executable's reduced execution-only composition, with an exclusive supervisor lock and bounded assignment/evidence spool. It does not open Control SQLite, run another scheduler or serve a worker API. Connect outbound to one pinned Control through a transport the owner has yet to decide (D-150); the candidate is the owning HTTP/WebSocket transport, with no new RPC protocol, SSH dispatcher or direct remote SQL.
• Verified owner/managed-admin authorization and a separate machine principal precede enrollment. The existing local bearer is not enrollment authority. Reuse the one-use five-minute challenge, scoped certificates, tailnet mTLS, revocation and secure-store contract. Team UI/invitations are not prerequisites.
• Enrollment can have zero environments. Placement binds exact Control/Execution Node, Project, Execution Environment, Session/activation, worker incarnation, capability/profile evidence, lease epoch, deadline and budget. Local capacity is not reinterpreted as an enrolled remote Node.
• One Project can use local and several remote hosts; one host can serve multiple authorized Projects. Paths and source files are not implicitly replicated. Prepare exact checkouts/directories and digest-verified authorized artifacts.
• Use five-second heartbeats/four-miss placement stop as the existing target. MN0 freezes lease TTL bounds, the clock error budget, local monotonic expiry anchored to the request, spool quotas and recovery evidence. A lost heartbeat stops placement, not proves cancellation. Revocation fences writes; unreachable external effects remain uncertain. Reconcile lost acknowledgements before replaying starts.
• Handoff is plan → drain → fence → prepare → assign → reconcile, not live process migration. Destination readiness and source/effect safety are mandatory. On Control outage, no fresh admissions/renewals; local supervisors obey finite leases. V1 has no Control high availability or automatic failover.
• A client can close while an independently hosted Control and worker continue. Sleeping the machine hosting the Control Node does not preserve availability.
• First remote candidate: separately granted managed-read-only. Editing, shell, builds and tests by managed workers, locally or remotely, require a named approved containment adapter for each OS/architecture. The unsandboxed local-operator-workspace escape hatch is forbidden for Agent/Project/Routine/ voice/peer execution, not merely remote execution. A worktree is not a sandbox. Record separate read-only-pool and coding-pool verdicts; the former never passes the latter's user journey.

Control Node host and full Desktop delivery

This is the primary requested deployment, not a read-only dashboard or SSH console. Reuse R6 enrollment/placement and R9's one Expo/Tauri application. The master VPS keeps Node state and deterministic orchestration; optional global and Project coordinators run as ordinary managed Maia Agent Sessions there or on an explicitly assigned qualified host (the first version runs no Session on the control Node's host). Desktop owns input/rendering only.

• Full control: configure admitted Workspaces/Projects, open every permitted coordinator/worker chat, send text or voice, inspect evidence/usage/queues, choose eligible placement, steer/cancel, approve exact operations, manage routines, drain/revoke capacity and reconcile failures through public SDK. Missing backend support is visibly unavailable, not a decorative control.
• Connectivity: Desktop and the laptop execution supervisor separately authenticate to one pinned VPS Control Node over qualified private transport. Their user/device and machine identities are not interchangeable. Workers have no direct Desktop API and never inherit the user's broad control credential.
• Availability: close/restart Desktop without stopping VPS work. Laptop sleep makes its capacity stale and triggers the finite lease/recovery policy; do not claim its local workers run while asleep. VPS outage blocks new control/renewals and shows stale/unknown state. No automatic local controller, replicated SQLite, live process migration or unattended replay substitutes for reconciliation.
• Host prerequisite: explicitly qualify the chosen Linux VPS distribution/ architecture, service manager/process ownership, secure machine/provider secret storage, rotation, filesystem/network/process containment, disk/spool bounds, backup/restore, update/rollback and logging. macOS secret-storage evidence is not Linux evidence. Name any missing adapter/dependency before approval and implementation. Likewise qualify local macOS/other Desktop-host execution independently.
• Data boundary: repository roots are host-specific. Local private files stay local unless an exact export/artifact/context policy permits transmission; choosing the VPS does not upload a home folder, credentials or all transcripts.
• Operator validation: PF-21/DF-21 proves real full Desktop control of laptop workers and VPS/other-host workers, disconnect, drain, updates and recovery. It uses separately consented disposable hosts and never restarts a live VPS.