docs: registra MCP ClinicAll Confirmação e confirmação de agenda via WhatsApp

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

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/<data>` | `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.