rmancinas/jorgecuadros-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: SES secrets created, ship blocker cleared

Browse Source 
Five documents asserted the SES_* secrets were unset in Gitea. They now
exist, so all five are corrected rather than leaving the claim to rot in
whichever one a reader opens first.

Replaces the blocker with the two things creating the secrets does NOT
establish, since both fail in ways that look identical to a missing
config: SES_FROM must be a verified identity in SES_REGION, and the
account must be out of the SES sandbox — in sandbox SES only delivers to
verified recipients, so a sweep across 815 policyholders would fail
almost every send while the configuration reads as correct.

Recommends running the first sweep with debug on, which diverts every
recipient and, on the pólizas side, leaves the avisos pending so a failed
test consumes nothing.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
rmancinas
2026-08-02 13:25:44 -07:00
co-authored by Claude Opus 5
parent 3e12597204
commit e77e5546d8
5 changed files with 49 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/INSURANCE_FEATURES_SPEC.md
+7 -4
View File
@@ -797,10 +797,13 @@ No collision with the abilities proposed in `RECEIPT_CAPTURE_SPEC.md`
## Open questions to take back to Jorge (collected)
**§1 — renewal emails** (feature built; these three are still open)
- Which SES region + verified identity/configuration set, and whether to reuse
existing IAM credentials or create a scoped `ses:SendEmail` user. **Still
unanswered in production**: the `SES_*` variables are wired through the
deploy workflow but unset in Gitea, so production sends fail loudly.
- ~~Which SES region + verified identity/configuration set, and whether to
reuse existing IAM credentials or create a scoped `ses:SendEmail` user.~~
**Answered in practice 2026-08-02** — the Gitea secrets were created. Two
things the deploy preflight cannot verify and that decide whether mail
actually goes out: `SES_FROM` must be a verified identity in `SES_REGION`,
and the account must be out of the SES sandbox (which restricts delivery to
verified recipients). See [`BACKLOG.md`](BACKLOG.md) §0.
- The 78 policyholders with no email: skip silently, or produce a print
worklist? Currently they are **logged as `SKIPPED_NO_EMAIL`** in
`email_notification_log` — visible in "Registro de envíos", but not yet a