# ScoreOdonto — Pendências, Tutoria e Deploy (dev)

> Documento de handoff. Última atualização: 2026-06-08.
> Contexto completo da arquitetura de agenda/workspaces: ver memória do projeto
> `project-agenda-workspace-architecture.md`.

---

## 1. Deploy no container de dev (IMPORTANTE)

**`dev.scoreodonto.com` NÃO é Vite HMR.** É servido pelo container
`scoreodontocom-scoreodonto-frontend-1` (projeto compose `scoreodontocom`,
de `docker-compose.yml`) rodando **nginx sobre um `vite build` estático**.
Edições no fonte **não aparecem sozinhas** — exigem rebuild + recreate manual.

### Banco é de PRODUÇÃO (compartilhado)
- Backend de dev (VPS 4) e produção (VPS 1) usam o **MESMO Postgres na VPS 3**
  (`10.99.0.3:5432/scoreodonto`). Não há banco de dev separado.
- Migrações aditivas idempotentes rodam no startup (`runMigrations()` em `server.js`).
- Qualquer dado criado "testando" em dev é **dado real de produção** → sempre limpar.
- A constraint `vinculos_role_check` é DROP+ADD a cada boot. Ao deployar na prod,
  o `server.js` de lá PRECISA incluir `'protetico'`, senão o ADD falha se já houver
  vínculo protético criado via dev.

### Comandos de deploy
```bash
cd /home/deploy/stack/scoreodonto.com
# Frontend (server.js NÃO é hot-mount; só plugins/sessions/media são):
docker compose build scoreodonto-frontend && docker compose up -d --force-recreate scoreodonto-frontend
# Backend:
docker compose build scoreodonto-backend  && docker compose up -d --force-recreate scoreodonto-backend
```
- Verificar: o hash do bundle em `https://dev.scoreodonto.com/` (`/assets/index-*.js`) muda.
- `vite build` NÃO faz type-check bloqueante → erros TS não quebram o build, mas
  podem estourar em runtime. Conferir após deploy.
- Logs de migração: `docker logs --tail 20 scoreodontocom-scoreodonto-backend-1 | grep -i migration`
  (esperado: `[MIGRATION] all migrations OK`).

### Efeito colateral relevante
Quando esta sessão começou, o dev servia um **build antigo** (`index-DWdouzmk.js`).
Os rebuilds passaram a publicar o **working tree atual**, que inclui vários arquivos
**untracked** (WIP de outra sessão): `OrthoView`, `OrthoReports`, `OrthoPhotoWorkspace`,
`TutoriaSection`, `SuperAdminView`, `GestaoEquipeView`, `Tutor*View`, `plugins/`, etc.
→ Bugs nesses arquivos só passaram a **aparecer agora** por causa do deploy, não por edição.

---

## 2. TUTORIA no modal de tratamento de orto — ✅ CAUSA RAIZ RESOLVIDA

**Relato do usuário:** "ferrou com a tutoria no modal que administra o tratamento de orto."

**CAUSA RAIZ (confirmada):** as telas WIP (`TutoriaSection`, `OrthoPhotoWorkspace`,
`PhotoAnnotator`, `TutorPainelView`, `TutorCandidaturaView`, `AdminGestaoTutoresView`)
chamavam **24 métodos do `HybridBackend` que não existiam** em `services/backend.ts`
(só `getCurrentUserName` existia) → crash `HybridBackend.X is not a function` assim que
o rebuild publicou esses componentes. Além disso o **backend não tinha nenhuma tabela
nem endpoint** de orto/tutoria.

**CORRIGIDO nesta sessão:**
- `services/backend.ts`: adicionados os 24 métodos via helper `_ortoJson` (chama o
  endpoint real e **degrada com fallback seguro** se a rota faltar → fim do crash).
- `backend/server.js`: **9 tabelas** (`ortho_photo_session`, `ortho_photo`,
  `ortho_photo_annotation`, `ortho_tutor_config`, `ortho_tutor_candidatura`,
  `ortho_tutor_profile`, `ortho_tutoring_request`, `ortho_tutoring_message`,
  `ortho_tutoring_photo_package`) + **25 endpoints** + upload real de fotos via `multer`
  no volume persistente `/app/media`, servidas por `/api/orto/fotos/:id/raw`.
- `backend/package.json`: + `multer`.
- Validado: migrations OK, 9 tabelas no banco, endpoints respondendo (200/401/404).
  Frontend e backend rebuildados → live no dev.

**FEITO depois:**
- [x] `OrthoDetailPanel` agora renderiza `OrthoPhotoWorkspace` + `TutoriaSection`
      (no lugar do `PhotoCompare` placeholder) — a tutoria/fotos vivem no modal do paciente.
- [x] **Sessões mensais**: orto é mensal → `ortho_photo_session` ganhou `rotulo`+`data_ref`;
      o workspace cria sessão por mês (input `month`) + especiais (INICIAL/FINALIZAÇÃO/
      PÓS-CONTENÇÃO); tabs dinâmicas ordenadas. Validado end-to-end.
