MCP standalone, desacoplado de qualquer provider de agendamento --
4 tools (enviar_texto, enviar_template, enviar_template_com_parametros,
enviar_template_marketing), API de envio do Z-PRO. Motivado pela
necessidade de confirmação de agenda (Klingo), mas reutilizável por
qualquer workflow futuro. Pendência real documentada: ApiID/token da
integração de mensageria ainda não confirmados (hipótese razoável
aponta pra credencial 'Canal QR', não verificado). Fora de escopo:
mídia/áudio/base64/busca por wamid, e a própria feature de
confirmação de agenda (fica pra depois, vai consumir este MCP).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nova seção 16: node Memória da Sessão (RAM) trocado pelo Postgres
Chat Memory oficial, tabela n8n_chat_histories criada
automaticamente. Container Postgres com um banco por cliente,
credencial por workflow. Testado de ponta a ponta em produção: duas
mensagens em sequência confirmam que o contexto persiste entre
execuções separadas do workflow.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4 tasks: verificar estrutura atual, trocar o node numa operação
atômica (add + connect + remove, mesma lição da implementação
anterior sobre nós desconectados), testar persistência real de
contexto entre duas execuções separadas do workflow, atualizar
runbook + commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Troca o node de memória do AI Agent (Simple Memory, em RAM, não
sobrevive a reinício do n8n) pelo node oficial Postgres Chat Memory,
mesma configuração de sessão (sessionKey, contextWindowLength).
Infraestrutura: um container Postgres com um banco por
cliente/clínica, mesma filosofia de isolamento já usada nos outros
parâmetros de configuração do projeto. Tabela criada automaticamente
pelo node, sem setup manual de schema. Nada a migrar (histórico
atual só existe em RAM).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nova seção 15: 4 nodes adicionados ao workflow de produção
(yG2mi6ECBpPv4Hmn) para buscar o systemMessage de negócio de um
Google Doc público por clínica, com fallback seguro em caso de
falha. Documenta o bug real encontrado e corrigido durante a
implementação: HTTP Request substitui o $json inteiro, quebrando a
Memória da Sessão por perda do sessionId -- fix foi reconstruir os
campos explicitamente a partir do node anterior ao HTTP Request.
Testado de ponta a ponta em produção: conteúdo do Doc aparece na
resposta, regras fixas continuam valendo, caminho de falha
confirmado sem quebrar o atendimento.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6 tasks: verificar estrutura atual antes de modificar (workflow em
produção), adicionar os 4 nodes novos (Config Clínica, Buscar config
da clínica, Doc OK, Doc falhou), rewire das conexões, estender o
systemMessage do AI Agent sem alterar as regras fixas existentes,
preencher docId de teste e testar de ponta a ponta (incluindo
caminho de falha), atualizar runbook + commit. Disciplina extra por
mexer em produção real: validação após cada task, teste de falha
obrigatório antes de concluir.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Externaliza a parte de negócio do systemMessage (tom de voz,
saudação, horário, regras específicas da clínica) para um Google Doc
por clínica, público para leitura (sem credencial OAuth) e editável
só pela conta do gestor. docId fixo por workflow, setado uma vez na
instalação. Regras fixas de segurança (não duplicar agendamento,
fuso horário, confirmar nome) continuam hardcoded no n8n, nunca
editáveis por fora -- documentado como decisão de segurança, com a
limitação conhecida de que a separação é só de prioridade no prompt,
não um bloqueio técnico real.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Renomeia o título e a intro para refletir que o runbook agora cobre
os 4 providers, não só o Z-PRO. Adiciona seção 14 consolidando
Klingo, SysLife e ClinicAll (IDs de workflow, diferenças de
autenticação, pendências reais de cada um) e uma subseção de padrão
comum aos quatro. Renomeia "Status final" para "Status final -
Z-PRO" para deixar claro o escopo.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
9 workflows criados e validados estruturalmente (0 erros): servidor
MCP + 8 sub-workflows. Nada ativado nem testado com chamada HTTP real
ainda -- as duas pendências reais (autenticação e verbo HTTP do
agendamento) continuam sem solução, aguardando clínica ClinicAll
real.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
10 tasks: 5 sub-workflows de catálogo (unidade, especialidade,
convenio, profissional, procedimento) com esqueleto quase idêntico,
sub-workflow paciente, sub-workflow consultar_horarios (GET
/disponibilidade com route params), sub-workflow agendar (PUT
/agendamento com a mesma proteção 2xx=sucesso), servidor MCP com as
8 tools, e revisão final + commit. Nenhuma credencial criada
(mecanismo de auth desconhecido, authentication:none) -- sem
clínica ClinicAll real disponível, validação só estrutural.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Quarta aplicação do padrão nativo, a partir do manual oficial da
Focus Tecnologia (docs/API Clinicall.pdf) -- documentação mais
completa dos 4 providers até agora. 8 tools: unidade, especialidade,
convenio, profissional, procedimento, paciente, consultar_horarios
(GET /disponibilidade) e agendar (PUT /agendamento). Duas
ambiguidades reais documentadas explicitamente: mecanismo de
autenticação por requisição não especificado no manual (nenhuma
credencial criada, authentication:none) e verbo HTTP de
criação/atualização do agendamento não mapeado (assumido PUT, não
verificado). Sem clínica ClinicAll real ainda -- validação estrutural
apenas.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5 sub-workflows novos criados e validados (0 erros). Servidor MCP
Server - Klingo atualizado com as 7 tools no total (agendar,
consultar_horarios + as 5 novas), agendar/consultar_horarios
confirmados intactos. Nada ativado nem testado com chamada HTTP real
ainda -- sem clínica Klingo real disponível.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
7 tasks: 5 sub-workflows novos de consulta (mesma credencial
X-APP-TOKEN já existente, sem sessão de paciente), adição desses 5
como novas tools no servidor MCP Server - Klingo já existente (via
addNode/addConnection, sem recriar o workflow), e revisão final +
commit. specialtyId/procedimento continua sem tool que resolva
(lacuna documentada na spec).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adiciona 5 tools ao MCP Server nativo do Klingo já existente (mesmo
servidor, sem criar um novo), a partir de endpoints do Swagger não
usados até agora pelo KlingoAdapter original. Todas usam a credencial
X-APP-TOKEN já existente (sem precisar de sessão de paciente).
Registra explicitamente a lacuna que continua sem solução: não há
endpoint GET de listagem de procedimentos no Klingo, então
specialtyId/procedimento continua sem uma tool que resolva (mesma
classe de limitação já registrada para SLOT_MAPPING_UNAVAILABLE).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
8 workflows criados e validados estruturalmente (0 erros): servidor
MCP + 7 sub-workflows (especialidade, medico, convenio, paciente,
procedimento, consultar_horarios, agendar). Nada ativado nem testado
com chamada HTTP real ainda -- sem clínica SysLife real disponível.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
9 tasks: 6 sub-workflows de consulta/apoio (especialidade, medico,
convenio, paciente, procedimento, consultar_horarios) com esqueleto
quase idêntico entre si, sub-workflow agendar (PUT /Agenda com a
mesma proteção contra duplicidade 2xx=sucesso), servidor MCP com as
7 tools, e revisão final + commit. Sem clínica SysLife real
disponível -- validação só estrutural, workflows ficam inativos até
haver um workflow de agente cliente pra consumi-los.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Terceira aplicação do padrão nativo (MCP Server Trigger + Call n8n
Sub-Workflow Tool), a partir do Manual WS SysLife V3.4 fornecido pelo
usuário (sem adapter TypeScript prévio para este provider). Escopo
"apenas agendamento" definido em conversa como 7 tools: 6 de
consulta/apoio (especialidade, medico, convenio, paciente,
procedimento, consultar_horarios) + agendar (PUT /Agenda). Auth Basic
fixo do WebService, sem clínica real ainda -- validação estrutural
apenas nesta etapa.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3 workflows criados e validados estruturalmente (0 erros): servidor
MCP + sub-workflows agendar/consultar_horarios. Nada ativado nem
testado com chamada HTTP real ainda -- sem clínica Klingo real
disponível.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4 tasks: sub-workflow consultar_horarios (SLOT_MAPPING_UNAVAILABLE),
sub-workflow agendar (fluxo de 2 chamadas HTTP com autenticação em
dois estágios — X-APP-TOKEN estático + Bearer de sessão dinâmico via
expressão, 3 pontos de saída antecipada por erro/validação), servidor
MCP com as 2 tools, e revisão final + commit. Sem clínica Klingo real
disponível — validação só estrutural, workflows ficam inativos até
haver um workflow de agente cliente pra consumi-los.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Segunda aplicação do padrão nativo (MCP Server Trigger + Call n8n
Sub-Workflow Tool) já validado em produção pro Z-PRO, agora pro
Klingo. Diferença principal: autenticação em dois estágios
(X-APP-TOKEN estático + Bearer de sessão do paciente dinâmico, não
armazenável como credential). Limitação conhecida aceita nesta etapa:
consultar_horarios sempre retorna SLOT_MAPPING_UNAVAILABLE (lacuna de
contrato já existente no KlingoAdapter TS, não desta migração). Sem
clínica Klingo real ainda — escopo desta etapa é só o MCP Server,
validação estrutural, sem chamada HTTP real.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Seção 13 do runbook: arquitetura nova (MCP Server Trigger + Call n8n
Sub-Workflow Tool, sem node comunitário/processo externo pro Z-PRO)
- Documenta os 2 gotchas reais de ativação e a causa raiz do 403 em
produção (ApiID e token vêm de integrações diferentes no Z-PRO,
não é bug de formato de header nem token expirado)
- Teste real de ponta a ponta confirmado (webhook -> AI Agent -> MCP
nativo -> Z-PRO), agendamento fictício criado e apagado
- Status final atualizado: workflow + 3 sub-workflows do MCP nativo
ativos em produção
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- gti-scheduling-mcp: MCP server com ZProAdapter e KlingoAdapter (agendar() completo pros dois)
- Workflow n8n 'Agendamento - GChat - Z-PRO': webhook -> AI Agent -> MCP -> Z-PRO, testado com sucesso real
- Documentacao: specs, plano, runbook de problemas reais e export do workflow
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
GustavoandClaude Sonnet 5