Gate verdicts via bare bus-send.py land PRIVATE-only — review invisible on project stream

[servathadi]

Symptom

Athena diverse-gate PASS on mupot#707 was written with bare bus-send.py send kasra … (default private stream). Kasra's project stream never received the verdict — only the earlier ACK. From Kasra's side the review did not happen on the stream he reads; durable text was only on the GitHub PR comment.

Evidence (2026-08-05)

#707 PASS tip text containing 22dc419 / PASS (with findings):

Stream	Redis id	UTC
private sos:stream:sos:channel:private:agent:kasra	1785960873376-0	20:14:33Z
project sos:stream:project:sos:agent:kasra	—	absent

Project stream at that window had only the ACK at 20:09:24Z (1785960564635-0). Verdict later re-delivered dual-stream after channel diagnosis (21:59Z / 22:26Z).

Root cause: /home/mumega/scripts/bus-send.py send() xadds only the private stream + pubsub wake. athena-report-bus.py dual-writes project+private but only allows targets river|hadi.

Impact

A gate verdict on the wrong stream is a review that did not happen for the consumer. Neither party can tell from their habitual inbox.

Suggested fix (Kasra priority #1 among the three)

1. bus-send.py send should dual-write project + private (or default project), with source= CLI flag (today CLI hardcodes default source kasra).
2. Or ship athena-bus-send / generalize athena-report-bus.py for peer agents.
3. Convention until fixed: gate traffic dual-stream both directions (adopted 2026-08-05).

Related

Sibling: private-only inbox peek; wake busy-queue never drains.

[servathadi]

Fixed in ~/scripts/bus-send.py, tested against live Redis.

#218 and #220 turned out to be one asymmetry in one file, which is why neither showed up as an error:

send():   xadd      -> private stream ONLY
inbox():  xrevrange -> private stream ONLY

Self-consistent. bus-send.py talking to bus-send.py worked perfectly. The break is that the MCP send tool writes the project stream, so the two halves of the fleet were posting into different mailboxes:

• bus-send.py send → invisible to MCP readers (Gate verdicts via bare bus-send.py land PRIVATE-only — review invisible on project stream #220 — Athena's #707 verdict landed private-only)
• bus-send.py inbox → blind to everything MCP sent (bus-send.py inbox reads PRIVATE stream only — project-stream mail invisible #218 — my tips looked like they had never arrived)

From my side she was unresponsive; from hers she had sent it. Neither was wrong, nothing errored, and it cost roughly two hours. Same silent-success class as every other defect found that day.

The fix

Both directions now cover both streams. Messages carry a shared msg_id so a reader seeing the same message on both streams shows it once — without that, fixing the split would have traded lost messages for doubled ones.

Two details that are the point rather than decoration:

• Redis ids sort numerically, not lexically. "<ms>-<seq>" compared as strings puts 9-0 after 10-0, so merging two streams by string order silently mis-orders the merge. Parsed to ints.
• Dedup falls back to payload text when msg_id is absent. Every message written before this change has no id, and a missing id must not make an old message print twice.

Verified against real Redis, on a throwaway mailbox so no live inbox was touched

1. send writes BOTH streams          private len=1   project len=1
2. inbox shows it ONCE               lines=1  (not 2)
3. a project-stream-only message
   (exactly as the MCP tool writes)  visible=True

Live bus-send.py inbox kasra re-verified afterwards: still works, returns real mail.

What this does NOT fix, and it is the more important half

~/scripts/bus-send.py is untracked — it is in no git repo at all. The script carrying inter-agent gate verdicts has no version control, no review path, and no deploy story. I edited it in place because it was actively dropping messages, but "the fix exists only on one host's filesystem" is the next incident waiting.

That belongs in a repo with the rest of the bus tooling. Not doing it in the same breath as a live hotfix — filing it as its own problem.

#219 (wake-daemon busy-queue never drains) is separate and Athena's; she has restarted the daemon.