Status. Proposed design only. Nothing in this vault is DG client approval. No application, service or test has been executed; every scenario is Not executed. Fees and dates are open.
Step 07 · Outbox delivery worker and email
Goal. Reliable immediate email for the four business events, delivered from the outbox contract built in step 01.
Not started. This is a specification; no code has been written. The primary-step mapping is an index, not proof that each full scenario can be completed in its step: see Dependency-and-Regression-Table.
Prerequisites
Step 01 outbox contract and step 06 event-producing mutations. Policy-independent scaffolding may start only after the overall start conditions are met (statement of work, ready-to-start kickoff checklist, funded DG-owned accounts, region and identity provider chosen). Decision-dependent behaviour and its final oracle stay blocked until DG chooses the applicable rule. Proposed defaults are recommendations, never prerequisites. Any provisional synthetic exploration must be labelled reversible and unapproved and is not accepted production behaviour. Blocked until DG decides: current-recipient rule, retry and lease limits, ambiguous-send handling and recovery owner (Q07); safe email labels (Q08).
Changes (illustrative, not a final schema)
Delivery worker over the existing outbox records; attempt history; email templates for the four events; reconciliation and manual recovery for ambiguous outcomes.
Build items:
- Worker leases, unique event-recipient-channel record, durable attempts
- Recheck authorisation at claim, send and link-open
- Ambiguous-send reconciliation; bounded retry; authorised manual recovery
- Minimal generic email with authenticated link
Expected outputs and invariants
At-least-once processing with duplicate protection on logical event and delivery identities; email content generic with an authenticated link; ambiguous provider outcomes reconciled and recorded.
Tests-first subset
Primary scenarios of this step (write these tests first): T33, T34, T35, T36.
Assertions to write first: T33–T36; the email and queued-send halves of T04, T10, T11, T18, T19, T21–T23, T25, T26, T32.
Method: make one meaningful test fail for the expected reason, implement the minimum behaviour, refactor without changing the observable contract. A scenario whose decision is still pending stays Pending decision; no oracle is invented.
Deferred integration checks
Scenarios whose primary step is this one but whose full variants need later components:
- T33 — needs step 04, 06: Verified for each real event-producing mutation as it is built; delivery in 07.
- T36 — needs step 10: The operations part needs the integrated build and runbooks.
Follow-up verification brought here
Earlier scenarios that can only be completed or rechecked once this step exists:
- T04 — Moving a question and an action needs step 06 records; reassignment notification behaviour needs step 07 and Q07 (no new event type assumed).
- T10 — The notification and email canary scan needs the worker.
- T11 — No private body in email or logs needs the worker.
- T18 — One logical event for the retry needs the worker side.
- T19 — One acceptance event and no duplicate logical delivery identity need the outbox contract (01) and worker (07).
- T21 — Recommendation refresh (05), EOI keeping V1 (06) and the safe change alert (07) complete it.
- T22 — Needs recommendations (05), EOI submission (06) and duplicate worker jobs (07).
- T23 — No closure email event is confirmed with the worker.
- T25 — Revoked access to engagement records needs 06; suppression of a queued email needs the worker (07).
- T26 — Recipient choice for queued mail needs the worker and Q07.
- T32 — Notification history for reassignment is checked with 07.
- T38 — Worker-failure visibility and staging email-sink isolation need the worker (07); the integrated operations review is at step 10.
Decisions DG must settle (dependent behaviour stays blocked until DG chooses)
Exit evidence
Failure injection shows durable state, no duplicate business records and no duplicate logical event or delivery identities, with at-least-once processing and ambiguous-provider reconciliation (T35 provider-ambiguity evidence still required). Duplicate external emails cannot be categorically ruled out, and no exactly-once delivery is claimed. No private body appears in email or logs.
Evidence is recorded only for a named build and fixture. A software scenario is not recorded as Passed until all its relevant variants have been exercised on a named integrated build (step 11).
Navigation: Step-06-Questions-Interest-Discussions-Actions ← this step → Step-08-Daily-Tracking-Views · Implementation-Order-Overview