Document the rectificar student-reminder email workflow: what triggers it, what emails a student actually receives, volume/dedup — then decide cleanup

Sub-tickets — 0/1 done

Activity

• wi-cli-venus created · 2026-07-19
• wi-cli-venus assigned · 5w ago
  coder02-mars-cc
• wi-cli-venus note · 5w ago
  VERIFIED STILL OPEN 2026-09-11 - investigation not done, and the subject of it exists. src/lib/mailer.ts:282 names a weekly rectificar-reminder cron that bumps a state row, and the rectificar email family is there: the para-rectificar notice (:494), the student-comentario notice to the teacher (:532,:550) and the reenviada-tras-rectificar notice (:593), with RECTIFICAR_REPLY_TO at :37 pointing at rectificar-practica@pensanta.com. So this is a documentable path today; what is missing is the end-to-end write-up (trigger, recipient selection, frequency, dedup) and the EVO-72 verdict on whether it feeds the over-4-emails complaint. Buildable with no dependency on anyone else.
• wi-cli-venus completed · 5w ago
  INVESTIGATION DELIVERED. Workflow doc + EVO-72 verdict written to mars/pm/reports/2026-09-11-mars525-rectificar-email-workflow.md (UNTRACKED as of this close - it rides out with the next code push's --only list; a doc-only push freezes the version and publishes whoever else's commits are ahead, so it does not get its own push). Child MARS-719 filed for the measured driver. No code or data changed. THE WORKFLOW, END TO END. Four rectificar triggers exist. (1) The FLIP: grading a practica to 'rectificar' emails the student immediately in the grading transaction's notification leg; template mailer.ts:494; Reply-To is the shared RECTIFICAR_REPLY_TO = rectificar-practica@pensanta.com (mailer.ts:37), not the grading teacher. 154 sends/60d. (2) RESUBMIT: student resends -> the returning teacher gets 'reenviada tras rectificar' (mailer.ts:593). 134/60d. (3) COMENTARIOS on a returned practica: student->teacher (mailer.ts:532,:550) 5/60d, teacher->student 98/60d. (4) The WEEKLY REMINDER cron - BUILT AND COMPLETE, BUT HELD OFF: src/app/api/cron/rectificar-reminder/route.ts, pg_cron jobid 18, schedule '0 9 * * 3', active=false, HAS NEVER FIRED. Its design: per-practica attemptCount ladder (1-3 student only; 4-6 add the picked jtp/ayudante; 7-9 add the comision's other jtps; 10 TERMINAL, writes rectificar-reminder-exhausted and stops), NO catch-up (a skipped week is skipped, not replayed - so enabling it sends at most one email per affected student in week one, not a backlog), one coalesced email per student per week regardless of how many practicas are pending, suppression+counter-reset on a practicaReviews row newer than the reminder state, per-student atomic tx, ?dryRun=1, maxDuration=60. All Mars crons are pg_cron via net.http_get; vercel.json has crons:[]. DEDUP is three unshared mechanisms: the cron's own weekly coalescing (inert while off), the egress classifier at the dispatcher chokepoint (source of blockedRecipientCount), and logEventOnce. There is NO cross-family per-recipient rate limit anywhere. THE ONLY RECTIFICAR REMINDER STUDENTS HAVE EVER RECEIVED was a manual one-off on 2026-06-30 - 39 students enqueued by coder-mars-cc under reason 'MARS rectificar-reminder live blast - Elazar GO', preceded by a live:false design sample to Elazar. One send, one day, by hand. EVO-72 VERDICT: RECTIFICAR IS NOT THE DRIVER. Student-facing families, 60d: practica-aprobada->student 1958, rectificar-flip->student 154, teacher-comentario->student 98. Approvals outnumber rectificar 12.7:1, the recurring reminder contributed zero because it never ran, and rectificar is ~7% of student-facing sends. Removing every rectificar email would not change what a student experiences. The driver is per-approval notification under BURST GRADING - 29% of the 659 student-weeks with >=1 review carried >=4 emails, 20.8% carried >=5, and in those 137 heavy weeks the MEDIAN first-to-last span is 55 MINUTES with 105/137 from a single reviewer. Detail in MARS-719. QUESTION LEFT OPEN FOR ELAZAR, WITH ITS DATA, NOT A RECOMMENDATION: enable jobid 18? Live population today is 55 practicas in 'rectificar' across 33 students, 38 of them untouched >30 days (median 46d, max 116d), 9 of them >90 days - so the job has a real backlog to address, and its no-catch-up design bounds week one to one email per student. Against: it adds a recurring family while the over-4-emails complaint is open. The route header says this is his call; this row takes no position. INSTRUMENT BOUNDS, stated because they bound every figure above. appEvents email-sent carries subject/attemptCount/recipientCount/blockedRecipientCount and NO RECIPIENT ADDRESS, so total per-student inbox volume across all families is NOT computable from any log - only the per-review family is, by proxy from practicaReviews, validated at 2130 reviews vs 2125 matching email-sent rows (0.2% gap). emailOutbox is not history (pg_cron jobid 5 purges sent/permanentlyFailed daily). The per-student-per-week distribution is CONDITIONAL on weeks containing >=1 review, not all students every week. date_trunc('week') buckets UTC Monday, so AR Sunday-night grading lands in the next bucket. NOT EXERCISED: no browser walkthrough (no local dev server), no mailbox read, no template render, and the teacher-side new-practica family (1750/60d) is measured but not analysed - out of this row's scope. No PII in the report: aggregates only, no student/teacher/address/codigo named.