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.
1Outbound email dead-letter queue has no drainer: ADR-0006 deleted retry-processor.ts on the rationale 'SendGrid native retry covers every real-world case', but transport-level failures (write ETIMEDOUT / TLS disconnect before connect — Sentry JAVASCRIPT-NEXTJS-18J, -18F) never reach SendGrid, so they are dead-lettered (addToDeadLetter) and never retried; getRetryableDeadLetters has zero non-test callers. [propflow-prod] entityType-createdAt-index GSI3PK=DeadLetterEmail → 230 rows (222 pending / 8 delivered, oldest 2026-04-10). send-pm-tour-cancellation.ts leaves pmCancelNotifiedAt unset 'so a later run can retry' but no later run exists (only caller: apply-tour-intent.ts:757 at cancel time). Restore a Temporal-scheduled drainer with a 24h createdAt cutoff, or declare no-retry and fix the 'Email queued for retry' log + ADR-0006?
In plain terms. When an email fails to send because of a network blip, PropFlow files it as 'queued for retry' — but the retry job was deleted months ago, so nothing ever re-sends it. 222 emails are sitting in that queue in production, some from April. Should we bring back an automatic re-send (only for emails that failed in the last day, so the old backlog doesn't go out stale), or keep no re-send and make the logs and the design record say so honestly?
The session raising this recommends: Bring back automatic re-send, only for emails that failed in the last day The sender's own code still expects a retry (it leaves the tour's 'PM notified' stamp unset on purpose so a later run can retry); the retry was deleted underneath it, and a socket timeout before the request reaches SendGrid is exactly the case SendGrid's own retry cannot cover. A 24h cutoff keeps the April backlog from going out stale. Tried first, unsuccessfully: Read ADR-0006 (retry processor deleted, DL rows deliberately left in place). Grepped origin/main for every caller of getRetryableDeadLetters/recordRetryFailure/markDeadLetterDelivered — only src/__tests__/email-stability.test.ts. Grepped for any sweep over pmCancelNotifiedAt — none. Queried propflow-prod's entity-type GSI: 230 DeadLetterEmail rows, 222 pending, 8 delivered, 3 this week with errorReason 'fetch failed' (all the TEST property's internal mailbox). Did not restore a drainer myself: it would resend up to 222 stale PM/renewal/tour emails to real recipients, which is outbound comms and a human's call.