- [x] **Exportar documentação**: botão EXPORTAR → modal seleciona "completa" (tudo) ou
      fotos específicas (checkbox por foto, agrupado por sessão) → abre view de impressão
      (navegador salva como PDF). Sem dependência nova.

**FEITO depois (cont.):**
- [x] **Tratamentos de orto persistem**: tabelas `ortho_tratamento` + `ortho_evolucao`
      (triagem/diagnóstico/flags em JSONB); endpoints GET/POST/PUT + `/evolucoes` +
      `/finalizar`. `backend.ts` troca o mock t1/t2 por chamadas reais (mappers snake↔camel).
      Botão "NOVO TRATAMENTO" abre modal de criação (paciente/plano/diagnóstico/triagem).
      Adicionar evolução atualiza `fio_atual`/`ultima_consulta`; finalizar grava contenção.
      Validado end-to-end.
- [x] Comparador cross-sessão (mesmo slot, sessão A × B / mês a mês) com modos
      **lado a lado / slider / sobreposição**.

**FEITO depois (cont.):**
- [x] **MercadoPago real**: `POST /tutoria/candidaturas/:id/pagamento` cria uma
      preference (Checkout Pro) com a `taxa_inscricao` da config, `external_reference=cand:<id>`,
      `back_urls` e `notification_url` → devolve `init_point`. `POST /tutoria/mp-webhook`
      (público) consulta o pagamento e, se `approved`, ativa o tutor automaticamente
      (`ativarCandidaturaTutor`, reaproveitado pelo confirmar-pagamento do admin).
      Sem `mp_access_token` na config → fallback honesto (ativação manual). Admin configura
      token/taxa em `AdminGestaoTutoresView`. **Caveat:** não testado contra a API real do MP
      (sem credenciais); fallback e webhook-noop validados.

**FEITO depois (cont.):**
- [x] **GestaoEquipeView corrigida** (estava roteada em `/gestao-equipe` e quebrava igual a
      tutoria — chamava 12 métodos inexistentes). Backend: tabelas `setores`/`funcoes` +
      colunas `vinculos.setor_id/funcao_id`; endpoints membros (GET com nomes, POST com
      setor/função, **+PUT**, DELETE) e setores/funções CRUD (todos `tenantGuard`).
      `backend.ts`: os 12 métodos. Validado end-to-end + isolamento de tenant (403).
- [x] **PDF nativo** (`jspdf` adicionado às deps): o EXPORTAR agora gera um PDF real
      (fotos agrupadas por sessão, 3/linha, legenda do slot) via canvas→jsPDF; botão
      IMPRIMIR mantém o print→PDF como alternativa. **Caveat:** geração é client-side
      (jsPDF+canvas), validei só install/tsc/build, não a renderização no navegador.

**FEITO depois (cont.):**
- [x] **Planejamento visual** no `PhotoAnnotator`: grupo PLANEJ. com **vetor de
      movimentação** (haste + barra de origem + cabeça larga, arrastar da posição atual →
      destino), **marca de extração** (X, clique no dente) e **linha média** (referência
      vertical tracejada, clique). Persistem como anotações (JSONB) — sem mudança no backend.

**FEITO depois (cont.):**
- [x] **Type-gaps zerados — `tsc` do frontend agora passa com 0 erros.** Bug real
      corrigido em `FinanceiroView` (`getPacientes` retorna `{data,total}` → usava o objeto
      inteiro como lista, quebrando a busca → agora `results.data`); `TutorPainelView` ganhou
      os campos financeiros na interface `Solicitacao`. Login/RxConfig limparam junto.

**FEITO depois (cont.):**
- [x] **Calibração de escala (mm)** no `PhotoAnnotator`: ferramenta ESCALA (arrastar sobre
      distância conhecida → informa o valor real em mm) define mm/px; os **vetores de
      movimentação passam a exibir a magnitude em mm**. Rótulos renderizados fora do SVG
      (HTML posicionado por `imgDim`) p/ não distorcer com o viewBox. Persiste no JSONB.
- [x] `RxConfigView` usava props inexistentes do `PageHeader` (`subtitle`/`icon`) → trocado
      por `description` (subtítulo agora aparece). **Resta 1 erro tsc pré-existente** em
      `LoginView:490` (comparação morta no fluxo de cadastro/auth) — deixado de propósito:
      é lógica de auth e mascarar esconderia a intenção do autor; funciona em runtime.
- [x] Comparador ganhou modo **EVOLUÇÃO**: mesmo slot em todas as sessões/meses lado a
      lado (faixa horizontal cronológica) — além de lado a lado / slider / sobreposição.
- [x] Vínculo com o cadastro de pacientes: o modal de Novo Tratamento tem busca no
      cadastro (`getPacientes`) que preenche `paciente_id` + nome + nascimento; digitar
      livre cria paciente avulso (sem vínculo). Frontend-only, validado por tsc/build.

---

## 2b. Apuração original (histórico)

