docs: registra MCP SysLife Confirmação e confirmação de agenda via WhatsApp
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
48efbe478b
commit
1e2b93c7be
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user