The page taught a role-addressed send that does not exist. fleet_send takes
sessionId, content, timeoutMs, wait, turnId and coordId — never role or prompt
(FleetMcp.java:1096-1108).
Other claims replaced:
- It said every worker is a Claude Code process and the only other kind is a
"remote local LLM". opencode is a first-class launcher kind. The page now says
what really differs: claude-code mounts MCP through an inline --mcp-config,
opencode through a generated opencode.json plus OPENCODE_CONFIG, and opencode
reads provider credentials from its own auth.json.
- It described "fleetd's concurrency policy" and role routing. The real controls
are per-profile maxLoad and weight, plus a placement policy. weighted uses
smooth weighted round-robin and follows weight ratios; it is not cheapest-first
(WeightedRoundRobinPolicy.java:7-48).
- A named profile bypasses placement but not maxLoad, and a full profile fails
the spawn rather than silently moving it elsewhere.
- It named a backend host. The guard's allowlist defaults to an empty list, so
the page names none.
Also corrects the two member roles against Authz: a worker may reply, ask and
read; an architect may also send; only a primary may spawn, stop or drain.
Match the code cutover: daemon name, config (fleetd.yaml), scripts, launchd/
systemd units, module dir, and MCP tool prefix bridge_* -> fleet_*. Kept:
the BRIDGED_MEMBER security marker, mcp__bridge__ (historical mount name), and
the .bridged-worktrees on-disk path. The portable CLAUDE.md block stays
byte-identical with the repo's CLAUDE.md.
wiki: consistency pass vs rewritten Architecture (5-agent review)
Independent cold reads of every page against 1-Architecture found no invariant
violations; fixed the drift the rewrite introduced plus one real contradiction:
- terminology: Channel 1/2 -> Mode 1/2, 'two-channel' -> 'two invariants / two
modes' (Approaches, Team, Home, Sidebar, Message-Server); north/south face ->
SERVER/CLIENT face (Message-Server, 6 spots)
- contradiction reconciled: Architecture now acknowledges a non-MCP *worker*
Stop-hook (POSTs reply to bridged) as well as the split-host-primary hook -
both target bridged, never a broker; Message-Server tier table split into
Unified / Hooked / Unmodified to match
- Approaches: footnote credits bridge_reply (Stop-hook = fallback); §4 subtitle
reframed; <payload> mermaid label de-angled (parse-safe)
- Team: SERVER 'role router' -> 'policy brain'; fan-out sequence quoted; inference edges labeled
- Home/README: CLIENT-face node regains 'status-gated injector'
- Operations: 'broker' -> 'internal broker/queue'; Stop-hook framed as split-host exception
- async ticket/bridge_poll reframed as injection-first (push), poll = non-pane fallback
All 16 mermaid blocks validated with mmdc.
wiki: bridged is the sole communication gateway (no Claude<->broker, no mainline Stop-hook)
Now that every Claude session mounts bridged over MCP, make bridged the ONLY
thing a Claude session talks to. Claude never posts to / polls a broker; async
delivery is bridged injecting an idle pane (event-driven off agent_status). The
broker drops below the gateway line as bridged-owned durability/cross-host infra.
The Stop-hook survives only as a split-host escape hatch that polls bridged (not
the broker).
- 1-Architecture: add the gateway invariant; rewrite Channel 2 as bridged-mediated
async; redraw components + deployment diagrams (broker below gateway, drop
Claude/Hook -> broker arrows); guardrails now bridged-enforced; failure-modes
updated (bridged down = whole gateway down)
- 2-Message-Server: reply-model, reply-envelope (hook posts bridged not broker),
async-duplex sequence, components/API/tech-stack/milestones/trade-offs, both
deployment diagrams
- 3-Approaches: sole-gateway notes in herdr/AgentAPI/queue sections, matrix + recs
- 4-Setup: split-host Stop-hook polls bridged; queue is internal
- 6-Team: detached jobs via bridged async, not broker
- Home + README: 'one gateway' bullet; intros updated
All 16 mermaid blocks validated with mmdc; 2 rendered to PNG for layout.
Declutter every component diagram to show bridged as ONE standalone daemon
split into a SERVER (north) face — MCP server + REST/SSE + policy brain — and
a CLIENT (south) face — status-gated injector + herdr socket client. Claude
sessions are shown as herdr panes that mount the MCP server (call up) while the
client drives them down over the socket.
- 2-Message-Server: main architecture flowchart rebuilt (herd subgraph of
panes + bridged subgraph with srv/cli); intro reframed; split-host node label
- 1-Architecture: components diagram — bridged subgraph with SERVER/CLIENT faces
- 6-Team: topology — bridged split into faces + role router; worker bridge_reply
- Home + README: overview flowchart — bridged subgraph with SERVER/CLIENT faces
All 16 mermaid blocks validated with mmdc.
Dai Ha
kevin