From e791474d155ae080d53f120b7760e18423ae57f1 Mon Sep 17 00:00:00 2001 From: Gustavo Date: Tue, 11 Aug 2026 16:11:55 -0300 Subject: [PATCH] =?UTF-8?q?docs:=20registra=20MCP=20ClinicAll=20Confirma?= =?UTF-8?q?=C3=A7=C3=A3o=20e=20confirma=C3=A7=C3=A3o=20de=20agenda=20via?= =?UTF-8?q?=20WhatsApp?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Sonnet 5 --- docs/n8n-agendamento-runbook.md | 78 +++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/docs/n8n-agendamento-runbook.md b/docs/n8n-agendamento-runbook.md index 4682654..9d7034c 100644 --- a/docs/n8n-agendamento-runbook.md +++ b/docs/n8n-agendamento-runbook.md @@ -722,3 +722,81 @@ exemplo (lembrete proativo + AI Agent reativo) prontos pra ativar assim que houver uma clínica Klingo real com credencial `X-APP-TOKEN` e banco Postgres provisionado. Sem teste de ponta a ponta contra a API real — pendência explícita até então. + +## 19. Confirmação de Agenda via WhatsApp (ClinicAll) + +**Data:** 11/08/2026. Ver design completo em +`docs/superpowers/specs/2026-08-11-confirmacao-agenda-clinicall-design.md` +e plano em +`docs/superpowers/plans/2026-08-11-confirmacao-agenda-clinicall.md`. + +**Motivação**: mesmo objetivo da seção 18 (Klingo), agora para o +ClinicAll — permitir que o paciente confirme presença numa consulta +via WhatsApp. Diferente do Klingo, o ClinicAll não tem uma API de +"Telefonia" separada: os endpoints de confirmação fazem parte do mesmo +`TCalendarController`/`TDomainController` já usado no MVP de +agendamento (seção 14.3), verificados diretamente no manual oficial +(`docs/API Clinicall.pdf`, v1.1.16, relido nesta sessão). + +**MCP Server "ClinicAll - Confirmação de Agenda"** (`lHU5H0cZP4BJ6dWp`) — 5 tools: + +| Tool | Endpoint | Workflow id | +| --- | --- | --- | +| `listar_agendamentos_do_dia` | `GET /TCalendarController/agendamento/` | `9pudW1QzBMh7c4ve` | +| `buscar_agendamento_por_cpf` | `GET /TCalendarController/agendamentoSemPaciente` (cpf + dataNascimento) | `i7Dw7xJZPpSbV3Ak` | +| `confirmar_presenca` | `POST /TCalendarController/AgendamentoFlags` | `3mAkzfGwGeRSvWvO` | +| `consultar_estados_agenda` | `GET /TDomainController/estadoAgenda` | `EGX5whFSJX6ew50a` | +| `consultar_situacoes_agenda` | `GET /TDomainController/situacaoAgenda` | `YzFJ5evrw2bzJTGi` | + +**Diferenças reais em relação ao Klingo** (mesma disciplina de não +generalizar padrões entre providers sem verificar): + +- **Strings exatas em vez de código curto**: o Klingo aceita `status: + 'C'/'S'/'N'` pra confirmar. O ClinicAll exige duas strings longas e + exatas (`estadoAgenda`, `situacaoAgenda` — ex.: `"CONFIRMADO PELA + TELEFONISTA"`, `"Agendado"`), documentadas só nas tabelas de domínio + — por isso `consultar_estados_agenda`/`consultar_situacoes_agenda` + são tools obrigatórias no fluxo, não apoio opcional. +- **CPF + data de nascimento, não só CPF**: `agendamentoSemPaciente` + exige os dois campos, diferente do `lista_ultimo_por_cpf` do Klingo. +- **Telefone aninhado**: no ClinicAll, o telefone do paciente vem em + `item.Paciente.telefoneCelular` (objeto aninhado), não um campo + direto do item como no Klingo (`item.celular`) — refletido na + extração de dados do workflow de lembrete. +- **Sem NPS nem consulta de bloqueios**: não documentados no manual do + ClinicAll para este módulo — ficaram fora, sem inventar. +- **Pendência não verificada**: o manual não esclarece se + `agendamentoSemPaciente` (`GET, POST`) espera os parâmetros como + query string ou body. Implementado como `GET` + query string, por + analogia com todos os outros GETs deste manual (nenhum usa body) — + suposição registrada, não testada contra a API real. +- **Mesma pendência de autenticação já registrada no MVP de + agendamento do ClinicAll**: `authentication: "none"` em todos os + nodes HTTP (não `httpHeaderAuth` como no Klingo) — o manual do + ClinicAll não documenta nenhum mecanismo de auth por requisição. + +**Workflow proativo "Lembrete de Confirmação - ClinicAll (exemplo)"** +(`liBLpRUmbcnWk05V`): mesmo desenho do Klingo (cron 8h → lista amanhã → +loop → `enviar_texto` do MCP Mensageria ZPRO), com um filtro a mais — +descarta itens com `situacaoAgenda: "Livre"` (sem `idPaciente`/ +`Paciente`) antes de montar a mensagem. Validado (0 erros), deixado +**inativo de propósito**. + +**Workflow de exemplo "Confirmação de Agenda - GChat - ClinicAll+Z-PRO +(exemplo)"** (`ylc3Jcz239ra6XZK`): mesmo padrão do Klingo (webhook → +AI Agent → memória Postgres), `systemMessage` ajustado pra pedir CPF +**e** data de nascimento, e pra sempre consultar +`consultar_estados_agenda`/`consultar_situacoes_agenda` antes de +chamar `confirmar_presenca` (nunca inventar a string exata). Tools +conectadas via `MCP Client Tool`: `buscar_agendamento_por_cpf`, +`confirmar_presenca`, `consultar_estados_agenda`, +`consultar_situacoes_agenda` (`listar_agendamentos_do_dia` fica de +fora, só serve ao workflow proativo). Validado (0 erros), deixado +**inativo de propósito**. + +**Resultado**: MCP Server de confirmação de agenda (ClinicAll) +completo e validado estruturalmente, junto com os dois workflows de +exemplo, prontos pra ativar quando houver clínica ClinicAll real — +falta resolver a autenticação (mesma pendência do MVP de agendamento), +preencher o `baseUrl` real, e provisionar banco Postgres + credencial +pro cliente.