gustavosantos/SLACK_COORD_RELATORIO
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(v2): WAITING_*/blocked classes never enter Top10 regardless of contextChanged

Browse Source 
Real bug confirmed in the prior cycle's Run A: WAITING_VENDOR tickets
entered the Top10 solely because contextChanged=true (a fresh AI call
happened this run) -- contextChanged should only decide whether to
reanalyze (logic/cache.js), never whether an already-still-blocked
ticket can compete.

logic/cooldown.js: removed the `&& !contextChanged` condition from the
BLOCKING_CLASSIFICATIONS check in computeCooldown -- a ticket whose
CURRENT classification (fresh or cached) is in BLOCKING_CLASSIFICATIONS
is now excluded unconditionally. Also expanded BLOCKING_CLASSIFICATIONS
to the full list required this cycle: WAITING_REQUESTER, WAITING_VENDOR,
WAITING_APPROVAL, SCHEDULED, DEPENDENCY_BLOCKED, PROJECT_LONG_TERM,
DUPLICATE_OR_OBSOLETE (WAITING_APPROVAL/PROJECT_LONG_TERM/
DUPLICATE_OR_OBSOLETE previously only had a score penalty, not exclusion
-- WAITING_APPROVAL has positive base score points, so it could
genuinely win a Top10 slot before this fix). The critical-override escape
hatch (SLA vencido + prioridade alta, etc.) is untouched -- still the
only way a blocked classification can surface.

logic/cooldown.test.js: rewrote the one test that was actually asserting
the buggy behavior ("mudanca de contexto real desbloqueia mesmo em
estado de espera" -> now proves the opposite, with a comment explaining
why); added tests for the chronology-driven unblock case (ticket moves
out of a blocking classification entirely) and the two newly-blocking
classes.
logic/score.test.js: added end-to-end tests through computeScore()
proving WAITING_VENDOR and WAITING_APPROVAL are excludedFromTop10 even
with contextChanged=true.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Gustavo
2026-08-24 20:50:12 -03:00
co-authored by Claude Sonnet 5
parent 482b7ef48e
commit e0f4b9a5d0
3 changed files with 52 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
logic/cooldown.js
+13 -2
View File
@@ -1,7 +1,12 @@
const ONE_DAY_MS = 24 * 60 * 60 * 1000;
// Classes que NUNCA disputam o Top10 operacional -- bloqueadas por definicao, nao por cache.
// Lista expandida na missao "finalizacao para producao" (secao 10): WAITING_APPROVAL,
// PROJECT_LONG_TERM e DUPLICATE_OR_OBSOLETE entraram aqui (antes so tinham penalidade de
// score, o que deixava WAITING_APPROVAL -- pontuacao base positiva -- competir de verdade).
const BLOCKING_CLASSIFICATIONS = new Set([
'WAITING_REQUESTER', 'WAITING_VENDOR', 'SCHEDULED', 'DEPENDENCY_BLOCKED',
'WAITING_REQUESTER', 'WAITING_VENDOR', 'WAITING_APPROVAL', 'SCHEDULED',
'DEPENDENCY_BLOCKED', 'PROJECT_LONG_TERM', 'DUPLICATE_OR_OBSOLETE',
]);
// Regra centralizada de "isso e critico o bastante pra furar uma exclusao normal" --
@@ -53,7 +58,13 @@ function computeCooldown({ ticket, classification, contextChanged, memory, now,
} else if (nextReviewAt != null && now < nextReviewAt && !contextChanged) {
blocked = true;
reason = 'waiting_next_review';
} else if (BLOCKING_CLASSIFICATIONS.has(classification) && !contextChanged) {
} else if (BLOCKING_CLASSIFICATIONS.has(classification)) {
// BUG REAL comprovado na Run A anterior: WAITING_VENDOR entrou no Top10 so porque o
// contexto tinha mudado nesta execucao (contextChanged=true). contextChanged decide SE
// reanalisamos (logic/cache.js) -- nunca decide se um chamado que CONTINUA classificado
// numa classe bloqueada pode competir. Por isso este bloqueio e incondicional aqui: se a
// classificacao atual (fresca ou cacheada, tanto faz) esta em BLOCKING_CLASSIFICATIONS,
// fica fora do Top10, ponto. Missao "finalizacao para producao", secao 10.
blocked = true;
reason = `blocked_${classification.toLowerCase()}`;
}