- Protético interno: a clínica cadastra um protético que não usa a plataforma. Cria usuário "mudo"
(e-mail placeholder @interno.local + senha-fantasma; usuarios.email é NOT NULL/UNIQUE) + vínculo
interno (fora do diretório). POST /protese/proteticos-internos; botão "Cadastrar protético interno"
na Nova OS, que recarrega o dropdown e seleciona o novo.
- Carteira no link /p/TOKEN: botão "Meus trabalhos" → trabalhos em andamento/finalizados + mini
financeiro mensal (valores pagos ao protético). GET /api/p/:token/carteira, escopo da relação
clínica↔protético do token (não vaza outras clínicas; sem dados do paciente).
Validado em DEV: interno criado e acessível no dropdown; OS+link; carteira com andamento + R$250/2026-06.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Novo módulo de logística do lab (doc/AGENDA-COLETA-LAB):
- protese_coleta: agendamento de coleta (lab busca) / entrega (lab leva), com data/hora,
endereço, responsável, status. Ligado à OS.
- POST /protese/os/:id/coleta (agendar), GET /protese/lab/agenda (cronológica),
POST /protese/coleta/:id/status. 'realizada' MOVE a custódia automaticamente
(coleta→laboratorio, entrega→clinica) — fonte única do movimento físico. GET detalhe traz coletas[].
- UI: tela AGENDA (lab-agenda) agrupada por dia com "marcar realizada"; seção Coleta/entrega na
aba Monitoramento da OS (clínica e lab).
Validado em DEV: agenda coleta → realizada → custódia=laboratorio; lab vê na agenda.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 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>
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>
- 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>
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>
- VERDADE-HOJE.md e DEPLOY-PRODUCAO.md: produção v1.0.16 (commit 471c2c2);
tag promove por re-tag SEM rebuild (digest :v1.0.16 == :471c2c2, provado);
versão nasce da tag; constants.ts/update-version.js removidos. Passo 5 ✅.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Pasta única scoreodonto.com/doc/ com 9 docs que prestam:
VERDADE-HOJE (estado, principal), DEPLOY-PRODUCAO (runbook), BANCO-DEV-ESTRATEGIA,
REGISTRY, AUDITORIA-FUNCIONAL, BACKLOG-FINANCEIRO-V1, CRM_Ortodontia, RX_ARQUITETURA, RX_BACKLOG.
- Removidos os docs de infra sobrepostos/desatualizados (estado consolidado em VERDADE-HOJE;
histórico fica no git): arquitetura.md, deploy.md, CHECKLIST-DEPLOY-PRODUCAO.md,
PENDENCIAS.md, PENDENCIAS_E_DEPLOY.md.
- Pasta documentação/ eliminada.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>