# Auditoria dos repositories contra a API

Fonte da documentacao: https://do5wegrct3.apidog.io/llms.txt

## Endpoints documentados

| Grupo | Metodo | Endpoint | Status no frontend |
| --- | --- | --- | --- |
| Autenticacao | POST | `/auth/v1/token?grant_type=password` | Sem repository dedicado |
| Autenticacao | POST | `/auth/v1/otp` | Sem repository dedicado |
| Autenticacao | POST | `/auth/v1/logout` | Sem repository dedicado |
| Autenticacao | GET | `/auth/v1/user` | Sem repository dedicado; relacionado a `profileRepository` |
| Usuarios | POST | `/delete-user` | Sem repository dedicado |
| Usuarios | POST | `/functions/v1/create-user` | Sem repository dedicado |
| Usuarios | POST | `/functions/v1/create-user-with-password` | Sem repository dedicado |
| Usuarios | POST | `/request-password-reset` | Sem repository dedicado |
| Usuarios | POST | `/functions/v1/user-info` | Sem repository dedicado; relacionado a `profileRepository` |
| Usuarios | POST | `/functions/v1/user-info-by-id` | Sem repository dedicado |
| SMS | POST | `/functions/v1/send-sms` | `communicationRepository` nao implementa chamada real |
| Pacientes | GET | `/rest/v1/patients` | Implementado em `patientRepository.getAll` |
| Pacientes | POST | `/rest/v1/patients` | Implementado em `patientRepository.create` |
| Pacientes | PATCH | `/rest/v1/patients?id=eq.{id}` | Implementado em `patientRepository.update` |
| Pacientes | DELETE | `/rest/v1/patients?id=eq.{id}` | Implementado em `patientRepository.remove` |
| Pacientes | POST | `/functions/v1/create-patient` | Implementado em `patientRepository.createWithValidation` |
| Pacientes | POST | `/functions/v1/register-patient` | Nao implementado |
| Medicos | GET | `/rest/v1/doctors` | `professionalRepository.getAll` usa mock |
| Medicos | POST | `/functions/v1/create-doctor` | Nao implementado |
| Agendamentos | GET | `/rest/v1/appointments` | `appointmentRepository.getAll` usa mock |
| Agendamentos | POST | `/rest/v1/appointments` | Nao implementado |
| Agendamentos | POST | `/functions/v1/get-available-slots` | Nao implementado |
| Disponibilidade | GET | `/rest/v1/doctor_availability` | Nao implementado |
| Disponibilidade | POST | `/rest/v1/doctor_availability` | Nao implementado |
| Disponibilidade | PATCH | `/rest/v1/doctor_availability?id=eq.{id}` | Nao implementado |
| Disponibilidade | DELETE | `/rest/v1/doctor_availability?id=eq.{id}` | Nao implementado |
| Disponibilidade | GET | `/rest/v1/doctor_exceptions` | Nao implementado |
| Disponibilidade | POST | `/rest/v1/doctor_exceptions` | Nao implementado |
| Storage | POST | `/storage/v1/object/avatars/{path}` | Nao implementado |
| Storage | GET | `/storage/v1/object/avatars/{path}` | Nao implementado |
| Reports | GET | `/rest/v1/reports` | `reportRepository.getInitialReports` usa mock |
| Reports | POST | `/rest/v1/reports` | Nao implementado |
| Reports | PATCH | `/rest/v1/reports?id=eq.{id}` | Nao implementado |

## Repositories ainda nao implementados

