VPS 4 Builder
6a88995146
"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>
3.2 KiB
Marketplace transacional de Prótese
Desenho (24/jun/2026). O último grande item do backlog do Provedor de Prótese. Princípio: transformar o diretório (descoberta) em jornada de compra — descobrir → ver serviços/preços → solicitar → cotar → contratar → vira OS. Reaproveita ao máximo o que já existe.
O que já existe (não recriar)
- Descoberta:
/api/profissionais/marketplace(busca por proximidade/especialidade) + Nota ScoreOdonto no card (feito). - Catálogo:
protese_produtos(nome, preço, garantia) +GET /api/protese/laboratorios/:id/produtos— já acessível a quem está no diretório (proteticoAcessivelPelaClinicaaceitadisponivel_diretorio). - Propostas:
propostas_profissional(clínica→profissional: mensagem,pendente→aceita/recusada). - Contratação: a clínica já cria OS para qualquer protético do diretório (Nova OS).
- Pós-venda: OS completa (etapas, custódia, ocorrências), financeiro, score — tudo pronto.
Conclusão: o "transacional" não exige nova fundação — falta costurar a jornada dentro do marketplace (hoje a clínica vê nome/nota/distância, mas não os serviços, e contrata por outra tela).
Fatias
✅ Fatia 1 — Vitrine (catálogo no marketplace) — IMPLEMENTADA
No card do protético no marketplace, "Ver catálogo" expande os produtos (nome, preço, garantia)
via getLaboratorioProdutos(id) (reuso — zero endpoint novo). A clínica passa a decidir vendo
serviços + preço + garantia + ★nota antes de contratar. Botão de contato vira "Solicitar
prótese" (proposta com contexto de prótese).
✅ Fatia 2 — Solicitação → OS direto — IMPLEMENTADA
"Solicitar prótese" (card do protético) abre o SolicitarProteseModal — fluxo enxuto com o lab
pré-selecionado: produto do catálogo (ou descrição livre) + paciente (busca) + dentista + dentes
- prazo + observações → cria a OS via
createProteseOS(que já aceita lab do diretório, sem vínculo prévio). Tela de confirmação com CTA para a Bancada. Optei por um modal próprio e auto-contido (reusa getLaboratorioProdutos/getDentistas/getPacientes/createProteseOS) em vez de extrair a Nova OS — menor risco. Validado em DEV: OS criada para lab do diretório (Coroa de Zircônia, status solicitado).
Fatia 3 — Cotação (RFQ) para trabalho sob medida
Quando não há produto de catálogo: a clínica descreve o trabalho e N labs cotam (preço + prazo);
a clínica escolhe e vira OS. Estende propostas_profissional com itens de prótese e valores, ou nova
protese_rfq + protese_rfq_cotacao.
Fatia 4 — Reputação pública e conversão
Avaliação da clínica ao final da OS (alimenta a Nota, hoje só operacional), selo "lab verificado", ordenar marketplace por nota dentro do raio.
Decisões de modelagem
- Catálogo público = catálogo atual (
protese_produtos); a vitrine só o exibe — sem duplicar. - Solicitação reusa a OS (não cria entidade paralela): toda contratação termina em
protese_os, preservando rastreabilidade/financeiro/score. - Cotação (Fatia 3) é o único caso que precisa de entidade nova (pré-OS multi-lab).