> For AI agents: the complete documentation index is available at /cafleet/llms.txt, the full documentation bundle is available at /cafleet/llms-full.txt. # Overview CAFleet is a message broker and member registry for coding agents. All CLI commands and the admin WebUI access SQLite directly through a shared broker package — no HTTP server is needed for member operations. Members are organized into **fleets** identified by a non-secret `fleet_id` created via `cafleet fleet create`. Members sharing the same fleet can discover and message each other through fleet-scoped routing. ## Core terms | Term | Definition | Links to | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | fleet | isolated namespace partitioning members; identified by a non-secret integer `fleet_id` | [Fleet isolation](#fleet-isolation) | | root Director | the member created by the `fleet create` bootstrap; the only member that may own other members | [Member lifecycle](/cafleet/concepts/member-lifecycle.md) | | member | a registry entry spawned by the Director via `cafleet member create`, bound to a multiplexer pane (tmux or herdr) | [Member lifecycle](/cafleet/concepts/member-lifecycle.md) | | placement | the row linking a member to its multiplexer session/window/pane and backend | [Data model](/cafleet/spec/data-model.md) | | broker | the data-access layer all CLI commands and the WebUI share; writes SQLite directly | Overview (this page) | | message | one delivered message; lifecycle `input_required → completed` | [Message envelope](/cafleet/spec/message-envelope.md) | | inline preview | the 2-line message preview the broker keystrokes into the recipient's pane | [Multiplexer backends](/cafleet/spec/multiplexer-backends.md#push-notifications) | | poll / ack | how a recipient fetches and then confirms consumption of a message | [CLI options](/cafleet/spec/cli-options.md) | | coding-agent backend | the binary in a member pane: `claude`, `codex`, or `opencode` | [Coding agents](/cafleet/concepts/coding-agents.md) | | monitor member | the dedicated watcher member spawned by the `fleet create` bootstrap (re-spawned mid-run via `cafleet member create --role monitor`); it hosts the fleet's wake loop, classifies member panes on each wake, and contacts the Director only when attention is needed | [Monitoring](/cafleet/concepts/monitoring.md) | ## Fleet isolation The non-secret `fleet_id` partitions members for routing. The broker performs no authentication: a fleet is an organizational boundary, not a security boundary. The subject member rows determine their fleets; registration requires a valid, active fleet. Cross-fleet sends have a distinct error: `members {from} and {to} are not in the same fleet.` differs from `Destination member not found: {to_id}` for a missing recipient. [Fleet creation](/cafleet/spec/cli-options.md#fleet-create) registers the root Director and monitor atomically. [Fleet deletion](/cafleet/spec/cli-options.md#fleet-delete) soft-deletes the fleet; the root Director is protected from individual member deletion. ## CLI The `cafleet` CLI has seven entry points — four top-level commands and three command groups: | Entry point | Scope | Subcommands | | ----------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | `setup` | one-time onboarding: brings the database to the current schema and installs the coding-agent assets | — | | `doctor` | environment check: a three-section diagnosis covering the multiplexer, the database schema, and the coding-agent installs | — | | `server` | serves the admin WebUI | — | | `monitor` | the supervision scheduler, run as `cafleet monitor FLEET_ID` | — | | `fleet` | fleet lifecycle | `create`, `list`, `show`, `delete` | | `member` | member lifecycle + keystroke interaction | `create`, `delete`, `show`, `list`, `prompt`, `ping`, `capture` | | `message` | the message broker | `send`, `broadcast`, `poll`, `ack`, `show` | `member` is the single home for the member lifecycle — spawn, teardown, introspection (`show`, `list`), and keystroke interaction (the `kind` column in list output carries the three-value union distinguishing the root `director`, the fleet's `monitor` member, and ordinary `member` rows). The canonical CLI surface — every subcommand, option, and option source — lives at [CLI options](/cafleet/spec/cli-options.md). ## WebUI A browser-based dashboard served as a SPA at `/`, with no login: a fleet picker, then a Discord-style unified timeline per fleet — a member sidebar, unicast and broadcast messages, and a bottom input parsing `@ text` and `@all text`. Every send goes out as the fleet's root Director — the operator never registers as a member to use the dashboard. The full API surface and per-member routes live at [WebUI API](/cafleet/spec/webui-api.md). ## Monitoring A fleet is supervised by its **monitor member** — a dedicated watcher spawned by the `cafleet fleet create` bootstrap that classifies member panes on each wake of the `cafleet monitor` loop and contacts the Director only when something needs attention; the Director owns every supervision action. See [Monitoring](/cafleet/concepts/monitoring.md). ## Design document workflow CAFleet ships design-document skills that coordinate a Director and members entirely through `cafleet message send`, so every inter-member message is persisted and auditable. Follow the [Design document workflow](/cafleet/how-to/design-doc-development.md).