- A clínica avalia o laboratório (1-5★ + comentário) após a entrega (protese_avaliacao, 1 por OS,
reavaliável). POST /protese/os/:id/avaliar; avaliação volta no GET detalhe.
- Nota ScoreOdonto passa a combinar 0.6·operacional + 0.4·satisfação (estrelas) quando há avaliações.
Selo "Verificado" (≥5 entregas). Exposto no marketplace (★nota · nº avaliações · Verificado) e nos
indicadores do lab (KPI Satisfação). Helper notasScorePorProtetico unificado (dropdown + marketplace).
- UI: seção "Avaliar o laboratório" na OS entregue (lado clínica); selo/avaliações no card do marketplace.
- Correção de passagem: FileText/Star importados em ProteseView (FileText faltava desde a fatia 3).
Validado em DEV: 6 entregas + 5★/3★ → nota 9.2, satisfação 4★, verificado (marketplace e indicadores).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Entidades protese_rfq + protese_rfq_cotacao. A clínica descreve o trabalho e convida N labs;
cada lab cota (valor/prazo/obs); a clínica compara (ordenado por preço) e escolhe → vira OS
(custo = valor da cotação) e a RFQ fecha (demais recusadas).
- Backend: POST/GET /protese/rfq, GET /protese/rfq/recebidas, POST /protese/rfq/cotacao/:id,
POST /protese/rfq/:id/escolher (cria a OS).
- Lado lab: tela Cotações (lab-cotacoes) — RFQs recebidas + responder.
- Lado clínica: botão Cotações na tela de Prótese — pedir multi-lab + comparar + escolher.
Validado em DEV ponta a ponta: pedido → cotação R$420 → escolha → OS criada → RFQ fechada.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
"Solicitar prótese" no card do protético abre o SolicitarProteseModal (lab pré-selecionado):
produto do catálogo (ou livre) + paciente + dentista + dentes + prazo + obs → cria a OS via
createProteseOS (que já aceita lab do diretório, sem vínculo prévio). Confirmação com CTA p/ a
Bancada. Modal auto-contido reusando getLaboratorioProdutos/getDentistas/getPacientes/createProteseOS.
Validado em DEV: OS criada para lab do diretório (Coroa de Zircônia, status solicitado).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
doc/MARKETPLACE-TRANSACIONAL-PROTESE: desenho do transacional (vitrine → solicitação → cotação
→ reputação), reusando catálogo/propostas/OS/score existentes.
Fatia 1: no card do protético no marketplace, "Ver catálogo de próteses" expande os produtos
(nome, preço, garantia) — reusa getLaboratorioProdutos (o catálogo já é acessível a quem está no
diretório, zero endpoint novo). Botão de contato vira "Solicitar prótese". A clínica passa a
decidir vendo serviços + preço + garantia + ★nota antes de contratar.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
GET /api/profissionais/marketplace passa a trazer a 'nota' dos protéticos (helper
notasScorePorProtetico, mesma fórmula da Fase 5 — só com volume mínimo). Card do protético
no marketplace exibe ★ nota. Ordem mantida por proximidade; a nota é comparação visível.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
VPS 4 Builder