**Apuração (fatos):**
- Não foi editado nenhum arquivo de orto/tutoria nesta sessão. Todos estão **untracked**
  (`git status` → `??`): `OrthoView.tsx`, `OrthoReports.tsx`, `TutoriaSection.tsx`,
  `TutorPainelView.tsx`, `TutorCandidaturaView.tsx`, `AdminGestaoTutoresView.tsx`.
- `OrthoView.tsx` **não tem nenhuma referência a "tutor"**.
- `TutoriaSection.tsx` **não é importada em lugar nenhum** (código solto/WIP).
- Quem referencia tutor: **`OrthoReports.tsx`** (e os Tutor*View).
- Único toque indireto possível: `services/backend.ts` (eu alterei `getCurrentRole`,
  mas só com fallback p/ superadmin quando não há workspace — não afeta dentista/tutoria;
  `getCurrentUserName`, usado pela TutoriaSection, NÃO foi alterado).
- Provável causa: o rebuild publicou a versão WIP da tutoria que antes não estava no ar.

**PENDENTE — preciso do sintoma para diagnosticar:**
- [ ] Onde exatamente? (OrthoView do paciente / OrthoReports / "Meus Tratamentos" / outro)
- [ ] O que acontece? (crash/tela branca / botão sumiu / dado não carrega / erro console)
- [ ] Mensagem de erro no console do navegador?

→ Com o sintoma, achar a causa raiz em `OrthoReports.tsx` / `TutoriaSection.tsx` e corrigir.

---

## 3. Status das fases (arquitetura agenda/workspaces)

- [x] **Fase 0** — Cadastro: 5 cards de perfil com preço (Clínica R$499 separada). `LoginView.tsx`.
- [x] **Fase 1** — Workspace pessoal automático no `/api/register` (dentista/protético/paciente);
      `clinicas.tipo`+`owner_id`; `protetico` adicionado ao `vinculos_role_check`. Fim do beco "aguardando-convite".
- [x] **Fase 2** — Identidade global: `dentistas.usuario_id` + backfill por email; criação seta usuario_id.
- [x] **Fase 3** — Anti-overbooking global: `POST /api/agendamentos` resolve identidade do
      profissional e bloqueia sobreposição em QUALQUER clínica → 409 `{conflito, ocupado, podeRegistrarInteresse}`.
- [~] **Fase 4** — Fila de interesse:
  - [x] Backend: tabela `interesses_agenda`, `POST/GET /api/interesses`, hook no DELETE de
        agendamento que notifica interessados como `enviado_por='sistema'` e marca `liberado`.
  - [x] Frontend Parte 1: AgendaView mostra painel "Horário ocupado" no 409 → registrar interesse (com minutos de espera).
  - [x] Frontend Parte 2: dentista vê "Pedidos de interesse" (sino + badge + modal; GET retorna `clinica_nome`).
  - [x] `POST /api/clinicas` passou a setar `owner_id`+`tipo`.
  - [ ] **FALTA**: endpoint **"tentar liberar"** (clínica pede → dentista decide mover/cancelar o ocupante).
  - [ ] **FALTA**: **re-notificação periódica** do sistema enquanto o dentista demora (job/cron),
        sempre rotulada como "notificação do sistema" (impessoal).
- [ ] **Fase 5** — Odontodelivery: diretório (`disponivel_diretorio` já existe) → pedido de horário ao freelancer.

### Regras de negócio confirmadas
- Profissional não pode estar em 2 lugares ao mesmo tempo (invariante: 1 agendamento por slot).
- Conflito não é "não" seco: vira fila de INTERESSE (não trava o slot). Clínica pode: registrar
  interesse com tempo de espera (expira), escolher outro horário, ou pedir pro dentista liberar.
- Todos têm workspace (pessoal automático no cadastro).

---

## 4. Bugs pré-existentes encontrados (não introduzidos nesta sessão)

- [ ] **`notificacoes.lida` é smallint**, mas `POST /api/superadmin/notificacoes` insere boolean
      `false` → **recurso de notificação do superadmin quebrado** (corrigir para `0`).
      (No meu código novo já usei `0`.)
- [ ] **`POST /api/agendamentos` default `status='Agendado'`** viola `agendamentos_status_check`
      (só aceita Confirmado/Pendente/Concluido/Faltou) → criar sem status explícito dá 500.
      Frontend hoje sempre manda status válido. Não há status 'Cancelado' (cancelar = DELETE).
- [ ] **`PUT /api/agendamentos/:id`** (mover horário) **ainda não passa pelo check de overlap** da Fase 3.

---

## 5. Estado de versionamento

- **NADA foi commitado** nesta sessão. Tudo está no working tree, rodando contra o banco de prod.
- Regra do projeto: **commit/push só com autorização explícita** — o push dispara o pipeline de
  produção via webhook do Gitea (pode sobrescrever trabalho em andamento).
- Arquivos que ESTA sessão editou: `backend/server.js`, `frontend/App.tsx`,
  `frontend/components/Sidebar.tsx`, `frontend/services/backend.ts`, `frontend/views/AgendaView.tsx`,
  `frontend/views/LoginView.tsx`, `frontend/views/LandingPage.tsx`.
  (Demais arquivos modificados/untracked são WIP de sessões anteriores.)