chore(release): v1.0.8

Cut by rmancinas via the "Cut release" workflow. Pushing the tag triggers build.yml; deploy separately with tag=1.0.8.

.gitea/workflows/deploy-galactus.yml

@@ -40,6 +40,21 @@
 #      SESSION_SECRET_GALACTUS        64-hex (openssl rand -hex 32)
 #      MINIO_ROOT_USER / MINIO_ROOT_PASSWORD
 #      MYSQL_PASSWORD / MYSQL_ROOT_PASSWORD
+#    Optional — outbound mail. Not needed to deploy; needed for
+#    /notificaciones to send anything at all (the image sets
+#    NODE_ENV=production, which disables MailService's stdout fallback, so
+#    a blank config fails every send loudly):
+#      SES_REGION                     e.g. us-west-2
+#      SES_FROM                       a VERIFIED SES sending identity
+#      SES_FROM_NAME                  display name, optional
+#      SES_ACCESS_KEY / SES_SECRET_KEY
+#      SES_CONFIGURATION_SET          optional, for bounce/complaint events
+#      NOTIFICATION_ADMIN_EMAILS      fallback only — the summary recipients
+#                                     are edited in the UI and stored in
+#                                     app_settings; this is what a deployment
+#                                     uses until somebody saves them there
+#    These are NOT galactus-specific (no _GALACTUS suffix) — one SES identity
+#    serves every deployment.
 #  - The runner (which lives on cubex) must be able to reach BOTH
 #    galactus:9443 (Portainer) and galactus:3306 (MySQL, for migrate deploy).
 #    If it cannot reach 3306, run the migration by hand from a host that can
@@ -116,6 +131,13 @@ jobs:
           MINIO_ROOT_PASSWORD: ${{ secrets.MINIO_ROOT_PASSWORD }}
           MYSQL_PASSWORD: ${{ secrets.MYSQL_PASSWORD }}
           MYSQL_ROOT_PASSWORD: ${{ secrets.MYSQL_ROOT_PASSWORD }}
+          # Not required — the app boots fine without mail. Warned about below,
+          # because the failure mode is remote: everything looks healthy until
+          # someone clicks "Ejecutar" and every send fails.
+          SES_REGION: ${{ secrets.SES_REGION }}
+          SES_FROM: ${{ secrets.SES_FROM }}
+          SES_ACCESS_KEY: ${{ secrets.SES_ACCESS_KEY }}
+          SES_SECRET_KEY: ${{ secrets.SES_SECRET_KEY }}
           SCOPE: ${{ github.event.inputs.scope }}
         run: |
           REQUIRED="PORTAINER_URL_GALACTUS PORTAINER_API_KEY_GALACTUS
@@ -140,6 +162,20 @@ jobs:
           fi
           echo "all required secrets present for scope=$SCOPE"
 
+          # Mail is optional to deploy but not optional to work. Say so loudly
+          # rather than letting /notificaciones fail one send at a time.
+          mail_missing=""
+          for name in SES_REGION SES_FROM SES_ACCESS_KEY SES_SECRET_KEY; do
+            eval "value=\${$name}"
+            [ -z "$value" ] && mail_missing="$mail_missing $name"
+          done
+          if [ -n "$mail_missing" ]; then
+            echo "::warning::outbound mail is NOT configured, missing:$mail_missing"
+            echo "::warning::the deploy will succeed, but every notification and"
+            echo "::warning::renewal aviso will fail with 'El envío de correo no"
+            echo "::warning::está configurado.' See docs/MASS_EMAIL_NOTIFICATIONS.md"
+          fi
+
       # --- full only: database ---------------------------------------------
       - name: Deploy database stack
         if: ${{ github.event.inputs.scope == 'full' }}
@@ -260,7 +296,14 @@ jobs:
               "OPS_DB_ADMIN_USER": "root",
               "OPS_DB_ADMIN_PASSWORD": "${{ secrets.MYSQL_ROOT_PASSWORD }}",
               "MINIO_ROOT_USER": "${{ secrets.MINIO_ROOT_USER }}",
-              "MINIO_ROOT_PASSWORD": "${{ secrets.MINIO_ROOT_PASSWORD }}"
+              "MINIO_ROOT_PASSWORD": "${{ secrets.MINIO_ROOT_PASSWORD }}",
+              "SES_REGION": "${{ secrets.SES_REGION }}",
+              "SES_FROM": "${{ secrets.SES_FROM }}",
+              "SES_FROM_NAME": "${{ secrets.SES_FROM_NAME }}",
+              "SES_ACCESS_KEY": "${{ secrets.SES_ACCESS_KEY }}",
+              "SES_SECRET_KEY": "${{ secrets.SES_SECRET_KEY }}",
+              "SES_CONFIGURATION_SET": "${{ secrets.SES_CONFIGURATION_SET }}",
+              "NOTIFICATION_ADMIN_EMAILS": "${{ secrets.NOTIFICATION_ADMIN_EMAILS }}"
             }
 
       # --- prove it ----------------------------------------------------------

.gitea/workflows/deploy.yml

@@ -267,7 +267,14 @@ jobs:
               "OPS_DB_ADMIN_USER": "root",
               "OPS_DB_ADMIN_PASSWORD": "${{ secrets.MYSQL_ROOT_PASSWORD }}",
               "MINIO_ROOT_USER": "${{ secrets.MINIO_ROOT_USER }}",
-              "MINIO_ROOT_PASSWORD": "${{ secrets.MINIO_ROOT_PASSWORD }}"
+              "MINIO_ROOT_PASSWORD": "${{ secrets.MINIO_ROOT_PASSWORD }}",
+              "SES_REGION": "${{ secrets.SES_REGION }}",
+              "SES_FROM": "${{ secrets.SES_FROM }}",
+              "SES_FROM_NAME": "${{ secrets.SES_FROM_NAME }}",
+              "SES_ACCESS_KEY": "${{ secrets.SES_ACCESS_KEY }}",
+              "SES_SECRET_KEY": "${{ secrets.SES_SECRET_KEY }}",
+              "SES_CONFIGURATION_SET": "${{ secrets.SES_CONFIGURATION_SET }}",
+              "NOTIFICATION_ADMIN_EMAILS": "${{ secrets.NOTIFICATION_ADMIN_EMAILS }}"
             }
 
       # --- prove it ----------------------------------------------------------

PLAN.md

@@ -1,5 +1,11 @@
 # Unified Customer / Insurance / Utilities Platform — Migration & Rebuild Plan
 
+> **Looking for what is still outstanding?** → [`docs/BACKLOG.md`](docs/BACKLOG.md).
+> This document is the plan and its running status; the backlog collects every
+> open item — blocked-on-Jorge decisions, live data defects, unbuilt features
+> and deploy blockers — in one list, checked against the code rather than
+> against these notes.
+
 ## Context
 
 Jorge Cuadros & Assoc. runs two lines of business — property/utility management (`UTILITIES.accdb`) and insurance brokerage (`SEGUROS 16.mdb` + its linked backend `SEGUROS 16_be.mdb`) — out of separate, decades-old MS Access databases, plus a third file (`SCOTHIA.mdb`) that's the office's own Scotiabank checking-account register ("chequera"). The same people are customers of both business lines, but today there's no shared customer record: a person's utility account and their insurance policies live in unrelated systems with independent, inconsistent copies of their name/address/contact info. The bank register is a fourth, disconnected source of truth for the money actually moving through the office's own account.
