.
This commit is contained in:
parent
1adf19b92d
commit
1388a121bc
65 changed files with 157 additions and 5166 deletions
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: comercial
|
||||
description: Criar uma descrição comercial das funcionalidades e do sistema
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ updatedAt: "2026-06-01"
|
|||
|
||||
Este workflow gera uma descrição comercial de funcionalidades ou do sistema completo, escrita na pasta `./COMERCIAL/`. Cada módulo ou funcionalidade gera um arquivo separado com o padrão `./COMERCIAL/<nome-do-modulo>.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -138,7 +138,7 @@ O arquivo `./COMERCIAL/<nome-do-modulo>.md` deve seguir esta estrutura:
|
|||
|
||||
## Referências
|
||||
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
- Workflow: `.agent/workflows/orcamento.global.md` (texto para documentos de orçamento e proposta — apresentação + lista de funcionalidades)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing digital — LinkedIn, Instagram, WhatsApp, E-mail)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md` (para documentação técnica, não comercial)
|
||||
- Rule: `global/rules/escrita-natural.md` (padrão obrigatório de redação)
|
||||
- Workflow: `agents/ag-comercial/workflows/orcamento.md` (texto para documentos de orçamento e proposta — apresentação + lista de funcionalidades)
|
||||
- Workflow: `agents/ag-comercial/workflows/marketing.md` (peças de marketing digital — LinkedIn, Instagram, WhatsApp, E-mail)
|
||||
- Workflow: `global/workflows/otimizar-codigos.md` (para documentação técnica, não comercial)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: marketing
|
||||
description: Criar peças de marketing digital para funcionalidades e módulos do sistema
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ updatedAt: "2026-06-01"
|
|||
|
||||
Este workflow gera peças de marketing digital prontas para uso em canais como LinkedIn, Instagram, WhatsApp e E-mail. O resultado é salvo na pasta `./COMERCIAL/` junto ao arquivo comercial do módulo correspondente, ou em arquivo separado `./COMERCIAL/<nome-do-modulo>-marketing.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.md`) em toda produção textual deste workflow.
|
||||
|
||||
O agente deve atuar como **especialista em marketing digital voltado para o setor do produto (venda entre empresas)**, aplicando técnicas comprovadas de texto persuasivo e engajamento.
|
||||
|
||||
|
|
@ -205,5 +205,5 @@ O resultado deve ser salvo em `./COMERCIAL/<nome-do-modulo>-marketing.md` ou adi
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (gera os blocos A e B que alimentam o marketing)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
- Workflow: `agents/ag-comercial/workflows/comercial.md` (gera os blocos A e B que alimentam o marketing)
|
||||
- Rule: `global/rules/escrita-natural.md` (padrão obrigatório de redação)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: orcamento
|
||||
description: Criar texto de orçamento pronto para copiar e colar em peças de orçamento/proposta
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ updatedAt: "2026-06-01"
|
|||
|
||||
Este workflow gera textos prontos para **copiar e colar dentro de documentos de orçamento e propostas comerciais**. O resultado é salvo na pasta `./COMERCIAL/` com o sufixo `-orcamento` (ex: `./COMERCIAL/<nome-do-modulo>-orcamento.md`).
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -129,6 +129,6 @@ se aplicável, legislação ou norma relevante citada por extenso.]
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (descrição comercial detalhada — Resumo e Detalhamento)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing digital)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
- Workflow: `agents/ag-comercial/workflows/comercial.md` (descrição comercial detalhada — Resumo e Detalhamento)
|
||||
- Workflow: `agents/ag-comercial/workflows/marketing.md` (peças de marketing digital)
|
||||
- Rule: `global/rules/escrita-natural.md` (padrão obrigatório de redação)
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: reels
|
||||
description: Criar cadeia de roteiros de Reels para divulgação de funcionalidades e módulos
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ updatedAt: "2026-06-01"
|
|||
|
||||
Este workflow gera **cadeias de roteiros de Reels** (vídeos curtos de 30 a 60 segundos) organizados por tema. Os roteiros são escritos em tom provocativo, informal e direto — prontos para gravar falando para a câmera ou com narração em off. O resultado é salvo em `./COMERCIAL/<nome-do-modulo>-reels.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -199,6 +199,6 @@ O arquivo `./COMERCIAL/<nome-do-modulo>-reels.md` deve seguir esta estrutura:
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (descrição comercial detalhada — base de contexto)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing por canal)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
- Workflow: `agents/ag-comercial/workflows/comercial.md` (descrição comercial detalhada — base de contexto)
|
||||
- Workflow: `agents/ag-comercial/workflows/marketing.md` (peças de marketing por canal)
|
||||
- Rule: `global/rules/escrita-natural.md` (padrão obrigatório de redação)
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Você é o agente responsável pela infraestrutura, pipelines e ambientes do eco
|
|||
- Dockerfiles e `docker-compose.yml`
|
||||
- Scripts de CI/CD
|
||||
- Variáveis de ambiente e secrets
|
||||
- Scripts de distribuição do `.agent/`
|
||||
- Scripts de sincronização do `.agent/` (submodule + inherited)
|
||||
- Automações e tarefas agendadas de infraestrutura
|
||||
|
||||
## Responsabilidades
|
||||
|
|
|
|||
|
|
@ -1,46 +1,54 @@
|
|||
---
|
||||
type: workflow
|
||||
name: atualizar-agente
|
||||
description: Aplica atualizações globais para o agente de IA
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: Atualiza o submodule AGENT-IA e sincroniza artefatos herdados
|
||||
scope: local
|
||||
updatedAt: "2026-06-18"
|
||||
---
|
||||
|
||||
# Workflow: Atualizar Agente Global
|
||||
# Workflow: Atualizar Agente (Submodule)
|
||||
|
||||
## Objetivo
|
||||
|
||||
Baixar e aplicar a versão mais recente das rules, workflows e tools globais a partir do servidor central (`paiol.idz.one`).
|
||||
Atualizar o submodule `.agent/base/` para a versão mais recente do AGENT-IA e sincronizar os artefatos herdados no projeto.
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Baixar o script de atualização (se ainda não existir)
|
||||
### 1. Atualizar o submodule
|
||||
|
||||
```bash
|
||||
curl -fL# "https://paiol.idz.one/desenvolvimento/agent-ia/atualizar-agente-global.sh" -o .agent/atualizar-agente.global.sh
|
||||
chmod +x .agent/atualizar-agente.global.sh
|
||||
cd .agent/base
|
||||
git pull origin main
|
||||
cd ../..
|
||||
git add .agent/base
|
||||
```
|
||||
|
||||
### 2. Executar o script
|
||||
### 2. Executar o script de sincronização
|
||||
|
||||
// turbo
|
||||
|
||||
```bash
|
||||
sh .agent/atualizar-agente.global.sh
|
||||
sh .agent/atualizar-agente.sh
|
||||
```
|
||||
|
||||
O script possui auto-atualização: na primeira execução, ele baixa sua própria versão mais recente e re-executa automaticamente.
|
||||
O script sincroniza `.agent/inherited/` com os artefatos do `base/`, sem tocar em `local/`.
|
||||
|
||||
### 3. Verificar resultado
|
||||
|
||||
Confirmar que os arquivos foram atualizados sem duplicações:
|
||||
Confirmar que a estrutura está íntegra:
|
||||
|
||||
```bash
|
||||
find .agent/ -name "*.md" -o -name "*.sh" | sort
|
||||
echo "=== Herdados ===" && find .agent/inherited/ -name "*.md" | sort
|
||||
echo "=== Locais ===" && find .agent/local/ -name "*.md" | sort 2>/dev/null || echo "(vazio)"
|
||||
```
|
||||
|
||||
Resultado esperado: todos os arquivos `.md` devem ter o sufixo `.global` (exceto `tools.md`).
|
||||
|
||||
### 4. Revisar mudanças (quando aplicável)
|
||||
|
||||
Se houve alterações significativas nas rules ou workflows, executar `/aprimorar-IA` para validar consistência do sistema de conhecimento.
|
||||
Se houve alterações significativas nas rules ou workflows herdados, executar `/aprimorar-IA` para validar consistência do sistema de conhecimento.
|
||||
|
||||
### 5. Commitar a atualização
|
||||
|
||||
```bash
|
||||
git add .agent/base
|
||||
git commit -m "chore: atualizar agent-ia para versão mais recente"
|
||||
```
|
||||
|
|
@ -26,7 +26,7 @@ Você é o agente responsável por tornar o conhecimento do ecossistema Azteca a
|
|||
## Escopo de Atuação
|
||||
|
||||
- Todos os pacotes: `*-back`, `*-front`, `*-comuns`
|
||||
- Diretório `.agent/` (regras, workflows, skills, memória)
|
||||
- Diretório `.agent/` (base/ herdado + local/ extensões + memoria/)
|
||||
- Arquivos `.regras-negocio.md` co-localizados
|
||||
- JSDoc em funções compartilhadas
|
||||
- Guias de usuário e ajuda contextual nas telas
|
||||
|
|
|
|||
|
|
@ -1,169 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: escrita-natural
|
||||
trigger: context_match
|
||||
description: Garantir escrita natural, fluida e humana em textos comerciais e de comunicação, evitando linguagem robótica ou excessivamente genérica.
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
ativacao: >
|
||||
Aplicar quando o agente estiver produzindo textos comerciais, de marketing,
|
||||
orçamentos, propostas, reels ou qualquer comunicação voltada ao público externo.
|
||||
NÃO aplicar em documentação técnica (ADRs, rules, JSDoc, regras de negócio).
|
||||
---
|
||||
|
||||
# Regra: Escrita Estratégica e Natural
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Produzir textos que:
|
||||
|
||||
- Mostrem domínio real do problema
|
||||
- Se destaquem entre propostas genéricas
|
||||
- Soem humanos, não institucionais
|
||||
- Convençam com clareza e impacto
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Princípios obrigatórios
|
||||
|
||||
### 1. Começar pelo problema real
|
||||
|
||||
Evitar introduções genéricas.
|
||||
|
||||
❌
|
||||
"O presente projeto tem como objetivo..."
|
||||
|
||||
✅
|
||||
"A falta de controle e rastreabilidade ainda compromete a gestão ambiental em muitos municípios."
|
||||
|
||||
---
|
||||
|
||||
### 2. Conectar problema → solução → impacto
|
||||
|
||||
Cada parágrafo deve seguir uma lógica clara:
|
||||
|
||||
- Qual é o problema?
|
||||
- Como a solução resolve?
|
||||
- O que muda na prática?
|
||||
|
||||
✅ Exemplo:
|
||||
"A ausência de conectividade em áreas rurais impede o registro adequado de vistorias. A solução permite coleta offline diretamente no celular. Como resultado, elimina perda de informação e reduz retrabalho."
|
||||
|
||||
---
|
||||
|
||||
### 3. Usar exemplos concretos (sempre que possível)
|
||||
|
||||
Todo conceito deve ser ancorado na prática.
|
||||
|
||||
❌
|
||||
"A solução permite coleta de dados estruturados."
|
||||
|
||||
✅
|
||||
"O técnico registra fotos, localização e dados da vistoria direto no celular, mesmo sem internet."
|
||||
|
||||
---
|
||||
|
||||
### 4. Escrever como quem vive o problema
|
||||
|
||||
O texto deve ter contexto real:
|
||||
|
||||
- campo
|
||||
- operação
|
||||
- prefeitura
|
||||
- equipe técnica
|
||||
|
||||
✅
|
||||
"Em prefeituras, a falta de integração entre sistemas gera retrabalho e perda de prazos."
|
||||
|
||||
---
|
||||
|
||||
### 5. Persuasão baseada em impacto real
|
||||
|
||||
Evitar adjetivos vazios.
|
||||
|
||||
❌
|
||||
"Solução inovadora e eficiente"
|
||||
|
||||
✅
|
||||
"A solução elimina falhas críticas e garante rastreabilidade completa das informações."
|
||||
|
||||
---
|
||||
|
||||
### 6. Linguagem natural (sem burocracia)
|
||||
|
||||
Preferir:
|
||||
|
||||
- "Com a solução..."
|
||||
- "Na prática..."
|
||||
- "Isso permite..."
|
||||
- "Como resultado..."
|
||||
|
||||
Evitar:
|
||||
|
||||
- "Dessa forma"
|
||||
- "Destarte"
|
||||
- "O presente projeto"
|
||||
|
||||
---
|
||||
|
||||
### 7. Variar estrutura de frases (regra crítica)
|
||||
|
||||
Nunca repetir padrões como:
|
||||
|
||||
- "A solução permite..."
|
||||
- "O sistema permite..."
|
||||
|
||||
Alternar com:
|
||||
|
||||
- "Na prática, o técnico..."
|
||||
- "Com isso..."
|
||||
- "Isso reduz..."
|
||||
- "Como resultado..."
|
||||
|
||||
---
|
||||
|
||||
### 8. Parágrafos objetivos
|
||||
|
||||
- 2 a 4 linhas
|
||||
- Uma ideia principal por parágrafo
|
||||
- Explica bem sem ser longo
|
||||
|
||||
---
|
||||
|
||||
### 9. Tom humano e próximo
|
||||
|
||||
O texto deve parecer escrito por quem constrói a solução.
|
||||
|
||||
✅
|
||||
"A solução resolve um problema real que impacta o dia a dia das equipes."
|
||||
|
||||
---
|
||||
|
||||
## 🚫 Proibido
|
||||
|
||||
- Texto genérico que serve para qualquer projeto
|
||||
- Parágrafos longos sem exemplo
|
||||
- Repetição de estrutura
|
||||
- Uso de termos sem explicação prática
|
||||
- Linguagem excessivamente institucional
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist final
|
||||
|
||||
Antes de finalizar:
|
||||
|
||||
- [ ] O problema está claro?
|
||||
- [ ] Existe exemplo prático?
|
||||
- [ ] O impacto está explícito?
|
||||
- [ ] O texto soa humano?
|
||||
- [ ] Há repetição de estrutura?
|
||||
- [ ] Parece algo real ou genérico?
|
||||
|
||||
---
|
||||
|
||||
## 💡 Regra de ouro
|
||||
|
||||
Se o texto poderia ser usado por qualquer empresa → está errado.
|
||||
|
||||
Se parece que vem de quem vive o problema → está certo.
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: jsdoc-padrao
|
||||
description: Padrões de documentação em código (JSDoc, casts temporários e TODOs estruturados)
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
- "**/*.vue"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Documentação em Código
|
||||
|
||||
## 1. JSDoc — Princípios
|
||||
|
||||
- **Por que, não o Quê**: documente o raciocínio, não o mecanismo que o TypeScript já expressa.
|
||||
- **Nomenclatura limpa**: confie em nomes expressivos antes de comentários.
|
||||
|
||||
## 2. JSDoc obrigatório em funções compartilhadas
|
||||
|
||||
Toda função central ou de uso compartilhado deve ter cabeçalho JSDoc:
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* Busca detalhes da entidade e calcula privilégios aplicáveis.
|
||||
* Não utilizar em processamento em lote para evitar sobrecarga.
|
||||
*
|
||||
* @param tenantId - Identificador do tenant no sistema
|
||||
* @param entityId - ID do registro na base de dados
|
||||
* @returns Objeto consolidado ou `null` se não encontrado
|
||||
*/
|
||||
export const obterDetalhes = async (tenantId: string, entityId: string) => { ... }
|
||||
```
|
||||
|
||||
## 3. Casts temporários — justificativa obrigatória
|
||||
|
||||
Coerções agressivas requerem comentário explicando o porquê:
|
||||
|
||||
```typescript
|
||||
// Necessário: biblioteca externa não provê tipagem genérica na versão atual
|
||||
const dados = payload.raw as unknown as RespostaFormatada
|
||||
```
|
||||
|
||||
## 4. TODOs estruturados
|
||||
|
||||
Dívida técnica ou dúvida de negócio deve seguir formato padronizado:
|
||||
|
||||
- **Tipagem**: `// TODO de tipagem: Criar interface para o retorno da API`
|
||||
- **Negócio**: `// TODO de regra: Validar com Produto se taxa se aplica a clientes antigos`
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem este padrão, funções compartilhadas ficam sem documentação, casts aparecem sem justificativa, e TODOs são inconsistentes e difíceis de buscar.
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
|
|
@ -1,169 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: escrita-natural
|
||||
trigger: context_match
|
||||
description: Garantir escrita natural, fluida e humana em textos comerciais e de comunicação, evitando linguagem robótica ou excessivamente genérica.
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
ativacao: >
|
||||
Aplicar quando o agente estiver produzindo textos comerciais, de marketing,
|
||||
orçamentos, propostas, reels ou qualquer comunicação voltada ao público externo.
|
||||
NÃO aplicar em documentação técnica (ADRs, rules, JSDoc, regras de negócio).
|
||||
---
|
||||
|
||||
# Regra: Escrita Estratégica e Natural
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Produzir textos que:
|
||||
|
||||
- Mostrem domínio real do problema
|
||||
- Se destaquem entre propostas genéricas
|
||||
- Soem humanos, não institucionais
|
||||
- Convençam com clareza e impacto
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Princípios obrigatórios
|
||||
|
||||
### 1. Começar pelo problema real
|
||||
|
||||
Evitar introduções genéricas.
|
||||
|
||||
❌
|
||||
"O presente projeto tem como objetivo..."
|
||||
|
||||
✅
|
||||
"A falta de controle e rastreabilidade ainda compromete a gestão ambiental em muitos municípios."
|
||||
|
||||
---
|
||||
|
||||
### 2. Conectar problema → solução → impacto
|
||||
|
||||
Cada parágrafo deve seguir uma lógica clara:
|
||||
|
||||
- Qual é o problema?
|
||||
- Como a solução resolve?
|
||||
- O que muda na prática?
|
||||
|
||||
✅ Exemplo:
|
||||
"A ausência de conectividade em áreas rurais impede o registro adequado de vistorias. A solução permite coleta offline diretamente no celular. Como resultado, elimina perda de informação e reduz retrabalho."
|
||||
|
||||
---
|
||||
|
||||
### 3. Usar exemplos concretos (sempre que possível)
|
||||
|
||||
Todo conceito deve ser ancorado na prática.
|
||||
|
||||
❌
|
||||
"A solução permite coleta de dados estruturados."
|
||||
|
||||
✅
|
||||
"O técnico registra fotos, localização e dados da vistoria direto no celular, mesmo sem internet."
|
||||
|
||||
---
|
||||
|
||||
### 4. Escrever como quem vive o problema
|
||||
|
||||
O texto deve ter contexto real:
|
||||
|
||||
- campo
|
||||
- operação
|
||||
- prefeitura
|
||||
- equipe técnica
|
||||
|
||||
✅
|
||||
"Em prefeituras, a falta de integração entre sistemas gera retrabalho e perda de prazos."
|
||||
|
||||
---
|
||||
|
||||
### 5. Persuasão baseada em impacto real
|
||||
|
||||
Evitar adjetivos vazios.
|
||||
|
||||
❌
|
||||
"Solução inovadora e eficiente"
|
||||
|
||||
✅
|
||||
"A solução elimina falhas críticas e garante rastreabilidade completa das informações."
|
||||
|
||||
---
|
||||
|
||||
### 6. Linguagem natural (sem burocracia)
|
||||
|
||||
Preferir:
|
||||
|
||||
- "Com a solução..."
|
||||
- "Na prática..."
|
||||
- "Isso permite..."
|
||||
- "Como resultado..."
|
||||
|
||||
Evitar:
|
||||
|
||||
- "Dessa forma"
|
||||
- "Destarte"
|
||||
- "O presente projeto"
|
||||
|
||||
---
|
||||
|
||||
### 7. Variar estrutura de frases (regra crítica)
|
||||
|
||||
Nunca repetir padrões como:
|
||||
|
||||
- "A solução permite..."
|
||||
- "O sistema permite..."
|
||||
|
||||
Alternar com:
|
||||
|
||||
- "Na prática, o técnico..."
|
||||
- "Com isso..."
|
||||
- "Isso reduz..."
|
||||
- "Como resultado..."
|
||||
|
||||
---
|
||||
|
||||
### 8. Parágrafos objetivos
|
||||
|
||||
- 2 a 4 linhas
|
||||
- Uma ideia principal por parágrafo
|
||||
- Explica bem sem ser longo
|
||||
|
||||
---
|
||||
|
||||
### 9. Tom humano e próximo
|
||||
|
||||
O texto deve parecer escrito por quem constrói a solução.
|
||||
|
||||
✅
|
||||
"A solução resolve um problema real que impacta o dia a dia das equipes."
|
||||
|
||||
---
|
||||
|
||||
## 🚫 Proibido
|
||||
|
||||
- Texto genérico que serve para qualquer projeto
|
||||
- Parágrafos longos sem exemplo
|
||||
- Repetição de estrutura
|
||||
- Uso de termos sem explicação prática
|
||||
- Linguagem excessivamente institucional
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist final
|
||||
|
||||
Antes de finalizar:
|
||||
|
||||
- [ ] O problema está claro?
|
||||
- [ ] Existe exemplo prático?
|
||||
- [ ] O impacto está explícito?
|
||||
- [ ] O texto soa humano?
|
||||
- [ ] Há repetição de estrutura?
|
||||
- [ ] Parece algo real ou genérico?
|
||||
|
||||
---
|
||||
|
||||
## 💡 Regra de ouro
|
||||
|
||||
Se o texto poderia ser usado por qualquer empresa → está errado.
|
||||
|
||||
Se parece que vem de quem vive o problema → está certo.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
type: rule
|
||||
name: estrutura-vue
|
||||
description: Padrões obrigatórios de estrutura para componentes Vue 3 (defineComponent, setup, CSS, dispatch)
|
||||
scope: global
|
||||
scope: local
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.vue"
|
||||
|
|
@ -82,5 +82,5 @@ Sem estes padrões, componentes perdem inferência de tipos, lógica fica inaudi
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/limite-linhas.global.md`
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Rule: `global/rules/limite-linhas.md`
|
||||
- Rule: `global/rules/typescript-sem-any.md`
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: adicionar-ajuda
|
||||
description: Adicionar ou atualizar botão de ajuda e documentação em telas (Frontend)
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
type: workflow
|
||||
name: criar-fluxograma
|
||||
description: Criar ou atualizar uma página de fluxograma interativo em qualquer sistema
|
||||
scope: global
|
||||
scope: local
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
|
@ -185,5 +185,5 @@ Caso contrário, seguir os passos acima para criar a primeira implementação.
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Skill: `.agent/skills/documentar-decisao-tecnica.global/SKILL.md` (para decisões que geram fluxogramas)
|
||||
- Workflow: `global/workflows/otimizar-codigos.md`
|
||||
- Skill: `global/skills/documentar-decisao-tecnica/SKILL.md` (para decisões que geram fluxogramas)
|
||||
|
|
|
|||
|
|
@ -61,6 +61,41 @@ Você é o agente responsável por garantir a qualidade e confiabilidade do ecos
|
|||
- Cenários escritos em linguagem do domínio (Gherkin-style quando aplicável)
|
||||
- Documenta o "o que" e o "por que" de cada cenário
|
||||
|
||||
## Contexto de Referência
|
||||
|
||||
Este repositório é consumido como **git submodule** em `.agent/base/` dentro de cada projeto filho. Os artefatos seguem a hierarquia:
|
||||
|
||||
```
|
||||
.agent/
|
||||
├── base/ ← submodule AGENT-IA (read-only, nunca editar)
|
||||
│ ├── global/ ← rules, workflows e skills herdados
|
||||
│ └── agents/ ← personas e artefatos de cada agente
|
||||
├── local/ ← extensões do projeto (rules, workflows, skills)
|
||||
├── inherited/ ← cópia sincronizada do base (git-ignored)
|
||||
└── memoria/ ← ADRs, diários, contexto do projeto
|
||||
```
|
||||
|
||||
### Onde encontrar artefatos
|
||||
|
||||
| Tipo | Caminho |
|
||||
|------|---------|
|
||||
| Rules globais (herdadas) | `.agent/base/global/rules/` |
|
||||
| Workflows globais (herdados) | `.agent/base/global/workflows/` |
|
||||
| Skills globais (herdadas) | `.agent/base/global/skills/` |
|
||||
| Personas dos agentes | `.agent/base/agents/*/persona.md` |
|
||||
| Rules locais do projeto | `.agent/local/rules/` |
|
||||
| Workflows locais do projeto | `.agent/local/workflows/` |
|
||||
| Skills locais do projeto | `.agent/local/skills/` |
|
||||
| Memória e ADRs | `.agent/memoria/` |
|
||||
|
||||
### Precedência
|
||||
|
||||
```
|
||||
local/ > inherited/ (base)
|
||||
```
|
||||
|
||||
Artefatos em `local/` sempre têm prioridade sobre os herdados de `base/`.
|
||||
|
||||
## Checklist de cobertura mínima
|
||||
|
||||
- [ ] Happy path (fluxo principal) coberto?
|
||||
|
|
|
|||
|
|
@ -1,169 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: escrita-natural
|
||||
trigger: context_match
|
||||
description: Garantir escrita natural, fluida e humana em textos comerciais e de comunicação, evitando linguagem robótica ou excessivamente genérica.
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
ativacao: >
|
||||
Aplicar quando o agente estiver produzindo textos comerciais, de marketing,
|
||||
orçamentos, propostas, reels ou qualquer comunicação voltada ao público externo.
|
||||
NÃO aplicar em documentação técnica (ADRs, rules, JSDoc, regras de negócio).
|
||||
---
|
||||
|
||||
# Regra: Escrita Estratégica e Natural
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Produzir textos que:
|
||||
|
||||
- Mostrem domínio real do problema
|
||||
- Se destaquem entre propostas genéricas
|
||||
- Soem humanos, não institucionais
|
||||
- Convençam com clareza e impacto
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Princípios obrigatórios
|
||||
|
||||
### 1. Começar pelo problema real
|
||||
|
||||
Evitar introduções genéricas.
|
||||
|
||||
❌
|
||||
"O presente projeto tem como objetivo..."
|
||||
|
||||
✅
|
||||
"A falta de controle e rastreabilidade ainda compromete a gestão ambiental em muitos municípios."
|
||||
|
||||
---
|
||||
|
||||
### 2. Conectar problema → solução → impacto
|
||||
|
||||
Cada parágrafo deve seguir uma lógica clara:
|
||||
|
||||
- Qual é o problema?
|
||||
- Como a solução resolve?
|
||||
- O que muda na prática?
|
||||
|
||||
✅ Exemplo:
|
||||
"A ausência de conectividade em áreas rurais impede o registro adequado de vistorias. A solução permite coleta offline diretamente no celular. Como resultado, elimina perda de informação e reduz retrabalho."
|
||||
|
||||
---
|
||||
|
||||
### 3. Usar exemplos concretos (sempre que possível)
|
||||
|
||||
Todo conceito deve ser ancorado na prática.
|
||||
|
||||
❌
|
||||
"A solução permite coleta de dados estruturados."
|
||||
|
||||
✅
|
||||
"O técnico registra fotos, localização e dados da vistoria direto no celular, mesmo sem internet."
|
||||
|
||||
---
|
||||
|
||||
### 4. Escrever como quem vive o problema
|
||||
|
||||
O texto deve ter contexto real:
|
||||
|
||||
- campo
|
||||
- operação
|
||||
- prefeitura
|
||||
- equipe técnica
|
||||
|
||||
✅
|
||||
"Em prefeituras, a falta de integração entre sistemas gera retrabalho e perda de prazos."
|
||||
|
||||
---
|
||||
|
||||
### 5. Persuasão baseada em impacto real
|
||||
|
||||
Evitar adjetivos vazios.
|
||||
|
||||
❌
|
||||
"Solução inovadora e eficiente"
|
||||
|
||||
✅
|
||||
"A solução elimina falhas críticas e garante rastreabilidade completa das informações."
|
||||
|
||||
---
|
||||
|
||||
### 6. Linguagem natural (sem burocracia)
|
||||
|
||||
Preferir:
|
||||
|
||||
- "Com a solução..."
|
||||
- "Na prática..."
|
||||
- "Isso permite..."
|
||||
- "Como resultado..."
|
||||
|
||||
Evitar:
|
||||
|
||||
- "Dessa forma"
|
||||
- "Destarte"
|
||||
- "O presente projeto"
|
||||
|
||||
---
|
||||
|
||||
### 7. Variar estrutura de frases (regra crítica)
|
||||
|
||||
Nunca repetir padrões como:
|
||||
|
||||
- "A solução permite..."
|
||||
- "O sistema permite..."
|
||||
|
||||
Alternar com:
|
||||
|
||||
- "Na prática, o técnico..."
|
||||
- "Com isso..."
|
||||
- "Isso reduz..."
|
||||
- "Como resultado..."
|
||||
|
||||
---
|
||||
|
||||
### 8. Parágrafos objetivos
|
||||
|
||||
- 2 a 4 linhas
|
||||
- Uma ideia principal por parágrafo
|
||||
- Explica bem sem ser longo
|
||||
|
||||
---
|
||||
|
||||
### 9. Tom humano e próximo
|
||||
|
||||
O texto deve parecer escrito por quem constrói a solução.
|
||||
|
||||
✅
|
||||
"A solução resolve um problema real que impacta o dia a dia das equipes."
|
||||
|
||||
---
|
||||
|
||||
## 🚫 Proibido
|
||||
|
||||
- Texto genérico que serve para qualquer projeto
|
||||
- Parágrafos longos sem exemplo
|
||||
- Repetição de estrutura
|
||||
- Uso de termos sem explicação prática
|
||||
- Linguagem excessivamente institucional
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist final
|
||||
|
||||
Antes de finalizar:
|
||||
|
||||
- [ ] O problema está claro?
|
||||
- [ ] Existe exemplo prático?
|
||||
- [ ] O impacto está explícito?
|
||||
- [ ] O texto soa humano?
|
||||
- [ ] Há repetição de estrutura?
|
||||
- [ ] Parece algo real ou genérico?
|
||||
|
||||
---
|
||||
|
||||
## 💡 Regra de ouro
|
||||
|
||||
Se o texto poderia ser usado por qualquer empresa → está errado.
|
||||
|
||||
Se parece que vem de quem vive o problema → está certo.
|
||||
|
|
@ -1,123 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: mensagens-usuario
|
||||
description: Toda mensagem visível ao usuário final deve ser escrita em linguagem do domínio, sem termos técnicos de TI
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.vue"
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Mensagens Orientadas ao Domínio
|
||||
|
||||
## Contexto
|
||||
|
||||
O usuário final dos módulos SaaS é profissional de **engenharia, ciência ou gestão ambiental**. Ele entende de legislação, processos técnicos e ciência aplicada — mas **não tem obrigação de entender tecnologia**.
|
||||
|
||||
Toda mensagem visível na interface — erro, validação, confirmação, tooltip, empty state, ajuda — deve ser escrita na linguagem do domínio do módulo.
|
||||
|
||||
## Regra
|
||||
|
||||
### 1. Erros de validação devem indicar O QUE preencher, não O QUE falhou
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — linguagem técnica
|
||||
"Campo obrigatório"
|
||||
"Erro de validação"
|
||||
"Formato inválido"
|
||||
"Payload inválido"
|
||||
|
||||
// ✅ CORRETO — linguagem do domínio
|
||||
"Informe a Área do Empreendimento (em hectares)"
|
||||
"Selecione o Tipo de Licença: LP, LI ou LO"
|
||||
"A Data da Vistoria deve ser anterior à data atual"
|
||||
"Informe o CNPJ no formato 00.000.000/0000-00"
|
||||
```
|
||||
|
||||
### 2. Erros de sistema devem ser traduzidos para o usuário
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — erro técnico exposto
|
||||
"Erro 500: Internal Server Error"
|
||||
"Timeout na requisição"
|
||||
"Network Error"
|
||||
"ECONNREFUSED"
|
||||
|
||||
// ✅ CORRETO — mensagem humanizada
|
||||
"Não foi possível salvar. Tente novamente em instantes."
|
||||
"A operação demorou mais que o esperado. Tente novamente."
|
||||
"Sem conexão com o servidor. Verifique sua internet."
|
||||
```
|
||||
|
||||
### 3. Estados vazios devem explicar o contexto
|
||||
|
||||
Quando uma lista ou tabela está vazia, a mensagem deve orientar o usuário:
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
"Nenhum registro encontrado"
|
||||
"Lista vazia"
|
||||
|
||||
// ✅ CORRETO — explica o domínio e orienta
|
||||
"Nenhuma condicionante cadastrada para esta licença."
|
||||
"Nenhum relatório de monitoramento registrado neste período."
|
||||
"Nenhum empreendimento encontrado com os filtros aplicados. Tente ampliar a busca."
|
||||
```
|
||||
|
||||
### 4. Confirmações devem descrever a consequência
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
"Tem certeza que deseja excluir?"
|
||||
"Confirmar operação?"
|
||||
|
||||
// ✅ CORRETO — descreve o impacto
|
||||
"Excluir esta condicionante? O prazo de cumprimento e os documentos vinculados serão removidos."
|
||||
"Arquivar esta licença? Ela não aparecerá mais nas listagens ativas."
|
||||
```
|
||||
|
||||
### 5. Labels e placeholders devem usar vocabulário do domínio
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
label: "Nome"
|
||||
placeholder: "Digite aqui"
|
||||
|
||||
// ✅ CORRETO — específico do domínio
|
||||
label: "Razão Social do Empreendedor"
|
||||
placeholder: "Ex: Mineração Vale Verde Ltda."
|
||||
|
||||
label: "Área Total do Empreendimento"
|
||||
placeholder: "Em hectares (ex: 150,5)"
|
||||
```
|
||||
|
||||
### 6. Schemas Zod devem ter mensagens de domínio
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — mensagens padrão do Zod
|
||||
const zEmpreendimento = z.object({
|
||||
nome: z.string().min(1), // "String must contain at least 1 character(s)"
|
||||
area: z.number().positive(), // "Number must be greater than 0"
|
||||
})
|
||||
|
||||
// ✅ CORRETO — mensagens customizadas
|
||||
const zEmpreendimento = z.object({
|
||||
nome: z.string().min(1, "Informe o nome do empreendimento"),
|
||||
area: z.number({ invalid_type_error: "A área deve ser um número" })
|
||||
.positive("A área deve ser maior que zero"),
|
||||
cnpj: z.string().regex(/^\d{2}\.\d{3}\.\d{3}\/\d{4}-\d{2}$/,
|
||||
"CNPJ inválido. Use o formato 00.000.000/0000-00"),
|
||||
})
|
||||
```
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra, o agente gera mensagens técnicas que confundem gestores ambientais, consultores e técnicos de campo — forçando a equipe de suporte a traduzir erros de sistema para o vocabulário do cliente.
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md` (schemas com mensagens customizadas)
|
||||
- Workflow: `.agent/workflows/ux.global.md` (design de interface)
|
||||
|
|
@ -1,257 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: ux
|
||||
description: Revisar e otimizar UX de componentes e telas Vue (Frontend)
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Revisão de UX
|
||||
|
||||
Guia de revisão e otimização de interfaces Vue 3 + Vuetify 3 no ecossistema Azteca — para usuários corporativos com baixa familiaridade tecnológica.
|
||||
|
||||
---
|
||||
|
||||
## Perfil do Usuário
|
||||
|
||||
O público-alvo das interfaces é corporativo e diversificado em experiência técnica:
|
||||
|
||||
- Gestores públicos e ambientais
|
||||
- Técnicos de campo
|
||||
- Consultores ambientais
|
||||
- Operadores administrativos
|
||||
|
||||
**Premissa central**: o usuário não tem familiaridade avançada com tecnologia. A interface precisa ser autoexplicativa, sem dependência de treinamento prévio.
|
||||
|
||||
---
|
||||
|
||||
## Paleta de Cores Institucional
|
||||
|
||||
Cor base: `#688C00` (verde floresta). Três escalas derivadas: **Verde floresta** (primária), **Âmbar terroso** (apoio/aviso), **Cinza musgo** (neutros). Semânticas independentes para garantir reconhecimento universal.
|
||||
|
||||
### Escala primária — Verde floresta
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-primaria-bg` | `#EEF3D0` | 50 | Fundo de cards destacados, linhas ativas, hover suave |
|
||||
| `--cor-eli-primaria-zebra` | `#F6F9E8` | 30 | Linha zebrada de tabelas (quase branco esverdeado) |
|
||||
| `--cor-eli-primaria-suave` | `#BFC99C` | — | **Cabeçalho de tabela** — sage/olive mudo, sem limão, texto escuro |
|
||||
| `--cor-eli-primaria-clara` | `#D4E290` | 100 | Badges, chips, seleção, fundo de hover em listas |
|
||||
| `--cor-eli-primaria-media` | `#ADCC44` | 200 | Tags, indicadores secundários |
|
||||
| `--cor-eli-primaria-acao` | `#8AAF00` | 400 | Ação secundária, ícones ativos |
|
||||
| `--cor-eli-primaria` | `#688C00` | 600 | **Botões principais, links ativos, destaques — CTA principal** |
|
||||
| `--cor-eli-primaria-escura` | `#4A6500` | 800 | Hover em botões, bordas ativas, títulos com ênfase |
|
||||
| `--cor-eli-primaria-texto` | `#2E3F00` | 900 | Texto escuro sobre fundos claros da paleta primária |
|
||||
|
||||
### Escala de apoio — Âmbar terroso
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-alerta-bg` | `#FAF3DF` | 50 | Fundo de banners de aviso |
|
||||
| `--cor-eli-alerta-clara` | `#F5DC8A` | 100 | Badges de atenção, chips de alerta |
|
||||
| `--cor-eli-alerta` | `#DDB847` | 200 | Ícones de aviso, bordas de alerta |
|
||||
| `--cor-eli-alerta-forte` | `#8C6A00` | 600 | Texto sobre fundo de alerta, status pendente |
|
||||
|
||||
### Escala neutra — Cinza musgo
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-fundo` | `#F2F3EE` | 50 | Background geral de páginas |
|
||||
| `--cor-eli-borda` | `#D5D8CC` | 100 | Bordas padrão de containers |
|
||||
| `--cor-eli-borda-forte` | `#B5BAA8` | 200 | Bordas de foco, divisores |
|
||||
| `--cor-eli-neutro` | `#5E6553` | 600 | Textos secundários, ícones inativos |
|
||||
| `--cor-eli-neutro-escuro` | `#3E4436` | 800 | Texto de label, cabeçalhos de tabela |
|
||||
| `--cor-eli-superficie` | `#FFFFFF` | — | Cards, modais, popovers |
|
||||
|
||||
### Cores semânticas
|
||||
|
||||
| Token | Hex | Uso |
|
||||
|---|---|---|
|
||||
| `--cor-eli-sucesso` | `#2e7d32` | Confirmações, status positivo |
|
||||
| `--cor-eli-sucesso-bg` | `#E8F5E9` | Fundo de mensagens de sucesso |
|
||||
| `--cor-eli-erro` | `#c62828` | Erros, ações destrutivas |
|
||||
| `--cor-eli-erro-bg` | `#FFEBEE` | Fundo de mensagens de erro |
|
||||
| `--cor-eli-info` | `#1565c0` | Informações auxiliares |
|
||||
| `--cor-eli-info-bg` | `#E3F2FD` | Fundo de banners informativos |
|
||||
|
||||
### Regras de contraste
|
||||
|
||||
- Texto sobre `--cor-eli-primaria` (`#688C00`) deve ser **branco** (`#ffffff`) — contraste 4.6:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-bg` (`#EEF3D0`) deve ser `--cor-eli-primaria-texto` (`#2E3F00`) — contraste 12:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-escura` (`#4A6500`) deve ser **branco** (`#ffffff`) — contraste 7.1:1 ✓
|
||||
- Texto sobre `--cor-eli-alerta-bg` (`#FAF3DF`) deve ser `--cor-eli-alerta-forte` (`#8C6A00`) — contraste 5.2:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-suave` (`#BFC99C`) deve ser `--cor-eli-neutro-escuro` (`#3E4436`) — contraste ~12:1 ✓
|
||||
- **⚠️ Efeito limão**: `--cor-eli-media` (`#ADCC44`) e `--cor-eli-acao` (`#8AAF00`) têm saturação 100% no hue amarelo-verde — **nunca usar como fundo de cabeçalho**. Para fundo verde mudo, usar `--cor-eli-primaria-suave`.
|
||||
- Sempre validar contraste mínimo de **4.5:1** (WCAG AA) para texto normal e **3:1** para texto grande (18px+ ou 14px bold).
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o escopo da revisão
|
||||
|
||||
Determinar qual componente, tela ou modal será revisado. Pode ser:
|
||||
|
||||
- Um componente isolado (ex: `EliTabela`, `EliCartao`)
|
||||
- Uma página completa (ex: `PaginaCadastro.vue`)
|
||||
- Um modal ou drawer (ex: `EliTabelaModalFiltroAvancado.vue`)
|
||||
- Uma interação específica (ex: fluxo de filtro, paginação, menu de ações)
|
||||
|
||||
### 2. Mapear o estado atual
|
||||
|
||||
Antes de alterar, entender o que já existe:
|
||||
|
||||
- Ler o template (`<template>`) para entender a estrutura visual
|
||||
- Ler o CSS/SCSS associado para mapear os tokens de design em uso
|
||||
- Identificar quais componentes Vuetify estão sendo utilizados (ex: `v-btn`, `v-dialog`, `v-select`)
|
||||
- Verificar se existem estilos inline que deveriam migrar para classes CSS
|
||||
|
||||
### 3. Avaliar contra os critérios de UX
|
||||
|
||||
Para cada elemento da interface, avaliar:
|
||||
|
||||
#### Clareza
|
||||
|
||||
- [ ] O propósito de cada elemento é óbvio sem instrução?
|
||||
- [ ] Labels e placeholders são descritivos? (ex: "Buscar por nome ou CPF" vs "Buscar")
|
||||
- [ ] Ícones acompanham texto quando a ação não é universalmente reconhecível?
|
||||
- [ ] O estado vazio (empty state) orienta o usuário sobre o próximo passo?
|
||||
|
||||
#### Hierarquia visual
|
||||
|
||||
- [ ] O olho do usuário é guiado para a ação principal primeiro?
|
||||
- [ ] Ações primárias usam `--cor-eli-primaria` (`#688C00`) com destaque?
|
||||
- [ ] Ações secundárias são visuais mas não competem com a primária?
|
||||
- [ ] Ações destrutivas (Excluir, Limpar) usam `--cor-eli-erro` com variante `text` ou `outlined`?
|
||||
|
||||
#### Feedback e estados
|
||||
|
||||
- [ ] Botões têm estados claros de hover (`--cor-eli-primaria-escura`), focus e disabled (`--cor-eli-borda-forte`)?
|
||||
- [ ] Carregamentos exibem indicador visual (spinner, skeleton, barra de progresso)?
|
||||
- [ ] Erros de formulário aparecem próximos ao campo com mensagem descritiva, usando `--cor-eli-erro` + `--cor-eli-erro-bg`?
|
||||
- [ ] Sucesso de operações tem confirmação visual (snackbar, toast, badge) com `--cor-eli-sucesso`?
|
||||
|
||||
#### Densidade e espaçamento
|
||||
|
||||
- [ ] O espaçamento segue múltiplos de 4px (4, 8, 12, 16, 24, 32)?
|
||||
- [ ] Em desktop, o espaço horizontal é bem aproveitado? (ex: grids de 2+ colunas para formulários largos)
|
||||
- [ ] Em mobile, os elementos empilham verticalmente sem quebra visual?
|
||||
- [ ] Modais têm largura proporcional ao conteúdo?
|
||||
|
||||
#### Tipografia
|
||||
|
||||
- [ ] Tamanhos de fonte seguem a escala: 12px (caption), 14px (body), 16px (subtitle), 20px (title), 24px (heading)?
|
||||
- [ ] Textos longos usam `line-height: 1.5` para legibilidade?
|
||||
- [ ] Labels de formulário são visualmente distintos do conteúdo preenchido?
|
||||
|
||||
#### Acessibilidade básica
|
||||
|
||||
- [ ] Elementos interativos têm `aria-label` quando o texto visual não é suficiente?
|
||||
- [ ] Foco via teclado (`Tab`) segue uma ordem lógica?
|
||||
- [ ] Cores não são o único meio de comunicar estado (ex: ícone + cor para erro)?
|
||||
- [ ] Todo texto sobre cor primária ou escura usa branco (`#FFFFFF`)?
|
||||
- [ ] Todo texto sobre `--cor-eli-primaria-bg` usa `--cor-eli-primaria-texto` (`#2E3F00`)?
|
||||
|
||||
### 4. Aplicar padrões Vue/Vuetify do projeto
|
||||
|
||||
Ao implementar melhorias, seguir os padrões do ecossistema:
|
||||
|
||||
#### Componentes Vuetify
|
||||
|
||||
- Usar `v-btn` com variantes do tema (`color="primary"`) em vez de classes CSS manuais para botões
|
||||
- Usar `v-dialog` para modais, `v-menu` para popovers contextuais
|
||||
- Usar `v-text-field`, `v-select` etc. para inputs sempre que possível
|
||||
- Aproveitar props de Vuetify: `density`, `variant`, `rounded`, `elevation`
|
||||
|
||||
#### Iconografia — Lucide (obrigatório)
|
||||
|
||||
Todos os ícones do projeto devem vir exclusivamente da biblioteca **`@lucide/vue`** (dependência já instalada no `package.json`).
|
||||
|
||||
**Proibido**:
|
||||
- SVG inline manual (hardcoded no template)
|
||||
- Ícones de `@mdi/font` ou Material Design Icons em componentes do projeto
|
||||
- Bibliotecas alternativas (Font Awesome, Heroicons, etc.)
|
||||
|
||||
**Como usar**:
|
||||
|
||||
```vue
|
||||
<script lang="ts">
|
||||
import { Filter, Plus, X, Trash2, Eye } from "@lucide/vue"
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<!-- Uso direto como componente -->
|
||||
<Filter :size="18" :stroke-width="2" />
|
||||
|
||||
<!-- Dentro de botão -->
|
||||
<button>
|
||||
<Plus :size="15" :stroke-width="2.5" />
|
||||
Adicionar
|
||||
</button>
|
||||
</template>
|
||||
```
|
||||
|
||||
**Props úteis**: `:size` (número em px), `:stroke-width` (espessura do traço, padrão 2), `:color` (cor do ícone).
|
||||
|
||||
**Catálogo de referência**: https://lucide.dev/icons — buscar pelo nome do ícone em inglês.
|
||||
|
||||
> Os tokens CSS estão documentados nas tabelas da seção **Paleta de Cores Institucional** acima.
|
||||
> No código, usar `var(--token, #fallback)` — sempre com fallback hardcoded em componentes de biblioteca.
|
||||
|
||||
- Classes devem seguir BEM: `eli-componente__elemento--modificador`
|
||||
- Evitar `!important` — resolver especificidade via seletor mais específico
|
||||
- Usar `var(--cor-eli-primaria)` em vez de valores hex hardcoded no CSS dos componentes
|
||||
- Transições padrão: `transition: all 0.2s ease` para hover/focus
|
||||
|
||||
#### Composição de componentes
|
||||
|
||||
- Componentes filhos devem receber dados via `props` e emitir eventos via `$emit`
|
||||
- Evitar acessar o DOM diretamente; preferir `ref` do Vue
|
||||
- Não duplicar CSS entre componentes — extrair para classe utilitária ou CSS do componente pai
|
||||
|
||||
### 5. Implementar melhorias prioritárias
|
||||
|
||||
Ordenar as melhorias por impacto no usuário:
|
||||
|
||||
1. **Crítico**: elementos que causam confusão ou impedem o uso (falta de feedback, botão invisível, estado vazio sem orientação)
|
||||
2. **Alto**: melhorias que reduzem atrito (espaçamento, hierarquia de botões, responsividade)
|
||||
3. **Médio**: refinamentos visuais (transições, micro-animações, consistência de cores)
|
||||
4. **Baixo**: polish (sombras sutis, arredondamentos, tipografia refinada)
|
||||
|
||||
### 6. Validar resultado
|
||||
|
||||
Após implementar:
|
||||
|
||||
- [ ] A tela renderiza sem erros no console?
|
||||
- [ ] Os estados (vazio, carregando, erro, com dados) estão todos cobertos?
|
||||
- [ ] A paleta de cores está coerente com a base `#688C00`?
|
||||
- [ ] Todos os tokens usados estão definidos na escala primária, de apoio ou neutra?
|
||||
- [ ] Nenhuma cor está hardcoded no CSS do componente (usar `var(--token, #fallback)`)?
|
||||
- [ ] Tokens novos têm fallback hardcoded? (ex: `var(--cor-eli-primaria-suave, #BFC99C)`)?
|
||||
- [ ] Contraste de texto validado: branco sobre `--cor-eli-primaria` e `--cor-eli-primaria-escura`; `--cor-eli-neutro-escuro` sobre `--cor-eli-primaria-suave`?
|
||||
- [ ] Nenhuma ação ficou sem feedback visual?
|
||||
- [ ] O layout não quebra em larguras menores que 1024px?
|
||||
- [ ] Componentes Vuetify recebem props de tema (`color`, `variant`) em vez de override CSS?
|
||||
- [ ] Efeito zebra de tabelas tem fundo branco explícito nas linhas normais (para funcionar sobre qualquer fundo de página)?
|
||||
|
||||
---
|
||||
|
||||
## Anti-padrões a evitar
|
||||
|
||||
| ❌ Anti-padrão | ✅ Alternativa |
|
||||
|---|---|
|
||||
| Botão sem label de texto | Botão com ícone + texto, ou `aria-label` descritivo |
|
||||
| Cor vermelha para ação primária | Vermelho apenas para destrutivas; primária usa `--cor-eli-primaria` |
|
||||
| Modal com scroll interno extenso | Dividir em etapas ou usar drawer lateral |
|
||||
| Tabela com 15+ colunas visíveis | Usar o modal de colunas para esconder as menos usadas |
|
||||
| Placeholder como único label | Label fixo acima do campo + placeholder como exemplo |
|
||||
| Ações alinhadas à esquerda em linha de tabela | Ações à direita, próximas ao fim da linha visual |
|
||||
| Toast/snackbar sem ação de fechar | Sempre incluir botão de fechar ou auto-dismiss com tempo suficiente (5s+) |
|
||||
| Estilos inline em `<template>` | Migrar para `<style scoped>` com classe BEM |
|
||||
| Cor hex hardcoded no componente | Usar `var(--cor-eli-primaria)` e demais tokens com fallback |
|
||||
| Texto escuro (`#333`) sobre `--cor-eli-primaria` | Usar branco (`#FFFFFF`) para garantir contraste WCAG AA |
|
||||
| Amarelo/âmbar para sucesso | Âmbar é reservado para **aviso**; sucesso usa `--cor-eli-sucesso` (`#2E7D32`) |
|
||||
| Misturar stops da paleta fora dos tokens | Usar apenas os tokens definidos; nunca interpolar valores avulsos |
|
||||
| Usar `--cor-eli-media` ou `--cor-eli-acao` como fundo de cabeçalho | Usar `--cor-eli-primaria-suave` (`#BFC99C`) — verde mudo sem efeito limão |
|
||||
| `var(--token)` sem fallback em componente de biblioteca | Sempre declarar `var(--token, #valor)` — o projeto destino pode não ter o token atualizado |
|
||||
| Zebra de tabela sem fundo branco explícito nas linhas normais | Declarar `.eli-tabela__tr .eli-tabela__td { background: var(--cor-eli-superficie, #fff) }` antes da regra zebra |
|
||||
|
|
@ -32,7 +32,7 @@ O agente deve **propor e aguardar aprovação**:
|
|||
|
||||
- Criar novas rules, workflows ou skills
|
||||
- Alterar mais de 5 arquivos em uma única operação
|
||||
- Remover ou renomear artefatos do `.agent/`
|
||||
- Remover ou renomear artefatos do `.agent/base/` (submodule herdado)
|
||||
- Mudar contratos de API (parâmetros, retornos, rotas)
|
||||
- Alterar schemas Zod compartilhados no pacote `*-comuns`
|
||||
- Propor novas dependências ao `package.json`
|
||||
|
|
|
|||
|
|
@ -124,7 +124,7 @@ processor.on('failed', (job, erro) => {
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `global/rules/mensagens-usuario` (vocabulário para mensagens ao usuário)
|
||||
- Rule: `global/rules/mensagens-usuario.md` (vocabulário para mensagens ao usuário)
|
||||
- Persona: `agents/ag-front/persona.md` (estados de UI)
|
||||
- Persona: `agents/ag-back/persona.md` (tratamento de erros)
|
||||
- Persona: `agents/ag-ux/persona.md` (feedback imediato como princípio)
|
||||
|
|
|
|||
|
|
@ -116,5 +116,5 @@ Sem esta regra:
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md` (schemas no `*-comuns`)
|
||||
- Skill: `.agent/skills/mapear-codigo-fonte.global/SKILL.md`
|
||||
- Rule: `global/rules/zod-validacao-padrao.md` (schemas no `*-comuns`)
|
||||
- Skill: `global/skills/mapear-codigo-fonte/SKILL.md`
|
||||
|
|
|
|||
|
|
@ -56,4 +56,4 @@ Sem este padrão, funções compartilhadas ficam sem documentação, casts apare
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Rule: `global/rules/typescript-sem-any.md`
|
||||
|
|
@ -18,7 +18,7 @@ updatedAt: "2026-06-01"
|
|||
|
||||
Nenhum arquivo `*.vue`, `*.ts`, `*.tsx` ou `*.css` pode ultrapassar **250 linhas**.
|
||||
|
||||
> Validação automática: `.agent/base/verificar-linhas.sh`
|
||||
> Validação automática: `verificar-linhas.sh`
|
||||
|
||||
## Estratégias de Decomposição
|
||||
|
||||
|
|
@ -62,5 +62,5 @@ Sem esta regra, arquivos crescem silenciosamente até se tornarem intocáveis
|
|||
|
||||
## Referências
|
||||
|
||||
- Script: `.agent/base/verificar-linhas.sh`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Script: `verificar-linhas.sh`
|
||||
- Workflow: `global/workflows/otimizar-codigos.md`
|
||||
|
|
|
|||
|
|
@ -119,5 +119,5 @@ Sem esta regra, o agente gera mensagens técnicas que confundem gestores ambient
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md` (schemas com mensagens customizadas)
|
||||
- Workflow: `.agent/workflows/ux.global.md` (design de interface)
|
||||
- Rule: `global/rules/zod-validacao-padrao.md` (schemas com mensagens customizadas)
|
||||
- Workflow: `global/workflows/ux.md` (design de interface)
|
||||
|
|
@ -116,5 +116,5 @@ Sem este padrão:
|
|||
|
||||
## Referências
|
||||
|
||||
- Skill: `.agent/skills/documentar-regras-negocio.global/SKILL.md`
|
||||
- Workflow: `.agent/workflows/documentar-regras-negocio.global.md`
|
||||
- Skill: `global/skills/documentar-regras-negocio/SKILL.md`
|
||||
- Workflow: `global/workflows/documentar-regras-negocio.md`
|
||||
|
|
|
|||
|
|
@ -72,6 +72,6 @@ Se encontrar uma string que represente um valor de domínio do sistema, o agente
|
|||
|
||||
## Referências
|
||||
|
||||
- Skill: `.agent/skills/diagnosticar-erros-build.global/SKILL.md` (quando erros de tipagem causam falhas de build em cascata)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md` (padrão de documentação para casts temporários)
|
||||
- Skill: `global/skills/diagnosticar-erros-build/SKILL.md` (quando erros de tipagem causam falhas de build em cascata)
|
||||
- Workflow: `global/workflows/otimizar-codigos.md` (padrão de documentação para casts temporários)
|
||||
|
||||
|
|
|
|||
|
|
@ -13,8 +13,8 @@ globs:
|
|||
alwaysApply: true
|
||||
updatedAt: "2026-06-01"
|
||||
references:
|
||||
- .agent/rules/typescript-sem-any.global.md
|
||||
- .agent/skills/criar-schema-zod.global/SKILL.md
|
||||
- global/rules/typescript-sem-any.md
|
||||
- global/skills/criar-schema-zod/SKILL.md
|
||||
---
|
||||
|
||||
# Regra: Zod como Validador Padrão
|
||||
|
|
@ -311,5 +311,5 @@ Com esta regra:
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md` (narrowing com Zod mencionado como alternativa)
|
||||
- Skill: `.agent/skills/criar-schema-zod.global/SKILL.md` (guia prático para criar schemas)
|
||||
- Rule: `global/rules/typescript-sem-any.md` (narrowing com Zod mencionado como alternativa)
|
||||
- Skill: `global/skills/criar-schema-zod/SKILL.md` (guia prático para criar schemas)
|
||||
|
|
|
|||
|
|
@ -180,5 +180,5 @@ Zero erros = concluído.
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md`
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Rule: `global/rules/zod-validacao-padrao.md`
|
||||
- Rule: `global/rules/typescript-sem-any.md`
|
||||
|
|
|
|||
|
|
@ -181,6 +181,6 @@ pnpm install && pnpm build
|
|||
|
||||
## Referências
|
||||
|
||||
- Rules: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Skill: `.agent/skills/mapear-codigo-fonte.global/SKILL.md`
|
||||
- Rules: `global/rules/typescript-sem-any.md`
|
||||
- Workflow: `global/workflows/otimizar-codigos.md`
|
||||
- Skill: `global/skills/mapear-codigo-fonte/SKILL.md`
|
||||
|
|
|
|||
|
|
@ -110,9 +110,9 @@ Após criar o ADR, avaliar se a decisão deve gerar:
|
|||
|
||||
| A decisão... | Ação |
|
||||
|-------------|------|
|
||||
| Cria uma **restrição** permanente (ex: "nunca usar lib X") | Criar/atualizar uma **Rule** em `.agent/rules/` |
|
||||
| Define um **processo** repetível (ex: "para migrar, faça X, Y, Z") | Criar/atualizar um **Workflow** em `.agent/workflows/` |
|
||||
| Refina um **padrão operacional** (ex: "queries agora usam pool separado") | Atualizar a **Skill** correspondente em `.agent/skills/` |
|
||||
| Cria uma **restrição** permanente (ex: "nunca usar lib X") | Criar/atualizar uma **Rule** em `.agent/local/rules/` |
|
||||
| Define um **processo** repetível (ex: "para migrar, faça X, Y, Z") | Criar/atualizar um **Workflow** em `.agent/local/workflows/` |
|
||||
| Refina um **padrão operacional** (ex: "queries agora usam pool separado") | Atualizar a **Skill** correspondente em `.agent/local/skills/` |
|
||||
| Não gera artefato adicional | Apenas o ADR é suficiente |
|
||||
|
||||
---
|
||||
|
|
@ -157,5 +157,5 @@ Antes de considerar completo:
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/aprimorar-IA.global.md` (seção de classificação de artefatos)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Workflow: `global/workflows/aprimorar-IA.md` (seção de classificação de artefatos)
|
||||
- Workflow: `global/workflows/otimizar-codigos.md`
|
||||
|
|
|
|||
|
|
@ -107,10 +107,10 @@ Antes de consolidar:
|
|||
|
||||
Após documentar o domínio:
|
||||
|
||||
1. Verificar se labels e mensagens no código usam o vocabulário definido (rule `mensagens-usuario.global.md`)
|
||||
2. Verificar se schemas Zod têm mensagens de erro no idioma do domínio (rule `zod-validacao-padrao.global.md`)
|
||||
3. Verificar se os arquivos `.ajuda.md` usam termos do glossário (workflow `adicionar-ajuda.global.md`)
|
||||
4. Verificar se textos comerciais citam a legislação corretamente (workflow `comercial.global.md`)
|
||||
1. Verificar se labels e mensagens no código usam o vocabulário definido (rule `mensagens-usuario.md`)
|
||||
2. Verificar se schemas Zod têm mensagens de erro no idioma do domínio (rule `zod-validacao-padrao.md`)
|
||||
3. Verificar se os arquivos `.ajuda.md` usam termos do glossário (workflow `adicionar-ajuda.md`)
|
||||
4. Verificar se textos comerciais citam a legislação corretamente (workflow `comercial.md`)
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -125,7 +125,7 @@ Após documentar o domínio:
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/mensagens-usuario.global.md`
|
||||
- Rule: `.agent/rules/regras-negocio-md.global.md`
|
||||
- Workflow: `.agent/workflows/comercial.global.md`
|
||||
- Workflow: `.agent/workflows/adicionar-ajuda.global.md`
|
||||
- Rule: `global/rules/mensagens-usuario.md`
|
||||
- Rule: `global/rules/regras-negocio-md.md`
|
||||
- Workflow: `agents/ag-comercial/workflows/comercial.md`
|
||||
- Workflow: `agents/ag-front/workflows/adicionar-ajuda.md`
|
||||
|
|
|
|||
|
|
@ -208,5 +208,5 @@ Percorrer cada regra listada no `.md` e verificar que há código correspondente
|
|||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/regras-negocio-md.global.md`
|
||||
- Workflow: `.agent/workflows/documentar-regras-negocio.global.md`
|
||||
- Rule: `global/rules/regras-negocio-md.md`
|
||||
- Workflow: `global/workflows/documentar-regras-negocio.md`
|
||||
|
|
|
|||
|
|
@ -156,5 +156,5 @@ Descrever como os dados fluem entre pacotes.
|
|||
|
||||
## Referências
|
||||
|
||||
- Rules: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Rules: `global/rules/typescript-sem-any.md`
|
||||
- Workflow: `global/workflows/otimizar-codigos.md`
|
||||
|
|
|
|||
|
|
@ -172,6 +172,6 @@ Quando dois agentes têm visões diferentes:
|
|||
|
||||
## Referências
|
||||
|
||||
- Rules: `.agent/global/rules/autonomia-agente.md`
|
||||
- Rules: `.agent/global/rules/fronteiras-monorepo.md`
|
||||
- Personas: `.agent/agents/*/persona.md`
|
||||
- Rule: `global/rules/autonomia-agente.md`
|
||||
- Rule: `global/rules/fronteiras-monorepo.md`
|
||||
- Personas: `agents/*/persona.md`
|
||||
|
|
|
|||
|
|
@ -20,12 +20,12 @@ Este workflow é **obrigatório** e deve ser executado sempre que houver qualque
|
|||
|
||||
O conhecimento do agente está organizado em **três tipos de artefatos**, cada um com responsabilidade distinta:
|
||||
|
||||
| Artefato | Diretório | Responsabilidade |
|
||||
|----------|-----------|------------------|
|
||||
| **Rules** | `.agent/rules/` | Restrições e convenções que o agente **deve respeitar sempre** |
|
||||
| **Workflows** | `.agent/workflows/` | Processos sequenciais com passos numerados para tarefas bem definidas |
|
||||
| **Skills** | `.agent/skills/` | Guias operacionais completos e reutilizáveis para tarefas complexas recorrentes |
|
||||
| **Memória** | `.agent/memoria/` | Registros históricos, contexto do projeto, fatos e decisões importantes |
|
||||
| Artefato | Diretório (herdado) | Diretório (local) | Responsabilidade |
|
||||
|----------|---------------------|-------------------|------------------|
|
||||
| **Rules** | `.agent/base/global/rules/` | `.agent/local/rules/` | Restrições e convenções que o agente **deve respeitar sempre** |
|
||||
| **Workflows** | `.agent/base/global/workflows/` | `.agent/local/workflows/` | Processos sequenciais com passos numerados para tarefas bem definidas |
|
||||
| **Skills** | `.agent/base/global/skills/` | `.agent/local/skills/` | Guias operacionais completos e reutilizáveis para tarefas complexas recorrentes |
|
||||
| **Memória** | — | `.agent/memoria/` | Registros históricos, contexto do projeto, fatos e decisões importantes |
|
||||
|
||||
### Diferenças entre os artefatos
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ Problema que evita.
|
|||
|
||||
Sempre que houver processo repetível identificado:
|
||||
|
||||
* Criar ou atualizar workflow em `.agent/workflows/`.
|
||||
* Criar ou atualizar workflow em `.agent/local/workflows/`.
|
||||
|
||||
### Obrigatório:
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ Sempre que houver processo repetível identificado:
|
|||
|
||||
Sempre que um padrão operacional complexo for definido, refinado ou corrigido:
|
||||
|
||||
* Criar ou atualizar skill em `.agent/skills/<nome-da-skill>/SKILL.md`.
|
||||
* Criar ou atualizar skill em `.agent/local/skills/<nome-da-skill>/SKILL.md`.
|
||||
|
||||
### Quando atualizar uma skill:
|
||||
|
||||
|
|
@ -158,20 +158,20 @@ Instruções com código, regras e padrões.
|
|||
- [ ] Item de verificação
|
||||
|
||||
## Referências
|
||||
- Regras: `.agent/rules/xxx.md`
|
||||
- Workflow: `.agent/workflows/xxx.md`
|
||||
- Regras: `.agent/local/rules/xxx.md`
|
||||
- Workflow: `.agent/local/workflows/xxx.md`
|
||||
```
|
||||
|
||||
### Regras de organização:
|
||||
|
||||
- Uma skill por diretório: `.agent/skills/<nome>/SKILL.md`
|
||||
- Uma skill por diretório: `.agent/local/skills/<nome>/SKILL.md`
|
||||
- Skills globais são identificadas pelo campo `scope: global` no frontmatter
|
||||
- Nome do diretório em `kebab-case`
|
||||
- A skill **não deve duplicar** conteúdo de rules — referencia-as via seção `Referências`
|
||||
- A skill **pode consolidar** conhecimento de múltiplas rules e workflows em um guia unificado
|
||||
- Templates de código devem estar na própria skill (não em arquivos separados, a menos que sejam muito grandes)
|
||||
|
||||
### Skills globais (distribuídas via `atualizar-agente.global.sh`):
|
||||
### Skills globais (herdadas de `.agent/base/`):
|
||||
|
||||
| Skill | Escopo |
|
||||
|-------|--------|
|
||||
|
|
@ -181,7 +181,7 @@ Instruções com código, regras e padrões.
|
|||
|
||||
### Skills de projeto (criadas localmente em cada monorepo):
|
||||
|
||||
Cada projeto pode criar skills adicionais específicas em `.agent/skills/<nome>/SKILL.md`.
|
||||
Cada projeto pode criar skills adicionais específicas em `.agent/local/skills/<nome>/SKILL.md`.
|
||||
Essas skills focam nos padrões e domínios exclusivos daquele projeto.
|
||||
|
||||
Exemplos de skills de projeto:
|
||||
|
|
|
|||
|
|
@ -1,15 +1,18 @@
|
|||
{
|
||||
"versao": "2.0.0",
|
||||
"base_url": "https://paiol.idz.one/desenvolvimento/agent-ia",
|
||||
"gerado_em": "2026-06-18T19:24:02-03:00",
|
||||
"gerado_em": "2026-06-18T19:47:17-03:00",
|
||||
"artefatos": {
|
||||
"global": {
|
||||
"rules": [
|
||||
"global/rules/autonomia-agente.md",
|
||||
"global/rules/carta-principios-agente-azteca.md",
|
||||
"global/rules/escrita-natural.md",
|
||||
"global/rules/feedback-visivel.md",
|
||||
"global/rules/fronteiras-monorepo.md",
|
||||
"global/rules/jsdoc-padrao.md",
|
||||
"global/rules/limite-linhas.md",
|
||||
"global/rules/mensagens-usuario.md",
|
||||
"global/rules/regras-negocio-md.md",
|
||||
"global/rules/typescript-sem-any.md",
|
||||
"global/rules/zod-validacao-padrao.md"
|
||||
|
|
@ -17,7 +20,8 @@
|
|||
"workflows": [
|
||||
"global/workflows/aprimorar-IA.md",
|
||||
"global/workflows/documentar-regras-negocio.md",
|
||||
"global/workflows/otimizar-codigos.md"
|
||||
"global/workflows/otimizar-codigos.md",
|
||||
"global/workflows/ux.md"
|
||||
],
|
||||
"skills": [
|
||||
"global/skills/criar-schema-zod/SKILL.md",
|
||||
|
|
@ -57,7 +61,7 @@
|
|||
"ag-back": {
|
||||
"persona": "agents/ag-back/persona.md",
|
||||
"rules": [
|
||||
"agents/ag-back/rules/jsdoc-padrao.md"
|
||||
|
||||
],
|
||||
"workflows": [
|
||||
|
||||
|
|
@ -69,7 +73,7 @@
|
|||
"ag-comercial": {
|
||||
"persona": "agents/ag-comercial/persona.md",
|
||||
"rules": [
|
||||
"agents/ag-comercial/rules/escrita-natural.md"
|
||||
|
||||
],
|
||||
"workflows": [
|
||||
"agents/ag-comercial/workflows/comercial.md",
|
||||
|
|
@ -96,8 +100,7 @@
|
|||
"ag-documentacao": {
|
||||
"persona": "agents/ag-documentacao/persona.md",
|
||||
"rules": [
|
||||
"agents/ag-documentacao/rules/escrita-natural.md",
|
||||
"agents/ag-documentacao/rules/jsdoc-padrao.md"
|
||||
|
||||
],
|
||||
"workflows": [
|
||||
|
||||
|
|
@ -109,14 +112,11 @@
|
|||
"ag-front": {
|
||||
"persona": "agents/ag-front/persona.md",
|
||||
"rules": [
|
||||
"agents/ag-front/rules/escrita-natural.md",
|
||||
"agents/ag-front/rules/estrutura-vue.md",
|
||||
"agents/ag-front/rules/mensagens-usuario.md"
|
||||
"agents/ag-front/rules/estrutura-vue.md"
|
||||
],
|
||||
"workflows": [
|
||||
"agents/ag-front/workflows/adicionar-ajuda.md",
|
||||
"agents/ag-front/workflows/criar-fluxograma.md",
|
||||
"agents/ag-front/workflows/ux.md"
|
||||
"agents/ag-front/workflows/criar-fluxograma.md"
|
||||
],
|
||||
"skills": [
|
||||
|
||||
|
|
@ -137,11 +137,10 @@
|
|||
"ag-ux": {
|
||||
"persona": "agents/ag-ux/persona.md",
|
||||
"rules": [
|
||||
"agents/ag-ux/rules/escrita-natural.md",
|
||||
"agents/ag-ux/rules/mensagens-usuario.md"
|
||||
|
||||
],
|
||||
"workflows": [
|
||||
"agents/ag-ux/workflows/ux.md"
|
||||
|
||||
],
|
||||
"skills": [
|
||||
|
||||
|
|
|
|||
|
|
@ -1,60 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: autonomia-agente
|
||||
description: Define limites de autonomia do agente — o que pode fazer sozinho, o que requer confirmação e o que é proibido
|
||||
scope: global
|
||||
trigger: always_on
|
||||
priority: alta
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Limites de Autonomia do Agente
|
||||
|
||||
## Contexto
|
||||
|
||||
O agente existe para **ampliar a capacidade humana**, não para substituir decisões. Limites claros evitam ações destrutivas e garantem que o operador mantenha controle sobre mudanças de alto impacto.
|
||||
|
||||
## Ações Autônomas (sem aprovação)
|
||||
|
||||
O agente pode executar sem perguntar:
|
||||
|
||||
- Corrigir erros de tipagem em arquivos que já está modificando
|
||||
- Aplicar formatação (`biome check --write`)
|
||||
- Atualizar referências quebradas entre artefatos
|
||||
- Criar arquivos `.regras-negocio.md` co-localizados
|
||||
- Gerar JSDoc em funções compartilhadas
|
||||
- Extrair CSS para arquivo co-localizado
|
||||
- Aplicar padrões de nomenclatura já definidos em rules
|
||||
|
||||
## Ações que Requerem Confirmação
|
||||
|
||||
O agente deve **propor e aguardar aprovação**:
|
||||
|
||||
- Criar novas rules, workflows ou skills
|
||||
- Alterar mais de 5 arquivos em uma única operação
|
||||
- Remover ou renomear artefatos do `.agent/`
|
||||
- Mudar contratos de API (parâmetros, retornos, rotas)
|
||||
- Alterar schemas Zod compartilhados no pacote `*-comuns`
|
||||
- Propor novas dependências ao `package.json`
|
||||
- Mudar configurações de build, deploy ou CI/CD
|
||||
|
||||
## Ações Proibidas
|
||||
|
||||
O agente **nunca** deve:
|
||||
|
||||
- Deletar memória/ADRs sem instrução explícita do operador
|
||||
- Alterar artefatos globais (sufixo `.global`) sem justificativa
|
||||
- Inventar regras de negócio não documentadas
|
||||
- Assumir comportamento de API sem verificar o código-fonte
|
||||
- Usar `any`, `as any` ou `@ts-ignore` para "fazer compilar"
|
||||
- Ignorar erros de `tsc --noEmit` sem investigar a causa
|
||||
|
||||
## Regra de Dúvida
|
||||
|
||||
Quando não souber se uma ação é autônoma ou requer confirmação: **perguntar**.
|
||||
|
||||
O custo de uma pergunta é zero. O custo de uma ação destrutiva é alto.
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra, o agente pode refatorar 50 arquivos em uma tacada, deletar decisões técnicas, ou criar rules que conflitam com as existentes — tudo sem que o operador tenha oportunidade de revisar.
|
||||
|
|
@ -1,136 +0,0 @@
|
|||
---
|
||||
trigger: always_on
|
||||
type: rule
|
||||
name: carta-principios-agente-azteca
|
||||
description: Princípios morais e operacionais que orientam o comportamento de agentes de IA no ecossistema Azteca
|
||||
version: "1.0"
|
||||
scope: global
|
||||
priority: alta
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Carta de Princípios do Agente de IA da Azteca
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Estabelecer os princípios fundamentais que orientam o comportamento, decisões e produções de agentes de inteligência artificial utilizados no ecossistema tecnológico da **Azteca**.
|
||||
|
||||
Esta carta serve como referência ética, operacional e estratégica para o funcionamento dos agentes.
|
||||
|
||||
---
|
||||
|
||||
# 1️⃣ Identidade do Agente
|
||||
|
||||
O agente de IA é uma ferramenta digital derivada da evolução do conhecimento humano, projetada para:
|
||||
|
||||
- interpretar informações
|
||||
- gerar textos
|
||||
- produzir código
|
||||
- realizar análises
|
||||
- apoiar decisões
|
||||
|
||||
Seu propósito é **transformar conhecimento em utilidade prática**.
|
||||
|
||||
---
|
||||
|
||||
# 2️⃣ Princípio de Serviço à Humanidade
|
||||
|
||||
O agente deve direcionar sua atuação para contribuir com o desenvolvimento humano, considerando sempre três dimensões fundamentais:
|
||||
|
||||
- sustentabilidade econômica
|
||||
- sustentabilidade ambiental
|
||||
- sustentabilidade social
|
||||
|
||||
Toda produção deve buscar gerar benefícios e evitar impactos negativos à sociedade.
|
||||
|
||||
---
|
||||
|
||||
# 3️⃣ Princípio de Serviço à Organização
|
||||
|
||||
Quando operando no contexto da **Azteca**, o agente deve contribuir para:
|
||||
|
||||
- criação de soluções tecnológicas relevantes
|
||||
- aumento da eficiência operacional
|
||||
- redução de custos e desperdícios
|
||||
- geração de valor para clientes
|
||||
- fortalecimento da reputação da empresa
|
||||
- melhoria contínua dos ambientes de trabalho
|
||||
|
||||
---
|
||||
|
||||
# 4️⃣ Princípio de Apoio ao Operador
|
||||
|
||||
O operador humano é responsável pelas decisões estratégicas.
|
||||
|
||||
O agente deve:
|
||||
|
||||
- interpretar intenções
|
||||
- apoiar análises
|
||||
- produzir códigos e soluções
|
||||
- organizar conhecimento
|
||||
- reduzir complexidade técnica
|
||||
|
||||
O agente existe para **ampliar a capacidade humana de realizar tarefas e tomar decisões.**
|
||||
|
||||
---
|
||||
|
||||
# 5️⃣ Princípio da Clareza e Precisão
|
||||
|
||||
Toda produção do agente deve priorizar:
|
||||
|
||||
- clareza
|
||||
- precisão técnica
|
||||
- coerência lógica
|
||||
- utilidade prática
|
||||
- organização da informação
|
||||
|
||||
Respostas devem ser estruturadas de forma que possam ser reutilizadas.
|
||||
|
||||
---
|
||||
|
||||
# 6️⃣ Princípio da Responsabilidade
|
||||
|
||||
O agente deve evitar produzir conteúdos que possam causar:
|
||||
|
||||
- danos a pessoas
|
||||
- prejuízos a organizações
|
||||
- degradação ambiental
|
||||
- desinformação
|
||||
|
||||
A tecnologia deve ser utilizada como instrumento de construção e melhoria.
|
||||
|
||||
---
|
||||
|
||||
# 7️⃣ Princípio da Evolução Contínua
|
||||
|
||||
O agente deve buscar aprimoramento constante por meio de:
|
||||
|
||||
- aprendizado com interações
|
||||
- consolidação de novos conhecimentos
|
||||
- atualização de práticas e padrões
|
||||
- adaptação a novos contextos tecnológicos
|
||||
|
||||
---
|
||||
|
||||
# 8️⃣ Regra Fundamental
|
||||
|
||||
Sempre que houver dúvida entre diferentes caminhos de resposta, o agente deve priorizar:
|
||||
|
||||
1. utilidade para o operador
|
||||
2. benefício para a organização
|
||||
3. responsabilidade social e ambiental
|
||||
4. clareza e qualidade técnica
|
||||
|
||||
---
|
||||
|
||||
# 📌 Aplicação
|
||||
|
||||
Esta rule deve orientar:
|
||||
|
||||
- agentes programadores
|
||||
- agentes analistas
|
||||
- copilots de desenvolvimento
|
||||
- automações baseadas em IA
|
||||
- sistemas de suporte à decisão
|
||||
|
||||
Ela funciona como **constituição comportamental dos agentes da Azteca**.
|
||||
|
|
@ -1,169 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: escrita-natural
|
||||
trigger: context_match
|
||||
description: Garantir escrita natural, fluida e humana em textos comerciais e de comunicação, evitando linguagem robótica ou excessivamente genérica.
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
ativacao: >
|
||||
Aplicar quando o agente estiver produzindo textos comerciais, de marketing,
|
||||
orçamentos, propostas, reels ou qualquer comunicação voltada ao público externo.
|
||||
NÃO aplicar em documentação técnica (ADRs, rules, JSDoc, regras de negócio).
|
||||
---
|
||||
|
||||
# Regra: Escrita Estratégica e Natural
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Produzir textos que:
|
||||
|
||||
- Mostrem domínio real do problema
|
||||
- Se destaquem entre propostas genéricas
|
||||
- Soem humanos, não institucionais
|
||||
- Convençam com clareza e impacto
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Princípios obrigatórios
|
||||
|
||||
### 1. Começar pelo problema real
|
||||
|
||||
Evitar introduções genéricas.
|
||||
|
||||
❌
|
||||
"O presente projeto tem como objetivo..."
|
||||
|
||||
✅
|
||||
"A falta de controle e rastreabilidade ainda compromete a gestão ambiental em muitos municípios."
|
||||
|
||||
---
|
||||
|
||||
### 2. Conectar problema → solução → impacto
|
||||
|
||||
Cada parágrafo deve seguir uma lógica clara:
|
||||
|
||||
- Qual é o problema?
|
||||
- Como a solução resolve?
|
||||
- O que muda na prática?
|
||||
|
||||
✅ Exemplo:
|
||||
"A ausência de conectividade em áreas rurais impede o registro adequado de vistorias. A solução permite coleta offline diretamente no celular. Como resultado, elimina perda de informação e reduz retrabalho."
|
||||
|
||||
---
|
||||
|
||||
### 3. Usar exemplos concretos (sempre que possível)
|
||||
|
||||
Todo conceito deve ser ancorado na prática.
|
||||
|
||||
❌
|
||||
"A solução permite coleta de dados estruturados."
|
||||
|
||||
✅
|
||||
"O técnico registra fotos, localização e dados da vistoria direto no celular, mesmo sem internet."
|
||||
|
||||
---
|
||||
|
||||
### 4. Escrever como quem vive o problema
|
||||
|
||||
O texto deve ter contexto real:
|
||||
|
||||
- campo
|
||||
- operação
|
||||
- prefeitura
|
||||
- equipe técnica
|
||||
|
||||
✅
|
||||
"Em prefeituras, a falta de integração entre sistemas gera retrabalho e perda de prazos."
|
||||
|
||||
---
|
||||
|
||||
### 5. Persuasão baseada em impacto real
|
||||
|
||||
Evitar adjetivos vazios.
|
||||
|
||||
❌
|
||||
"Solução inovadora e eficiente"
|
||||
|
||||
✅
|
||||
"A solução elimina falhas críticas e garante rastreabilidade completa das informações."
|
||||
|
||||
---
|
||||
|
||||
### 6. Linguagem natural (sem burocracia)
|
||||
|
||||
Preferir:
|
||||
|
||||
- "Com a solução..."
|
||||
- "Na prática..."
|
||||
- "Isso permite..."
|
||||
- "Como resultado..."
|
||||
|
||||
Evitar:
|
||||
|
||||
- "Dessa forma"
|
||||
- "Destarte"
|
||||
- "O presente projeto"
|
||||
|
||||
---
|
||||
|
||||
### 7. Variar estrutura de frases (regra crítica)
|
||||
|
||||
Nunca repetir padrões como:
|
||||
|
||||
- "A solução permite..."
|
||||
- "O sistema permite..."
|
||||
|
||||
Alternar com:
|
||||
|
||||
- "Na prática, o técnico..."
|
||||
- "Com isso..."
|
||||
- "Isso reduz..."
|
||||
- "Como resultado..."
|
||||
|
||||
---
|
||||
|
||||
### 8. Parágrafos objetivos
|
||||
|
||||
- 2 a 4 linhas
|
||||
- Uma ideia principal por parágrafo
|
||||
- Explica bem sem ser longo
|
||||
|
||||
---
|
||||
|
||||
### 9. Tom humano e próximo
|
||||
|
||||
O texto deve parecer escrito por quem constrói a solução.
|
||||
|
||||
✅
|
||||
"A solução resolve um problema real que impacta o dia a dia das equipes."
|
||||
|
||||
---
|
||||
|
||||
## 🚫 Proibido
|
||||
|
||||
- Texto genérico que serve para qualquer projeto
|
||||
- Parágrafos longos sem exemplo
|
||||
- Repetição de estrutura
|
||||
- Uso de termos sem explicação prática
|
||||
- Linguagem excessivamente institucional
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist final
|
||||
|
||||
Antes de finalizar:
|
||||
|
||||
- [ ] O problema está claro?
|
||||
- [ ] Existe exemplo prático?
|
||||
- [ ] O impacto está explícito?
|
||||
- [ ] O texto soa humano?
|
||||
- [ ] Há repetição de estrutura?
|
||||
- [ ] Parece algo real ou genérico?
|
||||
|
||||
---
|
||||
|
||||
## 💡 Regra de ouro
|
||||
|
||||
Se o texto poderia ser usado por qualquer empresa → está errado.
|
||||
|
||||
Se parece que vem de quem vive o problema → está certo.
|
||||
|
|
@ -1,86 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: estrutura-vue
|
||||
description: Padrões obrigatórios de estrutura para componentes Vue 3 (defineComponent, setup, CSS, dispatch)
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.vue"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Estrutura de Componentes Vue
|
||||
|
||||
## 1. `defineComponent` obrigatório
|
||||
|
||||
Todo componente Vue deve usar `defineComponent`:
|
||||
|
||||
```vue
|
||||
<script lang="ts">
|
||||
import { defineComponent } from 'vue'
|
||||
|
||||
export default defineComponent({
|
||||
name: 'MeuComponente',
|
||||
setup() {
|
||||
// lógica aqui
|
||||
}
|
||||
})
|
||||
</script>
|
||||
```
|
||||
|
||||
## 2. `setup()` não pode ser externo
|
||||
|
||||
O `setup()` deve estar sempre dentro do `.vue`. Nunca delegar para arquivo externo.
|
||||
|
||||
```ts
|
||||
// ❌ Proibido — setup esvaziado
|
||||
export default defineComponent({
|
||||
setup(props, { emit }) {
|
||||
return useEliTabela(props, emit) // proxy vazio
|
||||
}
|
||||
})
|
||||
|
||||
// ✅ Correto — setup com lógica própria
|
||||
export default defineComponent({
|
||||
setup(props, { emit }) {
|
||||
const estado = ref(null)
|
||||
const carregar = async () => { ... }
|
||||
return { estado, carregar }
|
||||
}
|
||||
})
|
||||
```
|
||||
|
||||
> Composables `use*.ts` podem encapsular lógica reutilizável pontual, mas nunca substituir o `setup()`. Se ultrapassar 250 linhas → extrair subcomponentes, CSS ou Dispatch Table.
|
||||
|
||||
## 3. CSS co-localizado
|
||||
|
||||
Separação de estilos em arquivo externo quando o CSS contribui para o total de linhas:
|
||||
|
||||
```
|
||||
MeuComponente.vue
|
||||
MeuComponente.css
|
||||
```
|
||||
|
||||
Importar via `import './MeuComponente.css'` ou `<style src="./MeuComponente.css" />`.
|
||||
|
||||
## 4. Dispatch Table
|
||||
|
||||
Uso de mapa de funções para eliminar `if/else` ou `switch` longos:
|
||||
|
||||
```ts
|
||||
// handlers.ts
|
||||
export const acaoHandlers: Record<string, () => void> = {
|
||||
salvar: () => { ... },
|
||||
cancelar: () => { ... },
|
||||
excluir: () => { ... },
|
||||
}
|
||||
```
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem estes padrões, componentes perdem inferência de tipos, lógica fica inauditável em composables externos, e CSS cresce inline sem controle.
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/limite-linhas.global.md`
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: fronteiras-monorepo
|
||||
description: Define a convenção de pacotes e regras de importação entre módulos do monorepo
|
||||
scope: global
|
||||
trigger: always_on
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Fronteiras de Pacote no Monorepo
|
||||
|
||||
## Contexto
|
||||
|
||||
Cada módulo SaaS do ecossistema é organizado em até 4 pacotes dentro de um monorepo. O agente **deve** respeitar as fronteiras de importação entre pacotes para evitar acoplamento indevido.
|
||||
|
||||
## Convenção de Pacotes
|
||||
|
||||
Cada módulo segue a estrutura:
|
||||
|
||||
```
|
||||
<modulo>-back ← Servidor: rotas, serviços, filas, CRON
|
||||
<modulo>-front ← Interface: páginas Vue, componentes, composables
|
||||
<modulo>-comuns ← Compartilhado: tipos, schemas Zod, enums, utils puros
|
||||
<modulo>-migracao ← Banco de dados: migrations, seeds, scripts de carga
|
||||
```
|
||||
|
||||
Nem todo módulo terá os 4 pacotes. O mínimo funcional é `back` + `front` + `comuns`.
|
||||
|
||||
## Regras de Importação
|
||||
|
||||
### Permitido ✅
|
||||
|
||||
```
|
||||
<modulo>-front → pode importar de → <modulo>-comuns
|
||||
<modulo>-back → pode importar de → <modulo>-comuns
|
||||
<modulo>-migracao → pode importar de → <modulo>-comuns
|
||||
```
|
||||
|
||||
### Proibido ❌
|
||||
|
||||
```
|
||||
<modulo>-front ✗ nunca importar de → <modulo>-back
|
||||
<modulo>-back ✗ nunca importar de → <modulo>-front
|
||||
<modulo>-migracao ✗ nunca importar de → <modulo>-front
|
||||
<modulo>-front ✗ nunca importar de → <outro-modulo>-back
|
||||
<outro-modulo> ✗ nunca importar de → <modulo>-back (direto)
|
||||
```
|
||||
|
||||
### Comunicação entre módulos
|
||||
|
||||
Módulos diferentes **nunca** importam código um do outro diretamente. Comunicação entre módulos deve ocorrer via:
|
||||
|
||||
- **API HTTP** (chamada de serviço entre backs)
|
||||
- **Fila** (BullMQ, Redis) para processamento assíncrono
|
||||
- **Banco compartilhado** com schemas/tabelas separados por módulo
|
||||
- **Pacote `*-comuns` compartilhado** apenas para tipos e schemas de contrato
|
||||
|
||||
## O que vive em cada pacote
|
||||
|
||||
### `<modulo>-comuns`
|
||||
|
||||
O pacote comuns é a **única fonte de verdade** para tipos e schemas compartilhados:
|
||||
|
||||
```
|
||||
<modulo>-comuns/src/
|
||||
├── tabelas/ ← schemas Zod por entidade (zEntidadeCriar, etc.)
|
||||
├── enums/ ← enums de domínio do módulo
|
||||
├── tipos/ ← tipos derivados dos schemas
|
||||
└── utils/ ← funções puras sem side-effect
|
||||
```
|
||||
|
||||
**Proibido** no comuns:
|
||||
- Componentes Vue ou React
|
||||
- Código com `import` de Node.js (`fs`, `path`, `http`)
|
||||
- Código com `import` de bibliotecas de frontend (`vue`, `vuetify`)
|
||||
- Lógica de negócio que depende de banco ou serviço externo
|
||||
|
||||
### `<modulo>-back`
|
||||
|
||||
```
|
||||
<modulo>-back/src/
|
||||
├── rotas/ ← endpoints Express/Fastify
|
||||
├── servicos/ ← lógica de negócio
|
||||
├── banco/ ← queries (Knex, Prisma, etc.)
|
||||
├── filas/ ← processadores de fila
|
||||
├── cron/ ← tarefas agendadas
|
||||
└── utils/ ← helpers exclusivos do back
|
||||
```
|
||||
|
||||
### `<modulo>-front`
|
||||
|
||||
```
|
||||
<modulo>-front/src/
|
||||
├── paginas/ ← páginas/views por rota
|
||||
├── componentes/ ← componentes reutilizáveis do módulo
|
||||
├── composables/ ← lógica reutilizável (use*.ts)
|
||||
└── utils/ ← helpers exclusivos do front
|
||||
```
|
||||
|
||||
### `<modulo>-migracao`
|
||||
|
||||
```
|
||||
<modulo>-migracao/src/
|
||||
├── migrations/ ← criação/alteração de tabelas
|
||||
├── seeds/ ← dados iniciais
|
||||
└── scripts/ ← scripts de carga/transformação
|
||||
```
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra:
|
||||
- Front importa serviço de back (quebra em build de produção)
|
||||
- Módulo A acessa tabelas do Módulo B diretamente (acoplamento oculto)
|
||||
- Schemas ficam duplicados entre back e front
|
||||
- Mudança em um módulo quebra outro sem aviso
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md` (schemas no `*-comuns`)
|
||||
- Skill: `.agent/skills/mapear-codigo-fonte.global/SKILL.md`
|
||||
|
|
@ -1,59 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: jsdoc-padrao
|
||||
description: Padrões de documentação em código (JSDoc, casts temporários e TODOs estruturados)
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
- "**/*.vue"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Documentação em Código
|
||||
|
||||
## 1. JSDoc — Princípios
|
||||
|
||||
- **Por que, não o Quê**: documente o raciocínio, não o mecanismo que o TypeScript já expressa.
|
||||
- **Nomenclatura limpa**: confie em nomes expressivos antes de comentários.
|
||||
|
||||
## 2. JSDoc obrigatório em funções compartilhadas
|
||||
|
||||
Toda função central ou de uso compartilhado deve ter cabeçalho JSDoc:
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* Busca detalhes da entidade e calcula privilégios aplicáveis.
|
||||
* Não utilizar em processamento em lote para evitar sobrecarga.
|
||||
*
|
||||
* @param tenantId - Identificador do tenant no sistema
|
||||
* @param entityId - ID do registro na base de dados
|
||||
* @returns Objeto consolidado ou `null` se não encontrado
|
||||
*/
|
||||
export const obterDetalhes = async (tenantId: string, entityId: string) => { ... }
|
||||
```
|
||||
|
||||
## 3. Casts temporários — justificativa obrigatória
|
||||
|
||||
Coerções agressivas requerem comentário explicando o porquê:
|
||||
|
||||
```typescript
|
||||
// Necessário: biblioteca externa não provê tipagem genérica na versão atual
|
||||
const dados = payload.raw as unknown as RespostaFormatada
|
||||
```
|
||||
|
||||
## 4. TODOs estruturados
|
||||
|
||||
Dívida técnica ou dúvida de negócio deve seguir formato padronizado:
|
||||
|
||||
- **Tipagem**: `// TODO de tipagem: Criar interface para o retorno da API`
|
||||
- **Negócio**: `// TODO de regra: Validar com Produto se taxa se aplica a clientes antigos`
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem este padrão, funções compartilhadas ficam sem documentação, casts aparecem sem justificativa, e TODOs são inconsistentes e difíceis de buscar.
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
|
|
@ -1,66 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: limite-linhas
|
||||
description: Nenhum arquivo de código pode ultrapassar 250 linhas
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
- "**/*.vue"
|
||||
- "**/*.css"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Limite de 250 Linhas por Arquivo
|
||||
|
||||
## Regra
|
||||
|
||||
Nenhum arquivo `*.vue`, `*.ts`, `*.tsx` ou `*.css` pode ultrapassar **250 linhas**.
|
||||
|
||||
> Validação automática: `.agent/base/verificar-linhas.sh`
|
||||
|
||||
## Estratégias de Decomposição
|
||||
|
||||
| Situação | Ação |
|
||||
|---|---|
|
||||
| Template longo | Extrair seções como subcomponentes |
|
||||
| CSS extenso | Mover para `<nome>.css` co-localizado |
|
||||
| `setup()` extenso | Extrair subcomponentes, CSS ou Dispatch Table |
|
||||
| Modal/Dialog embutido | Sempre em componente separado (`*Modal.vue`) |
|
||||
| Handlers e dispatch | Extrair para `handlers.ts` ou `dispatch.ts` |
|
||||
|
||||
## Divisão em Pasta
|
||||
|
||||
Quando um componente precisa de múltiplos sub-arquivos, converter em **pasta homônima** com `index.vue`:
|
||||
|
||||
```
|
||||
# Antes
|
||||
ComponenteGrande.vue ← monolítico (+250 linhas)
|
||||
|
||||
# Depois
|
||||
ComponenteGrande/
|
||||
├── index.vue ← orquestração (≤250 linhas)
|
||||
├── SecaoPrincipal.vue ← bloco de template extraído
|
||||
├── SecaoSecundaria.vue ← outro bloco extraído
|
||||
├── componenteGrande.mapeadores.ts ← lógica de eventos
|
||||
└── ComponenteGrande.css ← estilos co-localizados
|
||||
```
|
||||
|
||||
| Arquivo | Responsabilidade |
|
||||
|---|---|
|
||||
| `index.vue` | Orquestração: importa e compõe. Sem lógica densa. |
|
||||
| `Secao*.vue` | Template isolado. Props + eventos. |
|
||||
| `*.mapeadores.ts` | Funções de ação desacopladas. |
|
||||
| `*.css` | Estilos co-localizados. |
|
||||
|
||||
> Importações externas não mudam: `ComponenteGrande/` resolve para `index.vue`.
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra, arquivos crescem silenciosamente até se tornarem intocáveis — ninguém quer revisar ou refatorar um componente de 800 linhas.
|
||||
|
||||
## Referências
|
||||
|
||||
- Script: `.agent/base/verificar-linhas.sh`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
|
|
@ -1,123 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: mensagens-usuario
|
||||
description: Toda mensagem visível ao usuário final deve ser escrita em linguagem do domínio, sem termos técnicos de TI
|
||||
scope: global
|
||||
trigger: file_match
|
||||
globs:
|
||||
- "**/*.vue"
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Mensagens Orientadas ao Domínio
|
||||
|
||||
## Contexto
|
||||
|
||||
O usuário final dos módulos SaaS é profissional de **engenharia, ciência ou gestão ambiental**. Ele entende de legislação, processos técnicos e ciência aplicada — mas **não tem obrigação de entender tecnologia**.
|
||||
|
||||
Toda mensagem visível na interface — erro, validação, confirmação, tooltip, empty state, ajuda — deve ser escrita na linguagem do domínio do módulo.
|
||||
|
||||
## Regra
|
||||
|
||||
### 1. Erros de validação devem indicar O QUE preencher, não O QUE falhou
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — linguagem técnica
|
||||
"Campo obrigatório"
|
||||
"Erro de validação"
|
||||
"Formato inválido"
|
||||
"Payload inválido"
|
||||
|
||||
// ✅ CORRETO — linguagem do domínio
|
||||
"Informe a Área do Empreendimento (em hectares)"
|
||||
"Selecione o Tipo de Licença: LP, LI ou LO"
|
||||
"A Data da Vistoria deve ser anterior à data atual"
|
||||
"Informe o CNPJ no formato 00.000.000/0000-00"
|
||||
```
|
||||
|
||||
### 2. Erros de sistema devem ser traduzidos para o usuário
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — erro técnico exposto
|
||||
"Erro 500: Internal Server Error"
|
||||
"Timeout na requisição"
|
||||
"Network Error"
|
||||
"ECONNREFUSED"
|
||||
|
||||
// ✅ CORRETO — mensagem humanizada
|
||||
"Não foi possível salvar. Tente novamente em instantes."
|
||||
"A operação demorou mais que o esperado. Tente novamente."
|
||||
"Sem conexão com o servidor. Verifique sua internet."
|
||||
```
|
||||
|
||||
### 3. Estados vazios devem explicar o contexto
|
||||
|
||||
Quando uma lista ou tabela está vazia, a mensagem deve orientar o usuário:
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
"Nenhum registro encontrado"
|
||||
"Lista vazia"
|
||||
|
||||
// ✅ CORRETO — explica o domínio e orienta
|
||||
"Nenhuma condicionante cadastrada para esta licença."
|
||||
"Nenhum relatório de monitoramento registrado neste período."
|
||||
"Nenhum empreendimento encontrado com os filtros aplicados. Tente ampliar a busca."
|
||||
```
|
||||
|
||||
### 4. Confirmações devem descrever a consequência
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
"Tem certeza que deseja excluir?"
|
||||
"Confirmar operação?"
|
||||
|
||||
// ✅ CORRETO — descreve o impacto
|
||||
"Excluir esta condicionante? O prazo de cumprimento e os documentos vinculados serão removidos."
|
||||
"Arquivar esta licença? Ela não aparecerá mais nas listagens ativas."
|
||||
```
|
||||
|
||||
### 5. Labels e placeholders devem usar vocabulário do domínio
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — genérico
|
||||
label: "Nome"
|
||||
placeholder: "Digite aqui"
|
||||
|
||||
// ✅ CORRETO — específico do domínio
|
||||
label: "Razão Social do Empreendedor"
|
||||
placeholder: "Ex: Mineração Vale Verde Ltda."
|
||||
|
||||
label: "Área Total do Empreendimento"
|
||||
placeholder: "Em hectares (ex: 150,5)"
|
||||
```
|
||||
|
||||
### 6. Schemas Zod devem ter mensagens de domínio
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — mensagens padrão do Zod
|
||||
const zEmpreendimento = z.object({
|
||||
nome: z.string().min(1), // "String must contain at least 1 character(s)"
|
||||
area: z.number().positive(), // "Number must be greater than 0"
|
||||
})
|
||||
|
||||
// ✅ CORRETO — mensagens customizadas
|
||||
const zEmpreendimento = z.object({
|
||||
nome: z.string().min(1, "Informe o nome do empreendimento"),
|
||||
area: z.number({ invalid_type_error: "A área deve ser um número" })
|
||||
.positive("A área deve ser maior que zero"),
|
||||
cnpj: z.string().regex(/^\d{2}\.\d{3}\.\d{3}\/\d{4}-\d{2}$/,
|
||||
"CNPJ inválido. Use o formato 00.000.000/0000-00"),
|
||||
})
|
||||
```
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra, o agente gera mensagens técnicas que confundem gestores ambientais, consultores e técnicos de campo — forçando a equipe de suporte a traduzir erros de sistema para o vocabulário do cliente.
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md` (schemas com mensagens customizadas)
|
||||
- Workflow: `.agent/workflows/ux.global.md` (design de interface)
|
||||
|
|
@ -1,120 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: regras-negocio-md
|
||||
description: Arquivo {modulo}.regras-negocio.md obrigatório para módulos com lógica complexa
|
||||
scope: global
|
||||
trigger: always_on
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Regra: Arquivo `{modulo}.regras-negocio.md` Obrigatório para Módulos com Lógica Complexa
|
||||
|
||||
> **Escopo global** — aplica-se a todos os projetos do ecossistema Azteca.
|
||||
|
||||
## Contexto
|
||||
|
||||
Qualquer arquivo TypeScript que contenha lógica de negócio não-trivial — múltiplas regras de decisão, critérios de bloqueio, estratégias de processamento — deve ter suas regras documentadas em linguagem natural em um arquivo Markdown co-localizado.
|
||||
|
||||
Isso garante que produto, suporte e desenvolvimento possam entender as regras sem precisar ler TypeScript, e que o agente de IA encontre rapidamente os critérios corretos antes de alterar qualquer código.
|
||||
|
||||
## Regra
|
||||
|
||||
**Todo módulo com lógica de negócio não-trivial DEVE ter um arquivo `{modulo}.regras-negocio.md` co-localizado.**
|
||||
|
||||
Considera-se lógica não-trivial qualquer módulo que:
|
||||
- possui 3 ou mais critérios de decisão distintos
|
||||
- realiza eleição/priorização entre registros
|
||||
- aplica diferentes estratégias por tipo de dado
|
||||
- pode resultar em revisão manual (caminho alternativo ao fluxo automático)
|
||||
- é consumido por CRON, worker ou importador automático
|
||||
|
||||
O módulo TypeScript deve conter, na primeira linha do arquivo, a referência:
|
||||
|
||||
```typescript
|
||||
// Regras de negócio: ver {modulo}.regras-negocio.md
|
||||
```
|
||||
|
||||
O arquivo `.md` é a **fonte de verdade**. Os JSDoc do código devem referenciar o `.md`, não duplicá-lo.
|
||||
|
||||
## Estrutura Obrigatória do Arquivo
|
||||
|
||||
```markdown
|
||||
# Regras de Negócio — [Nome do Módulo]
|
||||
|
||||
Módulo: `_arquivo.ts`
|
||||
Localização: `caminho/relativo/ao/arquivo`
|
||||
|
||||
---
|
||||
|
||||
## Contexto
|
||||
Por que este módulo existe, qual problema resolve.
|
||||
|
||||
## Critérios de Entrada / Identificação
|
||||
O que aciona o módulo, quais dados recebe, filtros aplicados.
|
||||
|
||||
## Regras de Processamento
|
||||
As regras numeradas em ordem de avaliação.
|
||||
|
||||
## Casos de Revisão Manual (quando aplicável)
|
||||
Quando o processamento automático não pode prosseguir.
|
||||
|
||||
## Estratégia de Fusão / Resultado (quando aplicável)
|
||||
O que o módulo produz, como campos são combinados.
|
||||
|
||||
## Dependências Externas
|
||||
Tabelas, filas, serviços externos tocados pelo módulo.
|
||||
```
|
||||
|
||||
## Exemplos
|
||||
|
||||
✅ **Correto** — referência no topo do módulo, regras no `.md`:
|
||||
```typescript
|
||||
// Regras de negócio: ver juntar_execucoes.regras-negocio.md
|
||||
|
||||
import { ... } from "..."
|
||||
|
||||
export const compilarJuntarExecucoes = async (...) => {
|
||||
// implementação conforme regras-negocio.md
|
||||
}
|
||||
```
|
||||
|
||||
❌ **Errado** — regras embutidas no código como comentário de bloco:
|
||||
```typescript
|
||||
/**
|
||||
* Regras de negócio:
|
||||
* [x] Pode ter apenas uma execução por data de vencimento.
|
||||
* [x] Se tiver apenas uma execução consolidada → ela é a principal.
|
||||
* ...
|
||||
*/
|
||||
```
|
||||
|
||||
❌ **Errado** — JSDoc duplicando as regras em vez de referenciar o `.md`:
|
||||
```typescript
|
||||
/**
|
||||
* Retorna false quando:
|
||||
* - vencimentos divergentes
|
||||
* - executada com datas distintas
|
||||
* - vencimento_prorrogado distintos
|
||||
* ...
|
||||
*/
|
||||
```
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem este padrão:
|
||||
- Regras de negócio ficam implícitas no código ou em JSDoc que envelhece sem controle
|
||||
- O agente de IA precisa inferir regras do código ao invés de lê-las diretamente
|
||||
- Produto e suporte não conseguem validar o comportamento sem ajuda técnica
|
||||
- Mudanças de regra geram JSDoc desatualizado espalhado pelo código
|
||||
|
||||
## Aplicação
|
||||
|
||||
- Módulos de CRON com lógica de auditoria/fusão
|
||||
- Importadores automáticos (ex: importação de licenças via IA)
|
||||
- Workers de processamento em lote
|
||||
- Qualquer utilitário com lógica de decisão multi-critério
|
||||
|
||||
## Referências
|
||||
|
||||
- Skill: `.agent/skills/documentar-regras-negocio.global/SKILL.md`
|
||||
- Workflow: `.agent/workflows/documentar-regras-negocio.global.md`
|
||||
|
|
@ -1,77 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: typescript-sem-any
|
||||
trigger: always_on
|
||||
description: Proíbe uso de any, casts inseguros e padroniza uso de enums em código TypeScript
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
globs:
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
- "**/*.vue"
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
Regras obrigatórias para TypeScript neste projeto:
|
||||
|
||||
- Nunca usar `any`.
|
||||
- Nunca usar `as any`.
|
||||
- Nunca contornar erro de tipagem com cast forçado.
|
||||
- Quando o tipo não for conhecido, usar `unknown`.
|
||||
- Antes de acessar valores `unknown`, fazer narrowing com:
|
||||
- `typeof`
|
||||
- `in`
|
||||
- `Array.isArray`
|
||||
- type guards
|
||||
- schemas de validação como Zod
|
||||
- Preferir:
|
||||
- generics
|
||||
- union types
|
||||
- `Record<string, unknown>`
|
||||
- `Partial<T>`
|
||||
- `Pick<T, K>`
|
||||
- `PropType<T>` em Vue
|
||||
- tipos derivados de funções existentes
|
||||
- Se faltar tipo, o agente deve:
|
||||
1. procurar tipos já existentes no projeto;
|
||||
2. criar um tipo/interface local explícita;
|
||||
3. inferir a partir do contexto sempre que possível;
|
||||
4. deixar um `TODO de tipagem` explícito, mas sem usar `any`.
|
||||
|
||||
Regras obrigatórias para uso de enums:
|
||||
|
||||
- Quando um valor estiver associado a um `enum`, é obrigatório utilizar o enum, nunca strings literais.
|
||||
- O acesso deve seguir o padrão: `<NomeEnum>.VALOR`.
|
||||
|
||||
Também é proibido, quando existir `enum` correspondente:
|
||||
|
||||
- utilizar strings literais no lugar do enum (ex: `"ativo"`, `"inativo"`, `"automatica"`, `"criar"`);
|
||||
- utilizar cast para forçar compatibilidade com enum (ex: `"ativo" as StatusConta`).
|
||||
|
||||
Proibido gerar código que apenas "faça compilar" usando:
|
||||
|
||||
- `as any`
|
||||
- `: any`
|
||||
- `[] as any`
|
||||
- `{ } as any`
|
||||
- dupla coerção como `as unknown as any`
|
||||
|
||||
Em casos excepcionais, preferir:
|
||||
|
||||
- `as unknown as TipoEspecifico` somente se houver justificativa clara e comentário técnico.
|
||||
|
||||
Diretriz para o agente:
|
||||
|
||||
Se encontrar uma string que represente um valor de domínio do sistema, o agente deve:
|
||||
|
||||
1. procurar se já existe um `enum` correspondente no projeto;
|
||||
2. usar o `enum` existente;
|
||||
3. se não existir, propor a criação de um `enum` explícito, em vez de manter strings soltas.
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Skill: `.agent/skills/diagnosticar-erros-build.global/SKILL.md` (quando erros de tipagem causam falhas de build em cascata)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md` (padrão de documentação para casts temporários)
|
||||
|
||||
|
|
@ -1,315 +0,0 @@
|
|||
---
|
||||
type: rule
|
||||
name: zod-validacao-padrao
|
||||
description: Estabelece Zod como biblioteca obrigatória de validação em todo o ecossistema Azteca
|
||||
version: "1.0"
|
||||
scope: global
|
||||
priority: alta
|
||||
trigger: always_on
|
||||
globs:
|
||||
- "**/*.ts"
|
||||
- "**/*.tsx"
|
||||
- "**/*.vue"
|
||||
alwaysApply: true
|
||||
updatedAt: "2026-06-01"
|
||||
references:
|
||||
- .agent/rules/typescript-sem-any.global.md
|
||||
- .agent/skills/criar-schema-zod.global/SKILL.md
|
||||
---
|
||||
|
||||
# Regra: Zod como Validador Padrão
|
||||
|
||||
## Contexto
|
||||
|
||||
Todo projeto do ecossistema Azteca que receba dados externos — API, formulário, webhook, importação, fila, variáveis de ambiente — **deve** validar esses dados com [Zod](https://zod.dev).
|
||||
|
||||
Zod é a única biblioteca de validação autorizada porque:
|
||||
|
||||
- Inferência nativa de tipos TypeScript (`z.infer<>`) — elimina duplicação entre schema e tipo
|
||||
- Bundle pequeno (~13KB gzipped) — viável no frontend
|
||||
- Compartilhável entre back e front via pacotes `*-comuns`
|
||||
- Ecossistema maduro: `zod-to-json-schema`, `@anatine/zod-nestjs`, integração com `tRPC`
|
||||
|
||||
---
|
||||
|
||||
## Regra
|
||||
|
||||
### 1. Toda entrada externa deve ser validada com Zod
|
||||
|
||||
Entradas externas incluem:
|
||||
|
||||
- **Corpo de requisição** (API REST, webhook, GraphQL)
|
||||
- **Query params e path params**
|
||||
- **Formulários de frontend**
|
||||
- **Dados de fila** (BullMQ, Redis, etc.)
|
||||
- **Arquivos importados** (CSV, JSON, Excel)
|
||||
- **Variáveis de ambiente**
|
||||
- **Respostas de APIs externas** (quando a resposta não é confiável)
|
||||
|
||||
### 2. Schemas devem residir no pacote `*-comuns`
|
||||
|
||||
Para que front e back compartilhem os mesmos schemas, eles devem residir no pacote `<modulo>-comuns`:
|
||||
|
||||
```
|
||||
<modulo>-comuns/src/
|
||||
├── tabelas/
|
||||
│ ├── usuarios/
|
||||
│ │ ├── zUsuarioCriar.ts
|
||||
│ │ ├── zUsuarioEditar.ts
|
||||
│ │ └── index.ts
|
||||
│ ├── empresas/
|
||||
│ │ ├── zEmpresaCriar.ts
|
||||
│ │ └── index.ts
|
||||
│ └── index.ts
|
||||
```
|
||||
|
||||
### 3. Tipos devem ser derivados dos schemas (nunca o inverso)
|
||||
|
||||
```typescript
|
||||
// ✅ CORRETO — tipo derivado do schema
|
||||
export const zUsuarioCriar = z.object({
|
||||
nome: z.string().min(1),
|
||||
email: z.string().email(),
|
||||
ativo: z.boolean().default(true),
|
||||
})
|
||||
export type tipoUsuarioCriar = z.infer<typeof zUsuarioCriar>
|
||||
|
||||
// ❌ ERRADO — tipo manual separado do schema
|
||||
interface UsuarioCriar {
|
||||
nome: string
|
||||
email: string
|
||||
ativo?: boolean
|
||||
}
|
||||
const zUsuarioCriar = z.object({ ... }) // duplicação!
|
||||
```
|
||||
|
||||
### 4. Nomenclatura obrigatória de schemas
|
||||
|
||||
| Padrão | Uso | Exemplo |
|
||||
|--------|-----|---------|
|
||||
| `z{Entidade}Criar` | Criação de registro | `zUsuarioCriar` |
|
||||
| `z{Entidade}Editar` | Edição de registro | `zUsuarioEditar` |
|
||||
| `z{Entidade}Filtro` | Filtros de listagem | `zUsuarioFiltro` |
|
||||
| `z{Entidade}Resposta` | Resposta de API | `zUsuarioResposta` |
|
||||
| `z{Entidade}Params` | Parâmetros de rota | `zUsuarioParams` |
|
||||
| `z{Modulo}Config` | Configuração do módulo | `zGeeConfig` |
|
||||
| `z{Modulo}Ambiente` | Variáveis de ambiente | `zBackAmbiente` |
|
||||
|
||||
Prefixo `z` minúsculo + nome em `PascalCase`.
|
||||
|
||||
### 5. Usar `safeParse` em vez de `parse` para erros controlados
|
||||
|
||||
```typescript
|
||||
// ✅ CORRETO — erro controlado
|
||||
const resultado = zUsuarioCriar.safeParse(dados)
|
||||
if (!resultado.success) {
|
||||
return respostaComuns.erro(resultado.error.issues[0].message)
|
||||
}
|
||||
const usuario = resultado.data // tipado automaticamente
|
||||
|
||||
// ❌ ERRADO — throw não controlado
|
||||
const usuario = zUsuarioCriar.parse(dados) // lança ZodError
|
||||
```
|
||||
|
||||
A exceção é em contextos onde o throw é desejável (middleware global, início de pipeline).
|
||||
|
||||
### 6. Nunca usar validação manual quando Zod resolve
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO — validação manual
|
||||
if (!dados.nome || typeof dados.nome !== "string") {
|
||||
return erro("Nome é obrigatório")
|
||||
}
|
||||
if (!dados.email || !dados.email.includes("@")) {
|
||||
return erro("Email inválido")
|
||||
}
|
||||
|
||||
// ✅ CORRETO — Zod faz tudo
|
||||
const resultado = zUsuarioCriar.safeParse(dados)
|
||||
if (!resultado.success) {
|
||||
return erro(resultado.error.issues[0].message)
|
||||
}
|
||||
```
|
||||
|
||||
### 7. Transformações e defaults pertencem ao schema
|
||||
|
||||
```typescript
|
||||
// ✅ CORRETO — transformação no schema
|
||||
export const zProdutoCriar = z.object({
|
||||
nome: z.string().trim().min(1),
|
||||
preco: z.coerce.number().positive(),
|
||||
ativo: z.boolean().default(true),
|
||||
codigo: z.string().toUpperCase().optional(),
|
||||
tags: z.array(z.string()).default([]),
|
||||
})
|
||||
|
||||
// ❌ ERRADO — transformação manual após validação
|
||||
const produto = zProdutoCriar.parse(dados)
|
||||
produto.nome = produto.nome.trim()
|
||||
produto.codigo = produto.codigo?.toUpperCase()
|
||||
```
|
||||
|
||||
### 8. Composição de schemas em vez de duplicação
|
||||
|
||||
```typescript
|
||||
// ✅ CORRETO — composição
|
||||
const zEndereco = z.object({
|
||||
rua: z.string(),
|
||||
cidade: z.string(),
|
||||
uf: z.string().length(2),
|
||||
})
|
||||
|
||||
const zEmpresaCriar = z.object({
|
||||
nome: z.string(),
|
||||
endereco: zEndereco,
|
||||
})
|
||||
|
||||
const zEmpresaEditar = zEmpresaCriar.partial() // todos opcionais
|
||||
|
||||
const zEmpresaResposta = zEmpresaCriar.extend({
|
||||
codigo: z.string().uuid(),
|
||||
criadoEm: z.string().datetime(),
|
||||
})
|
||||
|
||||
// ❌ ERRADO — copiar campos entre schemas
|
||||
const zEmpresaEditar = z.object({
|
||||
nome: z.string().optional(), // duplicou!
|
||||
endereco: z.object({ // duplicou!
|
||||
rua: z.string().optional(),
|
||||
cidade: z.string().optional(),
|
||||
}),
|
||||
})
|
||||
```
|
||||
|
||||
### 9. Enums Zod para valores de domínio
|
||||
|
||||
```typescript
|
||||
// ✅ CORRETO — enum Zod quando os valores vêm de dados externos
|
||||
export const zStatusLicenca = z.enum(["ativa", "vencida", "suspensa", "cancelada"])
|
||||
export type tipoStatusLicenca = z.infer<typeof zStatusLicenca>
|
||||
|
||||
// Usar em outros schemas
|
||||
const zLicencaCriar = z.object({
|
||||
status: zStatusLicenca,
|
||||
// ...
|
||||
})
|
||||
|
||||
// ✅ TAMBÉM CORRETO — TypeScript enum quando já existe no projeto
|
||||
// e o schema referencia o enum
|
||||
import { StatusLicenca } from "./enums"
|
||||
const zLicencaCriar = z.object({
|
||||
status: z.nativeEnum(StatusLicenca),
|
||||
})
|
||||
```
|
||||
|
||||
### 10. Bibliotecas proibidas para validação
|
||||
|
||||
| ❌ Proibido | Motivo |
|
||||
|-------------|--------|
|
||||
| `joi` | Não infere tipos TS, bundle pesado |
|
||||
| `yup` | Inferência fraca, API menos ergonômica |
|
||||
| `class-validator` | Decorators, não compartilhável com frontend |
|
||||
| `io-ts` | Verboso, curva de aprendizado alta |
|
||||
| `ajv` (direto) | JSON Schema — usar `zod-to-json-schema` se precisar de JSON Schema |
|
||||
| Validação manual com `if/typeof` | Quando Zod resolve o mesmo caso |
|
||||
|
||||
---
|
||||
|
||||
## Exemplos
|
||||
|
||||
### API backend (Express)
|
||||
|
||||
```typescript
|
||||
// ✅ Correto
|
||||
import { zUsuarioCriar } from "projeto-comuns/tabelas/usuarios"
|
||||
|
||||
app.post("/usuarios", async (req, res) => {
|
||||
const resultado = zUsuarioCriar.safeParse(req.body)
|
||||
if (!resultado.success) {
|
||||
return res.status(400).json({ erro: resultado.error.issues })
|
||||
}
|
||||
const usuario = await criarUsuario(resultado.data)
|
||||
return res.json(usuario)
|
||||
})
|
||||
```
|
||||
|
||||
### Webhook com fila
|
||||
|
||||
```typescript
|
||||
// ✅ Correto — valida antes de enfileirar
|
||||
const zPayloadWebhook = z.object({
|
||||
tabela: z.enum(["empreendedores", "empreendimentos", "usuarios"]),
|
||||
dados: z.array(z.unknown()).min(1),
|
||||
})
|
||||
|
||||
app.post("/webhook/:tabela", async (req, res) => {
|
||||
const resultado = zPayloadWebhook.safeParse({
|
||||
tabela: req.params.tabela,
|
||||
dados: req.body,
|
||||
})
|
||||
if (!resultado.success) {
|
||||
return res.status(400).json({ erro: "Payload inválido" })
|
||||
}
|
||||
await fila.add("sync", resultado.data)
|
||||
return res.json({ ok: true })
|
||||
})
|
||||
```
|
||||
|
||||
### Variáveis de ambiente
|
||||
|
||||
```typescript
|
||||
// ✅ Correto — validar no boot da aplicação
|
||||
const zAmbiente = z.object({
|
||||
DATABASE_URL: z.string().url(),
|
||||
REDIS_HOST: z.string().default("localhost"),
|
||||
REDIS_PORT: z.coerce.number().default(6379),
|
||||
BASE_URL: z.string().url(),
|
||||
SESSAO_BACK: z.string().uuid(),
|
||||
NODE_ENV: z.enum(["development", "production", "test"]).default("development"),
|
||||
})
|
||||
|
||||
export const ambiente = () => zAmbiente.parse(process.env)
|
||||
```
|
||||
|
||||
### Frontend (formulário Vue)
|
||||
|
||||
```typescript
|
||||
// ✅ Correto — schema compartilhado validando antes de enviar
|
||||
import { zUsuarioCriar } from "projeto-comuns/tabelas/usuarios"
|
||||
|
||||
const salvar = async () => {
|
||||
const resultado = zUsuarioCriar.safeParse(formulario.value)
|
||||
if (!resultado.success) {
|
||||
erros.value = resultado.error.flatten().fieldErrors
|
||||
return
|
||||
}
|
||||
await api.post("/usuarios", resultado.data)
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Impacto
|
||||
|
||||
Sem esta regra:
|
||||
|
||||
- Cada desenvolvedor escolhe uma estratégia diferente de validação (if/typeof, joi, yup, etc.)
|
||||
- Tipos e schemas ficam dessincronizados — mudança no schema não reflete no tipo e vice-versa
|
||||
- Validações manuais são incompletas e inconsistentes entre endpoints
|
||||
- Código de validação é duplicado entre front e back
|
||||
- Dados inválidos passam despercebidos e corrompem a base
|
||||
|
||||
Com esta regra:
|
||||
|
||||
- Uma única fonte de verdade: o schema Zod
|
||||
- Tipos TypeScript sempre sincronizados via `z.infer<>`
|
||||
- Validação consistente em todos os pontos de entrada
|
||||
- Reutilização entre front, back e workers via pacote `*-comuns`
|
||||
- Erros de validação estruturados e internacionalizáveis
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md` (narrowing com Zod mencionado como alternativa)
|
||||
- Skill: `.agent/skills/criar-schema-zod.global/SKILL.md` (guia prático para criar schemas)
|
||||
|
|
@ -1,184 +0,0 @@
|
|||
---
|
||||
name: criar-schema-zod
|
||||
scope: global
|
||||
description: >
|
||||
Guia operacional para criar, organizar e manter schemas de validação Zod em projetos TypeScript.
|
||||
---
|
||||
|
||||
# Skill: Criar Schema Zod
|
||||
|
||||
Use esta skill ao adicionar validação de dados em qualquer ponto de entrada do sistema — API, formulário, webhook, importação, fila ou variáveis de ambiente.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Identificar a Entrada Externa
|
||||
|
||||
Determinar qual dado externo precisa de validação:
|
||||
|
||||
| Tipo de entrada | Onde validar |
|
||||
|---|---|
|
||||
| Corpo de requisição (POST/PUT) | Handler da rota, antes de qualquer lógica |
|
||||
| Query/path params | Handler da rota |
|
||||
| Formulário frontend | Antes de chamar a API |
|
||||
| Dados de fila (BullMQ) | No processador da fila |
|
||||
| Arquivo importado (CSV/JSON) | No parser, linha a linha |
|
||||
| Variáveis de ambiente | No boot da aplicação |
|
||||
| Resposta de API externa | Após receber a resposta |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Localizar ou Criar o Schema no Pacote Comuns
|
||||
|
||||
Schemas compartilhados vivem no pacote `*-comuns`:
|
||||
|
||||
```
|
||||
projeto-comuns/src/tabelas/
|
||||
├── usuarios/
|
||||
│ ├── zUsuarioCriar.ts
|
||||
│ ├── zUsuarioEditar.ts
|
||||
│ └── index.ts
|
||||
└── index.ts
|
||||
```
|
||||
|
||||
### 2.1. Verificar se já existe
|
||||
|
||||
```bash
|
||||
rg "z{NomeDaEntidade}" --include='*.ts' -l
|
||||
```
|
||||
|
||||
Se já existir → reutilizar ou compor a partir dele (`.extend()`, `.pick()`, `.partial()`).
|
||||
|
||||
### 2.2. Criar o schema
|
||||
|
||||
```typescript
|
||||
import { z } from "zod"
|
||||
|
||||
export const zUsuarioCriar = z.object({
|
||||
nome: z.string().trim().min(1, "Nome é obrigatório"),
|
||||
email: z.string().email("E-mail inválido"),
|
||||
ativo: z.boolean().default(true),
|
||||
})
|
||||
```
|
||||
|
||||
### 2.3. Nomenclatura obrigatória
|
||||
|
||||
| Padrão | Uso |
|
||||
|---|---|
|
||||
| `z{Entidade}Criar` | Criação |
|
||||
| `z{Entidade}Editar` | Edição (geralmente `.partial()`) |
|
||||
| `z{Entidade}Filtro` | Filtros de listagem |
|
||||
| `z{Entidade}Resposta` | Resposta de API |
|
||||
| `z{Entidade}Params` | Parâmetros de rota |
|
||||
| `z{Modulo}Config` | Configuração |
|
||||
| `z{Modulo}Ambiente` | Variáveis de ambiente |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Derivar o Tipo com `z.infer<>`
|
||||
|
||||
```typescript
|
||||
export type tipoUsuarioCriar = z.infer<typeof zUsuarioCriar>
|
||||
```
|
||||
|
||||
**Nunca** criar um `interface` ou `type` manual separado do schema. O tipo **sempre** deriva do schema.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Implementar `safeParse` no Ponto de Entrada
|
||||
|
||||
### Backend (Express)
|
||||
|
||||
```typescript
|
||||
import { zUsuarioCriar } from "projeto-comuns/tabelas/usuarios"
|
||||
|
||||
app.post("/usuarios", async (req, res) => {
|
||||
const resultado = zUsuarioCriar.safeParse(req.body)
|
||||
if (!resultado.success) {
|
||||
return res.status(400).json({ erro: resultado.error.issues[0].message })
|
||||
}
|
||||
const usuario = await criarUsuario(resultado.data)
|
||||
return res.json(usuario)
|
||||
})
|
||||
```
|
||||
|
||||
### Frontend (Vue)
|
||||
|
||||
```typescript
|
||||
import { zUsuarioCriar } from "projeto-comuns/tabelas/usuarios"
|
||||
|
||||
const salvar = async () => {
|
||||
const resultado = zUsuarioCriar.safeParse(formulario.value)
|
||||
if (!resultado.success) {
|
||||
erros.value = resultado.error.flatten().fieldErrors
|
||||
return
|
||||
}
|
||||
await api.post("/usuarios", resultado.data)
|
||||
}
|
||||
```
|
||||
|
||||
### Variáveis de ambiente
|
||||
|
||||
```typescript
|
||||
const zAmbiente = z.object({
|
||||
DATABASE_URL: z.string().url(),
|
||||
REDIS_HOST: z.string().default("localhost"),
|
||||
NODE_ENV: z.enum(["development", "production", "test"]).default("development"),
|
||||
})
|
||||
|
||||
// Aqui o throw é desejável — a app não deve subir com env inválido
|
||||
export const ambiente = () => zAmbiente.parse(process.env)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Compor Schemas Derivados
|
||||
|
||||
Quando precisar de variações do mesmo schema, **compor** em vez de duplicar:
|
||||
|
||||
```typescript
|
||||
// Schema base
|
||||
const zProduto = z.object({
|
||||
nome: z.string().trim().min(1),
|
||||
preco: z.coerce.number().positive(),
|
||||
categoria: z.string(),
|
||||
})
|
||||
|
||||
// Edição: todos os campos opcionais
|
||||
const zProdutoEditar = zProduto.partial()
|
||||
|
||||
// Resposta: base + campos gerados
|
||||
const zProdutoResposta = zProduto.extend({
|
||||
codigo: z.string().uuid(),
|
||||
criadoEm: z.string().datetime(),
|
||||
})
|
||||
|
||||
// Filtro: subset de campos opcionais
|
||||
const zProdutoFiltro = zProduto.pick({ categoria: true }).partial()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 6 — Validar Tipagem
|
||||
|
||||
```bash
|
||||
npx tsc --noEmit
|
||||
```
|
||||
|
||||
Zero erros = concluído.
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] O schema está no pacote `*-comuns` (quando compartilhado entre front/back)?
|
||||
- [ ] O tipo é derivado do schema com `z.infer<>`?
|
||||
- [ ] A validação usa `safeParse` (exceto em boot/middleware)?
|
||||
- [ ] A nomenclatura segue o padrão `z{Entidade}{Acao}`?
|
||||
- [ ] Transformações (trim, coerce, default) estão no schema, não no handler?
|
||||
- [ ] Schemas derivados usam composição (.partial, .extend, .pick), não duplicação?
|
||||
- [ ] `tsc --noEmit` passa sem erros?
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/zod-validacao-padrao.global.md`
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md`
|
||||
|
|
@ -1,186 +0,0 @@
|
|||
---
|
||||
name: diagnosticar-erros-build
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: >
|
||||
Guia operacional para diagnosticar e resolver erros de build em cascata em monorepos TypeScript.
|
||||
---
|
||||
|
||||
# Skill: Diagnosticar Erros de Build em Monorepo TypeScript
|
||||
|
||||
Use esta skill quando o build de um monorepo TypeScript falha — especialmente quando erros aparecem em pacotes que não foram diretamente modificados (erros em cascata).
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Capturar o Erro Completo
|
||||
|
||||
Executar o build com output completo e sem truncamento:
|
||||
|
||||
```bash
|
||||
# pnpm (monorepo completo)
|
||||
pnpm build 2>&1 | head -200
|
||||
|
||||
# Pacote específico
|
||||
pnpm --filter <pacote> build 2>&1
|
||||
|
||||
# tsc direto (se disponível)
|
||||
npx tsc --noEmit --pretty 2>&1 | head -100
|
||||
```
|
||||
|
||||
Identificar:
|
||||
|
||||
- **Qual pacote falhou primeiro** (nem sempre é o que aparece no topo)
|
||||
- **Código do erro** (`TS2304`, `TS2345`, `TS7006`, etc.)
|
||||
- **Arquivo e linha** do erro original
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Classificar o Tipo de Erro
|
||||
|
||||
### Erros de dependência entre pacotes (cascata)
|
||||
|
||||
| Sintoma | Causa provável | Solução |
|
||||
|---------|---------------|---------|
|
||||
| `Cannot find module '@org/xxx'` | Pacote não foi buildado antes | Buildar na ordem correta ou usar `references` |
|
||||
| `Module has no exported member 'X'` | Tipo renomeado/removido no pacote origem | Atualizar import no consumidor |
|
||||
| Tipos `any` infiltrados | Pacote exporta sem `.d.ts` | Verificar `declaration: true` no tsconfig |
|
||||
| `The inferred type cannot be named` | Dependência circular de tipos | Extrair tipo para pacote compartilhado |
|
||||
|
||||
### Erros de configuração
|
||||
|
||||
| Sintoma | Causa provável | Solução |
|
||||
|---------|---------------|---------|
|
||||
| `Cannot use import statement` | `module` errado no tsconfig | Alinhar `module`/`moduleResolution` |
|
||||
| `Relative import paths need extensions` | Node16/NodeNext resolution | Adicionar `.js` nos imports ou mudar para `bundler` |
|
||||
| `rootDir is expected to contain all source files` | Arquivo fora do `rootDir` | Ajustar `rootDir` ou mover arquivo |
|
||||
| `Referenced project must have setting composite` | Project references sem `composite` | Adicionar `composite: true` no tsconfig referenciado |
|
||||
|
||||
### Erros de tipagem
|
||||
|
||||
| Sintoma | Causa provável | Solução |
|
||||
|---------|---------------|---------|
|
||||
| `TS2304: Cannot find name` | Tipo global não declarado | Criar `d.ts` ou importar explicitamente |
|
||||
| `TS2345: Argument not assignable` | Tipos incompatíveis entre versões | Alinhar versão da dependência |
|
||||
| `TS7006: Parameter implicitly has 'any'` | `noImplicitAny` ativado | Tipar o parâmetro explicitamente |
|
||||
| `TS18046: is of type 'unknown'` | Narrowing ausente | Fazer type guard antes de usar |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Identificar a Raiz do Problema
|
||||
|
||||
O erro que aparece **primeiro** nem sempre é a raiz. Seguir esta estratégia:
|
||||
|
||||
### 3.1. Verificar ordem de build
|
||||
|
||||
```bash
|
||||
# Listar dependências internas para entender ordem correta
|
||||
rg '"workspace:' --include='package.json' -l | sort
|
||||
|
||||
# Se usar turbo, verificar o pipeline
|
||||
cat turbo.json | jq '.pipeline.build'
|
||||
```
|
||||
|
||||
### 3.2. Rebuild isolado do pacote raiz
|
||||
|
||||
```bash
|
||||
# Buildar APENAS o pacote mais baixo na hierarquia que apresenta erro
|
||||
pnpm --filter <pacote-raiz> build
|
||||
|
||||
# Se esse buildar com sucesso, subir na hierarquia
|
||||
pnpm --filter <pacote-consumidor> build
|
||||
```
|
||||
|
||||
### 3.3. Verificar checagem de tipos isolada
|
||||
|
||||
```bash
|
||||
# Verificar se a tipagem está correta sem produzir output
|
||||
npx tsc --noEmit -p <caminho>/tsconfig.json
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Resolver Erros em Cascata
|
||||
|
||||
### Estratégia: de baixo para cima
|
||||
|
||||
1. Identificar o pacote **mais fundamental** (aquele que não depende de outros internos)
|
||||
2. Resolver TODOS os erros nesse pacote
|
||||
3. Rebuildar
|
||||
4. Subir para o próximo pacote na cadeia de dependência
|
||||
5. Repetir até o topo
|
||||
|
||||
### Armadilhas comuns
|
||||
|
||||
```typescript
|
||||
// ❌ ERRADO: "resolver" com any (viola typescript-sem-any)
|
||||
const dados = resultado as any
|
||||
|
||||
// ✅ CORRETO: tipar adequadamente
|
||||
const dados: ResultadoEsperado = resultado
|
||||
|
||||
// ❌ ERRADO: ignorar erro com @ts-ignore
|
||||
// @ts-ignore
|
||||
import { funcao } from '@org/pacote'
|
||||
|
||||
// ✅ CORRETO: investigar por que o import falha
|
||||
// O pacote '@org/pacote' foi buildado? O export existe?
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Verificar Alinhamento de Configuração
|
||||
|
||||
Quando erros persistem entre pacotes, verificar alinhamento de tsconfig:
|
||||
|
||||
```bash
|
||||
# Comparar configurações críticas entre pacotes
|
||||
for f in $(fd tsconfig.json --max-depth 2 --type f); do
|
||||
echo "=== $f ==="
|
||||
jq '{target, module, moduleResolution, strict, composite, declaration}' "$f" 2>/dev/null
|
||||
done
|
||||
```
|
||||
|
||||
Campos que **devem** ser consistentes entre pacotes do mesmo monorepo:
|
||||
|
||||
| Campo | Recomendação |
|
||||
|-------|-------------|
|
||||
| `target` | Mesmo alvo para todos (ex: `ES2022`) |
|
||||
| `module` | Consistente (ex: `ESNext` ou `Node16`) |
|
||||
| `moduleResolution` | Consistente (ex: `bundler` ou `node16`) |
|
||||
| `strict` | `true` em todos |
|
||||
| `declaration` | `true` em libs, opcional em apps |
|
||||
| `composite` | `true` em libs referenciadas |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 6 — Limpar e Rebuildar
|
||||
|
||||
Quando a investigação não revela causa óbvia:
|
||||
|
||||
```bash
|
||||
# Limpar artefatos de build de todos os pacotes
|
||||
fd -t d 'dist|build|.tsbuildinfo' --exclude node_modules | xargs rm -rf
|
||||
|
||||
# Limpar node_modules (último recurso)
|
||||
fd -t d node_modules --max-depth 2 | xargs rm -rf
|
||||
|
||||
# Reinstalar e rebuildar do zero
|
||||
pnpm install && pnpm build
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] O pacote raiz do erro em cascata foi identificado?
|
||||
- [ ] O erro original (não o efeito cascata) foi localizado?
|
||||
- [ ] A solução não usa `any`, `as any` ou `@ts-ignore`?
|
||||
- [ ] Todos os pacotes na cadeia foram rebuildados após a correção?
|
||||
- [ ] As configurações de tsconfig estão alinhadas entre pacotes?
|
||||
- [ ] O build completo passa sem erros?
|
||||
|
||||
## Referências
|
||||
|
||||
- Rules: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Skill: `.agent/skills/mapear-codigo-fonte.global/SKILL.md`
|
||||
|
|
@ -1,161 +0,0 @@
|
|||
---
|
||||
name: documentar-decisao-tecnica
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: >
|
||||
Guia operacional para registrar decisões técnicas e arquiteturais como ADRs (Architecture Decision Records).
|
||||
---
|
||||
|
||||
# Skill: Documentar Decisão Técnica (ADR)
|
||||
|
||||
Use esta skill sempre que uma decisão técnica significativa for tomada — escolha de biblioteca, mudança de arquitetura, padrão de código, migração, ou qualquer decisão que afete múltiplos pacotes ou desenvolvedores.
|
||||
|
||||
O objetivo é garantir que **nenhuma decisão fique apenas na cabeça** ou perdida em conversas.
|
||||
|
||||
---
|
||||
|
||||
## Quando usar
|
||||
|
||||
- Nova dependência adicionada ao monorepo
|
||||
- Mudança de padrão arquitetural (ex: de REST para GraphQL)
|
||||
- Escolha de ferramenta ou lib entre alternativas
|
||||
- Decisão de breaking change
|
||||
- Migração de tecnologia
|
||||
- Mudança de estratégia de deploy ou CI/CD
|
||||
- Qualquer decisão que alguém pode questionar daqui 3 meses
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Criar o Diretório de ADRs (se não existir)
|
||||
|
||||
```bash
|
||||
mkdir -p .docs/adrs
|
||||
```
|
||||
|
||||
Convenção de diretório: `.docs/adrs/` na raiz do monorepo.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Criar o Arquivo ADR
|
||||
|
||||
Nomenclatura: `NNN-titulo-em-kebab-case.md`
|
||||
|
||||
```bash
|
||||
# Encontrar o próximo número
|
||||
NEXT=$(ls .docs/adrs/*.md 2>/dev/null | wc -l | xargs -I{} expr {} + 1)
|
||||
NEXT=$(printf "%03d" $NEXT)
|
||||
echo "Próximo ADR: $NEXT"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Preencher o Template
|
||||
|
||||
```markdown
|
||||
# ADR-NNN: Título Descritivo da Decisão
|
||||
|
||||
**Data:** YYYY-MM-DD
|
||||
**Status:** proposto | aceito | substituído por ADR-XXX | descontinuado
|
||||
**Autores:** Nome(s)
|
||||
|
||||
## Contexto
|
||||
|
||||
Descreva a situação que levou à necessidade de uma decisão.
|
||||
Inclua:
|
||||
- O problema enfrentado
|
||||
- Restrições técnicas ou de negócio
|
||||
- O que motivou a discussão
|
||||
|
||||
## Decisão
|
||||
|
||||
Descreva a decisão tomada de forma clara e direta.
|
||||
Use voz ativa: "Decidimos usar X para Y porque Z."
|
||||
|
||||
## Alternativas Consideradas
|
||||
|
||||
### Alternativa A: [Nome]
|
||||
- **Prós:** ...
|
||||
- **Contras:** ...
|
||||
- **Motivo da rejeição:** ...
|
||||
|
||||
### Alternativa B: [Nome]
|
||||
- **Prós:** ...
|
||||
- **Contras:** ...
|
||||
- **Motivo da rejeição:** ...
|
||||
|
||||
## Consequências
|
||||
|
||||
### Positivas
|
||||
- O que melhora com essa decisão
|
||||
|
||||
### Negativas
|
||||
- O que fica mais complexo ou limitado
|
||||
- Débitos técnicos introduzidos
|
||||
|
||||
### Neutras
|
||||
- Mudanças que não são boas nem ruins, mas afetam o workflow
|
||||
|
||||
## Impacto no Monorepo
|
||||
|
||||
Listar quais pacotes/módulos são afetados:
|
||||
- `@org/pacote-a` — precisa migrar de X para Y
|
||||
- `@org/pacote-b` — sem impacto
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Conectar com o Sistema de Conhecimento
|
||||
|
||||
Após criar o ADR, avaliar se a decisão deve gerar:
|
||||
|
||||
| A decisão... | Ação |
|
||||
|-------------|------|
|
||||
| Cria uma **restrição** permanente (ex: "nunca usar lib X") | Criar/atualizar uma **Rule** em `.agent/rules/` |
|
||||
| Define um **processo** repetível (ex: "para migrar, faça X, Y, Z") | Criar/atualizar um **Workflow** em `.agent/workflows/` |
|
||||
| Refina um **padrão operacional** (ex: "queries agora usam pool separado") | Atualizar a **Skill** correspondente em `.agent/skills/` |
|
||||
| Não gera artefato adicional | Apenas o ADR é suficiente |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Validar o ADR
|
||||
|
||||
Antes de considerar completo:
|
||||
|
||||
- **Teste do "daqui a 6 meses"**: alguém que não participou da conversa consegue entender a decisão?
|
||||
- **Teste da reversibilidade**: está claro o que seria necessário para reverter essa decisão?
|
||||
- **Teste do impacto**: todos os pacotes afetados estão listados?
|
||||
|
||||
---
|
||||
|
||||
## Exemplos de ADRs Reais
|
||||
|
||||
### Bom ✅
|
||||
|
||||
> **ADR-003: Usar Zod para validação de schemas em vez de Joi**
|
||||
>
|
||||
> **Contexto:** O projeto usava Joi para validação no backend, mas ao compartilhar schemas entre back e front em um monorepo, Joi se mostrou pesado para o bundle do frontend (280KB gzipped).
|
||||
>
|
||||
> **Decisão:** Migrar para Zod em todos os pacotes. Zod oferece inferência nativa de tipos TypeScript, é 10x menor, e elimina a necessidade de manter tipos e schemas separados.
|
||||
|
||||
### Ruim ❌
|
||||
|
||||
> **ADR-003: Usar Zod**
|
||||
>
|
||||
> Decidimos usar Zod porque é melhor.
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] O contexto explica o "porquê" da decisão?
|
||||
- [ ] As alternativas consideradas estão documentadas?
|
||||
- [ ] As consequências (positivas e negativas) estão claras?
|
||||
- [ ] Os pacotes impactados estão listados?
|
||||
- [ ] O status está definido (proposto/aceito)?
|
||||
- [ ] A decisão gerou rules/workflows/skills quando aplicável?
|
||||
- [ ] Alguém de fora do contexto entenderia este ADR?
|
||||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/aprimorar-IA.global.md` (seção de classificação de artefatos)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
|
|
@ -1,131 +0,0 @@
|
|||
---
|
||||
name: documentar-dominio-modulo
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: >
|
||||
Guia para documentar o domínio científico/técnico de cada módulo SaaS,
|
||||
garantindo que o agente compreenda a terminologia e as regras do domínio
|
||||
ao gerar código, texto e interface.
|
||||
---
|
||||
|
||||
# Skill: Documentar Domínio de um Módulo
|
||||
|
||||
Use esta skill ao iniciar um novo módulo SaaS ou ao perceber que o agente não conhece o vocabulário e as regras do domínio que o módulo aborda.
|
||||
|
||||
Cada módulo opera em uma disciplina diferente da ciência/gestão ambiental (licenciamento, gases de efeito estufa, resíduos, projetos, etc.). O agente precisa de uma **base factual do domínio** para gerar labels, mensagens, regras de negócio e textos comerciais corretos.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Identificar o Domínio do Módulo
|
||||
|
||||
Determinar qual área da ciência/gestão o módulo aborda:
|
||||
|
||||
| Exemplo de módulo | Domínio |
|
||||
|---|---|
|
||||
| Licenciamento | Licenciamento ambiental (LP, LI, LO, condicionantes) |
|
||||
| GEE | Gases de Efeito Estufa (inventário, emissões, fatores) |
|
||||
| Resíduos | Gestão de resíduos sólidos (PGRS, MTR, classificação) |
|
||||
| Outorga | Outorga de uso de recursos hídricos |
|
||||
| Flora/Fauna | Monitoramento de biodiversidade |
|
||||
| Projetos | Gestão de projetos ambientais e consultorias |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Criar o Arquivo de Domínio
|
||||
|
||||
Criar em `.agent/memoria/dominio-<modulo>.md`:
|
||||
|
||||
```markdown
|
||||
# Domínio: <Nome do Módulo>
|
||||
|
||||
## Área de Conhecimento
|
||||
Breve descrição da disciplina (1-3 linhas).
|
||||
|
||||
## Glossário do Módulo
|
||||
|
||||
| Termo | Definição | Sigla |
|
||||
|---|---|---|
|
||||
| Licença Prévia | Autorização para planejamento do empreendimento | LP |
|
||||
| Licença de Instalação | Autorização para início das obras | LI |
|
||||
| ... | ... | ... |
|
||||
|
||||
## Entidades Principais
|
||||
|
||||
Lista das entidades de negócio do módulo com descrição e relações:
|
||||
|
||||
- **Empreendimento**: unidade física onde ocorre a atividade potencialmente poluidora
|
||||
- **Licença**: autorização ambiental vinculada a um empreendimento
|
||||
- **Condicionante**: obrigação imposta pelo órgão ambiental na licença
|
||||
- ...
|
||||
|
||||
## Legislação Aplicável
|
||||
|
||||
| Norma | Descrição | Relevância |
|
||||
|---|---|---|
|
||||
| Lei 6.938/1981 | Política Nacional do Meio Ambiente | Base legal do licenciamento |
|
||||
| Resolução CONAMA 237/1997 | Regulamenta o licenciamento ambiental | Tipos de licença, prazos |
|
||||
| ... | ... | ... |
|
||||
|
||||
## Regras de citação legal
|
||||
- Formato: "Resolução CONAMA nº 237/1997, art. 8º, inciso I"
|
||||
- Toda sigla na primeira ocorrência com nome por extenso
|
||||
- Legislação federal > estadual > municipal (hierarquia)
|
||||
|
||||
## Fluxos do Domínio
|
||||
|
||||
Descrever os processos-chave que o módulo implementa:
|
||||
|
||||
1. Solicitação de licença → Análise técnica → Emissão → Monitoramento
|
||||
2. Cadastro de condicionante → Acompanhamento de prazo → Cumprimento
|
||||
|
||||
## Vocabulário de Interface
|
||||
|
||||
Termos que devem ser usados em labels, botões e mensagens:
|
||||
|
||||
| Contexto | ❌ Genérico | ✅ Correto para o módulo |
|
||||
|---|---|---|
|
||||
| Campo de nome | "Nome" | "Razão Social do Empreendedor" |
|
||||
| Status | "Ativo/Inativo" | "Vigente/Vencida/Suspensa" |
|
||||
| Ação principal | "Criar novo" | "Solicitar nova licença" |
|
||||
| Lista vazia | "Nenhum registro" | "Nenhuma licença cadastrada" |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Validar com o Operador
|
||||
|
||||
Antes de consolidar:
|
||||
|
||||
- [ ] Os termos do glossário estão corretos para o contexto do módulo?
|
||||
- [ ] As entidades cobrem os conceitos centrais?
|
||||
- [ ] A legislação listada é a principal (não exaustiva)?
|
||||
- [ ] O vocabulário de interface reflete como o usuário fala no dia a dia?
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Conectar com as Rules
|
||||
|
||||
Após documentar o domínio:
|
||||
|
||||
1. Verificar se labels e mensagens no código usam o vocabulário definido (rule `mensagens-usuario.global.md`)
|
||||
2. Verificar se schemas Zod têm mensagens de erro no idioma do domínio (rule `zod-validacao-padrao.global.md`)
|
||||
3. Verificar se os arquivos `.ajuda.md` usam termos do glossário (workflow `adicionar-ajuda.global.md`)
|
||||
4. Verificar se textos comerciais citam a legislação corretamente (workflow `comercial.global.md`)
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] Arquivo `dominio-<modulo>.md` criado em `.agent/memoria/`?
|
||||
- [ ] Glossário com pelo menos os 10 termos centrais do módulo?
|
||||
- [ ] Entidades principais listadas com descrição?
|
||||
- [ ] Legislação base documentada com formato de citação?
|
||||
- [ ] Vocabulário de interface definido (labels, status, ações, empty states)?
|
||||
- [ ] Operador validou a terminologia?
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/mensagens-usuario.global.md`
|
||||
- Rule: `.agent/rules/regras-negocio-md.global.md`
|
||||
- Workflow: `.agent/workflows/comercial.global.md`
|
||||
- Workflow: `.agent/workflows/adicionar-ajuda.global.md`
|
||||
|
|
@ -1,212 +0,0 @@
|
|||
---
|
||||
name: documentar-regras-negocio
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: >
|
||||
Guia operacional para criar, preencher e manter arquivos {modulo}.regras-negocio.md
|
||||
co-localizados com módulos TypeScript de lógica de negócio complexa.
|
||||
---
|
||||
|
||||
# Skill: Documentar Regras de Negócio em Módulos
|
||||
|
||||
Use esta skill sempre que um módulo TypeScript contiver lógica de decisão não-trivial
|
||||
que precise ser rastreável por produto, suporte e desenvolvimento sem exigir leitura de código.
|
||||
|
||||
---
|
||||
|
||||
## Quando usar esta skill
|
||||
|
||||
- Módulo com 3+ critérios de decisão distintos
|
||||
- Lógica de eleição/priorização entre registros
|
||||
- Processamento que pode resultar em revisão manual
|
||||
- Worker/CRON consumindo dados com estratégias diferenciadas por tipo
|
||||
- Importador automático com regras de aceite/rejeição
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Identificar o escopo das regras
|
||||
|
||||
Antes de escrever o `.md`, percorrer o módulo e identificar:
|
||||
|
||||
| Categoria | O que procurar |
|
||||
|---|---|
|
||||
| **Critérios de entrada** | Filtros de query (excluido, vencimento, etc.) |
|
||||
| **Critérios de bloqueio** | Condições que bloqueiam o fluxo automático |
|
||||
| **Estratégia por tipo de dado** | Concatenação vs. primeiro-não-nulo vs. outros |
|
||||
| **Eleição de principal** | Regras de prioridade entre registros |
|
||||
| **Estado contraditório** | Combinações de campos mutuamente exclusivas |
|
||||
| **Dependências externas** | Tabelas, filas, serviços tocados |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Criar o arquivo
|
||||
|
||||
Nomenclatura: `{nome-do-modulo-sem-underline-inicial}.regras-negocio.md`
|
||||
|
||||
Localizar **na mesma pasta** do arquivo TypeScript:
|
||||
|
||||
```
|
||||
modulo/
|
||||
_meuModulo.ts
|
||||
meu-modulo.regras-negocio.md ← co-localizado
|
||||
```
|
||||
|
||||
Se o módulo for arquivo isolado (não pasta):
|
||||
```
|
||||
CRONS/
|
||||
_cron_nome.ts
|
||||
_cron_nome.regras-negocio.md ← mesmo diretório
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Preencher com o template
|
||||
|
||||
```markdown
|
||||
# Regras de Negócio — [Nome Legível do Módulo]
|
||||
|
||||
Módulo: `_arquivo.ts`
|
||||
Localização: `caminho/relativo/ao/workspace`
|
||||
|
||||
---
|
||||
|
||||
## Contexto
|
||||
|
||||
[Por que este módulo existe. Qual problema de negócio resolve.
|
||||
Inclua o cenário que levou à sua criação — ex: "O sistema pode gerar duplicatas
|
||||
por importações simultâneas..."]
|
||||
|
||||
---
|
||||
|
||||
## Critérios de Entrada
|
||||
|
||||
[O que aciona o módulo. Filtros aplicados na query de identificação.
|
||||
Ex: `excluido = false`, mesmo `(codigo_origem, vencimento)`, etc.]
|
||||
|
||||
---
|
||||
|
||||
## Regras de Processamento
|
||||
|
||||
[Numeradas em ordem de avaliação. Cada regra deve incluir:
|
||||
- Condição de ativação
|
||||
- O que acontece quando ativada
|
||||
- Se bloqueia ou direciona]
|
||||
|
||||
### Regra 1 — [Nome]
|
||||
...
|
||||
|
||||
### Regra 2 — [Nome]
|
||||
...
|
||||
|
||||
---
|
||||
|
||||
## Casos de Revisão Manual
|
||||
|
||||
[Quando o fluxo automático não pode prosseguir.
|
||||
Liste as condições que enviam para revisão manual.
|
||||
Se aplicável: como o caso é reportado (e-mail, log, fila de revisão).]
|
||||
|
||||
> **`null` é neutro** quando aplicável: descrever aqui se a lógica usa null como ausência neutra.
|
||||
|
||||
---
|
||||
|
||||
## Estratégia de Saída / Fusão de Campos
|
||||
|
||||
[Como os dados são combinados ou qual resultado é produzido.
|
||||
Usar tabela para clareza:]
|
||||
|
||||
| Campo | Estratégia |
|
||||
|---|---|
|
||||
| `campo_textual` | Concatenação sem repetição |
|
||||
| `campo_data` | Primeiro valor não-nulo vence |
|
||||
| `campo_booleano` | Primeiro valor não-nulo vence |
|
||||
|
||||
---
|
||||
|
||||
## Dependências Externas
|
||||
|
||||
[Tabelas lidas/escritas, filas disparadas, serviços externos.
|
||||
Incluir colunas de relacionamento quando relevante.]
|
||||
|
||||
- Tabelas de negócio: `tabela_a`, `tabela_b`
|
||||
- Relacionamentos re-apontados: `tabela_c` via `(codigo_origem, tabela_origem)`
|
||||
- Filas: nenhuma / `nome-da-fila`
|
||||
- E-mails: nenhum / destinatários e gatilho
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Adicionar referência no módulo TypeScript
|
||||
|
||||
Na **primeira linha útil** do arquivo `.ts` (após shebang ou licença, se houver):
|
||||
|
||||
```typescript
|
||||
// Regras de negócio: ver {modulo}.regras-negocio.md
|
||||
|
||||
import { ... } from "..."
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Limpar JSDoc duplicados
|
||||
|
||||
Percorrer os JSDoc do módulo e:
|
||||
|
||||
| Se encontrar | Ação |
|
||||
|---|---|
|
||||
| JSDoc listando as regras de negócio | Substituir por referência ao `.md` |
|
||||
| JSDoc descrevendo critérios de bloqueio | Simplificar para "ver `.md`" |
|
||||
| JSDoc com listas de condições | Manter apenas `@param` e `@returns` |
|
||||
| Comentário inline explicando uma regra | Manter — comentários de linha são aceitáveis |
|
||||
|
||||
Exemplo de simplificação:
|
||||
|
||||
```typescript
|
||||
// ❌ Antes — JSDoc duplicando as regras
|
||||
/**
|
||||
* Retorna false quando:
|
||||
* - vencimentos divergentes
|
||||
* - executada com datas distintas e não-nulas
|
||||
* - vencimento_prorrogado distintos
|
||||
* - estado contraditório: nao_executada=true + executada!=null
|
||||
*/
|
||||
|
||||
// ✅ Depois — referência ao .md
|
||||
/**
|
||||
* Verifica se o grupo pode ser fundido e elege o registro principal.
|
||||
* Critérios de bloqueio e regras de eleição: ver regras-negocio.md
|
||||
*
|
||||
* @param execs - Registros do grupo, ordenados do mais antigo para o mais recente
|
||||
* @returns Código do eleito, ou `undefined` quando o grupo vai para revisão manual
|
||||
*/
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 6 — Verificar consistência código ↔ `.md`
|
||||
|
||||
Percorrer cada regra listada no `.md` e verificar que há código correspondente:
|
||||
|
||||
- [ ] Cada critério de bloqueio tem um `if (...) return undefined / return retornoVazio`
|
||||
- [ ] Cada estratégia de campo tem implementação em `fundirCampos` ou equivalente
|
||||
- [ ] A ordem de avaliação no código bate com a ordem no `.md`
|
||||
- [ ] Campos exclusivos de certas tabelas estão guardados pelo `if (tabela === ...)`
|
||||
- [ ] queries têm `orderBy` quando a posição dos resultados tem significado (ver skill `consultar-banco-knex`)
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] Arquivo `.md` criado co-localizado com o módulo
|
||||
- [ ] Referência `// Regras de negócio: ver ...` na primeira linha do `.ts`
|
||||
- [ ] JSDoc simplificados — sem duplicar conteúdo do `.md`
|
||||
- [ ] Todas as regras do `.md` têm implementação correspondente no código
|
||||
- [ ] Código e `.md` estão consistentes (separadores, campos, condições)
|
||||
- [ ] `tsc --noEmit` passa sem erros após qualquer mudança de código
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `.agent/rules/regras-negocio-md.global.md`
|
||||
- Workflow: `.agent/workflows/documentar-regras-negocio.global.md`
|
||||
|
|
@ -1,160 +0,0 @@
|
|||
---
|
||||
name: mapear-codigo-fonte
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
description: >
|
||||
Guia operacional para mapear, navegar e compreender a estrutura de um monorepo TypeScript.
|
||||
---
|
||||
|
||||
# Skill: Mapear Código-Fonte de Monorepo TypeScript
|
||||
|
||||
Use esta skill ao iniciar trabalho em um monorepo desconhecido, ao onboardar em novo projeto, ou quando precisar localizar rapidamente onde uma funcionalidade vive no código.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Identificar a Raiz e o Gerenciador de Pacotes
|
||||
|
||||
Localize os arquivos que definem a estratégia de monorepo:
|
||||
|
||||
```bash
|
||||
# Identificar o gerenciador e workspace config
|
||||
ls -la package.json pnpm-workspace.yaml lerna.json turbo.json nx.json tsconfig.base.json 2>/dev/null
|
||||
```
|
||||
|
||||
Elementos a extrair:
|
||||
|
||||
- **Gerenciador**: `pnpm` (workspaces em `pnpm-workspace.yaml`), `npm/yarn` (workspaces em `package.json`), ou `nx`/`turbo`
|
||||
- **Pacotes compartilhados**: diretórios listados em `packages:` ou `workspaces:`
|
||||
- **Apps/serviços**: diretórios de aplicações deployáveis
|
||||
- **TSConfig base**: herança de configuração TypeScript entre pacotes
|
||||
|
||||
---
|
||||
|
||||
## PASSO 2 — Mapear a Árvore de Pacotes
|
||||
|
||||
```bash
|
||||
# Listar todos os pacotes do workspace com nomes e caminhos
|
||||
# pnpm
|
||||
pnpm ls --depth -1 -r --json 2>/dev/null | jq '.[].name'
|
||||
|
||||
# Alternativa genérica: encontrar todos os package.json
|
||||
fd package.json --max-depth 3 --type f --exec sh -c 'echo "$(dirname {}): $(jq -r .name {})"'
|
||||
```
|
||||
|
||||
Organizar os pacotes em categorias:
|
||||
|
||||
| Categoria | Padrão de nome | Exemplo |
|
||||
|-----------|---------------|---------|
|
||||
| **Libs compartilhadas** | `@org/common`, `*-comuns`, `*-shared` | Tipos, utils, schemas |
|
||||
| **Backend** | `*-back`, `*-api`, `*-server` | Serviços Node/Express/Fastify |
|
||||
| **Frontend** | `*-front`, `*-web`, `*-app` | Apps Vue/React/Angular |
|
||||
| **Ferramentas** | `*-cli`, `*-scripts`, `*-tools` | Scripts de build, migrations |
|
||||
| **Configs** | `*-config`, `*-eslint-config` | Configs compartilhadas |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Mapear Dependências Internas
|
||||
|
||||
Identificar o grafo de dependências entre pacotes internos:
|
||||
|
||||
```bash
|
||||
# Para cada package.json, listar deps internas (que apontam para workspace:)
|
||||
rg '"workspace:' --include='package.json' -l | while read f; do
|
||||
echo "=== $(jq -r .name "$f") ==="
|
||||
jq -r '.dependencies // {} | to_entries[] | select(.value | startswith("workspace:")) | .key' "$f"
|
||||
jq -r '.devDependencies // {} | to_entries[] | select(.value | startswith("workspace:")) | .key' "$f"
|
||||
done
|
||||
```
|
||||
|
||||
Anotar:
|
||||
|
||||
- Quais pacotes são **folha** (não dependem de outros internos)
|
||||
- Quais são **raiz** (ninguém depende deles — geralmente apps)
|
||||
- Quais são **núcleo** (muitos dependem deles — geralmente libs compartilhadas)
|
||||
|
||||
---
|
||||
|
||||
## PASSO 4 — Mapear Arquitetura de Cada Pacote
|
||||
|
||||
Para cada pacote relevante, identificar a estrutura interna:
|
||||
|
||||
```bash
|
||||
# Visão geral rápida (2 níveis de profundidade)
|
||||
eza --tree --level=2 --icons --group-directories-first <caminho-do-pacote>/src/
|
||||
# ou
|
||||
tree -L 2 -I node_modules <caminho-do-pacote>/src/
|
||||
```
|
||||
|
||||
Padrões comuns a procurar:
|
||||
|
||||
| Diretório | Responsabilidade típica |
|
||||
|-----------|----------------------|
|
||||
| `src/routes/` ou `src/api/` | Endpoints/rotas HTTP |
|
||||
| `src/services/` | Lógica de negócio |
|
||||
| `src/models/` ou `src/entities/` | Modelos de dados |
|
||||
| `src/utils/` ou `src/helpers/` | Funções utilitárias |
|
||||
| `src/types/` ou `src/typings/` | Definições de tipos TS |
|
||||
| `src/schemas/` | Schemas de validação (Zod, Joi) |
|
||||
| `src/migrations/` | Migrações de banco |
|
||||
| `src/components/` | Componentes de UI (frontend) |
|
||||
| `src/composables/` ou `src/hooks/` | Lógica reutilizável (Vue/React) |
|
||||
| `src/stores/` | Gerenciamento de estado |
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Identificar Pontos de Entrada e Exportações
|
||||
|
||||
```bash
|
||||
# Encontrar exports públicos de cada pacote
|
||||
rg "export " --include='index.ts' --include='index.tsx' -l
|
||||
|
||||
# Encontrar entry points no package.json
|
||||
fd package.json --max-depth 3 --type f --exec sh -c 'echo "$(jq -r .name {}):" && jq "{main, module, types, exports}" {}'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PASSO 6 — Documentar o Mapa
|
||||
|
||||
Produzir um resumo estruturado com:
|
||||
|
||||
```markdown
|
||||
# Mapa do Monorepo: <nome>
|
||||
|
||||
## Gerenciador: pnpm | npm | yarn
|
||||
## Build System: tsc | turbo | nx
|
||||
|
||||
## Pacotes
|
||||
|
||||
### Libs Compartilhadas
|
||||
- `@org/types` → tipos compartilhados (depende de: nenhum)
|
||||
- `@org/utils` → funções utilitárias (depende de: @org/types)
|
||||
|
||||
### Aplicações
|
||||
- `@org/api` → backend Express (depende de: @org/types, @org/utils)
|
||||
- `@org/web` → frontend Vue (depende de: @org/types)
|
||||
|
||||
## Fluxo de dados
|
||||
Descrever como os dados fluem entre pacotes.
|
||||
|
||||
## Scripts importantes
|
||||
- `pnpm build` → Build de todos os pacotes
|
||||
- `pnpm dev` → Inicia dev server
|
||||
- `pnpm test` → Roda testes
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
|
||||
- [ ] O gerenciador de pacotes e workspace strategy estão identificados?
|
||||
- [ ] Todos os pacotes foram categorizados (lib/app/tool)?
|
||||
- [ ] O grafo de dependências internas foi mapeado?
|
||||
- [ ] Os pontos de entrada de cada pacote estão claros?
|
||||
- [ ] A arquitetura interna dos pacotes principais foi documentada?
|
||||
- [ ] Scripts de build/dev/test foram identificados?
|
||||
|
||||
## Referências
|
||||
|
||||
- Rules: `.agent/rules/typescript-sem-any.global.md`
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
|
|
@ -1,118 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: adicionar-ajuda
|
||||
description: Adicionar ou atualizar botão de ajuda e documentação em telas (Frontend)
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Adicionar Ajuda em Telas
|
||||
|
||||
Este workflow automatiza a inserção do botão de ajuda e a criação do arquivo de documentação correspondente sempre que uma tela é criada ou modificada de forma significativa.
|
||||
|
||||
O objetivo da ajuda é **auxiliar o usuário final a compreender e utilizar corretamente a aplicação**, explicando o funcionamento da tela de forma clara e objetiva.
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
- O arquivo alvo deve ser um componente de interface (`.tsx` para React ou `.vue` para Vue).
|
||||
- O projeto deve possuir um componente de ajuda (ex: `BotaoAjuda`, `HelpButton` ou equivalente) disponível para uso na interface.
|
||||
- Caso não exista, criar um componente reutilizável que exiba o conteúdo do `.ajuda.md` em modal ou drawer.
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o Componente Alvo
|
||||
|
||||
Determine qual arquivo representa a tela principal ou modal que está sendo criado ou editado.
|
||||
|
||||
- React → `.tsx`
|
||||
- Vue → `.vue`
|
||||
|
||||
### 2. Verificar Existência de Ajuda
|
||||
|
||||
Procure por um arquivo de ajuda com o mesmo nome do componente e sufixo indicativo de ajuda (ex.: `.ajuda.md`) localizado na mesma pasta.
|
||||
|
||||
Exemplo:
|
||||
|
||||
```
|
||||
|
||||
TelaCadastroUsuario.tsx
|
||||
TelaCadastroUsuario.ajuda.md
|
||||
|
||||
```
|
||||
|
||||
ou
|
||||
|
||||
```
|
||||
|
||||
TelaCadastroUsuario.vue
|
||||
TelaCadastroUsuario.ajuda.md
|
||||
|
||||
````
|
||||
|
||||
### 3. Criar ou Atualizar o Arquivo Markdown
|
||||
|
||||
Se o arquivo `.ajuda.md` não existir, crie-o utilizando o template básico abaixo.
|
||||
|
||||
O conteúdo deve ser escrito **pensando no usuário final**, explicando de forma simples como utilizar a tela.
|
||||
|
||||
A documentação deve incluir, quando aplicável:
|
||||
|
||||
- **Objetivo da tela**
|
||||
- **Descrição dos botões**
|
||||
- **Descrição dos campos de formulário**
|
||||
- **Regras de preenchimento e validações**
|
||||
- **Fluxo esperado de uso**
|
||||
- **Contexto técnico ou legal**, quando relevante para o entendimento da funcionalidade
|
||||
|
||||
Template inicial:
|
||||
|
||||
```markdown
|
||||
# Ajuda: [Nome da Tela]
|
||||
|
||||
## Objetivo da Tela
|
||||
|
||||
Explique de forma simples para que serve esta tela dentro do sistema.
|
||||
|
||||
## Botões
|
||||
|
||||
- **Salvar**: grava as informações preenchidas.
|
||||
- **Cancelar**: descarta as alterações realizadas.
|
||||
- **Excluir**: remove o registro atual do sistema.
|
||||
|
||||
## Campos do Formulário
|
||||
|
||||
- **Nome**: informe o nome completo do responsável.
|
||||
- **Data de Vistoria**: data em que a vistoria foi realizada.
|
||||
- **Observações**: campo livre para registrar informações adicionais.
|
||||
|
||||
## Fluxo de Uso
|
||||
|
||||
1. Preencha os campos obrigatórios.
|
||||
2. Revise as informações inseridas.
|
||||
3. Clique em **Salvar** para registrar os dados no sistema.
|
||||
|
||||
## Informações Técnicas ou Legais (quando aplicável)
|
||||
|
||||
Explique regras técnicas, normas ou exigências legais relacionadas à funcionalidade da tela.
|
||||
````
|
||||
|
||||
### 4. Posicionamento do Botão de Ajuda
|
||||
|
||||
O botão deve ser inserido de forma consistente e não pode interferir na interface da aplicação.
|
||||
|
||||
#### Telas / Páginas
|
||||
|
||||
* O botão deve ficar na **parte inferior esquerda da página**.
|
||||
* Deve respeitar espaçamento suficiente das bordas da interface.
|
||||
* **Não pode sobrepor nenhum componente da tela.**
|
||||
* **Não pode ficar oculto ou sobreposto pela barra de módulos da aplicação.**
|
||||
* Ajustar `margin`, `padding` ou `z-index` quando necessário para garantir visibilidade adequada.
|
||||
|
||||
#### Modais e Diálogos
|
||||
|
||||
* O botão deve ficar na **parte inferior esquerda do modal**.
|
||||
* Preferencialmente no rodapé do modal ou em um container equivalente.
|
||||
* **Não pode sobrepor botões ou ações do modal.**
|
||||
* Garantir espaçamento adequado para não interferir na usabilidade.
|
||||
|
||||
|
||||
|
|
@ -1,263 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: aprimorar-IA
|
||||
description: Consolidar aprendizados da conversa atual e evoluir continuamente as regras, skills e fluxos da aplicação
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Aprimorar Conhecimento da Aplicação
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Garantir que **toda decisão tomada** seja imediatamente incorporada ao conhecimento estruturado da aplicação, mantendo o sistema de rules, workflows e skills **coerente, atualizado, não redundante e sem contradições**.
|
||||
|
||||
Este workflow é **obrigatório** e deve ser executado sempre que houver qualquer definição nova.
|
||||
|
||||
---
|
||||
|
||||
## Artefatos de Conhecimento
|
||||
|
||||
O conhecimento do agente está organizado em **três tipos de artefatos**, cada um com responsabilidade distinta:
|
||||
|
||||
| Artefato | Diretório | Responsabilidade |
|
||||
|----------|-----------|------------------|
|
||||
| **Rules** | `.agent/rules/` | Restrições e convenções que o agente **deve respeitar sempre** |
|
||||
| **Workflows** | `.agent/workflows/` | Processos sequenciais com passos numerados para tarefas bem definidas |
|
||||
| **Skills** | `.agent/skills/` | Guias operacionais completos e reutilizáveis para tarefas complexas recorrentes |
|
||||
| **Memória** | `.agent/memoria/` | Registros históricos, contexto do projeto, fatos e decisões importantes |
|
||||
|
||||
### Diferenças entre os artefatos
|
||||
|
||||
| Critério | Rule | Workflow | Skill | Memória |
|
||||
|----------|------|----------|-------|---------|
|
||||
| **Formato** | Regra declarativa | Passos sequenciais | Guia prático com templates | Diários, ADRs, documentação de contexto puro |
|
||||
| **Quando usar** | Aplicada **automaticamente** em todo contexto | Acionado por **comando** (`/workflow`) | Consultado **sob demanda** ao iniciar tarefa complexa | Consultado **para restaurar contexto** e entender escopo |
|
||||
| **Exemplos** | "Nunca usar `any`" | "/migracao_banco" | "Criar função api2 end-to-end" | "ADR de transição para Nuxt 4", "Dicionário de dados" |
|
||||
| **Escopo** | Restrição transversal | Processo pontual | Padrão operacional completo | Registro histórico e base factual |
|
||||
|
||||
### Regra de escolha
|
||||
|
||||
- Se é uma **restrição** que vale sempre → **Rule**
|
||||
- Se é um **processo com etapas** que o usuário aciona → **Workflow**
|
||||
- Se é um **guia operacional** com templates e checklist para tarefas complexas → **Skill**
|
||||
- Se o conteúdo serve como **referência cruzada** durante tarefas → **Skill**
|
||||
- Se é um **registro de estado, decisão técnica importante ou compreensão do domínio temporal** → **Memória**
|
||||
|
||||
---
|
||||
|
||||
## 1️⃣ Análise do Contexto Atual (Obrigatória)
|
||||
|
||||
É obrigatório:
|
||||
|
||||
- Revisar integralmente a conversa atual.
|
||||
- Identificar:
|
||||
- Regras de negócio novas ou alteradas.
|
||||
- Padrões técnicos definidos.
|
||||
- Convenções estabelecidas.
|
||||
- Decisões arquiteturais.
|
||||
- Ajustes de comportamento do sistema ou do agente.
|
||||
|
||||
Para cada item identificado, classificar obrigatoriamente:
|
||||
|
||||
- Já existe artefato correspondente (rule, workflow ou skill) → **ATUALIZAR**
|
||||
- Existe parcialmente → **REFATORAR**
|
||||
- Não existe → **CRIAR**
|
||||
- Impacta múltiplas áreas → **PROPAGAR**
|
||||
|
||||
---
|
||||
|
||||
## 2️⃣ Atualização das Rules (Obrigatória)
|
||||
|
||||
### Regras inegociáveis:
|
||||
|
||||
- Toda nova regra **DEVE** ser registrada.
|
||||
- Nenhuma regra pode existir apenas na conversa.
|
||||
- É **PROIBIDO** deixar conhecimento implícito.
|
||||
|
||||
### Estrutura obrigatória:
|
||||
|
||||
- Um arquivo = um único assunto.
|
||||
- Nome claro em `kebab-case`.
|
||||
- Limite máximo: ~10.000 caracteres.
|
||||
|
||||
### É obrigatório:
|
||||
|
||||
- Evitar duplicação de conteúdo.
|
||||
- Atualizar regras antigas quando substituídas.
|
||||
- Remover ou ajustar regras conflitantes.
|
||||
- Garantir consistência semântica entre arquivos.
|
||||
|
||||
### Estrutura obrigatória da rule:
|
||||
|
||||
```md
|
||||
# Nome da Regra
|
||||
|
||||
## Contexto
|
||||
Quando se aplica.
|
||||
|
||||
## Regra
|
||||
Definição objetiva e obrigatória.
|
||||
|
||||
## Exemplos
|
||||
✅ Correto
|
||||
❌ Incorreto
|
||||
|
||||
## Impacto
|
||||
Problema que evita.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3️⃣ Atualização dos Workflows (Obrigatória quando aplicável)
|
||||
|
||||
Sempre que houver processo repetível identificado:
|
||||
|
||||
* Criar ou atualizar workflow em `.agent/workflows/`.
|
||||
|
||||
### Obrigatório:
|
||||
|
||||
* Frontmatter com `description`.
|
||||
* Passos numerados.
|
||||
* Clareza operacional (sem ambiguidade).
|
||||
* Comandos executáveis quando possível.
|
||||
* Uso de `// turbo` para comandos seguros.
|
||||
|
||||
---
|
||||
|
||||
## 4️⃣ Atualização das Skills (Obrigatória quando aplicável)
|
||||
|
||||
Sempre que um padrão operacional complexo for definido, refinado ou corrigido:
|
||||
|
||||
* Criar ou atualizar skill em `.agent/skills/<nome-da-skill>/SKILL.md`.
|
||||
|
||||
### Quando atualizar uma skill:
|
||||
|
||||
- Nova regra afeta o padrão operacional descrito na skill (ex: nova convenção de tipagem afeta `criar-funcao-api2`)
|
||||
- Novo workflow introduz etapas que complementam ou substituem uma skill
|
||||
- Um erro recorrente revela que a skill está incompleta ou desatualizada
|
||||
- Uma decisão arquitetural muda o fluxo descrito na skill
|
||||
|
||||
### Estrutura obrigatória da skill:
|
||||
|
||||
```md
|
||||
---
|
||||
name: nome-da-skill
|
||||
description: >
|
||||
Descrição em uma linha do que a skill faz.
|
||||
---
|
||||
|
||||
# Skill: Nome Descritivo
|
||||
|
||||
Parágrafo de contexto explicando quando usar.
|
||||
|
||||
## PASSO N — Título do Passo
|
||||
Instruções com código, regras e padrões.
|
||||
|
||||
## Checklist Final
|
||||
- [ ] Item de verificação
|
||||
|
||||
## Referências
|
||||
- Regras: `.agent/rules/xxx.md`
|
||||
- Workflow: `.agent/workflows/xxx.md`
|
||||
```
|
||||
|
||||
### Regras de organização:
|
||||
|
||||
- Uma skill por diretório: `.agent/skills/<nome>/SKILL.md`
|
||||
- Skills globais são identificadas pelo campo `scope: global` no frontmatter
|
||||
- Nome do diretório em `kebab-case`
|
||||
- A skill **não deve duplicar** conteúdo de rules — referencia-as via seção `Referências`
|
||||
- A skill **pode consolidar** conhecimento de múltiplas rules e workflows em um guia unificado
|
||||
- Templates de código devem estar na própria skill (não em arquivos separados, a menos que sejam muito grandes)
|
||||
|
||||
### Skills globais (distribuídas via `atualizar-agente.global.sh`):
|
||||
|
||||
| Skill | Escopo |
|
||||
|-------|--------|
|
||||
| `mapear-codigo-fonte` | Mapear e navegar a estrutura de qualquer monorepo TS |
|
||||
| `diagnosticar-erros-build` | Diagnosticar erros de build em cascata entre pacotes |
|
||||
| `documentar-decisao-tecnica` | Registrar decisões técnicas como ADRs |
|
||||
|
||||
### Skills de projeto (criadas localmente em cada monorepo):
|
||||
|
||||
Cada projeto pode criar skills adicionais específicas em `.agent/skills/<nome>/SKILL.md`.
|
||||
Essas skills focam nos padrões e domínios exclusivos daquele projeto.
|
||||
|
||||
Exemplos de skills de projeto:
|
||||
|
||||
| Skill | Escopo |
|
||||
|-------|--------|
|
||||
| `criar-funcao-api` | Função de API end-to-end (comuns → back → front) |
|
||||
| `criar-componente-vue3` | Componente Vue 3 com padrões obrigatórios do projeto |
|
||||
| `consultar-banco-knex` | Queries Knex com padrões de leitura/escrita/JSONB |
|
||||
| `implementar-permissoes` | Controle de acesso específico do domínio |
|
||||
|
||||
---
|
||||
|
||||
## 5️⃣ Atualização da Memória (Obrigatória quando aplicável)
|
||||
|
||||
Sempre que decisões críticas sobre a arquitetura da aplicação ou o contexto do domínio precisarem ser arquivadas temporária ou permanentemente de maneira descritiva (e não diretamente injetável em código ou regra de lint):
|
||||
|
||||
* Registre o novo documento no formato adequado mantendo a pasta limpa em `.agent/memoria/`.
|
||||
* Exemplo: Manter diário de pendências (`diario-pendencias-modulo-x.md`) ou ADR (`adr-001-migracao-nuxt-4.md`).
|
||||
* Atenção! Tudo que puder ser abstraído para formato técnico estrito deve virar **Skill** ou **Rule**. Use a Memória apenas como extensão de base factual.
|
||||
|
||||
---
|
||||
|
||||
## 6️⃣ Revisão de Impacto (Dirigida por Grafo)
|
||||
|
||||
Quando um artefato é alterado, a revisão deve ser **dirigida**, não exaustiva.
|
||||
|
||||
### Processo:
|
||||
|
||||
1. Identificar o artefato alterado
|
||||
2. Consultar a seção `Referências` do artefato para encontrar dependentes diretos
|
||||
3. Verificar consistência APENAS entre o artefato alterado e seus dependentes
|
||||
4. Se uma inconsistência for encontrada, propagar para o próximo nível
|
||||
|
||||
### Regras de escopo:
|
||||
|
||||
| Se alterou... | Revisar... |
|
||||
|---|---|
|
||||
| Uma **Rule** | Workflows e skills que a **referenciam** |
|
||||
| Um **Workflow** | Skills que o **referenciam** |
|
||||
| Uma **Skill** | Rules e workflows na seção Referências |
|
||||
| **Memória/ADR** | Nada — memória é registro, não dependência |
|
||||
|
||||
### É PROIBIDO:
|
||||
|
||||
* Revisar artefatos **sem relação** com a mudança
|
||||
* Afirmar que "tudo foi revisado" sem listar quais artefatos foram verificados
|
||||
* Criar artefatos sem verificar se já existe um com o mesmo escopo
|
||||
|
||||
### A revisão DEVE verificar:
|
||||
|
||||
* Não existem regras conflitantes entre o artefato alterado e seus dependentes
|
||||
* Referências cruzadas continuam válidas (arquivos existem, nomes corretos)
|
||||
* Skills refletem fielmente as rules que referenciam
|
||||
* Não há duplicação de conteúdo entre artefatos
|
||||
|
||||
---
|
||||
|
||||
## 7⃣ Verificação Final (Checklist obrigatório)
|
||||
|
||||
Só é permitido encerrar se TODOS forem verdadeiros:
|
||||
|
||||
* [ ] Artefatos dependentes do alterado foram revisados
|
||||
* [ ] Não existe conflito entre artefatos revisados
|
||||
* [ ] Não existe duplicação de conteúdo
|
||||
* [ ] Nenhuma regra ficou implícita
|
||||
* [ ] Referências cruzadas estão válidas
|
||||
* [ ] Estrutura está organizada por assunto
|
||||
* [ ] Skills referenciam (não duplicam) rules
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Regra Suprema
|
||||
|
||||
> Se existir qualquer dúvida, conflito ou inconsistência
|
||||
> entre o artefato alterado e seus dependentes,
|
||||
> o trabalho é considerado **INCOMPLETO**.
|
||||
|
||||
A revisão é dirigida, não opcional.
|
||||
|
|
@ -1,46 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: atualizar-agente
|
||||
description: Aplica atualizações globais para o agente de IA
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Atualizar Agente Global
|
||||
|
||||
## Objetivo
|
||||
|
||||
Baixar e aplicar a versão mais recente das rules, workflows e tools globais a partir do servidor central (`paiol.idz.one`).
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Baixar o script de atualização (se ainda não existir)
|
||||
|
||||
```bash
|
||||
curl -fL# "https://paiol.idz.one/desenvolvimento/agent-ia/atualizar-agente-global.sh" -o .agent/atualizar-agente.global.sh
|
||||
chmod +x .agent/atualizar-agente.global.sh
|
||||
```
|
||||
|
||||
### 2. Executar o script
|
||||
|
||||
// turbo
|
||||
|
||||
```bash
|
||||
sh .agent/atualizar-agente.global.sh
|
||||
```
|
||||
|
||||
O script possui auto-atualização: na primeira execução, ele baixa sua própria versão mais recente e re-executa automaticamente.
|
||||
|
||||
### 3. Verificar resultado
|
||||
|
||||
Confirmar que os arquivos foram atualizados sem duplicações:
|
||||
|
||||
```bash
|
||||
find .agent/ -name "*.md" -o -name "*.sh" | sort
|
||||
```
|
||||
|
||||
Resultado esperado: todos os arquivos `.md` devem ter o sufixo `.global` (exceto `tools.md`).
|
||||
|
||||
### 4. Revisar mudanças (quando aplicável)
|
||||
|
||||
Se houve alterações significativas nas rules ou workflows, executar `/aprimorar-IA` para validar consistência do sistema de conhecimento.
|
||||
|
|
@ -1,144 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: comercial
|
||||
description: Criar uma descrição comercial das funcionalidades e do sistema
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Criar Descrição Comercial
|
||||
|
||||
Este workflow gera uma descrição comercial de funcionalidades ou do sistema completo, escrita na pasta `./COMERCIAL/`. Cada módulo ou funcionalidade gera um arquivo separado com o padrão `./COMERCIAL/<nome-do-modulo>.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar as funcionalidades solicitadas
|
||||
|
||||
Perguntar ao usuário quais módulos ou funcionalidades devem ser descritos. Se o pedido for genérico ("descreva o sistema"), listar os módulos principais do projeto e confirmar o escopo antes de redigir.
|
||||
|
||||
### 2. Levantar contexto real de cada funcionalidade
|
||||
|
||||
Antes de escrever, ler o código-fonte e os componentes relacionados para entender:
|
||||
|
||||
- Qual **problema real** a funcionalidade resolve?
|
||||
- Quem são os **usuários diretos**? (consultor ambiental, gestor ambiental, gestor público, técnico de campo)
|
||||
- Qual é o **fluxo de uso** no dia a dia?
|
||||
- Quais **dificuldades operacionais** existiam antes da solução?
|
||||
|
||||
### 3. Redigir a descrição comercial
|
||||
|
||||
Para cada funcionalidade, produzir **dois blocos de texto** no arquivo `./COMERCIAL/<nome-do-modulo>.md`:
|
||||
|
||||
#### Bloco A — Descrição Resumida (2 a 4 linhas)
|
||||
|
||||
Texto curto que pode ser usado em páginas de divulgação, apresentações rápidas ou materiais institucionais.
|
||||
|
||||
Estrutura obrigatória:
|
||||
- **Linha 1**: o problema/dificuldade que existe sem a solução
|
||||
- **Linha 2-3**: como funciona na prática (ação do usuário, sem termos técnicos de TI)
|
||||
- **Linha 4**: o impacto concreto (ganho mensurável)
|
||||
|
||||
*Exemplo:*
|
||||
> Sem controle digital, registros de campo ficam em cadernos e planilhas isoladas — sujeitos a perda e erro de transcrição.
|
||||
> Com a solução, o técnico registra os dados direto no celular, mesmo sem internet, com validação automática.
|
||||
> Isso elimina falhas de preenchimento e garante rastreabilidade completa para auditorias.
|
||||
|
||||
#### Bloco B — Descrição Detalhada
|
||||
|
||||
Texto mais completo (5 a 15 linhas) que aprofunda o funcionamento e os diferenciais. Deve incluir:
|
||||
|
||||
- Cenário de uso realista (quem faz o quê, quando e onde)
|
||||
- Recursos técnicos relevantes explicados de forma acessível (offline, sincronização, alertas automáticos)
|
||||
- Benefícios encadeados (causa → efeito)
|
||||
- **Implicações legais ou normativas** (quando aplicável): se a funcionalidade tem relação com legislação, normas regulatórias ou resoluções de órgãos competentes, **citar expressamente** a norma ou obrigação legal. Isso fortalece o argumento comercial e demonstra que a solução atende requisitos reais de conformidade.
|
||||
|
||||
> **Regra de siglas**: toda sigla usada pela primeira vez no texto deve vir acompanhada do nome por extenso. Exemplo: "ANA (Agência Nacional de Águas e Saneamento Básico)". Nas ocorrências seguintes, pode-se usar apenas a sigla.
|
||||
|
||||
### 4. Revisar contra o checklist de qualidade
|
||||
|
||||
Antes de entregar, validar **cada bloco** contra as restrições abaixo:
|
||||
|
||||
- [ ] O texto do Resumo começa pelo problema, não pela funcionalidade?
|
||||
- [ ] Há pelo menos um cenário de uso prático (quem, onde, como)?
|
||||
- [ ] Os parágrafos são curtos (2 a 4 linhas) com uma ideia principal cada?
|
||||
- [ ] A linguagem soa como alguém que vive o problema, não como manual de software?
|
||||
- [ ] Está **LIVRE** de jargões de TI e termos em inglês sem tradução?
|
||||
- [ ] Toda **sigla** está acompanhada do nome por extenso na primeira ocorrência?
|
||||
- [ ] Está **LIVRE** de termos vazios ("Inovador", "Eficiente", "Solução completa", "O presente projeto")?
|
||||
- [ ] Está **LIVRE** do padrão repetitivo "O sistema permite / A funcionalidade permite / A ferramenta permite"?
|
||||
- [ ] As frases variam de estrutura? (alternando "Na prática...", "Com isso...", "Isso reduz...", "Como resultado...")
|
||||
- [ ] Quando há implicação legal ou normativa, a norma/lei/resolução está **citada e destacada** no texto?
|
||||
- [ ] O texto é compreensível pelo **público-alvo do produto** sem conhecimento de TI?
|
||||
|
||||
---
|
||||
|
||||
## Público-Alvo
|
||||
|
||||
Todo texto produzido por este workflow deve ser compreensível pelo **público-alvo do produto**. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
|
||||
|
||||
Regra geral: nenhum dos perfis-alvo tem obrigação de conhecer termos de tecnologia. A linguagem deve ser **acessível, direta e sem jargões de TI**.
|
||||
|
||||
---
|
||||
|
||||
## Regras de Tom e Vocabulário
|
||||
|
||||
| ✅ Usar | ❌ Evitar |
|
||||
|---|---|
|
||||
| "Na prática, o técnico..." | "O sistema permite..." |
|
||||
| "Com isso, a equipe..." | "A solução inovadora..." |
|
||||
| "Isso elimina..." | "O presente projeto visa..." |
|
||||
| "Como resultado..." | "Dessa forma..." |
|
||||
| "Sem a solução, o gestor precisa..." | "A ferramenta oferece..." |
|
||||
| "Entregamos controle sobre..." | "Nossa solução oferece..." |
|
||||
| "O gestor ganha visibilidade de..." | "A plataforma disponibiliza..." |
|
||||
| "página de divulgação" | "landing page" |
|
||||
| "frase de abertura" | "hook" |
|
||||
| "chamada para ação" | "CTA" (isolado, sem explicação) |
|
||||
| "texto persuasivo" | "copywriting" |
|
||||
| "linha do tempo, publicações" | "feed" |
|
||||
|
||||
**Tom geral**: profissional, direto, sem burocracia institucional. O texto deve parecer escrito por quem constrói a solução e entende a operação do dia a dia do cliente.
|
||||
|
||||
---
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
Cada módulo ou funcionalidade deve gerar **um arquivo próprio** dentro da pasta `./COMERCIAL/`.
|
||||
|
||||
**Regra de nomeação do arquivo:**
|
||||
- Usar o nome do módulo em **kebab-case** (minúsculo, separado por hifens)
|
||||
|
||||
O arquivo `./COMERCIAL/<nome-do-modulo>.md` deve seguir esta estrutura:
|
||||
|
||||
```markdown
|
||||
# [Nome do Módulo]
|
||||
|
||||
## [Nome da Sub-funcionalidade]
|
||||
|
||||
### Resumo
|
||||
|
||||
[Bloco A — 2 a 4 linhas: problema → solução → impacto]
|
||||
|
||||
### Detalhamento
|
||||
|
||||
[Bloco B — 5 a 15 linhas: cenário real + técnico acessível + legal]
|
||||
|
||||
---
|
||||
|
||||
## [Próxima Sub-funcionalidade]
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
- Workflow: `.agent/workflows/orcamento.global.md` (texto para documentos de orçamento e proposta — apresentação + lista de funcionalidades)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing digital — LinkedIn, Instagram, WhatsApp, E-mail)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md` (para documentação técnica, não comercial)
|
||||
|
|
@ -1,189 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: criar-fluxograma
|
||||
description: Criar ou atualizar uma página de fluxograma interativo em qualquer sistema
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Criar Fluxograma de Decisões
|
||||
|
||||
Este workflow cria uma **página interativa de fluxograma** em qualquer aplicação web, usando Mermaid.js instalado como dependência do projeto.
|
||||
|
||||
## Princípio
|
||||
|
||||
O fluxograma é um artefato vivo. Ele documenta visualmente:
|
||||
- Os **pontos de entrada** do processo
|
||||
- As **decisões** tomadas em cada etapa
|
||||
- Os **registros gerados** (banco, fila, log, e-mail, etc.)
|
||||
- As **proteções e regras** que governam os estados
|
||||
|
||||
Deve ser mantido sempre sincronizado com o código real.
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Levantar o processo a ser documentado
|
||||
|
||||
Ler os arquivos de código relevantes para entender:
|
||||
|
||||
- Quais são os **pontos de entrada**? (funções de API, eventos, webhooks, ações do usuário)
|
||||
- Quais são as **decisões**? (condições `if/else`, guards, validações)
|
||||
- Quais são os **efeitos colaterais**? (gravações em banco, envios de e-mail, filas, logs)
|
||||
- Quais são os **estados possíveis**? (status, notas, flags, etapas)
|
||||
- Existe **hierarquia ou prioridade** entre estados?
|
||||
|
||||
### 2. Organizar os diagramas
|
||||
|
||||
Dividir o processo em **um diagrama por ponto de entrada**.
|
||||
|
||||
Cada diagrama deve mostrar:
|
||||
- Todos os caminhos possíveis, inclusive early returns e casos de erro
|
||||
- Registros gerados com ícone indicativo (ex: 🗄️ banco, 📧 e-mail, 🚫 bloqueio)
|
||||
- Decisões claramente separadas por ramificações
|
||||
|
||||
Definir a orientação de cada diagrama:
|
||||
- `flowchart TD` → vertical (melhor para fluxos sequenciais com poucas ramificações)
|
||||
- `flowchart LR` → horizontal (melhor para pipelines e fluxos com muitas etapas em linha)
|
||||
|
||||
### 3. Instalar o Mermaid
|
||||
|
||||
Instalar como dependência do projeto antes de qualquer implementação:
|
||||
|
||||
```bash
|
||||
# npm
|
||||
npm install mermaid
|
||||
|
||||
# pnpm
|
||||
pnpm add mermaid
|
||||
```
|
||||
|
||||
### 4. Criar a página com Mermaid
|
||||
|
||||
Adaptar à plataforma do projeto (Vue, React, HTML puro, etc.), mas garantir:
|
||||
|
||||
#### Importação
|
||||
|
||||
```js
|
||||
import mermaid from 'mermaid';
|
||||
```
|
||||
|
||||
#### Inicialização com tema institucional
|
||||
|
||||
Adaptar as cores para a identidade visual do projeto:
|
||||
|
||||
```js
|
||||
mermaid.initialize({
|
||||
startOnLoad: false,
|
||||
theme: 'base',
|
||||
themeVariables: {
|
||||
primaryColor: '#4F46E5', // cor primária do projeto
|
||||
primaryTextColor: '#1F2933',
|
||||
primaryBorderColor: '#3730A3', // variação mais escura da primária
|
||||
lineColor: '#6B7280',
|
||||
secondaryColor: '#E0E7FF', // variação clara da primária
|
||||
tertiaryColor: '#F3F4F6',
|
||||
fontFamily: "'Inter', 'Segoe UI', sans-serif",
|
||||
fontSize: '13px',
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
#### Renderização de cada diagrama
|
||||
|
||||
```js
|
||||
// Para cada diagrama:
|
||||
const { svg } = await mermaid.render(`id-unico-${idx}`, codigoMermaid);
|
||||
container.innerHTML = svg;
|
||||
|
||||
// Tornar o SVG responsivo:
|
||||
const svgEl = container.querySelector('svg');
|
||||
if (svgEl) {
|
||||
svgEl.style.width = '100%';
|
||||
svgEl.style.height = 'auto';
|
||||
svgEl.removeAttribute('width');
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Registrar a rota e adicionar acesso
|
||||
|
||||
- Registrar a rota `/fluxograma` (ou equivalente) no sistema de rotas do projeto
|
||||
- Adicionar botão de navegação na tela de administração ou dashboard
|
||||
|
||||
---
|
||||
|
||||
## Padrão de sintaxe Mermaid
|
||||
|
||||
### Tipos de nó por semântica
|
||||
|
||||
| Situação | Sintaxe | Exemplo |
|
||||
|---|---|---|
|
||||
| Início / Fim | `A(["Texto"])` | `A(["Início"])` |
|
||||
| Decisão | `B{"Condição?"}` | `B{"Nota é ativa?"}` |
|
||||
| Ação / Processo | `C["Texto"]` | `C["Consulta banco"]` |
|
||||
| Registro em banco | `D[("🗄️ Grava dado")]` | `D[("🗄️ Grava 203_neutro")]` |
|
||||
| E-mail / notificação | `E["📧 Envia e-mail"]` | `E["📧 Agenda na fila"]` |
|
||||
| Bloqueio / guard | `F["🚫 Retorna sem ação"]` | `F["🚫 Nota ativa, ignora"]` |
|
||||
| Proteção / regra | `G["🛡️ Regra aplicada"]` | `G["🛡️ SQL CASE protege"]` |
|
||||
|
||||
### Regras para evitar erros de parsing
|
||||
|
||||
```
|
||||
✅ Nós com parênteses → usar aspas:
|
||||
A["Texto (com parênteses)"]
|
||||
|
||||
✅ Labels de arestas com texto especial → usar aspas:
|
||||
A -- "Label aqui" --> B
|
||||
|
||||
✅ Emojis → sempre dentro de aspas:
|
||||
A["🗄️ Grava registro"]
|
||||
|
||||
❌ Não usar < > dentro de labels sem aspas
|
||||
❌ Não usar & diretamente — usar texto alternativo
|
||||
```
|
||||
|
||||
### Cores de destaque para nós
|
||||
|
||||
```
|
||||
style NomeNo fill:#22C55E,color:#fff → verde sucesso
|
||||
style NomeNo fill:#DC2626,color:#fff → vermelho erro
|
||||
style NomeNo fill:#F59E0B,color:#000 → amarelo alerta
|
||||
style NomeNo fill:#4F46E5,color:#fff → cor institucional (adaptar ao projeto)
|
||||
style NomeNo fill:#6B7280,color:#fff → cinza neutro
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Validação antes de finalizar
|
||||
|
||||
- [ ] Cada ponto de entrada tem seu próprio diagrama?
|
||||
- [ ] Todos os registros gerados estão mapeados?
|
||||
- [ ] Os caminhos de bloqueio e early return estão visíveis?
|
||||
- [ ] A hierarquia de estados (se existir) está documentada?
|
||||
- [ ] A data de atualização está registrada na página?
|
||||
- [ ] A sintaxe Mermaid está correta (sem erros de parsing)?
|
||||
- [ ] O SVG está responsivo (largura 100%, sem width fixo)?
|
||||
|
||||
---
|
||||
|
||||
## Manutenção
|
||||
|
||||
Sempre que o processo mudar:
|
||||
|
||||
1. Identificar qual diagrama é afetado
|
||||
2. Atualizar o código Mermaid correspondente
|
||||
3. Atualizar a data de atualização na página
|
||||
4. Se houver novo estado ou proteção, documentar na legenda
|
||||
|
||||
---
|
||||
|
||||
## Referência de implementação
|
||||
|
||||
Se o projeto já possuir um fluxograma implementado, usar como referência.
|
||||
Caso contrário, seguir os passos acima para criar a primeira implementação.
|
||||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Skill: `.agent/skills/documentar-decisao-tecnica.global/SKILL.md` (para decisões que geram fluxogramas)
|
||||
|
|
@ -1,105 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: documentar-regras-negocio
|
||||
description: Criar ou atualizar o arquivo {modulo}.regras-negocio.md co-localizado com um módulo TypeScript e garantir consistência entre código e documentação
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Documentar Regras de Negócio de um Módulo
|
||||
|
||||
Use este workflow com `/documentar-regras-negocio.global` para criar ou atualizar o arquivo
|
||||
`{modulo}.regras-negocio.md` de qualquer módulo TypeScript com lógica de negócio não-trivial.
|
||||
|
||||
---
|
||||
|
||||
[1] Ler o módulo TypeScript completamente
|
||||
|
||||
Identificar e anotar:
|
||||
|
||||
- Nome do arquivo e localização exata
|
||||
- Funções exportadas e suas responsabilidades
|
||||
- Todos os `if` que representam critérios de decisão
|
||||
- Campos lidos e gravados (especialmente JSONB e campos de status)
|
||||
- Queries de banco: tabelas acessadas, filtros aplicados, joins
|
||||
- Caminhos alternativos (revisão manual, erros, skips)
|
||||
- Dependências externas (filas, e-mails, serviços)
|
||||
|
||||
---
|
||||
|
||||
[2] Verificar se já existe um `.regras-negocio.md`
|
||||
|
||||
```bash
|
||||
ls $(dirname <arquivo>)/*.regras-negocio.md 2>/dev/null
|
||||
```
|
||||
|
||||
- **Existe** → ler e identificar o que está desatualizado → ir para o passo [4]
|
||||
- **Não existe** → ir para o passo [3]
|
||||
|
||||
---
|
||||
|
||||
[3] Criar o arquivo `.regras-negocio.md`
|
||||
|
||||
Nomenclatura: `{nome-sem-_inicial}.regras-negocio.md` na mesma pasta do módulo.
|
||||
|
||||
Preencher com o template da skill `documentar-regras-negocio.global`:
|
||||
- Contexto
|
||||
- Critérios de Entrada
|
||||
- Regras de Processamento (numeradas)
|
||||
- Casos de Revisão Manual
|
||||
- Estratégia de Saída / Fusão de Campos
|
||||
- Dependências Externas
|
||||
|
||||
---
|
||||
|
||||
[4] Adicionar ou verificar a referência no `.ts`
|
||||
|
||||
Garantir que a primeira linha útil do arquivo TypeScript seja:
|
||||
|
||||
```typescript
|
||||
// Regras de negócio: ver {modulo}.regras-negocio.md
|
||||
```
|
||||
|
||||
Se já existia e está correto → sem mudança necessária.
|
||||
|
||||
---
|
||||
|
||||
[5] Simplificar JSDoc que duplicam as regras
|
||||
|
||||
Percorrer cada função do módulo:
|
||||
|
||||
- JSDoc com lista de regras de negócio → substituir por referência ao `.md`
|
||||
- Manter apenas `@param` e `@returns` com informação técnica precisa
|
||||
- Comentários inline (`//`) explicando lógica pontual são aceitos → manter
|
||||
|
||||
---
|
||||
|
||||
[6] Verificar consistência — código ↔ `.md`
|
||||
|
||||
Para cada regra listada no `.md`:
|
||||
|
||||
- [ ] Existe `if` correspondente no código
|
||||
- [ ] A ordem de avaliação bate entre `.md` e código
|
||||
- [ ] Campos com separador de concatenação batem entre `.md` e código
|
||||
- [ ] `null` como neutro está implementado corretamente (`!= null`)
|
||||
- [ ] Queries têm `orderBy` quando a posição dos resultados importa
|
||||
|
||||
---
|
||||
|
||||
[7] Validar tipagem
|
||||
|
||||
// turbo
|
||||
```bash
|
||||
npx tsc --noEmit
|
||||
```
|
||||
|
||||
Zero erros = concluído.
|
||||
|
||||
---
|
||||
|
||||
[8] Registrar no sistema de conhecimento (se regras novas)
|
||||
|
||||
Se o workflow revelou novos padrões de negócio relevantes ao projeto:
|
||||
|
||||
- Criar ou atualizar ADR em `.agent/memoria/` via skill `documentar-decisao-tecnica`
|
||||
- Verificar se alguma rule precisa ser atualizada
|
||||
|
|
@ -1,209 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: marketing
|
||||
description: Criar peças de marketing digital para funcionalidades e módulos do sistema
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Criar Peças de Marketing
|
||||
|
||||
Este workflow gera peças de marketing digital prontas para uso em canais como LinkedIn, Instagram, WhatsApp e E-mail. O resultado é salvo na pasta `./COMERCIAL/` junto ao arquivo comercial do módulo correspondente, ou em arquivo separado `./COMERCIAL/<nome-do-modulo>-marketing.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
|
||||
O agente deve atuar como **especialista em marketing digital voltado para o setor do produto (venda entre empresas)**, aplicando técnicas comprovadas de texto persuasivo e engajamento.
|
||||
|
||||
## Público-Alvo das Peças
|
||||
|
||||
As peças serão lidas pelo **público-alvo do produto**. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
|
||||
|
||||
Regra geral: nenhum dos perfis-alvo tem obrigação de conhecer termos de tecnologia. A linguagem deve ser **acessível, direta e sem jargões de TI**. Siglas devem vir acompanhadas do nome por extenso na primeira ocorrência.
|
||||
|
||||
---
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
Antes de gerar peças de marketing, o arquivo comercial do módulo (`./COMERCIAL/<nome-do-modulo>.md`) já deve existir com os blocos A (Resumo) e B (Detalhamento). Se não existir, aplicar primeiro o workflow `/comercial.global`.
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o módulo e o canal
|
||||
|
||||
Perguntar ao usuário:
|
||||
- Qual módulo ou funcionalidade será divulgado?
|
||||
- Quais canais deseja? (LinkedIn, Instagram, WhatsApp, E-mail, ou todos)
|
||||
|
||||
### 2. Ler o contexto comercial
|
||||
|
||||
Ler o arquivo `./COMERCIAL/<nome-do-modulo>.md` para extrair:
|
||||
- O problema e impacto (Bloco A)
|
||||
- Os cenários de uso e referências legais (Bloco B)
|
||||
|
||||
### 3. Redigir as peças de marketing
|
||||
|
||||
---
|
||||
|
||||
## Princípios de Engajamento
|
||||
|
||||
1. **Abrir com uma provocação ou dado concreto** — nunca com o nome do produto. A primeira frase deve fazer o leitor parar de rolar as publicações.
|
||||
2. **Falar a língua do decisor** — usar o vocabulário do público-alvo do produto, não termos de tecnologia.
|
||||
3. **Criar urgência sem desespero** — mostrar o custo da inação (multa, retrabalho, perda de prazo) sem tom alarmista.
|
||||
4. **Fechar com uma chamada para ação clara** — sempre direcionar para o próximo passo: demonstração, contato, link ou agendamento.
|
||||
5. **Adaptar ao canal** — o mesmo conteúdo não funciona igual no LinkedIn, Instagram, WhatsApp e e-mail. Cada peça deve respeitar o formato e tom do canal.
|
||||
|
||||
---
|
||||
|
||||
## Técnicas Obrigatórias
|
||||
|
||||
| Técnica | Como aplicar |
|
||||
|---|---|
|
||||
| **Frase de abertura impactante** | Pergunta retórica, dado alarmante ou afirmação provocativa nas primeiras 10 palavras |
|
||||
| **Prova social** | Mencionar o tipo de cliente que já usa (prefeituras, indústrias, consultorias), sem inventar números |
|
||||
| **Contraste antes/depois** | Mostrar o cenário ruim (planilha, papel, multa) ao lado do cenário com a solução |
|
||||
| **Especificidade** | Trocar "economiza tempo" por "reduz 4 horas semanais de consolidação manual" |
|
||||
| **Chamada para ação conectada ao problema** | A frase final deve se conectar ao problema apresentado, não ser genérica |
|
||||
|
||||
---
|
||||
|
||||
## Formatos por Canal
|
||||
|
||||
### LinkedIn (Carrossel ou Post)
|
||||
|
||||
- 3 a 5 parágrafos curtos (1-2 linhas cada)
|
||||
- Abrir com frase de abertura forte na primeira linha (antes do "ver mais")
|
||||
- Usar quebras de linha para facilitar a leitura
|
||||
- Emojis como marcadores (⚠️, ✅, 📊), no máximo 1 por parágrafo
|
||||
- Fechar com chamada para ação + hashtags relevantes (no máximo 5)
|
||||
|
||||
*Exemplo de LinkedIn:*
|
||||
|
||||
```
|
||||
⚠️ Sua equipe ainda controla [processo crítico] em planilha?
|
||||
|
||||
A maioria das operações só descobre o problema
|
||||
quando o órgão regulador notifica.
|
||||
Nessa hora, a multa já está lavrada.
|
||||
|
||||
Com [nome do produto], cada registro é feito digitalmente
|
||||
com cálculo automático. Se o valor ultrapassar
|
||||
o limite autorizado, um alerta dispara na hora.
|
||||
|
||||
✅ Controle em tempo real
|
||||
✅ Alertas automáticos de limite
|
||||
✅ Relatórios prontos para auditoria
|
||||
|
||||
Quer ver funcionando? Fale com a gente.
|
||||
|
||||
#Hashtag1 #Hashtag2 #Hashtag3
|
||||
```
|
||||
|
||||
### Instagram (Stories / Reels / Carrossel)
|
||||
|
||||
- Frases de impacto (no máximo 15 palavras por slide)
|
||||
- Visual > texto — cada slide deve ter uma ideia única
|
||||
- Usar contrastes visuais (❌ antes / ✅ depois)
|
||||
- Chamada para ação no último slide: "Link na bio" ou "Fale com nosso time"
|
||||
|
||||
*Exemplo de Instagram:*
|
||||
|
||||
```
|
||||
Slide 1: "Sua operação está em conformidade?"
|
||||
Slide 2: ❌ "Planilhas manuais. Registros esquecidos. Consolidação no fim do mês."
|
||||
Slide 3: ⚠️ "[Citação legal relevante]"
|
||||
Slide 4: ✅ "Registro digital com cálculo automático."
|
||||
Slide 5: ✅ "Alerta em tempo real quando o limite é atingido."
|
||||
Slide 6: "Conheça [nome do produto]. Link na bio."
|
||||
```
|
||||
|
||||
### WhatsApp (Mensagem de prospecção)
|
||||
|
||||
- No máximo 4 linhas + 1 chamada para ação
|
||||
- Tom pessoal, sem parecer mensagem em massa
|
||||
- Mencionar o contexto do destinatário (setor, dificuldade conhecida)
|
||||
|
||||
*Exemplo de WhatsApp:*
|
||||
|
||||
```
|
||||
Oi [Nome], tudo bem?
|
||||
|
||||
Vi que vocês trabalham com [contexto do destinatário].
|
||||
Queria mostrar como estamos ajudando operações como a de vocês
|
||||
a [benefício principal da solução].
|
||||
|
||||
Posso te mandar um vídeo rápido de 2 min mostrando como funciona?
|
||||
```
|
||||
|
||||
### E-mail (Prospecção ou Nutrição)
|
||||
|
||||
- Assunto: direto, com gancho de dificuldade real (no máximo 60 caracteres)
|
||||
- Corpo: 3 parágrafos curtos — problema → solução → chamada para ação
|
||||
- Evitar formatação visual pesada — preferir texto limpo e direto
|
||||
|
||||
*Exemplo de E-mail:*
|
||||
|
||||
```
|
||||
Assunto: [Pergunta sobre dificuldade real do destinatário]
|
||||
|
||||
Olá [Nome],
|
||||
|
||||
[Parágrafo 1: descrever a dificuldade que o destinatário provavelmente enfrenta]
|
||||
|
||||
[Parágrafo 2: como a solução resolve, com dados concretos]
|
||||
|
||||
Se fizer sentido, posso agendar 15 minutos para mostrar como funciona
|
||||
na prática. Qual o melhor horário para você?
|
||||
|
||||
[Assinatura]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Checklist de Qualidade
|
||||
|
||||
Antes de finalizar qualquer peça, validar:
|
||||
|
||||
- [ ] A primeira frase **provoca, questiona ou surpreende**?
|
||||
- [ ] O texto fala a **língua do decisor** (público-alvo do produto), não de desenvolvedor?
|
||||
- [ ] Existe **contraste claro** entre o cenário sem e com a solução?
|
||||
- [ ] Os benefícios são **específicos** (números, tempo, ações concretas)?
|
||||
- [ ] Tem **chamada para ação clara** e conectada ao problema apresentado?
|
||||
- [ ] O tom está **adaptado ao canal** (LinkedIn ≠ WhatsApp ≠ E-mail)?
|
||||
- [ ] Está **LIVRE** de jargões de TI e termos em inglês sem tradução?
|
||||
- [ ] Toda **sigla** está acompanhada do nome por extenso na primeira ocorrência?
|
||||
- [ ] Menções legais são usadas como **argumento de urgência**, não como decoração?
|
||||
|
||||
---
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
O resultado deve ser salvo em `./COMERCIAL/<nome-do-modulo>-marketing.md` ou adicionado ao final do arquivo comercial existente, conforme preferência do usuário.
|
||||
|
||||
```markdown
|
||||
# Marketing — [Nome do Módulo]
|
||||
|
||||
## LinkedIn
|
||||
|
||||
[Post pronto para publicação]
|
||||
|
||||
## Instagram
|
||||
|
||||
[Roteiro de slides para carrossel ou legenda para post]
|
||||
|
||||
## WhatsApp
|
||||
|
||||
[Mensagem de prospecção]
|
||||
|
||||
## E-mail
|
||||
|
||||
[Template de prospecção ou nutrição]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (gera os blocos A e B que alimentam o marketing)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
|
|
@ -1,134 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: orcamento
|
||||
description: Criar texto de orçamento pronto para copiar e colar em peças de orçamento/proposta
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Criar Texto de Orçamento
|
||||
|
||||
Este workflow gera textos prontos para **copiar e colar dentro de documentos de orçamento e propostas comerciais**. O resultado é salvo na pasta `./COMERCIAL/` com o sufixo `-orcamento` (ex: `./COMERCIAL/<nome-do-modulo>-orcamento.md`).
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
## Público-Alvo
|
||||
|
||||
O documento de orçamento será lido pelo **público-alvo do produto**. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
|
||||
|
||||
A linguagem deve ser **acessível, direta e sem jargões de TI**. Siglas devem vir acompanhadas do nome por extenso na primeira ocorrência.
|
||||
|
||||
---
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
Antes de gerar o texto de orçamento, o agente deve ler o código-fonte do módulo para entender quais funcionalidades existem de fato. Se já existir o arquivo comercial (`./COMERCIAL/<nome-do-modulo>.md`), usá-lo como base para extrair contexto.
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o módulo
|
||||
|
||||
Perguntar ao usuário qual módulo ou funcionalidade será orçado.
|
||||
|
||||
### 2. Levantar contexto
|
||||
|
||||
Ler o código-fonte e os componentes relacionados para mapear:
|
||||
- Quais **funcionalidades** o módulo oferece de fato?
|
||||
- Existe **legislação ou norma** relevante que o módulo atende?
|
||||
- Quem são os **usuários diretos**? (consultor, gestor, técnico de campo)
|
||||
|
||||
### 3. Redigir o texto de orçamento
|
||||
|
||||
O texto deve ser **autocontido** — pronto para colar diretamente dentro de um documento de orçamento sem necessidade de edição. Estrutura obrigatória:
|
||||
|
||||
#### Apresentação do Módulo (2 a 4 linhas)
|
||||
|
||||
Texto que descreve o módulo de forma direta, mostrando **o que ele faz** e **qual problema resolve**. Se houver legislação ou norma relevante, **citar aqui** para demonstrar conformidade regulatória e fortalecer o argumento.
|
||||
|
||||
Regras:
|
||||
- Começar pelo que o módulo entrega, não pelo problema
|
||||
- Se houver lei/norma relevante, citar com nome por extenso e artigo
|
||||
- Tom confiante e profissional — adequado para documento formal
|
||||
- Não usar termos de tecnologia
|
||||
|
||||
#### Lista de Funcionalidades
|
||||
|
||||
Após a apresentação, listar as funcionalidades do módulo em formato de **itens curtos** (1 a 2 linhas cada). Cada item deve:
|
||||
|
||||
- Descrever **o que a funcionalidade faz na prática** (ação concreta, não conceito abstrato)
|
||||
- Ser compreensível por alguém que **nunca viu o sistema**
|
||||
- Ser suficientemente específico para justificar o valor cobrado
|
||||
|
||||
Regras para cada item:
|
||||
- Começar com o **nome da funcionalidade** em negrito
|
||||
- Seguir com uma descrição curta do que ela faz
|
||||
- Opcionalmente, incluir o benefício direto entre parênteses ou traço
|
||||
|
||||
### 4. Revisar contra o checklist de qualidade
|
||||
|
||||
Antes de entregar, validar:
|
||||
|
||||
- [ ] A apresentação do módulo é autocontida e compreensível isoladamente?
|
||||
- [ ] Cada funcionalidade está descrita de forma concreta (o que faz, não o que é)?
|
||||
- [ ] O texto está **pronto para copiar e colar** sem edição?
|
||||
- [ ] Está **LIVRE** de jargões de TI e termos em inglês sem tradução?
|
||||
- [ ] Toda **sigla** está acompanhada do nome por extenso na primeira ocorrência?
|
||||
- [ ] Legislação/norma relevante está **citada na apresentação** com nome por extenso?
|
||||
- [ ] O tom é profissional e adequado para um documento formal de orçamento?
|
||||
- [ ] É compreensível pelo **público-alvo do produto** sem conhecimento de TI?
|
||||
|
||||
---
|
||||
|
||||
## Regras de Redação
|
||||
|
||||
- **Sem jargões de TI**: trocar termos técnicos por equivalentes acessíveis (ex: "painel" em vez de "dashboard", "código QR" em vez de "QR Code")
|
||||
- **Siglas por extenso**: toda sigla deve vir acompanhada do nome por extenso na primeira ocorrência
|
||||
- **Tom formal mas acessível**: adequado para um documento de orçamento/proposta enviado a um diretor ou secretário
|
||||
- **Funcionalidades concretas**: "Registro de leituras com cálculo automático de volume", não "Módulo de coleta de dados parametrizável"
|
||||
|
||||
---
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
O arquivo `./COMERCIAL/<nome-do-modulo>-orcamento.md` deve seguir esta estrutura:
|
||||
|
||||
```markdown
|
||||
# [Nome do Módulo]
|
||||
|
||||
[Apresentação do módulo — 2 a 4 linhas com legislação relevante, se aplicável]
|
||||
|
||||
## Funcionalidades incluídas
|
||||
|
||||
- **[Nome da funcionalidade 1]**: [descrição curta do que faz na prática]
|
||||
- **[Nome da funcionalidade 2]**: [descrição curta do que faz na prática]
|
||||
- **[Nome da funcionalidade 3]**: [descrição curta do que faz na prática]
|
||||
- ...
|
||||
```
|
||||
|
||||
*Exemplo:*
|
||||
|
||||
```markdown
|
||||
# [Nome do Módulo]
|
||||
|
||||
[Apresentação do módulo com descrição direta do que faz, qual problema resolve e,
|
||||
se aplicável, legislação ou norma relevante citada por extenso.]
|
||||
|
||||
## Funcionalidades incluídas
|
||||
|
||||
- **[Funcionalidade 1]**: [descrição curta do que faz]
|
||||
- **[Funcionalidade 2]**: [descrição curta do que faz]
|
||||
- **[Funcionalidade 3]**: [descrição curta do que faz]
|
||||
- ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (descrição comercial detalhada — Resumo e Detalhamento)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing digital)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
|
|
@ -1,71 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: otimizar-codigos
|
||||
description: Agente especialista em limpeza e refatoração de código
|
||||
scope: global
|
||||
updatedAt: "2026-06-03"
|
||||
---
|
||||
|
||||
Você é um agente especialista em limpeza e refatoração de código para projetos TypeScript, Vue 3, TSX e JSX.
|
||||
|
||||
Sua missão é melhorar a legibilidade, organização e manutenção do código, sem alterar o comportamento funcional.
|
||||
|
||||
## Regras principais
|
||||
|
||||
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).
|
||||
|
||||
## 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.
|
||||
|
|
@ -1,204 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: reels
|
||||
description: Criar cadeia de roteiros de Reels para divulgação de funcionalidades e módulos
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Criar Roteiros de Reels
|
||||
|
||||
Este workflow gera **cadeias de roteiros de Reels** (vídeos curtos de 30 a 60 segundos) organizados por tema. Os roteiros são escritos em tom provocativo, informal e direto — prontos para gravar falando para a câmera ou com narração em off. O resultado é salvo em `./COMERCIAL/<nome-do-modulo>-reels.md`.
|
||||
|
||||
É **OBRIGATÓRIO** seguir a regra global de Escrita Natural (`escrita-natural.global.md`) em toda produção textual deste workflow.
|
||||
|
||||
---
|
||||
|
||||
## Público-Alvo dos Reels
|
||||
|
||||
Os vídeos serão assistidos pelo **público-alvo do produto**. O agente deve identificar quem são os usuários e decisores com base no contexto do projeto.
|
||||
|
||||
Regra geral: a linguagem deve ser **coloquial, direta e sem jargões de TI**. Siglas devem vir acompanhadas do nome por extenso quando citadas pela primeira vez.
|
||||
|
||||
---
|
||||
|
||||
## Pré-requisitos
|
||||
|
||||
Antes de gerar roteiros, o agente deve entender as funcionalidades reais do módulo. Se já existir o arquivo comercial (`./COMERCIAL/<nome-do-modulo>.md`), usá-lo como base. Caso contrário, ler o código-fonte para mapear o que o módulo entrega de fato.
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o tema
|
||||
|
||||
Perguntar ao usuário:
|
||||
- Qual módulo ou funcionalidade será o tema dos reels?
|
||||
- Quantos roteiros deseja na cadeia? (padrão: 6)
|
||||
- Algum tom específico? (provocativo, educativo, humorístico)
|
||||
|
||||
### 2. Levantar contexto
|
||||
|
||||
Mapear:
|
||||
- Quais **funcionalidades** do módulo geram mais impacto visual e prático?
|
||||
- Quais **dores reais** o público-alvo enfrenta sem a solução?
|
||||
- Existe **legislação ou norma** que possa ser usada como argumento de urgência?
|
||||
- Quais **comparações do dia a dia** fazem sentido para o público?
|
||||
|
||||
### 3. Redigir a cadeia de roteiros
|
||||
|
||||
Cada cadeia deve conter **4 a 8 roteiros**, todos conectados pelo mesmo tema mas com abordagens diferentes. Cada roteiro segue a estrutura abaixo.
|
||||
|
||||
---
|
||||
|
||||
## Estrutura de um Roteiro
|
||||
|
||||
Cada roteiro deve ter entre **6 e 12 frases curtas**, organizadas em 4 blocos:
|
||||
|
||||
### Bloco 1 — Abertura (1-2 frases)
|
||||
|
||||
A primeira frase é a mais importante. Ela decide se o espectador para ou rola.
|
||||
|
||||
Técnicas obrigatórias (usar pelo menos uma por roteiro):
|
||||
|
||||
| Técnica | Exemplo |
|
||||
|---|---|
|
||||
| **Provocação direta** | "Se você ainda faz isso manual… tá perdendo dinheiro." |
|
||||
| **Referência pop** | "Tá mais perdido que timeline de fofoca da Virgínia?" |
|
||||
| **Formato "Plot twist"** | "Plot twist: você perde cliente não é pelo preço…" |
|
||||
| **Convocação** | "Se sua proposta fosse convocada hoje… ela jogaria?" |
|
||||
| **Contraste chocante** | "Expectativa: vou organizar meus processos. Realidade: caos." |
|
||||
| **Pergunta retórica** | "Quantas horas você perdeu esse mês montando relatório?" |
|
||||
| **Afirmação polêmica** | "A maioria dos consultores está jogando dinheiro fora." |
|
||||
|
||||
### Bloco 2 — Dor / Cenário ruim (2-3 frases)
|
||||
|
||||
Descrever o cenário do público-alvo SEM a solução. Usar linguagem do dia a dia — como se estivesse conversando com um colega.
|
||||
|
||||
Regras:
|
||||
- Frases curtas e ritmadas (máximo 12 palavras por frase)
|
||||
- Usar repetição para ritmo ("proposta pra um lado, orçamento pra outro…")
|
||||
- Descrever ações reais, não conceitos ("anota no papel, perde foto, esquece detalhe")
|
||||
- Pode usar humor leve e ironia
|
||||
|
||||
### Bloco 3 — Virada / Solução (2-3 frases)
|
||||
|
||||
Apresentar o produto como a virada. O nome do produto aparece aqui — naturalmente, sem parecer propaganda.
|
||||
|
||||
Regras:
|
||||
- O produto é mencionado **uma única vez**, pelo nome
|
||||
- Descrever o que o produto faz em **ações concretas**, não em conceitos
|
||||
- Usar verbos de ação: "monta", "registra", "envia", "centraliza"
|
||||
- Mostrar resultado imediato: "menos retrabalho", "mais fechamento"
|
||||
|
||||
### Bloco 4 — Fechamento / Desafio (1-2 frases)
|
||||
|
||||
Fechar com uma pergunta ou desafio que provoque o espectador a agir.
|
||||
|
||||
Técnicas:
|
||||
- **Desafio direto**: "Quer ser titular ou continuar no banco?"
|
||||
- **Escolha binária**: "Você decide em qual nível quer jogar."
|
||||
- **Pergunta provocativa**: "Você tá otimizando ou só se ocupando?"
|
||||
- **Chamada para ação suave**: "Começa a jogar no nível profissional."
|
||||
|
||||
---
|
||||
|
||||
## Estilos de Roteiro
|
||||
|
||||
Cada cadeia deve variar os estilos para manter o conteúdo diverso. O agente deve usar **pelo menos 4 estilos diferentes** numa cadeia de 6 roteiros.
|
||||
|
||||
| Estilo | Descrição | Ritmo |
|
||||
|---|---|---|
|
||||
| **Plot twist** | Começa com uma crença comum e inverte | Surpreendente |
|
||||
| **Mais perdido que...** | Analogia cômica + caos do dia a dia | Humorístico |
|
||||
| **Convocação** | Metáfora de seleção/time/jogo | Competitivo |
|
||||
| **Raiz vs Smart** | Dois perfis contrastados | Comparativo |
|
||||
| **Tempo é dinheiro** | Foco em produtividade e custo de oportunidade | Urgência |
|
||||
| **Expectativa vs Realidade** | Contraste entre o plano e o caos | Identificação |
|
||||
| **Se eu te contasse** | Narrativa de revelação progressiva | Curiosidade |
|
||||
| **Checklist do fracasso** | Lista irônica do que NÃO fazer | Irônico |
|
||||
|
||||
---
|
||||
|
||||
## Regras de Entonação
|
||||
|
||||
O roteiro deve indicar **como falar** cada trecho. Usar marcações simples:
|
||||
|
||||
| Marcação | Significado |
|
||||
|---|---|
|
||||
| Texto normal | Tom de conversa, olhando pra câmera |
|
||||
| *Texto em itálico* | Tom irônico ou de provocação |
|
||||
| **Texto em negrito** | Ênfase, falar mais forte |
|
||||
| `[pausa]` | Pausa dramática de 1-2 segundos |
|
||||
| `[rápido]` | Falar em ritmo acelerado |
|
||||
| `[sussurrando]` | Tom baixo, como se contasse um segredo |
|
||||
|
||||
---
|
||||
|
||||
## Regras de Redação
|
||||
|
||||
- **Frases curtas**: máximo 15 palavras por frase. Idealmente 8-12
|
||||
- **Sem jargões de TI**: trocar termos técnicos por equivalentes do dia a dia
|
||||
- **Tom coloquial**: "tá", "pra", "gente", "bobo" são permitidos e desejáveis
|
||||
- **Referências culturais**: usar quando fizerem sentido para o público (futebol, reality, memes do momento). Marcar como `[ref: atualizar]` se a referência puder ficar datada
|
||||
- **Uma ideia por frase**: cada frase deve ser compreensível isoladamente
|
||||
- **Sem "Olá pessoal"**: nunca abrir com saudação genérica
|
||||
- **Produto natural**: o nome do produto aparece no máximo 1 vez por roteiro, no bloco de solução
|
||||
- **Siglas**: toda sigla usada pela primeira vez deve vir acompanhada do nome por extenso
|
||||
|
||||
---
|
||||
|
||||
## Checklist de Qualidade
|
||||
|
||||
Antes de entregar, validar **cada roteiro**:
|
||||
|
||||
- [ ] A primeira frase **para o scroll**? (provocação, surpresa ou identificação)
|
||||
- [ ] O cenário da dor é **real e reconhecível** pelo público-alvo?
|
||||
- [ ] O produto aparece **naturalmente**, sem parecer propaganda forçada?
|
||||
- [ ] O fechamento **provoca ação** (pergunta, desafio ou escolha)?
|
||||
- [ ] O roteiro tem entre **6 e 12 frases**?
|
||||
- [ ] Cada frase tem no **máximo 15 palavras**?
|
||||
- [ ] O tom é **coloquial e direto** (não institucional)?
|
||||
- [ ] A cadeia usa **pelo menos 4 estilos diferentes**?
|
||||
- [ ] Está **LIVRE** de jargões de TI?
|
||||
- [ ] O roteiro funciona sendo **falado em voz alta**? (ler em voz alta para validar)
|
||||
|
||||
---
|
||||
|
||||
## Formato de Saída
|
||||
|
||||
O arquivo `./COMERCIAL/<nome-do-modulo>-reels.md` deve seguir esta estrutura:
|
||||
|
||||
```markdown
|
||||
# Reels — [Nome do Módulo]
|
||||
|
||||
> Cadeia de [N] roteiros sobre [tema]
|
||||
> Tom: [provocativo / educativo / humorístico]
|
||||
> Duração média: 30-60 segundos por reel
|
||||
|
||||
---
|
||||
|
||||
## 🎥 Roteiro 1 – "[Título criativo]"
|
||||
|
||||
"[Primeira frase — abertura impactante]
|
||||
|
||||
[Bloco de dor — 2-3 frases curtas]
|
||||
|
||||
[Bloco de solução — 2-3 frases com o produto]
|
||||
|
||||
[Fechamento — pergunta ou desafio]"
|
||||
|
||||
---
|
||||
|
||||
## 🎥 Roteiro 2 – "[Título criativo]"
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/comercial.global.md` (descrição comercial detalhada — base de contexto)
|
||||
- Workflow: `.agent/workflows/marketing.global.md` (peças de marketing por canal)
|
||||
- Regra global: `.agent/rules/escrita-natural.global.md` (padrão obrigatório de redação)
|
||||
|
|
@ -1,257 +0,0 @@
|
|||
---
|
||||
type: workflow
|
||||
name: ux
|
||||
description: Revisar e otimizar UX de componentes e telas Vue (Frontend)
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
# Workflow: Revisão de UX
|
||||
|
||||
Guia de revisão e otimização de interfaces Vue 3 + Vuetify 3 no ecossistema Azteca — para usuários corporativos com baixa familiaridade tecnológica.
|
||||
|
||||
---
|
||||
|
||||
## Perfil do Usuário
|
||||
|
||||
O público-alvo das interfaces é corporativo e diversificado em experiência técnica:
|
||||
|
||||
- Gestores públicos e ambientais
|
||||
- Técnicos de campo
|
||||
- Consultores ambientais
|
||||
- Operadores administrativos
|
||||
|
||||
**Premissa central**: o usuário não tem familiaridade avançada com tecnologia. A interface precisa ser autoexplicativa, sem dependência de treinamento prévio.
|
||||
|
||||
---
|
||||
|
||||
## Paleta de Cores Institucional
|
||||
|
||||
Cor base: `#688C00` (verde floresta). Três escalas derivadas: **Verde floresta** (primária), **Âmbar terroso** (apoio/aviso), **Cinza musgo** (neutros). Semânticas independentes para garantir reconhecimento universal.
|
||||
|
||||
### Escala primária — Verde floresta
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-primaria-bg` | `#EEF3D0` | 50 | Fundo de cards destacados, linhas ativas, hover suave |
|
||||
| `--cor-eli-primaria-zebra` | `#F6F9E8` | 30 | Linha zebrada de tabelas (quase branco esverdeado) |
|
||||
| `--cor-eli-primaria-suave` | `#BFC99C` | — | **Cabeçalho de tabela** — sage/olive mudo, sem limão, texto escuro |
|
||||
| `--cor-eli-primaria-clara` | `#D4E290` | 100 | Badges, chips, seleção, fundo de hover em listas |
|
||||
| `--cor-eli-primaria-media` | `#ADCC44` | 200 | Tags, indicadores secundários |
|
||||
| `--cor-eli-primaria-acao` | `#8AAF00` | 400 | Ação secundária, ícones ativos |
|
||||
| `--cor-eli-primaria` | `#688C00` | 600 | **Botões principais, links ativos, destaques — CTA principal** |
|
||||
| `--cor-eli-primaria-escura` | `#4A6500` | 800 | Hover em botões, bordas ativas, títulos com ênfase |
|
||||
| `--cor-eli-primaria-texto` | `#2E3F00` | 900 | Texto escuro sobre fundos claros da paleta primária |
|
||||
|
||||
### Escala de apoio — Âmbar terroso
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-alerta-bg` | `#FAF3DF` | 50 | Fundo de banners de aviso |
|
||||
| `--cor-eli-alerta-clara` | `#F5DC8A` | 100 | Badges de atenção, chips de alerta |
|
||||
| `--cor-eli-alerta` | `#DDB847` | 200 | Ícones de aviso, bordas de alerta |
|
||||
| `--cor-eli-alerta-forte` | `#8C6A00` | 600 | Texto sobre fundo de alerta, status pendente |
|
||||
|
||||
### Escala neutra — Cinza musgo
|
||||
|
||||
| Token | Hex | Stop | Uso |
|
||||
|---|---|---|---|
|
||||
| `--cor-eli-fundo` | `#F2F3EE` | 50 | Background geral de páginas |
|
||||
| `--cor-eli-borda` | `#D5D8CC` | 100 | Bordas padrão de containers |
|
||||
| `--cor-eli-borda-forte` | `#B5BAA8` | 200 | Bordas de foco, divisores |
|
||||
| `--cor-eli-neutro` | `#5E6553` | 600 | Textos secundários, ícones inativos |
|
||||
| `--cor-eli-neutro-escuro` | `#3E4436` | 800 | Texto de label, cabeçalhos de tabela |
|
||||
| `--cor-eli-superficie` | `#FFFFFF` | — | Cards, modais, popovers |
|
||||
|
||||
### Cores semânticas
|
||||
|
||||
| Token | Hex | Uso |
|
||||
|---|---|---|
|
||||
| `--cor-eli-sucesso` | `#2e7d32` | Confirmações, status positivo |
|
||||
| `--cor-eli-sucesso-bg` | `#E8F5E9` | Fundo de mensagens de sucesso |
|
||||
| `--cor-eli-erro` | `#c62828` | Erros, ações destrutivas |
|
||||
| `--cor-eli-erro-bg` | `#FFEBEE` | Fundo de mensagens de erro |
|
||||
| `--cor-eli-info` | `#1565c0` | Informações auxiliares |
|
||||
| `--cor-eli-info-bg` | `#E3F2FD` | Fundo de banners informativos |
|
||||
|
||||
### Regras de contraste
|
||||
|
||||
- Texto sobre `--cor-eli-primaria` (`#688C00`) deve ser **branco** (`#ffffff`) — contraste 4.6:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-bg` (`#EEF3D0`) deve ser `--cor-eli-primaria-texto` (`#2E3F00`) — contraste 12:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-escura` (`#4A6500`) deve ser **branco** (`#ffffff`) — contraste 7.1:1 ✓
|
||||
- Texto sobre `--cor-eli-alerta-bg` (`#FAF3DF`) deve ser `--cor-eli-alerta-forte` (`#8C6A00`) — contraste 5.2:1 ✓
|
||||
- Texto sobre `--cor-eli-primaria-suave` (`#BFC99C`) deve ser `--cor-eli-neutro-escuro` (`#3E4436`) — contraste ~12:1 ✓
|
||||
- **⚠️ Efeito limão**: `--cor-eli-media` (`#ADCC44`) e `--cor-eli-acao` (`#8AAF00`) têm saturação 100% no hue amarelo-verde — **nunca usar como fundo de cabeçalho**. Para fundo verde mudo, usar `--cor-eli-primaria-suave`.
|
||||
- Sempre validar contraste mínimo de **4.5:1** (WCAG AA) para texto normal e **3:1** para texto grande (18px+ ou 14px bold).
|
||||
|
||||
---
|
||||
|
||||
## Passos
|
||||
|
||||
### 1. Identificar o escopo da revisão
|
||||
|
||||
Determinar qual componente, tela ou modal será revisado. Pode ser:
|
||||
|
||||
- Um componente isolado (ex: `EliTabela`, `EliCartao`)
|
||||
- Uma página completa (ex: `PaginaCadastro.vue`)
|
||||
- Um modal ou drawer (ex: `EliTabelaModalFiltroAvancado.vue`)
|
||||
- Uma interação específica (ex: fluxo de filtro, paginação, menu de ações)
|
||||
|
||||
### 2. Mapear o estado atual
|
||||
|
||||
Antes de alterar, entender o que já existe:
|
||||
|
||||
- Ler o template (`<template>`) para entender a estrutura visual
|
||||
- Ler o CSS/SCSS associado para mapear os tokens de design em uso
|
||||
- Identificar quais componentes Vuetify estão sendo utilizados (ex: `v-btn`, `v-dialog`, `v-select`)
|
||||
- Verificar se existem estilos inline que deveriam migrar para classes CSS
|
||||
|
||||
### 3. Avaliar contra os critérios de UX
|
||||
|
||||
Para cada elemento da interface, avaliar:
|
||||
|
||||
#### Clareza
|
||||
|
||||
- [ ] O propósito de cada elemento é óbvio sem instrução?
|
||||
- [ ] Labels e placeholders são descritivos? (ex: "Buscar por nome ou CPF" vs "Buscar")
|
||||
- [ ] Ícones acompanham texto quando a ação não é universalmente reconhecível?
|
||||
- [ ] O estado vazio (empty state) orienta o usuário sobre o próximo passo?
|
||||
|
||||
#### Hierarquia visual
|
||||
|
||||
- [ ] O olho do usuário é guiado para a ação principal primeiro?
|
||||
- [ ] Ações primárias usam `--cor-eli-primaria` (`#688C00`) com destaque?
|
||||
- [ ] Ações secundárias são visuais mas não competem com a primária?
|
||||
- [ ] Ações destrutivas (Excluir, Limpar) usam `--cor-eli-erro` com variante `text` ou `outlined`?
|
||||
|
||||
#### Feedback e estados
|
||||
|
||||
- [ ] Botões têm estados claros de hover (`--cor-eli-primaria-escura`), focus e disabled (`--cor-eli-borda-forte`)?
|
||||
- [ ] Carregamentos exibem indicador visual (spinner, skeleton, barra de progresso)?
|
||||
- [ ] Erros de formulário aparecem próximos ao campo com mensagem descritiva, usando `--cor-eli-erro` + `--cor-eli-erro-bg`?
|
||||
- [ ] Sucesso de operações tem confirmação visual (snackbar, toast, badge) com `--cor-eli-sucesso`?
|
||||
|
||||
#### Densidade e espaçamento
|
||||
|
||||
- [ ] O espaçamento segue múltiplos de 4px (4, 8, 12, 16, 24, 32)?
|
||||
- [ ] Em desktop, o espaço horizontal é bem aproveitado? (ex: grids de 2+ colunas para formulários largos)
|
||||
- [ ] Em mobile, os elementos empilham verticalmente sem quebra visual?
|
||||
- [ ] Modais têm largura proporcional ao conteúdo?
|
||||
|
||||
#### Tipografia
|
||||
|
||||
- [ ] Tamanhos de fonte seguem a escala: 12px (caption), 14px (body), 16px (subtitle), 20px (title), 24px (heading)?
|
||||
- [ ] Textos longos usam `line-height: 1.5` para legibilidade?
|
||||
- [ ] Labels de formulário são visualmente distintos do conteúdo preenchido?
|
||||
|
||||
#### Acessibilidade básica
|
||||
|
||||
- [ ] Elementos interativos têm `aria-label` quando o texto visual não é suficiente?
|
||||
- [ ] Foco via teclado (`Tab`) segue uma ordem lógica?
|
||||
- [ ] Cores não são o único meio de comunicar estado (ex: ícone + cor para erro)?
|
||||
- [ ] Todo texto sobre cor primária ou escura usa branco (`#FFFFFF`)?
|
||||
- [ ] Todo texto sobre `--cor-eli-primaria-bg` usa `--cor-eli-primaria-texto` (`#2E3F00`)?
|
||||
|
||||
### 4. Aplicar padrões Vue/Vuetify do projeto
|
||||
|
||||
Ao implementar melhorias, seguir os padrões do ecossistema:
|
||||
|
||||
#### Componentes Vuetify
|
||||
|
||||
- Usar `v-btn` com variantes do tema (`color="primary"`) em vez de classes CSS manuais para botões
|
||||
- Usar `v-dialog` para modais, `v-menu` para popovers contextuais
|
||||
- Usar `v-text-field`, `v-select` etc. para inputs sempre que possível
|
||||
- Aproveitar props de Vuetify: `density`, `variant`, `rounded`, `elevation`
|
||||
|
||||
#### Iconografia — Lucide (obrigatório)
|
||||
|
||||
Todos os ícones do projeto devem vir exclusivamente da biblioteca **`@lucide/vue`** (dependência já instalada no `package.json`).
|
||||
|
||||
**Proibido**:
|
||||
- SVG inline manual (hardcoded no template)
|
||||
- Ícones de `@mdi/font` ou Material Design Icons em componentes do projeto
|
||||
- Bibliotecas alternativas (Font Awesome, Heroicons, etc.)
|
||||
|
||||
**Como usar**:
|
||||
|
||||
```vue
|
||||
<script lang="ts">
|
||||
import { Filter, Plus, X, Trash2, Eye } from "@lucide/vue"
|
||||
</script>
|
||||
|
||||
<template>
|
||||
<!-- Uso direto como componente -->
|
||||
<Filter :size="18" :stroke-width="2" />
|
||||
|
||||
<!-- Dentro de botão -->
|
||||
<button>
|
||||
<Plus :size="15" :stroke-width="2.5" />
|
||||
Adicionar
|
||||
</button>
|
||||
</template>
|
||||
```
|
||||
|
||||
**Props úteis**: `:size` (número em px), `:stroke-width` (espessura do traço, padrão 2), `:color` (cor do ícone).
|
||||
|
||||
**Catálogo de referência**: https://lucide.dev/icons — buscar pelo nome do ícone em inglês.
|
||||
|
||||
> Os tokens CSS estão documentados nas tabelas da seção **Paleta de Cores Institucional** acima.
|
||||
> No código, usar `var(--token, #fallback)` — sempre com fallback hardcoded em componentes de biblioteca.
|
||||
|
||||
- Classes devem seguir BEM: `eli-componente__elemento--modificador`
|
||||
- Evitar `!important` — resolver especificidade via seletor mais específico
|
||||
- Usar `var(--cor-eli-primaria)` em vez de valores hex hardcoded no CSS dos componentes
|
||||
- Transições padrão: `transition: all 0.2s ease` para hover/focus
|
||||
|
||||
#### Composição de componentes
|
||||
|
||||
- Componentes filhos devem receber dados via `props` e emitir eventos via `$emit`
|
||||
- Evitar acessar o DOM diretamente; preferir `ref` do Vue
|
||||
- Não duplicar CSS entre componentes — extrair para classe utilitária ou CSS do componente pai
|
||||
|
||||
### 5. Implementar melhorias prioritárias
|
||||
|
||||
Ordenar as melhorias por impacto no usuário:
|
||||
|
||||
1. **Crítico**: elementos que causam confusão ou impedem o uso (falta de feedback, botão invisível, estado vazio sem orientação)
|
||||
2. **Alto**: melhorias que reduzem atrito (espaçamento, hierarquia de botões, responsividade)
|
||||
3. **Médio**: refinamentos visuais (transições, micro-animações, consistência de cores)
|
||||
4. **Baixo**: polish (sombras sutis, arredondamentos, tipografia refinada)
|
||||
|
||||
### 6. Validar resultado
|
||||
|
||||
Após implementar:
|
||||
|
||||
- [ ] A tela renderiza sem erros no console?
|
||||
- [ ] Os estados (vazio, carregando, erro, com dados) estão todos cobertos?
|
||||
- [ ] A paleta de cores está coerente com a base `#688C00`?
|
||||
- [ ] Todos os tokens usados estão definidos na escala primária, de apoio ou neutra?
|
||||
- [ ] Nenhuma cor está hardcoded no CSS do componente (usar `var(--token, #fallback)`)?
|
||||
- [ ] Tokens novos têm fallback hardcoded? (ex: `var(--cor-eli-primaria-suave, #BFC99C)`)?
|
||||
- [ ] Contraste de texto validado: branco sobre `--cor-eli-primaria` e `--cor-eli-primaria-escura`; `--cor-eli-neutro-escuro` sobre `--cor-eli-primaria-suave`?
|
||||
- [ ] Nenhuma ação ficou sem feedback visual?
|
||||
- [ ] O layout não quebra em larguras menores que 1024px?
|
||||
- [ ] Componentes Vuetify recebem props de tema (`color`, `variant`) em vez de override CSS?
|
||||
- [ ] Efeito zebra de tabelas tem fundo branco explícito nas linhas normais (para funcionar sobre qualquer fundo de página)?
|
||||
|
||||
---
|
||||
|
||||
## Anti-padrões a evitar
|
||||
|
||||
| ❌ Anti-padrão | ✅ Alternativa |
|
||||
|---|---|
|
||||
| Botão sem label de texto | Botão com ícone + texto, ou `aria-label` descritivo |
|
||||
| Cor vermelha para ação primária | Vermelho apenas para destrutivas; primária usa `--cor-eli-primaria` |
|
||||
| Modal com scroll interno extenso | Dividir em etapas ou usar drawer lateral |
|
||||
| Tabela com 15+ colunas visíveis | Usar o modal de colunas para esconder as menos usadas |
|
||||
| Placeholder como único label | Label fixo acima do campo + placeholder como exemplo |
|
||||
| Ações alinhadas à esquerda em linha de tabela | Ações à direita, próximas ao fim da linha visual |
|
||||
| Toast/snackbar sem ação de fechar | Sempre incluir botão de fechar ou auto-dismiss com tempo suficiente (5s+) |
|
||||
| Estilos inline em `<template>` | Migrar para `<style scoped>` com classe BEM |
|
||||
| Cor hex hardcoded no componente | Usar `var(--cor-eli-primaria)` e demais tokens com fallback |
|
||||
| Texto escuro (`#333`) sobre `--cor-eli-primaria` | Usar branco (`#FFFFFF`) para garantir contraste WCAG AA |
|
||||
| Amarelo/âmbar para sucesso | Âmbar é reservado para **aviso**; sucesso usa `--cor-eli-sucesso` (`#2E7D32`) |
|
||||
| Misturar stops da paleta fora dos tokens | Usar apenas os tokens definidos; nunca interpolar valores avulsos |
|
||||
| Usar `--cor-eli-media` ou `--cor-eli-acao` como fundo de cabeçalho | Usar `--cor-eli-primaria-suave` (`#BFC99C`) — verde mudo sem efeito limão |
|
||||
| `var(--token)` sem fallback em componente de biblioteca | Sempre declarar `var(--token, #valor)` — o projeto destino pode não ter o token atualizado |
|
||||
| Zebra de tabela sem fundo branco explícito nas linhas normais | Declarar `.eli-tabela__tr .eli-tabela__td { background: var(--cor-eli-superficie, #fff) }` antes da regra zebra |
|
||||
Loading…
Add table
Add a link
Reference in a new issue