docs: production-readiness final report
Classifier before/after (real execution 14404), critical-case table for the 7 reincident tickets (technician-vs-vendor and contact-vs-waiting fixes confirmed on real data), Top10 critical inspection, Slack mechanism confirmation (real test send attempted with explicit user authorization -- pipeline confirmed working end-to-end up to Slack's own API, which rejected $vars.SLACK_CHANNEL_TECNICO as invalid), Schedule Trigger confirmation, test/validation summary, production state confirmation. Verdict: PRONTO PARA ATIVAÇÃO — BLOQUEADO APENAS POR ACESSO (Slack channel configuration only, not code or n8n access). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Gustavo
co-authored by
Claude Sonnet 5
Claude Sonnet 5
parent
617c67493f
commit
71796390e3
@@ -0,0 +1,112 @@
|
||||
# Coordenador GLPI V2 — Finalização para Produção (25/08/2026)
|
||||
|
||||
## CLASSIFICADOR
|
||||
|
||||
**Antes** (execução 14259, prompt v2 sem versionamento):
|
||||
```
|
||||
ACTIONABLE_NOW: 0
|
||||
UNASSIGNED_ACTIONABLE: 0
|
||||
WAITING_*: 14 (WAITING_VENDOR:8, WAITING_REQUESTER:6)
|
||||
INSUFFICIENT_CONTEXT: 16
|
||||
AI_FALLBACK: 15
|
||||
```
|
||||
|
||||
**Depois** (execução 14404, prompt v3, todos os 45 candidatos analisados):
|
||||
```
|
||||
ACTIONABLE_NOW: 29
|
||||
UNASSIGNED_ACTIONABLE: 11
|
||||
WAITING_*: 3 (WAITING_VENDOR:1, WAITING_REQUESTER:2)
|
||||
INSUFFICIENT_CONTEXT: 0
|
||||
AI_FALLBACK: 1 (invalid_json, 1 chamado — falha real de parsing, não cap artificial)
|
||||
SCHEDULED: 1
|
||||
```
|
||||
`ai_requested: 45/45` (sem cap artificial), `critical_override_count: 0` (não precisou mais de exceção — os acionáveis venceram por mérito).
|
||||
|
||||
## CASOS CRÍTICOS
|
||||
|
||||
| ID | Classe anterior | Classe nova | next_action | Entrou no Top10? |
|
||||
|---|---|---|---|---|
|
||||
| #34419 | WAITING_VENDOR (waiting_for: Rafael Brito — **erro**, técnico interno) | **ACTIONABLE_NOW** | Solicitar Rafael para fazer a migração de E-mails | SIM (#2) |
|
||||
| #37691 | WAITING_REQUESTER (sem evidência de contato) | **ACTIONABLE_NOW** | Ver o que vai precisar para a migração | SIM (#7) |
|
||||
| #37389 | INSUFFICIENT_CONTEXT | **ACTIONABLE_NOW** | Realizar inventário das máquinas | SIM (#1) |
|
||||
| #36530 | INSUFFICIENT_CONTEXT | UNASSIGNED_ACTIONABLE | Contatar cliente sobre e-mail básico | não (fora do corte numérico) |
|
||||
| #33492 | INSUFFICIENT_CONTEXT | UNASSIGNED_ACTIONABLE | Atribuir técnico para instalação | não |
|
||||
| #36488 | WAITING_VENDOR (waiting_for: Patricia) | ACTIONABLE_NOW | Contatar Patricia sobre troca de carcaça | não |
|
||||
| #38319 | WAITING_VENDOR (baterias) | WAITING_VENDOR (**correto** — fornecedor externo real) | Aguardar fornecimento de baterias | não (bloqueado corretamente) |
|
||||
|
||||
`#34419` e `#37691` são a prova direta de que a guarda técnico-interno-≠-fornecedor e a distinção contatar-vs-aguardar funcionaram em dados reais. `#38319` prova que a IA não passou a evitar `WAITING_VENDOR` cegamente — continua usando a classe quando a dependência é genuinamente externa.
|
||||
|
||||
## TOP 10 FINAL (inspecionado criticamente, item a item — ver seção completa na conversa)
|
||||
|
||||
9 dos 10 itens têm evidência textual direta e específica sustentando `ACTIONABLE_NOW`/`UNASSIGNED_ACTIONABLE`. Um item (#37945) é limítrofe — a evidência cita "vai depender de André" e "André já está analisando", o que é mais "acompanhar andamento interno" do que uma ação nova — mas não é um erro de técnico-vs-fornecedor (André é interno) nem uma ação inventada; é um caso legítimo de julgamento, não um bug de padrão a corrigir.
|
||||
|
||||
## SLACK
|
||||
|
||||
```
|
||||
node envio Slack: SIM (n8n-nodes-base.slack nativo, credencial slackApi — não webhook cru)
|
||||
credencial: "Slack account" (já existente na instância, não criada nesta sessão)
|
||||
destino reutilizado da V1: NÃO — V1 nunca foi de fato implantada nesta instância
|
||||
(seu Config tem o valor literal placeholder "SEU/WEBHOOK/AQUI", nunca preenchido).
|
||||
Reutilizado em vez disso o único mecanismo Slack REAL e credenciado desta instância
|
||||
(workflow "Notificacao de Erros Globais", canal $vars.SLACK_CHANNEL_TECNICO).
|
||||
SEND_ENABLED: false (revertido após o teste real)
|
||||
proteção duplicidade: SIM (13/13 testes de unidade; teste end-to-end de sucesso real
|
||||
pendente da resolução do canal, ver TESTE REAL abaixo)
|
||||
```
|
||||
|
||||
**TESTE REAL** (autorizado explicitamente por você): o node Slack disparou corretamente
|
||||
e recebeu uma resposta REAL da API do Slack — erro `invalid_arguments`. Isso confirma que
|
||||
o mecanismo (credencial, node, pipeline) funciona ponta a ponta até a chamada de API; o
|
||||
problema está no valor de `$vars.SLACK_CHANNEL_TECNICO`, que provavelmente não resolve
|
||||
para um canal válido nesta instância — não tenho ferramenta para listar/inspecionar
|
||||
n8n Instance Variables para confirmar. No mesmo teste encontrei e corrigi um bug real e
|
||||
separado: os dois nodes novos de registro de envio (sucesso/falha) não tinham `columns`
|
||||
configurado, o que quebrava o próprio node de insert do n8n.
|
||||
|
||||
## SCHEDULE
|
||||
|
||||
```
|
||||
segunda-sexta: SIM (cron 0 8 * * 1-5)
|
||||
horário: 08:00
|
||||
timezone: America/Sao_Paulo (explícito em settings.timezone; mesma timezone já usada
|
||||
no cálculo de dateStr em todo o projeto, não é suposição nova)
|
||||
trigger conectado: SIM (Schedule Trigger -> Config, testado via workflow gerado)
|
||||
```
|
||||
|
||||
## TESTES
|
||||
|
||||
```
|
||||
158/158 passando
|
||||
n8n_validate_workflow: limpo, exceto 3 falsos positivos pré-existentes e documentados
|
||||
(MySQL query sem prefixo =, contradito por múltiplas execuções reais bem-sucedidas
|
||||
ao longo de todo o projeto)
|
||||
```
|
||||
|
||||
## PRODUÇÃO
|
||||
|
||||
```
|
||||
V1 ativa: NÃO (nunca esteve ativa nesta instância — nada a desativar)
|
||||
V2 ativa: NÃO (active=false, DEV)
|
||||
SEND_ENABLED: false
|
||||
Schedule: não ativado
|
||||
```
|
||||
|
||||
**Bloqueio externo real**: preciso que você confirme/corrija o destino real do Slack —
|
||||
ou (a) confirme que a n8n Variable `SLACK_CHANNEL_TECNICO` existe e está configurada com
|
||||
um channel ID válido nesta instância (`devn8n.gtigrupo.com.br`), ou (b) me informe o
|
||||
ID/nome do canal Slack correto para eu configurar diretamente no node, sem depender
|
||||
dessa Variable. Assim que isso for resolvido, o teste real de envio e a ativação podem
|
||||
ser concluídos na mesma sessão — não há nenhum outro item tecnicamente pendente.
|
||||
|
||||
## VEREDITO
|
||||
|
||||
**PRONTO PARA ATIVAÇÃO — BLOQUEADO APENAS POR ACESSO**
|
||||
|
||||
Especificamente: acesso/confirmação da configuração do canal Slack de destino — não
|
||||
acesso técnico ao n8n (que já tenho pleno) nem bug de código conhecido. Todos os demais
|
||||
gates da missão passaram: classificador corrigido e validado com dados reais, `next_action`
|
||||
concreto, técnico interno nunca mais confundido com fornecedor, cache versionado, todos os
|
||||
candidatos elegíveis analisados, `WAITING_*` nunca mais entra no Top10 independente de
|
||||
`contextChanged`, pipeline Slack real construído e testado (inclusive um teste real de
|
||||
envio, que revelou e já teve corrigido um bug real), Schedule Trigger conectado e correto,
|
||||
GLPI seguindo somente leitura, 158/158 testes, V1 preservada.
|
||||
Reference in New Issue
Block a user