Research: decisões de paridade

Decisão: duas unidades de deploy, uma fonte de especificação

Rationale: Web e API têm ciclos de deploy próprios, mas os contratos e a decisão de produto precisam ser revisados no mesmo workspace.

Alternatives considered: reintroduzir o monorepo como fonte operacional ou criar repositórios para worker/agentes/specs. Ambos aumentam acoplamento e já foram descartados pelo owner.

Decisão: preservar comportamento, não endpoints legados

Rationale: Contratos antigos expõem tenant/clínica e clientes de código que não fazem parte do produto individual atual. A equivalência é avaliada pela jornada e pela regra de dados, não pelo nome de uma rota.

Alternatives considered: compatibilidade literal de rotas. Rejeitada por manter dependência e ambiguidade entre os dois modelos.

Decisão: trabalho assíncrono no repositório da API

Rationale: IA e sincronização podem exigir processo próprio, mas compartilham segredos, schema, observabilidade e contrato com a API.

Alternatives considered: repositório worker separado. Rejeitado pelo owner.

Decisão: capacidade sensível indisponível é preferível a placeholder

Rationale: Documento, áudio e IA envolvem dados clínicos. A interface deve mostrar indisponibilidade específica até autorização, retenção e revisão humana estarem implementadas.

Alternatives considered: simular sucesso ou guardar conteúdo sem contrato. Rejeitado por segurança clínica.