rafaeskytrabalhoandClaude Opus 5 00c8e004c1 feat(agenda): o lembrete de compromisso ganha quem o dispare ...

A migration 0177 declarou `calendar_appointments.reminder_sent_at` como "quem
recebe o lembrete" e deu a `calendar_event_types` as colunas `reminder_enabled`
e `reminder_minutes_before`. Nada nunca as leu — coluna sem consumidor, o
anti-pattern nº 3 do CLAUDE.md. Esta rota é o consumidor.

Varre a cada 5 min o compromisso confirmado, futuro, ainda não avisado e cujo
tipo pede lembrete; resolve contato, canal e fuso SEMPRE dentro da organização
da linha do compromisso; respeita a janela de envio do canal; e carimba a
TENTATIVA, porque o desfecho da entrega vive na mensagem. Rodada que não avisou
ninguém não audita, como manda a regra de cron desta base.

⚠️ NASCE DORMENTE, e o commit não muda isso. A 0194 pôs `reminder_enabled` em
`default false` e escreveu que ligar por padrão "fica com o dono do produto NO
DIA em que o disparador nascer". Este é o disparador; a decisão segue sendo
dele. Medido na main 58dcb811: `reminder_enabled` não está no `criarSchema`
nem no `alterarSchema` de `app/api/v1/agenda/tipos/route.ts`, não é projetado
no GET, e não existe em `app/app/settings/tenant/agenda/` — ou seja, hoje
ninguém consegue ligar o lembrete pela tela nem pela API, e a consulta devolve
zero linhas em toda instalação. A superfície de configuração é o outro meio do
par e ainda falta escrevê-la.

Medido antes do porte, na main 58dcb811: zero leitores das quatro colunas de
lembrete fora de `lib/database.types.ts` (controle positivo da mesma sonda:
`event_type_id` aparece em 14 arquivos), e nenhuma linha de lembrete no
`docker/scheduler/entrypoint.sh`.

Trabalho original de @rafaeskytrabalho no PR #423 (fechado pelo autor sem
nunca ter recebido resposta nossa).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-09-08 09:30:44 -03:00

..

entrypoint.sh

feat(agenda): o lembrete de compromisso ganha quem o dispare

2026-09-08 09:30:44 -03:00