@@ -134,16 +140,22 @@ Given the amount of near-duplicate/overlapping data across snapshot tables (mult
     - **Receipt capture module — DONE** (2026-07-27). The legacy "Editor" replacement, built on the single-movement capture from step 6. Wires up the previously-unused `Transaction.outstanding` (NOPAGO): capture flag on `POST /billing`, `?outstanding=` list filter, `POST /billing/:id/resolve-outstanding` (gated `ledger:create`, not `ledger:void` — resolving *completes* a capture), and exclusion from every balance aggregate exactly as the legacy `SALDOS ULTIMO 0`'s `HAVING NOPAGO = 0` did. Adds `POST /billing/batch` (one `$transaction`, check-level fields shared, per-line customer/amount) and `GET /billing/by-check`, plus the `cheque-count` report replacing `REPORTE CHEQUE COUNT` / `REPORTE POR CHEQUE` / `EDITA CHEQUE ALF|COUNT|NUM` — print/PDF/CSV/XLSX come free from the existing `/reportes/:slug` machinery. Web: `/estado-cuenta/lote` (the actual "Editor" screen, with live reconciliation against the physical check amount), plus an "Estado de pago" filter, a "sin fondos" row tag and a Resolver dialog on `/estado-cuenta`. No new abilities. Verified end-to-end against dev, API + browser.
       **Two pre-existing bugs found and fixed while building it:** (a) `statement()` filtered `legacySourceTable: { notIn: [...] }`, which compiles to SQL `NOT IN` — and `NULL NOT IN (…)` is NULL, so **every app-captured movement was invisible on the customer statement** (438 rows in the movement browser vs 392 on the statement) while still appearing everywhere else. This would have made the whole receipt-capture feature look broken to staff. Now NULL-safe. (b) The balances *count* query omitted the void filter its own page query applied, so the row count disagreed with the rows.
       **OCR seam:** `BillingService.createBatch(dto, opts)` is the single multi-row write path and carries three contract guarantees for the step-11 OCR module to post through — `items[i]` maps to `lines[i]` (so `StatementDocument.postedTransactionId` can be zipped back on), `opts.refs[i]` stamps `captureRef` with a duplicate-post guard that a *voided* row deliberately does not block, and `opts.source` is service-level only so an HTTP client cannot label hand-keyed rows as machine-captured. Backed by a new `TransactionCaptureSource` enum (MANUAL/BATCH/OCR) + `captureRef`, both nullable so the 40,136 migrated rows stay NULL rather than being mislabelled.
-    - **PDF/OCR auto-capture — DONE** (2026-08-01). The ingest→split→OCR→match→review pipeline for the 300+/month/service-provider statements staff key in by hand, built in `apps/api/src/statements/` and posting through §1.2's `createBatch` seam with `source: "OCR"` and a per-document `captureRef`. Web: `/recibos` + `/recibos/:id`. Abilities `statement:ingest`/`statement:review` (STAFF — the review step is what makes machine capture safe at that tier). OCR is self-hosted **Tesseract** behind a swappable `OcrProvider` interface; `tesseract-ocr`, `tesseract-ocr-data-spa` and `poppler-utils` were added to the API image.
+    - **PDF/OCR auto-capture — DONE** (2026-08-01). As-built write-up in [`docs/STATEMENT_OCR.md`](docs/STATEMENT_OCR.md); the design and the measured evidence stay in the spec's §2. The ingest→split→OCR→match→review pipeline for the 300+/month/service-provider statements staff key in by hand, built in `apps/api/src/statements/` and posting through §1.2's `createBatch` seam with `source: "OCR"` and a per-document `captureRef`. Web: `/recibos` + `/recibos/:id`. Abilities `statement:ingest`/`statement:review` (STAFF — the review step is what makes machine capture safe at that tier). OCR is self-hosted **Tesseract** behind a swappable `OcrProvider` interface; `tesseract-ocr`, `tesseract-ocr-data-spa` and `poppler-utils` were added to the API image.
       **Every decision was driven by 10 real scans (46 pages).** Shipped-parser results on them: provider 46/46, account ref 43/46, amount 42/46, due date 44/46 — and against the dev database **39/46 (85%) exact auto-match, 40/46 (87%) identified**, the rest genuine review cases. The scans are pure images (no text layer), so OCR is mandatory, and they arrive **bundled one customer per page**.
       **The three gaps are closed, and two of them were mis-stated in the spec.** (a) `TELEPHONE` now exists and is backfilled from `Property.phone1` only — coverage is 534/18/1 across phone1/2/3, so phone is one billed line per property, not three. (b) **Clave catastral ≠ predial**: `DATMEX.clave` (934 rows, `KA903009`) is what CESPT and predial bills actually print, while `predial` — what `PROPERTY_TAX.accountNumber` holds — has only 663 distinct values across 1135 rows and appears on no statement; the clave now lives on `Property.cadastralKey` as the matcher's secondary key and predial is left untouched. (c) Gas was **not** a dead end: 160 of the 334 `DATMEX.gas` values are real account numbers (the rest are `ESTACIONARIO`/`CILINDRO` descriptors), all recovered into `GAS.meterNumber`.
       **Matching is scoped per service kind and never reads the customer name** — a CESPT receipt prints `ARNAIZ ROSAS ELSA AURORA` for an account this office holds under `CATT, RANDY`, because the name on a utility bill is the registrant, not the current owner. Normalisation is per provider: CFE strips leading zeros off `NO. DE SERVICIO`, Telnor strips the 664 LADA down to the stored local 7 digits. Where a provider prints a payment barcode it is preferred over the printed label (one CFE label OCR'd a digit too many while its barcode was correct) and the two are cross-checked, with disagreement forcing review. Confirming a document whose service had no reference writes it back, so gas and any other cold start is a one-time cost.
+    - **Policy OCR capture — DONE** (2026-08-01), **unplanned — it came out of building the bullet above.** Full write-up in [`docs/POLICY_OCR.md`](docs/POLICY_OCR.md). Once the receipt pipeline existed it was obvious the same render→OCR→parse→match→review shape fits the *other* stack of paper this office keys in by hand: the carrier policy PDFs behind every `Policy` row. Built in `apps/api/src/policy-ocr/` with a GMX parser, `policy_ocr_batches`/`policy_ocr_documents`, and abilities `policy:ingest`/`policy:ocr-review` (STAFF, same trust tier and same reason). Web: `/polizas/captura` is the "automática" tab of the policy-creation screen (`/polizas/nuevo` is the manual one, both render `PolicyCaptura.tsx`) with the review queue at `/polizas/captura/[id]`. The `OcrProvider` seam was **extracted out of `StatementsModule` into its own `OcrModule`** to make this possible — that was blocking, not cosmetic; `StatementsModule` now imports it and binds nothing.
+      **The statement pipeline's core assumption inverts here.** Utility statements arrive bundled *one customer per page*, so there a page is a document; a GMX certificate is one policy across two pages (header on 1, coverage table on 2), so the pipeline concatenates the pages and runs the parser and matcher **once per file**. `PolicyOcrDocument.pageNumber` is therefore the file ordinal in the batch, and `storageKey` points at the **source PDF** (the review screen embeds the exact artifact the office received) rather than at a page image. Matching is on `Policy.policyNumber` alone and never the printed insured name — the same registrant-vs-owner drift that rules names out on the utility side. Zero hits means a new policy and confirm creates it; more than one is surfaced, never auto-picked.
+      **The GMX certificate carries no premium at all** — the figure lives on a separate `recibo` PDF — so the premium fields stay null with a note saying why, confirm never overwrites an existing premium with null, and the optional ledger write is gated on staff ticking `postPremium` *and* a premium actually parsing. 8/8 parser tests against one real document (`HC_Folio_000767_Traduccion.pdf`). GMX is the only carrier implemented; the dispatcher is a pattern table, so a second one is a parser function and two entries.
     - **Multi-bank chequera — DONE** (2026-07-27). `Bank`/`BankAccount` models so Seguros (US bank) and Utilities (Mexican bank, currently SCOTHIA) can each have their own register. `bank_transactions` gained a **required** `bankAccountId` (plus an `(bankAccountId, transactionDate)` index, since every read is now filtered by account and ordered by date), and all 22,669 existing rows were backfilled onto a seeded "Utilities — Scotiabank (MXN)" account by `migration/backfill_bank_accounts.py` — a standalone step because `prisma db push` cannot add a required column to a populated table. It is idempotent and now runs inside `run_all.py` (both normal and `--sync`) ahead of `transform_bank.py`, which fails fast if the account is missing. Every read path in `bank.service.ts` is account-scoped, including `facets()` (which had no filter at all) and *both* raw-SQL rollups in `summary()`. API: `?bankAccountId=` is required on `list`/`stats`/`facets`/`summary` — **not** optional-with-an-all-accounts-default, since summing an MXN and a USD register repeats exactly the currency-collapsing mistake the billing module exists to prevent — plus a new `bank/accounts` + `bank/banks` sub-resource under a MANAGER `bank:manage-accounts` ability. Web: `/banco` gained an account picker (remembered per browser) and reads every figure in the selected account's currency, `/banco/cuentas` manages banks and accounts, and `/inicio`'s chequera card names the account it is showing instead of implying one register. An account's `currency` is immutable after creation by design — its booked movements are denominated in it. Verified against dev + browser: a second USD account showed full read/write isolation from the MXN register, whose totals were unchanged.
     - **Customer-number recycling** — promotes the legacy `NUM id` (currently only inside `customer_legacy_refs`) into a first-class, reusable `Customer.customerNumber`, automates *finding* candidates for reuse (cancelled / 1-year-inactive), and auto-assigns the lowest free number at creation — the search is automated, the release/reuse decision stays a human action. Backfill needs care: ~140 utilities rows and all insurance-only customers have no real legacy number (synthetic `rownum_N`/`insrow_N` placeholders in `transform_customers.py`, not real `NUM id`s).
     
     Several open questions block parts of this (OCR provider/budget, the Seguros bank's identity, the clave-catastral-vs-predial mismatch, exact recycling triggers, and whether "recycling" should ever mean true data purge vs. archive-and-reuse-the-number) — see the spec's collected open-questions section.
-12. **Insurance features — NOT STARTED, spec written.** Full design in [`docs/INSURANCE_FEATURES_SPEC.md`](docs/INSURANCE_FEATURES_SPEC.md), the insurance half of the same 2026-07-25/26 meeting with Jorge that produced step 11:
-    - **Renewal notification emails** — a daily `@nestjs/schedule` sweep that mails the customer 30 days before expiry, 15 days before, and 7 days after, mapping onto `RenewalNotice.generation` 1/2/3 with **no schema change**. Sending is **Amazon SES** (`@aws-sdk/client-sesv2`, mirroring `StorageService`'s optional-client/degrade-don't-crash pattern) — the office already runs SES, so provider and budget are settled, not open. The letter body is the *existing* `aviso-renovacion` report (`reports.registry.ts:623-799`); `@@unique([policyId, generation])` is already-in-place idempotency, so a re-run cannot double-send. Volume ≈260 mails/month, and **815 of the 893 policyholders (91%) have an email**. Also adds the manual mark-as-sent mutation the report's own comment anticipates, so the report's permanently-zero `enviadas` total becomes real. Smallest useful piece — do first.
+12. **Insurance features — one of four built, rest spec'd.** Full design in [`docs/INSURANCE_FEATURES_SPEC.md`](docs/INSURANCE_FEATURES_SPEC.md), the insurance half of the same 2026-07-25/26 meeting with Jorge that produced step 11:
+    - **Renewal notification emails — DONE** (2026-08-01, extended 08-02). A sweep that mails the customer 30 days before expiry, 15 days before, and 7 days after, mapping onto `RenewalNotice.generation` 1/2/3 with **no schema change**. Sending is **Amazon SES** (`@aws-sdk/client-sesv2`, mirroring `StorageService`'s optional-client/degrade-don't-crash pattern). The letter body is the *existing* `aviso-renovacion` report; `@@unique([policyId, generation])` is already-in-place idempotency, so a re-run cannot double-send. Volume ≈260 mails/month, and **815 of the 893 policyholders (91%) have an email**.
+      **Three things came out differently from the spec.** (a) The manual mark-as-sent mutation was **dropped on purpose** — a button that marks a notice sent without sending anything lets the list claim a customer was told when they were not. `POST /renewals/send` replaced it: sending from the list *is* the marking, and the report's `enviadas` total becomes real the same way. (b) The send history is **not renewal-specific** — every attempt, including the failures and no-email skips a `RenewalNotice` row cannot represent, also writes `email_notification_log` as `RENEWAL_NOTICE`/`POLICIES`, shared with the four bulk jobs from [`docs/MASS_EMAIL_NOTIFICATIONS.md`](docs/MASS_EMAIL_NOTIFICATIONS.md). `RenewalNotice` stays *gating* state; the log is *history*. (c) The `@Cron("0 6 * * *")` literal the spec called for lasted one day: both this sweep and the servicios jobs now take their cadence from `NotificationScheduleService`, stored in `app_settings` and reinstalled on save — no redeploy. Defaults preserve the old behaviour (pólizas 06:00 daily, servicios off).
+      **Both halves live on one screen.** `/notificaciones` has Servicios and Pólizas tabs over the one log; `/renovaciones` is an alias onto the Pólizas tab. The send flags (`debug` in particular) sit in the shell above the tabs and govern both — before that there was no way to test a renewal aviso without mailing a real customer. A debug send diverts the mail, skips the `RenewalNotice` upsert **and** does not advance the sweep's `lastSuccessfulAt`; all three are needed together, or a test run silently narrows tomorrow's window and drops the letters it only pretended to send.
+      **Production status:** the `SES_*` Gitea secrets were created 2026-08-02, clearing the last blocker — but the feature has not shipped yet (master is well past the newest tag) and nothing has confirmed that `SES_FROM` is a verified SES identity or that the account is out of the sandbox. Run the first sweep with `debug` on. See [`docs/BACKLOG.md`](docs/BACKLOG.md) §0.
     - **Liquidación batch workflow** — ~70% already built (`liquidated`/`liquidationNumber`/`liquidationDate` are wired through DTOs, list filter, stats, form and detail page); only the *batch* print-and-mark step is missing, against a live pending set of 226 policies. Adds a ramo-parameterized pending report plus `POST /policies/liquidate-batch` under a new MANAGER `policy:liquidate` ability. Parameterized by ramo, not MULT-only — legacy `TABLA LIQUIDA MF` served `MULT`, `INCENDIO` and `M EMPR` alike.
     - **Certificate / "Solicitud Atlas"** — renders from the same `format: "letter"` machinery `aviso-renovacion` uses, then reaches customers as an extension of the step-8/9 replication (PDF generated here, pushed to MinIO, pointer replicated), **not** as a new public surface in this repo. Half-blocked: "Solicitud" has zero referent in the legacy system and normally means an *application form*, a different artifact from a certificate.
     - **Carrier API integration (ANA Seguros + GMX)** — shape only (`CarrierConnector` + an import-review queue rather than direct `Policy` writes, matching how step 11's OCR results are routed). Carrier research done 2026-07-27: **the two carriers are one company** — both belong to **Grupo Valore** (ANA writes autos, GMX writes daños, which is exactly this database's `AUTO`/`LICENCIAS` vs `MULT`/`INCENDIO`/`M_EMPR` split), so it is one commercial relationship, not two. **ANA has a real live SOAP service** (`server.anaseguros.com.mx/ananetws/service.asmx`, ASP.NET `.asmx`) with a published operation list — catalogs, `CalculaValor`/`CalculaMSI`, `ValidaSerie`, `RecuperaCotizacion`, `Transaccion`. **GMX publishes no machine interface at all**, only human agent portals. ⚠️ **Critical mismatch:** every ANA operation serves *new-business quoting/issuance*, not "list the policies where I am agent of record" — so if the ask is inbound portfolio sync, no evidence exists that either carrier sells it. Blocked on one phone call to Grupo Valore ((55) 5480-4000) for credentials + a direction answer, not on further research. ("GDMX" in the meeting notes was a typo for `GMX` — confirmed 2026-07-27.)
@@ -162,7 +174,13 @@ Repo scaffolded at `jorgecuadros-platform/`: npm workspaces, NestJS API with a r
 
 **Step 11 is now three-quarters built.** Receipt capture, the multi-bank chequera and PDF/OCR auto-capture are all done and verified; only customer-number recycling remains unbuilt. `docs/RECEIPT_CAPTURE_SPEC.md` carries a BUILT note per section recording what shipped and, for §2, the four things real scanned statements proved the spec had wrong or unknown.
 
-**Step 12 spec written, not built.** `docs/INSURANCE_FEATURES_SPEC.md` covers the insurance half of the same meeting (renewal emails, liquidación batch, certificate + portal delivery, carrier APIs) — see Build sequencing step 12 above. Verified the same way, plus a live query of the dev DB for the counts it quotes (email coverage, pending liquidación, installment fill rates) and of the staged Parquet for the legacy settlement-slot usage. Two of the four features are much smaller than they sound: the renewal-notice table, its idempotency key and the letter body already exist, and the per-policy liquidación fields are already wired end to end.
+Each of the two OCR intakes now has an as-built doc separate from its spec — `docs/STATEMENT_OCR.md` and `docs/POLICY_OCR.md`. The specs record what was designed and why; those record what is in the code. They share one `OcrProvider` seam (`apps/api/src/ocr/`), so the Tesseract-vs-managed-API decision is one line for both.
+
+**It also produced a feature nobody planned.** The statement OCR pipeline generalised: the same render→OCR→parse→match→review shape reads **carrier policy PDFs** into `Policy` rows, which is `docs/POLICY_OCR.md` (built 2026-08-01, GMX only so far). It belongs to step 12's subject matter but to step 11's lineage, and it is in no spec — worth knowing before reading `INSURANCE_FEATURES_SPEC.md`, which does not mention it. It also partly overlaps what §4's carrier API was wanted for, and unlike that section it is not blocked on a phone call.
+
+**Step 12 is one-quarter built.** `docs/INSURANCE_FEATURES_SPEC.md` covers the insurance half of the same meeting (renewal emails, liquidación batch, certificate + portal delivery, carrier APIs) — see Build sequencing step 12 above. Verified the same way, plus a live query of the dev DB for the counts it quotes (email coverage, pending liquidación, installment fill rates) and of the staged Parquet for the legacy settlement-slot usage. **§1 renewal emails is done** (2026-08-01/02) and carries a BUILT note recording the three places the build diverged from the spec; §2 liquidación is still the smallest remaining piece, since the per-policy fields are already wired end to end.
+
+**Notifications are one screen, not two features.** The four legacy mass-email jobs (`docs/MASS_EMAIL_NOTIFICATIONS.md`) and the insurance renewal avisos both mean "tell a customer something by email", so they are tabs of `/notificaciones` over one `email_notification_log`, with one shared flags panel and one schedule editor. `app_settings` + `SettingsService` (db → env → default) is the operator-config seam they introduced: summary recipients and both sweep cadences live there, so changing any of them is a save, not a redeploy. Credentials stay in the environment.
 
 ## Decisions (locked)
 

README.md

@@ -4,7 +4,8 @@ Internal platform for a Baja California insurance brokerage and property-service
 firm: a single expedient joining each client's **properties/services**,
 **insurance policies**, **account statement**, and the firm's **checkbook**.
 It replaces a legacy PHP/Access app (see `RESUME.md` and `PLAN.md` for the full
-history and rebuild rationale).
+history and rebuild rationale, and [`docs/BACKLOG.md`](docs/BACKLOG.md) for
+everything still outstanding).
 
 The UI is Spanish-first; the codebase and this document are in English.
 
@@ -40,8 +41,21 @@ docker-compose.yml          mysql + api + web
 ```
 
 API feature modules: `auth`, `users`, `customers`, `policies`, `properties`,
-`billing`, `bank`. Web routes: `/clientes`, `/polizas`, `/servicios`,
-`/estado-cuenta`, `/banco` (chequera), `/catalogos`, `/usuarios`, `/login`.
+`billing`, `bank`, `reports`, `notifications`, `renewals`, `mail`, `statements`,
+`policy-ocr`, `ocr`, `storage`, `settings`, `ops`.
+
+Web routes: `/inicio`, `/clientes`, `/polizas` (+ `/polizas/captura`, policy
+PDF OCR capture), `/servicios`, `/estado-cuenta`, `/banco` (chequera),
+`/recibos` (utility statement OCR capture), `/notificaciones` (mass email +
+renewal avisos; `/renovaciones` is an alias onto its Pólizas tab), `/reportes`,
+`/catalogos`, `/operaciones` (DB ingest/backup, ADMIN), `/usuarios`, `/login`.
+
+Two OCR intakes share one `OcrProvider` seam (`src/ocr/`, Tesseract today):
+utility statements → ledger rows ([`docs/STATEMENT_OCR.md`](docs/STATEMENT_OCR.md))
+and carrier policy PDFs → `Policy` rows ([`docs/POLICY_OCR.md`](docs/POLICY_OCR.md)).
+Both need `tesseract-ocr`, `tesseract-ocr-data-spa`, `poppler-utils` and object
+storage; each reports its own availability and disables only itself if either
+is missing.
 
 ---
 
@@ -195,6 +209,28 @@ python migration/run_all.py
 
 ---
 
+## Scheduled jobs
+
+The API runs two automatic email sweeps. Neither cadence is in the source:
+both are stored in `app_settings` and edited at `/notificaciones` →
+"Programación de envíos" (ADMIN, `setting:manage`), taking effect immediately
+without a restart. Shipped defaults:
+
+| Job | Default | What it does |
+| --- | ------- | ------------ |
+| Pólizas | **on**, 06:00 daily (America/Tijuana) | Renewal avisos at 30/15 days before expiry and 7 days after. |
+| Servicios | **off** | All four mass-email jobs in order, same as "Ejecutar todos". |
+
+A scheduled run never uses the UI's send flags — in particular it ignores
+`debug`, so a forgotten test toggle cannot silently stop customer mail. Full
+detail in [`docs/MASS_EMAIL_NOTIFICATIONS.md`](docs/MASS_EMAIL_NOTIFICATIONS.md).
+
+Sending needs `SES_*` in the environment. Without it the API still boots and
+logs mail to stdout in dev; in production every send fails loudly and is
+recorded as `FAILED` rather than quietly going nowhere.
+
+---
+
 ## Production notes
 
 - Use `pnpm --filter @jorgecuadros/database exec prisma migrate deploy` if/when

RESUME.md

@@ -447,6 +447,11 @@ for what's actually next.
 
 ## Statement OCR intake (`/recibos`) — DONE 2026-08-01
 
+> As-built reference: **`docs/STATEMENT_OCR.md`** (written 2026-08-02) — the
+> parsers, the matcher's scoped-field rules, confirm/learning semantics and the
+> API surface. `docs/RECEIPT_CAPTURE_SPEC.md` §2 stays the design and the
+> measured evidence. This section is the session record of building it.
+
 Plan step 11 §2 (`docs/RECEIPT_CAPTURE_SPEC.md` §2). The last big utilities
 feature: staff scan the month's utility bills and the machine proposes customer
 + amount per page, instead of keying 300+ statements per company by hand. Built
@@ -526,3 +531,167 @@ Implementation notes worth keeping:
 **Open:** whether the CFE charge should be the rounded barcode/headline figure
 (`$268`, what is paid at the window — what the parser uses today) or the exact
 breakdown total (`$268.88`). One question for Jorge.
+
+## Policy OCR capture (`/polizas/captura`) — DONE 2026-08-01, unplanned
+
+**This feature was not in any spec.** It is what the statement OCR work above
+turned into once the pipeline existed. Having built render → OCR → parse →
+match → review for CFE/CESPT/Telnor receipts, the same shape obviously fits
+the *other* stack of paper this office keys in by hand every week: the carrier
+policy PDFs behind every `Policy` row. Full write-up in `docs/POLICY_OCR.md`.
+
+The pipeline was reused rather than copied. `OcrModule` was **extracted out of
+`StatementsModule`** in the same commit so `PolicyOcrModule` could inject
+`OCR_PROVIDER` without taking on the statement pipeline — that extraction was
+blocking, not tidying; the policy module could not resolve the provider at all
+until it existed. `StatementsModule` imports it now and binds nothing itself,
+so the Tesseract-vs-managed-API decision stays one line in one file for both
+features.
+
+Screens mirror Captura exactly: `/polizas/nuevo` is the manual tab,
+`/polizas/captura` the automática one, both rendering `PolicyCaptura.tsx`, with
+the batch review queue at `/polizas/captura/[id]`. Abilities `policy:ingest` /
+`policy:ocr-review`, both STAFF — same trust tier as statement OCR, and for the
+same reason: nothing reaches the books unconfirmed.
+
+**The statement pipeline's central assumption inverts here, and that is the
+thing to remember.** Utility statements arrive bundled *one customer per page*,
+so there a page is a document and the parser runs per page. A policy PDF is the
+opposite: the GMX certificate is one policy spread across two pages (contract
+header on page 1, the per-coverage table on page 2). So every page's text is
+concatenated and the parser and matcher run **once per file**. Consequences:
+`PolicyOcrDocument.pageNumber` is repurposed as the file ordinal within the
+batch (the `(batchId, pageNumber)` unique constraint still holds), `ocrConfidence`
+is the mean across the file's pages, and a file that fails to parse yields
+exactly one `OCR_FAILED` row.
+
+`storageKey` points at the **source PDF**, not a rendered page image, so the
+review screen embeds the exact artifact the office received and gets the
+browser's native PDF scrolling, zoom and text selection for free. The page PNGs
+are still written for future re-OCR, but nothing treats them as the document's
+identity. (The statement side is the reverse, because there a page *is* the
+document.)
+
+Findings worth keeping:
+
+- **The GMX certificate has no premium on it at all.** Not intermittently
+  missing — the figure lives on GMX's separate `recibo` PDF. The parser leaves
+  the premium fields null and pushes a note saying so, confirm never overwrites
+  an existing `Policy.netPremium` with null, and the optional ledger write is
+  gated on staff ticking `postPremium` *and* a premium actually parsing.
+  Without that second gate a premium-less certificate would book a $0 charge on
+  every confirm.
+- **Match on `Policy.policyNumber`, never the printed insured name.** Same
+  registrant-vs-current-owner drift that rules names out on the utility side.
+  Zero hits means a new policy and confirm creates the row under a picked
+  customer; more than one hit is surfaced for a human, never auto-picked —
+  duplicate numbers across related parties do occur.
+- Deductible and loss participation are stored as **strings** (`"5%"`,
+  `"USD 1,000"`): they are printed as a mix of percentages, amounts and free
+  text, and normalising them would lose the distinction.
+- Carrier-portal PDFs are usually **born-digital**, so the text layer wins and
+  no OCR runs at all most of the time — same precedence rule as the statement
+  pipeline.
+- The digit-confusion map and the amount-by-separator-position parser are
+  **duplicated on purpose** rather than imported, to keep the module
+  self-contained. Fix a bug in one, check the other.
+
+8/8 parser tests, all against verbatim text from one real document
+(`HC_Folio_000767_Traduccion.pdf`).
+
+**Open:** GMX is the only carrier implemented — the dispatcher is a
+`[provider, pattern]` table plus a parser map, so a second carrier is a
+function and two entries, but no other layout has been seen. Reading the
+premium off the separate `recibo` PDF and pairing it to its certificate is the
+obvious next piece; it is what would let `postPremium` stop being a manual
+tick. And nothing versions a re-issued policy — confirm updates the existing
+row, so there is no record that this is the 2027 issue of that number.
+
+
+## Notificaciones (`/notificaciones`) — DONE 2026-08-01 → 08-02
+
+Two features that were spec'd separately turned out to be one screen. The four
+legacy mass-email jobs (`docs/MASS_EMAIL_NOTIFICATIONS.md`, ported from
+`email.notifications/send*.php`) and the insurance renewal avisos
+(`docs/INSURANCE_FEATURES_SPEC.md` §1) both mean *tell a customer something by
+email*, so they are **tabs of one screen over one log**, not two menu entries.
+`/renovaciones` is an alias that lands on the Pólizas tab, the same pattern
+Captura uses.
+
+- **Servicios tab** — the four jobs (pagos pendientes, confirmación de pago,
+  estado de cuenta, fideicomiso), individually or "Ejecutar todos". Ability
+  `notification:send` (MANAGER); STAFF sees the log read-only.
+- **Pólizas tab** — pending avisos at 30/15 days before expiry and 7 days
+  after, sent one at a time or as a sweep. Ability `renewal:send` (MANAGER).
+
+**One send log for the whole platform.** `email_notification_log` is not
+job-specific: renewals write it too (`RENEWAL_NOTICE` / `POLICIES`) through the
+same `NotificationLogService`. That is what makes "Registro de envíos" complete
+— the failures and no-email skips exist *only* there. `RenewalNotice` was not
+made redundant by it: that row is **gating** state (one per policy+generation,
+drives the pending list), the log is **history** (every attempt). `level` is
+therefore per-type and unreadable without its `notificationType` — 0/1
+yellow/red on `ACCOUNT_STATUS`, the aviso generation 1/2/3 on
+`RENEWAL_NOTICE`.
+
+**Manual mark-as-sent was dropped on purpose.** The spec called for it; a
+button that marks a notice sent without sending anything is a button that lets
+the list claim a customer was told when they were not. `POST /renewals/send`
+replaced it — sending from the list *is* the marking.
+
+**`app_settings` is the operator-config seam this work introduced.**
+`SettingsService` resolves every key **db → env → default** and reports which
+rung a value came from, so an existing deployment keeps behaving exactly as it
+did until somebody saves in the UI. Three keys today: the summary recipients
+(was `NOTIFICATION_ADMIN_EMAILS`, now a fallback) and the two sweep cadences.
+Credentials deliberately stay in the environment — SES keys, `DATABASE_URL`
+and S3 config are deployment identity, must exist before the app can reach its
+own database, and a table only widens who can read them.
+
+**The send flags are global, and that was a real bug fix (08-02).** The
+`debug` / `ignoreDayRestriction` / `useEmailLimit` panel lived inside the
+Servicios tab, so there was **no way to test a renewal aviso without mailing a
+real customer**. It now lives in the shell above the tabs and both halves read
+it. On the pólizas path `debug` does three things, and all three are required
+together: it diverts the mail, it skips the `RenewalNotice` upsert, and it does
+not advance the sweep's `lastSuccessfulAt`. Miss the third and `renewalWindow()`
+narrows back to a single day on the next real run — a test send would silently
+destroy the letters it only pretended to send. Flags are per-visit UI state and
+are **never persisted**; a stored `debug` would survive a reload and swallow
+real customer mail until somebody noticed.
+
+**Both cadences are operator-editable (08-02).** The renewal sweep's
+`@Cron("0 6 * * *")` literal lasted one day. `NotificationScheduleService` now
+owns both: the owning services register a handler in `onModuleInit`, the
+service compiles the stored `{hour, minute, weekdays}` to a cron expression and
+installs it in `SchedulerRegistry`, and saving from the UI reinstalls the job —
+no restart, which was the point. It lives in its own module for the same reason
+as `NotificationLogModule`: `NotificationsModule` and `RenewalsModule` both need
+it and neither may import the other. Defaults preserve prior behaviour exactly
+(pólizas 06:00 daily, servicios **off** — a default that starts mailing 260
+customers after a deploy is not a default, it's an incident). A scheduled run
+never inherits the UI flags: no `debug`, and no `ignoreDayRestriction`, since an
+automatic run on the operator's own cadence is precisely the case the
+Mon/Wed/Fri gate was written for.
+
+Implementation notes worth keeping:
+
+- `cron` had to become a **direct dependency of `apps/api`**. It is a
+  transitive dep of `@nestjs/schedule`, but pnpm's strict layout does not hoist
+  it, so `import { CronJob } from "cron"` does not resolve without it.
+- The pólizas sweep already had a DB lock (`scheduled_job_states`); the
+  servicios run-all does not, and relies on the deployment being
+  single-replica, which it is on galactus today.
+- Wire shapes of the four jobs are byte-for-byte the legacy PHP responses,
+  quirks included (Job 1 reports `result`, not `request`).
+
+**Open:** the `SES_*` Gitea secrets were created 2026-08-02, so the feature is
+no longer blocked — but it has not shipped (master is well past the newest tag)
+and two things nobody has checked decide whether mail leaves the building:
+`SES_FROM` must be a verified identity in `SES_REGION`, and the AWS account
+must be out of the SES sandbox, which otherwise restricts delivery to verified
+recipients and would fail a real sweep while looking correctly configured. Run
+the first sweep with `debug` on. Still open beyond that: the 78 policyholders
+with no email are logged as `SKIPPED_NO_EMAIL` but have no printable worklist,
+and the notice body is English-only (`Customer` carries no language
+preference).

apps/api/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jorgecuadros/api",
-  "version": "1.0.6",
+  "version": "1.0.8",
   "private": true,
   "scripts": {
     "build": "nest build",
@@ -23,6 +23,7 @@
     "argon2": "^0.41.1",
     "class-transformer": "^0.5.1",
     "class-validator": "^0.14.1",
+    "cron": "^3.2.1",
     "exceljs": "^4.4.0",
     "express-session": "^1.18.0",
     "passport": "^0.7.0",

apps/api/src/auth/abilities.ts

@@ -40,7 +40,8 @@ export type Ability =
   | "lookup:manage"
   | "user:manage"
   | "db:manage"
-  | "notification:send";
+  | "notification:send"
+  | "setting:manage";
 
 /** Minimum role required for each ability. */
 export const ABILITY_MIN: Record<Ability, Role> = {
@@ -79,6 +80,10 @@ export const ABILITY_MIN: Record<Ability, Role> = {
   // a STAFF user typing one customer receipt is fine; a STAFF user firing
   // 260 mail merges on the customer base is not.
   "notification:send": "MANAGER",
+  // Editing operator configuration. Above `notification:send` on purpose:
+  // firing a sweep is the day job, but changing WHERE the audit summaries
+  // land is how someone would quietly stop them being read.
+  "setting:manage": "ADMIN",
 };
 
 export const ALL_ABILITIES = Object.keys(ABILITY_MIN) as Ability[];

apps/api/src/mail/mail.module.ts

@@ -1,12 +1,13 @@
-import { Module } from "@nestjs/common";
-import { ConfigService } from "@nestjs/config";
+import { Global, Module } from "@nestjs/common";
 import { MailService } from "./mail.service";
 
 /** Global so any feature module can inject MailService without re-importing.
  *  Matches the StorageService pattern: env-driven, null when unconfigured,
- *  and never blocks API boot. Notifications use it; renewals reuse it. */
+ *  and never blocks API boot. Notifications use it; renewals reuse it.
+ *  ConfigService comes from the global ConfigModule in AppModule. */
+@Global()
 @Module({
-  providers: [{ provide: MailService, useFactory: (c: ConfigService) => new MailService(c) }],
+  providers: [MailService],
   exports: [MailService],
 })
 export class MailModule {}

apps/api/src/notifications/notification-log.module.ts

@@ -0,0 +1,14 @@
+import { Module } from "@nestjs/common";
+import { NotificationLogService } from "./notification-log.service";
+
+/**
+ * Just the log writer, so a feature that sends mail can record it without
+ * importing `NotificationsModule` (which carries the four bulk-job pipelines
+ * and their controller). Imported by `NotificationsModule` and
+ * `RenewalsModule`.
+ */
+@Module({
+  providers: [NotificationLogService],
+  exports: [NotificationLogService],
+})
+export class NotificationLogModule {}

apps/api/src/notifications/notification-log.service.ts

@@ -0,0 +1,74 @@
+import { Injectable } from "@nestjs/common";
+import {
+  EmailNotificationServicio,
+  EmailNotificationStatus,
+  EmailNotificationType,
+} from "@jorgecuadros/database";
+import { PrismaService } from "../prisma/prisma.service";
+import { AttemptStatus } from "./notification.types";
+
+/**
+ * The single writer for `email_notification_log`.
+ *
+ * Extracted out of `NotificationsService` so the renewal sweep can write the
+ * same rows as the four bulk jobs without pulling that service (and its four
+ * job pipelines) into `RenewalsModule`. Every outbound email the platform
+ * sends goes through here, which is what makes /notificaciones' "Registro de
+ * envíos" complete rather than per-feature.
+ */
+export interface NotificationLogEntry {
+  notificationType: EmailNotificationType;
+  servicio: EmailNotificationServicio;
+  /** Defaults to now(). Pass it when the row must line up exactly with
+   *  another record of the same send (the renewal sweep pins it to
+   *  `RenewalNotice.sentAt`). */
+  sendDate?: Date;
+  /** Type-dependent discriminator — see the `level` doc on the Prisma model.
+   *  0/1 for ACCOUNT_STATUS, the generation for RENEWAL_NOTICE. */
+  level?: number | null;
+  customerId: string | null;
+  customerName: string;
+  customerEmail: string;
+  subject: string;
+  bodySnapshot: string;
+  bodyRequestUrl?: string;
+  status: AttemptStatus;
+  debug: boolean;
+  providerMessageId?: string;
+  providerResponse?: string;
+  error?: string;
+}
+
+/** `providerResponse` is a VARCHAR(191); anything longer is a provider dump
+ *  we only need the head of. Errors go to the TEXT `error` column and get
+ *  the 4k cap the schema documents. */
+const PROVIDER_RESPONSE_MAX = 180;
+const ERROR_MAX = 4096;
+
+@Injectable()
+export class NotificationLogService {
+  constructor(private readonly prisma: PrismaService) {}
+
+  async record(entry: NotificationLogEntry): Promise<void> {
+    await this.prisma.emailNotificationLog.create({
+      data: {
+        notificationType: entry.notificationType,
+        servicio: entry.servicio,
+        ...(entry.sendDate && { sendDate: entry.sendDate }),
+        level: entry.level ?? null,
+        customerId: entry.customerId,
+        customerName: entry.customerName,
+        customerEmail: entry.customerEmail,
+        subject: entry.subject,
+        bodySnapshot: entry.bodySnapshot,
+        bodyRequestUrl: entry.bodyRequestUrl ?? null,
+        debug: entry.debug,
+        providerMessageId: entry.providerMessageId ?? null,
+        providerResponse:
+          entry.providerResponse?.slice(0, PROVIDER_RESPONSE_MAX) ?? null,
+        status: entry.status as EmailNotificationStatus,
+        error: entry.error?.slice(0, ERROR_MAX) ?? null,
+      },
+    });
+  }
+}

apps/api/src/notifications/notification-schedule.module.ts

@@ -0,0 +1,15 @@
+import { Module } from "@nestjs/common";
+import { SettingsModule } from "../settings/settings.module";
+import { NotificationScheduleService } from "./notification-schedule.service";
+
+/**
+ * Just the cadence registry, split out for the same reason as
+ * `NotificationLogModule`: both `NotificationsModule` and `RenewalsModule`
+ * need it, and neither may import the other.
+ */
+@Module({
+  imports: [SettingsModule],
+  providers: [NotificationScheduleService],
+  exports: [NotificationScheduleService],
+})
+export class NotificationScheduleModule {}

apps/api/src/notifications/notification-schedule.service.ts

@@ -0,0 +1,203 @@
+import { Injectable, Logger } from "@nestjs/common";
+import { SchedulerRegistry } from "@nestjs/schedule";
+import { CronJob } from "cron";
+import { SettingsService } from "../settings/settings.service";
+import type { ResolvedSetting } from "../settings/settings.service";
+
+/**
+ * When the two automatic envíos run.
+ *
+ * Both halves of /notificaciones used to be hardcoded: pólizas swept at 06:00
+ * from a `@Cron` decorator, servicios had no automatic run at all and had to
+ * be clicked. Neither could be changed without a redeploy. This service owns
+ * the cadence for both, stores it in `app_settings`, and re-installs the job
+ * the moment an operator saves — no restart.
+ *
+ * The owning services register their handler at boot rather than this service
+ * importing them: `NotificationsService` and `RenewalsService` would otherwise
+ * have to be injected here, and this file is imported by both.
+ */
+
+export const SCHEDULE_TIME_ZONE = "America/Tijuana";
+
+export type ScheduleKind = "servicios" | "polizas";
+
+export const SCHEDULE_KINDS: ScheduleKind[] = ["servicios", "polizas"];
+
+export interface NotificationSchedule {
+  enabled: boolean;
+  /** Local hour/minute in `SCHEDULE_TIME_ZONE`, not UTC — the office thinks
+   *  in Tijuana time and DST would otherwise drift the run by an hour. */
+  hour: number;
+  minute: number;
+  /** 0 = Sunday … 6 = Saturday. Empty means every day. */
+  weekdays: number[];
+}
+
+export interface ResolvedSchedule extends ResolvedSetting<NotificationSchedule> {
+  /** The cron expression the value compiles to, shown in the UI so the
+   *  operator can see exactly what was installed. */
+  cron: string;
+  /** Next fire time, or null when disabled. */
+  nextRun: string | null;
+}
+
+/**
+ * Defaults preserve what each half did before this existed: pólizas keeps its
+ * 06:00 daily sweep, servicios stays OFF. Turning a mass send on is an
+ * operator decision — a default that starts mailing 260 customers on its own
+ * after a deploy is not a default, it's an incident.
+ */
+const DEFAULTS: Record<ScheduleKind, NotificationSchedule> = {
+  servicios: { enabled: false, hour: 7, minute: 0, weekdays: [1, 3, 5] },
+  polizas: { enabled: true, hour: 6, minute: 0, weekdays: [] },
+};
+
+/** Human label used in log lines and audit entries. */
+export const SCHEDULE_LABELS: Record<ScheduleKind, string> = {
+  servicios: "envíos de servicios",
+  polizas: "avisos de renovación",
+};
+
+export function scheduleCron(schedule: NotificationSchedule): string {
+  const dow = schedule.weekdays.length
+    ? [...new Set(schedule.weekdays)].sort((a, b) => a - b).join(",")
+    : "*";
+  return `${schedule.minute} ${schedule.hour} * * ${dow}`;
+}
+
+/** Reject anything that would compile to a cron we can't install. Returns the
+ *  normalized value, or a message naming the offending field. */
+export function parseSchedule(
+  raw: unknown,
+): { ok: true; value: NotificationSchedule } | { ok: false; error: string } {
+  const v = raw as Partial<NotificationSchedule> | null;
+  if (!v || typeof v !== "object") return { ok: false, error: "Horario inválido." };
+  const hour = Number(v.hour);
+  const minute = Number(v.minute);
+  if (!Number.isInteger(hour) || hour < 0 || hour > 23) {
+    return { ok: false, error: "La hora debe estar entre 0 y 23." };
+  }
+  if (!Number.isInteger(minute) || minute < 0 || minute > 59) {
+    return { ok: false, error: "Los minutos deben estar entre 0 y 59." };
+  }
+  const weekdays = Array.isArray(v.weekdays) ? v.weekdays.map(Number) : [];
+  if (weekdays.some((d) => !Number.isInteger(d) || d < 0 || d > 6)) {
+    return { ok: false, error: "Los días deben estar entre 0 (domingo) y 6." };
+  }
+  return {
+    ok: true,
+    value: {
+      enabled: !!v.enabled,
+      hour,
+      minute,
+      weekdays: [...new Set(weekdays)].sort((a, b) => a - b),
+    },
+  };
+}
+
+@Injectable()
+export class NotificationScheduleService {
+  private readonly logger = new Logger(NotificationScheduleService.name);
+  private readonly handlers = new Map<ScheduleKind, () => Promise<unknown>>();
+
+  constructor(
+    private readonly settings: SettingsService,
+    private readonly registry: SchedulerRegistry,
+  ) {}
+
+  /**
+   * Called once per kind at boot by the service that owns the sweep. Installs
+   * the job immediately so a freshly started process honours the stored
+   * cadence without waiting for someone to open the UI.
+   */
+  async register(kind: ScheduleKind, handler: () => Promise<unknown>) {
+    this.handlers.set(kind, handler);
+    await this.apply(kind);
+  }
+
+  async get(kind: ScheduleKind): Promise<ResolvedSchedule> {
+    const resolved = await this.settings.notificationSchedule(
+      kind,
+      DEFAULTS[kind],
+    );
+    const cron = scheduleCron(resolved.value);
+    return { ...resolved, cron, nextRun: this.nextRun(kind) };
+  }
+
+  async getAll(): Promise<Record<ScheduleKind, ResolvedSchedule>> {
+    const entries = await Promise.all(
+      SCHEDULE_KINDS.map(async (k) => [k, await this.get(k)] as const),
+    );
+    return Object.fromEntries(entries) as Record<ScheduleKind, ResolvedSchedule>;
+  }
+
+  async set(
+    kind: ScheduleKind,
+    schedule: NotificationSchedule,
+    userId: string,
+  ): Promise<ResolvedSchedule> {
+    await this.settings.setNotificationSchedule(kind, schedule, userId);
+    await this.apply(kind);
+    return this.get(kind);
+  }
+
+  /** (Re)install the cron job for one kind from whatever is stored now. */
+  private async apply(kind: ScheduleKind): Promise<void> {
+    const handler = this.handlers.get(kind);
+    if (!handler) return;
+
+    this.remove(kind);
+
+    const { value } = await this.settings.notificationSchedule(
+      kind,
+      DEFAULTS[kind],
+    );
+    if (!value.enabled) {
+      this.logger.log(`Horario de ${SCHEDULE_LABELS[kind]}: desactivado.`);
+      return;
+    }
+
+    const cron = scheduleCron(value);
+    const job = new CronJob(
+      cron,
+      () => {
+        void handler().catch((error) =>
+          this.logger.error(
+            `Falló la corrida programada de ${SCHEDULE_LABELS[kind]}: ` +
+              `${(error as Error).message}`,
+          ),
+        );
+      },
+      null,
+      false,
+      SCHEDULE_TIME_ZONE,
+    );
+    this.registry.addCronJob(this.jobName(kind), job);
+    job.start();
+    this.logger.log(
+      `Horario de ${SCHEDULE_LABELS[kind]}: ${cron} (${SCHEDULE_TIME_ZONE}).`,
+    );
+  }
+
+  private remove(kind: ScheduleKind): void {
+    const name = this.jobName(kind);
+    // `deleteCronJob` throws when the job was never installed, which is the
+    // normal case on first apply — presence check instead of try/catch so a
+    // real failure still surfaces.
+    if (!this.registry.doesExist("cron", name)) return;
+    this.registry.getCronJob(name).stop();
+    this.registry.deleteCronJob(name);
+  }
+
+  private nextRun(kind: ScheduleKind): string | null {
+    const name = this.jobName(kind);
+    if (!this.registry.doesExist("cron", name)) return null;
+    const next = this.registry.getCronJob(name).nextDate();
+    return next ? next.toJSDate().toISOString() : null;
+  }
+
+  private jobName(kind: ScheduleKind): string {
+    return `notification-schedule:${kind}`;
+  }
+}

apps/api/src/notifications/notification-schedule.spec.ts

@@ -0,0 +1,57 @@
+import { parseSchedule, scheduleCron } from "./notification-schedule.service";
+
+/**
+ * The cadence editor's only sharp edge: a stored value compiles to a cron
+ * expression that the scheduler installs verbatim. A malformed one either
+ * throws at install time (taking the sweep down) or silently installs the
+ * wrong cadence, so validation happens before anything is written.
+ */
+
+describe("scheduleCron", () => {
+  it("compiles a daily schedule with no weekday filter", () => {
+    expect(
+      scheduleCron({ enabled: true, hour: 6, minute: 0, weekdays: [] }),
+    ).toBe("0 6 * * *");
+  });
+
+  it("compiles the legacy Mon/Wed/Fri cadence, sorted and de-duplicated", () => {
+    expect(
+      scheduleCron({ enabled: true, hour: 7, minute: 30, weekdays: [5, 1, 3, 1] }),
+    ).toBe("30 7 * * 1,3,5");
+  });
+});
+
+describe("parseSchedule", () => {
+  it("normalizes weekdays and coerces enabled to a boolean", () => {
+    const parsed = parseSchedule({
+      enabled: 1,
+      hour: 6,
+      minute: 0,
+      weekdays: [3, 1, 3],
+    });
+    expect(parsed).toEqual({
+      ok: true,
+      value: { enabled: true, hour: 6, minute: 0, weekdays: [1, 3] },
+    });
+  });
+
+  it("defaults a missing weekday list to every day", () => {
+    const parsed = parseSchedule({ enabled: true, hour: 0, minute: 0 });
+    expect(parsed.ok && parsed.value.weekdays).toEqual([]);
+  });
+
+  it.each([
+    [{ enabled: true, hour: 24, minute: 0 }, "hora"],
+    [{ enabled: true, hour: 6, minute: 60 }, "minutos"],
+    [{ enabled: true, hour: 6, minute: 0, weekdays: [7] }, "días"],
+    [{ enabled: true, hour: 6.5, minute: 0 }, "hora"],
+  ])("rejects %p", (input, field) => {
+    const parsed = parseSchedule(input);
+    expect(parsed.ok).toBe(false);
+    expect(!parsed.ok && parsed.error.toLowerCase()).toContain(field);
+  });
+
+  it("rejects a non-object", () => {
+    expect(parseSchedule(null).ok).toBe(false);
+  });
+});

apps/api/src/notifications/notification.types.ts

@@ -5,13 +5,24 @@ import {
 import { IsBoolean, IsEnum, IsOptional } from "class-validator";
 
 /**
- * Shared flags for the four notification jobs. Every endpoint takes the
- * same shape so the UI can be uniform; each flag is documented inline so
- * the per-job semantics are obvious in one place.
+ * Where `debug` sends everything. The PHP used `rmancinas@freakma.net`;
+ * same here. Exported because the flag is platform-wide — the renewal
+ * notices honour it too, and two copies of this address would eventually
+ * disagree.
+ */
+export const DEBUG_RECIPIENT = "rmancinas@freakma.net";
+
+/**
+ * Shared flags for every notification send — the four servicios jobs and
+ * the pólizas renewal notices alike. Every endpoint takes the same shape
+ * so the UI can offer one set of switches for the whole screen; each flag
+ * is documented inline so the per-job semantics are obvious in one place.
  *
- * `debug`            — replace every recipient with the admin override
- *                      address so a real customer never receives mail
- *                      during a test run. Logged on every row.
+ * `debug`            — replace every recipient with `DEBUG_RECIPIENT` so a
+ *                      real customer never receives mail during a test run.
+ *                      Logged on every row. On the renewal side a debug send
+ *                      also does NOT write the `RenewalNotice` row, so a test
+ *                      can't gate the letter the customer is still owed.
  * `ignoreDayRestriction` — Job 3 only: bypass the Mon/Wed/Fri (red) and
  *                      Wed-only (yellow) day gates. Off by default so
  *                      the on-demand sweep behaves like the legacy
@@ -103,6 +114,44 @@ export type NotificationJobResponse =
       type: "TRUST_PAYMENT_CONFIRMATION";
     };
 
+/** The four jobs, in the order the "ejecutar todos" sweep runs them. */
+export type NotificationJobKind =
+  | "outstanding"
+  | "payment"
+  | "account"
+  | "trust";
+
+/**
+ * One entry of the run-all sweep. A job that throws does NOT abort the
+ * sweep — it is recorded with `ok: false` and the next job still runs, so a
+ * single bad query can't silently block the other three envíos.
+ */
+export interface NotificationRunAllJobResult {
+  kind: NotificationJobKind;
+  ok: boolean;
+  result?: NotificationJobResponse;
+  error?: string;
+}
+
+/**
+ * Aggregate response for `POST /notifications/run-all`. `sent/skipped/failed`
+ * are the sums across every job that completed; `jobs` keeps each job's own
+ * verbatim legacy response so the UI can still show per-job detail.
+ */
+export interface NotificationRunAllResponse {
+  request: "success";
+  notificationType: "runAllNotifications";
+  statusCode: 200;
+  debug: boolean;
+  sent: number;
+  skipped: number;
+  failed: number;
+  /** Jobs that threw — sweep continued past them. */
+  errors: number;
+  jobs: NotificationRunAllJobResult[];
+  type: "RUN_ALL";
+}
+
 /** Normalized record for a single send attempt, fed by all four jobs. */
 export interface SendAttempt {
   notificationType: EmailNotificationType;

apps/api/src/notifications/notifications.controller.ts

@@ -1,9 +1,12 @@
 import {
+  BadRequestException,
   Body,
   Controller,
   Get,
   HttpCode,
+  Param,
   Post,
+  Put,
   Query,
   Req,
   UseGuards,
@@ -15,11 +18,28 @@ import {
   EmailNotificationType,
 } from "@jorgecuadros/database";
 import { Transform, Type } from "class-transformer";
-import { IsEnum, IsInt, IsOptional, Max, Min } from "class-validator";
+import {
+  ArrayMaxSize,
+  IsArray,
+  IsBoolean,
+  IsEnum,
+  IsInt,
+  IsOptional,
+  IsString,
+  Max,
+  Min,
+} from "class-validator";
 import { AuthenticatedGuard } from "../auth/authenticated.guard";
 import { AbilityGuard } from "../auth/ability.guard";
 import { RequireAbility } from "../auth/require-ability.decorator";
 import { AuditService } from "../common/audit.service";
+import { invalidEmails, SettingsService } from "../settings/settings.service";
+import {
+  NotificationScheduleService,
+  parseSchedule,
+  SCHEDULE_KINDS,
+  ScheduleKind,
+} from "./notification-schedule.service";
 import { NotificationFlagsDto } from "./notification.types";
 import { NotificationsService } from "./notifications.service";
 
@@ -31,11 +51,40 @@ class ListLogDto {
   @IsOptional() @Type(() => Number) @IsInt() @Min(1) page?: number;
   @IsOptional() @Type(() => Number) @IsInt() @Min(1) @Max(200) pageSize?: number;
   @IsOptional() @IsEnum(EmailNotificationType) type?: EmailNotificationType;
-  @IsOptional() @IsEnum(EmailNotificationServicio) servicio?: EmailNotificationServicio;
+  /** One or more servicios, comma-separated. The /notificaciones tabs each
+   *  read their own slice of the one log: Servicios passes
+   *  `CUSTOMERS,TRUST`, Pólizas passes `POLICIES`. Omitted = every servicio. */
+  @IsOptional()
+  @Transform(({ value }) =>
+    typeof value === "string"
+      ? value.split(",").map((s) => s.trim()).filter(Boolean)
+      : value,
+  )
+  @IsEnum(EmailNotificationServicio, { each: true })
+  servicio?: EmailNotificationServicio[];
   @IsOptional() @IsEnum(EmailNotificationStatus) status?: EmailNotificationStatus;
   @IsOptional() @IsEnum(["sent", "failed", "skipped", "all"]) view?: "sent" | "failed" | "skipped" | "all";
 }
 
+/** An empty array is valid and means "send no summaries" — the cap only
+ *  exists so a paste accident can't write an unbounded blob. */
+class AdminEmailsDto {
+  @IsArray()
+  @ArrayMaxSize(50)
+  @IsString({ each: true })
+  emails!: string[];
+}
+
+/** Cadence of one automatic envío. Ranges are re-checked by `parseSchedule`,
+ *  which is also what the scheduler itself uses — the decorators here only
+ *  reject wrong *types* so a bad payload fails at the edge. */
+class ScheduleDto {
+  @IsBoolean() enabled!: boolean;
+  @IsInt() @Min(0) @Max(23) hour!: number;
+  @IsInt() @Min(0) @Max(59) minute!: number;
+  @IsOptional() @IsArray() @IsInt({ each: true }) weekdays?: number[];
+}
+
 function actingId(req: Request): string {
   return (req.user as { id: string }).id;
 }
@@ -52,6 +101,8 @@ export class NotificationsController {
   constructor(
     private readonly svc: NotificationsService,
     private readonly audit: AuditService,
+    private readonly settings: SettingsService,
+    private readonly schedule: NotificationScheduleService,
   ) {}
 
   /* -------------------------------------------------------------- triggers */
@@ -139,6 +190,35 @@ export class NotificationsController {
     return result;
   }
 
+  /**
+   * Run all four jobs sequentially with one set of flags. Audited as a
+   * single `notification.run-all.run` entry carrying the aggregate totals
+   * plus each job's outcome — the per-job endpoints are NOT re-audited, so
+   * the log has exactly one row per staff click.
+   */
+  @Post("run-all")
+  @RequireAbility("notification:send")
+  @HttpCode(200)
+  async runAll(
+    @Body() body: RunJobDto,
+    @Query() query: RunJobDto,
+    @Req() req: Request,
+  ) {
+    const flags = { ...query, ...body };
+    const result = await this.svc.runAll(flags);
+    void this.audit.log(actingId(req), "notification.run-all.run", {
+      debug: !!flags.debug,
+      ignoreDayRestriction: !!flags.ignoreDayRestriction,
+      useEmailLimit: !!flags.useEmailLimit,
+      sent: result.sent,
+      skipped: result.skipped,
+      failed: result.failed,
+      errors: result.errors,
+      jobs: result.jobs.map((j) => ({ kind: j.kind, ok: j.ok })),
+    });
+    return result;
+  }
+
   /* ----------------------------------------------------------- read views */
 
   @Get("log")
@@ -156,19 +236,96 @@ export class NotificationsController {
   }
 
   @Get("stats")
-  stats() {
-    return this.svc.stats();
+  stats(@Query() q: ListLogDto) {
+    return this.svc.stats(q.servicio);
   }
 
+  /* -------------------------------------------------------------- settings */
+
+  /** Who receives the per-job summary email. Readable by any logged-in user
+   *  so the UI can show the current list; editing needs `setting:manage`. */
+  @Get("settings/admin-emails")
+  adminEmails() {
+    return this.settings.notificationAdminEmails();
+  }
+
+  @Put("settings/admin-emails")
+  @RequireAbility("setting:manage")
+  async setAdminEmails(@Body() dto: AdminEmailsDto, @Req() req: Request) {
+    const emails = dto.emails.map((e) => e.trim()).filter(Boolean);
+    const bad = invalidEmails(emails);
+    if (bad.length) {
+      throw new BadRequestException(
+        `Correo inválido: ${bad.join(", ")}`,
+      );
+    }
+    const result = await this.settings.setNotificationAdminEmails(
+      emails,
+      actingId(req),
+    );
+    void this.audit.log(actingId(req), "notification.settings.admin-emails", {
+      emails,
+    });
+    return result;
+  }
+
+  /* -------------------------------------------------------------- schedule */
+
+  /**
+   * Cadence of both automatic envíos. Readable by any logged-in user so the
+   * screen can show "próxima corrida" without needing edit rights; changing
+   * it needs `setting:manage`, same as the summary recipients.
+   */
+  @Get("settings/schedule")
+  schedules() {
+    return this.schedule.getAll();
+  }
+
+  @Put("settings/schedule/:kind")
+  @RequireAbility("setting:manage")
+  async setSchedule(
+    @Param("kind") kind: string,
+    @Body() dto: ScheduleDto,
+    @Req() req: Request,
+  ) {
+    if (!SCHEDULE_KINDS.includes(kind as ScheduleKind)) {
+      throw new BadRequestException(
+        `Horario desconocido: ${kind}. Use ${SCHEDULE_KINDS.join(" o ")}.`,
+      );
+    }
+    const parsed = parseSchedule({ ...dto, weekdays: dto.weekdays ?? [] });
+    if (!parsed.ok) throw new BadRequestException(parsed.error);
+
+    const result = await this.schedule.set(
+      kind as ScheduleKind,
+      parsed.value,
+      actingId(req),
+    );
+    void this.audit.log(actingId(req), "notification.settings.schedule", {
+      kind,
+      ...parsed.value,
+      cron: result.cron,
+    });
+    return result;
+  }
+
+  /** Resolve the UI's coarse view tabs to concrete statuses. An explicit
+   *  `status` wins. "Omitidos" covers both SKIPPED_* variants, which is why
+   *  this returns a list rather than a single value. */
   private mapViewStatus(
     view: ListLogDto["view"],
     status: ListLogDto["status"],
-  ): EmailNotificationStatus | undefined {
-    if (status) return status;
+  ): EmailNotificationStatus[] | undefined {
+    if (status) return [status];
     if (!view || view === "all") return undefined;
-    if (view === "sent") return EmailNotificationStatus.SENT;
-    if (view === "failed") return EmailNotificationStatus.FAILED;
-    if (view === "skipped") return undefined; // both SKIPPED_* variants
+    if (view === "sent") return [EmailNotificationStatus.SENT];
+    if (view === "failed") return [EmailNotificationStatus.FAILED];
+    if (view === "skipped") {
+      return [
+        EmailNotificationStatus.SKIPPED_NO_EMAIL,
+        EmailNotificationStatus.SKIPPED_GATE,
+      ];
+    }
     return undefined;
   }
 }

apps/api/src/notifications/notifications.module.ts

@@ -1,4 +1,7 @@
 import { Module } from "@nestjs/common";
+import { NotificationLogModule } from "./notification-log.module";
+import { NotificationScheduleModule } from "./notification-schedule.module";
+import { SettingsModule } from "../settings/settings.module";
 import { NotificationsController } from "./notifications.controller";
 import { NotificationsService } from "./notifications.service";
 
@@ -6,11 +9,12 @@ import { NotificationsService } from "./notifications.service";
  * Mass email notifications. MailModule is global (registered in AppModule),
  * so this module needs no MailService import — it picks it up by injection.
  *
- * Cron sweeps (a future `@nestjs/schedule` trigger of these four methods on
- * the legacy Mon/Wed/Fri cadence) belong in this module; the per-job
- * service methods are already the entry points they would call.
+ * The automatic sweep is registered by `NotificationsService` against
+ * `NotificationScheduleService`, which owns the cadence for both halves of
+ * /notificaciones and stores it in `app_settings`.
  */
 @Module({
+  imports: [NotificationLogModule, NotificationScheduleModule, SettingsModule],
   controllers: [NotificationsController],
   providers: [NotificationsService],
   exports: [NotificationsService],

apps/api/src/notifications/notifications.service.ts

@@ -1,5 +1,9 @@
-import { Injectable, Logger, ServiceUnavailableException } from "@nestjs/common";
-import { ConfigService } from "@nestjs/config";
+import {
+  Injectable,
+  Logger,
+  OnModuleInit,
+  ServiceUnavailableException,
+} from "@nestjs/common";
 import {
   Currency,
   EmailNotificationServicio,
@@ -10,9 +14,16 @@ import {
 } from "@jorgecuadros/database";
 import { MailService } from "../mail/mail.service";
 import { PrismaService } from "../prisma/prisma.service";
+import { SettingsService } from "../settings/settings.service";
+import { NotificationLogService } from "./notification-log.service";
+import { NotificationScheduleService } from "./notification-schedule.service";
 import {
+  DEBUG_RECIPIENT,
   SendAttempt,
+  NotificationJobKind,
   NotificationJobResponse,
+  NotificationRunAllJobResult,
+  NotificationRunAllResponse,
   AttemptStatus,
 } from "./notification.types";
 import {
@@ -68,31 +79,40 @@ const RATE_LIMIT_EMAILS = 100;
 const PAYMENT_LOOKBACK_HOURS = 24;
 
 @Injectable()
-export class NotificationsService {
+export class NotificationsService implements OnModuleInit {
   private readonly logger = new Logger(NotificationsService.name);
 
-  /** Override addresses — comma-separated in env. Falls back to the
-   *  legacy defaults so a fresh deploy still has somewhere to send. */
-  private readonly adminEmails: string[];
-
   constructor(
     private readonly prisma: PrismaService,
     private readonly mail: MailService,
-    config: ConfigService,
-  ) {
-    const csv = config.get<string>("NOTIFICATION_ADMIN_EMAILS");
-    if (csv && csv.trim()) {
-      this.adminEmails = csv
-        .split(",")
-        .map((s) => s.trim())
-        .filter(Boolean);
-    } else {
-      this.adminEmails = ["rmancinas@freakma.net", "mpulido@freakma.net"];
-    }
+    private readonly log: NotificationLogService,
+    private readonly settings: SettingsService,
+    private readonly schedule: NotificationScheduleService,
+  ) {}
+
+  /** The automatic servicios sweep is the same "ejecutar todos" the button
+   *  fires. Off by default — see the defaults in `NotificationScheduleService`. */
+  async onModuleInit(): Promise<void> {
+    await this.schedule.register("servicios", () => this.scheduledRunAll());
+  }
+
+  /**
+   * Unattended run of all four jobs. Never debug, and never
+   * `ignoreDayRestriction`: an automatic run on the operator's own cadence is
+   * exactly the case the Mon/Wed/Fri gate was written for, so bypassing it
+   * here would mail the red list every single scheduled day.
+   */
+  async scheduledRunAll(): Promise<void> {
+    const result = await this.runAll({});
+    this.logger.log(
+      `Corrida programada de servicios: enviados ${result.sent}, ` +
+        `omitidos ${result.skipped}, fallidos ${result.failed}, ` +
+        `jobs con error ${result.errors}.`,
+    );
   }
 
   /* ============================================================================
-   *  Public jobs — called by the controller and by future cron sweeps alike.
+   *  Public jobs — called by the controller, the schedule, and tests alike.
    * ========================================================================== */
 
   /** Job 1 — Outstanding payments. */
@@ -649,6 +669,66 @@ export class NotificationsService {
     return response;
   }
 
+  /**
+   * "Ejecutar todos" — run all four jobs back to back with one set of flags.
+   *
+   * Sequential on purpose: the jobs share the SES transport and Job 3 can
+   * self-throttle via `useEmailLimit`, so firing them in parallel would both
+   * defeat that pause and interleave `email_notification_log` writes for no
+   * gain. A job that throws is captured and the sweep continues — one bad
+   * query must not swallow the other three envíos.
+   */
+  async runAll(flags: {
+    debug?: boolean;
+    ignoreDayRestriction?: boolean;
+    useEmailLimit?: boolean;
+  }): Promise<NotificationRunAllResponse> {
+    const debug = !!flags.debug;
+    const steps: {
+      kind: NotificationJobKind;
+      run: () => Promise<NotificationJobResponse>;
+    }[] = [
+      { kind: "outstanding", run: () => this.runOutstandingPayments(flags) },
+      { kind: "payment", run: () => this.runPaymentConfirmation(flags) },
+      { kind: "account", run: () => this.runAccountStatus(flags) },
+      { kind: "trust", run: () => this.runTrustConfirmation(flags) },
+    ];
+
+    const jobs: NotificationRunAllJobResult[] = [];
+    let sent = 0;
+    let skipped = 0;
+    let failed = 0;
+    let errors = 0;
+
+    for (const step of steps) {
+      try {
+        const result = await step.run();
+        sent += result.sent;
+        skipped += result.skipped;
+        failed += result.failed;
+        jobs.push({ kind: step.kind, ok: true, result });
+      } catch (e) {
+        errors++;
+        const message = e instanceof Error ? e.message : String(e);
+        this.logger.error(`run-all: job ${step.kind} failed — ${message}`);
+        jobs.push({ kind: step.kind, ok: false, error: message });
+      }
+    }
+
+    return {
+      request: "success",
+      notificationType: "runAllNotifications",
+      statusCode: 200,
+      debug,
+      sent,
+      skipped,
+      failed,
+      errors,
+      jobs,
+      type: "RUN_ALL",
+    };
+  }
+
   /* ============================================================================
    *  Log browser — list / drill-down for the UI.
    * ========================================================================== */
@@ -658,14 +738,16 @@ export class NotificationsService {
     page: number;
     pageSize: number;
     type?: EmailNotificationType;
-    servicio?: EmailNotificationServicio;
-    status?: EmailNotificationStatus;
+    /** Empty/omitted = every servicio. The /notificaciones tabs pass their
+     *  own slice (Servicios: CUSTOMERS+TRUST, Pólizas: POLICIES). */
+    servicio?: EmailNotificationServicio[];
+    status?: EmailNotificationStatus[];
     customerId?: string;
   }) {
     const where: Prisma.EmailNotificationLogWhereInput = {};
     if (params.type) where.notificationType = params.type;
-    if (params.servicio) where.servicio = params.servicio;
-    if (params.status) where.status = params.status;
+    if (params.servicio?.length) where.servicio = { in: params.servicio };
+    if (params.status?.length) where.status = { in: params.status };
     if (params.customerId) where.customerId = params.customerId;
 
     const [total, rows] = await this.prisma.$transaction([
@@ -702,22 +784,32 @@ export class NotificationsService {
     };
   }
 
-  /** Per-type + per-status counts for the dashboard header. */
-  async stats() {
+  /** Per-type + per-status counts for the dashboard header. Scoped by
+   *  servicio so each /notificaciones tab reports its own totals instead of
+   *  the whole platform's. */
+  async stats(servicio?: EmailNotificationServicio[]) {
+    const where: Prisma.EmailNotificationLogWhereInput = servicio?.length
+      ? { servicio: { in: servicio } }
+      : {};
+
     const [byType, byStatus, byServicio, lastRun] = await Promise.all([
       this.prisma.emailNotificationLog.groupBy({
         by: ["notificationType", "status"],
+        where,
         _count: { _all: true },
       }),
       this.prisma.emailNotificationLog.groupBy({
         by: ["status"],
+        where,
         _count: { _all: true },
       }),
       this.prisma.emailNotificationLog.groupBy({
         by: ["servicio", "status"],
+        where,
         _count: { _all: true },
       }),
       this.prisma.emailNotificationLog.findFirst({
+        where,
         orderBy: { sendDate: "desc" },
         select: { sendDate: true, notificationType: true },
       }),
@@ -739,10 +831,10 @@ export class NotificationsService {
    *  Internals — send / log / balance helpers.
    * ========================================================================== */
 
-  /** Where debug=1 sends everything. The PHP used
-   *  `rmancinas@freakma.net`; same here. */
+  /** Where debug=1 sends everything. Shared with the renewal sweep so both
+   *  halves of /notificaciones divert to the same inbox. */
   private debugEmail(): string {
-    return "rmancinas@freakma.net";
+    return DEBUG_RECIPIENT;
   }
 
   /** The customer's `minimumBalance`, or null if unset. The legacy TIPO
@@ -854,7 +946,9 @@ export class NotificationsService {
     }
   }
 
-  /** Persist one notification log row. */
+  /** Persist one notification log row. Thin pass-through to the shared
+   *  writer — the renewal sweep writes the same rows through the same
+   *  service, which is what keeps /notificaciones' log complete. */
   private async recordAttempt(args: {
     notificationType: EmailNotificationType;
     servicio: EmailNotificationServicio;
@@ -871,24 +965,7 @@ export class NotificationsService {
     providerResponse?: string;
     error?: string;
   }) {
-    await this.prisma.emailNotificationLog.create({
-      data: {
-        notificationType: args.notificationType,
-        servicio: args.servicio,
-        level: args.level ?? null,
-        customerId: args.customerId,
-        customerName: args.customerName,
-        customerEmail: args.customerEmail,
-        subject: args.subject,
-        bodySnapshot: args.bodySnapshot,
-        bodyRequestUrl: args.bodyRequestUrl ?? null,
-        debug: args.debug,
-        providerMessageId: args.providerMessageId ?? null,
-        providerResponse: args.providerResponse ?? null,
-        status: args.status as EmailNotificationStatus,
-        error: args.error ?? null,
-      },
-    });
+    await this.log.record(args);
   }
 
   /** Send the admin summary email after every job. The PHP sent one to
@@ -896,7 +973,11 @@ export class NotificationsService {
    *  response so it matches the legacy format verbatim. */
   private async adminSummary(subject: string, response: NotificationJobResponse) {
     const body = JSON.stringify(response);
-    for (const to of this.adminEmails) {
+    // Resolved per job, not cached at boot: the recipient list is edited in
+    // the UI while the app is running (SettingsService), and a cached copy
+    // would put us back to needing a restart for it to take effect.
+    const { value: adminEmails } = await this.settings.notificationAdminEmails();
+    for (const to of adminEmails) {
       try {
         const { messageId } = await this.mail.send({
           to,

apps/api/src/policies/policies.controller.ts

@@ -27,7 +27,6 @@ import {
   type PolicyStatus,
 } from "./policies.service";
 import { CreatePolicyDto, UpdatePolicyDto } from "./policy.dto";
-import { MarkRenewalNoticeDto } from "./renewal-notice.dto";
 import {
   BeneficiaryDto,
   ClaimDto,
@@ -146,26 +145,6 @@ export class PoliciesController {
     return p;
   }
 
-  @Post(":id/renewal-notices")
-  @RequireAbility("renewal:send")
-  async markRenewalNotice(
-    @Param("id") id: string,
-    @Body() dto: MarkRenewalNoticeDto,
-    @Req() req: Request,
-  ) {
-    const notice = await this.policies.markRenewalNotice(
-      id,
-      dto,
-      this.actingId(req),
-    );
-    void this.audit.log(this.actingId(req), "renewalNotice.markSent", {
-      policyId: id,
-      generation: dto.generation,
-      channel: dto.channel,
-    });
-    return notice;
-  }
-
   // --- children (all editing a policy => policy:update) ---------------------
 
   @Post(":id/installments")

apps/api/src/policies/policies.service.ts

@@ -6,7 +6,6 @@ import { StorageService } from "../storage/storage.service";
 import { extForUpload, type UploadedFileLike } from "../storage/upload-file";
 import { toDate } from "../common/coerce";
 import { CreatePolicyDto, UpdatePolicyDto } from "./policy.dto";
-import { MarkRenewalNoticeDto } from "./renewal-notice.dto";
 import {
   BeneficiaryDto,
   ClaimDto,
@@ -359,33 +358,6 @@ export class PoliciesService {
     return this.prisma.policy.update({ where: { id }, data: { archivedAt: null } });
   }
 
-  async markRenewalNotice(
-    policyId: string,
-    dto: MarkRenewalNoticeDto,
-    sentById: string,
-  ) {
-    await this.ensurePolicy(policyId);
-    const sentAt = toDate(dto.sentAt) ?? new Date();
-    return this.prisma.renewalNotice.upsert({
-      where: {
-        policyId_generation: { policyId, generation: dto.generation },
-      },
-      create: {
-        policyId,
-        generation: dto.generation,
-        channel: dto.channel,
-        sentAt,
-        sentById,
-        notes: dto.notes,
-      },
-      update: {
-        channel: dto.channel,
-        sentAt,
-        sentById,
-        notes: dto.notes,
-      },
-    });
-  }
 
   private async ensurePolicy(id: string) {
     const found = await this.prisma.policy.findUnique({

apps/api/src/policies/renewal-notice.dto.ts

@@ -1,28 +0,0 @@
-import { RenewalNoticeChannel } from "@jorgecuadros/database";
-import {
-  IsDateString,
-  IsEnum,
-  IsInt,
-  IsOptional,
-  IsString,
-  Max,
-  Min,
-} from "class-validator";
-
-export class MarkRenewalNoticeDto {
-  @IsInt()
-  @Min(1)
-  @Max(3)
-  generation!: number;
-
-  @IsEnum(RenewalNoticeChannel)
-  channel!: RenewalNoticeChannel;
-
-  @IsOptional()
-  @IsDateString()
-  sentAt?: string;
-
-  @IsOptional()
-  @IsString()
-  notes?: string;
-}

apps/api/src/renewals/renewals-log.spec.ts

@@ -0,0 +1,197 @@
+import { RenewalsService } from "./renewals.service";
+
+/**
+ * The renewal sweep's half of the unified notification log.
+ *
+ * `RenewalNotice` only records that a policy WAS notified — it has no way to
+ * say a send failed or that a customer had no address. Those rows exist only
+ * in `email_notification_log`, so they are what these tests pin down.
+ */
+
+const POLICY_ID = "policy-1";
+const CUSTOMER_ID = "cust-1";
+
+function makePolicy(email: string | null) {
+  return {
+    id: POLICY_ID,
+    policyNumber: "700442181",
+    policyTo: new Date("2026-09-01T00:00:00.000Z"),
+    netPremium: null,
+    policyFee: null,
+    total: null,
+    currency: "MXN",
+    coveragesJson: null,
+    customer: {
+      id: CUSTOMER_ID,
+      name: "ACME SA DE CV",
+      nameMissing: false,
+      email,
+      phone: null,
+      mobile: null,
+      addressLine1: null,
+      addressLine2: null,
+      city: null,
+      state: null,
+      zipCode: null,
+      country: null,
+    },
+    policyType: { name: "AUTO" },
+    insuranceProvider: { name: "GMX" },
+    vehicles: [],
+    renewalNotices: [],
+  };
+}
+
+function build(overrides: {
+  policies?: ReturnType<typeof makePolicy>[];
+  sendImpl?: () => Promise<{ messageId: string; response: string }>;
+}) {
+  const policies = overrides.policies ?? [makePolicy("cliente@example.com")];
+
+  const record = jest.fn().mockResolvedValue(undefined);
+  const send =
+    overrides.sendImpl ??
+    jest.fn().mockResolvedValue({ messageId: "ses-1", response: "{}" });
+
+  const prisma = {
+    // Only generation 1 has a candidate; the other two cadences return none,
+    // so a sweep produces exactly one outcome to assert on.
+    policy: {
+      findMany: jest
+        .fn()
+        .mockResolvedValueOnce(policies)
+        .mockResolvedValue([]),
+      findFirst: jest.fn().mockResolvedValue(policies[0]),
+    },
+    renewalNotice: { upsert: jest.fn().mockResolvedValue({}) },
+    scheduledJobState: {
+      upsert: jest.fn().mockResolvedValue({}),
+      updateMany: jest.fn().mockResolvedValue({ count: 1 }),
+      findUniqueOrThrow: jest.fn().mockResolvedValue({ lastSuccessfulAt: null }),
+      update: jest.fn().mockResolvedValue({}),
+    },
+  };
+
+  // `register` is a no-op here: these tests drive the sweep directly, so no
+  // cron job is ever installed.
+  const schedule = { register: jest.fn().mockResolvedValue(undefined) };
+  const service = new RenewalsService(
+    prisma as never,
+    { available: true, send } as never,
+    { log: jest.fn() } as never,
+    { record } as never,
+    schedule as never,
+  );
+
+  return { service, record, send, prisma };
+}
+
+describe("renewal notices write the shared notification log", () => {
+  it("records a SENT row tagged RENEWAL_NOTICE / POLICIES", async () => {
+    const { service, record, prisma } = build({});
+
+    await service.sweep("user-1");
+
+    expect(record).toHaveBeenCalledTimes(1);
+    const row = record.mock.calls[0][0];
+    expect(row).toMatchObject({
+      notificationType: "RENEWAL_NOTICE",
+      servicio: "POLICIES",
+      status: "SENT",
+      customerId: CUSTOMER_ID,
+      customerEmail: "cliente@example.com",
+      providerMessageId: "ses-1",
+      debug: false,
+    });
+    // `level` carries the aviso generation, not an alert colour.
+    expect(row.level).toBe(1);
+    expect(row.subject).toContain("700442181");
+    expect(row.bodySnapshot).toContain("ACME SA DE CV");
+    // The gating row is still written — the log does not replace it.
+    expect(prisma.renewalNotice.upsert).toHaveBeenCalledTimes(1);
+  });
+
+  it("records a FAILED row and no gating row when the send throws", async () => {
+    const { service, record, prisma } = build({
+      sendImpl: jest.fn().mockRejectedValue(new Error("SES rejected")),
+    });
+
+    const result = await service.sweep("user-1");
+
+    expect(result.sent).toBe(0);
+    expect(result.failed).toBe(1);
+    expect(record).toHaveBeenCalledTimes(1);
+    expect(record.mock.calls[0][0]).toMatchObject({
+      status: "FAILED",
+      error: "SES rejected",
+      notificationType: "RENEWAL_NOTICE",
+    });
+    // Nothing was delivered, so nothing may gate tomorrow's retry.
+    expect(prisma.renewalNotice.upsert).not.toHaveBeenCalled();
+  });
+
+  it("records SKIPPED_NO_EMAIL for a candidate with no address", async () => {
+    const { service, record, send, prisma } = build({
+      policies: [makePolicy("   ")],
+    });
+
+    const result = await service.sweep("user-1");
+
+    expect(result.skipped).toBe(1);
+    expect(send).not.toHaveBeenCalled();
+    expect(prisma.renewalNotice.upsert).not.toHaveBeenCalled();
+    expect(record.mock.calls[0][0]).toMatchObject({
+      status: "SKIPPED_NO_EMAIL",
+      customerEmail: "",
+    });
+  });
+
+  it("diverts a debug sweep and leaves the notice pending", async () => {
+    const { service, record, send, prisma } = build({});
+
+    const result = await service.sweep("user-1", { debug: true });
+
+    expect(result.sent).toBe(1);
+    expect(result.debug).toBe(true);
+    // The customer's own address is never contacted.
+    expect(jest.mocked(send).mock.calls[0][0]).toMatchObject({
+      to: "rmancinas@freakma.net",
+      xTracking: "debug",
+    });
+    expect(record.mock.calls[0][0]).toMatchObject({
+      status: "SENT",
+      customerEmail: "rmancinas@freakma.net",
+      debug: true,
+    });
+    // The letter is still owed, so nothing may gate it: no RenewalNotice row,
+    // and `lastSuccessfulAt` must not advance past the days we only tested.
+    expect(prisma.renewalNotice.upsert).not.toHaveBeenCalled();
+    const release = prisma.scheduledJobState.update.mock.calls.at(-1)?.[0];
+    expect(release.data.lastSuccessfulAt).toBeUndefined();
+  });
+
+  it("sends one notice on demand in debug without marking it sent", async () => {
+    const { service, send, prisma } = build({});
+
+    const result = await service.sendOne(POLICY_ID, 1, "user-1", {
+      debug: true,
+    });
+
+    expect(result.debug).toBe(true);
+    expect(result.to).toBe("rmancinas@freakma.net");
+    expect(send).toHaveBeenCalledTimes(1);
+    expect(prisma.renewalNotice.upsert).not.toHaveBeenCalled();
+  });
+
+  it("does not fail a delivered notice when the log write throws", async () => {
+    const { service, record } = build({});
+    record.mockRejectedValue(new Error("log table gone"));
+
+    const result = await service.sweep("user-1");
+
+    // The mail went out and the gating row was written; a lost audit row must
+    // not report that as a failure, which would re-send tomorrow.
+    expect(result.sent).toBe(1);
+    expect(result.failed).toBe(0);
+  });
+});

apps/api/src/renewals/renewals.controller.ts

@@ -1,17 +1,42 @@
 import {
+  Body,
   Controller,
   Get,
+  HttpCode,
   Post,
   Query,
   Req,
   UseGuards,
 } from "@nestjs/common";
 import { Request } from "express";
+import { Type } from "class-transformer";
+import { IsBoolean, IsInt, IsOptional, IsString, Max, Min } from "class-validator";
 import { AbilityGuard } from "../auth/ability.guard";
 import { AuthenticatedGuard } from "../auth/authenticated.guard";
 import { RequireAbility } from "../auth/require-ability.decorator";
 import { RenewalsService } from "./renewals.service";
 
+/** The pólizas half of the shared "Flags del envío" panel. Only `debug`
+ *  means anything here — the day gate and the send limit are estado-de-cuenta
+ *  concepts — so the other two are simply not accepted. */
+class RenewalFlagsDto {
+  @IsOptional()
+  @IsBoolean()
+  debug?: boolean;
+}
+
+class SendRenewalDto extends RenewalFlagsDto {
+  @IsString()
+  policyId!: string;
+
+  /** 1 = 30 días antes, 2 = 15 días antes, 3 = 7 días después. */
+  @Type(() => Number)
+  @IsInt()
+  @Min(1)
+  @Max(3)
+  generation!: number;
+}
+
 @UseGuards(AuthenticatedGuard, AbilityGuard)
 @Controller("renewals")
 export class RenewalsController {
@@ -26,7 +51,22 @@ export class RenewalsController {
 
   @Post("sweep")
   @RequireAbility("renewal:send")
-  sweep(@Req() req: Request) {
-    return this.renewals.sweep((req.user as { id: string }).id);
+  sweep(@Body() dto: RenewalFlagsDto, @Req() req: Request) {
+    return this.renewals.sweep((req.user as { id: string }).id, {
+      debug: dto?.debug,
+    });
+  }
+
+  /** Send a single pending notice from the /notificaciones list. */
+  @Post("send")
+  @RequireAbility("renewal:send")
+  @HttpCode(200)
+  send(@Body() dto: SendRenewalDto, @Req() req: Request) {
+    return this.renewals.sendOne(
+      dto.policyId,
+      dto.generation,
+      (req.user as { id: string }).id,
+      { debug: dto.debug },
+    );
   }
 }

apps/api/src/renewals/renewals.module.ts

@@ -1,8 +1,14 @@
 import { Module } from "@nestjs/common";
+import { NotificationLogModule } from "../notifications/notification-log.module";
+import { NotificationScheduleModule } from "../notifications/notification-schedule.module";
 import { RenewalsController } from "./renewals.controller";
 import { RenewalsService } from "./renewals.service";
 
 @Module({
+  // Renewal sends write to the same `email_notification_log` the four bulk
+  // jobs write, so /notificaciones has one send history across both tabs, and
+  // take their cadence from the same operator-editable schedule.
+  imports: [NotificationLogModule, NotificationScheduleModule],
   controllers: [RenewalsController],
   providers: [RenewalsService],
 })

apps/api/src/renewals/renewals.service.ts

@@ -1,14 +1,23 @@
 import {
+  BadRequestException,
   ConflictException,
   Injectable,
   Logger,
+  NotFoundException,
+  OnModuleInit,
   ServiceUnavailableException,
 } from "@nestjs/common";
-import { Cron } from "@nestjs/schedule";
 import { AuditService } from "../common/audit.service";
 import { MailService } from "../mail/mail.service";
+import { NotificationLogService } from "../notifications/notification-log.service";
+import {
+  NotificationScheduleService,
+  SCHEDULE_TIME_ZONE,
+} from "../notifications/notification-schedule.service";
+import { DEBUG_RECIPIENT } from "../notifications/notification.types";
 import { PrismaService } from "../prisma/prisma.service";
 import {
+  RenewalLetterPolicy,
   renewalLetterSelect,
   toRenewalLetterRow,
 } from "../reports/renewal-letter";
@@ -21,7 +30,9 @@ export const RENEWAL_CADENCE = [
 ] as const;
 
 const JOB_NAME = "renewal-email-sweep";
-const TIME_ZONE = "America/Tijuana";
+/** The window maths runs in office time; the cadence itself is owned by
+ *  `NotificationScheduleService`, which uses the same zone. */
+const TIME_ZONE = SCHEDULE_TIME_ZONE;
 const DAY_MS = 86400000;
 
 export function dateInTimeZone(now: Date, timeZone = TIME_ZONE): Date {
@@ -53,16 +64,27 @@ export function renewalWindow(
 }
 
 @Injectable()
-export class RenewalsService {
+export class RenewalsService implements OnModuleInit {
   private readonly logger = new Logger(RenewalsService.name);
 
   constructor(
     private readonly prisma: PrismaService,
     private readonly mail: MailService,
     private readonly audit: AuditService,
+    private readonly notificationLog: NotificationLogService,
+    private readonly schedule: NotificationScheduleService,
   ) {}
 
-  @Cron("0 6 * * *", { timeZone: TIME_ZONE })
+  /** The cadence used to be a `@Cron("0 6 * * *")` literal here; it is now
+   *  operator-editable, and the stored value defaults to that same 06:00
+   *  daily run. */
+  async onModuleInit(): Promise<void> {
+    await this.schedule.register("polizas", () => this.scheduledSweep());
+  }
+
+  /** The unattended run always sends for real: `debug` is a per-click switch
+   *  in the UI, never persisted, so the schedule cannot inherit a forgotten
+   *  test toggle and silently stop mailing customers. */
   async scheduledSweep(): Promise<void> {
     try {
       await this.sweep();
@@ -100,7 +122,8 @@ export class RenewalsService {
     );
   }
 
-  async sweep(userId?: string) {
+  async sweep(userId?: string, flags: { debug?: boolean } = {}) {
+    const debug = !!flags.debug;
     const now = new Date();
     const state = await this.acquireLock(now);
 
@@ -128,49 +151,20 @@ export class RenewalsService {
         for (const policy of policies) {
           const to = policy.customer.email?.trim();
           if (!to) {
+            // Logged rather than silently counted: "we had nobody to mail"
+            // is a finding the office acts on, and only the log survives the
+            // HTTP response.
+            await this.recordLog(policy, cadence.generation, "", {
+              status: "SKIPPED_NO_EMAIL",
+              debug,
+            });
             skipped++;
             continue;
           }
 
           try {
-            const letter = toRenewalLetterRow(policy, cadence.generation);
-            const message = renderRenewalEmail(letter);
-            const result = await this.mail.send({
-              to,
-              subject: message.subject,
-              html: message.html,
-              xTracking: "renewals",
-            });
-            const sentAt = new Date();
-
-            await this.prisma.renewalNotice.upsert({
-              where: {
-                policyId_generation: {
-                  policyId: policy.id,
-                  generation: cadence.generation,
-                },
-              },
-              create: {
-                policyId: policy.id,
-                generation: cadence.generation,
-                channel: "EMAIL",
-                sentAt,
-                sentById: userId,
-                providerMessageId: result.messageId,
-              },
-              update: {
-                channel: "EMAIL",
-                sentAt,
-                sentById: userId,
-                providerMessageId: result.messageId,
-              },
-            });
+            await this.deliver(policy, cadence.generation, to, userId, debug);
             sent++;
-            void this.audit.log(userId, "renewalNotice.send", {
-              policyId: policy.id,
-              generation: cadence.generation,
-              providerMessageId: result.messageId,
-            });
           } catch (error) {
             failures.push({
               policyId: policy.id,
@@ -181,8 +175,18 @@ export class RenewalsService {
         }
       }
 
-      const result = { eligible, sent, skipped, failed: failures.length, failures };
-      await this.releaseLock(failures.length === 0 ? now : null);
+      const result = {
+        eligible,
+        sent,
+        skipped,
+        failed: failures.length,
+        failures,
+        debug,
+      };
+      // A debug run must not advance `lastSuccessfulAt`: it wrote no
+      // RenewalNotice rows, so the days it "covered" are still owed, and
+      // narrowing tomorrow's window back to a single day would drop them.
+      await this.releaseLock(!debug && failures.length === 0 ? now : null);
       void this.audit.log(userId, "renewalNotice.sweep", result);
       return result;
     } catch (error) {
@@ -191,6 +195,198 @@ export class RenewalsService {
     }
   }
 
+  /**
+   * Send one pending renewal notice on demand, from the /notificaciones
+   * list. Same path the sweep takes — render, send, then record the notice —
+   * so a letter sent by hand is marked exactly like a swept one and drops
+   * off the pending list. Refuses a generation already sent so a double
+   * click can't mail the customer twice.
+   *
+   * Under `debug` the notice is NOT marked as sent, so the row stays in the
+   * pending list — the customer has still not been told anything.
+   */
+  async sendOne(
+    policyId: string,
+    generation: number,
+    userId?: string,
+    flags: { debug?: boolean } = {},
+  ) {
+    const debug = !!flags.debug;
+    if (!this.mail.available) {
+      throw new ServiceUnavailableException(
+        "El servicio de correo no está configurado.",
+      );
+    }
+
+    const policy = await this.prisma.policy.findFirst({
+      where: { id: policyId, archivedAt: null },
+      select: renewalLetterSelect(generation),
+    });
+    if (!policy) {
+      throw new NotFoundException("Póliza no encontrada.");
+    }
+    if (policy.renewalNotices.some((notice) => notice.sentAt)) {
+      throw new ConflictException("Este aviso ya fue enviado.");
+    }
+    const to = policy.customer.email?.trim();
+    if (!to) {
+      throw new BadRequestException("El cliente no tiene correo registrado.");
+    }
+
+    const { sentAt, providerMessageId, addressedTo } = await this.deliver(
+      policy,
+      generation,
+      to,
+      userId,
+      debug,
+    );
+    return {
+      policyId,
+      generation,
+      // The address the mail actually went to — under debug that is the
+      // override inbox, and the UI says so rather than claiming the customer
+      // was notified.
+      to: addressedTo,
+      debug,
+      sentAt: sentAt.toISOString(),
+      providerMessageId,
+    };
+  }
+
+  /** Render + send + record one notice. Shared by the sweep and `sendOne`.
+   *
+   *  Two records come out of a send: the `RenewalNotice` row, which gates the
+   *  pending list, and an `email_notification_log` row, which is the send
+   *  history the /notificaciones "Registro de envíos" reads. A failed send
+   *  writes only the second — there is no notice to gate on — and rethrows so
+   *  the sweep counts it as a failure.
+   *
+   *  Under `debug` the mail is diverted to `DEBUG_RECIPIENT` and the
+   *  `RenewalNotice` row is deliberately skipped: the customer was not
+   *  notified, so nothing may gate the letter they are still owed. Only the
+   *  log row is written, flagged `debug`. */
+  private async deliver(
+    policy: RenewalLetterPolicy,
+    generation: number,
+    to: string,
+    userId?: string,
+    debug = false,
+  ) {
+    const letter = toRenewalLetterRow(policy, generation);
+    const message = renderRenewalEmail(letter);
+    const addressedTo = debug ? DEBUG_RECIPIENT : to;
+
+    let result: Awaited<ReturnType<MailService["send"]>>;
+    try {
+      result = await this.mail.send({
+        to: addressedTo,
+        toName: letter.customerName,
+        subject: message.subject,
+        html: message.html,
+        xTracking: debug ? "debug" : "renewals",
+      });
+    } catch (error) {
+      const detail = error instanceof Error ? error.message : String(error);
+      await this.recordLog(policy, generation, addressedTo, {
+        status: "FAILED",
+        error: detail,
+        debug,
+      });
+      throw error;
+    }
+
+    const sentAt = new Date();
+
+    if (!debug) {
+      await this.prisma.renewalNotice.upsert({
+        where: {
+          policyId_generation: { policyId: policy.id, generation },
+        },
+        create: {
+          policyId: policy.id,
+          generation,
+          channel: "EMAIL",
+          sentAt,
+          sentById: userId,
+          providerMessageId: result.messageId,
+        },
+        update: {
+          channel: "EMAIL",
+          sentAt,
+          sentById: userId,
+          providerMessageId: result.messageId,
+        },
+      });
+    }
+    await this.recordLog(policy, generation, addressedTo, {
+      status: "SENT",
+      providerMessageId: result.messageId || undefined,
+      providerResponse: result.response || undefined,
+      sendDate: sentAt,
+      debug,
+    });
+    void this.audit.log(userId, "renewalNotice.send", {
+      policyId: policy.id,
+      generation,
+      debug,
+      providerMessageId: result.messageId,
+    });
+    return { sentAt, providerMessageId: result.messageId, addressedTo };
+  }
+
+  /**
+   * Write one row to the shared notification log.
+   *
+   * Never throws: the mail is already gone (or already failed) by the time we
+   * get here, and losing the audit row must not turn a delivered notice into
+   * a reported failure — which on the SENT path would also strand the
+   * `RenewalNotice` we just wrote and re-send tomorrow.
+   */
+  private async recordLog(
+    policy: RenewalLetterPolicy,
+    generation: number,
+    /** Recipient as addressed. Empty on the SKIPPED_NO_EMAIL path — that
+     *  emptiness IS the reason the row exists. */
+    to: string,
+    outcome: {
+      status: "SENT" | "FAILED" | "SKIPPED_NO_EMAIL";
+      providerMessageId?: string;
+      providerResponse?: string;
+      error?: string;
+      sendDate?: Date;
+      debug?: boolean;
+    },
+  ): Promise<void> {
+    const letter = toRenewalLetterRow(policy, generation);
+    const message = renderRenewalEmail(letter);
+    try {
+      await this.notificationLog.record({
+        notificationType: "RENEWAL_NOTICE",
+        servicio: "POLICIES",
+        sendDate: outcome.sendDate,
+        // `level` carries the aviso generation for RENEWAL_NOTICE rows — see
+        // the column doc on the Prisma model.
+        level: generation,
+        customerId: policy.customer.id,
+        customerName: letter.customerName,
+        customerEmail: to,
+        subject: message.subject,
+        bodySnapshot: message.html,
+        status: outcome.status,
+        debug: !!outcome.debug,
+        providerMessageId: outcome.providerMessageId,
+        providerResponse: outcome.providerResponse,
+        error: outcome.error,
+      });
+    } catch (error) {
+      this.logger.warn(
+        `No se pudo registrar el aviso de renovación en el log ` +
+          `(póliza ${policy.id}, aviso ${generation}): ` +
+          `${(error as Error).message}`,
+      );
+    }
+  }
+
   private findCandidates(
     cadence: (typeof RENEWAL_CADENCE)[number],
     today: Date,

apps/api/src/reports/renewal-letter.ts

@@ -12,6 +12,8 @@ export function renewalLetterSelect(generation: number) {
     coveragesJson: true,
     customer: {
       select: {
+        // Needed by the notification log's customerId FK, not by the letter.
+        id: true,
         name: true,
         nameMissing: true,
         email: true,

apps/api/src/settings/settings.module.ts

@@ -0,0 +1,14 @@
+import { Module } from "@nestjs/common";
+import { SettingsService } from "./settings.service";
+
+/**
+ * Operator-editable configuration. No controller of its own — each setting is
+ * exposed by the feature that owns it (summary recipients live under
+ * /notifications), so the validation and the permission live next to the
+ * thing they protect rather than behind a generic key/value endpoint.
+ */
+@Module({
+  providers: [SettingsService],
+  exports: [SettingsService],
+})
+export class SettingsModule {}

apps/api/src/settings/settings.service.spec.ts

@@ -0,0 +1,89 @@
+import { SettingsService, invalidEmails, parseEmailList } from "./settings.service";
+
+/**
+ * The db → env → default ladder is the whole contract of this service: it is
+ * what lets the setting move out of the environment without changing how any
+ * existing deployment behaves.
+ */
+
+function build(row: { value: string } | null, env?: string) {
+  const prisma = {
+    appSetting: {
+      findUnique: jest.fn().mockResolvedValue(
+        row ? { key: "k", updatedAt: new Date("2026-08-02"), updatedById: "u1", ...row } : null,
+      ),
+      upsert: jest.fn().mockResolvedValue({}),
+    },
+  };
+  const config = { get: jest.fn().mockReturnValue(env) };
+  return {
+    service: new SettingsService(prisma as never, config as never),
+    prisma,
+  };
+}
+
+describe("notification admin emails resolve db > env > default", () => {
+  it("prefers the stored row", async () => {
+    const { service } = build({ value: "a@x.com,b@x.com" }, "env@x.com");
+
+    await expect(service.notificationAdminEmails()).resolves.toMatchObject({
+      value: ["a@x.com", "b@x.com"],
+      source: "db",
+      updatedById: "u1",
+    });
+  });
+
+  it("falls back to the environment when nothing is stored", async () => {
+    const { service } = build(null, "env@x.com, other@x.com");
+
+    await expect(service.notificationAdminEmails()).resolves.toMatchObject({
+      value: ["env@x.com", "other@x.com"],
+      source: "env",
+    });
+  });
+
+  it("falls back to the built-in defaults when neither is set", async () => {
+    const { service } = build(null, undefined);
+
+    const resolved = await service.notificationAdminEmails();
+    expect(resolved.source).toBe("default");
+    expect(resolved.value).toHaveLength(2);
+  });
+
+  it("treats a stored empty list as 'nobody', not as unset", async () => {
+    // The regression this guards: falling through to env/defaults here would
+    // keep mailing people who were deliberately removed.
+    const { service } = build({ value: "" }, "env@x.com");
+
+    await expect(service.notificationAdminEmails()).resolves.toMatchObject({
+      value: [],
+      source: "db",
+    });
+  });
+
+  it("writes the list back as CSV", async () => {
+    const { service, prisma } = build({ value: "" });
+
+    await service.setNotificationAdminEmails(["a@x.com", "b@x.com"], "user-9");
+
+    expect(prisma.appSetting.upsert).toHaveBeenCalledWith(
+      expect.objectContaining({
+        create: expect.objectContaining({ value: "a@x.com,b@x.com", updatedById: "user-9" }),
+        update: expect.objectContaining({ value: "a@x.com,b@x.com", updatedById: "user-9" }),
+      }),
+    );
+  });
+});
+
+describe("email list parsing", () => {
+  it("trims and drops blanks", () => {
+    expect(parseEmailList(" a@x.com , ,b@x.com ")).toEqual(["a@x.com", "b@x.com"]);
+  });
+
+  it("rejects entries that are not addresses at all", () => {
+    expect(invalidEmails(["ok@x.com", "nope", "also@bad"])).toEqual([
+      "nope",
+      "also@bad",
+    ]);
+  });
+});

apps/api/src/settings/settings.service.ts

@@ -0,0 +1,183 @@
+import { Injectable, Logger } from "@nestjs/common";
+import { ConfigService } from "@nestjs/config";
+import { PrismaService } from "../prisma/prisma.service";
+
+/**
+ * Reader/writer for `app_settings` — the configuration staff can change
+ * without a redeploy.
+ *
+ * Every setting resolves through the same three-step ladder: the database row
+ * if an operator has set one, else the environment variable it used to live
+ * in, else a hardcoded default. That ordering is what makes this migration
+ * safe — an existing deployment keeps behaving exactly as it did until
+ * somebody edits the value in the UI, and `source` tells the UI which of the
+ * three it is looking at so "this came from the env, editing it here will
+ * take over" is visible rather than surprising.
+ */
+
+export const SETTING_KEYS = {
+  /** Comma-separated recipients of the per-job notification summary. */
+  notificationAdminEmails: "notification.adminEmails",
+  /** JSON cadence of the automatic servicios sweep. */
+  scheduleServicios: "notification.schedule.servicios",
+  /** JSON cadence of the automatic pólizas renewal sweep. */
+  schedulePolizas: "notification.schedule.polizas",
+} as const;
+
+/** Where a resolved value came from. Shown in the UI. */
+export type SettingSource = "db" | "env" | "default";
+
+export interface ResolvedSetting<T> {
+  value: T;
+  source: SettingSource;
+  updatedAt: Date | null;
+  updatedById: string | null;
+}
+
+/** Last resort when neither the database nor the environment says otherwise.
+ *  Matches what `NotificationsService` hardcoded before this table existed. */
+const DEFAULT_ADMIN_EMAILS = ["rmancinas@freakma.net", "mpulido@freakma.net"];
+
+/** Deliberately permissive — this rejects "not an address at all", not
+ *  "not deliverable". Only SES can tell us the latter, and a validator strict
+ *  enough to argue with is a validator that blocks a legitimate address. */
+const EMAIL_RE = /^[^\s@,]+@[^\s@,]+\.[^\s@,]+$/;
+
+export function parseEmailList(raw: string): string[] {
+  return raw
+    .split(",")
+    .map((s) => s.trim())
+    .filter(Boolean);
+}
+
+export function invalidEmails(list: string[]): string[] {
+  return list.filter((e) => !EMAIL_RE.test(e));
+}
+
+@Injectable()
+export class SettingsService {
+  private readonly logger = new Logger(SettingsService.name);
+
+  constructor(
+    private readonly prisma: PrismaService,
+    private readonly config: ConfigService,
+  ) {}
+
+  /**
+   * Recipients of the per-job summary email.
+   *
+   * Read on every send rather than cached at boot: the point of moving this
+   * out of the environment was that it changes while the app is running, and
+   * a cache would reintroduce exactly the restart-to-apply behaviour we are
+   * removing. It is one indexed primary-key lookup per sweep, not per email.
+   */
+  async notificationAdminEmails(): Promise<ResolvedSetting<string[]>> {
+    const row = await this.read(SETTING_KEYS.notificationAdminEmails);
+    if (row) {
+      const parsed = parseEmailList(row.value);
+      // An empty stored value is a legitimate choice — "send no summaries" —
+      // and must not silently fall through to the env or the defaults, or an
+      // operator who cleared the field would keep receiving mail.
+      return {
+        value: parsed,
+        source: "db",
+        updatedAt: row.updatedAt,
+        updatedById: row.updatedById,
+      };
+    }
+
+    const env = this.config.get<string>("NOTIFICATION_ADMIN_EMAILS");
+    if (env && env.trim()) {
+      return {
+        value: parseEmailList(env),
+        source: "env",
+        updatedAt: null,
+        updatedById: null,
+      };
+    }
+
+    return {
+      value: [...DEFAULT_ADMIN_EMAILS],
+      source: "default",
+      updatedAt: null,
+      updatedById: null,
+    };
+  }
+
+  /** Persist the summary recipients. An empty list is stored as an empty
+   *  string and means "nobody" — see the read path above. */
+  async setNotificationAdminEmails(
+    emails: string[],
+    userId: string,
+  ): Promise<ResolvedSetting<string[]>> {
+    await this.write(
+      SETTING_KEYS.notificationAdminEmails,
+      emails.join(","),
+      userId,
+    );
+    return this.notificationAdminEmails();
+  }
+
+  /**
+   * Cadence of one automatic envío, stored as JSON.
+   *
+   * No env rung on this ladder: a schedule was never an environment variable
+   * (it was a `@Cron` literal in the source), so the only two sources are the
+   * operator's row and the caller's default — which is the previous hardcoded
+   * behaviour. A row that fails to parse is treated as absent and logged
+   * rather than thrown: a bad JSON blob must not take the scheduler down with
+   * it, and falling back to the shipped cadence is the safe reading.
+   */
+  async notificationSchedule<T>(
+    kind: "servicios" | "polizas",
+    fallback: T,
+  ): Promise<ResolvedSetting<T>> {
+    const key =
+      kind === "servicios"
+        ? SETTING_KEYS.scheduleServicios
+        : SETTING_KEYS.schedulePolizas;
+    const row = await this.read(key);
+    if (row) {
+      try {
+        return {
+          value: { ...fallback, ...(JSON.parse(row.value) as T) },
+          source: "db",
+          updatedAt: row.updatedAt,
+          updatedById: row.updatedById,
+        };
+      } catch (error) {
+        this.logger.warn(
+          `Setting ${key} is not valid JSON, using the default: ` +
+            `${(error as Error).message}`,
+        );
+      }
+    }
+    return { value: fallback, source: "default", updatedAt: null, updatedById: null };
+  }
+
+  async setNotificationSchedule(
+    kind: "servicios" | "polizas",
+    schedule: unknown,
+    userId: string,
+  ): Promise<void> {
+    await this.write(
+      kind === "servicios"
+        ? SETTING_KEYS.scheduleServicios
+        : SETTING_KEYS.schedulePolizas,
+      JSON.stringify(schedule),
+      userId,
+    );
+  }
+
+  private read(key: string) {
+    return this.prisma.appSetting.findUnique({ where: { key } });
+  }
+
+  private async write(key: string, value: string, userId: string) {
+    await this.prisma.appSetting.upsert({
+      where: { key },
+      create: { key, value, updatedById: userId },
+      update: { value, updatedById: userId },
+    });
+  }
+}

apps/web/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jorgecuadros/web",
-  "version": "1.0.6",
+  "version": "1.0.8",
   "private": true,
   "scripts": {
     "dev": "next dev -p 4500",

apps/web/src/app/globals.css

@@ -212,6 +212,11 @@ button {
   color: var(--muted);
 }
 
+/* Secondary line inside a row or card — used alongside .muted throughout. */
+.small {
+  font-size: 0.8125rem;
+}
+
 /* ============================================================================
    App shell / top nav
    ========================================================================== */

apps/web/src/app/notificaciones/page.tsx

@@ -1,444 +1,12 @@
 "use client";
 
-import { useCallback, useEffect, useState } from "react";
 import { AppShell } from "@/components/AppShell";
-import { useCan } from "@/lib/abilities";
-import { formatDateTime } from "@/lib/labels";
-import {
-  NOTIFICATION_STATUS_COLORS,
-  NOTIFICATION_STATUS_LABELS,
-  NOTIFICATION_SERVICIO_LABELS,
-  NOTIFICATION_TYPE_LABELS,
-} from "@/lib/labels";
-import {
-  getNotificationStats,
-  listNotificationLog,
-  runAccountStatus,
-  runOutstandingPayments,
-  runPaymentConfirmation,
-  runTrustConfirmation,
-} from "@/lib/api";
-import type {
-  NotificationFlags,
-  NotificationJobResponse,
-  NotificationLogPage,
-  NotificationStats,
-  NotificationStatus,
-} from "@/lib/api";
-
-/**
- * Mass email notifications UI. Manual triggers for the four jobs plus a
- * paged log browser. The page is gated on `notification:send`; a STAFF
- * viewer sees the read-only log table but not the trigger buttons.
- */
+import { Notificaciones } from "@/components/Notificaciones";
 
 export default function NotificacionesPage() {
   return (
     <AppShell>
-      <Notificaciones />
+      <Notificaciones initialTab="servicios" />
     </AppShell>
   );
 }
-
-type JobKind = "outstanding" | "payment" | "account" | "trust";
-
-interface JobDef {
-  kind: JobKind;
-  title: string;
-  endpoint: string;
-  description: string;
-  servicio: "Clientes" | "Fideicomiso";
-  flagsHint?: string;
-}
-
-const JOBS: JobDef[] = [
-  {
-    kind: "outstanding",
-    title: "Pagos pendientes",
-    endpoint: "sendOutstandingPaymentAlerts",
-    servicio: "Clientes",
-    description:
-      "Clientes con al menos un movimiento marcado como pendiente (outstanding). Equivale a la columna NOPAGO=1 del antiguo datosfreak.",
-  },
-  {
-    kind: "payment",
-    title: "Confirmación de pago",
-    endpoint: "sendPaymentConfirmation",
-    servicio: "Clientes",
-    description:
-      "Clientes con un crédito (abono) en las últimas 24 horas. Un correo por cliente con el pago más reciente.",
-  },
-  {
-    kind: "account",
-    title: "Estado de cuenta",
-    endpoint: "sendAccountStatus",
-    servicio: "Clientes",
-    description:
-      "Alerta amarilla (DEBAJO DEL TIPO) los miércoles y roja (EN ROJO) lunes/miércoles/viernes. El flag ignoreDayRestriction salta los gates.",
-    flagsHint: "Solo este job respeta ignoreDayRestriction y useEmailLimit.",
-  },
-  {
-    kind: "trust",
-    title: "Confirmación fideicomiso",
-    endpoint: "sendConfirmTrustPayment",
-    servicio: "Fideicomiso",
-    description:
-      "Clientes con TrustAccount que recibieron un crédito en el dominio TRUST en las últimas 24 horas.",
-  },
-];
-
-function Notificaciones() {
-  const allowed = useCan("notification:send");
-
-  const [flags, setFlags] = useState<NotificationFlags>({ debug: true });
-  const [stats, setStats] = useState<NotificationStats | null>(null);
-  const [log, setLog] = useState<NotificationLogPage | null>(null);
-  const [logFilter, setLogFilter] = useState<{
-    status?: NotificationStatus;
-    view: "all" | "sent" | "failed" | "skipped";
-  }>({ view: "all" });
-  const [logPage, setLogPage] = useState(1);
-  const [busy, setBusy] = useState<JobKind | null>(null);
-  const [lastResult, setLastResult] = useState<NotificationJobResponse | null>(null);
-  const [error, setError] = useState<string | null>(null);
-
-  const refresh = useCallback(async () => {
-    try {
-      const [s, l] = await Promise.all([
-        getNotificationStats(),
-        listNotificationLog({
-          page: logPage,
-          pageSize: 50,
-          status: logFilter.status,
-          view: logFilter.view === "all" ? undefined : logFilter.view,
-        }),
-      ]);
-      setStats(s);
-      setLog(l);
-      setError(null);
-    } catch (e) {
-      setError(e instanceof Error ? e.message : String(e));
-    }
-  }, [logPage, logFilter]);
-
-  useEffect(() => {
-    void refresh();
-  }, [refresh]);
-
-  const run = useCallback(
-    async (job: JobDef) => {
-      if (!allowed) return;
-      setBusy(job.kind);
-      setError(null);
-      try {
-        let res: NotificationJobResponse;
-        if (job.kind === "outstanding") res = await runOutstandingPayments(flags);
-        else if (job.kind === "payment") res = await runPaymentConfirmation(flags);
-        else if (job.kind === "account") res = await runAccountStatus(flags);
-        else res = await runTrustConfirmation(flags);
-        setLastResult(res);
-        await refresh();
-      } catch (e) {
-        setError(e instanceof Error ? e.message : String(e));
-      } finally {
-        setBusy(null);
-      }
-    },
-    [allowed, flags, refresh],
-  );
-
-  return (
-    <div style={{ display: "grid", gap: 24, padding: 24 }}>
-      <header>
-        <h1 style={{ margin: 0 }}>Notificaciones masivas</h1>
-        <p style={{ color: "#666", marginTop: 4 }}>
-          Disparo manual de los cuatro envíos equivalentes a los scripts PHP
-          de <code>email.notifications/</code>. Cada ejecución registra todas
-          las filas (enviado, fallido, omitido) en <code>email_notification_log</code>.
-        </p>
-      </header>
-
-      <section
-        style={{
-          background: "#fff",
-          border: "1px solid #ddd",
-          borderRadius: 8,
-          padding: 16,
-          display: "grid",
-          gap: 12,
-        }}
-      >
-        <strong>Flags del envío</strong>
-        <label style={{ display: "flex", gap: 8, alignItems: "center" }}>
-          <input
-            type="checkbox"
-            checked={!!flags.debug}
-            disabled={!allowed}
-            onChange={(e) => setFlags((f) => ({ ...f, debug: e.target.checked }))}
-          />
-          <span>
-            <strong>debug</strong> — reescribe todos los destinatarios a{" "}
-            <code>rmancinas@freakma.net</code>. Ningún cliente real recibe el
-            correo mientras esté activo.
-          </span>
-        </label>
-        <label style={{ display: "flex", gap: 8, alignItems: "center" }}>
-          <input
-            type="checkbox"
-            checked={!!flags.ignoreDayRestriction}
-            disabled={!allowed}
-            onChange={(e) =>
-              setFlags((f) => ({ ...f, ignoreDayRestriction: e.target.checked }))
-            }
-          />
-          <span>
-            <strong>ignoreDayRestriction</strong> — salta los gates de
-            Mon/Wed/Fri del estado de cuenta (job 3). Útil para disparar en
-            cualquier día sin esperar a la próxima corrida.
-          </span>
-        </label>
-        <label style={{ display: "flex", gap: 8, alignItems: "center" }}>
-          <input
-            type="checkbox"
-            checked={!!flags.useEmailLimit}
-            disabled={!allowed}
-            onChange={(e) =>
-              setFlags((f) => ({ ...f, useEmailLimit: e.target.checked }))
-            }
-          />
-          <span>
-            <strong>useEmailLimit</strong> — pausa el job 3 cada 100 correos
-            durante 1 hora. Vestigio de la era SMTP; SES no lo necesita.
-          </span>
-        </label>
-      </section>
-
-      <section
-        style={{
-          display: "grid",
-          gridTemplateColumns: "repeat(auto-fit, minmax(280px, 1fr))",
-          gap: 12,
-        }}
-      >
-        {JOBS.map((j) => (
-          <article
-            key={j.kind}
-            style={{
-              background: "#fff",
-              border: "1px solid #ddd",
-              borderRadius: 8,
-              padding: 16,
-              display: "grid",
-              gap: 8,
-            }}
-          >
-            <header style={{ display: "flex", justifyContent: "space-between" }}>
-              <strong>{j.title}</strong>
-              <span style={{ fontSize: 12, color: "#666" }}>{j.servicio}</span>
-            </header>
-            <p style={{ margin: 0, color: "#444", fontSize: 13 }}>{j.description}</p>
-            {j.flagsHint && (
-              <p style={{ margin: 0, color: "#666", fontSize: 12, fontStyle: "italic" }}>
-                {j.flagsHint}
-              </p>
-            )}
-            <button
-              type="button"
-              disabled={!allowed || busy !== null}
-              onClick={() => void run(j)}
-              style={{
-                padding: "8px 12px",
-                background: !allowed || busy !== null ? "#bbb" : "#1f4eaf",
-                color: "#fff",
-                border: "none",
-                borderRadius: 6,
-                cursor: !allowed || busy !== null ? "not-allowed" : "pointer",
-                fontWeight: 600,
-              }}
-            >
-              {busy === j.kind ? "Ejecutando…" : "Ejecutar"}
-            </button>
-          </article>
-        ))}
-      </section>
-
-      {!allowed && (
-        <div
-          style={{
-            background: "#fff8e1",
-            border: "1px solid #f1c40f",
-            borderRadius: 8,
-            padding: 12,
-          }}
-        >
-          Tu rol no incluye <code>notification:send</code>. Solo puedes ver el
-          registro. Para disparar envíos pide a un MANAGER/ADMIN.
-        </div>
-      )}
-
-      {stats && (
-        <section
-          style={{
-            background: "#fff",
-            border: "1px solid #ddd",
-            borderRadius: 8,
-            padding: 16,
-          }}
-        >
-          <strong>Estado del transporte</strong>
-          <ul style={{ marginTop: 8, marginBottom: 0 }}>
-            <li>
-              SES configurado:{" "}
-              <strong style={{ color: stats.transport.available ? "#1f7a3a" : "#b3261e" }}>
-                {stats.transport.available ? "sí" : "no"}
-              </strong>
-              {stats.transport.devFallback && " (fallback dev: stdout)"}
-            </li>
-            <li>Último envío registrado: {stats.lastRun ? `${NOTIFICATION_TYPE_LABELS[stats.lastRun.notificationType]} — ${formatDateTime(stats.lastRun.sendDate)}` : "—"}</li>
-            <li>
-              Totales:{" "}
-              {stats.byStatus.map((s) => (
-                <span key={s.status} style={{ marginRight: 12 }}>
-                  {NOTIFICATION_STATUS_LABELS[s.status]}: {s._count._all}
-                </span>
-              ))}
-            </li>
-          </ul>
-        </section>
-      )}
-
-      {lastResult && (
-        <section
-          style={{
-            background: "#eef6ff",
-            border: "1px solid #b3d4fc",
-            borderRadius: 8,
-            padding: 12,
-          }}
-        >
-          <strong>Última respuesta</strong>
-          <pre style={{ margin: 0, fontSize: 12, overflow: "auto" }}>
-            {JSON.stringify(lastResult, null, 2)}
-          </pre>
-        </section>
-      )}
-
-      {error && (
-        <div
-          style={{
-            background: "#fdecea",
-            border: "1px solid #b3261e",
-            borderRadius: 8,
-            padding: 12,
-            color: "#b3261e",
-          }}
-        >
-          {error}
-        </div>
-      )}
-
-      <section
-        style={{
-          background: "#fff",
-          border: "1px solid #ddd",
-          borderRadius: 8,
-          padding: 16,
-        }}
-      >
-        <div style={{ display: "flex", justifyContent: "space-between", alignItems: "center" }}>
-          <strong>Registro de envíos</strong>
-          <div style={{ display: "flex", gap: 8 }}>
-            {(["all", "sent", "failed", "skipped"] as const).map((v) => (
-              <button
-                key={v}
-                type="button"
-                onClick={() => {
-                  setLogFilter({ view: v });
-                  setLogPage(1);
-                }}
-                style={{
-                  padding: "4px 10px",
-                  background: logFilter.view === v ? "#1f4eaf" : "#eee",
-                  color: logFilter.view === v ? "#fff" : "#333",
-                  border: "none",
-                  borderRadius: 4,
-                  cursor: "pointer",
-                  fontSize: 12,
-                }}
-              >
-                {v === "all" ? "Todos" : v === "sent" ? "Enviados" : v === "failed" ? "Fallidos" : "Omitidos"}
-              </button>
-            ))}
-          </div>
-        </div>
-
-        <table style={{ width: "100%", borderCollapse: "collapse", marginTop: 12 }}>
-          <thead>
-            <tr style={{ borderBottom: "2px solid #ddd" }}>
-              <th style={{ textAlign: "left", padding: 6 }}>Fecha</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Tipo</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Servicio</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Cliente</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Email</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Estado</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Asunto</th>
-              <th style={{ textAlign: "left", padding: 6 }}>Provider</th>
-            </tr>
-          </thead>
-          <tbody>
-            {log?.items.map((row) => (
-              <tr key={row.id} style={{ borderBottom: "1px solid #eee" }}>
-                <td style={{ padding: 6, fontSize: 12 }}>{formatDateTime(row.sendDate)}</td>
-                <td style={{ padding: 6, fontSize: 12 }}>
-                  {NOTIFICATION_TYPE_LABELS[row.notificationType]}
-                  {row.level !== null && (row.level === 0 ? " (amarilla)" : " (roja)")}
-                </td>
-                <td style={{ padding: 6, fontSize: 12 }}>{NOTIFICATION_SERVICIO_LABELS[row.servicio]}</td>
-                <td style={{ padding: 6, fontSize: 12 }}>{row.customerName}{row.debug ? " · debug" : ""}</td>
-                <td style={{ padding: 6, fontSize: 12 }}>{row.customerEmail}</td>
-                <td style={{ padding: 6, fontSize: 12, color: NOTIFICATION_STATUS_COLORS[row.status] }}>
-                  {NOTIFICATION_STATUS_LABELS[row.status]}
-                </td>
-                <td style={{ padding: 6, fontSize: 12 }}>{row.subject}</td>
-                <td style={{ padding: 6, fontSize: 11, color: "#666" }}>
-                  {row.providerMessageId ?? row.error ?? "—"}
-                </td>
-              </tr>
-            ))}
-            {log && log.items.length === 0 && (
-              <tr>
-                <td colSpan={8} style={{ padding: 12, color: "#666", textAlign: "center" }}>
-                  Sin envíos con el filtro actual.
-                </td>
-              </tr>
-            )}
-          </tbody>
-        </table>
-
-        {log && log.pageCount > 1 && (
-          <div style={{ marginTop: 8, display: "flex", justifyContent: "space-between", alignItems: "center" }}>
-            <span style={{ fontSize: 12, color: "#666" }}>
-              {log.total} fila{log.total === 1 ? "" : "s"} · página {log.page} de {log.pageCount}
-            </span>
-            <div style={{ display: "flex", gap: 4 }}>
-              <button
-                type="button"
-                disabled={log.page <= 1}
-                onClick={() => setLogPage((p) => Math.max(1, p - 1))}
-              >
-                ←
-              </button>
-              <button
-                type="button"
-                disabled={log.page >= log.pageCount}
-                onClick={() => setLogPage((p) => Math.min(log.pageCount, p + 1))}
-              >
-                →
-              </button>
-            </div>
-          </div>
-        )}
-      </section>
-    </div>
-  );
-}

apps/web/src/app/renovaciones/page.tsx

@@ -1,266 +1,14 @@
 "use client";
 
-import { useCallback, useEffect, useState } from "react";
 import { AppShell } from "@/components/AppShell";
-import { useCan } from "@/lib/abilities";
-import { formatDate, formatMoney } from "@/lib/labels";
-import { apiFetch } from "@/lib/api";
-
-export interface RenewalLetter {
-  policyId: string;
-  policyNumber: string;
-  policyType: string;
-  customerName: string;
-  customerEmail: string | null;
-  provider: string;
-  policyTo: string;
-  netPremium: string | null;
-  total: string | null;
-  currency: string;
-  generation: number;
-  sentAt: string | null;
-}
-
-export interface RenewalSweepResult {
-  eligible: number;
-  sent: number;
-  skipped: number;
-  failed: number;
-  failures: { policyId: string; generation: number; error: string }[];
-}
-
-export interface RenewalMarkInput {
-  generation: number;
-  channel: "MAIL" | "EMAIL";
-  sentAt?: string;
-  notes?: string;
-}
+import { Notificaciones } from "@/components/Notificaciones";
 
+/** Renewal notices moved into /notificaciones as its "Pólizas" tab. This route
+ *  stays so old bookmarks and links land on that tab instead of a 404. */
 export default function RenovacionesPage() {
   return (
     <AppShell>
-      <Renovaciones />
+      <Notificaciones initialTab="polizas" />
     </AppShell>
   );
 }
-
-const GENERATION_LABEL: Record<number, string> = {
-  1: "Primer aviso (30 días antes)",
-  2: "Segundo aviso (15 días antes)",
-  3: "Tercer aviso (7 días después)",
-};
-
-const CHANNEL_LABEL: Record<"MAIL" | "EMAIL", string> = {
-  MAIL: "Impreso",
-  EMAIL: "Correo electrónico",
-};
-
-function Renovaciones() {
-  const allowed = useCan("renewal:send");
-  const [days, setDays] = useState(30);
-  const [pending, setPending] = useState<RenewalLetter[] | null>(null);
-  const [pendingError, setPendingError] = useState<string | null>(null);
-  const [actionError, setActionError] = useState<string | null>(null);
-  const [notice, setNotice] = useState<string | null>(null);
-  const [sweeping, setSweeping] = useState(false);
-
-  const refresh = useCallback(async () => {
-    setPendingError(null);
-    try {
-      const data = await apiFetch<RenewalLetter[]>(
-        `/renewals/pending?days=${days}`,
-      );
-      setPending(data);
-    } catch (e) {
-      setPendingError(
-        (e as Error)?.message ?? "No se pudo cargar la lista de avisos.",
-      );
-      setPending([]);
-    }
-  }, [days]);
-
-  useEffect(() => {
-    if (allowed) refresh();
-  }, [allowed, refresh]);
-
-  async function handleSweep() {
-    setActionError(null);
-    setNotice(null);
-    setSweeping(true);
-    try {
-      const result = await apiFetch<RenewalSweepResult>("/renewals/sweep", {
-        method: "POST",
-      });
-      setNotice(
-        `Enviados ${result.sent} avisos (${result.failed} con error).`,
-      );
-      await refresh();
-    } catch (e) {
-      setActionError((e as Error)?.message ?? "No se pudo ejecutar el barrido.");
-    } finally {
-      setSweeping(false);
-    }
-  }
-
-  async function handleMark(letter: RenewalLetter, channel: "MAIL" | "EMAIL") {
-    setActionError(null);
-    setNotice(null);
-    try {
-      await apiFetch(`/policies/${letter.policyId}/renewal-notices`, {
-        method: "POST",
-        body: JSON.stringify({
-          generation: letter.generation,
-          channel,
-        } satisfies RenewalMarkInput),
-      });
-      setNotice(`Aviso marcado como enviado (${CHANNEL_LABEL[channel]}).`);
-      await refresh();
-    } catch (e) {
-      setActionError(
-        (e as Error)?.message ?? "No se pudo registrar el aviso.",
-      );
-    }
-  }
-
-  if (!allowed) {
-    return (
-      <div className="page-head">
-        <h1 className="page-title">Renovaciones</h1>
-        <div className="state-box state-error">
-          No tiene permisos para enviar avisos de renovación.
-        </div>
-      </div>
-    );
-  }
-
-  const counts = (pending ?? []).reduce<Record<number, number>>(
-    (acc, item) => ({
-      ...acc,
-      [item.generation]: (acc[item.generation] ?? 0) + 1,
-    }),
-    {},
-  );
-  const grouped = [1, 2, 3].filter((gen) => (counts[gen] ?? 0) > 0);
-
-  return (
-    <>
-      <div className="page-head">
-        <p className="eyebrow">Renovaciones</p>
-        <h1 className="page-title">Avisos de renovación</h1>
-        <p className="muted" style={{ marginTop: 6, maxWidth: 720 }}>
-          El sistema ejecuta un barrido diario a las 06:00 hora local que
-          notifica a los clientes a 30, 15 y 7 días antes o después del
-          vencimiento de su póliza. Esta pantalla muestra qué avisos están
-          pendientes y permite ejecutarlo manualmente.
-        </p>
-      </div>
-
-      {actionError && <div className="state-box state-error">{actionError}</div>}
-      {notice && <div className="state-box">{notice}</div>}
-
-      <div className="card" style={{ padding: 20, marginBottom: 20 }}>
-        <div className="row-actions" style={{ justifyContent: "space-between" }}>
-          <div>
-            <h2 className="section-title">Barrido manual</h2>
-            <p className="muted small" style={{ marginTop: 4 }}>
-              Usa la fecha actual del servidor como referencia para seleccionar
-              avisos vencidos a 30 y 15 días, y vencidos hace 7 días.
-            </p>
-          </div>
-          <button
-            type="button"
-            className="btn btn-primary"
-            disabled={sweeping}
-            onClick={handleSweep}
-          >
-            {sweeping ? "Enviando…" : "Ejecutar barrido"}
-          </button>
-        </div>
-        <div className="field" style={{ maxWidth: 180, marginTop: 12 }}>
-          <span className="field-label">Ventana (días)</span>
-          <input
-            className="input"
-            type="number"
-            min={1}
-            max={365}
-            value={days}
-            onChange={(e) =>
-              setDays(Math.min(365, Math.max(1, Number(e.target.value) || 30)))
-            }
-          />
-        </div>
-      </div>
-
-      {pendingError && (
-        <div className="state-box state-error">{pendingError}</div>
-      )}
-
-      {!pendingError && grouped.length === 0 && (
-        <div className="empty-inline">
-          No hay avisos pendientes en esta ventana.
-        </div>
-      )}
-
-      {grouped.map((generation) => (
-        <section className="card" key={generation} style={{ padding: 20 }}>
-          <h2 className="section-title">{GENERATION_LABEL[generation]}</h2>
-          <div className="tx-scroll">
-            <table className="tx-table">
-              <thead>
-                <tr>
-                  <th>Cliente</th>
-                  <th>Póliza</th>
-                  <th>Tipo</th>
-                  <th>Aseguradora</th>
-                  <th>Vence</th>
-                  <th className="num">Prima</th>
-                  <th>Acciones</th>
-                </tr>
-              </thead>
-              <tbody>
-                {(pending ?? [])
-                  .filter((item) => item.generation === generation)
-                  .map((item) => (
-                    <tr key={`${item.policyId}-${item.generation}`}>
-                      <td>
-                        <div>{item.customerName}</div>
-                        <div className="muted small">
-                          {item.customerEmail ?? "Sin correo"}
-                        </div>
-                      </td>
-                      <td className="mono">{item.policyNumber}</td>
-                      <td>{item.policyType}</td>
-                      <td>{item.provider}</td>
-                      <td>{formatDate(item.policyTo)}</td>
-                      <td className="num">
-                        {formatMoney(item.total ?? item.netPremium, item.currency)}
-                      </td>
-                      <td>
-                        <div className="row-actions">
-                          <button
-                            type="button"
-                            className="btn btn-outline btn-sm"
-                            onClick={() => handleMark(item, "EMAIL")}
-                            disabled={!item.customerEmail}
-                          >
-                            Marcar EMAIL
-                          </button>
-                          <button
-                            type="button"
-                            className="btn btn-outline btn-sm"
-                            onClick={() => handleMark(item, "MAIL")}
-                          >
-                            Marcar impreso
-                          </button>
-                        </div>
-                      </td>
-                    </tr>
-                  ))}
-              </tbody>
-            </table>
-          </div>
-        </section>
-      ))}
-    </>
-  );
-}

apps/web/src/components/AdminEmailsSetting.tsx

@@ -0,0 +1,196 @@
+"use client";
+
+import { useCallback, useEffect, useState } from "react";
+import { useCan } from "@/lib/abilities";
+import {
+  getNotificationAdminEmails,
+  setNotificationAdminEmails,
+  type NotificationAdminEmails,
+} from "@/lib/api";
+import { formatDateTime } from "@/lib/labels";
+
+/**
+ * Who receives the per-job summary email.
+ *
+ * This used to be NOTIFICATION_ADMIN_EMAILS in the deployment environment,
+ * which made "add Beto to the summaries" a redeploy. It is now a stored
+ * setting; the env var still acts as the fallback until someone saves here,
+ * so nothing changes for a deployment that never touches this screen.
+ */
+
+const SOURCE_NOTE: Record<NotificationAdminEmails["source"], string> = {
+  db: "Guardado desde esta pantalla.",
+  env: "Viene de la configuración del despliegue (NOTIFICATION_ADMIN_EMAILS). Al guardar aquí, este valor toma precedencia.",
+  default: "Nadie lo ha configurado; se están usando los valores por omisión.",
+};
+
+export function AdminEmailsSetting() {
+  const canEdit = useCan("setting:manage");
+
+  const [setting, setSetting] = useState<NotificationAdminEmails | null>(null);
+  const [draft, setDraft] = useState("");
+  const [editing, setEditing] = useState(false);
+  const [saving, setSaving] = useState(false);
+  const [error, setError] = useState<string | null>(null);
+  const [saved, setSaved] = useState(false);
+
+  const load = useCallback(async () => {
+    try {
+      const data = await getNotificationAdminEmails();
+      setSetting(data);
+      setDraft(data.value.join(", "));
+      setError(null);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    }
+  }, []);
+
+  useEffect(() => {
+    void load();
+  }, [load]);
+
+  async function save() {
+    setSaving(true);
+    setError(null);
+    setSaved(false);
+    try {
+      const emails = draft
+        .split(",")
+        .map((s) => s.trim())
+        .filter(Boolean);
+      const data = await setNotificationAdminEmails(emails);
+      setSetting(data);
+      setDraft(data.value.join(", "));
+      setEditing(false);
+      setSaved(true);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    } finally {
+      setSaving(false);
+    }
+  }
+
+  function cancel() {
+    setDraft(setting?.value.join(", ") ?? "");
+    setEditing(false);
+    setError(null);
+  }
+
+  if (!setting) {
+    return (
+      <section className="card" style={{ padding: 20 }}>
+        <h2 className="section-title">Destinatarios del resumen</h2>
+        {error ? (
+          <div className="state-box state-error" style={{ marginTop: 12 }}>
+            {error}
+          </div>
+        ) : (
+          <p className="muted small" style={{ marginTop: 8, marginBottom: 0 }}>
+            Cargando…
+          </p>
+        )}
+      </section>
+    );
+  }
+
+  return (
+    <section className="card" style={{ padding: 20 }}>
+      <div
+        style={{
+          display: "flex",
+          justifyContent: "space-between",
+          alignItems: "flex-start",
+          gap: 12,
+          flexWrap: "wrap",
+        }}
+      >
+        <div>
+          <h2 className="section-title">Destinatarios del resumen</h2>
+          <p className="muted small" style={{ marginTop: 4, marginBottom: 0, maxWidth: 620 }}>
+            Después de cada envío se manda un correo interno con el resultado
+            (enviados, omitidos, fallidos). Estas son las direcciones que lo
+            reciben. No afecta a los correos que reciben los clientes.
+          </p>
+        </div>
+        {canEdit && !editing && (
+          <button
+            type="button"
+            className="btn btn-outline btn-sm"
+            onClick={() => setEditing(true)}
+          >
+            Editar
+          </button>
+        )}
+      </div>
+
+      {error && (
+        <div className="state-box state-error" style={{ marginTop: 12 }}>
+          {error}
+        </div>
+      )}
+
+      {editing ? (
+        <div style={{ marginTop: 14 }}>
+          <label className="field" style={{ marginBottom: 8 }}>
+            <span className="field-label">
+              Correos separados por coma (vacío = no enviar resumen a nadie)
+            </span>
+            <input
+              className="input"
+              type="text"
+              value={draft}
+              disabled={saving}
+              placeholder="alguien@ejemplo.com, otro@ejemplo.com"
+              onChange={(e) => setDraft(e.target.value)}
+            />
+          </label>
+          <div className="row-actions">
+            <button
+              type="button"
+              className="btn btn-primary btn-sm"
+              disabled={saving}
+              onClick={() => void save()}
+            >
+              {saving ? "Guardando…" : "Guardar"}
+            </button>
+            <button
+              type="button"
+              className="btn btn-outline btn-sm"
+              disabled={saving}
+              onClick={cancel}
+            >
+              Cancelar
+            </button>
+          </div>
+        </div>
+      ) : (
+        <div style={{ marginTop: 14 }}>
+          {setting.value.length === 0 ? (
+            <span className="empty-inline">
+              Nadie recibe el resumen de los envíos.
+            </span>
+          ) : (
+            <ul className="small" style={{ margin: 0, paddingLeft: 18 }}>
+              {setting.value.map((email) => (
+                <li key={email} className="mono">
+                  {email}
+                </li>
+              ))}
+            </ul>
+          )}
+          <p className="section-note" style={{ marginTop: 10, marginBottom: 0 }}>
+            {SOURCE_NOTE[setting.source]}
+            {setting.updatedAt &&
+              ` Última edición: ${formatDateTime(setting.updatedAt)}.`}
+            {saved && " Guardado."}
+          </p>
+          {!canEdit && (
+            <p className="section-note" style={{ marginTop: 6, marginBottom: 0 }}>
+              Solo un ADMIN puede cambiar esta lista.
+            </p>
+          )}
+        </div>
+      )}
+    </section>
+  );
+}

apps/web/src/components/AppShell.tsx

@@ -28,6 +28,9 @@ type NavLink = {
   href: string;
   label: string;
   ability?: Ability;
+  /** Shown when the user holds *any* of these — for a screen that merges two
+   *  separately-gated jobs (Notificaciones: servicios + pólizas). */
+  anyAbility?: Ability[];
   exact?: boolean;
   /** Extra path prefixes that belong to this entry (e.g. a second route into
    *  the same screen), so they highlight it instead of nothing. */
@@ -78,13 +81,15 @@ const NAV: NavEntry[] = [
         label: "Cuentas de chequera",
         ability: "bank:manage-accounts",
       },
+      // Mass email (servicios) and renewal notices (pólizas) are two tabs of
+      // one screen; `/renovaciones` opens the same page on its pólizas tab.
       {
         href: "/notificaciones",
-        label: "Notificaciones masivas",
-        ability: "notification:send",
+        label: "Notificaciones",
+        anyAbility: ["notification:send", "renewal:send"],
+        aliases: ["/renovaciones"],
       },
       { href: "/usuarios", label: "Usuarios", ability: "user:manage" },
-      { href: "/renovaciones", label: "Renovaciones", ability: "renewal:send" },
       { href: "/operaciones", label: "Operaciones", ability: "db:manage" },
     ],
   },
@@ -97,7 +102,9 @@ const NAV_LINKS: NavLink[] = NAV.flatMap((entry) =>
 
 /** The nav the given user may see, with empty groups dropped. */
 function visibleNav(user: AuthUser | null): NavEntry[] {
-  const allowed = (item: NavLink) => !item.ability || can(user, item.ability);
+  const allowed = (item: NavLink) =>
+    (!item.ability || can(user, item.ability)) &&
+    (!item.anyAbility || item.anyAbility.some((a) => can(user, a)));
   const out: NavEntry[] = [];
   for (const entry of NAV) {
     if (entry.kind === "link") {

apps/web/src/components/Notificaciones.tsx

@@ -0,0 +1,111 @@
+"use client";
+
+import { useState } from "react";
+import { useCan } from "@/lib/abilities";
+import { NotificacionesServicios } from "@/components/NotificacionesServicios";
+import { NotificacionesPolizas } from "@/components/NotificacionesPolizas";
+import { NotificationFlagsCard } from "@/components/NotificationFlagsCard";
+import { NotificationScheduleCard } from "@/components/NotificationScheduleCard";
+import type { NotificationFlags } from "@/lib/api";
+
+/**
+ * Notificaciones — one screen, two subsections:
+ *
+ * - **servicios** — the four mass-email jobs against customer ledgers
+ *   (pagos pendientes, confirmación de pago, estado de cuenta, fideicomiso).
+ * - **polizas** — renewal notices, 30/15 days before and 7 days after a
+ *   policy expires.
+ *
+ * Both are "tell a customer something by email", so they are modes of one
+ * screen rather than two menu entries. `/renovaciones` still resolves here on
+ * the pólizas tab so old bookmarks keep working (same pattern as Captura).
+ *
+ * Two things are owned by this shell rather than by a tab, because they are
+ * true of every notification: the send flags (`debug` in particular, which the
+ * pólizas half honours exactly like the servicios half) and the automatic
+ * cadence of both sweeps. Keeping the flags here also means switching tabs
+ * cannot silently drop a `debug` the operator just ticked.
+ */
+
+export type NotificacionesTab = "servicios" | "polizas";
+
+const TAB_HINT: Record<NotificacionesTab, string> = {
+  servicios:
+    "Envíos masivos de cobranza y estado de cuenta a los clientes de servicios.",
+  polizas: "Avisos de renovación de pólizas: 30 y 15 días antes, 7 días después.",
+};
+
+export function Notificaciones({
+  initialTab = "servicios",
+}: {
+  initialTab?: NotificacionesTab;
+}) {
+  const canNotify = useCan("notification:send");
+  const canRenew = useCan("renewal:send");
+
+  // Gating is cosmetic (the API enforces every send), but a user who only has
+  // one of the two abilities should land on the tab they can actually use.
+  // Servicios stays visible read-only for STAFF, who can browse the log.
+  const tabs: { key: NotificacionesTab; label: string }[] = [
+    { key: "servicios", label: "Servicios" },
+    ...(canRenew ? [{ key: "polizas" as const, label: "Pólizas" }] : []),
+  ];
+
+  const [tab, setTab] = useState<NotificacionesTab>(
+    tabs.some((t) => t.key === initialTab) ? initialTab : "servicios",
+  );
+  // Defaults to debug ON: the safe end of the switch is the one you land on.
+  const [flags, setFlags] = useState<NotificationFlags>({ debug: true });
+
+  if (!canNotify && !canRenew) {
+    return (
+      <div className="state-box state-error">
+        No tienes permiso para enviar notificaciones.
+      </div>
+    );
+  }
+
+  return (
+    <>
+      <div className="page-head">
+        <p className="eyebrow">Notificaciones</p>
+        <h1 className="page-title">Notificaciones</h1>
+        <p className="muted" style={{ marginTop: 6, maxWidth: 720 }}>
+          {TAB_HINT[tab]}
+        </p>
+      </div>
+
+      <div style={{ display: "grid", gap: 16, marginBottom: 20 }}>
+        <NotificationFlagsCard
+          flags={flags}
+          onChange={setFlags}
+          disabled={!canNotify && !canRenew}
+        />
+        <NotificationScheduleCard />
+      </div>
+
+      {tabs.length > 1 && (
+        <div className="seg" role="tablist" style={{ marginBottom: 20 }}>
+          {tabs.map((t) => (
+            <button
+              key={t.key}
+              type="button"
+              role="tab"
+              aria-selected={tab === t.key}
+              className={`seg-btn ${tab === t.key ? "active" : ""}`}
+              onClick={() => setTab(t.key)}
+            >
+              {t.label}
+            </button>
+          ))}
+        </div>
+      )}
+
+      {tab === "servicios" ? (
+        <NotificacionesServicios flags={flags} />
+      ) : (
+        <NotificacionesPolizas flags={flags} />
+      )}
+    </>
+  );
+}

apps/web/src/components/NotificacionesPolizas.tsx

@@ -0,0 +1,305 @@
+"use client";
+
+import { useCallback, useEffect, useState } from "react";
+import { useCan } from "@/lib/abilities";
+import { formatDate, formatMoney } from "@/lib/labels";
+import { NotificationLogPanel } from "@/components/NotificationLogPanel";
+import { apiFetch, POLIZAS_LOG_SCOPE, type NotificationFlags } from "@/lib/api";
+
+/**
+ * Renewal notices — the "Pólizas" half of /notificaciones. Shows which
+ * renewal letters are pending in a window and lets staff send them, either
+ * one row at a time or as a whole sweep. Sending is what marks a notice as
+ * delivered — there is no manual "mark as sent", so the list can never claim
+ * a letter went out when no mail was ever sent. Gated on `renewal:send`.
+ *
+ * Sends are recorded in the same `email_notification_log` the Servicios tab
+ * reads, so "Registro de envíos" below is the same component with the
+ * POLICIES slice — failures and no-email skips included, which the pending
+ * list alone cannot show.
+ *
+ * `debug` comes from the shared flags card above the tabs and means the same
+ * thing here as it does for servicios: the mail is diverted to the override
+ * inbox. It additionally does NOT mark the notice as sent, so a test send
+ * leaves the row exactly where it was — pending.
+ */
+
+export interface RenewalLetter {
+  policyId: string;
+  policyNumber: string;
+  policyType: string;
+  customerName: string;
+  customerEmail: string | null;
+  provider: string;
+  policyTo: string;
+  netPremium: string | null;
+  total: string | null;
+  currency: string;
+  generation: number;
+  sentAt: string | null;
+}
+
+export interface RenewalSweepResult {
+  eligible: number;
+  sent: number;
+  skipped: number;
+  failed: number;
+  failures: { policyId: string; generation: number; error: string }[];
+  debug: boolean;
+}
+
+export interface RenewalSendResult {
+  policyId: string;
+  generation: number;
+  /** Where the mail actually went — the override inbox under debug. */
+  to: string;
+  debug: boolean;
+  sentAt: string;
+  providerMessageId?: string;
+}
+
+const GENERATION_LABEL: Record<number, string> = {
+  1: "Primer aviso (30 días antes)",
+  2: "Segundo aviso (15 días antes)",
+  3: "Tercer aviso (7 días después)",
+};
+
+export function NotificacionesPolizas({ flags }: { flags: NotificationFlags }) {
+  const allowed = useCan("renewal:send");
+  const debug = !!flags.debug;
+  const [days, setDays] = useState(30);
+  const [pending, setPending] = useState<RenewalLetter[] | null>(null);
+  const [pendingError, setPendingError] = useState<string | null>(null);
+  const [actionError, setActionError] = useState<string | null>(null);
+  const [notice, setNotice] = useState<string | null>(null);
+  const [sweeping, setSweeping] = useState(false);
+  /** `policyId-generation` of the row currently being sent, if any. */
+  const [sendingKey, setSendingKey] = useState<string | null>(null);
+  /** Raised after every send so the log panel reloads. */
+  const [logToken, setLogToken] = useState(0);
+
+  const refresh = useCallback(async () => {
+    setPendingError(null);
+    try {
+      const data = await apiFetch<RenewalLetter[]>(
+        `/renewals/pending?days=${days}`,
+      );
+      setPending(data);
+    } catch (e) {
+      setPendingError(
+        (e as Error)?.message ?? "No se pudo cargar la lista de avisos.",
+      );
+      setPending([]);
+    }
+  }, [days]);
+
+  useEffect(() => {
+    if (allowed) refresh();
+  }, [allowed, refresh]);
+
+  async function handleSweep() {
+    // Only worth confirming when debug is off — that is the case where real
+    // customers receive mail. Mirrors "Ejecutar todos" on the servicios tab.
+    if (!debug) {
+      const ok = window.confirm(
+        "debug está desactivado: los avisos irán a los correos reales de los clientes. ¿Ejecutar el barrido?",
+      );
+      if (!ok) return;
+    }
+    setActionError(null);
+    setNotice(null);
+    setSweeping(true);
+    try {
+      const result = await apiFetch<RenewalSweepResult>("/renewals/sweep", {
+        method: "POST",
+        body: JSON.stringify({ debug }),
+      });
+      setNotice(
+        `Enviados ${result.sent} avisos (${result.failed} con error).` +
+          (result.debug
+            ? " Modo debug: fueron al buzón de pruebas y siguen pendientes."
+            : ""),
+      );
+      setLogToken((t) => t + 1);
+      await refresh();
+    } catch (e) {
+      setActionError((e as Error)?.message ?? "No se pudo ejecutar el barrido.");
+      setLogToken((t) => t + 1);
+    } finally {
+      setSweeping(false);
+    }
+  }
+
+  /**
+   * Send this one notice now. The API records it as sent on success, so the
+   * row leaves the pending list — that disappearance IS the "sent" signal,
+   * backed by the confirmation line above the table.
+   */
+  async function handleSend(letter: RenewalLetter) {
+    setActionError(null);
+    setNotice(null);
+    setSendingKey(`${letter.policyId}-${letter.generation}`);
+    try {
+      const result = await apiFetch<RenewalSendResult>("/renewals/send", {
+        method: "POST",
+        body: JSON.stringify({
+          policyId: letter.policyId,
+          generation: letter.generation,
+          debug,
+        }),
+      });
+      setNotice(
+        result.debug
+          ? `Prueba enviada a ${result.to}. El aviso sigue pendiente: el cliente no ha recibido nada.`
+          : `Aviso enviado a ${result.to}.`,
+      );
+      setLogToken((t) => t + 1);
+      await refresh();
+    } catch (e) {
+      setActionError((e as Error)?.message ?? "No se pudo enviar el aviso.");
+      // A rejected send may still have written a FAILED row; reload either way.
+      setLogToken((t) => t + 1);
+    } finally {
+      setSendingKey(null);
+    }
+  }
+
+  if (!allowed) {
+    return (
+      <div className="empty-inline">
+        No tiene permisos para enviar avisos de renovación.
+      </div>
+    );
+  }
+
+  const counts = (pending ?? []).reduce<Record<number, number>>(
+    (acc, item) => ({
+      ...acc,
+      [item.generation]: (acc[item.generation] ?? 0) + 1,
+    }),
+    {},
+  );
+  const grouped = [1, 2, 3].filter((gen) => (counts[gen] ?? 0) > 0);
+
+  return (
+    <div style={{ display: "grid", gap: 20 }}>
+      <p className="muted" style={{ maxWidth: 760, margin: 0 }}>
+        El sistema ejecuta un barrido automático (ver «Programación de envíos»
+        arriba) que notifica a los clientes a 30, 15 y 7 días antes o después
+        del vencimiento de su póliza. Esta sección muestra qué avisos están
+        pendientes y permite ejecutarlo manualmente.
+      </p>
+
+      {actionError && <div className="state-box state-error">{actionError}</div>}
+      {notice && <div className="empty-inline">{notice}</div>}
+
+      <section className="card" style={{ padding: 20 }}>
+        <div className="row-actions" style={{ justifyContent: "space-between" }}>
+          <div>
+            <h2 className="section-title">Barrido manual</h2>
+            <p className="muted small" style={{ marginTop: 4 }}>
+              Usa la fecha actual del servidor como referencia para seleccionar
+              avisos vencidos a 30 y 15 días, y vencidos hace 7 días.
+            </p>
+          </div>
+          <button
+            type="button"
+            className="btn btn-primary"
+            disabled={sweeping}
+            onClick={handleSweep}
+          >
+            {sweeping ? "Enviando…" : "Ejecutar barrido"}
+          </button>
+        </div>
+        <div className="field" style={{ maxWidth: 180, marginTop: 12, marginBottom: 0 }}>
+          <span className="field-label">Ventana (días)</span>
+          <input
+            className="input"
+            type="number"
+            min={1}
+            max={365}
+            value={days}
+            onChange={(e) =>
+              setDays(Math.min(365, Math.max(1, Number(e.target.value) || 30)))
+            }
+          />
+        </div>
+      </section>
+
+      {pendingError && <div className="state-box state-error">{pendingError}</div>}
+
+      {!pendingError && grouped.length === 0 && (
+        <div className="empty-inline">
+          No hay avisos pendientes en esta ventana.
+        </div>
+      )}
+
+      {grouped.map((generation) => (
+        <section className="card" key={generation} style={{ padding: 20 }}>
+          <h2 className="section-title">{GENERATION_LABEL[generation]}</h2>
+          <div className="tx-scroll" style={{ marginTop: 12 }}>
+            <table className="tx-table">
+              <thead>
+                <tr>
+                  <th>Cliente</th>
+                  <th>Póliza</th>
+                  <th>Tipo</th>
+                  <th>Aseguradora</th>
+                  <th>Vence</th>
+                  <th className="num">Prima</th>
+                  <th>Acciones</th>
+                </tr>
+              </thead>
+              <tbody>
+                {(pending ?? [])
+                  .filter((item) => item.generation === generation)
+                  .map((item) => (
+                    <tr key={`${item.policyId}-${item.generation}`}>
+                      <td>
+                        <div>{item.customerName}</div>
+                        <div className="muted small">
+                          {item.customerEmail ?? "Sin correo"}
+                        </div>
+                      </td>
+                      <td className="mono">{item.policyNumber}</td>
+                      <td>{item.policyType}</td>
+                      <td>{item.provider}</td>
+                      <td>{formatDate(item.policyTo)}</td>
+                      <td className="num">
+                        {formatMoney(item.total ?? item.netPremium, item.currency)}
+                      </td>
+                      <td>
+                        <div className="row-actions">
+                          <button
+                            type="button"
+                            className="btn btn-outline btn-sm"
+                            onClick={() => handleSend(item)}
+                            disabled={
+                              !item.customerEmail ||
+                              sweeping ||
+                              sendingKey !== null
+                            }
+                          >
+                            {sendingKey ===
+                            `${item.policyId}-${item.generation}`
+                              ? "Enviando…"
+                              : "Enviar aviso"}
+                          </button>
+                        </div>
+                      </td>
+                    </tr>
+                  ))}
+              </tbody>
+            </table>
+          </div>
+        </section>
+      ))}
+
+      <NotificationLogPanel
+        servicio={POLIZAS_LOG_SCOPE}
+        reloadToken={logToken}
+        emptyHint="Todavía no se ha enviado ningún aviso de renovación con este filtro."
+      />
+    </div>
+  );
+}

apps/web/src/components/NotificacionesServicios.tsx

@@ -0,0 +1,353 @@
+"use client";
+
+import { useCallback, useEffect, useState } from "react";
+import { useCan } from "@/lib/abilities";
+import {
+  formatDateTime,
+  NOTIFICATION_STATUS_LABELS,
+  NOTIFICATION_TYPE_LABELS,
+} from "@/lib/labels";
+import { NotificationLogPanel } from "@/components/NotificationLogPanel";
+import { AdminEmailsSetting } from "@/components/AdminEmailsSetting";
+import {
+  getNotificationStats,
+  runAccountStatus,
+  runAllNotifications,
+  runOutstandingPayments,
+  runPaymentConfirmation,
+  runTrustConfirmation,
+  SERVICIOS_LOG_SCOPE,
+} from "@/lib/api";
+import type {
+  NotificationFlags,
+  NotificationJobResponse,
+  NotificationRunAllResponse,
+  NotificationStats,
+} from "@/lib/api";
+
+/**
+ * Mass email notifications — the "Servicios" half of /notificaciones. Manual
+ * triggers for the four jobs plus a paged log browser. Gated on
+ * `notification:send`; a STAFF viewer sees the read-only log table but not the
+ * trigger buttons.
+ *
+ * The send flags come from the shell above the tabs — they are shared with the
+ * pólizas half — so this component only consumes them.
+ */
+
+type JobKind = "outstanding" | "payment" | "account" | "trust";
+
+interface JobDef {
+  kind: JobKind;
+  title: string;
+  endpoint: string;
+  description: string;
+  servicio: "Clientes" | "Fideicomiso";
+  flagsHint?: string;
+}
+
+const JOBS: JobDef[] = [
+  {
+    kind: "outstanding",
+    title: "Pagos pendientes",
+    endpoint: "sendOutstandingPaymentAlerts",
+    servicio: "Clientes",
+    description:
+      "Clientes con al menos un movimiento marcado como pendiente (outstanding). Equivale a la columna NOPAGO=1 del antiguo datosfreak.",
+  },
+  {
+    kind: "payment",
+    title: "Confirmación de pago",
+    endpoint: "sendPaymentConfirmation",
+    servicio: "Clientes",
+    description:
+      "Clientes con un crédito (abono) en las últimas 24 horas. Un correo por cliente con el pago más reciente.",
+  },
+  {
+    kind: "account",
+    title: "Estado de cuenta",
+    endpoint: "sendAccountStatus",
+    servicio: "Clientes",
+    description:
+      "Alerta amarilla (DEBAJO DEL TIPO) los miércoles y roja (EN ROJO) lunes/miércoles/viernes. El flag ignoreDayRestriction salta los gates.",
+    flagsHint: "Solo este job respeta ignoreDayRestriction y useEmailLimit.",
+  },
+  {
+    kind: "trust",
+    title: "Confirmación fideicomiso",
+    endpoint: "sendConfirmTrustPayment",
+    servicio: "Fideicomiso",
+    description:
+      "Clientes con TrustAccount que recibieron un crédito en el dominio TRUST en las últimas 24 horas.",
+  },
+];
+
+/** Job title by kind — used by the run-all summary, which only carries kinds. */
+const JOB_TITLES: Record<JobKind, string> = JOBS.reduce(
+  (acc, j) => ({ ...acc, [j.kind]: j.title }),
+  {} as Record<JobKind, string>,
+);
+
+export function NotificacionesServicios({ flags }: { flags: NotificationFlags }) {
+  const allowed = useCan("notification:send");
+
+  const [stats, setStats] = useState<NotificationStats | null>(null);
+  /** Raised after every run so the shared log panel reloads. */
+  const [logToken, setLogToken] = useState(0);
+  const [busy, setBusy] = useState<JobKind | "all" | null>(null);
+  const [lastResult, setLastResult] = useState<
+    NotificationJobResponse | NotificationRunAllResponse | null
+  >(null);
+  const [error, setError] = useState<string | null>(null);
+
+  const refresh = useCallback(async () => {
+    try {
+      setStats(await getNotificationStats(SERVICIOS_LOG_SCOPE));
+      setLogToken((t) => t + 1);
+      setError(null);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    }
+  }, []);
+
+  useEffect(() => {
+    void refresh();
+  }, [refresh]);
+
+  const run = useCallback(
+    async (job: JobDef) => {
+      if (!allowed) return;
+      setBusy(job.kind);
+      setError(null);
+      try {
+        let res: NotificationJobResponse;
+        if (job.kind === "outstanding") res = await runOutstandingPayments(flags);
+        else if (job.kind === "payment") res = await runPaymentConfirmation(flags);
+        else if (job.kind === "account") res = await runAccountStatus(flags);
+        else res = await runTrustConfirmation(flags);
+        setLastResult(res);
+        await refresh();
+      } catch (e) {
+        setError(e instanceof Error ? e.message : String(e));
+      } finally {
+        setBusy(null);
+      }
+    },
+    [allowed, flags, refresh],
+  );
+
+  // "Ejecutar todos" — one POST, the API runs the four jobs sequentially with
+  // the same flags. Confirmation only matters when debug is off, since that
+  // is the case where real customers receive mail.
+  const runAll = useCallback(async () => {
+    if (!allowed) return;
+    if (!flags.debug) {
+      const ok = window.confirm(
+        "debug está desactivado: los cuatro envíos irán a los correos reales de los clientes. ¿Ejecutar todos?",
+      );
+      if (!ok) return;
+    }
+    setBusy("all");
+    setError(null);
+    try {
+      const res = await runAllNotifications(flags);
+      setLastResult(res);
+      await refresh();
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    } finally {
+      setBusy(null);
+    }
+  }, [allowed, flags, refresh]);
+
+  return (
+    <div style={{ display: "grid", gap: 20 }}>
+      <p className="muted" style={{ maxWidth: 760, margin: 0 }}>
+        Disparo manual de los cuatro envíos equivalentes a los scripts PHP de{" "}
+        <code>email.notifications/</code>. Cada ejecución registra todas las filas
+        (enviado, fallido, omitido) en <code>email_notification_log</code>.
+      </p>
+
+      {!allowed && (
+        <div className="empty-inline">
+          Tu rol no incluye <code>notification:send</code>. Solo puedes ver el
+          registro. Para disparar envíos pide a un MANAGER/ADMIN.
+        </div>
+      )}
+
+      {error && <div className="state-box state-error">{error}</div>}
+
+      <section className="card" style={{ padding: 20 }}>
+        <h2 className="section-title">Ejecutar ahora</h2>
+        <div
+          style={{
+            display: "flex",
+            alignItems: "center",
+            gap: 12,
+            flexWrap: "wrap",
+            marginTop: 12,
+          }}
+        >
+          <button
+            type="button"
+            className="btn btn-primary btn-sm"
+            disabled={!allowed || busy !== null}
+            onClick={() => void runAll()}
+          >
+            {busy === "all" ? "Ejecutando todos…" : "Ejecutar todos"}
+          </button>
+          <span className="muted small">
+            Dispara los cuatro envíos en orden (pagos pendientes, confirmación
+            de pago, estado de cuenta, fideicomiso) con los flags de arriba. Si
+            uno falla, los demás continúan. Es lo mismo que ejecuta la corrida
+            programada de Servicios.
+          </span>
+        </div>
+      </section>
+
+      <section
+        style={{
+          display: "grid",
+          gridTemplateColumns: "repeat(auto-fit, minmax(280px, 1fr))",
+          gap: 12,
+        }}
+      >
+        {JOBS.map((j) => (
+          <article
+            key={j.kind}
+            className="card"
+            style={{ padding: 18, display: "grid", gap: 8, alignContent: "start" }}
+          >
+            <header
+              style={{
+                display: "flex",
+                justifyContent: "space-between",
+                alignItems: "center",
+                gap: 8,
+              }}
+            >
+              <strong>{j.title}</strong>
+              <span
+                className={
+                  j.servicio === "Fideicomiso"
+                    ? "badge badge-fideicomiso"
+                    : "badge badge-servicios"
+                }
+              >
+                <span className="dot" />
+                {j.servicio}
+              </span>
+            </header>
+            <p className="muted small" style={{ margin: 0 }}>
+              {j.description}
+            </p>
+            {j.flagsHint && (
+              <p className="section-note" style={{ margin: 0, fontStyle: "italic" }}>
+                {j.flagsHint}
+              </p>
+            )}
+            <div className="row-actions" style={{ marginTop: 4 }}>
+              <button
+                type="button"
+                className="btn btn-primary btn-sm"
+                disabled={!allowed || busy !== null}
+                onClick={() => void run(j)}
+              >
+                {busy === j.kind ? "Ejecutando…" : "Ejecutar"}
+              </button>
+            </div>
+          </article>
+        ))}
+      </section>
+
+      {stats && (
+        <section className="card" style={{ padding: 20 }}>
+          <h2 className="section-title">Estado del transporte</h2>
+          <ul className="small" style={{ marginTop: 10, marginBottom: 0, paddingLeft: 18 }}>
+            <li>
+              SES configurado:{" "}
+              <strong
+                style={{
+                  color: stats.transport.available
+                    ? "var(--positive)"
+                    : "var(--negative)",
+                }}
+              >
+                {stats.transport.available ? "sí" : "no"}
+              </strong>
+              {stats.transport.devFallback && " (fallback dev: stdout)"}
+            </li>
+            <li>
+              Último envío registrado:{" "}
+              {stats.lastRun
+                ? `${NOTIFICATION_TYPE_LABELS[stats.lastRun.notificationType]} — ${formatDateTime(stats.lastRun.sendDate)}`
+                : "—"}
+            </li>
+            <li>
+              Totales:{" "}
+              {stats.byStatus.map((s) => (
+                <span key={s.status} style={{ marginRight: 12 }}>
+                  {NOTIFICATION_STATUS_LABELS[s.status]}: {s._count._all}
+                </span>
+              ))}
+            </li>
+          </ul>
+        </section>
+      )}
+
+      <AdminEmailsSetting />
+
+      {lastResult && (
+        <section className="card" style={{ padding: 20 }}>
+          <h2 className="section-title">Última respuesta</h2>
+          {lastResult.type === "RUN_ALL" && (
+            <ul
+              className="small"
+              style={{ marginTop: 10, marginBottom: 0, paddingLeft: 18 }}
+            >
+              <li>
+                Totales: enviados {lastResult.sent} · omitidos{" "}
+                {lastResult.skipped} · fallidos {lastResult.failed}
+                {lastResult.errors > 0 && ` · jobs con error ${lastResult.errors}`}
+              </li>
+              {lastResult.jobs.map((j) => (
+                <li key={j.kind}>
+                  {JOB_TITLES[j.kind]}:{" "}
+                  {j.ok && j.result ? (
+                    <>
+                      enviados {j.result.sent} · omitidos {j.result.skipped} ·
+                      fallidos {j.result.failed}
+                    </>
+                  ) : (
+                    <span style={{ color: "var(--negative)" }}>
+                      error — {j.error}
+                    </span>
+                  )}
+                </li>
+              ))}
+            </ul>
+          )}
+          <pre
+            className="mono"
+            style={{
+              margin: "10px 0 0",
+              fontSize: 12,
+              overflow: "auto",
+              background: "var(--surface-2)",
+              border: "1px solid var(--line)",
+              borderRadius: "var(--radius-sm)",
+              padding: 12,
+            }}
+          >
+            {JSON.stringify(lastResult, null, 2)}
+          </pre>
+        </section>
+      )}
+
+      <NotificationLogPanel
+        servicio={SERVICIOS_LOG_SCOPE}
+        reloadToken={logToken}
+      />
+    </div>
+  );
+}

apps/web/src/components/NotificationFlagsCard.tsx

@@ -0,0 +1,92 @@
+"use client";
+
+import type { NotificationFlags } from "@/lib/api";
+
+/**
+ * The "Flags del envío" panel. It lives in the /notificaciones shell above the
+ * tabs, not inside one of them, because the flags are platform-wide: `debug`
+ * governs the pólizas avisos exactly as it governs the four servicios jobs,
+ * and a switch that only protected half the screen was the bug this fixes.
+ *
+ * State is per-visit, never persisted — see the note on the schedule card. A
+ * stored `debug` would survive a reload and silently swallow real customer
+ * mail; the automatic corridas therefore always send for real.
+ */
+
+export function NotificationFlagsCard({
+  flags,
+  onChange,
+  disabled = false,
+}: {
+  flags: NotificationFlags;
+  onChange: (next: NotificationFlags) => void;
+  disabled?: boolean;
+}) {
+  const set = (patch: Partial<NotificationFlags>) =>
+    onChange({ ...flags, ...patch });
+
+  return (
+    <section className="card" style={{ padding: 20 }}>
+      <h2 className="section-title">Flags del envío</h2>
+      <p className="muted small" style={{ marginTop: 4, marginBottom: 0, maxWidth: 620 }}>
+        Se aplican a todo lo que se envía desde esta pantalla — servicios y
+        pólizas — y solo a los envíos manuales. Las corridas automáticas siempre
+        mandan de verdad.
+      </p>
+      <div style={{ display: "grid", gap: 4, marginTop: 14 }}>
+        <label
+          className="field"
+          style={{ display: "flex", gap: 8, alignItems: "flex-start", marginBottom: 8 }}
+        >
+          <input
+            type="checkbox"
+            checked={!!flags.debug}
+            disabled={disabled}
+            onChange={(e) => set({ debug: e.target.checked })}
+            style={{ marginTop: 2 }}
+          />
+          <span className="small">
+            <strong>debug</strong> — reescribe todos los destinatarios a{" "}
+            <code>rmancinas@freakma.net</code>. Ningún cliente real recibe el
+            correo mientras esté activo. Un aviso de renovación enviado en debug
+            NO se marca como enviado: sigue pendiente en la lista.
+          </span>
+        </label>
+        <label
+          className="field"
+          style={{ display: "flex", gap: 8, alignItems: "flex-start", marginBottom: 8 }}
+        >
+          <input
+            type="checkbox"
+            checked={!!flags.ignoreDayRestriction}
+            disabled={disabled}
+            onChange={(e) => set({ ignoreDayRestriction: e.target.checked })}
+            style={{ marginTop: 2 }}
+          />
+          <span className="small">
+            <strong>ignoreDayRestriction</strong> — salta los gates de
+            Mon/Wed/Fri del estado de cuenta. Útil para disparar en cualquier
+            día sin esperar a la próxima corrida. Solo aplica a servicios.
+          </span>
+        </label>
+        <label
+          className="field"
+          style={{ display: "flex", gap: 8, alignItems: "flex-start", marginBottom: 0 }}
+        >
+          <input
+            type="checkbox"
+            checked={!!flags.useEmailLimit}
+            disabled={disabled}
+            onChange={(e) => set({ useEmailLimit: e.target.checked })}
+            style={{ marginTop: 2 }}
+          />
+          <span className="small">
+            <strong>useEmailLimit</strong> — pausa el estado de cuenta cada 100
+            correos durante 1 hora. Vestigio de la era SMTP; SES no lo necesita.
+            Solo aplica a servicios.
+          </span>
+        </label>
+      </div>
+    </section>
+  );
+}

apps/web/src/components/NotificationLogPanel.tsx

@@ -0,0 +1,186 @@
+"use client";
+
+import { useCallback, useEffect, useState } from "react";
+import {
+  listNotificationLog,
+  type NotificationLogPage,
+  type NotificationServicio,
+} from "@/lib/api";
+import {
+  formatDateTime,
+  NOTIFICATION_SERVICIO_LABELS,
+  NOTIFICATION_STATUS_COLORS,
+  NOTIFICATION_STATUS_LABELS,
+  NOTIFICATION_TYPE_LABELS,
+  notificationLevelLabel,
+} from "@/lib/labels";
+
+/**
+ * "Registro de envíos" — the send history over `email_notification_log`.
+ *
+ * Every outbound email the platform sends writes to that one table (the four
+ * bulk jobs and the renewal avisos alike), so this component is shared by
+ * both /notificaciones tabs; each passes the `servicio` slice it owns. Rows
+ * cover failures and skips too, which is the whole point: a notice that never
+ * left is invisible everywhere else.
+ */
+
+const LOG_VIEWS = [
+  { key: "all", label: "Todos" },
+  { key: "sent", label: "Enviados" },
+  { key: "failed", label: "Fallidos" },
+  { key: "skipped", label: "Omitidos" },
+] as const;
+
+export type LogView = (typeof LOG_VIEWS)[number]["key"];
+
+export function NotificationLogPanel({
+  servicio,
+  emptyHint = "Sin envíos con el filtro actual.",
+  /** Bump to force a reload — the parent raises it after a send. */
+  reloadToken = 0,
+}: {
+  servicio: NotificationServicio[];
+  emptyHint?: string;
+  reloadToken?: number;
+}) {
+  const [log, setLog] = useState<NotificationLogPage | null>(null);
+  const [error, setError] = useState<string | null>(null);
+  const [view, setView] = useState<LogView>("all");
+  const [page, setPage] = useState(1);
+
+  // `servicio` is a literal array at every call site, so a new identity each
+  // render would re-fetch forever. Key the effect on its contents instead.
+  const servicioKey = servicio.join(",");
+
+  const refresh = useCallback(async () => {
+    try {
+      const data = await listNotificationLog({
+        page,
+        pageSize: 50,
+        servicio: servicioKey.split(",") as NotificationServicio[],
+        view: view === "all" ? undefined : view,
+      });
+      setLog(data);
+      setError(null);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    }
+  }, [page, view, servicioKey]);
+
+  useEffect(() => {
+    void refresh();
+  }, [refresh, reloadToken]);
+
+  return (
+    <section className="card" style={{ padding: 20 }}>
+      <div
+        style={{
+          display: "flex",
+          justifyContent: "space-between",
+          alignItems: "center",
+          gap: 12,
+          flexWrap: "wrap",
+        }}
+      >
+        <h2 className="section-title">Registro de envíos</h2>
+        <div className="seg" role="tablist">
+          {LOG_VIEWS.map((v) => (
+            <button
+              key={v.key}
+              type="button"
+              role="tab"
+              aria-selected={view === v.key}
+              className={`seg-btn ${view === v.key ? "active" : ""}`}
+              onClick={() => {
+                setView(v.key);
+                setPage(1);
+              }}
+            >
+              {v.label}
+            </button>
+          ))}
+        </div>
+      </div>
+
+      {error && (
+        <div className="state-box state-error" style={{ marginTop: 12 }}>
+          {error}
+        </div>
+      )}
+
+      <div className="tx-scroll" style={{ marginTop: 12 }}>
+        <table className="tx-table">
+          <thead>
+            <tr>
+              <th>Fecha</th>
+              <th>Tipo</th>
+              <th>Servicio</th>
+              <th>Cliente</th>
+              <th>Email</th>
+              <th>Estado</th>
+              <th>Asunto</th>
+              <th>Provider</th>
+            </tr>
+          </thead>
+          <tbody>
+            {log?.items.map((row) => (
+              <tr key={row.id}>
+                <td>{formatDateTime(row.sendDate)}</td>
+                <td>
+                  {NOTIFICATION_TYPE_LABELS[row.notificationType]}
+                  {notificationLevelLabel(row.notificationType, row.level)}
+                </td>
+                <td>{NOTIFICATION_SERVICIO_LABELS[row.servicio]}</td>
+                <td>
+                  {row.customerName}
+                  {row.debug ? " · debug" : ""}
+                </td>
+                <td>{row.customerEmail || "—"}</td>
+                <td style={{ color: NOTIFICATION_STATUS_COLORS[row.status] }}>
+                  {NOTIFICATION_STATUS_LABELS[row.status]}
+                </td>
+                <td>{row.subject}</td>
+                <td className="muted small">
+                  {row.providerMessageId ?? row.error ?? "—"}
+                </td>
+              </tr>
+            ))}
+            {log && log.items.length === 0 && (
+              <tr>
+                <td colSpan={8}>
+                  <span className="empty-inline">{emptyHint}</span>
+                </td>
+              </tr>
+            )}
+          </tbody>
+        </table>
+      </div>
+
+      {log && log.pageCount > 1 && (
+        <div className="pager" style={{ marginTop: 14 }}>
+          <button
+            type="button"
+            className="btn btn-outline btn-sm"
+            disabled={log.page <= 1}
+            onClick={() => setPage((p) => Math.max(1, p - 1))}
+          >
+            ← Anterior
+          </button>
+          <span className="pager-info">
+            {log.total} fila{log.total === 1 ? "" : "s"} · página {log.page} de{" "}
+            {log.pageCount}
+          </span>
+          <button
+            type="button"
+            className="btn btn-outline btn-sm"
+            disabled={log.page >= log.pageCount}
+            onClick={() => setPage((p) => Math.min(log.pageCount, p + 1))}
+          >
+            Siguiente →
+          </button>
+        </div>
+      )}
+    </section>
+  );
+}

apps/web/src/components/NotificationScheduleCard.tsx

@@ -0,0 +1,309 @@
+"use client";
+
+import { useCallback, useEffect, useState } from "react";
+import { useCan } from "@/lib/abilities";
+import {
+  getNotificationSchedules,
+  setNotificationSchedule,
+  type NotificationSchedule,
+  type NotificationSchedules,
+  type ScheduleKind,
+} from "@/lib/api";
+import { formatDateTime } from "@/lib/labels";
+
+/**
+ * When the two automatic envíos run.
+ *
+ * Both cadences used to be source code: pólizas barría a las 06:00 desde un
+ * `@Cron` en el servidor y servicios no corría solo en absoluto. Cambiar
+ * cualquiera de los dos era un redeploy. Ahora se guardan en `app_settings` y
+ * el servidor reinstala el job al guardar — sin reinicio.
+ *
+ * Los flags de la tarjeta de arriba NO se aplican aquí: una corrida
+ * automática siempre manda de verdad.
+ */
+
+const KIND_LABEL: Record<ScheduleKind, string> = {
+  servicios: "Servicios",
+  polizas: "Pólizas",
+};
+
+const KIND_HINT: Record<ScheduleKind, string> = {
+  servicios:
+    "Ejecuta los cuatro envíos en orden, igual que el botón «Ejecutar todos». El estado de cuenta sigue respetando sus gates de lunes/miércoles/viernes.",
+  polizas:
+    "Barrido de avisos de renovación: 30 y 15 días antes del vencimiento, y 7 días después.",
+};
+
+const DAYS = [
+  { value: 0, label: "Dom" },
+  { value: 1, label: "Lun" },
+  { value: 2, label: "Mar" },
+  { value: 3, label: "Mié" },
+  { value: 4, label: "Jue" },
+  { value: 5, label: "Vie" },
+  { value: 6, label: "Sáb" },
+];
+
+function timeValue(s: NotificationSchedule): string {
+  return `${String(s.hour).padStart(2, "0")}:${String(s.minute).padStart(2, "0")}`;
+}
+
+function describe(s: NotificationSchedule): string {
+  if (!s.enabled) return "Desactivado — solo se envía manualmente.";
+  const days = s.weekdays.length
+    ? s.weekdays
+        .map((d) => DAYS.find((x) => x.value === d)?.label ?? d)
+        .join(", ")
+    : "todos los días";
+  return `${days} a las ${timeValue(s)} (hora de Tijuana).`;
+}
+
+export function NotificationScheduleCard() {
+  const canEdit = useCan("setting:manage");
+
+  const [schedules, setSchedules] = useState<NotificationSchedules | null>(null);
+  const [drafts, setDrafts] = useState<Partial<Record<ScheduleKind, NotificationSchedule>>>({});
+  const [editing, setEditing] = useState<ScheduleKind | null>(null);
+  const [saving, setSaving] = useState(false);
+  const [error, setError] = useState<string | null>(null);
+  const [saved, setSaved] = useState<ScheduleKind | null>(null);
+
+  const load = useCallback(async () => {
+    try {
+      setSchedules(await getNotificationSchedules());
+      setError(null);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    }
+  }, []);
+
+  useEffect(() => {
+    void load();
+  }, [load]);
+
+  function startEdit(kind: ScheduleKind) {
+    if (!schedules) return;
+    setDrafts((d) => ({ ...d, [kind]: { ...schedules[kind].value } }));
+    setEditing(kind);
+    setSaved(null);
+    setError(null);
+  }
+
+  async function save(kind: ScheduleKind) {
+    const draft = drafts[kind];
+    if (!draft) return;
+    setSaving(true);
+    setError(null);
+    try {
+      const result = await setNotificationSchedule(kind, draft);
+      setSchedules((prev) => (prev ? { ...prev, [kind]: result } : prev));
+      setEditing(null);
+      setSaved(kind);
+    } catch (e) {
+      setError(e instanceof Error ? e.message : String(e));
+    } finally {
+      setSaving(false);
+    }
+  }
+
+  if (!schedules) {
+    return (
+      <section className="card" style={{ padding: 20 }}>
+        <h2 className="section-title">Programación de envíos</h2>
+        {error ? (
+          <div className="state-box state-error" style={{ marginTop: 12 }}>
+            {error}
+          </div>
+        ) : (
+          <p className="muted small" style={{ marginTop: 8, marginBottom: 0 }}>
+            Cargando…
+          </p>
+        )}
+      </section>
+    );
+  }
+
+  return (
+    <section className="card" style={{ padding: 20 }}>
+      <h2 className="section-title">Programación de envíos</h2>
+      <p className="muted small" style={{ marginTop: 4, marginBottom: 0, maxWidth: 660 }}>
+        Cuándo corre solo cada envío. Los cambios aplican de inmediato, sin
+        reiniciar el servidor. Una corrida automática nunca usa los flags de
+        arriba: siempre manda a los clientes reales.
+      </p>
+
+      {error && (
+        <div className="state-box state-error" style={{ marginTop: 12 }}>
+          {error}
+        </div>
+      )}
+
+      <div style={{ display: "grid", gap: 12, marginTop: 14 }}>
+        {(Object.keys(KIND_LABEL) as ScheduleKind[]).map((kind) => {
+          const current = schedules[kind];
+          const draft = drafts[kind];
+          const isEditing = editing === kind && draft;
+
+          return (
+            <article
+              key={kind}
+              style={{
+                border: "1px solid var(--line)",
+                borderRadius: "var(--radius-sm)",
+                padding: 14,
+              }}
+            >
+              <div
+                style={{
+                  display: "flex",
+                  justifyContent: "space-between",
+                  alignItems: "flex-start",
+                  gap: 12,
+                  flexWrap: "wrap",
+                }}
+              >
+                <div>
+                  <strong>{KIND_LABEL[kind]}</strong>
+                  <p className="muted small" style={{ margin: "4px 0 0", maxWidth: 560 }}>
+                    {KIND_HINT[kind]}
+                  </p>
+                </div>
+                {canEdit && !isEditing && (
+                  <button
+                    type="button"
+                    className="btn btn-outline btn-sm"
+                    onClick={() => startEdit(kind)}
+                  >
+                    Editar
+                  </button>
+                )}
+              </div>
+
+              {isEditing ? (
+                <div style={{ marginTop: 12 }}>
+                  <label
+                    className="field"
+                    style={{ display: "flex", gap: 8, alignItems: "center", marginBottom: 10 }}
+                  >
+                    <input
+                      type="checkbox"
+                      checked={draft.enabled}
+                      disabled={saving}
+                      onChange={(e) =>
+                        setDrafts((d) => ({
+                          ...d,
+                          [kind]: { ...draft, enabled: e.target.checked },
+                        }))
+                      }
+                    />
+                    <span className="small">
+                      <strong>Corrida automática activada</strong>
+                    </span>
+                  </label>
+
+                  <label className="field" style={{ maxWidth: 160, marginBottom: 10 }}>
+                    <span className="field-label">Hora (Tijuana)</span>
+                    <input
+                      className="input"
+                      type="time"
+                      value={timeValue(draft)}
+                      disabled={saving || !draft.enabled}
+                      onChange={(e) => {
+                        const [h, m] = e.target.value.split(":").map(Number);
+                        setDrafts((d) => ({
+                          ...d,
+                          [kind]: {
+                            ...draft,
+                            hour: Number.isFinite(h) ? h : draft.hour,
+                            minute: Number.isFinite(m) ? m : draft.minute,
+                          },
+                        }));
+                      }}
+                    />
+                  </label>
+
+                  <div className="field" style={{ marginBottom: 10 }}>
+                    <span className="field-label">
+                      Días (ninguno seleccionado = todos los días)
+                    </span>
+                    <div style={{ display: "flex", gap: 6, flexWrap: "wrap", marginTop: 4 }}>
+                      {DAYS.map((d) => {
+                        const on = draft.weekdays.includes(d.value);
+                        return (
+                          <button
+                            key={d.value}
+                            type="button"
+                            className={`btn btn-sm ${on ? "btn-primary" : "btn-outline"}`}
+                            disabled={saving || !draft.enabled}
+                            onClick={() =>
+                              setDrafts((prev) => ({
+                                ...prev,
+                                [kind]: {
+                                  ...draft,
+                                  weekdays: on
+                                    ? draft.weekdays.filter((x) => x !== d.value)
+                                    : [...draft.weekdays, d.value].sort(),
+                                },
+                              }))
+                            }
+                          >
+                            {d.label}
+                          </button>
+                        );
+                      })}
+                    </div>
+                  </div>
+
+                  <div className="row-actions">
+                    <button
+                      type="button"
+                      className="btn btn-primary btn-sm"
+                      disabled={saving}
+                      onClick={() => void save(kind)}
+                    >
+                      {saving ? "Guardando…" : "Guardar"}
+                    </button>
+                    <button
+                      type="button"
+                      className="btn btn-outline btn-sm"
+                      disabled={saving}
+                      onClick={() => {
+                        setEditing(null);
+                        setError(null);
+                      }}
+                    >
+                      Cancelar
+                    </button>
+                  </div>
+                </div>
+              ) : (
+                <div style={{ marginTop: 10 }}>
+                  <p className="small" style={{ margin: 0 }}>
+                    {describe(current.value)}
+                  </p>
+                  <p className="section-note" style={{ marginTop: 6, marginBottom: 0 }}>
+                    <code>{current.cron}</code>
+                    {current.nextRun &&
+                      ` · próxima corrida: ${formatDateTime(current.nextRun)}`}
+                    {current.source === "default" &&
+                      " · valor por omisión, nadie lo ha cambiado"}
+                    {current.updatedAt &&
+                      ` · última edición: ${formatDateTime(current.updatedAt)}`}
+                    {saved === kind && " · guardado"}
+                  </p>
+                </div>
+              )}
+            </article>
+          );
+        })}
+      </div>
+
+      {!canEdit && (
+        <p className="section-note" style={{ marginTop: 12, marginBottom: 0 }}>
+          Solo un ADMIN puede cambiar la programación.
+        </p>
+      )}
+    </section>
+  );
+}

apps/web/src/lib/api.ts

@@ -979,9 +979,14 @@ export type NotificationType =
   | "OUTSTANDING_PAYMENT"
   | "PAYMENT_CONFIRMATION"
   | "ACCOUNT_STATUS"
-  | "TRUST_PAYMENT_CONFIRMATION";
+  | "TRUST_PAYMENT_CONFIRMATION"
+  | "RENEWAL_NOTICE";
 
-export type NotificationServicio = "CUSTOMERS" | "TRUST";
+export type NotificationServicio = "CUSTOMERS" | "TRUST" | "POLICIES";
+
+/** Which servicios each /notificaciones tab reads out of the shared log. */
+export const SERVICIOS_LOG_SCOPE: NotificationServicio[] = ["CUSTOMERS", "TRUST"];
+export const POLIZAS_LOG_SCOPE: NotificationServicio[] = ["POLICIES"];
 
 export type NotificationStatus =
   | "SENT"
@@ -1125,11 +1130,44 @@ export function runTrustConfirmation(
   });
 }
 
+export type NotificationJobKind = "outstanding" | "payment" | "account" | "trust";
+
+export interface NotificationRunAllJobResult {
+  kind: NotificationJobKind;
+  ok: boolean;
+  result?: NotificationJobResponse;
+  error?: string;
+}
+
+/** Aggregate response of the "Ejecutar todos" sweep. */
+export interface NotificationRunAllResponse {
+  request: "success";
+  notificationType: "runAllNotifications";
+  statusCode: 200;
+  debug: boolean;
+  sent: number;
+  skipped: number;
+  failed: number;
+  errors: number;
+  jobs: NotificationRunAllJobResult[];
+  type: "RUN_ALL";
+}
+
+export function runAllNotifications(
+  flags: NotificationFlags = {},
+): Promise<NotificationRunAllResponse> {
+  return apiFetch<NotificationRunAllResponse>("/notifications/run-all", {
+    method: "POST",
+    body: JSON.stringify(flags),
+  });
+}
+
 export interface NotificationLogQuery {
   page?: number;
   pageSize?: number;
   type?: NotificationType;
-  servicio?: NotificationServicio;
+  /** One or more servicios; omitted = the whole log. */
+  servicio?: NotificationServicio[];
   status?: NotificationStatus;
   view?: "sent" | "failed" | "skipped" | "all";
 }
@@ -1141,15 +1179,85 @@ export function listNotificationLog(
   if (q.page) qs.set("page", String(q.page));
   if (q.pageSize) qs.set("pageSize", String(q.pageSize));
   if (q.type) qs.set("type", q.type);
-  if (q.servicio) qs.set("servicio", q.servicio);
+  if (q.servicio?.length) qs.set("servicio", q.servicio.join(","));
   if (q.status) qs.set("status", q.status);
   if (q.view) qs.set("view", q.view);
   const tail = qs.toString();
   return apiFetch<NotificationLogPage>(`/notifications/log${tail ? `?${tail}` : ""}`);
 }
 
-export function getNotificationStats(): Promise<NotificationStats> {
-  return apiFetch<NotificationStats>("/notifications/stats");
+/** Where a setting's current value came from — shown so an operator can tell
+ *  "nobody has set this, you are seeing the deploy's value" from "somebody
+ *  set this on purpose". */
+export type SettingSource = "db" | "env" | "default";
+
+export interface NotificationAdminEmails {
+  value: string[];
+  source: SettingSource;
+  updatedAt: string | null;
+  updatedById: string | null;
+}
+
+export function getNotificationAdminEmails(): Promise<NotificationAdminEmails> {
+  return apiFetch<NotificationAdminEmails>("/notifications/settings/admin-emails");
+}
+
+export function setNotificationAdminEmails(
+  emails: string[],
+): Promise<NotificationAdminEmails> {
+  return apiFetch<NotificationAdminEmails>("/notifications/settings/admin-emails", {
+    method: "PUT",
+    body: JSON.stringify({ emails }),
+  });
+}
+
+/* ----------------------------------------------------- envío scheduling */
+
+/** The two automatic envíos, one per /notificaciones tab. */
+export type ScheduleKind = "servicios" | "polizas";
+
+export interface NotificationSchedule {
+  enabled: boolean;
+  /** Local hour/minute in America/Tijuana. */
+  hour: number;
+  minute: number;
+  /** 0 = domingo … 6 = sábado. Vacío = todos los días. */
+  weekdays: number[];
+}
+
+export interface ResolvedSchedule {
+  value: NotificationSchedule;
+  source: SettingSource;
+  updatedAt: string | null;
+  updatedById: string | null;
+  /** Expression the value compiles to, shown verbatim in the UI. */
+  cron: string;
+  nextRun: string | null;
+}
+
+export type NotificationSchedules = Record<ScheduleKind, ResolvedSchedule>;
+
+export function getNotificationSchedules(): Promise<NotificationSchedules> {
+  return apiFetch<NotificationSchedules>("/notifications/settings/schedule");
+}
+
+export function setNotificationSchedule(
+  kind: ScheduleKind,
+  schedule: NotificationSchedule,
+): Promise<ResolvedSchedule> {
+  return apiFetch<ResolvedSchedule>(`/notifications/settings/schedule/${kind}`, {
+    method: "PUT",
+    body: JSON.stringify(schedule),
+  });
+}
+
+export function getNotificationStats(
+  servicio?: NotificationServicio[],
+): Promise<NotificationStats> {
+  const tail = servicio?.length
+    ? `?servicio=${encodeURIComponent(servicio.join(","))}`
+    : "";
+  return apiFetch<NotificationStats>(`/notifications/stats${tail}`);
 }
 
 /** Build a download URL for a report's file output. The session cookie

apps/web/src/lib/labels.ts

@@ -393,13 +393,35 @@ export const NOTIFICATION_TYPE_LABELS: Record<NotificationType, string> = {
   PAYMENT_CONFIRMATION: "Confirmación de pago",
   ACCOUNT_STATUS: "Estado de cuenta",
   TRUST_PAYMENT_CONFIRMATION: "Confirmación fideicomiso",
+  RENEWAL_NOTICE: "Aviso de renovación",
 };
 
 export const NOTIFICATION_SERVICIO_LABELS: Record<NotificationServicio, string> = {
   CUSTOMERS: "Clientes",
   TRUST: "Fideicomiso",
+  POLICIES: "Pólizas",
 };
 
+/**
+ * The `level` column means something different per notification type, so it
+ * can only be read alongside one. ACCOUNT_STATUS uses it for the alert colour;
+ * RENEWAL_NOTICE for the aviso generation. Everything else leaves it null.
+ */
+export function notificationLevelLabel(
+  type: NotificationType,
+  level: number | null,
+): string {
+  if (level === null) return "";
+  if (type === "ACCOUNT_STATUS") return level === 0 ? " (amarilla)" : " (roja)";
+  if (type === "RENEWAL_NOTICE") {
+    if (level === 1) return " (1.º, 30 días antes)";
+    if (level === 2) return " (2.º, 15 días antes)";
+    if (level === 3) return " (3.º, 7 días después)";
+    return ` (aviso ${level})`;
+  }
+  return "";
+}
+
 export const NOTIFICATION_STATUS_LABELS: Record<NotificationStatus, string> = {
   SENT: "Enviado",
   FAILED: "Falló",
@@ -408,8 +430,8 @@ export const NOTIFICATION_STATUS_LABELS: Record<NotificationStatus, string> = {
 };
 
 export const NOTIFICATION_STATUS_COLORS: Record<NotificationStatus, string> = {
-  SENT: "#1f7a3a",
-  FAILED: "#b3261e",
-  SKIPPED_NO_EMAIL: "#666",
-  SKIPPED_GATE: "#888",
+  SENT: "var(--positive)",
+  FAILED: "var(--negative)",
+  SKIPPED_NO_EMAIL: "var(--muted)",
+  SKIPPED_GATE: "var(--muted-2)",
 };

apps/web/src/lib/types.ts

@@ -28,7 +28,8 @@ export type Ability =
   | "lookup:manage"
   | "user:manage"
   | "db:manage"
-  | "notification:send";
+  | "notification:send"
+  | "setting:manage";
 
 export interface AuthUser {
   id: string;

deploy/galactus/jorgecuadros-app.compose.yml

@@ -73,6 +73,25 @@ services:
       S3_BUCKET: ${S3_BUCKET:-jorgecuadros-documents}
       MINIO_ROOT_USER: ${MINIO_ROOT_USER:?MINIO_ROOT_USER must be set}
       MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD:?MINIO_ROOT_PASSWORD must be set}
+      # Outbound mail (SES). Runtime config — read at container boot, never
+      # baked into the image; the build does not send mail, this container
+      # does. Values arrive the same way DATABASE_URL does: as Gitea repo
+      # secrets, injected into this stack's env by the `env_data` block of
+      # .gitea/workflows/deploy-galactus.yml.
+      #
+      # The image sets NODE_ENV=production, which disables MailService's
+      # stdout dev fallback: leave these blank and every notification and
+      # renewal aviso fails with "El envío de correo no está configurado."
+      # rather than silently going nowhere.
+      SES_REGION: ${SES_REGION:-}
+      SES_FROM: ${SES_FROM:-}
+      SES_FROM_NAME: ${SES_FROM_NAME:-}
+      SES_ACCESS_KEY: ${SES_ACCESS_KEY:-}
+      SES_SECRET_KEY: ${SES_SECRET_KEY:-}
+      SES_CONFIGURATION_SET: ${SES_CONFIGURATION_SET:-}
+      # Who gets the per-job summary mail. Falls back to the two hardcoded
+      # defaults in NotificationsService when unset.
+      NOTIFICATION_ADMIN_EMAILS: ${NOTIFICATION_ADMIN_EMAILS:-}
     ports:
       - "${API_PORT:-3001}:3001"
     volumes:

deploy/jorgecuadros-app.env.example

@@ -33,8 +33,31 @@ S3_BUCKET=jorgecuadros-documents
 MINIO_ROOT_USER=jc_minio
 MINIO_ROOT_PASSWORD=CHANGE_ME
 
-SES_REGION=
-SES_FROM=
+# --- Outbound mail (Amazon SES) ----------------------------------------------
+# NOTE: for the Portainer-deployed stacks these do NOT come from a file on the
+# host — the deploy workflows build the stack env from Gitea repo secrets (see
+# the `env_data` blocks in .gitea/workflows/deploy*.yml). This file documents
+# the full variable set and is what you fill in for a hand-run stack.
+#
+# Either way they are RUNTIME config, read at container boot
+# (apps/api/src/mail/mail.service.ts) — never baked into the image.
+#
+# The production image sets NODE_ENV=production, which turns OFF the stdout dev
+# fallback. Leaving these blank does not silently swallow mail — every send
+# fails with "El envío de correo no está configurado.", and the failure is
+# recorded in the notification log. Fill them in before enabling any envío.
+#
+# SES_FROM must be a verified SES sending identity.
+SES_REGION=us-west-2
+SES_FROM=mail@jorgecuadros.com
+SES_FROM_NAME=Information Server
 SES_ACCESS_KEY=
 SES_SECRET_KEY=
+# Optional — only needed to publish bounce/complaint events.
 SES_CONFIGURATION_SET=
+
+# Recipients of the per-job summary email. NOW EDITABLE IN THE UI
+# (/notificaciones > Servicios > "Destinatarios del resumen", ADMIN only), so
+# this is only the fallback for a deployment where nobody has set it there.
+# A saved value takes precedence and this var is ignored from then on.
+NOTIFICATION_ADMIN_EMAILS=rmancinas@freakma.net,mpulido@freakma.net

deploy/jorgecuadros-app.stack.yml

@@ -55,11 +55,14 @@ services:
       S3_BUCKET: ${S3_BUCKET:-jorgecuadros-documents}
       MINIO_ROOT_USER: ${MINIO_ROOT_USER:?MINIO_ROOT_USER must be set}
       MINIO_ROOT_PASSWORD: ${MINIO_ROOT_PASSWORD:?MINIO_ROOT_PASSWORD must be set}
+      # Outbound mail (SES) — runtime config, not a build-time CI secret.
       SES_REGION: ${SES_REGION:-}
       SES_FROM: ${SES_FROM:-}
+      SES_FROM_NAME: ${SES_FROM_NAME:-}
       SES_ACCESS_KEY: ${SES_ACCESS_KEY:-}
       SES_SECRET_KEY: ${SES_SECRET_KEY:-}
       SES_CONFIGURATION_SET: ${SES_CONFIGURATION_SET:-}
+      NOTIFICATION_ADMIN_EMAILS: ${NOTIFICATION_ADMIN_EMAILS:-}
     ports:
       - target: 3001
         published: ${API_PORT:-3001}

docs/BACKLOG.md

@@ -0,0 +1,217 @@
+# Backlog — what is pending, missing, and not yet built
+
+One place for work that is known-outstanding. Compiled 2026-08-02 from
+`PLAN.md`, `RESUME.md`, the four specs and the two OCR docs, then **checked
+against the code and the dev database** rather than trusted — several items in
+those documents had already been closed, and two defects they describe are
+still live.
+
+This file is an index, not a replacement. Each item points at the document that
+carries the reasoning. Close an item *there* as well as here, or the two drift.
+
+**Verified against dev at compile time** (re-run before trusting the numbers):
+
+```
+policy_types: AUTO, LICENCIAS, MULT
+policies NULL policyTypeId: 5
+policies pending liquidación: 226
+customers: 1536
+last tag: v1.0.6 (2026-08-02 02:06 UTC) — 14 commits, 5 migrations behind HEAD
+```
+
+---
+
+## 0. Ship-blocked — read before the next deploy
+
+**Everything from the notificaciones arc is unreleased.** `v1.0.6` predates it.
+Five migrations are waiting:
+
+```
+20260801120000_ocr_batch_discarded
+20260801130000_renewal_email_notifications
+20260801200000_mass_email_notifications
+20260802120000_renewal_notices_unified_log
+20260802140000_app_settings
+```
+
+Plus three backup-pipeline fixes that have never reached prod (`860d483`,
+`567b033`, `898cf48` — the last prod run went green through the whole chain and
+died on the final step wanting `deploy/.env.prod`).
+
+> ### `SES_*` secrets created in Gitea 2026-08-02 — unblocked, unverified
+>
+> The variables were wired through both deploy workflows and the app stack but
+> had never been set. **They now exist.** What that clears: the production
+> image runs `NODE_ENV=production`, which disables the stdout dev fallback, so
+> a blank config made every send fail and log `FAILED` — and the pólizas sweep
+> defaults to **enabled, 06:00 America/Tijuana**, so the failure would have
+> repeated nightly.
+>
+> **Not yet confirmed, and the first deploy is what confirms it:**
+>
+> 1. **Names match.** The preflight checks `SES_REGION`, `SES_FROM`,
+>    `SES_ACCESS_KEY`, `SES_SECRET_KEY` and warns by name if any is blank —
+>    read that warning on the next run. No `_GALACTUS` suffix on any of them;
+>    one SES identity serves every deployment.
+> 2. **`SES_FROM` is a verified identity in `SES_REGION`.** An unverified
+>    sender is rejected per-send, which looks identical to a missing config in
+>    the log.
+> 3. **The AWS account is out of the SES sandbox.** This is the one that would
+>    hurt: in sandbox, SES only delivers to *verified* recipients, so a renewal
+>    sweep across 815 policyholders would fail almost every send while the
+>    config looks entirely correct. Check before letting a real sweep run.
+>
+> Until 2 and 3 are confirmed, run the first sweep with `debug` on — it diverts
+> every recipient to the override inbox, and on the pólizas side it also leaves
+> the avisos pending, so nothing is consumed by a failed test. See
+> [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md) "Send flags".
+
+Also outstanding on the deploy path: every pre-existing database still needs
+its one-time `prisma migrate resolve --applied 0000_init`.
+
+---
+
+## 1. Blocked on a decision from Jorge
+
+Nothing here is a build problem. Each one makes the work either impossible or a
+guess.
+
+| # | Question | Blocks | Source |
+|---|---|---|---|
+| 1.1 | What "garantías" refers to | §2 liquidación's exclusion filter | INSURANCE §2 |
+| 1.2 | What "Solicitud Atlas" is — application form or certificate | §3 entirely | INSURANCE §3 |
+| 1.3 | Carrier API **direction**: outbound quote/issue (ANA supports today) or inbound portfolio sync (no evidence either carrier offers it) | whether §4 is buildable at all | INSURANCE §4 |
+| 1.4 | CFE amount: the rounded barcode figure (`$268`, what is paid at the window) or the exact breakdown total (`$268.88`) | the parser currently takes the barcode | STATEMENT_OCR / RECEIPT §2 |
+| 1.5 | The Seguros USD bank's name, currency and details | multi-bank is built; that account does not exist yet | RECEIPT §3 |
+| 1.6 | Recycling triggers — exact "1 year inactive" / "cancelled" definitions, and whether recycling ever means true data purge | §4 recycling | RECEIPT §4 |
+| 1.7 | Notice body in Spanish or English | `Customer` carries no language preference | INSURANCE §1 |
+| 1.8 | How to model `TRASPASOS PAYPAL` — a clearing account, not a customer, carrying −7.03M MXN over 309 movements and therefore topping the adeudo worklist | deliberately not special-cased in code | RESUME §6 |
+| 1.9 | The 78 policyholders with no email — skip silently or produce a print worklist | recommendation is the worklist | INSURANCE §1 |
+
+1.3 also needs the practical half: WSDL + credentials for
+`server.anaseguros.com.mx/ananetws/service.asmx`, whether a cartera download
+exists for an agent's own book, whether GMX daños has any machine interface at
+all, and whether one Grupo Valore credential spans both carriers. All four go
+in the same phone call — (55) 5480-4000.
+
+---
+
+## 2. Live data defects — open, and confirmed open today
+
+### 2.1 `policy_types` is missing `INCENDIO` and `M_EMPR`, and 5 policies are orphaned
+
+`policyTypeId` is `String?` with a plain relation, so Prisma's default is
+`SetNull`. The spec's recommended `onDelete: Restrict` was **never applied**.
+Five `m_empr` policies lost their ramo; four of them are pending liquidación
+and are invisible to every ramo-filtered query — including the pending report
+§2 is supposed to produce.
+
+Fix alongside the liquidación work (3.1), since it distorts that feature's own
+report. Source: INSURANCE "Two defects found while verifying this spec".
+
+### 2.2 ≤41 MULT second settlements were dropped in migration
+
+`MULT`/`INCENDIO` carry two settlement slots and `M EMPR` carries four; `Policy`
+collapses to one. Spec recommends moving settlement onto
+`PolicyPaymentInstallment` rather than adding a second slot. Open sub-question:
+whether to backfill the lost rows.
+
+### 2.3 Three dead tables
+
+`EmailTemplate`, `EmailCampaign` and `EmailLog` exist in the schema with
+**zero references anywhere in `apps/api/src` or `apps/web/src`**. They were
+scaffolded for plan step 10's "email campaigns"; notificaciones shipped against
+`email_notification_log` instead. Either wire them or drop them — a schema that
+carries tables nothing writes teaches the next reader the wrong thing.
+
+---
+
+## 3. Spec'd, not built
+
+| # | Item | State | Source |
+|---|---|---|---|
+| 3.1 | **Liquidación batch workflow** | ~70% of the fields already wired end to end. **226 policies pending.** Needs the ramo-parameterized pending report + `POST /policies/liquidate-batch` under a new `policy:liquidate` (MANAGER). Smallest remaining piece of step 12 | INSURANCE §2 |
+| 3.2 | **Certificate rendering** | The report half is buildable now off the same `format: "letter"` machinery as `aviso-renovacion`. Portal delivery waits on steps 8/9. Whole section waits on 1.2 | INSURANCE §3 |
+| 3.3 | **Carrier API integration** | Blocked on 1.3. ANA's SOAP service is real with a known operation list; GMX publishes nothing machine-readable and writes the larger half of this book | INSURANCE §4 |
+| 3.4 | **Customer-number recycling** | Not started. `Customer.customerNumber` **does not exist in the schema**. Backfill needs care: ~140 utilities rows and all insurance-only customers carry synthetic `rownum_N`/`insrow_N` placeholders, not real `NUM id`s. Last unbuilt piece of step 11 | RECEIPT §4 |
+
+Note 3.3 partly overlaps what [`POLICY_OCR.md`](POLICY_OCR.md) already does —
+an OCR path that turns a carrier PDF into a `Policy` row covers some of what
+the API was wanted for, and unlike the API it is not waiting on a phone call.
+
+---
+
+## 4. Roadmap steps with no spec
+
+| # | Item | State |
+|---|---|---|
+| 4.1 | **Step 8 — VPS provisioning** | Not started. Provider undecided (Hetzner vs DigitalOcean), size, Tailscale + MySQL replica. Pure ops; the design is settled. RESUME calls this *the only genuinely blocking item left on the roadmap* |
+| 4.2 | **Step 9 — sync worker** | Not built. Unblocked now that `utility_dbo` and the portal code are on disk, but depends on 4.1. Portal write points to poll: `peticion_gas`, PayPal payments, `notifications_settings`, `verification_codes` |
+| 4.3 | **Step 10 — reports / campaigns / admin** | Mostly done by other work. `/reportes` exists; "email campaigns" landed as `/notificaciones` against a different table (see 2.3) |
+| 4.4 | **Phase B sync in production** | Verified 32/32 against dev, never run from the `/operaciones` UI (the `OpsService` path) nor against a prod-shaped database |
+
+---
+
+## 5. Gaps in features that already shipped
+
+Each of these is a known, deliberate stopping point rather than a bug.
+
+**Notificaciones** — [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md)
+- No multi-replica lock on the servicios sweep (pólizas has one via
+  `scheduled_job_states`). Safe only while the deployment stays single-replica.
+- No per-recipient preview of a sent body in the UI.
+- No SNS bounce/complaint webhook. `providerMessageId` is captured so one can
+  be added.
+- No `SKIPPED_NO_EMAIL` worklist (see 1.9).
+
+**Policy OCR** — [`POLICY_OCR.md`](POLICY_OCR.md)
+- **GMX only.** The dispatcher is a `[provider, pattern]` table plus a parser
+  map, so a second carrier is one function and two entries — but no other
+  layout has been seen, and guessing produces a parser nobody can verify.
+- **The `recibo` PDF is unread.** The GMX certificate carries no premium at
+  all; reading the separate receipt and pairing it to its certificate is what
+  would let `postPremium` stop being a manual tick.
+- **No versioning.** A re-issued policy arrives as a new certificate with the
+  same number and confirm updates the existing row. Nothing records that this
+  is the 2027 issue of that policy.
+
+**Statement OCR** — [`STATEMENT_OCR.md`](STATEMENT_OCR.md)
+- **CFE / CESPT / Telnor have no unit suite.** They predate the gas/predial
+  extension and were verified end to end against the 46-page corpus only.
+  Close this if those parsers are ever touched.
+- No way to re-run a corrected parser over a stored batch, though the source
+  PDFs are kept precisely so it is possible.
+- Handwritten folder numbers are deliberately not an input to matching
+  (Tesseract read `405` as `205`).
+
+**Bank** — the concept→ramo classifier is **won't-build**, not pending.
+`concepto` is a payee name (0 of 22,354 match a category) and TABLA RAMODOS is
+a property-management expense chart, not the business-line split it was assumed
+to be. `/banco` intentionally has no category dimension. Recorded here only
+because `bank_transactions.categoryId` being null on every row otherwise reads
+as unfinished work.
+
+---
+
+## 6. Security / hygiene
+
+- **The old repo's `dbConnection.php` has a plaintext MySQL password committed
+  to git history.** Not carried into this platform, but the credential is
+  already exposed and has not been rotated. Rotate regardless of this repo.
+- The pre-migrate backup step sets `NODE_TLS_REJECT_UNAUTHORIZED=0` because
+  Portainer serves a self-signed certificate. Scoped to that one step; the real
+  fix is replacing the certificate.
+
+---
+
+## Source documents
+
+| Document | What it carries |
+|---|---|
+| [`../PLAN.md`](../PLAN.md) | build sequencing, locked decisions, per-step status |
+| [`../RESUME.md`](../RESUME.md) | session history and §6 open items |
+| [`INSURANCE_FEATURES_SPEC.md`](INSURANCE_FEATURES_SPEC.md) | §1 renewal emails (built), §2 liquidación, §3 certificate, §4 carrier APIs |
+| [`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md) | §1 Editor (built), §2 OCR (built), §3 multi-bank (built), §4 recycling |
+| [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md) | mass email + schedules, as built |
+| [`STATEMENT_OCR.md`](STATEMENT_OCR.md) · [`POLICY_OCR.md`](POLICY_OCR.md) | the two OCR intakes, as built |
+| [`DEPLOY_AND_MIGRATIONS.md`](DEPLOY_AND_MIGRATIONS.md) | release chain, galactus, known caveats |

docs/DEPLOY_AND_MIGRATIONS.md

@@ -325,3 +325,20 @@ backup does them (see `deploy/scripts/pre-migrate-backup.mjs`):
 - `bootstrap: true` lets the pre-migrate backup be skipped when no API container
   exists yet. Use it for a first-ever deploy only — it is the one switch that
   lets a migration run with no restore point.
+- **The API container sends mail on a timer.** Two sweeps run inside it
+  (renewal avisos, on by default at 06:00 America/Tijuana; the servicios
+  run-all, off by default) — see
+  [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md). Two
+  consequences for deploys: the cadence lives in `app_settings`, so it
+  **survives a redeploy and is not restored by rolling back an image**, and
+  running more than one API replica would double-fire the servicios sweep,
+  which has no DB lock (the pólizas one does). Keep it single-replica.
+- `SES_*` is optional to deploy — the preflight only warns — but the production
+  image sets `NODE_ENV=production`, which disables the stdout dev fallback. A
+  blank SES config therefore makes every send fail and log `FAILED`. The
+  secrets were created 2026-08-02; the preflight warning on the next run is
+  what confirms the names are right. Two things it cannot check: that
+  `SES_FROM` is a **verified identity** in `SES_REGION`, and that the account
+  is **out of the SES sandbox** (in sandbox, delivery is restricted to verified
+  recipients, which would fail a real sweep while looking correctly
+  configured).

docs/INSURANCE_FEATURES_SPEC.md

@@ -11,6 +11,15 @@ Companion doc: [`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md) covers the
 Utility Management half of the same meeting (PLAN.md step 11). This doc is the
 insurance half (PLAN.md step 12).
 
+> **A fifth insurance feature exists that this spec never proposed.**
+> [`POLICY_OCR.md`](POLICY_OCR.md) — OCR capture of carrier policy PDFs into
+> `Policy` rows, built 2026-08-01. It came out of the *utility* statement OCR
+> work in [`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md) §2, not from
+> this meeting, which is why it is documented on its own rather than folded in
+> here. It is relevant to §4: an OCR path that turns a carrier PDF into a
+> `Policy` row already covers part of what a carrier API was wanted for, and
+> unlike the API it is not blocked on Grupo Valore returning a phone call.
+
 ## Why these four features are one spec
 
 The meeting produced four insurance asks. They are specified together because
@@ -199,6 +208,35 @@ recycling backfill that consulted `UTILSEG` would merge unrelated people.
 
 ## 1. Renewal notification emails
 
+> **BUILT — 2026-08-01, extended 2026-08-02.** `apps/api/src/renewals/`
+> (sweep, `sendOne`, the `scheduled_job_states` lock) plus
+> `apps/api/src/mail/` (SES). Web: the **Pólizas** tab of `/notificaciones`;
+> `/renovaciones` is an alias that lands on it. Ability `renewal:send`
+> (MANAGER), as specced.
+>
+> Three things in the sections below were **superseded**, each noted inline:
+>
+> - **§1.1** — the `@Cron("0 6 * * *")` literal is gone. Both this sweep and
+>   the servicios jobs take their cadence from `NotificationScheduleService`,
+>   which stores it in `app_settings` and reinstalls the job on save. The
+>   default is still 06:00 daily, so behaviour is unchanged until an operator
+>   edits it. See [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md),
+>   "Scheduled runs".
+> - **§1.4 manual mark-as-sent — dropped, deliberately.** Sending from the
+>   list is what marks a notice sent; there is no way to claim a letter went
+>   out when no mail was sent. `RenewalNoticeChannel.MAIL` still exists for a
+>   future paper path, but nothing writes it.
+> - **The send log is not renewal-specific.** Every attempt — including the
+>   failures and no-email skips a `RenewalNotice` row cannot represent — also
+>   writes `email_notification_log` as `RENEWAL_NOTICE` / `POLICIES`, shared
+>   with the four bulk jobs. `RenewalNotice` stays the *gating* state; the log
+>   is *history*.
+>
+> Also added 2026-08-02: the platform-wide `debug` flag reaches this path. A
+> debug send diverts the mail, skips the `RenewalNotice` upsert **and** does
+> not advance `lastSuccessfulAt` — see that doc's "Send flags" for why all
+> three are required together.
+
 ### What Jorge asked for
 
 Automatic notice to the customer at **30 days before expiry, 15 days before,
@@ -223,6 +261,13 @@ and 7 days after** — replacing the manual monthly run of the legacy
 
 ### 1.1 The scheduler
 
+> **Superseded — the cadence is operator-editable, not a literal.**
+> `RenewalsService` registers its handler with `NotificationScheduleService`
+> in `onModuleInit`; that service compiles the stored
+> `{hour, minute, weekdays}` to a cron expression and installs it in
+> `SchedulerRegistry`. Default `0 6 * * *` / `America/Tijuana`, i.e. exactly
+> what the literal below did. The rest of this section still holds.
+
 Add `@nestjs/schedule`. One `@Cron` job, daily, early morning local time.
 
 ```
@@ -302,6 +347,12 @@ traced back to the notice that caused it. (`notes` stays free-text for staff.)
 
 ### 1.4 Manual mark-as-sent
 
+> **Not built, and deliberately so.** A button that marks a notice sent
+> without sending anything is a button that lets the list claim a customer
+> was told when they were not — the exact failure the log exists to make
+> visible. `POST /renewals/send` replaced it: sending *is* the marking.
+> Revisit only when a real paper-mail workflow exists to record.
+
 The `aviso-renovacion` doc comment (`reports.registry.ts:617-621`) already
 anticipates this: staff who *mail* a paper notice need to record it.
 `RenewalNoticeChannel` (`MAIL` | `EMAIL`) exists for exactly this distinction.
@@ -321,12 +372,19 @@ customer to stop the mail.
 
 ### API surface
 
+As built (the `/policies/:id/renewal-notices` mark-as-sent mutation was
+dropped — see §1.4):
+
 | Method | Route | Ability |
 |---|---|---|
-| `POST` | `/policies/:id/renewal-notices` | `renewal:send` |
-| `POST` | `/renewals/sweep` (manual trigger of the cron body) | `renewal:send` |
+| `POST` | `/renewals/sweep` (manual trigger of the scheduled body; body `{ debug? }`) | `renewal:send` |
+| `POST` | `/renewals/send` (one notice; body `{ policyId, generation, debug? }`) | `renewal:send` |
 | `GET` | `/renewals/pending?days=` (what the next sweep would send) | read (AuthenticatedGuard) |
 
+The cadence itself is edited through the notifications module
+(`GET`/`PUT /notifications/settings/schedule[/:kind]`, `setting:manage`),
+because one editor covers both sweeps.
+
 ### Abilities (new)
 
 | Ability | Min role | Notes |
@@ -706,9 +764,8 @@ equivalent is `InsuranceProvider`, which today holds only a name.
 
 ## Build sequencing
 
-1. **§1 renewal emails** — highest value, schema already ready, no blocker
-   beyond the SES sending account. ≈260 mails/month against a 91%-reachable
-   policyholder base.
+1. ~~**§1 renewal emails**~~ — **DONE 2026-08-01/02.** See §1's BUILT note.
+   ≈260 mails/month against a 91%-reachable policyholder base.
 2. **§2 liquidación batch** — small, builds on fields already wired. Do the two
    defect fixes (missing `policy_types` rows + FK `ON DELETE RESTRICT`) as part
    of it, since both distort its own report.
@@ -739,11 +796,18 @@ No collision with the abilities proposed in `RECEIPT_CAPTURE_SPEC.md`
 
 ## Open questions to take back to Jorge (collected)
 
-**§1 — renewal emails**
-- Which SES region + verified identity/configuration set, and whether to reuse
-  existing IAM credentials or create a scoped `ses:SendEmail` user.
+**§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.~~
+  **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? (Recommend the worklist.)
+  worklist? Currently they are **logged as `SKIPPED_NO_EMAIL`** in
+  `email_notification_log` — visible in "Registro de envíos", but not yet a
+  printable worklist. (Recommend the worklist.)
 - Spanish or English notice body?
 
 **§2 — liquidación**

docs/MASS_EMAIL_NOTIFICATIONS.md

@@ -32,11 +32,16 @@ feature ports the four jobs onto the unified data and writes its own log.
   `payment-confirm`, `account-status`, `trust-confirm`), each a public
   service method + a `POST /notifications/{slug}` HTTP endpoint gated on
   the new `notification:send` ability (MANAGER).
+- `apps/api/src/notifications/notification-schedule.service.ts` (+ its own
+  module) — the cadence of **both** automatic sweeps, stored in
+  `app_settings` and installed into `SchedulerRegistry` at boot. See
+  "Scheduled runs" below.
 - `packages/database/prisma/migrations/20260801200000_mass_email_notifications/migration.sql`
   — two new tables (`email_notification_log`, `account_status_history`)
   with enums and FKs to `customers`.
-- `apps/web/src/app/notificaciones/` — admin page with 4 trigger cards,
-  a flags panel, a transport-status header, and a paginated log browser.
+- `apps/web/src/app/notificaciones/` — admin page: a shared flags panel and
+  schedule editor above the tabs, then per-tab trigger cards, a
+  transport-status header, and a paginated log browser.
 
 ## Job semantics
 
@@ -82,6 +87,36 @@ reported per-customer, never collapsed (see `BillingService.balances()`).
 `useEmailLimit=true` enables a vestigial throttle: pause the sweep 1h
 after 100 sends. Off by default; SES does not need it.
 
+## Send flags
+
+The three flags are **platform-wide**, not per-tab. They live in the
+`/notificaciones` shell above the tabs (`NotificationFlagsCard`), and the
+shell passes them to both halves.
+
+| Flag | Applies to | Effect |
+|---|---|---|
+| `debug` | everything | Rewrites every recipient to `DEBUG_RECIPIENT` (`rmancinas@freakma.net`), tags the log row `debug: true`, sends with `xTracking: "debug"`. |
+| `ignoreDayRestriction` | Job 3 only | Bypasses the Wed / Mon-Wed-Fri gates. |
+| `useEmailLimit` | Job 3 only | The vestigial throttle above. |
+
+`debug` used to exist only on the servicios side, which meant there was no
+way to test a renewal aviso without mailing a real customer. On the pólizas
+path it now does three things beyond diverting the mail, all for the same
+reason — *the customer was not notified, so nothing may claim they were*:
+
+1. no `RenewalNotice` row is written, so the aviso stays in the pending list;
+2. the sweep's `lastSuccessfulAt` is not advanced, because `renewalWindow()`
+   uses it to widen the window over missed days — advancing it after a test
+   run would narrow tomorrow's window and drop those candidates for good;
+3. the send response carries `debug: true` and the address actually used, so
+   the UI says "prueba enviada … el cliente no ha recibido nada" rather than
+   claiming a delivery.
+
+Flags are **per-visit UI state and are never persisted.** A stored `debug`
+would survive a reload and silently swallow real customer mail for as long
+as nobody noticed. For the same reason the automatic runs below ignore them
+entirely and always send for real.
+
 ## Tables
 
 ### `email_notification_log`
@@ -93,6 +128,24 @@ correlation.
 
 Indexes: `(sendDate)`, `(notificationType, sendDate)`, `(customerId, sendDate)`.
 
+**This table is not job-specific.** Insurance renewal avisos
+(`RenewalsService`, see [`RENEWAL_NOTICES.md`](RENEWAL_NOTICES.md)) write
+here too, as `notificationType = RENEWAL_NOTICE` /
+`servicio = POLICIES` — one send history for the whole platform rather
+than one per feature. `NotificationLogService` is the only writer;
+anything that sends mail goes through it.
+
+`level` is therefore per-type and cannot be read without its
+`notificationType`: 0/1 (yellow/red) on `ACCOUNT_STATUS`, the aviso
+generation 1/2/3 on `RENEWAL_NOTICE`, null elsewhere. On the web side
+`notificationLevelLabel()` is the only place that branch lives.
+
+Renewals keep their own `renewal_notices` row as well. The two are not
+redundant: `renewal_notices` is *gating* state (one row per
+policy+generation, "already notified" — it drives the pending list),
+while this log is *history* (every attempt, including the failures and
+no-email skips a gating row cannot represent).
+
 ### `account_status_history`
 
 Mirrors the legacy `utility_dbo.send_account_status_history` table:
@@ -113,28 +166,164 @@ SES_SECRET_KEY=...
 SES_FROM=mail@jorgecuadros.com
 SES_FROM_NAME=Information Server
 SES_CONFIGURATION_SET=...      # optional
-NOTIFICATION_ADMIN_EMAILS=rmancinas@freakma.net,mpulido@freakma.net
+NOTIFICATION_ADMIN_EMAILS=rmancinas@freakma.net,mpulido@freakma.net  # fallback only
 ```
 
+`NOTIFICATION_ADMIN_EMAILS` is no longer the source of truth. The summary
+recipients are edited in the UI and stored in `app_settings`; the env var
+is the fallback for a deployment where nobody has saved them yet. See
+"Operator settings" below.
+
 Without SES_* the API still boots and `MailService` falls back to stdout
 in dev (`NODE_ENV !== "production"`). In production every send throws
 `ServiceUnavailableException` and the row is recorded as `FAILED`.
 
+These are **runtime** config — read at container boot, never baked into the
+image. For the Portainer deployments they are set as **Gitea repo secrets**
+and injected into the stack env by the `env_data` block of
+`.gitea/workflows/deploy-galactus.yml` (and `deploy.yml`), exactly like
+`DATABASE_URL` and `SESSION_SECRET`. Unlike most secrets there they carry no
+`_GALACTUS` suffix: one SES identity serves every deployment.
+
+They are optional to *deploy* — the preflight only warns — but the
+production image sets `NODE_ENV=production`, which disables the stdout dev
+fallback, so a blank SES config makes every send fail loudly rather than
+quietly going nowhere.
+
 ## UI
 
-`/notificaciones` (gated on `notification:send`) — four trigger cards,
-a debug/ignoreDayRestriction/useEmailLimit flags panel, a transport
-status header, and a paginated log table. STAFF users see the log
-read-only.
+`/notificaciones`, two tabs over the one log.
 
-## Cron (future)
+Above the tabs, owned by the shell because both halves are subject to them:
 
-The four service methods (`runOutstandingPayments`, `runPaymentConfirmation`,
-`runAccountStatus`, `runTrustConfirmation`) are the entry points. A future
-`@nestjs/schedule` cron would call them on the legacy cadence (Job 3 on
-Mon/Wed/Fri, Job 2 daily, Jobs 1 + 4 ad-hoc). Pattern matches
-`OpsService`'s single-running-job guard: one `email_notification_sweep`
-OpsJob per run, with its log streamed to `OpsJob.log`.
+- **Flags del envío** — the three flags above.
+- **Programación de envíos** — the cadence of both automatic sweeps
+  (`setting:manage` to edit; everyone can see when the next run is).
+
+Then per tab:
+
+- **Servicios** (`notification:send`) — an "Ejecutar todos" card, four
+  trigger cards, a transport status header, and the summary-recipients
+  setting. Reads the `CUSTOMERS` + `TRUST` slice.
+- **Pólizas** (`renewal:send`) — pending avisos and the manual sweep.
+  Reads the `POLICIES` slice.
+
+Both render the same `NotificationLogPanel` ("Registro de envíos"), which
+filters by servicio and by view (todos / enviados / fallidos / omitidos).
+STAFF users see the Servicios log read-only.
+
+Both mass actions ("Ejecutar todos" and the pólizas sweep) confirm before
+firing **only when `debug` is off** — that is the case where real customers
+receive mail, and a confirm on every click trains people to dismiss it.
+
+## API surface
+
+| Method | Route | Ability |
+|---|---|---|
+| `POST` | `/notifications/outstanding-payments` | `notification:send` |
+| `POST` | `/notifications/payment-confirmation` | `notification:send` |
+| `POST` | `/notifications/account-status` | `notification:send` |
+| `POST` | `/notifications/trust-payment-confirmation` | `notification:send` |
+| `POST` | `/notifications/run-all` | `notification:send` |
+| `GET` | `/notifications/log`, `/notifications/stats` | authenticated |
+| `GET` | `/notifications/settings/admin-emails` | authenticated |
+| `PUT` | `/notifications/settings/admin-emails` | `setting:manage` |
+| `GET` | `/notifications/settings/schedule` | authenticated |
+| `PUT` | `/notifications/settings/schedule/:kind` | `setting:manage` |
+
+Every trigger accepts the flags as **body or query string** — the PHP
+scripts took both (STDIN vs HTTP-CGI) and parity was cheap. The pólizas
+endpoints (`POST /renewals/sweep`, `POST /renewals/send`) accept `debug`
+only; the other two flags are estado-de-cuenta concepts and are not
+accepted there rather than being silently ignored.
+
+## Operator settings
+
+`app_settings` holds the configuration staff change without a redeploy.
+`SettingsService` resolves every key **db → env → default**, and reports
+which of the three a value came from so the UI can say so. Adding a key
+means adding a typed accessor there, not a generic getter.
+
+Keys today:
+
+| Key | Edited on | Notes |
+|---|---|---|
+| `notification.adminEmails` | Servicios tab | Summary recipients, comma-separated. |
+| `notification.schedule.servicios` | shell | JSON cadence of the automatic run-all. |
+| `notification.schedule.polizas` | shell | JSON cadence of the renewal sweep. |
+
+All three are gated on `setting:manage` (ADMIN — above `notification:send`,
+because redirecting the audit summaries is how someone would stop them being
+read).
+
+`notification.adminEmails` is read on every job rather than cached, so an
+edit takes effect on the next sweep with no restart. An empty saved list
+means "nobody" and deliberately does **not** fall through to the env.
+
+The two schedule keys have **no env rung** on the db → env → default ladder:
+a cadence was never an environment variable (it was a `@Cron` literal in the
+source), so the only two sources are the operator's row and the shipped
+default. A row that fails to parse is logged and treated as absent — a bad
+JSON blob must not take the scheduler down with it.
+
+Credentials do not belong here. SES keys, `DATABASE_URL` and S3 config stay
+in the environment: they are deployment identity, they must exist before
+the app can reach its own database, and a table only widens who can read
+them.
+
+## Scheduled runs
+
+Both halves run themselves on an **operator-editable** cadence. Nothing
+about the schedule is in the source any more:
+
+| Kind | Handler | Default | Was |
+|---|---|---|---|
+| `servicios` | `NotificationsService.scheduledRunAll()` → all four jobs in order | **off**, 07:00 Mon/Wed/Fri when enabled | nothing — the four jobs were click-only |
+| `polizas` | `RenewalsService.scheduledSweep()` | **on**, 06:00 daily | `@Cron("0 6 * * *")` in `renewals.service.ts` |
+
+The defaults preserve exactly what each half did before: pólizas keeps its
+06:00 sweep, servicios stays off. A default that starts mailing 260
+customers on its own after a deploy is not a default, it's an incident.
+
+### How it works
+
+`NotificationScheduleService` owns both cadences. The services that own the
+sweeps register a handler in `onModuleInit`:
+
+```ts
+await this.schedule.register("polizas", () => this.scheduledSweep());
+```
+
+The schedule service then compiles the stored value to a cron expression
+(`{hour, minute, weekdays}` → `m h * * dow`, empty weekdays = `*`) and
+installs a `CronJob` in `SchedulerRegistry` under
+`notification-schedule:<kind>`, in `America/Tijuana`. Saving from the UI
+re-reads the row, removes the old job and installs the new one — **no
+restart**, which was the whole point.
+
+Handlers are registered rather than injected because
+`NotificationsModule` and `RenewalsModule` both need this service and
+neither may import the other. It lives in its own
+`NotificationScheduleModule` for the same reason as
+`NotificationLogModule`.
+
+`cron` is a **direct dependency of `apps/api`**, not just a transitive one
+of `@nestjs/schedule`: pnpm's strict layout does not hoist it, so
+`import { CronJob } from "cron"` fails to resolve without it.
+
+### What a scheduled run does not do
+
+- **It never uses the UI flags.** No `debug` (so a forgotten test toggle
+  cannot silently stop customer mail), and no `ignoreDayRestriction` — an
+  automatic run on the operator's own cadence is exactly the case the
+  Mon/Wed/Fri gate was written for, so bypassing it would mail the red list
+  every scheduled day.
+- **It does not guard against multi-replica double-fire.** The pólizas sweep
+  has always had its own DB lock (`scheduled_job_states`, taken in
+  `RenewalsService.acquireLock`); the servicios run-all has no equivalent
+  and relies on the deployment being single-replica, which it is today on
+  galactus. Adding one means the `OpsService` single-running-job pattern —
+  a DB row, not an in-process flag.
 
 ## What is intentionally NOT in scope
 

docs/POLICY_OCR.md

@@ -0,0 +1,248 @@
+# Insurance Policy OCR Capture
+
+Reads an insurance policy PDF the office downloads from a carrier portal,
+proposes the `Policy` row it should become, and lets staff confirm. Built
+2026-08-01 (`5e9cb12`), live under `/polizas/captura`.
+
+## Why this exists — it was not planned
+
+This feature is **not in any spec**. It came out of building the utility
+statement OCR intake in [`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md)
+§2: once there was a working render → OCR → parse → match → review pipeline
+for CFE/CESPT/Telnor receipts, it was obvious the same shape applies to the
+*other* stack of paper this office keys in by hand every week — the carrier
+policy PDFs behind every `Policy` row.
+
+The two are the same job with a different document on the scanner. Keeping
+that recognition cheap is the whole point of how it was built: the pipeline
+was **reused, not copied**.
+
+- `OcrModule` (`apps/api/src/ocr/ocr.module.ts`) was extracted out of
+  `StatementsModule` in this same commit, purely so `PolicyOcrModule` can
+  inject `OCR_PROVIDER` without dragging in the statement pipeline.
+  `StatementsModule` now imports it and binds nothing itself. That extraction
+  was **blocking**: without it the policy module could not resolve the
+  provider at all.
+- The engine stays Tesseract behind the same swappable seam, so a managed
+  extraction API remains a one-line change in one file for both features.
+- The intake screen is a *mode of* the existing policy-creation screen, the
+  same way OCR receipt capture is a mode of Captura — not a new menu entry.
+
+## What ships
+
+| Piece | Path |
+|---|---|
+| API module | `apps/api/src/policy-ocr/` (service, controller, DTOs, matcher, parser) |
+| Shared OCR seam | `apps/api/src/ocr/ocr.module.ts` |
+| Tables | `policy_ocr_batches`, `policy_ocr_documents` (`20260801000000_policy_ocr_intake`) |
+| Web | `components/PolicyCaptura.tsx` (tab shell), `PolicyOcrIntake.tsx` (upload), `PolicyOcrReview.tsx` (review queue) |
+| Abilities | `policy:ingest`, `policy:ocr-review` — both **STAFF** |
+
+Abilities are STAFF for the same reason statement OCR is: nothing reaches the
+books unconfirmed, and the review step is what makes machine capture safe at
+that tier.
+
+## The screen
+
+`PolicyCaptura` is one screen with two ways in, mirroring `Captura.tsx`:
+
+- `/polizas/nuevo` → **manual** tab (`PolicyForm`, every field by hand)
+- `/polizas/captura` → **automática** tab (`PolicyOcrIntake`, drop a PDF)
+- `/polizas/captura/[id]` → the batch review queue
+
+Both modes end at the same place — a `Policy` row on a customer's file — so
+they are modes of one screen rather than two menu entries. Either URL renders
+the same component, so the tab toggle works from either entry point and old
+bookmarks land on the right tab.
+
+## Pipeline
+
+```
+upload PDF → store source → render pages → text layer? → parse → match → review → confirm
+```
+
+1. **Store the source.** `policy-ocr/{batchId}/source-N.pdf`, before anything
+   else touches it.
+2. **Render + read.** Every page is rendered to
+   `policy-ocr/{batchId}/page-M.png`. Text-layer wins when the PDF has one
+   (cheap, exact); the rendered image is OCR'd only when it does not — the
+   same precedence rule as the statement pipeline. Carrier-portal PDFs are
+   usually born-digital, so most of the time no OCR runs at all.
+3. **Parse.** Provider detected by brand signal first
+   (`GMX`, `Grupo Mexicano de Seguros`, `gmx.com.mx`,
+   `JUNTOS EL RIESGO ES MENOR`), layout patterns only as fallback — the same
+   ordering rule the statement parser needed.
+4. **Match.** Against `Policy.policyNumber`.
+5. **Review + confirm.** Nothing is written to `Policy` until a human
+   confirms.
+
+### One PDF = one policy
+
+This is the sharpest difference from statement OCR, and it inverts that
+feature's core assumption.
+
+Utility statements arrive **bundled, one customer per page** — so there, one
+page is one document and the parser runs per page. A policy PDF is the
+opposite: the GMX certificate is a 2-page document where page 1 carries the
+contract header and page 2 carries the per-coverage table, and **both pages
+describe the same policy**. So the pipeline concatenates every page's text
+(`\n\n` between pages, which also keeps `ocrRawText` readable for debugging)
+and runs the parser and the matcher exactly **once per file**.
+
+Consequences worth knowing before touching this code:
+
+- `PolicyOcrDocument.pageNumber` is repurposed as the **file ordinal within
+  the batch** (1, 2, 3…), not a page index. The
+  `(batchId, pageNumber)` unique constraint still holds, and one batch still
+  carries many policies — one per uploaded file.
+- Parser regexes are anchored across the whole concatenated text (`^From$`,
+  `^Currency\s+…`), which is why the page-boundary blank line matters.
+- `ocrConfidence` on the row is the **mean** across the file's pages.
+- A file that fails to parse produces exactly one `OCR_FAILED` row — the right
+  granularity, and the page PNGs stay on disk for a re-run after a parser fix.
+
+### `storageKey` is the source PDF, not a page image
+
+`PolicyOcrDocument.storageKey` points at `source-N.pdf`. The review screen
+embeds that file directly, so the reviewer looks at the **exact artifact the
+office received** and gets the browser's native PDF scrolling, zoom and text
+selection for free. Rendered PNGs are still written for future re-OCR or an
+image-based audit, but nothing points at them as the document's identity.
+
+(The statement side does the opposite — there `storageKey` is the page image,
+because a page *is* the document.)
+
+## Matching: policy number only, never the insured name
+
+`PolicyMatcherService` matches on `Policy.policyNumber` and nothing else.
+
+The certificate's "Insured" line is the account's registrant, which drifts
+from the customer the office actually holds the file under — the same finding
+the statement matcher is built around (a CESPT receipt reading
+`ARNAIZ ROSAS ELSA AURORA` for a customer this office holds as `CATT, RANDY`).
+Names are shown to the reviewer as a sanity check and never feed matching.
+
+| Rows on `policyNumber` | Result |
+|---|---|
+| exactly 1 | `MATCHED`, confident — the only unambiguous hit |
+| 0 | new policy: review offers a customer picker, confirm **creates** the row |
+| >1 | surfaced as candidates, human picks |
+
+More than one hit is never auto-resolved. Duplicate policy numbers across
+customers do occur (one group policy bound by two related parties), and
+picking arbitrarily would silently book the wrong coverage against the wrong
+person.
+
+## What the parser reads, and the field it cannot
+
+`ParsedPolicy` fields are all nullable on purpose: each carrier prints a
+different subset, and the matcher and review queue both work better with
+"field was read" vs "field was not" than with a guess.
+
+Read from the GMX certificate: policy number, insured name, additional
+insured, broker (→ `Policy.agentName`), legal address, ZIP, `policyFrom` /
+`policyTo` / `policyDate`, currency, premium-payment cadence, and the full
+per-coverage table (risk, insured amount, deductible, loss participation)
+preserved verbatim.
+
+> **The GMX certificate carries no premium.** Not "sometimes missing" — the
+> document does not have the figure. It lives on GMX's **separate `recibo`
+> PDF**. The parser leaves `netPremium` / `policyFee` / `brokerFee` / `total`
+> null and pushes a note onto the row —
+> *"esta página no trae prima; revisar el recibo de GMX por separado"* — so
+> the reviewer sees why the field is empty rather than assuming a read
+> failure.
+
+This is also why confirm never overwrites an existing `Policy.netPremium`
+with null: the certificate not carrying a premium is not evidence that the
+premium is gone.
+
+Deductible and loss participation are stored as **strings** (`"5%"`, `"20%"`,
+`"USD 1,000"`) — they are printed as a mix of percentages, currency amounts
+and free text, and normalising them would lose the distinction.
+
+## Confirm: what actually gets written
+
+Per confirmed document, in order:
+
+1. **The `Policy` row** — updated if a policy was matched, created under the
+   picked customer if not. Only non-null `extracted*` fields are written; null
+   never overwrites existing data.
+2. **A `PolicyDocument`** — the source PDF is streamed into the policy's
+   storage namespace and attached, so the paperwork stays with the policy.
+3. **Optionally a `Transaction`** — `INSURANCE` domain, negative amount
+   (a charge), `captureSource: "OCR"`, `captureRef` = the document id.
+
+The ledger write is **opt-in twice over**: staff must tick `postPremium`
+*and* a premium must have parsed to a positive number. Without that gate the
+premium-less certificate above would silently book a $0 charge on every
+confirm.
+
+`createdPolicyId` and `postedTransactionId` are unique columns on the
+document row, so a double-confirm cannot re-apply — and a `POSTED` document
+is refused outright.
+
+Discarding a batch is refused once any page is `POSTED`: a partly-applied
+batch has already written `Policy` (and possibly `Transaction`) rows, and
+hiding the paperwork behind a "discarded" label would leave those rows
+unexplained. Reject the remaining pages individually instead.
+
+## API surface
+
+| Method | Route | Ability |
+|---|---|---|
+| `GET` | `/policy-ocr/status` (is OCR + storage available) | authenticated |
+| `GET` | `/policy-ocr/batches`, `/batches/:id`, `/batches/:id/documents` | authenticated |
+| `GET` | `/policy-ocr/documents/:id/page` (streams the source PDF) | authenticated |
+| `POST` | `/policy-ocr/batches` (upload) | `policy:ingest` |
+| `PATCH` | `/policy-ocr/documents/:id` (edit the extracted fields) | `policy:ocr-review` |
+| `POST` | `/policy-ocr/documents/:id/reject` | `policy:ocr-review` |
+| `POST` | `/policy-ocr/batches/:id/discard` | `policy:ocr-review` |
+| `POST` | `/policy-ocr/batches/:id/confirm` | `policy:ocr-review` |
+
+## Requirements
+
+Same as statement OCR: object storage (`S3_ENDPOINT` + credentials) for the
+source PDFs and page images, and `tesseract-ocr` / `tesseract-ocr-data-spa` /
+`poppler-utils` in the API image. `GET /policy-ocr/status` reports both; if
+either is missing the feature reports itself unavailable and only this
+feature is disabled.
+
+## Tests
+
+`apps/api/src/policy-ocr/parsers/policy-parser.spec.ts` — 8 cases, all
+against verbatim text extracted from one real document,
+`HC_Folio_000767_Traduccion.pdf`: provider detection from the wordmark and
+from the footer URL, the header fields, every coverage row off the second
+page, the deductible/loss-participation strings, the missing-premium note,
+the broker line with the agent-number parens absent, and a page with no GMX
+signal at all (which must yield no provider rather than a bad guess).
+
+## Not built
+
+- **Only GMX.** The dispatcher (`detectPolicyProvider`) is a table of
+  `[provider, pattern]` pairs plus a `parsers` map, so adding ANA or Qualitas
+  is a parser function and two entries — but no other carrier's layout has
+  been seen yet, and guessing at one produces a parser nobody can verify.
+- **The `recibo` PDF.** Reading the premium off GMX's separate receipt
+  document, and pairing it to the certificate it belongs to, is the obvious
+  next piece. It is what would let `postPremium` stop being a manual tick.
+- **Renewals from OCR.** A re-issued policy arrives as a new certificate with
+  the same number; confirm updates the existing row rather than versioning
+  it. Nothing tracks "this is the 2027 issue of that policy".
+
+## Related
+
+- [`STATEMENT_OCR.md`](STATEMENT_OCR.md) — the utility statement pipeline this
+  was lifted from, as built. [`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md)
+  §2 is its design and the measured evidence behind it. Between them they are
+  the origin of three rules the policy parser applies: detect the provider by brand before layout, only
+  ever apply the Tesseract digit-confusion map (`O→0`, `S→5`, `B→8`, …) to
+  fields known to be digits, and parse amounts by separator *position* rather
+  than assuming `,` is thousands.
+
+  Those last two are **duplicated on purpose**, not imported: the module is
+  kept self-contained, since sharing a helper would couple two unrelated
+  domains through it. If you fix a bug in one, check the other.
+- [`INSURANCE_FEATURES_SPEC.md`](INSURANCE_FEATURES_SPEC.md) — the four
+  insurance features that *were* planned. This is not one of them.

docs/RECEIPT_CAPTURE_SPEC.md

@@ -131,7 +131,12 @@ single-movement form.
 
 ## 2. PDF / OCR auto-capture
 
-> **BUILT — 2026-08-01.** Implemented and verified end to end against real
+> **BUILT — 2026-08-01.** As-built reference:
+> [`STATEMENT_OCR.md`](STATEMENT_OCR.md) — what the shipped feature does, its
+> parsers, matcher rules and API surface. This section stays the *design* and
+> the evidence behind it; go there for what is in the code today.
+>
+> Implemented and verified end to end against real
 > scanned statements. `apps/api/src/statements/` holds the module: a swappable
 > `OcrProvider` seam with a self-hosted Tesseract implementation, per-provider
 > parsers for CFE / CESPT / Telnor / gas / predial, a scoped matcher, and a
@@ -151,6 +156,21 @@ single-movement form.
 > blobs. `GET /statements/status` reports `ocrAvailable` and `storageAvailable`,
 > and the upload card hides itself unless both hold.
 >
+> **This pipeline turned out to generalise, and a second feature came out of
+> it.** Once render → OCR → parse → match → review existed for utility
+> receipts, the same shape obviously fit the *other* stack of paper this
+> office keys in by hand — carrier policy PDFs. That is
+> [`POLICY_OCR.md`](POLICY_OCR.md), built 2026-08-01, and it is **not in any
+> spec**; it was a revelation from doing this one. The `OcrProvider` seam was
+> lifted out of `StatementsModule` into its own `OcrModule` so the policy
+> module could inject it without taking on the statement pipeline —
+> `StatementsModule` imports it now and binds nothing itself. The engine
+> choice stays a one-line change in one file, for both features.
+>
+> One assumption does **not** carry over: statements arrive bundled *one
+> customer per page*, so here a page is a document. A policy PDF is one
+> document across several pages. See that doc's "One PDF = one policy".
+>
 > **Measured, not assumed.** Ten real scans (46 pages of CFE, CESPT and Telnor
 > bills) drove every decision below. Against them the shipped parser identifies
 > the provider on **46/46**, reads an account reference on **43/46**, an amount

docs/RENEWAL_NOTICES.md

@@ -126,6 +126,16 @@ from data (one parameterized template), not from report design text. See
 `RenewalNotice` in `schema.prisma` and the `aviso-renovacion` entry in
 `apps/api/src/reports/reports.registry.ts` for the first cut at this.
 
+> **Built 2026-08-01/02.** The three generations above are now
+> `RenewalNotice.generation` 1/2/3, mailed by `apps/api/src/renewals/` on an
+> operator-editable cadence (default 06:00 daily) and driven from the
+> **Pólizas** tab of `/notificaciones`. The `CONTROL … X MES` companion
+> reports have no equivalent and need none: every attempt — sent, failed, or
+> skipped for a missing address — lands in `email_notification_log`. See
+> [`MASS_EMAIL_NOTIFICATIONS.md`](MASS_EMAIL_NOTIFICATIONS.md) and
+> [`INSURANCE_FEATURES_SPEC.md`](INSURANCE_FEATURES_SPEC.md) §1. This document
+> stays a record of the **legacy** report chain, not of what shipped.
+
 ## Caveats
 
 - Only the ATLAS variants were extracted verbatim; the QUALITAS and

docs/STATEMENT_OCR.md

@@ -0,0 +1,315 @@
+# Utility Statement OCR Capture (receipt capture)
+
+Reads the stack of scanned utility bills the office pays every month, proposes
+the customer and the amount for each page, and posts the confirmed pages to the
+ledger as one batch against one check. Built 2026-08-01, live under `/recibos`.
+
+This is the **as-built** record. The design and the reasoning behind it are
+[`RECEIPT_CAPTURE_SPEC.md`](RECEIPT_CAPTURE_SPEC.md) §2, which also carries the
+measured results and the four spec corrections the real scans forced. Read that
+for *why*; read this for *what is there*.
+
+## The job it replaces
+
+Staff receive 300+ pages per month per service provider — CFE electricity,
+CESPT water, Telnor phone, gas, municipal predial, federal zone — and key each
+one into the ledger by hand, as a charge against the customer whose property
+the bill belongs to. The whole stack is paid with one office check, so the
+capture is naturally a batch.
+
+Auto-capture is a **mode of** the existing capture screen, not a separate
+feature: it is the same daily job with a scanner instead of a keyboard, and
+both modes post through the same ledger path.
+
+## What ships
+
+| Piece | Path |
+|---|---|
+| API module | `apps/api/src/statements/` (service, controller, DTOs, matcher, parsers) |
+| OCR seam | `apps/api/src/statements/ocr/` (interface + Tesseract), bound in `apps/api/src/ocr/ocr.module.ts` |
+| Tables | `statement_batches`, `statement_documents` (`20260731235721_statement_ocr_intake`) |
+| Web | `components/Captura.tsx` (tab shell), `StatementIntake.tsx` (upload + batch list), `/recibos/:id` (review queue) |
+| Abilities | `statement:ingest`, `statement:review` — both **STAFF** |
+
+STAFF is deliberate: the review step is what makes machine capture safe at that
+tier, since nothing reaches the ledger unconfirmed.
+
+## The screen
+
+`Captura` is one screen with two ways in:
+
+- `/estado-cuenta/lote` → **manual** tab (`ManualCheckCapture`, key each
+  receipt against one check by hand)
+- `/recibos` → **automática (OCR)** tab (`StatementIntake`, upload the scans)
+- `/recibos/:id` → the batch review queue, page image beside the extracted
+  fields
+
+Both end in the same place — charges on customers' ledgers posted against one
+check — so they are modes of one screen. Staff pick by what is on the desk that
+morning. Either URL renders the same component, so old bookmarks land on the
+right tab.
+
+## Pipeline
+
+```
+upload PDFs (+ service kind) → store source → render pages → text layer? → parse → match → review → confirm → ledger
+```
+
+**A batch is one service kind.** The uploader labels it (ELECTRIC, WATER,
+TELEPHONE, GAS, PROPERTY_TAX, FEDERAL_ZONE) and that label is enforced: if the
+parser reads a page as a different provider, the page is rejected as
+mis-sorted rather than matched. Posting a phone bill as a water charge is the
+failure being prevented.
+
+**Processing is not awaited.** 300 pages of OCR is minutes of CPU, far past any
+HTTP timeout, so `POST /statements/batches` returns the batch id immediately and
+the client polls. That is also what lets the review queue show partial progress.
+
+**One page = one document.** Statements arrive **bundled, one customer per
+page** — Telnor's own `Pág 3 de 6` is its internal pagination, not the office's
+scan — so every rendered page becomes its own `StatementDocument` and the
+parser runs per page. (The policy OCR feature inverts this; see "Sibling
+feature" below.)
+
+**One unreadable page must not abandon the other 299.** A page that throws
+becomes a single `OCR_FAILED` row and the loop continues.
+
+Both the source PDFs (`statement/{batchId}/source-N.pdf`) and every rendered
+page image (`page-N.png`) are stored. The source is the artifact the office
+received and the only way to re-run a corrected parser over the original; the
+page image is what the reviewer looks at, because "what the parser read" is
+only checkable against a picture of the paper.
+
+## The OCR seam
+
+`OcrProvider` (`ocr/ocr.provider.ts`) is the swap point. Four methods:
+`available()`, `renderPages()`, `recognize()`, `textPages()`.
+
+Everything above it works in terms of page text and word boxes, so the engine
+is replaceable without touching the parsers, the matcher or the schema. The
+shipped implementation is **self-hosted Tesseract**, and that choice is
+evidence-based rather than assumed — see the spec's measured results. A managed
+API (Textract, Document Intelligence, Document AI) fits behind the same
+interface with no schema change; at 300+ pages/month/company it would carry
+real recurring cost for accuracy that is not the bottleneck.
+
+The binding lives in `apps/api/src/ocr/ocr.module.ts`, extracted out of
+`StatementsModule` when [`POLICY_OCR.md`](POLICY_OCR.md) needed the same seam.
+`StatementsModule` imports it and binds nothing itself, so the engine decision
+is one line in one file for both features.
+
+### Text layer first, OCR as the fallback
+
+**Not every statement is a scan.** The gas company sends born-digital CFDI
+invoices whose text layer is already exact and already positioned.
+`textPages()` reads it (`pdftotext -bbox-layout`, same poppler package as
+`pdftoppm`) and OCR runs only where there is none.
+
+Rasterising a born-digital page and re-recognising it can only lose
+information — one sample turned `MEDIDOR: VM01014426` into
+`ar (LTR): 014420` — while costing about a minute of CPU for the privilege.
+Positions come back in the same pixel space `recognize()` uses, so the parsers'
+geometric helpers work unchanged on either source. When the text layer is used
+the document's notes say so verbatim: *"texto leído del PDF original, sin
+OCR"*.
+
+### Word boxes, not just text
+
+`OcrPage` carries `words[]` with pixel boxes because several real layouts are
+**tables**: the CESPT "RECIBO" prints `No. DE CUENTA` as a column header with
+the value in the row beneath it, which line-oriented text cannot associate.
+Parsers fall back to geometry for exactly those fields.
+
+## Parsers
+
+Eight providers, dispatched by a `BRAND` table checked before a `LAYOUT` table:
+
+| Provider | Service kind |
+|---|---|
+| `CFE` | ELECTRIC |
+| `CESPT` | WATER |
+| `TELNOR` | TELEPHONE |
+| `GAS TIJUANA` | GAS |
+| `PREDIAL TIJUANA` / `PREDIAL ROSARITO` / `PREDIAL ENSENADA` | PROPERTY_TAX |
+| `ZONA FEDERAL TIJUANA` | FEDERAL_ZONE |
+
+Three predial parsers rather than one because Tijuana, Rosarito and Ensenada
+issue three completely different documents — same tax, nothing else in common.
+
+Rules that are load-bearing and easy to break:
+
+- **Brand before layout, and never interleaved.** Scanned logos read badly (a
+  CESPT header came back as `E BAJA ES PAGO / EALIFORNIA`), which is why the
+  layout fallback exists — but *every* brand rule runs first, because a Telnor
+  page contains words a CFE structural rule would otherwise claim.
+- **Tijuana bills predial and zona federal from the same treasury.** Same
+  header, same address, same `ATB-541201` RFC, so every predial discriminator
+  matches a zona federal page too. The words only that layout prints are
+  `Marítimo Terrestre`, so its rule is asked ahead of all three predial ones.
+  **Order matters here in a way that is invisible from the code shape.**
+- **Parse amounts by separator position.** A real Telnor bill OCR'd as
+  `$ 649,00`; stripping commas as thousands separators makes that $64,900.
+- **A misread `$` is the dangerous failure, not a missing one.** An Ensenada
+  receipt for `$2,203.00` OCR'd as `82,203.00` — the sign read as an 8, which
+  would post a charge 37× too large and look entirely ordinary in the ledger.
+  Every predial amount therefore requires a literal `$`; a page that cannot
+  produce one reports no amount and goes to review.
+- **Digit-confusion repair only on fields known to be digits** (`O→0`, `S→5`,
+  `B→8`, …), never on free text.
+- **The clave catastral is not `[A-Z]{2}[0-9]{6}`.** Position three is a letter
+  in fifteen of the 932 stored claves (`MMB01041`, `CGH52121`). Digitising the
+  whole tail maps that `B` to an `8` and yields a key matching no property.
+- **Barcodes beat printed labels.** Where a provider prints a payment barcode
+  it is preferred and the two are cross-checked; disagreement sets
+  `crossChecked: false` and forces review, because which of the two was
+  misread is a judgement call.
+
+## Matching
+
+`StatementMatcherService`. Two rules govern everything:
+
+**Match on one scoped field, never fuzzily across all identifiers.** Each
+service kind has exactly one column its statements print, and only that column
+is consulted. A blanket search over accountNumber/meterNumber/route would let a
+water account number collide with an unrelated phone number, and the mis-post
+would look perfectly ordinary in the ledger.
+
+**Never match on the customer name.** A CESPT receipt for account `5365218`
+prints `ARNAIZ ROSAS ELSA AURORA`; the office's book, corroborated by the
+clave, has `CATT, RANDY`. The name on a utility bill is the registrant, not the
+current owner. Names are shown to the reviewer and are never an input.
+
+### `scopedRefField` — which column each kind actually prints
+
+| Kind | Column | Why |
+|---|---|---|
+| ELECTRIC, WATER, TELEPHONE, CABLE | `accountNumber` | the legacy column holds the printed number |
+| GAS | `meterNumber` | the number lived in free-text notes; `accountNumber` was never populated |
+| PROPERTY_TAX | `meterNumber` | `accountNumber` holds `DATMEX.predial`, an office file number that is neither unique nor printed anywhere |
+| FEDERAL_ZONE | `meterNumber` | `accountNumber` holds `DATMEX.zfed`, which is a **peso amount**, not a reference |
+
+`scopedRefField` is exported because three places must agree on the answer: the
+lookup, the blank-service fill on review, and the write-back on confirm. When
+they disagree a reference gets learned into a column nothing searches, and the
+same page returns to the review queue every month forever.
+
+The `FEDERAL_ZONE` case is the sharpest instance of a trap this codebase hits
+repeatedly (see also `policies.total`): a legacy column whose *name* promises
+an identifier and whose *contents* are something else. Three of its 77 values
+carry cents and one is negative. Worse than never matching — because every row
+already has a value, the `[field]: null` guards on learning and on the
+blank-service fill would never fire either.
+
+### The clave catastral is a rescue on some layouts and the primary key on others
+
+CESPT bills print the clave as well as an account number, so it rescues a page
+whose account number did not OCR — which happened on real samples. There it
+stays a hint.
+
+On Rosarito and Ensenada predial the receipt prints **nothing else**, so a
+unique clave hit is a real match and auto-matches. Tijuana predial prints no
+clave at all; its only identifier is an 8-digit municipal account carried in a
+32-digit payment barcode (`account(8) + DDMMYY + amount(9) + folio(9)`) that
+the legacy database never held, so those pages start cold and are taught by the
+first confirm.
+
+Multiple hits are always surfaced, never auto-picked — duplicate account
+numbers do occur in the legacy data, and the office's own `DUPLICADOS` report
+existed for a reason.
+
+## Confirm: what gets written
+
+`confirmBatch` posts through **`BillingService.createBatch`** — the same method
+the manual Editor screen uses — rather than writing `Transaction` rows
+directly, so OCR-sourced and hand-keyed receipts share one write path, one
+validation path and one audit trail.
+
+- `source: "OCR"` and a per-line `captureRef` of the document id feed the
+  duplicate-post guard, so a batch confirmed twice cannot double-charge.
+- `items[i]` is positionally parallel to `lines[i]` (a documented seam
+  guarantee), so the created rows zip straight back onto the documents that
+  produced them via `postedTransactionId`.
+- **The sign is applied here.** Charges are negative in this ledger; the parser
+  reads the printed positive figure, and `-Math.abs()` is applied at the single
+  point where a statement becomes a ledger row.
+- A missing amount blocks the confirm with the offending page numbers, rather
+  than silently posting zero.
+
+### Learning: the cold start is a one-time cost
+
+After posting, `learnAccountRefs` writes each confirmed reference back onto the
+`PropertyService` that matched — **only where the field was null**. Never
+overwrites a number already on file, which would let one misread page rewrite
+good reference data.
+
+This is what turns gas (whose numbers the migration never populated) and
+Tijuana predial (whose municipal account the legacy database never held) from a
+permanent review queue into a one-time cost: next month's statement for the
+same account matches on its own.
+
+### Discarding
+
+Refused once any page is `POSTED` — those pages already wrote ledger rows
+against a check, and a "discarded" label on the batch would leave the charges
+unexplained. Reject the remaining pages individually instead.
+
+## API surface
+
+| Method | Route | Ability |
+|---|---|---|
+| `GET` | `/statements/status` (is OCR + storage available) | authenticated |
+| `GET` | `/statements/batches`, `/batches/:id`, `/batches/:id/documents` | authenticated |
+| `GET` | `/statements/documents/:id/page` (streams the page image) | authenticated |
+| `POST` | `/statements/batches` (upload + service kind) | `statement:ingest` |
+| `PATCH` | `/statements/documents/:id` (correct a field or the match) | `statement:review` |
+| `POST` | `/statements/documents/:id/reject` | `statement:review` |
+| `POST` | `/statements/batches/:id/discard` | `statement:review` |
+| `POST` | `/statements/batches/:id/confirm` | `statement:review` |
+
+## Requirements
+
+Object storage (`S3_ENDPOINT` + credentials) for the scans, and `tesseract-ocr`
+/ `tesseract-ocr-data-spa` / `poppler-utils` in the API image. Both are checked
+at upload rather than at the first write — a missing dependency should be a 400
+on the request, not a `FAILED` batch minutes later. `GET /statements/status`
+reports both and the upload card hides itself unless both hold.
+
+## Tests
+
+- `parsers/statement-parser.spec.ts` — `detectProvider`,
+  `normalizeCadastralKey`, and one suite per newer parser
+  (`parsePredialTijuana`, `parsePredialRosarito`, `parsePredialEnsenada`,
+  `parseGas`, `parseZonaFederal`). Every fixture is a **verbatim OCR excerpt
+  from a real receipt**, including the ones that bit: the `82,203.00` Ensenada
+  dollar sign, the three-letter clave, the CESPT logo garbage.
+- `ocr/tesseract.provider.spec.ts` — `parseBboxLayout`, the
+  `pdftotext -bbox-layout` reader that produces the text-layer `OcrPage`
+  (positions included, which is what lets the geometric helpers work on
+  born-digital input).
+
+Note the CFE / CESPT / Telnor parsers themselves have **no unit suite** — they
+predate the gas/predial extension and were verified against the 46-page corpus
+end to end rather than in isolation. Worth closing if they are touched.
+
+## Not built
+
+- **Handwritten folder numbers.** Staff pencil a customer number on each bill
+  (`9`, `405`); Tesseract read `405` as `205`. Handwriting is a review hint at
+  best and is deliberately not an input to matching.
+- **Re-running a corrected parser over a stored batch.** The source PDFs are
+  kept precisely so this is possible, but nothing exposes it yet.
+- **Providers beyond the eight above.** Adding one is a `BRAND` entry, an
+  optional `LAYOUT` entry, and a parser function.
+
+## Sibling feature
+
+[`POLICY_OCR.md`](POLICY_OCR.md) — the same pipeline reading carrier policy
+PDFs into `Policy` rows, built out of this one. It reuses the seam, the
+provider-detection ordering, the digit-confusion map and the
+amount-by-separator rule.
+
+**One assumption does not carry over.** Here a page *is* a document, because
+statements arrive one customer per page. A policy PDF is one document across
+several pages, so that feature concatenates the pages and parses once per file.
+If you are porting a change between the two, that is the difference to check
+first.

migration/transform_customers.py

@@ -189,6 +189,11 @@ def customer_from_utilities(row, name_index) -> dict:
         customerSince=as_date(row["cliente_desde"]),
         status=as_bool(row["status"]),
         feeAmount=as_decimal(row["fee"]),
+        # DATGRAL.TIPO is the minimum-balance threshold (100/200/300/500 —
+        # 1,017 of 1,172 customers carry one), NOT an identification or account
+        # type as the column name suggests. It reaches the website as
+        # datosfreak.TIPO and is returned to the customer app as `minBalance`.
+        minimumBalance=as_decimal(row["tipo"]),
         updatedAt=NOW,
     )
 
@@ -217,6 +222,7 @@ def customer_from_insurance(row, name_index) -> dict:
         customerSince=None,
         status=1,
         feeAmount=None,
+        minimumBalance=None,
         updatedAt=NOW,
     )
 
