What the owner hit (2026-08-07 08:41-09:01 PT, first morning of 26.08.013)
In Buzz #general with a third party (Ryan) present, two messages silently never reached barsik:
- Owner's "@ryan reply here again" — p-tagged to Ryan → dropped by the conservative foreign-p suppression.
- Ryan's "no" — sender not in the verified-contact registry (only the owner is seeded by the 26.08.013 migration) → dropped.
Owner discovered both by screenshot ("you didn't seem to get this"), and separately expected an approval prompt for the third-party interaction ("no approval here to approve") — no such flow exists. Both drops produced ZERO log lines.
Positive control from the same session: the 2026-06-22 tool-only outreach rule correctly suppressed two console-prose route_response fallbacks toward buzz channels (broker.py _internal_surfaces guard) — that guard logs loudly and held. The inbound drops are the asymmetric silent half.
Three pieces (separable increments)
A. Loud drops (smallest, do first). Every inbound buzz event discarded by policy (foreign-p, unverified sender, unknown kind) must leave one bounded log line with the reason + sender principal + channel — rate-limited per (sender,channel,reason) to avoid spam. Silent policy drops violate graceful-degradation-must-be-loud and cost owner trust exactly as observed today. Optionally: a daily digest line ("suppressed N events from M unverified senders") surfaced via owner-notify.
B. Verified-contact management. The registry exists (26.08.013 migration seeds the owner). Needs an operator path to add/remove contacts per agent (API endpoint + optionally an owner chat command). Semantics to decide: does verified-contact grant visibility only (agent sees the message; respond rail still owner-only) or also response eligibility? Today's ask: visibility-only for Ryan.
C. Third-party approval flow (design, owner input needed). Owner expectation: non-owner interacts with the agent → owner receives an approval card (approve once / allow contact / deny). Touches owner-notify, the respond rail, and per-contact policy state. Should reuse the existing approval-card pattern (voice-call approvals) rather than a new mechanism. Needs owner decisions on: approve-per-message vs approve-contact, expiry, and which surfaces (Buzz only vs all platforms).
Refs
🤖 Opened by Barsik
What the owner hit (2026-08-07 08:41-09:01 PT, first morning of 26.08.013)
In Buzz #general with a third party (Ryan) present, two messages silently never reached barsik:
Owner discovered both by screenshot ("you didn't seem to get this"), and separately expected an approval prompt for the third-party interaction ("no approval here to approve") — no such flow exists. Both drops produced ZERO log lines.
Positive control from the same session: the 2026-06-22 tool-only outreach rule correctly suppressed two console-prose route_response fallbacks toward buzz channels (broker.py
_internal_surfacesguard) — that guard logs loudly and held. The inbound drops are the asymmetric silent half.Three pieces (separable increments)
A. Loud drops (smallest, do first). Every inbound buzz event discarded by policy (foreign-p, unverified sender, unknown kind) must leave one bounded log line with the reason + sender principal + channel — rate-limited per (sender,channel,reason) to avoid spam. Silent policy drops violate graceful-degradation-must-be-loud and cost owner trust exactly as observed today. Optionally: a daily digest line ("suppressed N events from M unverified senders") surfaced via owner-notify.
B. Verified-contact management. The registry exists (26.08.013 migration seeds the owner). Needs an operator path to add/remove contacts per agent (API endpoint + optionally an owner chat command). Semantics to decide: does verified-contact grant visibility only (agent sees the message; respond rail still owner-only) or also response eligibility? Today's ask: visibility-only for Ryan.
C. Third-party approval flow (design, owner input needed). Owner expectation: non-owner interacts with the agent → owner receives an approval card (approve once / allow contact / deny). Touches owner-notify, the respond rail, and per-contact policy state. Should reuse the existing approval-card pattern (voice-call approvals) rather than a new mechanism. Needs owner decisions on: approve-per-message vs approve-contact, expiry, and which surfaces (Buzz only vs all platforms).
Refs
🤖 Opened by Barsik