ce7af94d55b226f147b36c745cddc7b84575a369
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  GustavoandClaude Sonnet 5
|
124516e64a |
fix(v2): fix "Validar e executar" bug (real root cause), expand generic-phrase blacklist, add FORCE_SEND
Root cause found for why the real Slack message showed "→ Validar e
executar" for nearly every ACTIONABLE_NOW ticket: logic/message.js's
ACTION_LABELS map had a hardcoded entry for ACTIONABLE_NOW that always
won over the AI's actual next_action field in shortActionLabel(). The
AI's real, specific, already-validated-as-non-generic next_action (e.g.
"Realizar inventário das máquinas") was being silently discarded for
display purposes on every single message. Fixed by removing the
ACTIONABLE_NOW entry -- it now falls through to the existing
next_action-based fallback (already there, just unreachable for that
class before). UNASSIGNED_ACTIONABLE intentionally keeps its fixed
"Atribuir técnico" label -- that IS the correct display for that class.
logic/classification.js: expanded GENERIC_NEXT_ACTION_PHRASES with the
exact phrase that leaked through ("validar e executar") plus the
mission's additional list (validar chamado, prosseguir atendimento,
executar chamado, tratar chamado, analisar chamado). Bumped
AI_CLASSIFIER_VERSION 3->4 since this changes what next_action values
validate as non-generic -- forces reclassification of any cached
candidate that only passed under the older, narrower blacklist.
n8n/nodes/validate-ai-response.node.js: generic-next-action rejections
now get their own distinct fallback_reason ('generic_or_unsupported_
next_action') instead of being lumped into 'invalid_json', matching the
same pattern already used for the technician-vendor conflict.
logic/slack.js + logic/config.js: added FORCE_SEND (default false).
Manual-triggered runs now never send for real even with SEND_ENABLED=
true in production, unless FORCE_SEND is also explicitly set -- protects
against someone clicking "Execute Workflow" in production and
accidentally re-sending today's digest.
Added format-safety regression tests (no literal backslash-n, URL never
bleeds into the next item's id, no markdown-wrapped URLs) -- verified
these were never actually triggered in a real send (the reported
corruption was n8n's raw JSON data-inspector view, not a delivered
Slack message; both manual runs in question had shouldSend:false).
169/169 tests passing.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
GustavoandClaude Sonnet 5
|
abc690ddb7 |
feat(v2): real Slack send pipeline (guard, idempotency, success/failure registration)
Implements the actual send branch: Selecionar Top N -> Montar Mensagem ->
Guard de Envio -> Slack real -> registrar resultado (only after
confirmed success/failure) -- previously simulated/absent.
logic/slack.js (new): shouldSendByConfig (SEND_ENABLED gate, defaults
false), computeMessageHash (djb2Hash of the exact message text, reused
from logic/hash.js), alreadySentSuccessfully (idempotency check: only a
prior status='success' record for the same report_date+run_type+
message_hash blocks a resend -- a prior 'failed' record does not, so
retries after a real failure aren't stuck), evaluateSendGuard (single
auditable decision combining both), buildEnvioDigestRecord.
logic/slack.test.js: 13 tests covering all of the above, explicitly
labeled against the mission's required tests #13-#16.
New node drivers:
- guard-envio-slack.node.js: reads the digest + recent envio records
(fetched by report_date), computes the send decision.
- Slack node itself (n8n-nodes-base.slack, native, not a raw webhook):
reuses the real "Slack account" credential (slackApi) and
$vars.SLACK_CHANNEL_TECNICO channel variable already used by this
org's own "Notificacao de Erros Globais" workflow on the same n8n
instance -- V1's own Slack webhook URL was never actually deployed
(its Config value is literally "SEU/WEBHOOK/AQUI", same class of
placeholder as the old GLPI URL from the prior cycle), so this reuses
the one REAL, credentialed Slack mechanism that exists in this
environment rather than inventing a new destination. onError:
continueErrorOutput splits success/failure into two branches.
- registrar-envio-sucesso.node.js / registrar-envio-falha.node.js: build
the success/failure record; only the success path continues to the
existing per-ticket send-counter logic (rewired below).
- lancar-erro-envio.node.js: after the failure record is written,
explicitly throws so the n8n execution shows status=error (never
silently swallow a send failure).
- pular-envio.node.js: terminal no-op for the "should not send" branch
(SEND_ENABLED=false or already sent today), for observability only.
n8n/nodes/prepare-envio-record.node.js: rewired to read the Top10
selection by name ($('Code - Selecionar Top 10').all()) instead of
$input, since it now runs downstream of the Slack-success registration,
not directly off Selecionar Top10 -- registering per-ticket send counts
before Slack ever confirmed anything was the exact "don't register
before confirmation" bug the mission called out.
logic/message.test.js: added a full-Top10 message-length regression test
(mission requirement: message stays short, no leaked JSON/score/evidence).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
GustavoandClaude Sonnet 5
|
ea105d525c |
fix(v2): three real bugs found by an actual end-to-end run against production GLPI data
Ran the deployed workflow for real (temporary webhook trigger, briefly
activated, immediately deactivated and removed after each attempt) against
the real GLPI MySQL database and a real OpenAI credential. Found and fixed:
1. $env access is blocked on this n8n instance (N8N_BLOCK_ENV_ACCESS_IN_NODE).
parseConfig($env) threw "access to env vars denied" on the very first
Code node. Config now comes from the "Config - Coordenador GLPI v2" Set
node instead (same pattern the V1 workflow already used) -- expanded
that node with all 13 tunable parameters, and pointed the 3 affected
node drivers (build-sql-candidatos, decide-needs-ai, select-top10) at
it instead of $env.
2. Data Table "upsert" operation requires both `columns` (values) and a
separate `filters` (match condition) -- I had only set columns with
matchingColumns, which isn't enough; n8n refused to activate the
workflow ("Missing or invalid required parameters: filters"). Added
filters.conditions matching on ticket_id to both memory-writing Data
Table nodes.
3. Real architecture bug: "Data Table - Buscar Memoria" sat inline in the
41-candidate chain (Mesclar Contexto -> Buscar Memoria -> Decidir
Necessidade de IA). A bulk "get all rows" Data Table node run with 41
input items produced 41 identical fetches and its OWN output (the empty
memory table on a first run) replaced the 41 candidates entirely --
"Decidir Necessidade de IA" received 0 items and the whole main branch
silently skipped. Moved the memory fetch to a parallel branch off
Config (fires once) and added a real Merge node ("Merge - Aguardar
Memoria") to guarantee both the candidates and the memory rows have
executed before "Decidir Necessidade de IA" runs -- same synchronization
pattern already used for context and for the shadow comparison.
Also fixed a cosmetic bug found in the real message output: buildTopMessage
produced a quadruple newline between the header and the first ticket block
([header, '', ...blocks].join('\n\n') double-counts the blank line already
inserted by the '\n\n' join). Added a regression test.
Verified with a real execution (id 13599, 24/08/2026 19:25 UTC) against the
live GLPI database: 41 real candidates, 30 sent to OpenAI (capped), 11
fallback-capped, memory table populated with 41 real rows including
genuine WAITING_VENDOR/WAITING_REQUESTER classifications with real
blocker_type/waiting_for fields extracted from real ticket task content,
and a real shadow_runs row comparing Legacy x V2 (4 tickets removed by V2:
2 for INSUFFICIENT_CONTEXT, 1 WAITING_REQUESTER, 1 WAITING_VENDOR; 4 added).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
GustavoandClaude Sonnet 5
|
60015c0972 |
feat(v2): add short message and coordination digest builders
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |