Everything I could decide myself is decided. What's left needs
you. Each one carries the recommendation of the session that raised it — if you
agree, pick it and press Done. A model's opinion, where there is one, appears on the card
as a receipt line; cards with no receipt were never put to a model. "I'm not sure" is a real answer and becomes work for me.
You don't need to open the session — pressing Done sends your answer back and it picks up.
1hello@ mirror: who should post customer GROUP mail to Slack long-term — the SES Lambda (needs the Google Group wired to hello-mirror@inbound.propflowai.co) or the Gmail poller (already doing it, 2-min latency)?
In plain terms. Do you want one 2-minute email mirror, or should we also wire up the instant one? Right now customer emails to hello@ reach Slack only through Smith's 2-minute Gmail check; the instant path was never fed real mail.
The session raising this recommends: Keep the one 2-minute poller; retire the instant path Measured 2026-09-22: 34 group messages in Gmail over 3 days, the Lambda ran twice (both test mail). It has never seen a real group email, keeps its own S3 state the poller cannot see (double-posts the day the group is wired unless the plist flips in the same change), has no failure alarm, and no deploy path in the repo. The poller already mirrors both kinds of mail with one query and one dedup; the only cost is ~2 minutes of latency vs instant. One system to watch beats two that cannot see each other. Tried first, unsuccessfully: Tried: reading the SES receipt rules (hello-mirror@ / customer-mirror@ on inbound.propflowai.co), the Lambda's CloudWatch invocations and logs, the S3 inbound bucket, and the poller's state vs Gmail thread counts. The group-forwarding half is a Google Workspace admin action I cannot perform from here, and whether to keep two posting systems is a product/ops call, not a code fix.