diff --git a/docs/n8n-agendamento-runbook.md b/docs/n8n-agendamento-runbook.md
index 9d7034c..5656edb 100644
--- a/docs/n8n-agendamento-runbook.md
+++ b/docs/n8n-agendamento-runbook.md
@@ -800,3 +800,83 @@ 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.
+
+## 20. Confirmação de Agenda via WhatsApp (SysLife)
+
+**Data:** 11/08/2026. Ver design completo em
+`docs/superpowers/specs/2026-08-11-confirmacao-agenda-syslife-design.md`
+e plano em
+`docs/superpowers/plans/2026-08-11-confirmacao-agenda-syslife.md`.
+
+**Motivação**: mesmo objetivo das seções 18 (Klingo) e 19 (ClinicAll),
+agora para o SysLife. O recurso relevante, `AgendaWSApp`, já vem
+descrito no manual (`Manual WS SysLife V3.4.pdf`, salvo em
+`docs/Manual WS SysLife V3.4 (1).pdf`, relido nesta sessão — não
+estava commitado no repositório antes) explicitamente como "retorna os
+registros da agenda **para uso do WhatsApp**".
+
+**MCP Server "SysLife - Confirmação de Agenda"** (`xq8CyqyewtENpIMW`) — 3 tools:
+
+| Tool | Endpoint | Parâmetro | Workflow id |
+| --- | --- | --- | --- |
+| `listar_agendamentos_do_dia` | `GET /AgendaWSApp` | `QuantidadeDias` | `ezcqDpU4R4LuHldj` |
+| `buscar_agendamento_por_telefone` | `GET /AgendaWSApp` | `NumeroCelular` | `sTLFa6VyUkBnM8C0` |
+| `confirmar_presenca` | `POST /AgendaWSApp` | `CodigoAgenda` + `Resposta` (`"1"`/`"2"`) | `Pv0BbagqdeoBgENZ` |
+
+**Ponto único deste provider**: um mesmo `GET /AgendaWSApp` serve três
+propósitos diferentes conforme qual dos três parâmetros é enviado
+(`QuantidadeDias`, `CodigoAgenda` ou `NumeroCelular` — o manual é
+explícito: **"Deverá ser usado somente um dos 3 parâmetros"**). Duas
+tools deste MCP (`listar_agendamentos_do_dia`,
+`buscar_agendamento_por_telefone`) apontam pro mesmo endpoint via
+sub-workflows diferentes, cada um montando só o parâmetro que lhe
+cabe.
+
+**Diferenças reais em relação a Klingo e ClinicAll**:
+
+- **Autenticação já resolvida de verdade**: diferente dos outros dois,
+  a credencial Basic Auth (`httpBasicAuth`, `u8XXJ6wyrKuGJp4Y`,
+  `SysLife Basic Auth - clínica pendente`) **já existia**, criada
+  durante o MVP de agendamento do SysLife — usuário/senha fixos do
+  WebService, documentados literalmente no manual, não variam por
+  clínica. Foi só reaproveitada, nenhuma credencial nova criada.
+- **`Resposta` é o mais simples dos três providers**: só `"1"` (SIM)
+  ou `"2"` (NÃO), documentado direto no manual — sem precisar de tools
+  de tabela de domínio como no ClinicAll, nem terceiro estado
+  ("Sem Resposta") como no Klingo.
+- **Resposta já vem com texto formatado pro WhatsApp**: os campos
+  `txWhatsappProcedimento`/`txWhatsappHorario`/`txWhatsappMedico` já
+  vêm prontos do próprio SysLife — usados no workflow de lembrete com
+  fallback pros campos brutos quando ausentes.
+- **Telefone é campo direto do item** (`nuCelular`/`nuCelularDdd`),
+  sem objeto `Paciente` aninhado como no ClinicAll.
+- **Fora de escopo**: `AgendaCentral` (central telefônica, não
+  WhatsApp — mesmo raciocínio do `/entrada` do Klingo), `AgendaRetorno`
+  (consultas de retorno), `AgendaStatus` (base pra NPS, sem endpoint
+  de submissão documentado), `AgendaConfirmado` (só consulta
+  informativa, sem ação).
+
+**Workflow proativo "Lembrete de Confirmação - SysLife (exemplo)"**
+(`LpRRZxTsM0Vc9PsV`): cron 8h → `listar_agendamentos_do_dia`
+(`quantidadeDias: 1`, literal fixo — o próprio SysLife já calcula
+"amanhã" a partir desse número, sem precisar de node de cálculo de
+data) → loop → `enviar_texto` do MCP Mensageria ZPRO. Validado (0
+erros), deixado **inativo de propósito**.
+
+**Workflow de exemplo "Confirmação de Agenda - GChat - SysLife+Z-PRO
+(exemplo)"** (`wBjXOZSEj5TopzfB`): mesmo padrão dos outros dois
+(webhook → AI Agent → memória Postgres), `systemMessage` ajustado pro
+fluxo mais simples (telefone → `buscar_agendamento_por_telefone` →
+`confirmar_presenca` com `resposta: "1"`/`"2"`). Tools conectadas:
+`buscar_agendamento_por_telefone`, `confirmar_presenca`
+(`listar_agendamentos_do_dia` só serve ao workflow proativo). Validado
+(0 erros), deixado **inativo de propósito**.
+
+**Resultado**: MCP Server de confirmação de agenda (SysLife) completo
+e validado estruturalmente, junto com os dois workflows de exemplo,
+prontos pra ativar quando houver clínica SysLife real — diferente dos
+outros dois providers, a autenticação já está pronta; falta só
+preencher o `baseUrl` real (IP:9000) e provisionar banco Postgres +
+credencial pro cliente. Com isso, os 4 providers (Z-PRO em produção
+real, Klingo, ClinicAll, SysLife estruturalmente prontos) têm o mesmo
+padrão de confirmação de agenda implementado.