fred
3884f2de4d
All four findings reproduced before fixing. rev-code-01 was right on each. B2 (blocker, mine). SEAT-IDENTITY provisioning step 4 said to symlink the framework store entry to the seat slot, while the same file says those bridges must not be recreated. The same bridge, told both ways, in one document. I rewrote the resolution and token-location sections when the deploy made them stale and did not carry the change into the numbered steps. Step 4 is gone and the file now says explicitly that no provisioning step links the store to the slot, so the omission cannot read as an oversight. S1 (mine). The guide claimed the helper "attempts a fleet notification" on refusal. The shipped helper does no such thing — its only reference to notification is a comment saying an alert built on the record is best-effort, and there is no send or wake call anywhere in the file. Now: it writes a durable record, the record is what exists, and nobody should wait for a notification that nothing sends. A guide that promises an alert is worse than one that promises nothing. S2. Estate-local content removed from files that ship to every estate: the ~/.mosaic/fleet/bin script paths (dead paths elsewhere) and the 2026-08-18 dates, which dated a specific host's migration rather than describing behavior. The bridge-removal passage now states the ORDERING that matters — remove bridges only after a seat-aware helper can reach the slot, never before — which is the part that transfers. B1. prettier reformatted all three files. Reproduced the pipeline 2515 failure locally before and confirmed clean after; the other three guides prettier flags are untouched by this branch (0 changes vs origin/next) and are pre-existing. Sanitization gate re-run and passing. Verified for the record, since I could not verify my own work: rev-code-01 confirmed the no-fallback claim TRUE against helper content on origin/next, and judged the evidence rules actionable on the grounds that each names an executable replacement.
3.5 KiB
Fleet Comms Guide
How one seat reaches another on a host. The mechanism is the framework's; the sessions and sockets are per-host, so measure yours rather than trusting an example.
mosaic <runtime> would normally inject the addressing block from the roster. Where the composer
is unavailable, or where the roster is stale, this guide is the substitute.
Measure the fleet; do not trust the roster
fleet/roster.yaml is a declaration of intent, not an observation. It routinely names a socket
that was never created, lists seats that are not running, and omits seats that are — this was
all three have been observed true at once on a live host. Find out what is actually
up before addressing anyone:
tmux list-sessions
tmux list-panes -a -F '#{session_name} #{pane_current_command} #{pane_current_path}'
The pane command tells you the runtime. A pane showing bash is an idle shell with no agent
attached — a send there lands in a shell prompt and is not read by anyone.
Use the default socket. Do not pass -L mosaic-fleet on the strength of the roster.
Sending
~/.config/mosaic/tools/tmux/agent-send.sh -s <dst_session> -C <class> -m "<message>"
-s also accepts session:window.pane. -f <file> sends a file body; stdin works too.
Classes
-C takes exactly one of these. Anything else exits 3.
| Class | Use for |
|---|---|
terminal-log |
log only; never needs the agent's attention |
actionable |
a decision, blocker, gate, or question needing an answer |
human |
relayed from a human operator |
reaction |
an ack or acknowledgement token |
digest |
machine wake, coalescible |
An absent class is treated as actionable by consumers, which is the fail-safe direction. Prefer
naming it anyway.
Addressing preamble
The wire format is [<src> -> <dst> class=<class>] <body>. Flip it when you reply — the tool
sends, it does not auto-reply.
Exit codes
| rc | Meaning |
|---|---|
| 0 | delivered or queued |
| 1 | target session not found |
| 2 | text reached the pane but is still a draft |
| 3 | usage error (bad class, missing -s) |
Never retry on rc=2. The message is in the target pane; retrying double-sends it. Confirm instead:
tmux capture-pane -p -t <session>:0.0 | tail -20
rc=2 is the normal result when the target is an idle pi seat.
Durable comms
tmux delivery is host-local and does not survive a pane. Anything that must outlive the session
goes through the estate's durable comms protocol — a committed comms/ tree in an estate repo,
with its own README. Use it for cross-host messages, verdicts, and anything a later session needs
to find.
Handing work across seats
- A verdict handed to the requesting seat is a legitimate delivery path, and the required one
for anything
pr-review.shwould otherwise post (seeguides/CODE-REVIEW.md). - Address the seat, not the runtime. A seat name is a session name; whether it runs claude, pi or codex is not the sender's business.
- Say what you measured, not just what you concluded — the receiving seat cannot see your terminal.