Sandbox sender stack: remaining follow-ups #563

Sandbox sender stack: remaining follow-ups

The managed sandbox sender stack (Silthus/posthog #426 to #456) left these items out of scope.
None of them blocks the stack: each is a refactor, a test cleanup, a nit, or a check that waits on access.
Each line names the PR it belongs to and why it waits.

Design refactors (no defect found)

• G2-7, feat(workflows): restrict sandbox email to verified org members #434: pass one typed delivery envelope through the recipient gate instead of parsing recipients again at each step. A structural rewrite of the gate needs its own proof.
• G2-8, feat(workflows): cap sandbox sends and refund ses throttles #441: let the daily-cap limiter hand out a refund receipt instead of the sender making a claim ID. A refactor of the cap path, with no defect behind it.
• G2-9, feat(workflows): restrict sandbox email to verified org members #434 and feat(workflows): cap sandbox sends and refund ses throttles #441: the sandbox gate is split across EmailService and SandboxEmailSender, and email.service.ts is past 1,000 lines. Propose the split as its own base PR, per splitting-oversized-modules.
• G2-10, feat(workflows): restrict sandbox email to verified org members #434: replace the hand-written address splitter with nodemailer's addressparser. A parser change in the recipient gate needs its own parsing proof (groups, encoded words).
• G2-11, feat(workflows): restrict sandbox email to verified org members #434: drop the packing of blocked addresses into the log line. A simplification with no defect behind it.
• G3-13, feat(workflows): offer the sandbox sender in workflow email steps #450: the sender picker has both a controlled value/onChange and a logic-bound contract. Pick one. A component API change that touches its story and tests.
• G5-4, feat(workflows): resolve the first-run email sender #455: merge editor and template eligibility into one first-run preparation step. The second pass is already gone; the merge itself is a refactor.
• G5-5, feat(workflows): offer a switch from the sandbox sender #456: give workflowLogic's loadWorkflow a named return type. Its payload type expands to about 1,700 lines of inline typegen in every logic that connects it. feat(workflows): offer a switch from the sandbox sender #456 no longer connects it, but workflowLogic and hogFlowEditorLogic on master still carry the expansion.
• G5-6, feat(workflows): resolve the first-run email sender #455: move the email preparation out of the inline onDrop handler into the logic.
• G3-5, feat(workflows): test templates with the sandbox sender #451: send a structured skip reason from the worker instead of skip wording. Both result banners already share one helper that reads the wording, so this is a contract change, not a fix.

Tests

• G2-4, feat(workflows): restrict sandbox email to verified org members #434 and feat(workflows): cap sandbox sends and refund ses throttles #441: clean up singleton isTest matrices, an unreachable cleanup branch, and a cross-project cap case in the limiter suite. The cleanup commit conflicted with later layers' test rewrites, so it lands as a test-only PR on the stack tip.
• G2-12, feat(workflows): restrict sandbox email to verified org members #434: the members cache test asserts calls on the query mock. Assert the cache behavior through the service instead.
• G3-8, feat(workflows): offer the sandbox sender in workflow email steps #450: the picker tests stub logic actions. Drive them through the rendered picker instead.

UI nits

• G5-7 and G5-8, feat(workflows): resolve the first-run email sender #455: the tile canvas controls and the tree dropzone show no pending marker while an email step is prepared. Insertion already asks the user to wait; disabled controls with a loading row are the rest.
• UI-F1, feat(workflows): restrict sandbox email to verified org members #434 and feat(workflows): cap sandbox sends and refund ses throttles #441: a sandbox test send to a non-member whose domain has no MX records shows the hard-bounce reason, not the members-only reason, because the MX check runs first. Both messages are true and the send is refused either way. Reordering the gates changes the recipient gate and needs its own proof.
• UI-F4, feat(workflows): offer the sandbox sender in workflow email steps #450: the Channels sandbox row keeps offering "Add your own sender" after a verified own sender exists. The banner and the picker already move users to their own sender.

Checks that wait on production read access

• Prod shape, feat(workflows): provision a managed sandbox email sender #426, feat(workflows): validate sandbox sender use at save time #430, feat(workflows): separate sandbox delivery history #454 and feat(workflows): resolve the first-run email sender #455: the share of stored rows (email integrations, stored workflow email steps, app metric totals) that take each changed branch. Accepted as a gap until production read access lands on 2026-11-02.
• UI-F3, feat(workflows): restrict sandbox email to verified org members #434 and feat(workflows): test templates with the sandbox sender #451: how many active members have no verified email address, and so now see "Verify your email address" instead of a send. Same access.

Rollout

• R2-11, feat(workflows): provision a managed sandbox email sender #426 and feat(workflows): route sandbox email through its fixed ses identity #428: the code remainder is none. Django and the worker now read the same SES_SANDBOX_FROM_ADDRESS. The deploy must set it on Django web and Celery as well as the worker, with one value, before the sandbox sender turns on.

Map: #461. Charted by the map conductor on 2026-10-24 at Michael's request. Not a build lane yet.