# CAFleet

> Message broker and member registry for coding agents.

## Docs

- [Quickstart](/cafleet/quickstart.md): Create a fleet, send a message, and close the team from your coding-agent pane inside tmux or herdr. Use the literal IDs returned by each command. Run each CAFleet command in its own shell-tool invocation.

## Others

- [Coding agents](/cafleet/concepts/coding-agents.md): cafleet supports three coding-agent binaries inside member panes. The backend is selected per member with --coding-agent {claude,codex,opencode}, and mixed-backend teams are allowed: a single Director may spawn all three in the same fleet with no broker-level differences. The value is recorded in the placement's coding_agent column. Plain cafleet setup installs the skills and preset for all three backends in one run; --coding-agent narrows the selection — see CLI options § cafleet setup. The flag means slightly different things per command: cafleet fleet create --coding-agent is required, operator-declared metadata — cafleet does not spawn the root Director's process and cannot auto-detect what is already running in the calling pane, so the operator states the backend the Director is actually running on.cafleet member create --coding-agent both selects which backend is spawned and is recorded as placement metadata. When the flag is omitted, the member — every role — inherits the spawning Director's placement backend (an explicit value still wins). Each backend is spawned with flags that enable its Bash tool with no runtime permission prompts. The per-backend spawn argv, shell-command posture, and sandbox trade-offs are specified in Coding-agent backends § Spawn argv.
- [Member lifecycle](/cafleet/concepts/member-lifecycle.md): The cafleet member CLI group wraps the two-step "register + spawn a pane" recipe behind cafleet member create and persists the member-to-pane mapping in the member_placements table. An ordinary member is an active registry row with a placement row, other than the fleet's root Director: it is spawned by a Director via cafleet member create and linked to a specific multiplexer pane, window, and session. The root Director is instead bootstrapped by cafleet fleet create and keeps its own placement row since it is pane-bound. Single-Director invariant: A fleet has exactly one Director — the root Director recorded in fleets.director_member_id at fleet create time. Only that root Director may own members: cafleet member create resolves the Director from the fleet row itself, so a member can never be another member's Director by construction. The team model is a single flat tier; there is no team nesting.
- [Monitoring](/cafleet/concepts/monitoring.md): cafleet monitor is a fleet-scoped foreground loop — scan → wake → sleep. The fleet's monitor member hosts it as a backend-resolved long-lived execution in its own pane. The monitor member is a dedicated watcher spawned before any other member (by the cafleet fleet create bootstrap) on a cheap model — its work is bounded classification, not generation. The loop supplies the heartbeat: a plain loop, not agent reasoning, that fires one unconditional fleet-level wake into the monitor member's own pane once per wake interval. On each wake the monitor member classifies every member pane and contacts the Director only when something actually needs attention, so the Director is never nudged by a timer. The monitor member alone owns the execution handle and liveness checks; the Director reacts only to broker signals and never launches or polls the execution. Hosting mechanics differ by backend, while the heartbeat semantics are identical. One monitor loop per fleet; deleting the monitor member kills its pane and the loop process with it. Separately, the database enforces one active monitor member per fleet, including concurrent registrations. A monitor's pane dying does not itself deregister the member: deregister the old member before re-spawning it. Existing duplicate records block migration and require duplicate-monitor recovery.
- [Overview](/cafleet/concepts/overview.md): 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.
- [Storage](/cafleet/concepts/storage.md)
- [Contributing](/cafleet/contributing.md): CAFleet is developed using its own CAFleet-orchestrated skills — the repository dogfoods the spec-driven-development flow it ships. This document covers the project layout, the local development loop, and the contribution path.
- [Design document workflow](/cafleet/how-to/design-doc-development.md): Develop a feature through a reviewed design, an interview and an implementation. The cafleet and cafleet-design-doc skills coordinate the teams; give your coding agent one prompt per stage.
- [Run a fleet](/cafleet/how-to/mixed-backend-team.md): Create a supervised team from your coding-agent pane inside tmux or herdr. A Director can use one backend or mix Claude, Codex and OpenCode members; all exchange messages through the same broker.
- [Use the admin WebUI](/cafleet/how-to/use-the-webui.md): The admin WebUI is a browser dashboard for watching and joining a fleet's message traffic (Overview). It is the only surface that needs a running server — CLI commands write to SQLite directly and never require one. Its writes are messages and the monitor controls (the wake interval and the forced wake); everything else is read-only.
- [CLI options](/cafleet/spec/cli-options.md): How the unified CAFleet CLI (cafleet) accepts configuration parameters. This page catalogs the arguments, conventions, and error strings.
- [Coding-agent backends](/cafleet/spec/coding-agent-backends.md): Every member pane runs one of three coding-agent binaries: claude (Claude Code), codex (OpenAI Codex CLI), or opencode. The backend is recorded per member in member_placements.coding_agent; selection and inheritance via --coding-agent, mixed-backend teams, and identity delivery are covered in Coding agents. This page specifies each backend's spawn argv, auto-approval posture, model-flag format, and version/config requirements.
- [Data model](/cafleet/spec/data-model.md): The Message payload is fully relational: every routing field plus the message body lives in its own typed column. The only JSON TEXT blob is members.member_card_json. The database is SQLite, accessed synchronously and bundled into the binary; the schema is managed by a chain of SQL migrations embedded in the binary — run cafleet setup to migrate to head (idempotent, data-preserving; see Storage). The complete column-level DDL contract is an optional reference for reimplementers: Repository specification. Fleet operation uses the CLI and bundled contract pages; opening that URL is not required for offline operation. Minted ids are never reused and real ids are always >= 1.
- [Message envelope](/cafleet/spec/message-envelope.md): The shape of a Message envelope as it is persisted in SQLite, returned by the broker layer, and rendered by the CLI.
- [Multiplexer backends](/cafleet/spec/multiplexer-backends.md): cafleet hosts every coding-agent member inside a terminal-multiplexer pane. The multiplexer is abstracted behind the Multiplexer Protocol, so the spawn, keystroke-delivery, capture, and teardown paths are backend-neutral. Two backends ship today: tmux and herdr (herdr.dev). Both satisfy the same Protocol, so every member * path behaves identically regardless of which one is active. Pane ids are treated as opaque strings end to end — tmux ids look like %7, herdr ids look like w1:p1; cafleet stores and passes them verbatim and never parses them. The pane is also cafleet's only push channel: message delivery stays pull-based (recipients drain the persisted queue with cafleet message poll), and the broker keystrokes an inline preview into the recipient's pane after persisting a message — see Push notifications.
- [WebUI API](/cafleet/spec/webui-api.md): Base path: /api