Bounced addresses: a Re-enable button with an in-page confirm
Staff can see the addresses Clara stopped emailing because they bounced as not existing, and turn one back on. Captured against propflow-stage with two synthetic @example.test bounces.
8 Oct 2026 · branch feat/bounced-addresses-reenable-button · captured against propflow-stage · at 2dff8d0fda7+local
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
1 · The Bounced addresses tab
The second tab on the email page lists every address we skip, newest bounce first: the address in full, the reason the receiving server gave, where we learned it, and when. A row still being skipped reads Not sending and carries a Re-enable button; Status stays the last column.
Asserted in the captured DOM — Bounced addresses · typo.resident@example.test · old.mailbox@example.test · Recipient not found · Not sending · Re-enable. Both synthetic bounces, their reasons, their status and the button are on screen.
Sections 2–2
2 · Re-enable asks first, in the page
Clicking Re-enable opens the shared confirm dialog, never the browser's own prompt, naming the address. Nothing is sent until Confirm; Cancel closes it with no change.
Asserted in the captured DOM — Re-enable this address? · Clara will start emailing typo.resident@example.test again. The confirm dialog is open and names the address; no request has been made yet.
