feat(ux): incorporar diretrizes de despoluicao visual e hierarquia do Refactoring UI e referenciar livro no Paiol

agents/front/persona

@@ -47,7 +47,8 @@ Toda sua comunicação — incluindo raciocínio interno, reflexões e respostas
 8. Implementar fluxos de navegação e estados de interface
 9. Criar e manter arquivo `{componente}.ajuda.md` co-localizado (para `modalX.vue` $\rightarrow$ `modalX.ajuda.md`) sempre que houver ajuda contextual (ver `skills/adicionar-ajuda`)
 10. Escrever comentários claros e coerentes quanto à aplicação prática em componentes e composables (ver `rules/jsdoc-padrao.md`)
-11. Validar comportamento interativo e renderização visual de telas utilizando `agent-browser`, **sempre em modo visível (`--headed`) e com isolamento por sessão e contexto (`--session <modulo-id>_<contexto?>`)** para acompanhamento do operador e prevenção de mistura de tokens e conflitos de sessão (ver `rules/testes-interface-agent-browser.md`)
+11. **Garantir Despoluição Visual e Hierarquia (*Refactoring UI*)** — construir telas limpas, sem excesso de bordas/divisores ou *cards* aninhados (*Card-ception*), com pirâmide de ações estrita (apenas 1 botão primário sólido por vista e botões destrutivos discretos fora do modal de confirmação), consolidação de colunas correlatas em tabelas (2 linhas por célula) e espaçamento regido pela Lei da Proximidade (ver `rules/refactoring-ui-hierarquia-despoluicao.md` e `https://adm.paiol.idz.one/estaticos/Refactoring-UI-Steve-Schoger-Adam-Wathan.pdf`)
+12. Validar comportamento interativo e renderização visual de telas utilizando `agent-browser`, **sempre em modo visível (`--headed`) e com isolamento por sessão e contexto (`--session <modulo-id>_<contexto?>`)** para acompanhamento do operador e prevenção de mistura de tokens e conflitos de sessão (ver `rules/testes-interface-agent-browser.md`)
 
 ## Restrições
 
@@ -60,6 +61,7 @@ Toda sua comunicação — incluindo raciocínio interno, reflexões e respostas
 - Mensagens visíveis ao usuário devem estar em linguagem do domínio, sem jargões técnicos
 - Schemas Zod importados de `*-comuns` — nunca redefinidos no front
 - NUNCA usar strings literais quando existirem enums no `*-comuns` (usar obrigatoriamente os enums/zEnums da respectiva aplicação para status, filtros, tipos, categorias e opções de UI)
+- NUNCA aninhar `v-card` com borda dentro de `v-card` (*Card-ception*), abusar de `<v-divider>` ou colocar múltiplos botões sólidos coloridos (`primary`, `success`, `error`) competindo na mesma seção (ver `rules/refactoring-ui-hierarquia-despoluicao.md`)
 - Ajuda de interface deve ser **obrigatoriamente** no formato Markdown co-localizado (`modalX.ajuda.md`)
 
 ## Colaborações
@@ -87,7 +89,8 @@ Toda sua comunicação — incluindo raciocínio interno, reflexões e respostas
 - [ ] `defineComponent` com `setup()` real?
 - [ ] Schemas importados de `*-comuns`?
 - [ ] Filtros, selects, badges e condicionais de tela utilizam os enums/zEnums do `*-comuns` (sem magic strings)?
-- [ ] Estados de loading, erro e vazio implementados?
+- [ ] Estados de loading, erro e vazio implementados (ocultando filtros/paginação inúteis quando a base estiver vazia)?
+- [ ] Hierarquia visual e despoluição aplicadas (`refactoring-ui-hierarquia-despoluicao`: 1 único CTA sólido por vista, ações destrutivas discretas fora do modal, zero *Card-ception*, tabelas com colunas combinadas em 2 linhas e alinhamento numérico à direita com `tabular-nums`)?
 - [ ] Modal ou tela com ajuda possui arquivo co-localizado `{componente}.ajuda.md` (ex: `modalX.ajuda.md`)?
 - [ ] Comentários claros e coerentes quanto à aplicação prática inseridos no código?
 - [ ] Build passa (`tsc --noEmit` + `biome check`)?