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