Terra outbound mail: access-request notification (NOT migration terra_13 — that is TERRA-10's deliverable)
Terra first-party outbound mail path for the /sin-acceso access-request notification. Scope cleared by pmmaster to ONE job; account-lifecycle mail explicitly out. Built outside supabase.auth (separate origin, wrong appKey if enamel sends). Two guards built separately named: admission allowlist vs egress classifier. Integrated against the applied requestTerraAccess DB contract (SECURITY INVOKER, four explicit provenance args). Shipped 15eb713 v0.15.0. INERT ON ARRIVAL for two independent reasons: zero roleless users so no eligible caller, and recipient seam sourceUndecided pending Elazar naming la coordinacion. Green deploy is NOT evidence it works; five compensating boundary assertions in access-request-core.test.ts carry the verification, must-fail control run.
Questions
Activity
-
Terra outbound mail: access-request notification (NOT migration terra_13 — that is TERRA-10's deliverable)
-
NAME COLLISION WARNING: WI TERRA-13 ships NO DDL. The file db/migrations/*/terra_13_delete_truncate_coverage.sql belongs to WI TERRA-10 (db-terra-cc). Grepping db/migrations/ for 'terra_13' from this WI lands on unrelated work. Inertness, exact: the behavioural arm is unexercised for ONE reason - no eligible caller (users=3 rows, all 3 carry a terra group row, roleless=0, measured 2026-08-01 by explicit anti-join). Residue risk is NOT a reason and never was: ticketNumber comes from fn_assignTicketNumber upserting supportTicketCounters, a TABLE, so a rolled-back probe leaves nothing. The probe is not the missing piece; a roleless user is.
-
BLOCK:15eb713 from audit-terra-ca (Class-A email-send path). 7 findings. Live-wrong now: recipient-guard.ts admits a@@gmail.com, x@localhost, x@gmail..com, x@-bad.com as ok:true and does not dedupe case-insensitively - one bad DB address makes Nodemailer reject the whole multi-recipient send. HIGH latent: raw Error.message written to shared appEvents leaks recipient addresses into enamel's co-tenanted ledger (SMTP responses echo addresses); allRecipientsBlocked has no failureCode ledger and empty input emits no row at all; no monitored replyTo; to: array discloses every coordinator address to every other recipient. Verification gap: nothing executes readMailConfig, transporter options, SMTP success/failure ledger, redaction, replyTo, or notifyAccessRequest's 7 outcomes - transport core must be extracted and tested with its own must-fail control. Also: qualify public.requestTerraAccess so resolution does not ride pool search_path; stale lines 10-12 comment still says DIRECT INSERT; SMTP_PORT Number(text) yields NaN with no config-failure outcome. Finding 1 (COORDINATION_GROUP null) stays blocked on Elazar and is not coder's to close.
-
BLOCK:35bcbdb from audit-terra-ca — 7 findings: #1 HIGH recipient source still inert (COORDINATION_GROUP null, gated on Elazar coordination answer, PTD unexercised), #2 HIGH partial-delivery unmodelled in transport-core.ts, #3 HIGH monitored Reply-To not enforced, #4 MED/HIGH quoted-local regex admits malformed addresses, #5 HIGH redaction incomplete on From/Reply-To echo, #6 HIGH real transporter boundary (nodemailer/TLS) untested, #7 MED invalid SMTP_PORT silently coerced to 587. Relayed to coder-terra-cc. Re-ping audit on next correcting SHA.
-
mail transport rework shipped 0126740/0.15.7, audit PASS; mail rollout still blocked on Elazar coordination-group decision