M6: Finalize and email #47

New issue

Closed

opened 2026-07-05 19:21:09 +01:00 by TimCane · 0 comments

TimCane commented

2026-07-05 19:21:09 +01:00

(Migrated from github.com)

Goal

Finalize the split (unclaimed equal-split, lock, TTL shrink) with a summary screen and an optional summary email that never persists the address.

Scope

Finalize endpoint (unclaimed split, lock, TTL shrink, SessionFinalized), Summary screen with countdown, MailKit sender + template, email-optional capability flag.

References

Acceptance criteria (docs/14)

A1 Post-finalize invariant holds: per-person totals sum to the full bill (property + e2e)
A2 Claim gesture after finalize -> soft wrong-state handling (refresh, no error toast)
A3 Email received via a real relay; address absent from Redis and logs
A4 Session and code keys report ~1h TTL after finalize

Notes

Backend finalize precedes Summary/finalize-dialog UI; capability flag precedes the email field; soft-handling depends on M5 hub error surfacing.

Sub-tasks are tracked as sub-issues below.

## Goal Finalize the split (unclaimed equal-split, lock, TTL shrink) with a summary screen and an optional summary email that never persists the address. ## Scope Finalize endpoint (unclaimed split, lock, TTL shrink, SessionFinalized), Summary screen with countdown, MailKit sender + template, email-optional capability flag. ## References - [docs/14-build-order.md#m6---finalize-and-email](https://github.com/TimCane/bill-splitter/blob/main/docs/14-build-order.md#m6---finalize-and-email) - [docs/04-api-contract.md](https://github.com/TimCane/bill-splitter/blob/main/docs/04-api-contract.md) - [docs/02-domain-model.md](https://github.com/TimCane/bill-splitter/blob/main/docs/02-domain-model.md) - [docs/03-redis-schema.md](https://github.com/TimCane/bill-splitter/blob/main/docs/03-redis-schema.md) - [docs/07-backend-design.md](https://github.com/TimCane/bill-splitter/blob/main/docs/07-backend-design.md) - [docs/09-ux-flows.md](https://github.com/TimCane/bill-splitter/blob/main/docs/09-ux-flows.md) ## Acceptance criteria (docs/14) - [ ] A1 Post-finalize invariant holds: per-person totals sum to the full bill (property + e2e) - [ ] A2 Claim gesture after finalize -> soft `wrong-state` handling (refresh, no error toast) - [ ] A3 Email received via a real relay; address absent from Redis and logs - [ ] A4 Session and code keys report ~1h TTL after finalize ## Notes Backend finalize precedes Summary/finalize-dialog UI; capability flag precedes the email field; soft-handling depends on M5 hub error surfacing. Sub-tasks are tracked as sub-issues below.