mirror of
https://github.com/melgarafael/DeskcommCRM.git
synced 2026-10-02 01:28:34 +08:00
Achado DIRIGINDO A TELA, que e o unico jeito de ter achado: nenhum gate
assertava a linha de auditoria, e o erro so aparece no log do servidor.
[audit] insert error invalid input syntax for type uuid: "stage_classifier"
{ action: 'ai.purpose_binding_updated' }
`api_audit_log.resource_id` e **uuid**; a rota mandava `corpo.purpose`, que
e texto. O insert falhava com 22P02 e, como o audit e fire-and-forget, o
erro nao chegava a lugar nenhum. Resultado: NENHUMA troca de modelo era
auditada — num painel cujo efeito e mudar para onde vao o dinheiro e os
dados do cliente. DoD 5 do repo violado em silencio.
Conserto: `resourceId` recebe o id da LINHA (o upsert passa a devolve-lo) e
o `purpose` vai para o metadata, onde texto e aceito. Guarda em
`provedores-x-registry.test.ts`.
PROVA PELA TELA (DoD 12), em ambiente com o baseline aplicado e as
migrations 0139/0141:
- `prova-painel-provedores.spec.ts` 8/8 verdes, com o erro de audit
desaparecido do log (0 ocorrencias contra 1 antes).
- Caso novo: numa instalacao SEM agente publicado — o estado de quem acabou
de instalar — os dois pontos que respondem o cliente ficam EDITAVEIS.
Antes apareciam sem seletor, dizendo que sao governados por uma versao
publicada que nao existe. Evidencia em
`evidence/provedores/08-sem-agente-publicado-destravado.png`: "Responder o
cliente" e "Trabalhar o funil" com Provedor/Modelo/Chave e botao Salvar.
- O timeout da spec foi a 90s, e a razao esta escrita no arquivo: cada caso
refaz o login e o TOTP tem janela de 30s, entao dois logins na mesma
janela obrigam a esperar a virada — espera que comia o timeout padrao e
aparecia como "o botao nao respondeu". Medido por instrumento que a tela
NAO e o gargalo: abrir cada grupo do painel com 424 modelos no catalogo
custa 60-105ms.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FkS3mzwtXughmjVC5FCoNo
260 KiB
1280x2424px
260 KiB
1280x2424px