10 Cross Host Messaging
Dai Ha edited this page 2026-08-31 10:12:16 +07:00
Clone

Wiki Page Revisions

6 Commits

Author SHA1 Message Date
Dai Ha 48c8a1e328 Ch.10: cross-host lead-to-lead already shipped; rename the proposed exchanges
The scope note said only the single-host reply inbox was as-built. That is
wrong: lead-to-lead coordination across hosts works today over a shared AMQP
vhost (coordinator: block, fleet_send{coordId}, LeadMailbox + LeadCoordLoop).

It deliberately does not use the exchange topology in section 3 — it is a
durable mailbox per lead, carrying coordination only, never a task. Said so at
the top and added a short as-built table to section 9, so the chapter cannot be
read as 'none of this is real yet'.

Also renamed the proposed exchanges bridge.* -> fleet.* with the product.
2026-08-31 10:12:16 +07:00
Dai Ha 3357960dd1 CB-634: rename bridged -> fleetd across the wiki
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.
2026-08-25 04:08:38 +02:00
Dai Ha e5424f4665 CB-552: sync architect and session docs 2026-08-13 20:19:23 +02:00
kevin 4320c1ca52 Chapter 10: fold in the adversarial review — envelope, dual ack, queue migration
Second-pass (Opus reviewer) findings, accepted and written through:

- §2.1 the message envelope: AMQP-header fields + kinds; sig over exact body
  bytes + canonical header subset (no JSON canonicalization in the security
  path); verify to == routing key; reject-to-DLX on failure. CB-201's descope
  stays right single-host and wrong across hosts — stated.
- §3 footnote corrected: the inbox keying INVERTS (sender-keyed as-built →
  recipient-keyed), so CB-308 is a migration, not a rename; .v2 queue names
  dodge the PRECONDITION_FAILED crash loop on in-place upgrade.
- §5/§6 rewritten as the dual ack model: reply path at-least-once (ack after
  drain), forward path at-most-once (ack BEFORE inject) + INJECTED
  confirmation; basicQos so the backlog stays on the queue.
- §7.4: expiry is gateway-enforced (expiresAt), broker TTL a backstop;
  NO_WAITER answered on arrival.
- §10.1: caps made real by prefetch; expiry sweeper (head-of-line); DLQ
  consumer reports FAILED to the sender; DLQ itself capped.
- §8 checklist: separate confirm/mandatory publish channel (return-before-
  confirm caveat), queue deletion on stop, host-level signed heartbeat with
  profile list, exclusive-lock takeover caveat.
- §9: keying migration + multi-primary named as CB-500's delta.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ZGgxLQ2VpwZhEYoru8rkf
2026-08-10 22:31:45 +07:00
kevin 36bb86588a Chapter 10: resolve the cross-host design review — U8 broadcast + hardening rules
2026-08-10 review decisions, broker-level half (CB-308-side half lands in
docs/CB-308-Multi-Host-Federation.md §7):

- U8 broadcast use case: publish once to broadcast.all / broadcast.<group>,
  the broker copies into every bound inbox; tailored briefs stay N-sends
- invariant 1 broker-enforced via AMQP exclusive consumers (loud, not split)
- invariant 6: per-gateway message signing + roster host check
- U2 walkthrough (§7.4): asks live-only with TTL; late answer dropped + TOO_LATE
- §10 hardening rules: inbox caps→DLQ, amqps + private broker (disk holds task
  text), schema version with tolerant reads, trace id per flow, broker-outage
  semantics (local unaffected, remote fails fast)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013ZGgxLQ2VpwZhEYoru8rkf
2026-08-10 21:54:15 +07:00
Dai Ha b646be108d wiki: add chapter 10 — Cross-Host Messaging & Broker Topology
New design chapter answering the cross-host broker questions: the 7 cross-host
communication use cases (delegate+reply, mid-turn ask, stranded reply, cross-host
spawn, presence, main-pair, orchestrator↔mains), the AMQP exchange/queue layout,
and which exchange+queue belongs to each entity.

Topology: 5 exchanges (bridge.msg topic, bridge.roster topic, bridge.control
direct, bridge.dlx fanout, bridge.delay) → per-entity inbox agent.<gid>.inbox
(durable, consumed ONLY by the co-located gateway → herdr-inject for agents / MCP-
pull for mains), per-gateway control.<host> (durable) + roster.<host> (transient),
shared bridge.dlq. Invariants: single-consumer-per-inbox, publish-by-recipient,
pull-final-hop for MCP clients, keystrokes-never-on-broker, soft-state roster
(persistence boundary). Honest as-built vs proposed split: CB-307's
agent.<target>.inbox consume-and-hold is real (default exchange, already cross-
host-routable); net-new = globalId key + roster/control/DLX planes.

6 mmdc-validated theme-safe diagrams (entity model, topology, ack lifecycle, U1
delegate+reply, U4 cross-host spawn, U5 presence fanout). Sidebar updated.
Anchored to msg.AmqpReplyInbox as-built; tracks CB-308 + CB-500 for proposed.
2026-07-28 16:33:44 +02:00