fix(followup): excluir nó ou aresta passa a pedir confirmação (#700) - #749
fix(followup): excluir nó ou aresta passa a pedir confirmação (#700)#749webtecnica wants to merge 1 commit into
Conversation
…afael#700) O botão de excluir a SELEÇÃO no builder de follow-up dividia o mesmo assento da barra com o botão que apaga o fluxo inteiro — mesmo ícone de lixeira, mesma cor destrutiva, mesma posição — e disparava a exclusão no primeiro clique. O irmão ao lado confirmava antes. Quem aprendeu a confiar na lixeira daquele canto clicava no botão mais à mão (o que existe para limpar o que acabou de ser selecionado) com a mesma confiança e perdia o trabalho do canvas sem aviso: a assimetria entre dois botões gêmeos era o defeito. Agora os dois têm o mesmo contrato: o clique abre um `AlertDialog` que NOMEIA o alvo — "Excluir este nó?" ou "Excluir esta aresta?", conforme a seleção — e diz o que vai junto (as arestas ligadas ao nó; a ligação entre os dois nós) e que não há desfazer. A exclusão só acontece no clique de confirmação; cancelar não muda nada. Os textos novos entram no dicionário PT→ES e a regra fica escrita em `docs/doctrine/destrutivo-pede-confirmacao.md`. Testes em app/app/ai/followups/[id]/_components/PublishBar.test.tsx: nada é excluído antes de confirmar, cancelar não exclui, confirmar exclui uma vez, o título acompanha a seleção — e, sem seleção, o lugar segue sendo do irmão do fluxo (é ele quem apaga o fluxo inteiro, com a confirmação que já existia).
|
@webtecnica is attempting to deploy a commit to the rafael-maudibrasil's projects Team on Vercel. A member of the Team first needs to authorize it. |
ECC Tools / Security EvidenceCommit: Security evidence gate passed (success) No security-sensitive scanner-evidence gap detected. Mode: enforce Scanned 6 changed file(s). No missing scanner-evidence signal was detected. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / PR Risk TaxonomyCommit: PR taxonomy review recommended (neutral) Detected 2 PR taxonomy bucket(s): CI/CD Recommendation, Cost/Token Risk. Scanned 6 changed file(s). Roadmap taxonomy buckets: CI/CD RecommendationCI, dependency, coverage, and contract signals should be routed into follow-up checks or verification work. Signals:
Paths:
Cost/Token RiskAI routing, usage, and token-budget changes should include budget or usage-limit evidence. Signals:
Paths:
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
ECC Tools / Reference Set ReadinessCommit: Reference set readiness gaps detected (neutral) Reference evidence present for 0/7 areas (0%) across 6 changed file(s). This check is based on files changed in this PR. Repository-level readiness is still reported by
Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
|
Recebido, @webtecnica — obrigado por isto. Duas coisas que vão parecer erro seu e não são:
Um mantenedor vai revisar de verdade — rodando os gates e reproduzindo o comportamento, não só Esta mensagem é automática e não diz nada sobre o seu PR: ela é sobre o processo. O que vem |
ECC Tools / Hosted Promotion ReadinessCommit: Hosted promotion readiness passed (success) No hosted promotion evidence gaps detected across 6 changed file(s); 0 corpus scenarios had matching evidence. This check compares PR file changes against the evaluator/RAG promotion corpus in No evaluator corpus scenarios matched this PR. Check publication was denied or unavailable. An app owner must enable Checks: read and write, and the installation owner must approve the updated permission. |
1 participant
O que este PR faz
Excluir nó ou aresta no builder de follow-up passa a pedir confirmação: o botão de excluir a seleção abre um diálogo, e a exclusão só acontece na confirmação.
Antes, o botão ocupava o lugar do "Excluir fluxo", com o mesmo ícone e sem confirmação — um clique errado apagava a seleção.
Closes #700
Como resolve
app/app/ai/followups/[id]/_components/PublishBar.tsx— o botão de excluir a seleção passa a apenas abrir oAlertDialog; a exclusão acontece no clique de confirmação.app/app/ai/followups/[id]/_components/PublishBar.test.tsx(novo) — 5 testes de comportamento.lib/i18n/dicionario.ts— 4 chaves novas PT→ES (títulos e descrições, nó × aresta).docs/doctrine/destrutivo-pede-confirmacao.md(novo) — a regra, como a issue pediu;docs/index.mdganha a linha na tabela de doutrina..changes/excluir-no-pede-confirmacao.md— fragmento (impacto: nada_mudou,secao: corrigido).O que medi (comandos e saídas)
pnpm exec vitest run app/app/ai/followups/[id]/_components/PublishBar.test.tsxcom os vizinhos → 5 files passed, 23 tests na rodada de referência (4,84s); os 5 novos são de comportamento no call-site.Sabotagem (pós-commit; previsão escrita antes: os 4 testes do diálogo em vermelho, o 5º "sem seleção" verde): revertendo os dois arquivos que carregam o fix (
PublishBar.tsx+dicionario.ts) → Tests 4 failed | 19 passed (23), exatamente as 4 do diálogo — a última emPublishBar.test.tsx:122, comfindByRole("alertdialog")não achando nada porque o botão voltou a excluir direto. A previsão extra — o gatei18n-espanhol-cobre-a-telaficar vermelho — errou, e o motivo fica registrado: o gate mede chave usada sem tradução; revertendo componente e dicionário os dois lados ficam consistentes e ele passa. Restaurado comgit checkout HEAD -- <os dois>→git statuslimpo e verdes de novo.Gates —
eslint --max-warnings=0nos três arquivos rc=0 nas medições focadas;release:conferirrc=0 (1.20.0 + patch = 1.20.1, fragmento.changes/excluir-no-pede-confirmacao.md); e a fila local completa (um pesado por vez —flock+systemd-run --scope -p MemoryMax=5G):pnpm typecheckpnpm lintpnpm lint:channelspnpm lint:role-rankpnpm release:conferirpnpm test:unitpnpm test:shellpnpm buildNota: o primeiro
lintda fila foi interrompido por SIGTERM (rc=143), travado em espera de I/O (estadoD) com dois lotes de gate concorrentes na máquina; a re-rodada fechou rc=0 com 0 errors (os avisos são pré-existentes do repo) — está na tabela acima.O que NÃO medi
tests/invariants/**— precisa de Postgres/Docker, fora do include do vitest focado.2 failed | 1 passed (3)com 416s (transform 304s) — cara de contenção de máquina; as execuções imediatamente anterior e posterior, mesmo comando, deram verdes em ~5s. Não reproduziu e não investiguei a fundo.prettier --checknão é gate do CI (gov:verifynão incluiformat:check) e reprova arquivos pré-existentes; não rodei--writepara não inflar o diff.