Rafael MelgaçoandClaude Opus 5 53bda83ebd feat(crm-vivo): o card oferece a retomada, com o prazo na cara [wave 7 · 23] ...

A faixa ③ ganha um quarto estado e a precedência fica
`awaiting > reactivation > cooling > medidor`. Ela separa INFORMAR de PERMITIR
AGIR: `cooling` diz "este negócio parou"; a proposta diz "parou E aqui está o
que fazer". Mostrar "parado há 3 dias" quando existe proposta viva ESCONDE a
decisão — e o card cujo propósito é provocar decisão passaria a só descrever o
problema.

Continua perdendo para a próxima ação do agente, por coerência com o cenário 24
já decidido: duas decisões pendentes no mesmo card é a pilha que o §5 proíbe.

O PRAZO APARECE NO CARD, e é a diferença visível em relação à wave 4. Proposta
com prazo que não mostra o prazo é a mesma simulação de atenção que o prazo
existe para evitar: quem olha precisa saber que a janela fecha, senão "decido
depois" é indistinguível de "decidi não".

"Encerrar" e não "Ignorar": ignorar não é decisão, e a recusa aqui É decisão
registrada — o que distingue negócio encerrado com critério de negócio
esquecido.

SEM REALTIME, E ISSO É DECLARADO: a entrega em tempo real está sob disputa entre
dois aparatos, e construir a tela em cima dela produziria trabalho que não pode
ser provado. A proposta aparece no refetch (60s, porque o prazo corre e uma
proposta vencida não pode continuar oferecendo botão). Quando o realtime tiver
veredito, isto ganha a assinatura junto com a peça 3.

O HOOK NÃO USA O ECO LOCAL, ao contrário do irmão da wave 4: os tipos
`reactivation_*` estão fora da lista positiva da 0079, então não carimbam
`last_activity_at` — o lead não é tocado, o board não pulsa, não há eco a
suprimir, e marcar um deixaria marca pendurada esperando evento que nunca vem.

PROVA NA TELA (tests/sonda-card-reativacao.ts):
  1. a faixa mostra a proposta ............... sim
  2. mostra o PRAZO .......................... sim, "· 2d"
  3. os dois botões decidem .................. Retomar / Encerrar
  4. o card cresceu? ......................... NÃO — 144px com e sem proposta,
     medido contra um card VIZINHO e não contra um número que eu escolhi
  5. decidir tira a oferta da tela ........... sim, DEPOIS do conserto

O ITEM 5 ACHOU DEFEITO REAL: o servidor respondia `accepted` e o card SEGUIA
OFERECENDO o botão. O hook invalidava só `["board", pipelineId]`, e a lista de
propostas vive em `["reactivations"]` — um lado mudou, o outro não acompanhou, e
nada reclamou. Clicar de novo daria 409 e o usuário concluiria que o sistema não
obedeceu. É a família de defeito da entrega inteira, agora no cache.

Vai junto a adoção do `escolherAlvo()` do QAVivo na sonda de realtime: ela
pegava lead com `limit 1` SEM ORDEM, e o "2/2, tudo chega" que eu reportei como
contradição não contradizia nada — media outro lead. O helper recusa lista
vazia, ordena e LOGA qual de quantos escolheu.

typecheck 0 · lint 0 erros · 442 testes em 71 arquivos.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013dxBNZMjUzBx8xWs8DvGvP

2026-07-25 15:21:36 -03:00

163 KiB

1500x950px

Raw Permalink History