@@ -225,7 +231,7 @@ _CUST_COLS = [
     "id", "name", "nameSource", "nameMissing", "addressLine1", "addressLine2", "city", "state", "zipCode",
     "country", "phone", "mobile", "fax", "email", "notes", "identificationType",
     "identificationNumber", "identificationExpiration", "customerSince",
-    "status", "feeAmount", "updatedAt",
+    "status", "feeAmount", "minimumBalance", "updatedAt",
 ]
 
 
@@ -316,7 +322,7 @@ def main() -> None:
             remap[rec["id"]] = stable or rec["id"]
         for rec in customers:
             rec["id"] = remap[rec["id"]]
-            cur.execute(f"INSERT INTO customers ({','.join(f'`{c}`' for c in _CUST_COLS)}) VALUES ({placeholders}) ON DUPLICATE KEY UPDATE name=VALUES(name),nameSource=VALUES(nameSource),nameMissing=VALUES(nameMissing),addressLine1=VALUES(addressLine1),addressLine2=VALUES(addressLine2),city=VALUES(city),state=VALUES(state),zipCode=VALUES(zipCode),country=VALUES(country),phone=VALUES(phone),mobile=VALUES(mobile),fax=VALUES(fax),email=VALUES(email),notes=VALUES(notes),identificationType=VALUES(identificationType),identificationNumber=VALUES(identificationNumber),identificationExpiration=VALUES(identificationExpiration),customerSince=VALUES(customerSince),status=VALUES(status),feeAmount=VALUES(feeAmount),updatedAt=VALUES(updatedAt)", tuple(rec[c] for c in _CUST_COLS))
+            cur.execute(f"INSERT INTO customers ({','.join(f'`{c}`' for c in _CUST_COLS)}) VALUES ({placeholders}) ON DUPLICATE KEY UPDATE name=VALUES(name),nameSource=VALUES(nameSource),nameMissing=VALUES(nameMissing),addressLine1=VALUES(addressLine1),addressLine2=VALUES(addressLine2),city=VALUES(city),state=VALUES(state),zipCode=VALUES(zipCode),country=VALUES(country),phone=VALUES(phone),mobile=VALUES(mobile),fax=VALUES(fax),email=VALUES(email),notes=VALUES(notes),identificationType=VALUES(identificationType),identificationNumber=VALUES(identificationNumber),identificationExpiration=VALUES(identificationExpiration),customerSince=VALUES(customerSince),status=VALUES(status),feeAmount=VALUES(feeAmount),minimumBalance=VALUES(minimumBalance),updatedAt=VALUES(updatedAt)", tuple(rec[c] for c in _CUST_COLS))
         for ref in refs:
             cur.execute("INSERT INTO customer_legacy_refs (id,customerId,sourceSystem,sourceTable,legacyId) VALUES (%s,%s,%s,%s,%s) ON DUPLICATE KEY UPDATE customerId=VALUES(customerId)",
                         (ref[0], remap[ref[1]], ref[2], ref[3], ref[4]))

