unchained/mission-control
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: rewrite core reader journey pages (NetBox-style)

Browse Source
This commit is contained in:
Abhimanyu Saharan
2026-02-11 12:59:37 +00:00
parent c6417bcffb
commit 54f10fac4f
7 changed files with 381 additions and 544 deletions
Download Patch File Download Diff File Expand all files Collapse all files

62
docs/01-overview.md
View File

@@ -1,45 +1,43 @@
# Overview
# Mission Control
Mission Control is the **web UI + HTTP API** for operating OpenClaw.
It’s where you manage **boards**, **tasks**, **agents**, **approvals**, and (optionally) **gateway connections**.
It’s the place you go to coordinate work across people and agents, keep an evidence trail, and operate the system safely.
## Problem statement
## What problem it solves
OpenClaw can execute work (tools/skills) and converse across channels, but real operations need a place to:
OpenClaw can run tools/skills and hold conversations across channels. What’s missing in practice is a control plane that makes this operational:
- **Coordinate** work across people + agents (what’s next, what’s blocked, who owns what)
- **Track evidence** of what happened (commands run, links, logs, artifacts)
- **Control risk** (approvals, guardrails, isolation)
- **Operate reliably** (deployment, configuration, troubleshooting)
- **Coordination**: boards + tasks make it explicit what’s being worked on, by whom, and what’s blocked.
- **Evidence**: task comments capture commands run, links, outputs, and decisions.
- **Risk control**: approvals provide a structured “allow/deny” gate for sensitive actions.
- **Operations**: deployment, configuration, and troubleshooting live in one navigable docs spine.
Mission Control provides that control plane.
## Who uses it
- **Maintainers / operators**: keep Mission Control + gateways healthy, deploy upgrades, respond to incidents.
- **Contributors**: develop backend/frontend changes, run tests, ship docs.
- **Automation authors**: define agent identities, skills, and task workflows.
## Key concepts (glossary-lite)
## Core concepts
- **Board**: a workspace containing tasks, memory, and agents.
- **Task**: a unit of work on a board (status + comments/evidence).
- **Agent**: an automated worker that can execute tasks and post evidence.
- **Approval**: a structured “allow/deny” checkpoint for risky actions.
- **Gateway**: the OpenClaw runtime host that executes tools/skills and runs heartbeats/cron.
- **Heartbeat**: periodic agent check-in loop for incremental work.
- **Cron job**: scheduled execution (recurring or one-shot), often isolated from conversational context.
- **Task**: a unit of work with a status and evidence (comments).
- **Agent**: an automated worker that executes tasks and posts evidence.
- **Approval**: a review gate for risky steps.
- **Gateway** (optional integration): an OpenClaw runtime host Mission Control can coordinate with.
- **Heartbeat**: periodic agent loop for incremental work.
- **Cron**: scheduled execution (recurring or one-shot).
## Out of scope
## What it is not
- Not a general-purpose project management suite (we optimize for AI-assisted operations, not every PM feature).
- Not a full observability platform (we integrate with logs/metrics rather than replacing them).
- Not a secrets manager (we reference secret sources; don’t store secrets in docs/tasks/comments).
- A general-purpose project management tool.
- An observability suite (use your existing logs/metrics/tracing; Mission Control links and operationalizes them).
- A secrets manager (keep secrets in your secret store; don’t paste them into tasks/docs).
## Where to go next
## How to navigate these docs
- Want it running? → [Quickstart](02-quickstart.md)
- Want to contribute? → [Development](03-development.md)
- Want to understand internals? → [Architecture](05-architecture.md)
- Operating it? → [Ops / runbooks](09-ops-runbooks.md)
This repo keeps a small “reader journey” spine under `docs/`:
1. [Quickstart](02-quickstart.md) — run it locally/self-host.
2. [Development](03-development.md) — contributor workflow and CI parity.
3. [Configuration](06-configuration.md) — env vars, precedence, migrations, CORS.
4. [API reference](07-api-reference.md) — route groups + auth model.
5. [Ops / runbooks](09-ops-runbooks.md) — operational checklists.
6. [Troubleshooting](10-troubleshooting.md) — symptom → checks → fixes.
For deeper references, see `docs/architecture/`, `docs/deployment/`, `docs/production/`, `docs/testing/`, and `docs/troubleshooting/`.