O protético opera dentro do workspace 'laboratorio' (menu governado pelo branch tipo).
Remove as telas clínicas legadas (agenda/lancar-gto/proteses/tratamentos/dashboard) do
fallback do protético em Sidebar.tsx e da lista de permissões em App.tsx; o fallback fora do
contexto laboratório fica mínimo (notificações/clínicas/config/diretório).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fecha o Modo 1 (link seguro do protético sem conta):
- GET /api/protese/os/:id/link/status: link ativo, nº de acessos, último acesso e expiração.
- UI (aba Monitoramento, modo clínica): mostra status do link com Copiar / WhatsApp / Revogar
e os contadores de acesso/expiração; gera sob demanda.
Conversão por herança é nativa (a OS já aponta para o protetico_id do destinatário). Validado em
DEV: acessos contados, expiração 60 dias, revogação → status inativo + leitura pública 404.
Modo 1 concluído (1a leitura + 1b ação + 1c gestão).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Pelo link /p/TOKEN o protético (sem conta) passa a ATUAR na OS, tudo auditado como "<nome> (link)":
- POST /api/p/:token/custodia — confirmar recebimento / devolução (clínica↔lab)
- POST /api/p/:token/status — avançar a produção (recebido…finalizado); entregue/cancelado
seguem exclusivos da clínica (400 pelo link)
- POST /api/p/:token/foto — anexar foto do trabalho
Página pública ganha a seção "Atualizar status" (custódia/etapa/foto) enquanto a OS não está
finalizada; header alterna Acompanhamento/Somente leitura.
Validado em DEV: recebimento, avanço de etapa, foto; entregue pelo link → 400.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provedor de Prótese SEM conta (doc/MODO1-LINK-SEGURO-PROTESE):
- Token por OS: tabela protese_os_link (aleatório 24B base64url, expira 60 dias, revogável,
conta acessos). POST /protese/os/:id/link (gera/recupera) + POST .../link/revogar.
- Leitura pública GET /api/p/:token (sem auth): payload curado com a mesma blindagem soLab —
SEM paciente_id (CPF) e SEM valor cobrado ao paciente; mostra trabalho, etapas, componentes,
fotos, custódia, ocorrências, histórico e custo do lab.
- Página pública ProtesePublicView (mobile-first 320px+), interceptada no index.tsx antes do
app autenticado; CTA "Criar conta grátis". Botão Gerar link / WhatsApp / Copiar na aba
Monitoramento (modo clínica).
- Validado em DEV: leitura, blindagem (CPF/valor ocultos), token inválido→404, revogação→404.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- OnboardingChat: adiciona o card de atalho "Protéticos" (perfil profissional → protetico),
ao lado de Dentistas/Biomédicos. O cadastro de protético já funcionava via "Sou profissional",
faltava o atalho na vitrine.
- doc/MODO1-LINK-SEGURO-PROTESE: desenho do "Provedor sem conta" — link seguro /p/TOKEN
(token por OS, revogável; rotas públicas com a mesma blindagem soLab; página pública read+ação;
CTA de conversão com herança de histórico). Evolução futura, sem refatoração.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provedor de Prótese, Fase 5 (doc/PROVEDOR-PROTESE-DECISAO.md) — sobre a captura das fases 2-4:
- Indicadores do lab (GET /protese/lab/indicadores, só dono): entregues, tempo médio, atraso %,
retrabalho % (garantia), ocorrências resolvidas %, componentes ausentes. Tela lab-indicadores.
- Nota ScoreOdonto (0-10) = 10 − (atraso%×3 + retrabalho%×4 + ocorrência%×3), só com ≥3 entregas
("score em formação" abaixo disso). Apenas ocorrências RESOLVIDAS pesam (contraditório respeitado).
- Ranking: getProteseLaboratorios devolve a nota por protético e ordena internos→nota→nome; a
clínica vê ★ nota no dropdown de Nova OS e Lançar GTO.
Roadmap do Provedor de Prótese concluído (Fases 1-5). Marketplace transacional e Modo 1 (link
seguro sem conta) ficam como evolução futura.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provedor de Prótese, Fase 4 (doc/PROVEDOR-PROTESE-DECISAO.md):
- PF/PJ: clinicas.pessoa_tipo (individual | laboratório) + documento (CPF/CNPJ) editáveis.
Tela "Laboratório & Equipe" (lab-equipe). GET/PATCH /protese/lab.
- Equipe: novo vinculos.role='tecnico_protese'. Dono convida por e-mail (ensureUsuarioPorEmail
→ credencial temporária). GET/POST/DELETE /protese/lab/equipe (só dono).
- Acesso estendido: proteseOsAccesso reconhece o técnico (vínculo no laboratorio_id) e a bancada
passa a usar labDoUsuario (dono OU técnico). Técnico opera a produção; menu reduzido e sem
clientes/financeiro/equipe (endpoints retornam vazio/403). Gestão é exclusiva do dono.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provedor de Prótese, Fase 3 (doc/PROVEDOR-PROTESE-DECISAO.md):
- Clientes (lab-clientes): clínicas que enviam OS, com OS totais/ativas/atrasadas/entregues,
faturado e a-receber por cliente. GET /protese/lab/clientes (agrega por clinica_id no escopo
do laboratório).
- Financeiro do lab (lab-financeiro): KPIs faturado/recebido/a-receber + extrato de recebimentos
(pagamentos lado lab) com clínica/paciente/forma/data. GET /protese/lab/pagamentos.
Regra: faturado = custo das OS entregues (≠ garantia); a-receber = faturado − recebido.
- Menu do laboratório ganha CLIENTES e FINANCEIRO (Sidebar + App rotas/contexto + nova
LabClientesView com abas).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Provedor de Prótese, Fase 1 do roadmap (doc/PROVEDOR-PROTESE-DECISAO.md):
- Origem da OS: bancada e detalhe passam a trazer clinica_nome (subquery em clinicas);
o protético vê a clínica de origem na lista da bancada e no topo do modal. Destrava o
cenário multi-clínica (Clínica A/B/C → mesmo laboratório).
- Blindagem de CPF (LGPD): confirmado que pacientes.id É o CPF. O provedor de prótese
(lab que não é da clínica) deixa de receber paciente_id no detalhe e na bancada,
mantendo paciente_nome; a clínica continua vendo o CPF para operar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Etapas repetíveis/puláveis: cada etapa tem ação Ir/Voltar/Repetir (não só "avançar
para a próxima"). 'entregue' segue na Linha do tempo.
- Ajustes do trabalho (aba Etapas): editar cor/material (PATCH .../os/:id); trocar o
trabalho por outro + MOTIVO obrigatório (POST .../trocar); acréscimo/redução do valor
cobrado do paciente com observação (POST .../ajuste-valor) — tudo auditado no histórico.
- Privacidade: o protético (lab que não é da clínica) NÃO vê o que o paciente paga/deve —
GET detalhe omite pagamentos do lado clínica e zera o valor cobrado; a bancada também
zera o valor. O ajuste de valor do paciente é exclusivo da clínica (403 para o lab). No
front, o modo bancada esconde "Recebido do paciente".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Aba "Linha do tempo" movida para o FINAL (entregue/cancelar continuam nela).
- Etapas agora avançáveis também pela clínica (não só pelo lab): nova lista "Etapas do
trabalho" na 1ª aba, com botão "Avançar" por etapa. Backend: avanço da produção passa
a aceitar lab OU clínica de origem (auditado por actor). 'entregue' segue na timeline
(exige foto).
- Impressão por etapa em DOIS formatos: térmica (bobina 80mm) e laser (A4), com os dados
da OS preenchidos no recibo (paciente, trabalho, dentista, lab, dentes, material/cor,
componentes, prazo, local atual + assinaturas).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reorganiza o gerenciamento da OS em ABAS (sem o scrollão único):
- Etapas: dados + stepper; substitui entregue/cancelar por "imprimir cupom" de cada
etapa (comprovante imprimível que circula com o trabalho — janela de impressão).
- Linha do tempo: histórico com data/hora/autor; AQUI ficam marcar entregue / cancelar
(e o fluxo do lab / acionar garantia).
- Itens & Valores: componentes, fotos e pagamentos.
- Monitoramento: custódia do trabalho (clínica ↔ laboratório) — "protético retirou" /
"devolveu à clínica", com local atual em destaque e histórico de movimentações.
Backend: protese_os.local_atual + tabela protese_os_custodia + POST .../custodia
(valida transição, registra movimento e evento). GET detalhe expõe local_atual + custodia.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Reformula o modal de detalhe da OS de prótese, fechando os gaps de gestão:
- Etapas: stepper visual do fluxo (solicitado→…→entregue) com a etapa atual e datas.
- Fotos: agora anexáveis TAMBÉM no modo clínica (antes só na bancada — beco sem saída
para entregar), com autoria (quem anexou), data e legenda; remover foto. Toda foto
entra no histórico.
- Componentes enviados: nova tabela protese_os_componente — item, qtd, quem enviou e
quando (ex.: implante, pilar, modelo). Add/remover.
- Valores recebidos (dois lados): nova tabela protese_os_pagamento — lado='clinica'
(paciente→clínica) e lado='lab' (clínica→lab), com totais, forma, autor e data.
- Auditoria: histórico com data+HORA e autor; foto/componente/pagamento viram eventos
rastreados. Helpers carregaOSComAcesso/logEventoOS reaproveitados nos sub-recursos.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Workspace tipo='laboratorio' ganha menu próprio (PAINEL DO LAB + BANCADA),
isolado das telas clínicas — espelha o tratamento de tipo='sala'. lab-bancada
reaproveita ProteseView (modo bancada); lab-home é o novo LabHomeView (fila por
status, atrasadas, entregues e faturamento do mês a partir do que já existe).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Workspace do protético passa a ser tipo='laboratorio' (re-tag dos existentes +
novos nascem assim no /api/register). Área de gestão própria, como a clínica.
- Roteamento por laboratorio_id: OS nascem com o lab (POST /os e GTO→OS); a
Bancada filtra por laboratorio_id com fallback por protetico_id (OS legadas).
Helper labDoProtetico(). Backfill aditivo + índice.
- Receita espelhada (2.1): a entrega lança RECEITA no workspace do lab
(clinica_id=laboratorio_id, valor=os.custo), espelho da DESPESA da clínica —
idempotente (financeiro_lab_id), isolado em try/catch.
fix: corrige coluna `paciente_nome`→`pacientenome` no INSERT da DESPESA de prótese
(bug pré-existente da Fase 1, em produção): a entrega de OS com custo>0 abortava
com "column paciente_nome does not exist". A mesma correção vale para a RECEITA nova.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Funcionário/membro com vínculo na clínica dona da sala passa a ter a sala como
workspace de acesso OPERACIONAL (papel_sala='operador'): vê a agenda da sala e
bloqueia horário para manutenção, sem locação nem financeiro. O Painel da Sala
detecta o modo operador e esconde recebíveis/relatório/baixa, mostrando só a
agenda + ação de bloqueio.
Bloqueio de manutenção: reserva tipo='manutencao' (coluna nova, default
'locacao'), valor 0, nasce 'confirmada' (sem aprovação) e NÃO gera recebível.
Reaproveita o anti-conflito de horário da sala (409 em sobreposição) e o
cancelamento por solicitante/unidade. A agenda renderiza o bloqueio em cinza.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- FASE2-PROTETICO-AREA: Laboratório como workspace de 1ª classe (tipo='laboratorio'),
roteamento por laboratorio_id, área de gestão própria, financeiro espelhado.
- FASE2-IMPL-2.0-2.1: detalhamento de implementação (migrações, backfill, bancada,
receita espelhada, menu da área).
- ANALISE-AREA-RECEPCAO-TC: gap de permissões da recepção fundamentado em modelos
validados (Treatment Coordinator / RBAC / Lab Case Manager).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Os menus de locador (MINHAS SALAS) e locatário (ALUGAR SALAS) eram exibidos a
"todos menos superadmin", vazando para funcionário e paciente — papéis que não
são titulares de sala e não tomam decisões de locação. Passa a exibir apenas a
papéis que podem ser titulares (donosala/donoclinica/donoconsultorio/admin/
dentista/biomedico/protetico).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
PAGINAS_RBAC não listava 'proteses' nem 'contratos', então essas páginas não
eram concedíveis por nenhum cargo (nem via "MARCAR TODAS"/GERENTE, que derivam
de TODAS_PAGINAS = flatMap de PAGINAS_RBAC). Resultado: era impossível um dono
dar acesso à área de Prótese a um funcionário pela interface.
Adiciona ambas ao grupo ATENDIMENTO e inclui proteses/lancar-gto nos templates
RECEPÇÃO e AUXILIAR (alinhado ao papel de Treatment Coordinator).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Itens de GTO ligados a um produto do catálogo do protético geram, na
finalização da GTO, uma OS de prótese (status 'solicitado') na Bancada do
laboratório — idempotente por gto_item_id e isolado em try/catch para nunca
derrubar o finalize. Migrações aditivas (gto_items.produto_id/protetico_id,
protese_os.gto_item_id, re-tag de especialidades para area='protese').
No Lançar GTO, a especialidade de prótese troca o seletor de procedimentos
pelo fluxo laboratório → produto → valor → observação. Busca de pacientes
passa a ser server-side com debounce (antes filtrava só a 1ª página).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- ClinicasView: botão '+ Nova clínica/consultório' + modal de criação,
gateado pelo papel da conta (donoclinica/donoconsultorio/admin).
- Corrige applyWorkspace destrutivo no onboarding: usa refreshWorkspaces
(acrescenta a unidade à lista, em vez de sobrescrever as existentes).
Antes não havia caminho de UI para criar uma 2ª clínica fora do
onboarding; o backend já suportava N clínicas. Validado em DEV (8020).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Alinha o documento ao git HEAD/produção atual. Mantém intactas as
menções históricas (validação em v1.0.16, colisão de tag v1.0.14).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Atualiza STATUS-SEGURANCA-E-PRODUCAO.md: cabeçalho (prod v1.0.19), nova
seção "Fila A concluída" (push → fix CI → build → tag/promote → backup →
verificação), seção A marcada como feita, commits agora publicados e
"Como retomar" com pendências restantes (B + A.2) e rollback.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
O compose interpola environment: (com fail-fast `:?` em SCOREO_DB_PASS)
mesmo só no `docker compose build`, e o runner não tem .env → build abortava
(run #29, commit 8a27f3b). SCOREO_DB_PASS é runtime-only (environment:, não
build-arg), então um placeholder satisfaz a interpolação sem entrar na imagem.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- STATUS-SEGURANCA-E-PRODUCAO.md: a rotação do JWT_SECRET deixa de ser
atribuída ao commit fcf2fb1 (que só remove .env/adiciona .dockerignore) —
passa a constar como ação operacional na VPS, sem commit (segredo não
versionado). Ajusta a contagem: 13 commits da sessão (inclui este doc),
repo ahead 14 de origin/main (o 14º, docs/LEIA, é anterior à sessão).
- dev-build.sh: builda o ambiente de DEV injetando APP_VERSION/GIT_COMMIT/
BUILD_TIME a partir do git (git describe), espelhando o deploy-prod.sh.
/api/version em DEV deixa de mostrar apenas "dev".
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- documentação/MAPA-FUNCIONAL-COMPLETO.md: inventário de rotas/telas/botões/fluxos,
matriz de módulos, mapa de conexões (mermaid) e notas — baseado em evidências do código.
- documentação/AUDITORIA-ESTRATEGICA-MODELAGEM.md: análise Pessoa→Vínculo→Workspace,
entidades mal classificadas e riscos arquiteturais.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Novo helper requireCapabilityFromOrders(cap, tabela): deriva o clinicaId do 1º
item de req.body.orders, fechando o RBAC dos catálogos.
- Aplica em PUT /{especialidades,procedimentos,dentistas}/reorder (cap do catálogo).
Antes eram authGuard puro (qualquer autenticado reordenava catálogo de qualquer clínica).
- Validado em DEV: dono 200; dentista 403; id inexistente 404; lista vazia 400.
Marketplace (salas/sala-reservas/propostas): AUDITADO — já protegido por checagem de
POSSE nos handlers (owner_usuario_id / profissional_id destinatário / vínculo p/ cancelar).
Não há gap; capability-gating seria incorreto (modelo é posse cross-clínica). Sem mudança.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gateia 16 rotas clínicas remanescentes a 'agenda' (staff clínico; bloqueia paciente):
- coleções (requireCapability): agenda/presenca (GET+POST), agenda/pendencias,
agenda/atividade, agenda/importar-google, interesses (GET+POST), dentistas/horarios (POST),
dentistas/:dentistaId/horarios (GET)
- /:id (requireCapabilityRow, clinicaId da linha): agenda/pendencias/:id/resolver,
dentistas/horarios/:id (DELETE), agendamentos/:id/{avaliacao,historico},
pacientes/:id/{score,faltas,familia}
As /:id eram authGuard SEM validação de tenant — agora o requireCapabilityRow valida
vínculo+cargo pela clínica da linha (fecha também o gap cross-tenant).
Confirmado que telas de paciente (MeusTratamentos/Notifications) não usam nenhuma delas;
detalhes de paciente são só do PatientsView (funcionário+dono).
Validado em DEV: dono+dentista passam em tudo (200/404); row real→200, fake→404.
Residual cosmético (fora do sub-pass): rotas /reorder (sem clinicaId/:id, baixo impacto).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gateia 18 rotas (tenantGuard + requireCapability), espelhando o frontend:
- orcamentos (GET/POST/PUT/DELETE) → 'orcamentos' (funcionário + dono)
- contratos (modelos CRUD+duplicar; instâncias CRUD+enviar+assinar+cancelar+
gerar-cobranca; GETs) → 'contratos' (funcionário + dono)
'assinar' incluído: usa tenantGuard+loadContratoScoped (quem assina é membro da
clínica registrando a assinatura via ContratosView — não há fluxo de contraparte
externa). Todos os endpoints de contrato são usados só no ContratosView (funcionário+dono).
Propostas (marketplace, autorização por posse do profissional) ficam para sub-pass próprio.
Validado em DEV: dono acessa (fake→404); dentista 403.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Gateia 15 rotas (cap espelhando o frontend):
- leads (GET/POST/converter) → 'leads' (funcionário + dono)
- pacientes mutações (export, POST, PUT/:id) → 'agenda' (staff clínico; bloqueia
paciente; INCLUI dentista — OrthoView cria/edita paciente)
- agendamentos (POST + ações /🆔 PUT, DELETE, confirmar, falta, remarcar, restaurar,
reencaminhar, solicitar-avaliacao) → 'agenda' (via requireCapabilityRow nas /:id)
Escolha de 'agenda' como discriminador 'staff clínico vs paciente': é a única capability
presente em funcionário/dentista/biomédico/protético/dono e AUSENTE em paciente — casa com
quem realmente opera (inclui o dentista que mexe em paciente pelo Ortho).
GETs de operação (lista de agendamentos/pacientes, detalhes) seguem abertos (consumidos por
todas as telas clínicas). Validado em DEV: dono/dentista passam onde devem; leads nega dentista;
reads 200; negação por linha sem apagar dados.
Deferido (sub-pass): presença, pendências/resolver, importar-google, interesses,
detalhes de paciente (score/faltas/família) e horários de dentista.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Refatora a autorização: extrai capabilityCore; requireCapability passa a derivar o
clinicaId da requisição (param/body/query) quando não há tenantGuard; adiciona
requireCapabilityRow(cap, tabela) p/ rotas /:id cujo clinicaId vem da LINHA.
Gateia 12 rotas (cap por cargo, espelhando o frontend):
- especialidades/procedimentos: POST + PUT/:id + DELETE (dono OU biomédico)
- planos: POST + PUT/:id + DELETE (dono)
- dentistas: POST + PUT/:id + DELETE/:id (dono)
GETs de catálogo seguem abertos (dados de referência usados em toda a app).
Corrige também risco pré-existente: POST/PUT de catálogo usavam authGuard SEM validar
vínculo (escrita cross-tenant) — agora validam vínculo + cargo.
Deferido: rotas /reorder (sem clinicaId/:id; baixo impacto) e horários de dentista (grupo agenda).
Validado em DEV: dono 404(fake)/dentista 403; GETs 200; negação por linha sem apagar dados.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aplica requireCapability('gestao-equipe') (dono-only por padrão; ou cargo com a
permissão) APÓS tenantGuard em 12 rotas: membros, setores e funcoes (GET + mutações).
- reset-senha: troca authGuard → tenantGuard + requireCapability (antes não validava
o vínculo do solicitante; só hierarquia).
- PUT /clinicas/:id/color: eleva de 'tem vínculo' para 'dono/admin' (igual a /nome).
- nome, PUT /clinicas/:clinicaId e PUT /areas já tinham checagem de dono (mantidos).
- GET /clinicas/:clinicaId (branding) segue legível por qualquer membro (por design).
Checagens de hierarquia (nivelNaClinica) preservadas como defesa secundária.
Validado em DEV: dono ok; dentista 403 (inclui /color); outra clínica 403.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Adiciona requireCapability(cap) — espelha o isViewAllowed do frontend
(superadmin global; dono donoclinica/donoconsultorio/admin; cargo com
permissoes explícitas da funcao; senão mapa padrão por papel) — e aplica
APÓS o tenantGuard em 22 rotas:
- financeiro: GET/POST/PUT/DELETE + relatorio (cap 'financeiro')
- glosas: listar/itens/recebiveis/criar/recorrer/recuperar/excluir (cap 'glosas')
- comissoes: regras GET/PUT/DELETE + relatorio (cap 'comissoes')
- repasses: fechar/listar/detalhe/pagar/cancelar/comprovante (cap 'comissoes')
/repasses/comprovante/:id/raw fica de fora (URL assinada, sem tenantGuard).
Antes: bastava ter vínculo (tenantGuard) p/ chamar a API — UI escondia, backend não.
Validado em DEV: dono 200; dentista 403; outra clínica 403 (isolamento intacto).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- /update (migração de banco) sai da lista sempre-liberada do isViewAllowed;
passa a exigir superadmin (não-superadmin cai na view padrão; deslogado vai p/ landing).
- ROUTE_MAP ganha /comissoes e /glosas (existiam em VIEW_TO_ROUTE mas faltavam aqui;
refresh/deep-link nessas telas caía em dashboard).
- (cadastro-dentista já estava mapeado — correção de equívoco da auditoria.)
- Validado em DEV: build compila, app sobe, rotas resolvem (HTTP 200 SPA).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Senha do banco deixa de ter default no compose: vem de SCOREO_DB_PASS (.env raiz
em DEV; provisionar fora do git em PROD). `:?` faz o up falhar se faltar (fail-fast).
- DRAGONFLY_URL (com senha) sai do compose e passa a vir do env_file backend/.env.
- Host/usuário/banco mantêm default (não são segredo).
- Validado em DEV: db (pgdev) ok, cache ok, login ok.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- backend/.env deixa de ser versionado (continha JWT_SECRET, DATABASE_URL,
DRAGONFLY_URL e chaves de IA); arquivo preservado em disco (dev e prod).
- backend/.dockerignore: impede que segredos sejam copiados para a imagem
(Dockerfile usa COPY . . e não havia .dockerignore).
- .gitignore reforçado (**/.env, .secrets, *.dump, backups de env).
- backend/.env.example documenta as variáveis sem valores.
- JWT_SECRET rotacionado em dev e prod (fora do git).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
VPS 4 Builder