migration/transform_transactions.py

@@ -112,6 +112,29 @@ def main():
         type_rows.append((tid, en, s(r["espa_ol"]), 0))
         type_map[en.upper()] = tid
 
+    def type_id_for(raw) -> str | None:
+        """Resolve a transaction type, minting one when the lookup lacks it.
+
+        The Access `TYPE OF TRX` table is a stale pick-list, not a constraint —
+        staff free-text straight into DATOS2, so 78 values covering 3,939 rows
+        (BALANCE FORWARD 1,188, ANNUAL FEE 1,116, IZZI 367, ...) appear in the
+        ledger but not the lookup. Leaving those unmapped stored typeId NULL and
+        lost the label outright: nothing else on `transactions` carries the type
+        text, so the row rendered blank and was unrecoverable after migration.
+        Minting from the literal keeps the display string; nameEs stays NULL
+        because only the lookup has translations.
+        """
+        en = s(raw)
+        if not en:
+            return None
+        key = en.upper()
+        tid = type_map.get(key)
+        if tid is None:
+            tid = str(uuid.uuid4())
+            type_rows.append((tid, en, None, 0))
+            type_map[key] = tid
+        return tid
+
     xr = load("stg_utilities", "tipo_hist")
     xr_rows = []
     for _, r in xr.iterrows():
