diff --git a/docs/superpowers/notes/2026-08-24-schema-introspection.md b/docs/superpowers/notes/2026-08-24-schema-introspection.md
index 7375ade..0555082 100644
--- a/docs/superpowers/notes/2026-08-24-schema-introspection.md
+++ b/docs/superpowers/notes/2026-08-24-schema-introspection.md
@@ -1,34 +1,25 @@
 # Introspecção de schema GLPI — Task 14
 
-Status: **bloqueado, pendente da credencial MySQL**.
+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 falta confirmar
+## O que foi confirmado (real, via `SHOW COLUMNS` contra o banco)
 
-A credencial `MySQL GLPI - Coordenador` ainda não existe no n8n DEV
-(`devn8n.gtigrupo.com.br`) — nem em nenhum outro lugar acessível a mim.
-Sem ela não há como executar `SHOW COLUMNS` nem rodar a query real.
-
-Quando a credencial existir, rodar antes de qualquer execução real do workflow V2:
-
-```sql
-SHOW COLUMNS FROM glpi_tickettasks;
-SHOW COLUMNS FROM glpi_itilfollowups;
-```
-
-e confirmar:
-
-- `glpi_tickettasks`: a coluna de status foi assumida como `state`
-  (`sql/contexto_glpi.sql`) — nome comum no schema GLPI 9.x/10.x, mas
-  **não verificado neste ambiente**. Se o nome real for outro, ajustar
-  `sql/contexto_glpi.sql` (linha `state AS status`) e rodar
-  `node tools/build-workflow.js` de novo antes de reaplicar no n8n.
-- `glpi_itilfollowups`: `content`, `date`, `is_private`, `items_id`,
-  `itemtype` — todos já usados sem alteração pela query V1 (comprovada
-  em produção), então a suposição aqui é de risco baixo.
-
-Depois, rodar `sql/candidatos_v2_glpi.sql` com `{CANDIDATE_POOL_SIZE}` → `5`
-para conferir que a query devolve linhas plausíveis antes de rodar o
-workflow completo.
+- `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)
 
@@ -38,10 +29,9 @@ Ao criar o workflow via API sem a credencial MySQL existir ainda, o n8n
 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. **Quando a credencial `MySQL GLPI - Coordenador`
-existir, alguém precisa abrir os 3 nodes MySQL no n8n e selecioná-la
-manualmente** (ou eu faço isso via `n8n_update_partial_workflow` assim que
-souber o ID real da credencial).
+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`.