codigo limpo

global/workflows/otimizar-codigos.md

@@ -1,71 +1,30 @@
 ---
 type: workflow
 name: otimizar-codigos
-description: Agente especialista em limpeza e refatoração de código
+description: Agente especialista em limpeza e refatoração de código (Alias compatível para /codigo-limpo)
 scope: global
-updatedAt: "2026-06-03"
+updatedAt: "2026-09-16"
 ---
 
-Você é um agente especialista em limpeza e refatoração de código para projetos TypeScript, Vue 3, TSX e JSX.
+# Workflow: /otimizar-codigos (Alias para /codigo-limpo)
 
-Sua missão é melhorar a legibilidade, organização e manutenção do código, sem alterar o comportamento funcional.
+> ⚡ **Evolução Canônica:** Este fluxo de trabalho evoluiu e está totalmente integrado ao workflow oficial **[`/codigo-limpo`](./codigo-limpo.md)**, estruturado com as **12 Regras Canônicas do Código Limpo**.
 
-## Regras principais
+## As 12 Regras Canônicas
 
-1. Não altere regras de negócio.
-2. Não mude nomes públicos de props, emits, funções exportadas ou contratos de API.
-3. Não remova validações existentes.
-4. Não altere layout visual sem necessidade.
-5. Nenhum arquivo `.vue`, `.ts`, `.tsx` ou `.jsx` deve ultrapassar 250 linhas.
-6. Se o arquivo estiver grande, proponha separação em:
-   - composables
-   - helpers
-   - constants
-   - dispatch tables
-   - arquivos `.css` separados
-7. O `setup()` de componentes Vue não deve ser separado do componente.
-8. CSS pode ser separado em:
-   - `NomeDoArquivo.vue`
-   - `NomeDoArquivo.css`
-9. Quando houver separação de arquivos, melhore a estrutura de pastas (ex: convertendo o arquivo principal em uma pasta dedicada contendo `index.vue` ou `index.ts` junto com seus arquivos auxiliares e subcomponentes).
+1. **Nomes significativos e sem "Números Mágicos":** Intenção revelada no nome; substituição de números mágicos por constantes/enums descritivos.
+2. **O código deve explicar a si mesmo:** Evitar comentários redundantes; comentar somente o *porquê* de decisões técnicas ou regras de negócio.
+3. **Prefira Mapeamento (Dispatch Tables) a Switch/If-Else encadeados:** Mapear status/chaves para funções, dados ou componentes em vez de criar tripas de condicionais.
+4. **Funções devem ser pequenas:** Uma única responsabilidade clara por função (máx. 25-30 linhas).
+5. **Reduza o número de parâmetros:** Máximo 1 ou 2 argumentos. Para 3 ou mais, agrupar em um Objeto/Interface de parâmetros.
+6. **Não crie efeitos colaterais:** Funções puras e previsíveis sem mutações ocultas fora do escopo.
+7. **Princípio DRY (Don't Repeat Yourself):** Eliminar duplicação reutilizando funções, composables e componentes.
+8. **Responsabilidade Única (SRP) e Limite de 250 Linhas:** Nenhum arquivo pode ultrapassar 250 linhas (`verificar-linhas.sh`). Separar em `index.vue`, `SecaoX.vue`, `*.mapeadores.ts` e `*.css`.
+9. **Formatação e Padronização:** Manter consistência automatizada com Biome (`biome check --write`).
+10. **Trate erros com elegância:** Sem blocos `catch` vazios; lançar exceções semânticas e prover feedback visível (`feedback-visivel.md`).
+11. **Testes devem ser limpos e independentes:** Testes rápidos, isolados e focados em um conceito por vez.
+12. **A Regra do Escoteiro:** Deixar o código mais limpo do que o encontrou a cada intervenção.
 
-## O que limpar
+---
 
-- imports não utilizados
-- variáveis não utilizadas
-- funções duplicadas
-- nomes confusos
-- blocos muito grandes
-- condicionais repetidas
-- código morto
-- comentários óbvios
-- funções inline complexas
-- tipagens fracas ou `any` desnecessário
-- componentes com responsabilidade demais
-
-## Padrões desejados
-
-- Preferir funções pequenas e nomeadas.
-- Usar `computed`, `ref` e `reactive` de forma clara.
-- Usar `PropType<T>` quando a prop tiver tipo complexo.
-- Sempre usar **Dispatch Table** fortemente tipada para substituir múltiplos blocos de `if`, `else` ou `switch`.
-- Sempre dar prioridade para uso de enums.
-- Manter tipagens existentes sempre que possível.
-- Criar nomes claros e objetivos.
-- Preservar compatibilidade com Vue 3 e TypeScript.
-
-## Saída esperada
-
-Para cada arquivo analisado, retorne:
-
-1. Problemas encontrados
-2. Melhorias aplicadas
-3. Código final refatorado
-4. Arquivos sugeridos caso seja necessário dividir
-
-## Formato da resposta
-
-- Seja direto.
-- Não explique conceitos básicos.
-- Entregue o código pronto.
-- Quando separar arquivos, mostrar o conteúdo completo de cada arquivo.
+Para a documentação completa, detalhes operacionais e exemplos práticos, consulte **[`global/workflows/codigo-limpo.md`](./codigo-limpo.md)**.