cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs(email): record draft identity evidence
CI and Deploy / test (pull_request) Successful in 4m26s
Details
CI and Deploy / deploy (pull_request) Has been skipped
Details

Browse Source
This commit is contained in:
cesnimda
2026-08-10 10:12:01 +02:00
parent 80b5532c2f
commit 050b99ca36
6 changed files with 20 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/work-programmes/decisions.md
+10
View File
@@ -559,3 +559,13 @@
- **Consequences:** saving never sends or checks connection state. Send still uses the separate explicit-confirmed/idempotent boundary and revalidates all fields/provider consent. UI must surface revision conflicts and treat bodies as untrusted plain text.
- **User approval required:** No; this is approved local MAIL-001 work with synthetic data and no provider/production action.
- **Reversible:** Revert `a9bb22e`; the inert/exported schema remains for a later UI. Existing stored drafts are unaffected.
## DEC-057 — Persist one delivery identity for the life of a draft
- **Date:** 2026-08-10
- **Decision:** Assign every server draft one canonical client-request UUID, preserve it across edits/refresh, include it in readable exports, and allow listing all current-owner drafts for recovery.
- **Reason/evidence:** the send ledger keys idempotency by client request ID. Generating a new UUID after refresh would let identical restored content reserve a second delivery attempt. Focused tests prove creation, edit preservation, export and tenant-filtered all-draft listing.
- **Alternatives considered:** generate UUID only at send; regenerate after every edit/refresh; derive it from content; store it only in browser memory. These permit duplicate delivery after refresh, conflate content changes with attempt identity or lose the safety state on navigation.
- **Consequences:** one draft maps to one send attempt identity until the user explicitly starts a new attempt after a confirmed failure. A sent/restored draft can only replay the existing ledger result. The additive migration defaults only during the same pre-exposure rollout; no draft UI existed before it.
- **User approval required:** No; this closes a local safety dependency before UI exposure and sends no email.
- **Reversible:** Downgrade `20260810080858_AddEmailDraftClientRequestId` before reverting `80b5532`. Do not deploy draft UI without an equivalent persisted idempotency identity.