Research: Fechamento das Lacunas Pós-Migração¶
Decision: construir a grade com date-fns e componentes locais¶
Rationale: prontuare-web já depende de date-fns e shadcn/ui. As necessidades aprovadas são mês, semana, navegação e seleção; uma biblioteca completa adicionaria peso e uma abstração maior que o escopo.
Alternatives considered: FullCalendar/React Big Calendar (recursos e dependência excedem o escopo); copiar a implementação legada (arrasta decisões antigas); somente lista (não atende ao gap P0).
Decision: manter /api/appointments e endurecer seu contrato¶
Rationale: A API já filtra agendamentos por owner e intervalo. A grade precisa de ordenação determinística, limite de 42 dias e identificação mínima do paciente, não de outro endpoint paralelo.
Alternatives considered: endpoint /calendar/events (duplicaria o modelo); carregar todos os pacientes no cliente para fazer join (mais requests e risco de inconsistência).
Decision: timezone explícito e intervalo semiaberto¶
Rationale: from <= startsAt < to evita dupla contagem em bordas. referenceAt e timezone IANA tornam “hoje” e “mês” reproduzíveis e testáveis.
Alternatives considered: timezone do servidor (incorreto para usuário); timezone implícito do browser sem contrato (não reproduzível); datas locais sem offset (ambíguas).
Decision: endpoint agregado único para dashboard¶
Rationale: Um snapshot único evita que cards representem instantes diferentes, centraliza ownership e mantém regras de contagem na API.
Alternatives considered: quatro endpoints/queries no web (inconsistência e mais latência); reutilizar lista completa de pacientes/agendamentos (transferência de regra e dados desnecessários).
Decision: métricas usam união available/unavailable¶
Rationale: O schema atual possui pacientes e agendamentos, mas não possui documentos nem lançamentos financeiros. Zero seria uma afirmação falsa. O estado discriminado permite evolução compatível.
Alternatives considered: manter mocks (rejeitado pelo PRD); criar tabelas vazias nesta feature (domínios sem requisito); omitir campos (contrato instável e UI ambígua).
Decision: consultas brasileiras são um gate documental¶
Rationale: O web contém hooks de CEP/CNPJ, porém a API isolada não oferece os endpoints legados e CFP não está implementado. Custo, confiabilidade, LGPD e termos precisam de decisão do owner antes de credenciais ou novas dependências.
Alternatives considered: restaurar automaticamente BrasilAPI/InfoSimples (expansão não autorizada); remover tudo sem decisão (perda silenciosa); validar CFP apenas por formato (não comprova registro profissional).
Decision: testes verticais em Playwright com fixture determinística¶
Rationale: A constituição exige browser → API → banco. A fixture precisa criar dois owners e eventos nas bordas para comprovar layout, agregação e isolamento.
Alternatives considered: somente snapshots/component tests (não comprovam contrato e ownership); somente integração API (não comprova acessibilidade e navegação).