Progress and Demo Guide

What Works Now

• Team members can sign in to the mission control interface.
• Admins can create customer organizations.
• Admins can add and review managed machines.
• The local agent can register a machine and keep its status fresh.
• The system can show container inventory from managed machines.
• The system can detect likely OpenClaw environments without changing them.
• Admins can deploy a new OpenClaw instance through an approved job.
• Admins can take over an existing OpenClaw record after confirmation.
• Admins can run health checks, view logs, and request a controlled gateway restart.
• Admins can create reusable capability records and capability packs.
• Admins can create connection records for tools like ServiceTitan, Google Drive, QuickBooks, and Composio.
• Admins can create workflows, run them step by step in simulation, and review the results.
• Workflow steps are checked against rules before they run, and unsafe steps are blocked.
• Admins can manage capability permissions that control allowed actions and risk levels.
• A workflow can run one approved Google Drive file-list action through a connected record.
• External action results are labeled as Stub or Live Data so demos stay clear.
• Workflows can pause for human confirmation and resume after the phrase is typed correctly.
• Jobs show retry counts, timeout windows, recovery state, and clear failure reasons.
• Machines with old check-ins are marked stale or offline instead of disappearing.
• Interrupted workflows fail safely, while workflows waiting for approval stay paused.
• Browser E2E tests now verify the most important user paths from the running web app.
• Core architecture rules are documented and covered by backend regression tests.
• Baseline production checks now verify configuration, database access, service readiness, bundle readiness, and secret redaction.
• Backup and restore helpers now exist for the local database.
• A deployment runbook explains startup, verification, restart, rollback, and recovery steps.
• Self-hosted Linux deployment can now run through a repeatable script with health checks and validation.
• Rollback can be dry-run first, then explicitly confirmed for a target commit.
• Database backups are compressed, verified, retention-managed, and restore-tested safely.
• Operators can now see system health, failed jobs, stale nodes, and workflow failures from the dashboard.
• A local health-check script can be run manually or by cron to detect API, database, Redis, and status failures.
• A local logs helper gives quick access to API, web, report, database, and Redis service logs.
• The dashboard now starts with one clear System Health answer: Healthy, Degraded, or Critical.
• Operators can open health details for plain-English issues, recommended human actions, and links to the right views.
• Technical fields, IDs, logs, and JSON are hidden by default and available through Show details or Show technical details.
• Major resource details now open in modal views instead of permanent right-side panes.
• Jobs, instances, connections, workflows, nodes, capabilities, permissions, and packs use calmer selected-record detail views.
• MSP operators can upload a shared SSH private key credential, connect a jumpbox, test host access through it, discover resources, and register an access-verified node candidate.
• Access attempts now show a readable transcript with attempt id, route, status, where, why, next action, timestamps, and raw OpenSSH detail hidden until requested.

How To Use It

1. Sign in to mission control.
2. Create a customer organization.
3. Add a managed machine for that customer or for shared infrastructure.
4. Register the agent on the machine so it can check in.
5. Deploy OpenClaw to a managed machine after approval.
6. Manage the OpenClaw instance with safe health, logs, and restart actions.
7. Attach capabilities that describe what the organization or instance is allowed to use.
8. Attach connection records that prepare the system for future SaaS access.
9. Create a workflow that uses capabilities and connections, then run it in simulation.
10. For Google Drive, add the list files action to the workflow and review the returned file list.
11. Turn on confirmation for a capability permission and run the workflow to see it pause.
12. Type the displayed phrase to approve the step and continue the workflow.
13. Review the Jobs page to see timeout and recovery details for operational work.
14. Review the Nodes page to see whether a machine is online, stale, or offline.
15. Open Access / Jumpboxes, upload an SSH private key as a shared MSP credential, and connect a jumpbox.
16. Open Hosts / Node Onboarding, create a host profile, choose direct SSH or the jumpbox route, and run Test Access.
17. Review the access transcript, discovered resources, Docker readiness, and next action before registering the host as a node candidate.
18. Review any blocked workflow step to see which rule stopped it.
19. Adjust capability permissions to control which actions workflows may simulate.
20. Run the validation script before moving to another phase.
21. Run the browser E2E script when the Docker Compose stack is already running.

Known Limitations

• Production readiness is a baseline, not a replacement for a full launch checklist.
• Secrets still come from environment configuration until a vault is added.
• Rollback steps are documented, but full rollback is not automated yet.
• The OpenClaw CLI is a control surface, not a background health component. Only health and channel listing are allowlisted today.
• Some CLI commands that look read-only still create device pairing state, so they remain blocked until they can be run without side effects.
• SaaS sign-in is not connected yet, so there is no OAuth flow.
• Only one outside action exists today: Google Drive file listing.
• Google Drive returns demo data unless a development-only read token is configured.
• Workflow approvals are single-person, step-level approvals only.
• Recovery runs during startup and normal status views, not as a separate background monitor yet.
• Monitoring is local and script-based; there is no external alert delivery yet.
• There is no long-term metrics storage or dashboard charting yet.
• The health model summarizes recorded conditions; it does not perform automatic repair.
• Technical details are hidden by default, so operators must expand them when debugging deeply.
• Retry information is visible, but automatic retry buttons are not available yet.
• Capability permissions can be edited, but not deleted or disabled yet.
• Connection records still do not contain real credentials.
• Composio support remains prepared, not a broad live integration.
• Browser tests do not run real OpenClaw deployment yet; that remains backend and manual validated.
• Credential storage is encrypted for local development, but broad production use still needs Vault or KMS-backed secret management.
• Access verification stops at node candidate readiness. Agent installation and OpenClaw deployment are intentionally not available from this workflow yet.

What's Next

• Add the approved agent installation and registration phase after access-verified host onboarding is stable.
• Add the later OpenClaw deployment workflow only after the node candidate has a registered agent and explicit confirmation path.
• Expand from one safe external action to a small set of approved provider actions.
• Add real OAuth and Composio account handshakes.
• Add secure credential handling with one-time secret capture and protected storage.
• Add automation so routine work can be scheduled, monitored, and reviewed.
• Add richer recovery controls such as manual retry for safe jobs and stronger agent health monitoring.
• Add optional notification channels for local health-check failures.
• Add historical metrics after the self-hosted monitoring baseline proves stable.
• Expand browser coverage as the future org and user interfaces are split out.