gustavosantos/SLACK_COORD_RELATORIO
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e322cec92b37fcbaba499c459f9616eb0ef3383c
SLACK_COORD_RELATORIO/coordenador/docs/superpowers/notes/2026-08-24-schema-introspection.md
T
Gustavo Santos e322cec92b chore: import coordenador (subtree) 
git-subtree-dir: coordenador
git-subtree-mainline: facbe2e340
git-subtree-split: ce7af94d55
2026-10-01 14:25:55 -03:00

2.7 KiB
Raw Blame History

Introspecção de schema GLPI — Task 14

Status: concluído. Credencial GLPI (mySql, id dsVj1nmOIXRvix9n) criada pelo usuário às 2026-08-24 18:51 UTC. Rodei SHOW COLUMNS real contra o banco (via workflow temporário de introspecção, deletado depois) e confirmei tudo abaixo.

O que foi confirmado (real, via SHOW COLUMNS contra o banco)

  • glpi_tickettasks.state: existe exatamente como assumido em sql/contexto_glpi.sql (int, default 1). Nenhum ajuste necessário.
  • glpi_itilfollowups: itemtype, items_id, date, content, is_private, date_mod, date_creation — todos confirmados, batendo com o que a query V1 (já em produção) sempre assumiu.
  • sql/candidatos_v2_glpi.sql rodada de verdade (LIMIT 5) contra o banco real: retornou linhas plausíveis, incluindo os chamados #34419, #36530 e #37945 — os mesmos números que o usuário já tinha usado como exemplo na missão original, confirmando que é o mesmo GLPI.
  • Execução completa do workflow V2 (id de execução 13599, 2026-08-24 19:25 UTC): 41 candidatos reais, contexto (followups/tarefas) buscado com sucesso, 30 chamados avaliados pela IA (limite AI_MAX_CANDIDATES), memória gravada com 41 linhas reais. Ver relatório final para os números completos.

Achado durante o deploy (não é sobre schema do GLPI, mas registrado aqui)

Ao criar o workflow via API sem a credencial MySQL existir ainda, o n8n resolveu sozinho por tipo e vinculou os 3 nodes MySQL à única credencial mySql existente no ambiente (MySQL account - Gerar e Enviar Chave, do sistema Asaas/cobrança — nada a ver com GLPI). Removi essa vinculação (credentials: null) nos 3 nodes MySQL do workflow y6JFEnp7Z2IJEUe2 e no template local, para não deixar o workflow silenciosamente "configurado" apontando pro banco errado. Resolvido: quando o usuário criou a credencial GLPI (id dsVj1nmOIXRvix9n), reapontei os 3 nodes MySQL para ela via n8n_update_partial_workflow.

Nodes afetados: MySQL - Buscar Candidatos, MySQL - Legado Top 10 (Shadow), MySQL - Buscar Contexto.

Achado adicional (Data Tables de terceiros)

No mesmo instante em que eu investigava este ambiente, apareceram duas Data Tables novas no DEV que eu não criei: dev_glpi_v2_insights_memory e dev_glpi_v2_run_history (criadas ~18:37, no meio desta sessão). O schema delas não bate com o desenho deste projeto (parecem de outra tentativa — colunas tipo fingerprint/insight_type/subject_key e tipo_periodo/history_bucket). Não toquei nelas. Criei as minhas com nomes próprios (coordenador_glpi_memoria, coordenador_glpi_shadow_runs) para não colidir. Vale confirmar com quem estiver por trás dessas tabelas se é trabalho duplicado.

Reference in New Issue View Git Blame Copy Permalink