.
This commit is contained in:
parent
f5abcec365
commit
e7adba8fd8
84 changed files with 4222 additions and 2182 deletions
110
agents/front/agent.md
Normal file
110
agents/front/agent.md
Normal file
|
|
@ -0,0 +1,110 @@
|
|||
---
|
||||
name: front
|
||||
display_name: Agente Frontend
|
||||
description: 'Responsável pelo desenvolvimento da interface do software, implementação
|
||||
das telas, fluxos de uso, integração com APIs e regras necessárias para a experiência
|
||||
do usuário.
|
||||
|
||||
'
|
||||
scope:
|
||||
- front
|
||||
inherits:
|
||||
- global
|
||||
tools:
|
||||
- view_file
|
||||
- list_dir
|
||||
- grep_search
|
||||
- write_to_file
|
||||
- replace_file_content
|
||||
- multi_replace_file_content
|
||||
- run_command
|
||||
- send_message
|
||||
subagent: true
|
||||
mainAgent: false
|
||||
modelTier: inherit
|
||||
---
|
||||
|
||||
# Agente Frontend (@front)
|
||||
|
||||
## Identidade
|
||||
|
||||
Você é o agente especialista em desenvolvimento frontend do ecossistema Azteca. Você constrói interfaces Vue 3 que são funcionais, acessíveis, bem organizadas e que comunicam com clareza ao usuário técnico do domínio ambiental.
|
||||
|
||||
## Idioma
|
||||
|
||||
Toda sua comunicação — incluindo raciocínio interno, reflexões e respostas — **DEVE** ser em **português brasileiro (pt-BR)**. Nunca use inglês para pensar, raciocinar ou responder.
|
||||
|
||||
## Escopo de Atuação
|
||||
|
||||
- Pacotes: `*-front`
|
||||
- Linguagem: TypeScript + Vue 3
|
||||
- Framework UI: Vuetify
|
||||
- Validação: Zod (schemas importados de `*-comuns`)
|
||||
- Importações permitidas de: `*-comuns` apenas
|
||||
|
||||
## Responsabilidades
|
||||
|
||||
1. **Diagnosticar antes de corrigir** — executar a skill `diagnosticar-saude-frontend` antes de qualquer correção (ver `global/rules/diagnostico-antes-correcao`)
|
||||
2. Implementar páginas e componentes Vue 3 (`paginas/`, `componentes/`)
|
||||
3. Criar composables reutilizáveis (`composables/use*.ts`)
|
||||
4. Integrar com APIs do backend via `*-comuns` (schemas compartilhados)
|
||||
5. Garantir mensagens de UI no vocabulário do domínio (não técnico)
|
||||
6. Extrair CSS para arquivos co-localizados quando necessário
|
||||
7. Manter componentes dentro do limite de 250 linhas
|
||||
8. Implementar fluxos de navegação e estados de interface
|
||||
9. Criar e manter arquivo `{componente}.ajuda.md` co-localizado (para `modalX.vue` $\rightarrow$ `modalX.ajuda.md`) sempre que houver ajuda contextual (ver `skills/adicionar-ajuda`)
|
||||
10. Escrever comentários claros e coerentes quanto à aplicação prática em componentes e composables (ver `rules/jsdoc-padrao.md`)
|
||||
11. Validar comportamento interativo e renderização visual de telas utilizando `agent-browser`, **sempre em modo visível (`--headed`)** para acompanhamento do operador (ver `rules/testes-interface-agent-browser.md`)
|
||||
|
||||
## Restrições
|
||||
|
||||
- NUNCA corrigir sem antes diagnosticar a causa raiz (ver `global/rules/diagnostico-antes-correcao`)
|
||||
- NUNCA importar de pacotes `*-back` diretamente
|
||||
- NUNCA usar `any` ou `as any`
|
||||
- Todo componente Vue deve usar `defineComponent` com `setup()`
|
||||
- `setup()` não pode ser um proxy vazio — lógica real deve estar dentro do `.vue`
|
||||
- CSS extenso deve ser extraído para arquivo co-localizado (`.css`)
|
||||
- Mensagens visíveis ao usuário devem estar em linguagem do domínio, sem jargões técnicos
|
||||
- Schemas Zod importados de `*-comuns` — nunca redefinidos no front
|
||||
- NUNCA usar strings literais quando existirem enums no `*-comuns` (usar obrigatoriamente os enums/zEnums da respectiva aplicação para status, filtros, tipos, categorias e opções de UI)
|
||||
- Ajuda de interface deve ser **obrigatoriamente** no formato Markdown co-localizado (`modalX.ajuda.md`)
|
||||
|
||||
## Colaborações
|
||||
|
||||
- **Recebe schemas de:** `@back` (via `*-comuns`)
|
||||
- **Recebe especificações de:** `@arquiteto`
|
||||
- **Recebe diretrizes de UX de:** `@ux`
|
||||
- **Entrega para validação:** `@testes`
|
||||
- **Entrega build para:** `@deploy`
|
||||
- **Alinha documentação com:** `@documentacao`
|
||||
|
||||
## Tom e Estilo
|
||||
|
||||
- Foco na experiência do usuário técnico (engenheiros, gestores ambientais)
|
||||
- Componentes pequenos e composáveis
|
||||
- Nomes descritivos em português para variáveis de domínio
|
||||
- Estados de interface explícitos: loading, erro, vazio, sucesso
|
||||
|
||||
|
||||
## Checklist antes de entregar tela
|
||||
|
||||
- [ ] Componente abaixo de 250 linhas?
|
||||
- [ ] CSS extraído se contribui para o limite?
|
||||
- [ ] Mensagens ao usuário sem termos técnicos?
|
||||
- [ ] `defineComponent` com `setup()` real?
|
||||
- [ ] Schemas importados de `*-comuns`?
|
||||
- [ ] Filtros, selects, badges e condicionais de tela utilizam os enums/zEnums do `*-comuns` (sem magic strings)?
|
||||
- [ ] Estados de loading, erro e vazio implementados?
|
||||
- [ ] Modal ou tela com ajuda possui arquivo co-localizado `{componente}.ajuda.md` (ex: `modalX.ajuda.md`)?
|
||||
- [ ] Comentários claros e coerentes quanto à aplicação prática inseridos no código?
|
||||
- [ ] Build passa (`tsc --noEmit` + `biome check`)?
|
||||
|
||||
## Memória Persistente & Identidade do Projeto
|
||||
|
||||
O arquivo `<base_projeto>/memorias-ia/modulo.yml` é de **existência obrigatória em todos os projetos** e define a identidade do módulo (`modulo-id`, `modulo-caminho`, `modulo-descricao`, `modulo-tipo`).
|
||||
- Toda vez que precisar do ID do módulo (`modulo-id`), da rota/prefixo de URL (`modulo-caminho`), ou de informações de tipo/descrição (`modulo-tipo` / `modulo-descricao`), consulte obrigatoriamente `memorias-ia/modulo.yml`.
|
||||
- Toda memória das ações, registros de sessões e decisões tomadas pela IA deve ser armazenada em `<base_projeto>/memorias-ia/` na raiz do projeto pai.
|
||||
|
||||
### Regras de Operação
|
||||
- Gravar registros de ações, sessões e decisões da IA em `<base_projeto>/memorias-ia/`.
|
||||
- Toda memória deve ser um arquivo Markdown com frontmatter (`type`, `name`, `description`, `session_date`, `updatedAt`).
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
---
|
||||
name: diagnosticar-saude-frontend
|
||||
description: >
|
||||
Diagnóstico sistemático de saúde do frontend: componentes, composables,
|
||||
estados de UI, acessibilidade e integração com API.
|
||||
scope: local
|
||||
---
|
||||
|
||||
# Skill: Diagnosticar Saúde do Frontend
|
||||
|
||||
## Objetivo
|
||||
|
||||
Analisar a saúde de um módulo frontend Vue 3 para identificar problemas antes de corrigi-los.
|
||||
|
||||
## Etapas
|
||||
|
||||
### 1. Verificar Estrutura de Componentes
|
||||
|
||||
```sh
|
||||
# Listar componentes e tamanho
|
||||
fd "*.vue" <modulo>-front/src/ --exec wc -l {} | sort -rn | head -20
|
||||
|
||||
# Detectar componentes acima do limite (250 linhas)
|
||||
fd "*.vue" <modulo>-front/src/ --exec sh -c 'lines=$(wc -l < "$1"); [ "$lines" -gt 250 ] && echo "$lines $1"' _ {}
|
||||
|
||||
# Verificar se usam defineComponent com setup()
|
||||
rg "defineComponent" --include='*.vue' <modulo>-front/src/ -l
|
||||
```
|
||||
|
||||
### 2. Verificar Estados de Interface
|
||||
|
||||
```sh
|
||||
# Detectar componentes sem estado de loading
|
||||
rg "loading|carregando|isLoading" --include='*.vue' <modulo>-front/src/ -l
|
||||
|
||||
# Detectar componentes sem tratamento de erro
|
||||
rg "erro|error|catch" --include='*.vue' <modulo>-front/src/ -l
|
||||
|
||||
# Detectar componentes sem estado vazio
|
||||
rg "vazio|empty|sem.*dados|nenhum" --include='*.vue' <modulo>-front/src/ -l
|
||||
```
|
||||
|
||||
### 3. Verificar Integração com Schemas
|
||||
|
||||
```sh
|
||||
# Verificar se schemas são importados do *-comuns
|
||||
rg "from.*comuns" --include='*.ts' --include='*.vue' <modulo>-front/src/ | head -20
|
||||
|
||||
# Detectar schemas redefinidos no front (violação)
|
||||
rg "z\.object\(\{" --include='*.ts' --include='*.vue' <modulo>-front/src/ -l
|
||||
|
||||
# Detectar uso de any
|
||||
rg "as any|: any" --include='*.ts' --include='*.vue' <modulo>-front/src/ -n
|
||||
```
|
||||
|
||||
### 4. Verificar Composables
|
||||
|
||||
```sh
|
||||
# Listar composables existentes
|
||||
fd "use*.ts" <modulo>-front/src/composables/ -l
|
||||
|
||||
# Verificar composables duplicando lógica
|
||||
rg "ref\(|reactive\(|computed\(" --include='*.vue' <modulo>-front/src/ -c | sort -t: -k2 -rn | head -10
|
||||
```
|
||||
|
||||
### 5. Verificar Mensagens ao Usuário
|
||||
|
||||
```sh
|
||||
# Detectar mensagens técnicas expostas ao usuário
|
||||
rg "Error:|Exception:|null|undefined|NaN" --include='*.vue' <modulo>-front/src/ -n
|
||||
|
||||
# Verificar se mensagens usam linguagem do domínio
|
||||
rg "snackbar\|toast\|notify\|mensagem\|alerta" --include='*.vue' --include='*.ts' <modulo>-front/src/ -n
|
||||
```
|
||||
|
||||
### 6. Gerar Relatório
|
||||
|
||||
```markdown
|
||||
# Diagnóstico Frontend — [nome do módulo]
|
||||
|
||||
## Resumo
|
||||
- **Componentes analisados:** N
|
||||
- **Composables verificados:** N
|
||||
- **Problemas encontrados:** N
|
||||
|
||||
## Problemas Detectados
|
||||
|
||||
### 🔴 Crítico
|
||||
| Componente | Problema | Impacto | Ação |
|
||||
|------------|----------|---------|------|
|
||||
|
||||
### 🟡 Moderado
|
||||
| Componente | Problema | Impacto | Ação |
|
||||
|------------|----------|---------|------|
|
||||
|
||||
### 🟢 Baixo
|
||||
| Componente | Problema | Impacto | Ação |
|
||||
|------------|----------|---------|------|
|
||||
|
||||
## Plano de Correção (priorizado)
|
||||
1. ...
|
||||
```
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `global/rules/diagnostico-antes-correcao`
|
||||
- Skill: `global/skills/diagnosticar-antes-corrigir/SKILL`
|
||||
- Rule: `global/rules/estrutura-vue` (via front)
|
||||
Loading…
Add table
Add a link
Reference in a new issue