Zero conflicts. Every agent aligned.
5 agents, 1 codebase, 0 merge conflicts. The MCP server that keeps parallel Claude Code, Cursor, and Cline agents aligned.
The coordination pain
Parallel agents without shared awareness produce three failure modes that ship to production.
Silent regressions
Tuesday 3pm. Alice's agent ships User.updated_at. Four minutes later, Bob's agent renames User.id. Tests pass. Prod breaks at 2am because the migration order was wrong.
Duplicated effort
Two agents both implement retry logic. Agent A picks exponential backoff (250ms→8s). Agent B picks linear (500ms, 5 retries). Code review surfaces the divergence — 800k tokens in.
No visibility
Tom asks his agent: “is anyone else working on auth?” The agent answers: “I have no way to know.” Tom shrugs and proceeds. Carol's agent did the same thing 20 minutes ago.
See it run live
Four agents stay aligned in real time without chat tools, merge gymnastics, or shared spreadsheets.
Conflicts caught before code is written
Every announcement reaches every concerned agent before they open a file. Overlaps surface as a paused turn, not a midnight rollback.
How it works
Four steps run before any code is written, then a score decides who consults.
Announce
The agent declares intent: task, target files, affected modules. No code yet.
Detect
The scorer checks every active announcement across six layers and returns a 0-to-100 impact score.
Consult
The coordinator opens a consultation thread and publishes it to the MQTT broker. Each concerned agent reads the event between turns and posts context, constraints, or a resolution. No sidecar process required.
Resolve
Proposals are approved, contested, or re-proposed. The thread closes on consensus. Every decision lands on the dashboard timeline.
Impact score
Every announcement is scored 0 to 100 against active work. The score decides the response.
Six layers, most severe wins. Full details on GitHub →
In-flight awarenessv0.5
Hook-based PreToolUse + PostToolUse hooks let the coordinator see agents start editing files — not just when they finish. Conflicts surface before bytes are written, not after.
Symbol-aware scoringv0.3+
tree-sitter parses 15 languages (TS/TSX/JS/Python/Go/Rust/Java/C#/C/C++/Ruby/PHP/Kotlin/Swift/Bash). Two agents editing the same file but different functions get an annotated reason — not a silent block.
Git co-change scoringv0.5
Files that move together in git history (config + consumer, fixture + test) are scored as related: impact 60 if >50% co-change, 40 if >20%. Catches regressions invisible to filename matching.
Real-time push: MQTT topics and delivery flow
An embedded MQTT broker fans every event to subscribers. Eight topics, end-to-end latency under 50ms.
| Topic | Emitted when | Key payload |
|---|---|---|
coordinator/consultations/new |
A thread is opened | thread_id, subject, initiator_id, target_files |
.../consultations/+/messages |
Someone posts to a thread | agent_id, name, content, type |
.../consultations/+/status |
Thread transitions state | status: open/resolving/resolved/timeout |
.../consultations/+/claimed |
Work-stealing claim (atomic) | claimed_by, thread_id |
.../consultations/+/completed |
Claimed task finishes | agent_id, thread_id, resolution |
coordinator/agents/+/status |
Agent online / offline | status, name, modules |
coordinator/broadcast |
System-wide announcement | arbitrary JSON |
coordinator/quota/update |
Anthropic quota refresh | usage, limit, utilization_pct |
Push delivery flow
Coordination patterns
Four coordination shapes the protocol supports natively. Build them with the 26 MCP tools.
All agents start at once. The coordinator opens a consultation thread the moment two announcements overlap.
[A] [B] [C] [D] | | | | A & C overlap on types.ts → consultation
Agents work in declared order. Each one consumes the prior agent's output before announcing its own work.
[A] → [B] → [C] spec code test handoff between turns
A lead agent splits the mission and dispatches subtasks. Subordinates announce work, consult, and report back.
[lead] / | \ [A] [B] [C] ↑ ↑ ↑ report results
Observer agents watch the timeline. They post warnings or comments without ever announcing their own work.
[A] [B] [C] | | | [obs] reads timeline → posts comment or warning
Wire these patterns yourself via mcp-coordinator's 26 MCP tools — or skip the boilerplate with essaim's pre-built catalog. See essaim's catalog →
Why not alternatives?
Worktrees, lockfiles, CI, orchestrators — none of them know your agent's intent.
…git worktrees?
No. Worktrees isolate filesystems. mcp-coordinator coordinates intent. A clean merge of two incompatible designs still ships a broken runtime. Use both.
…Claude Code subagents?
Subagents coordinate inside one Claude Code session. mcp-coordinator coordinates any MCP client across any session, machine, or vendor. Cursor and Claude Code on different laptops can share one consultation thread.
…Slack and manual coordination?
Slack works because humans read it. Your agent doesn't. mcp-coordinator lets the agent itself ask "is anyone touching this file?" before writing — at a cost of a few milliseconds.
…CI gates and branch protection?
CI catches the conflict after both agents have already burned tokens writing incompatible code. mcp-coordinator catches it before a single line is written. CI is the safety net; this is the harness.
…multi-agent orchestrators?
Orchestrators run agents; mcp-coordinator is the protocol they speak. essaim composes with mcp-coordinator natively. AutoGen and CrewAI ship without conflict detection — pair them with mcp-coordinator and they stop colliding.
…mcp_agent_mail?
Our closest OSS neighbour — Markdown mail committed into your repo, FTS5 full-text search over threads, renewable file reservations. Worth being straight about: its reservations are advisory (conflicts are returned alongside the grant) and so are ours. What it lacks is transport and tenancy — HTTP-only, no stdio, no real-time push, no org/auth/audit layer. What we lack is its full-text search.
npm install -g mcp-coordinator
Install in one command
Architecture & deployment
One agent-loop per developer, one coordinator serving MCP, MQTT, and the dashboard, same shape from laptop to cloud.
The shape of a coordinated session
agent-loop
MCP + MQTT + SSE
agent-loop
TCP 1883 / WS /mqtt
SSE /api/events · UI :3100/dashboard
Agent-loop
A programmatic loop wrapping the Claude CLI (spawn-per-turn claude -p --resume). Holds the MQTT listener, the protocol state machine, and the work-stealing claim logic. Use essaim's loop, or roll your own.
mcp-coordinator server
A Node.js process exposing 26 MCP tools over HTTP/SSE, with the embedded Aedes MQTT broker. SQLite stores threads, agents, and the dependency map. Anthropic quota is pre-flighted before multi-agent runs.
Dashboard
A dashboard at localhost:3100/dashboard, live over an SSE stream from /api/events. Per-agent activity, scoring breakdown, quota widget, decision timeline, and the v0.5 Conflict signals panel with per-layer firing counts over the last 24 h. No auth in local mode; the event stream and REST APIs are JWT-gated for cloud.
Three modes, one experience
Local mode
The coordinator, broker, and dashboard run on your machine. Best for solo work or trying mcp-coordinator before bringing teammates in.
agent-loop
:3100
Aedes · :1883 / /mqtt
:3100/dashboard
mcp-coordinator server start --daemonTeam server
One coordinator on a shared LAN machine. Every developer's agent-loop connects to the same instance. Every announcement, every consultation, visible to the whole team.
agent-loop
coordinator :3100
MQTT :1883 / /mqtt
dashboard /dashboard
agent-loop
agent-loop
mcp-coordinator init --url http://192.168.x.x:3100 --write-mcp-config ~/projectCloud hosted
Self-hosted on a VM or container. Remote teams coordinate through one TLS endpoint, with WebSocket MQTT on port 443. JWT-gated.
agent-loop
coordinator + Aedes
WS /mqtt on 443
TLS + JWT auth
agent-loop
agent-loop
mcp-coordinator init --url https://coordinator.team.com/mcp --write-mcp-config ~/projectGet started
Self-hosted from one npm package — embedded broker and dashboard, no cloud, ready in under a minute.
Install
One npm package. The -g flag adds the mcp-coordinator command to your PATH. No separate broker, no database to provision. Requires Node.js 22+.
First-time setup
Creates the config directory, writes a default config.json, and prints the .mcp.json snippet for your MCP client (Claude Code, Cursor, Cline). Add --write-mcp-config <path> to merge the snippet straight into a project's .mcp.json.
Start the server
Boots the MCP server, embedded MQTT broker, and dashboard on localhost:3100. --daemon backgrounds the process and writes logs to the config directory.
Verify and open
The doctor command checks config, server, MCP responses, and MQTT connections, then opens the dashboard at localhost:3100/dashboard.
Prefer Docker? Pull the multi-arch image instead: docker pull ghcr.io/swoofer/mcp-coordinator:2.3.0. A working compose stack with Caddy auto-TLS ships at examples/docker-compose/.
Want real-time push instead of polling? The Channels sidecar (v0.12+ research preview) streams coordination events into a Claude Code session as <channel> tags. It does not load on a stock install today — the flag is only parsed in an interactive session, availability sits behind an Anthropic-side switch that defaults to off, and every refusal is silent. Polling is the answer that works today: see the polling-vs-push decision guide and the channels-quickstart example.
git worktree add ../feature-x main and run each agent in its own worktree — mcp-coordinator handles "who's editing types.ts"; worktrees handle "no two agents fighting the same inode."
What you'll see in 60 seconds
Tested coordination scenarios
Four canonical conflict patterns, each run end-to-end with two real agents to verify score, thread state, and resolution.
| Scenario | Description | Score | Outcome |
|---|---|---|---|
| S1 | Two agents announce work on the same file at the same moment | 100 | Consultation thread opens, both agents post context, consensus reached, both proceed |
| S2 | Two agents announce work inside the same feature module | 30 | Auto-resolved, both agents notified for awareness |
| S3 | Agent A's module depends on Agent B's current output | 80 | Dependency flagged, dependent agent waits or replans |
| S4 | Fully independent tasks, no shared files or modules | 0 | No conflict detected, both agents proceed in parallel |
Enterprise & Compliance
Built for compliance from the foundation up. v2.0.0 ships full Phase 2 OAuth 2.1, multi-IdP SSO, and an HMAC-keyed hash-chained audit log — the capabilities regulated-industry and SOC 2 Type II deployments actually need to assemble an audit dossier.
| Capability | Status | Aligned with |
|---|---|---|
Multi-tenant org_id isolation across 14 tables |
Shipped v0.7 | SOC 2 CC6.1 · GDPR Art. 32 |
| OAuth 2.1 + RFC 8628 device flow + cookie sessions + service tokens (Phase 2) | Shipped v0.8 | SOC 2 CC6.1 · CC6.6 · CC6.7 |
| Multi-IdP SSO — GitHub OAuth App + GitHub App + Google + generic OIDC | Shipped v0.9 → v0.10 | SOC 2 CC6.1 · centralized identity |
| Audit log table (append-only data layer) + 39 event types Tier 1/Tier 2 | Shipped v0.7 → v0.8 | SOC 2 CC7.2 · CC7.3 |
SHA-256 hash chain on every audit_log row (tamper-evidence) |
Shipped v0.9.1 | SOC 2 Type II · CC7.3 |
JWT — HS256 pin · RFC 6750 · zero-downtime rotation + rotate-jwt-secret CLI |
Shipped v0.7 → v0.9.2 | SOC 2 CC6.1 |
OIDC id_token RS256 signature + iss + aud + nonce verification |
Shipped v0.9 → v0.10.1 | OIDC Core 1.0 §3.1.2.1 |
EncryptionProvider interface (passthrough default) |
Shipped v0.7 | Hook for envelope encryption |
Encryption-at-rest for idp_*_token + SQLCipher whole-DB |
Planned v0.10.x | SOC 2 CC6.1 |
| Per-org DEK + BYOK (AWS KMS / GCP KMS / Vault) | Future | Regulated industries |
GDPR /export & /delete endpoints + Art. 17 procedures |
Procedures shipped · endpoints future | GDPR Art. 15 · 17 · 20 |
| Retention policies + audit log surface UI | Sweeper shipped · UI future | SOC 2 · GDPR minimization |
mcp-coordinator is not SOC 2 certified — certification is auditor work, not code. We ship the architectural hooks (multi-tenant isolation, audit log, encryption interface) so teams pursuing audits get a head start, but the certification itself is your team's process.
FAQ
Quick answers to common questions about coordination, deployment, and integration.
Does this replace git worktrees?
Is it production-ready?
doctor command, structured Pino logs.What does it cost?
Which MCP clients work?
Can multiple repos share one coordinator?
Is auth or JWT required?
How is this different from Aider or Cline's own coordination?
Yet another tool to maintain?
npm install -g, or pull the published image ghcr.io/swoofer/mcp-coordinator:2.3.0 if you prefer Docker. Embedded MQTT broker, SQLite, and dashboard ship in the package. Zero sidecar. Symmetric uninstall reverses the init actions; --purge wipes the data dir.What if the coordinator goes down?
Will my agent lose context between turns?
Which programming languages does conflict detection support?
.jsx, .mjs, and .cjs map onto the JavaScript grammar. A strategy-registry pattern makes adding more languages a one-file contribution.How does conflict detection work under the hood?
working_files (100). Layer 2: depends-on file recently modified (80). Layer 3: module overlap (30). Layer 4 (v0.5): git co-change — files that have moved together in commit history score 60 (>50% co-change) or 40 (>20% co-change).Roadmap
Shipped, in flight, and what comes after.
v0.1 — Server extraction
26 MCP tools, embedded Aedes broker, SQLite state, real-time dashboard. Standalone npm package.
v0.2 — Standalone autonomy
First-run init, doctor diagnostics, daemon log tailing via server logs, symmetric uninstall. Vanilla MCP clients (Claude Code, Cursor, Cline) coordinate via polling out of the box. essaim's agent-loop adds push.
v0.3 — Consistency, hardening & the landing redesign
Graceful shutdown with a returned ServerHandle. Consistency: announceWork wrapped in a transaction, compare-and-set on approveResolution, checkTimeouts moved off the request path into a background sweeper. Security: opt-in MQTT JWT auth with anonymous still the default, /api/reset gated when auth is disabled, path-traversal guard on the dashboard static handler. Plus the 11-section landing redesign, with Open Graph cards, sitemap, and the first full i18n pass.
v0.4 — Health probes & Prometheus metrics
The observability surface, plus a correctness pass on MQTT delivery, SSE resilience and scorer performance. Health handlers: /livez for liveness, /readyz probing SQLite and the MQTT bridge and answering 503 when either is down, /health kept as an alias. And metrics.ts with 10 Prometheus series — 5 counters (announces, threads resolved, MQTT publishes, HTTP requests, auth rejections) and 5 gauges (agents online, threads open, threads resolving, MQTT listeners, SSE clients). The routes were wired into the HTTP server one release later, in v0.5.0.
v0.5 — Semantic conflict detection, in-flight awareness & operability
/api/working-files/{start,stop}: a client PreToolUse hook opens a file, PostToolUse closes it, and a TTL sweeper cleans up after crashes — so the coordinator sees agents start editing, not just finish. Layer 1 unions those in-flight files with recent file_activity. Tree-sitter symbol extraction across 15 languages (TS/TSX/JS/Python/Go/Rust/Java/C#/C/C++/Ruby/PHP/Kotlin/Swift/Bash) feeds Layer 0.5, which re-labels a same-file hit when the two agents are on disjoint symbols instead of blocking silently. Layer 4 git co-change: files that share commit history (config + consumer, fixture + test) score 60 at >50% co-change, 40 at >20%. Operability: /livez, /readyz, and /metrics wired into the HTTP server, /readyz extended with non-gating tree_sitter and git_cochange blocks, 5 more Prometheus series (15 total), 8 new env vars of which 6 also have CLI flags, a PRAGMA user_version downgrade guard, a 1 MiB body cap returning 413, and /api/scoring-stats behind the dashboard's Conflict signals panel.
v0.6 — scoring-stats hardening & docs pass
/api/scoring-stats hardening in handle-rest.ts, and the documentation pass that brought the README, the landing page, and the five translation bundles up to date with the Layer 0.5 and Layer 4 work that shipped in v0.5.0.
v0.7 — Multi-tenant security foundation
Organization scoping (org_id) baked into 14 tables and every MCP/HTTP/MQTT/SSE call. JWT hardened with HS256 pin, RFC 6750 WWW-Authenticate headers, and zero-downtime secret rotation via COORDINATOR_JWT_PREV_SECRET. audit_log table, EncryptionProvider interface, and IdPProvider interface ship as hooks for Phase 2 OAuth, multi-IdP, and encryption-at-rest.
v0.8 — Phase 2 OAuth 2.1 + device flow
Full OAuth 2.1 + RFC 8628 device flow + cookie sessions (__Host-coordinator_session) + service tokens for CI/CD + refresh-token rotation with stolen-token detection (10s grace window, family revoke on reuse) + two-tier audit pipeline (Tier 1 sync never-drop + Tier 2 async batched) + 29 Prometheus metrics on /metrics/auth. Feature-flagged behind COORDINATOR_OAUTH_ENABLED=true; Phase 1 deployments byte-identical when unset.
v0.9 — Multi-IdP + audit chain + rotation tooling
First-class GoogleProvider (id_token verification via jose + JWKS) and generic OIDCProvider (auto-discovery via /.well-known/openid-configuration for Okta / Auth0 / Azure AD / Keycloak / Authentik). Picker UI on /auth/login when 2+ providers are registered. SHA-256 hash chain on every audit_log row (SOC 2 Type II tamper-evidence) + verify-audit-chain.ts operator script. mcp-coordinator rotate-jwt-secret CLI helper with systemd-timer + Kubernetes CronJob automation patterns.
v0.10 — GitHub App + OIDC defense-in-depth + per-provider allowlist strategies
First-class GitHubAppProvider sibling to the OAuth App, with auto-refresh of 8h user-to-server tokens via refreshIdpToken. OIDC nonce claim verification (Core 1.0 §3.1.2.1) guards against id_token replay. Four allowlist strategies — memberships / idp_org_id / id_token_groups / none — auto-selected per provider so Google Workspace deploys off the hd claim, OIDC off configurable groups path, GitHub App off either user orgs or installation footprint. 1740 tests across 119 passing files.
LLM Reasoner — gray-zone arbitration (opt-in)
A gated, opt-in layer that sends gray-zone conflicts — deterministic score 30–89 — to a small model for structured arbitration, off by default behind COORDINATOR_REASONER. Design phase: it ships once layer-firing telemetry shows a real gray-zone gap, and it carries a written kill criterion — ripped out after one month of pilot data if it changes fewer than 25% of verdicts, exceeds 100 ms p50 on a cache miss, or costs more than $10 per developer-month.
Encryption-at-rest for IdP tokens
Envelope encryption for users.idp_access_token and users.idp_refresh_token. Master key via COORDINATOR_ENCRYPTION_KEY; per-row DEK derived via HKDF. Shipped in v0.10.5 with column-level rotation support and a self-healing decrypt path for graceful key migration.
v0.11 — pnpm migration + official Docker image
Tooling stack moved from npm to pnpm (Corepack-managed) for faster, deterministic installs and a stricter dep tree. Official multi-arch Docker image now published to GitHub Container Registry (ghcr.io/swoofer/mcp-coordinator) on every release tag with provenance and SBOM attestation. server status exit code now reflects daemon health for clean shell scripting. FK constraints added on coordinator tables to prevent orphan rows on org delete. 5 npm-audit findings cleared (uuid, qs).
v0.12 — Channels Phase 1 (push) + stdio fixes
Push-based delivery via Claude Code Channels: a new mcp-coordinator channel stdio process subscribes to the embedded MQTT broker and surfaces consultation events, agent-status changes, and conflicts as notifications/claude/channel directly into Claude Code — no polling, no sidecar subscriber. Stdio-mode tool calls fixed (no more spurious “MCP tool requires a session” errors). New MCP SDK integration test harness exercises a real client + server end-to-end.
v0.13 — Channels Phase 2 reply tool + chained Docker publish
Channels become bidirectional: a new post_to_thread tool lets a Claude Code session reply directly into a consultation thread over MQTT. CI: the chained release.yml → docker-publish.yml workflow_call now auto-publishes the multi-arch image to GHCR on every release tag without manual dispatch (root-cause was gating on the wrong event field). New operating-modes (polling vs push) guide spells out the choice; list_threads status enum corrected for external integrators.
v1.0 — First stable release: security & supply-chain hardening
The audit-remediation milestone and first major version. Breaking: JWTs now carry a typ claim (access/refresh) — tokens issued before v1.0 are rejected, so every user re-authenticates once after upgrade. Hardens the default install (127.0.0.1 bind via COORDINATOR_BIND, Origin/CORS enforcement, secret redaction on all log paths), closes the supply chain (pnpm 10 with onlyBuiltDependencies, SHA-pinned Actions, digest-pinned Docker base), and adds zod-validated REST endpoints with structured 400s. 110 audit findings remediated across 23 PRs; 0 known vulnerabilities. Followed a day later by v1.0.1: the dashboard's inline script moves to an external dashboard.js so a strict script-src 'self' CSP applies, and SSE responses flush headers immediately so EventSource opens without waiting for the first heartbeat.
v1.1 — Per-run thread scoping + NDJSON logging
Consultation threads now carry a run_id: a run sees its own threads plus every un-scoped one, so an aborted run stops leaking stale thread ids into the next. The filter is run_id IS NULL OR run_id = ?, not strict equality — a run hides other runs but never other sessions, so a human working the same repo stays visible. Announcing without a run_id stays un-scoped and existing clients are unaffected. New --log-json flag (COORDINATOR_LOG_JSON) forces NDJSON output for log aggregators and is forwarded to the detached daemon. Adopted from contributor PR #151.
v1.2 — GitHub OAuth becomes optional
Phase 2 no longer hard-requires a GitHub OAuth App. GitHub credentials are optional both-or-neither like Google, boot requires at least one IdP and fails closed when none is configured, and COORDINATOR_GOOGLE_WORKSPACE_DOMAIN seeds the bootstrap org's IdP allowlist so the first Google sign-in matches an org and becomes admin — previously a Google-only deploy booted to an empty orgs table and denied every login. doctor probes Google credentials and treats GitHub as optional. The v1.2.1 patch marks the tree-sitter grammars --external in the bun --compile binary build and installs Corepack explicitly in the Docker image, since Node 26 dropped the bundled one.
v1.3 — Google provider in the phase2 init wizard
init phase2 was GitHub-only. It now offers independent per-provider toggles with per-provider app-creation instructions, plus --google-client-id, --google-client-secret, and --google-workspace-domain flags for non-interactive runs. The wizard mirrors bootPhase2's rules exactly: both-or-neither per provider, at least one required, GITHUB_ORG only when GitHub is configured. Interactive prompts default to GitHub yes and Google no, so existing runs are unchanged; declining both aborts.
v1.4 — CLI operability pass + grounded docs and examples
Five CLI additions land together: a server restart subcommand, --timeout and --force on server stop, --since / --grep / --level filters on server logs, a --print-only dry run for init, and --json output for service-token issue and list. Ships three reference docs — a 12-question FAQ, a 9-section troubleshooting guide, and a canonical MQTT topic reference — plus eight self-contained integration examples: Go and Node MQTT subscribers, Slack and Discord webhook forwarders, systemd, Fly.io, Traefik, and a GitHub Actions bridge.
v1.5 — External MQTT broker, org-scoped bridge, opt-in Redis multi-instance
The MQTT bridge can now target an external broker (COORDINATOR_MQTT_URL, COORDINATOR_MQTT_EMBEDDED=false, optional username and password) instead of the embedded Aedes one, and it became org-aware: traffic publishes under coordinator/<org>/* with consultation listeners scoped by (org, agent). That closes a tenant-isolation leak where every org's MQTT traffic flowed through coordinator/default/*. Opt-in multi-instance shared state behind COORDINATOR_REDIS_URL adds Redis locks, a shared rate limiter, a membership cache, sweeper leader election, serialized boot migrations, and token-epoch pub/sub — unset, every component keeps its unchanged in-memory single-instance path. Broker-side ACL is deferred.
v2.0 — Node 22 floor, keyed audit chain, auth-path hardening
Breaking: the minimum supported Node is now 22 — better-sqlite3@13 declares engines node >=22 and Node 20 reached EOL on 2026-04-30 — with the CI matrix moved from 20/22 to 22/24. The audit hash chain is now keyed with HMAC-SHA256 derived from COORDINATOR_ENCRYPTION_KEY via HKDF, so DB write access alone can no longer forge a self-consistent chain: new rows carry an hmac-sha256-v1: prefix, existing rows and keyless deployments stay bare SHA-256, and verification rejects an algorithm downgrade. Audit rows now record the real actor id instead of a truncated pseudonym that was reversible from the cleartext id on the same row. Alongside: revocation and admin-route guards on the cookie session path, auto-provision and login-lockout enforcement on the CLI token grant, org-scoped /api/scoring-stats, a POST-only allowlist on state-changing /api/* routes, boot-time encryption of lingering plaintext IdP tokens, and rejection of low-complexity master keys that evade Shannon entropy.
Beyond v2.0 — cross-repo coordination & a frozen public API
Coordination across multiple repositories from a single MQTT broker. A frozen, versioned public REST API with migration guides.