| Repository | Metodos atuais | Endpoint equivalente | Observacao |
| --- | --- | --- | --- |
| `analyticsRepository` | `getDashboardData` | Nao documentado | Retorna dados estaticos de KPIs, graficos e pacientes frequentes. |
| `appointmentRepository` | `getAll`, `getTodayTimeline`, `getPredictiveQueueSummary`, `getWeekDays` | Parcial: `GET /rest/v1/appointments`, `POST /rest/v1/appointments`, `POST /functions/v1/get-available-slots` | `getAll` deveria chamar a API; demais metodos sao derivados/visuais e nao aparecem na doc. |
| `communicationRepository` | `getCampaigns`, `getInitialMessages`, `getInitialTemplates` | Parcial: `POST /functions/v1/send-sms` | A API so documenta envio de SMS; nao ha endpoints para campanhas, mensagens ou templates. |
| `homeRepository` | `getDashboardOverview` | Nao documentado | Tela inicial usa agregados estaticos. |
| `medicalRecordRepository` | `getRecordTypes`, `getInitialRecords` | Nao documentado | Nao ha endpoint de prontuarios/medical records na doc atual. |
| `professionalRepository` | `getAll`, `getCoverageMap` | Parcial: `GET /rest/v1/doctors`, `POST /functions/v1/create-doctor` | `getAll` deveria usar doctors; `getCoverageMap` parece derivado de disponibilidade, mas nao bate direto com um endpoint. |
| `profileRepository` | `getCurrentUserProfile` | Parcial: `GET /auth/v1/user`, `POST /functions/v1/user-info` | Retorna perfil fixo; deveria consumir dados do usuario autenticado. |
| `reportRepository` | `getAdminUsers`, `getCurrentUser`, `getDoctors`, `getInitialReports`, `getReportTypes`, `getTemplates` | Parcial: `GET/POST/PATCH /rest/v1/reports` | Lista e metadados sao mockados; nao existem metodos de criar/atualizar usando API. |
| `settingsRepository` | `getIntegrations`, `getSections` | Nao documentado | Configuracoes exibidas sao estaticas. |
| `visitRepository` | `getCareQueue`, `getStages` | Nao documentado | Nao ha endpoint de atendimentos/fila/visits na doc atual. |

## Inconsistencias encontradas

- `patientRepository.getById(patientId)` nao bate com um endpoint documentado especifico. Ele chama `getAll()` e filtra em memoria; se a API aceitar filtro Supabase por id, o ideal seria usar `/rest/v1/patients?id=eq.{id}&select=*`, mas isso nao aparece como endpoint proprio na documentacao.
- `patientRepository.getDirectoryRows()` transforma pacientes em campos de UI e preenche `insurance`, `city`, `state`, `vip`, `lastVisit` e `nextVisit` com valores fixos. Esses campos nao estao descritos na resposta de `GET /rest/v1/patients`.
- `patientRepository.create(data)` e `createWithValidation(data)` enviam `created_by` com UUID zerado quando nao informado. A documentacao nao confirma esse fallback; isso pode gerar registro invalido se a API exigir usuario real.
- `patientRepository.createWithValidation(data)` usa a Edge Function documentada (`/functions/v1/create-patient`), mas a API tambem possui o endpoint publico `/functions/v1/register-patient`, ainda sem metodo correspondente.
- `appointmentRepository.getAll()` nao chama `GET /rest/v1/appointments`; usa `mockData`. Alem disso, nao existem metodos para `POST /rest/v1/appointments` nem para `POST /functions/v1/get-available-slots`.
- `professionalRepository.getAll()` nao chama `GET /rest/v1/doctors`; usa `mockData`. Tambem falta metodo para `POST /functions/v1/create-doctor`.
- `reportRepository.getInitialReports()` nao chama `GET /rest/v1/reports`; usa dados estaticos e nomes/status em portugues (`rascunho`, `finalizado`, `enviado`) diferentes dos status documentados (`draft`, `completed`).
- `reportRepository` expoe templates, tipos, usuarios admin e medico atual, mas esses recursos nao aparecem na API documentada de Reports.
- `communicationRepository` tem campanhas, mensagens e templates, mas a documentacao so possui `POST /functions/v1/send-sms`; nao ha equivalencia para listar ou gerenciar esses dados.
- `profileRepository.getCurrentUserProfile()` retorna perfil fixo; deveria ser alinhado com `GET /auth/v1/user` ou `POST /functions/v1/user-info`.
- `homeRepository`, `analyticsRepository`, `settingsRepository`, `visitRepository` e `medicalRecordRepository` nao possuem endpoints equivalentes na documentacao atual.

## Configuracao extraida

As variaveis reutilizaveis de API foram centralizadas em `src/config/api.js`:

- `VITE_SUPABASE_URL`
- `VITE_SUPABASE_REST_URL`
- `VITE_SUPABASE_FUNCTIONS_URL`
- `VITE_SUPABASE_STORAGE_URL`
- `VITE_SUPABASE_ANON_KEY`

O arquivo mantem os valores atuais como fallback para nao quebrar o ambiente local, mas o ideal e configurar esses valores via `.env`.