@@ -193,7 +216,7 @@ def main():
             td = dt(r["date"])
             if td is None:
                 skip_date += 1; continue
-            tid = type_map.get((s(r["type_of_trx"]) or "").upper())
+            tid = type_id_for(r["type_of_trx"])
             add(cid, "UTILITY", td, dec(r["chargecredit"], Decimal(0)), "MXN",
                 period=s(r["period"]), reference=s(r["refer"]), typeid=tid,
                 check=s(r["cheque"]), src_db="UTILITIES", src_tbl=legacy_tbl,

package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgecuadros-platform",
-  "version": "1.0.6",
+  "version": "1.0.8",
   "private": true,
   "workspaces": [
     "apps/*",

packages/database/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jorgecuadros/database",
-  "version": "1.0.6",
+  "version": "1.0.8",
   "private": true,
   "main": "generated/client/index.js",
   "types": "generated/client/index.d.ts",

packages/database/prisma/migrations/20260802120000_renewal_notices_unified_log/migration.sql

@@ -0,0 +1,67 @@
+-- Fold insurance renewal avisos into the one notification log.
+--
+-- Until now `renewal_notices` was the only record a renewal send left
+-- behind, and its sole job is gating: a row with `sentAt` removes the
+-- policy from the pending list. It cannot represent a failed send, a
+-- customer with no email, or a second attempt — so the Pólizas tab of
+-- /notificaciones had no "Registro de envíos" to show.
+--
+-- Extending the two enums lets `RenewalsService` write the same
+-- `email_notification_log` rows the four bulk jobs write. `renewal_notices`
+-- keeps its gating role unchanged.
+
+-- AlterEnum: EmailNotificationType += RENEWAL_NOTICE
+ALTER TABLE `email_notification_log`
+    MODIFY `notificationType` ENUM('OUTSTANDING_PAYMENT', 'PAYMENT_CONFIRMATION', 'ACCOUNT_STATUS', 'TRUST_PAYMENT_CONFIRMATION', 'RENEWAL_NOTICE') NOT NULL;
+
+-- AlterEnum: EmailNotificationServicio += POLICIES
+ALTER TABLE `email_notification_log`
+    MODIFY `servicio` ENUM('CUSTOMERS', 'TRUST', 'POLICIES') NOT NULL;
+
+-- Backfill: every renewal notice this platform actually emailed.
+--
+-- Scope is deliberately `channel = 'EMAIL' AND sentAt IS NOT NULL`. MAIL-
+-- channel rows are printed letters carried over from the legacy book — they
+-- were never emails, and inventing log rows for them would misreport the
+-- send history. Emailed rows carry a real recipient (resolved through the
+-- policy's customer) and a real timestamp; the only fields we cannot
+-- recover are the rendered body and the exact subject, so `bodySnapshot`
+-- stays empty and the subject is reconstructed from the same two templates
+-- `renderRenewalEmail()` uses (generation 3 = expired wording).
+--
+-- Rows whose customer has no email are skipped: `customerEmail` is NOT NULL
+-- and a blank recipient would be a lie. Their `renewal_notices` row still
+-- gates the pending list exactly as before.
+INSERT INTO `email_notification_log` (
+    `id`, `sendDate`, `notificationType`, `level`, `servicio`,
+    `customerId`, `customerName`, `customerEmail`, `subject`,
+    `bodyRequestUrl`, `bodySnapshot`, `debug`,
+    `providerMessageId`, `providerResponse`, `status`, `error`
+)
+SELECT
+    UUID(),
+    rn.`sentAt`,
+    'RENEWAL_NOTICE',
+    rn.`generation`,
+    'POLICIES',
+    c.`id`,
+    c.`name`,
+    c.`email`,
+    CASE WHEN rn.`generation` = 3
+         THEN CONCAT('Póliza vencida: ', p.`policyNumber`)
+         ELSE CONCAT('Aviso de renovación: póliza ', p.`policyNumber`)
+    END,
+    NULL,
+    '',
+    FALSE,
+    rn.`providerMessageId`,
+    'backfill:20260802120000',
+    'SENT',
+    NULL
+FROM `renewal_notices` rn
+JOIN `policies` p ON p.`id` = rn.`policyId`
+JOIN `customers` c ON c.`id` = p.`customerId`
+WHERE rn.`channel` = 'EMAIL'
+  AND rn.`sentAt` IS NOT NULL
+  AND c.`email` IS NOT NULL
+  AND c.`email` <> '';

packages/database/prisma/migrations/20260802140000_app_settings/migration.sql

@@ -0,0 +1,19 @@
+-- Operator-editable configuration.
+--
+-- First tenant: the notification summary recipients, which were
+-- NOTIFICATION_ADMIN_EMAILS in the environment. That list changes when office
+-- staff change — a redeploy is the wrong unit of work for "Ana left, add
+-- Beto" — so it belongs in the database with a UI, not in a stack env var.
+--
+-- Credentials stay in env. See the model doc in schema.prisma for where the
+-- line is drawn.
+
+-- CreateTable
+CREATE TABLE `app_settings` (
+    `key` VARCHAR(191) NOT NULL,
+    `value` TEXT NOT NULL,
+    `updatedAt` DATETIME(3) NOT NULL,
+    `updatedById` VARCHAR(191) NULL,
+
+    PRIMARY KEY (`key`)
+) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

packages/database/prisma/schema.prisma

@@ -944,20 +944,31 @@ model EmailLog {
 ///                                  red and yellow; the threshold is in the
 ///                                  `level` column, 0=yellow / 1=red)
 ///   - TRUST_PAYMENT_CONFIRMATION → sendConfirmTrustPayment.php (TRUSTHFEE)
+///
+/// RENEWAL_NOTICE has no PHP ancestor — it is the insurance renewal aviso
+/// (`RenewalsService`), logged here so every outbound email the platform
+/// sends lands in one table. `RenewalNotice` remains the per-policy
+/// "already notified" record that drives the pending list; this log is the
+/// send history, including the failures and skips `RenewalNotice` cannot
+/// represent.
 enum EmailNotificationType {
   OUTSTANDING_PAYMENT
   PAYMENT_CONFIRMATION
   ACCOUNT_STATUS
   TRUST_PAYMENT_CONFIRMATION
+  RENEWAL_NOTICE
 }
 
 /// Which "servicio" (line of business) the notification draws its recipients
 /// from. CUSTOMERS = the unified customers ledger (replaces `datosfreak`);
-/// TRUST = the trust-fee account table (replaces `TRUSTHFEE`). Keeping the
-/// two services tagged makes a per-line report trivial.
+/// TRUST = the trust-fee account table (replaces `TRUSTHFEE`);
+/// POLICIES = the insurance book (renewal avisos). Keeping the services
+/// tagged makes a per-line report trivial — and lets the /notificaciones
+/// tabs each show their own slice of the one log.
 enum EmailNotificationServicio {
   CUSTOMERS
   TRUST
+  POLICIES
 }
 
 /// Outcome of a single send attempt. SENT / FAILED are the meaningful ones;
@@ -982,11 +993,17 @@ model EmailNotificationLog {
   id                String                   @id @default(uuid())
   sendDate          DateTime                 @default(now())
   notificationType  EmailNotificationType
-  /// 0 = yellow ("DEBAJO DEL TIPO"), 1 = red ("EN ROJO"). Only set on
-  /// ACCOUNT_STATUS rows; null on the other three jobs.
+  /// Per-type discriminator, null where the type has none:
+  ///   ACCOUNT_STATUS → 0 = yellow ("DEBAJO DEL TIPO"), 1 = red ("EN ROJO")
+  ///   RENEWAL_NOTICE → the aviso generation (1 = 30d before, 2 = 15d
+  ///                    before, 3 = 7d after expiry)
+  /// Null on the remaining jobs. Readers MUST branch on notificationType
+  /// before interpreting it.
   level             Int?
   /// Which servicio sourced the recipient list. CUSTOMERS for jobs 1/2/3,
-  /// TRUST for job 4. Tagged here so a per-line audit doesn't need to join.
+  /// TRUST for job 4, POLICIES for renewal avisos. Tagged here so a per-line
+  /// audit doesn't need to join — and so the /notificaciones Servicios tab
+  /// (CUSTOMERS + TRUST) and Pólizas tab (POLICIES) can filter one log.
   servicio          EmailNotificationServicio
   /// FK to the customer that triggered the send. Trust-account notifications
   /// resolve the owner through `Property.customerId`, so this stays set on
@@ -1108,3 +1125,30 @@ model ScheduledJobState {
 
   @@map("scheduled_job_states")
 }
+
+/// Operator-editable configuration — the settings that staff must be able to
+/// change without a redeploy.
+///
+/// Deliberately NOT a home for everything in the environment. Credentials and
+/// endpoints (SES keys, DATABASE_URL, S3) stay in env: they are deployment
+/// identity, they must exist before the app can talk to its own database, and
+/// putting a secret in a table only widens who can read it. What belongs here
+/// is the opposite kind of value — no secret, changes on office business
+/// rhythm rather than deploy rhythm, and wrong far more often than the
+/// deployment is.
+///
+/// `value` is TEXT holding whatever encoding the owning feature defines
+/// (a comma-separated list, a JSON blob). Each setting has exactly one reader,
+/// which owns parsing and validation; there is no generic typed accessor,
+/// because a schema-less bag with a typed façade is just a schema with the
+/// checks moved somewhere easier to forget.
+model AppSetting {
+  key         String   @id
+  value       String   @db.Text
+  updatedAt   DateTime @updatedAt
+  /// Who last changed it. Null for rows written before the UI existed or by
+  /// a migration. Not an FK: a setting must outlive the user who set it.
+  updatedById String?
+
+  @@map("app_settings")
+}

pnpm-lock.yaml

@@ -46,6 +46,9 @@ importers:
       class-validator:
         specifier: ^0.14.1
         version: 0.14.4
+      cron:
+        specifier: ^3.2.1
+        version: 3.2.1
       exceljs:
         specifier: ^4.4.0
         version: 4.4.0