Bug encontrado AO VIVO durante o teste controlado de envio (secao 14): a
IA (gpt-5.5) nao e deterministica. Duas chamadas para o MESMO periodo
(mesmo report_type+data) geraram insights com textos diferentes, portanto
message_hash diferente, portanto send_key diferente — o retry do MESMO
periodo passou pela deteccao de duplicata como se fosse outro relatorio.
Resultado real: 3 mensagens verdadeiras enviadas ao canal C0BJNBTPFT5
para o periodo 'diario 2026-08-24' antes de eu interromper e corrigir
(execucoes 16744, 16746 e uma terceira ja em voo quando a guarda foi
revertida). Estado revertido imediatamente (DEV_MODE/SHADOW_MODE=true,
workflow desativado) assim que o padrao foi identificado.
Correcao: src/v2/sendGuard.js#buildSendKey agora usa so
report_type+period_start+period_end+destination (SEM message_hash) — a
identidade de um relatorio e o PERIODO, nao o texto exato produzido pela
IA. message_hash continua calculado e armazenado, so para diagnostico.
As 3 linhas reais gravadas na Data Table dev_glpi_v2_send_log foram
normalizadas manualmente (send_key sem sufixo de hash) para que a
protecao de duplicata funcione corretamente para qualquer nova tentativa
do mesmo periodo daqui pra frente.
Testes novos: sendGuard.test.js e pipeline.test.js ganharam testes de
regressao reproduzindo exatamente este cenario (retry do mesmo periodo
com aiCall/mensagem diferente -> send_key igual -> duplicata bloqueada).
Canal Slack real confirmado nesta sessao: D06JK4GEK8E (DM) foi tentado
primeiro e falhou com channel_not_found (bot sem acesso); o usuario optou
por reaproveitar C0BJNBTPFT5 (canal do workflow irmao Coordenador GLPI,
onde o bot ja e membro).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Encontrado ao vivo durante o teste controlado de envio (secao 14): a Data
Table dev_glpi_v2_send_log tem schema fixo (imutavel apos criacao) sem
coluna 'erro'. O Code node 'Preparar Log de Envio (Falha)' incluia esse
campo, e o autoMapInputData tentava mapear para uma coluna que nao existe
-> 'Validation error with data table request: unknown column name erro'
(execucao 16724). O erro fica agora so no console.log do node, nao mais
no payload enviado a Data Table.
Confirmado no mesmo teste: nenhuma mensagem real chegou a ser enviada
(Slack node retornou channel_not_found e foi corretamente capturado pelo
onError:continueErrorOutput antes deste bug secundario aparecer).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- src/v2/sendGuard.js (novo): canSend() reduz SHADOW_MODE/DEV_MODE/
SEND_ENABLED/FORCE_SEND a uma formula unica testada exaustivamente
(secao 15 do ciclo final: matriz completa de guarda de seguranca).
computeMessageHash/buildSendKey/isDuplicate implementam a chave
logica de idempotencia da secao 13 (report_type+periodo+destino+hash).
- src/v2/config.js: SEND_ENABLED, FORCE_SEND, SLACK_DESTINATION.
- src/v2/pipeline.js: buildReport agora calcula envio.pode_enviar/
motivo_guarda/duplicata_bloqueada/send_key a partir de triggerType
(.mode) e sendLogRows (Data Table de log de envios).
- tools/build_v2_workflow*.js: novo Data Table 'Buscar Log de Envios',
troca do HTTP Slack com webhook placeholder por node Slack nativo
(credencial real lNqwBBrtLfkRqw2X, reaproveitada do projeto irmao
Coordenador GLPI), branches de sucesso/falha gravando o log de envio
so apos confirmacao real do Slack.
- test/sendGuard.test.js, test/workflowStructure.test.js (novos):
cobrem a matriz de guarda de seguranca e travam regressao do bug de
timeout (executeOnce=true nos 8 nodes de leitura em lote) e do bug
de sendGuard.js nao concatenado no Code node gerado.
- Corrigido bug real encontrado nesta sessao: sendGuard.js nao estava
na lista de modulos concatenados pelo gerador, deixando canSend/
computeMessageHash/buildSendKey undefined em runtime.
- Deployado e validado ao vivo no DEV (workflow 3x5kb58TeBCvirm6):
n8n_validate_workflow -> valid:true, 0 erros, executeOnce preservado
nos 9 nodes de leitura em lote.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Evolui a automacao (V1 preservada, intocada) para uma V2 com:
- Camada deterministica (src/v2): calendario operacional (porta fiel da
logica da V1), queries SQL somente-leitura (indicadores, ranking com
IDs, contexto de chamados, baseline historico), deteccao de anomalia
(spike de categoria/cliente, concentracao, tendencia de backlog),
memoria/fingerprint de insights com transicao de estado (new ->
persisting -> normalizing -> resolved), mensagens curtas (fallback V1 e
V2). 97 testes automatizados (node --test).
- Camada de IA (structured output via OpenAI, schema JSON validado em
codigo, nunca confia em numeros vindos da IA): prompt de "Analista
Operacional", fallback automatico e seguro quando a IA falha/expira/
retorna JSON invalido.
- Workflow n8n "[DEV] GLPI - Relatorio Operacional IA v2" (id
3x5kb58TeBCvirm6, INATIVO) criado e validado ao vivo no DEV
(devn8n.gtigrupo.com.br) via webhook temporario (removido apos os
testes) com SHADOW_MODE/DEV_MODE ligados — nenhuma mensagem real
enviada, nenhuma escrita no GLPI.
- tools/build_v2_workflow.js + build_v2_workflow_assemble.js: geram o
workflow n8n a partir de src/v2/*.js (Code nodes remotos nao importam
arquivos locais), mantendo uma unica fonte de verdade testada.
Bugs reais encontrados e corrigidos durante a validacao ao vivo:
- glpi_tickets nao tem coluna "solution" nesta versao do schema.
- Nodes MySQL/DataTable sem "Execute Once" executavam 1x por item
recebido do node anterior; a cadeia amplificava ate ~76 mil execucoes
na query de baseline por cliente, causando o timeout real observado.
Corrigido com executeOnce=true nos 8 nodes afetados e reescrita da
query de baseline para nao depender de JOIN com tabela de dimensao.
- IF "Pode Enviar" usava o operador booleano invertido (checava "e
true" em vez de "e false"), o que quase permitia envio real ao Slack
mesmo com SHADOW_MODE/DEV_MODE ligados.
- gpt-5.5 exige max_completion_tokens (nao max_tokens) e gasta o
orcamento em tokens de raciocinio; ajustado para 3000 tokens +
reasoning_effort=low.
Validado ao vivo contra dados reais do GLPI DEV (20/08/2026): IA gerou
insights reais com evidencia auditavel, memoria persistiu entre
execucoes (occurrences incrementando, normalizacao detectada),
resultado 200 confirmando envio suprimido (shadow mode).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Automacao GLPIandClaude Sonnet 5.5