ajustes na tabela de consulta
This commit is contained in:
parent
aea3da6585
commit
1446d6225b
78 changed files with 17921 additions and 17580 deletions
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -74,7 +78,7 @@ Para cada item identificado, classificar obrigatoriamente:
|
|||
### Estrutura obrigatória:
|
||||
|
||||
- Um arquivo = um único assunto.
|
||||
- Nome claro em `snake_case`.
|
||||
- Nome claro em `kebab-case`.
|
||||
- Limite máximo: ~10.000 caracteres.
|
||||
|
||||
### É obrigatório:
|
||||
|
|
@ -196,105 +200,64 @@ Exemplos de skills de projeto:
|
|||
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 Arquivo de Registro de Decisão Arquitetural (`adr-001-migracao-nuxt-4.md`).
|
||||
* Atenção! Tudo que puder ser abstraído para um formato técnico estrito/guiado, deve virar **Skill** ou **Rule**. Use a Memória apenas como extensão de base factual.
|
||||
* 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 Global de TODO o Sistema de Conhecimento (OBRIGATÓRIA E INEGOCIÁVEL)
|
||||
## 6️⃣ Revisão de Impacto (Dirigida por Grafo)
|
||||
|
||||
Esta é a etapa mais crítica.
|
||||
Quando um artefato é alterado, a revisão deve ser **dirigida**, não exaustiva.
|
||||
|
||||
Sempre que qualquer alteração ocorrer, é **OBRIGATÓRIO revisar TODO o sistema de conhecimento**, incluindo:
|
||||
### Processo:
|
||||
|
||||
* **TODOS os arquivos em `.agent/rules/`**
|
||||
* **TODOS os arquivos em `.agent/workflows/`**
|
||||
* **TODOS os arquivos em `.agent/skills/`**
|
||||
* **TODOS os arquivos em `.agent/memoria/`**
|
||||
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:
|
||||
|
||||
* Atualizar apenas um arquivo isolado.
|
||||
* Assumir que o impacto é local.
|
||||
* Ignorar arquivos existentes.
|
||||
* Criar artefatos sem validar o restante do sistema.
|
||||
* 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
|
||||
|
||||
---
|
||||
|
||||
### A revisão DEVE obrigatoriamente verificar:
|
||||
|
||||
#### Consistência
|
||||
|
||||
* Não existem regras conflitantes.
|
||||
* Não existem interpretações ambíguas.
|
||||
* Skills refletem fielmente as rules e workflows atuais.
|
||||
|
||||
#### Atualização
|
||||
|
||||
* Nenhuma rule está desatualizada.
|
||||
* Nenhum workflow usa regra antiga.
|
||||
* Nenhuma skill contém padrões obsoletos.
|
||||
|
||||
#### Não duplicação
|
||||
|
||||
* Não existem regras repetidas em arquivos diferentes.
|
||||
* Conteúdos redundantes foram consolidados.
|
||||
* Skills referenciam rules (não copiam o conteúdo).
|
||||
|
||||
#### Propagação de impacto
|
||||
|
||||
* Toda mudança foi refletida em:
|
||||
|
||||
* Rules relacionadas
|
||||
* Workflows relacionados
|
||||
* Skills relacionadas
|
||||
* Memória afetada pela mudança (ADRs, Diários)
|
||||
|
||||
#### Coerência estrutural
|
||||
|
||||
* Nomes de arquivos continuam válidos.
|
||||
* Assuntos estão bem separados.
|
||||
* Arquivos grandes foram divididos.
|
||||
* Skills estão organizadas em diretórios individuais.
|
||||
|
||||
---
|
||||
|
||||
### Regras obrigatórias desta etapa:
|
||||
|
||||
* **Toda alteração é considerada global até prova contrária.**
|
||||
* **Se uma rule muda, todos os workflows e skills relacionados DEVEM ser revisados.**
|
||||
* **Se um workflow muda, todas as rules e skills relacionadas DEVEM ser revisadas.**
|
||||
* **Se uma skill muda, as rules e workflows que ela referencia DEVEM ser verificados.**
|
||||
* **Atualizações de contexto devem garantir que toda a memória conflitante seja suprimida ou tagueada.**
|
||||
* **Nenhuma inconsistência pode permanecer.**
|
||||
* **Nenhuma duplicação é aceitável.**
|
||||
|
||||
---
|
||||
|
||||
## 7️⃣ Verificação Final (Checklist obrigatório)
|
||||
## 7⃣ Verificação Final (Checklist obrigatório)
|
||||
|
||||
Só é permitido encerrar se TODOS forem verdadeiros:
|
||||
|
||||
* [ ] Todas as rules foram revisadas
|
||||
* [ ] Todos os workflows foram revisados
|
||||
* [ ] Todas as skills foram revisadas
|
||||
* [ ] Não existe conflito entre artefatos
|
||||
* [ ] 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
|
||||
* [ ] Todas as mudanças foram propagadas (rules ↔ workflows ↔ skills)
|
||||
* [ ] Referências cruzadas estão válidas
|
||||
* [ ] Estrutura está organizada por assunto
|
||||
* [ ] Nenhum arquivo excede ~10k caracteres
|
||||
* [ ] Workflows refletem fielmente as rules atuais
|
||||
* [ ] Skills referenciam (não duplicam) rules
|
||||
* [ ] O sistema está consistente como um todo
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ Regra Suprema
|
||||
|
||||
> Se existir qualquer dúvida, conflito, duplicação ou inconsistência,
|
||||
> Se existir qualquer dúvida, conflito ou inconsistência
|
||||
> entre o artefato alterado e seus dependentes,
|
||||
> o trabalho é considerado **INCOMPLETO**.
|
||||
|
||||
Não existe atualização parcial.
|
||||
Não existe impacto local.
|
||||
Não existe exceção.
|
||||
A revisão é dirigida, não opcional.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -137,4 +141,4 @@ O arquivo `./COMERCIAL/<nome-do-modulo>.md` deve seguir esta estrutura:
|
|||
- 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/documentar-codigo.global.md` (para documentação técnica, não comercial)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md` (para documentação técnica, não comercial)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -181,5 +185,5 @@ Caso contrário, seguir os passos acima para criar a primeira implementação.
|
|||
|
||||
## Referências
|
||||
|
||||
- Workflow: `.agent/workflows/documentar-codigo.global.md`
|
||||
- Skill: `.agent/skills/documentar-decisao-tecnica/SKILL.md` (para decisões que geram fluxogramas)
|
||||
- Workflow: `.agent/workflows/otimizar-codigos.global.md`
|
||||
- Skill: `.agent/skills/documentar-decisao-tecnica.global/SKILL.md` (para decisões que geram fluxogramas)
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -86,7 +90,7 @@ Para cada regra listada no `.md`:
|
|||
|
||||
// turbo
|
||||
```bash
|
||||
cd e-licencie-back && node_modules/.bin/tsc --noEmit
|
||||
npx tsc --noEmit
|
||||
```
|
||||
|
||||
Zero erros = concluído.
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,221 +1,76 @@
|
|||
---
|
||||
description: Otimizar código e documentar padrões de qualidade (estrutura, limites, JSDoc e tipagem)
|
||||
type: workflow
|
||||
name: otimizar-codigos
|
||||
description: Processo de refatoração e validação de qualidade de código
|
||||
scope: global
|
||||
updatedAt: "2026-06-01"
|
||||
---
|
||||
|
||||
|
||||
|
||||
# Workflow: Qualidade e Documentação de Código
|
||||
# Workflow: Qualidade e Otimização de Código
|
||||
|
||||
## 🎯 Objetivo
|
||||
|
||||
Unificar as regras de **estrutura de arquivos**, **otimização** e **documentação** em um único fluxo de referência para o projeto `eli-vue`.
|
||||
Aplicar as rules de qualidade do ecossistema Azteca em código existente ou novo, garantindo que todos os padrões sejam cumpridos antes de finalizar uma tarefa.
|
||||
|
||||
---
|
||||
|
||||
## 1️⃣ Limite de Linhas por Arquivo
|
||||
## Passos
|
||||
|
||||
Nenhum arquivo `*.vue`, `*.ts` ou `*.tsx` pode ultrapassar **250 linhas**.
|
||||
### 1. Verificar limite de linhas
|
||||
|
||||
Essa regra existe para facilitar a leitura humana, a revisão de código e a manutenção a longo prazo.
|
||||
|
||||
> O script `scripts/check-vue-linhas.sh` valida automaticamente os arquivos `.vue` no `prebuild`.
|
||||
|
||||
**Estratégias quando o limite se aproxima:**
|
||||
|
||||
| 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` |
|
||||
|
||||
---
|
||||
|
||||
## 2️⃣ Estrutura de Componentes Vue
|
||||
|
||||
### `defineComponent` obrigatório
|
||||
|
||||
Todo componente Vue deve usar `defineComponent` para garantir inferência de tipos correta e consistência.
|
||||
|
||||
```vue
|
||||
<script lang="ts">
|
||||
import { defineComponent } from 'vue'
|
||||
|
||||
export default defineComponent({
|
||||
name: 'MeuComponente',
|
||||
setup() {
|
||||
// lógica aqui
|
||||
}
|
||||
})
|
||||
</script>
|
||||
```bash
|
||||
sh .agent/verificar-linhas.sh
|
||||
```
|
||||
|
||||
**Por que é importante:**
|
||||
- Inferência de tipos TypeScript correta dentro do componente
|
||||
- Reconhecimento por ferramentas de análise estática e IDEs
|
||||
- Compatível com Options API e Composition API com `setup()`
|
||||
- Padronização entre todos os componentes do projeto
|
||||
Se houver violações, aplicar estratégias da rule `limite-linhas.global.md`:
|
||||
- Extrair subcomponentes, mover CSS, usar Dispatch Table
|
||||
- Se necessário, converter em pasta com `index.vue`
|
||||
|
||||
---
|
||||
### 2. Validar estrutura Vue
|
||||
|
||||
### `setup()` não pode ser externo
|
||||
Para cada componente `.vue` modificado, verificar conforme `estrutura-vue.global.md`:
|
||||
- `defineComponent` presente?
|
||||
- `setup()` contém lógica própria (não delegada)?
|
||||
- CSS extenso foi movido para arquivo co-localizado?
|
||||
|
||||
O `setup()` deve estar sempre dentro do componente `.vue`. Não é permitido extrair ou delegar o `setup` para nenhum arquivo externo.
|
||||
### 3. Documentar código
|
||||
|
||||
```ts
|
||||
// ❌ Proibido — setup delegado inteiramente para arquivo externo
|
||||
// useEliTabela.ts
|
||||
export function useEliTabela(props, emit) { ... }
|
||||
Para cada função compartilhada criada/modificada, aplicar `jsdoc-padrao.global.md`:
|
||||
- JSDoc com `@param` e `@returns`?
|
||||
- Casts temporários têm comentário justificando?
|
||||
- TODOs no formato padronizado?
|
||||
|
||||
// EliTabela.vue
|
||||
export default defineComponent({
|
||||
setup(props, { emit }) {
|
||||
return useEliTabela(props, emit) // setup é apenas um proxy vazio
|
||||
}
|
||||
})
|
||||
### 4. Validar tipagem
|
||||
|
||||
```bash
|
||||
npx tsc --noEmit
|
||||
```
|
||||
|
||||
```ts
|
||||
// ✅ Correto — setup com lógica própria dentro do componente
|
||||
// EliTabela.vue
|
||||
export default defineComponent({
|
||||
setup(props, { emit }) {
|
||||
const estado = ref(null)
|
||||
const carregar = async () => { ... }
|
||||
return { estado, carregar }
|
||||
}
|
||||
})
|
||||
```
|
||||
Zero erros = prosseguir. Se houver erros, aplicar `typescript-sem-any.global.md` — nunca resolver com `any`.
|
||||
|
||||
> Composables `use*.ts` podem encapsular lógica reutilizável pontual (ex: `useFormatador`, `usePermissao`), mas nunca substituir ou esvaziar o `setup()` do componente. Se o componente ultrapassar 250 linhas, a solução é extrair subcomponentes, mover CSS ou usar Dispatch Table — não esvaziar o `setup`.
|
||||
### 5. Formatar
|
||||
|
||||
---
|
||||
|
||||
### Desassociação de CSS
|
||||
|
||||
A separação de estilos em arquivo externo é permitida e recomendada quando o CSS contribui significativamente para o total de linhas.
|
||||
|
||||
**Padrão de nomenclatura:**
|
||||
|
||||
```
|
||||
MeuComponente.vue
|
||||
MeuComponente.css
|
||||
```
|
||||
|
||||
O `.vue` importa o arquivo CSS no script:
|
||||
|
||||
```ts
|
||||
import './MeuComponente.css'
|
||||
```
|
||||
|
||||
Ou via tag `<style>`:
|
||||
|
||||
```vue
|
||||
<style src="./MeuComponente.css" />
|
||||
```bash
|
||||
npx biome check --write .
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Dispatch Table em Arquivo Separado
|
||||
## Checklist Final
|
||||
|
||||
O uso de Dispatch Table (mapa de funções) em arquivos separados é bem-vindo para eliminar blocos longos de `if/else` ou `switch`.
|
||||
- [ ] `verificar-linhas.sh` passa sem violações?
|
||||
- [ ] Componentes Vue usam `defineComponent`?
|
||||
- [ ] Funções compartilhadas têm JSDoc?
|
||||
- [ ] Casts temporários estão justificados?
|
||||
- [ ] `tsc --noEmit` zero erros?
|
||||
- [ ] `biome check` sem problemas?
|
||||
|
||||
```ts
|
||||
// handlers.ts
|
||||
export const acaoHandlers: Record<string, () => void> = {
|
||||
salvar: () => { ... },
|
||||
cancelar: () => { ... },
|
||||
excluir: () => { ... },
|
||||
}
|
||||
```
|
||||
## Rules Aplicadas
|
||||
|
||||
```ts
|
||||
// MeuComponente.vue
|
||||
import { acaoHandlers } from './handlers'
|
||||
Este workflow orquestra a verificação das seguintes rules:
|
||||
|
||||
function executar(acao: string) {
|
||||
acaoHandlers[acao]?.()
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3️⃣ Documentação em Código (JSDoc)
|
||||
|
||||
### Princípios básicos
|
||||
|
||||
- **Por que, não o Quê**: Documente o raciocínio por trás da decisão arquitetural, não o mecanismo óbvio que o TypeScript já expressa.
|
||||
- **Nomenclatura limpa**: Confie na auto-documentação de nomes expressivos antes de escrever comentários de texto livre.
|
||||
|
||||
### Funções compartilhadas — JSDoc obrigatório
|
||||
|
||||
Toda função central ou de uso compartilhado (frontend, backend, mobile ou bibliotecas comuns) deve ter cabeçalho em `JSDoc`.
|
||||
|
||||
```typescript
|
||||
/**
|
||||
* Busca os detalhes de uma entidade baseando-se no ID fornecido e calcula privilégios aplicáveis.
|
||||
* Não utilizar em fluxos de processamento em lote para evitar sobrecarga de requisições.
|
||||
*
|
||||
* @param tenantId - Identificador único do cliente/tenant no sistema
|
||||
* @param entityId - ID exclusivo identificando o registro na base de dados
|
||||
* @returns Retorna o objeto consolidado com dados ou `null` caso não seja encontrado
|
||||
*/
|
||||
export const obterDetalhesEntidade = async (tenantId: string, entityId: string) => { ... }
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4️⃣ Casts Temporários e Exceções de Tipagem
|
||||
|
||||
Devido à política **TypeScript sem any**, coerções agressivas requerem justificativa obrigatória em comentário.
|
||||
|
||||
```typescript
|
||||
// Necessário cast duplo pois a biblioteca externa não provê tipagem genérica adequada na versão atual
|
||||
const dados = payload.raw as unknown as RespostaFormatada
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5️⃣ TODOs Estruturados
|
||||
|
||||
Toda dívida técnica ou dúvida de negócio deixada em código deve seguir o formato `// TODO`:
|
||||
|
||||
- **Tipagem**: `// TODO de tipagem: Criar interface estrita para o retorno da API de listagem`
|
||||
- **Negócio**: `// TODO de regra: Validar com Produto se a taxa adicional se aplica a clientes antigos`
|
||||
|
||||
---
|
||||
|
||||
## 6️⃣ Resumo das Regras
|
||||
|
||||
| Regra | Permitido | Proibido |
|
||||
|---|---|---|
|
||||
| Tamanho de arquivo | Até 250 linhas | Acima de 250 linhas |
|
||||
| `defineComponent` | Obrigatório em todo `.vue` | Componentes sem `defineComponent` |
|
||||
| `setup()` externo | — | Proibido em qualquer forma |
|
||||
| CSS externo | `<nome>.css` vinculado ao `.vue` | CSS inline quando ultrapassa o limite |
|
||||
| Dispatch Table | Em arquivo separado | — |
|
||||
| JSDoc | Obrigatório em funções compartilhadas | Omitir em funções de uso amplo |
|
||||
| Casts `as any` | Com `biome-ignore` justificado | Sem comentário explicativo |
|
||||
|
||||
---
|
||||
|
||||
## 7️⃣ Checklist de Validação
|
||||
|
||||
Antes de concluir qualquer refatoração ou adição de código:
|
||||
|
||||
- [ ] O arquivo resultante tem menos de 250 linhas?
|
||||
- [ ] Funções compartilhadas têm `JSDoc` com `@param` e `@returns`?
|
||||
- [ ] Casts temporários têm comentário justificando?
|
||||
- [ ] TODOs estão no formato padronizado?
|
||||
- [ ] A documentação explica o **porquê**, não apenas o **o quê**?
|
||||
- [ ] `defineComponent` está presente em todo componente `.vue`?
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Script: `scripts/check-vue-linhas.sh` (validação automática de tamanho)
|
||||
- Rule: `.agent/rules/vue-limite-linhas.global.md` (política de limite de linhas)
|
||||
- Rule: `.agent/rules/typescript-sem-any.global.md` (política de tipagem)
|
||||
- Skill: `.agent/skills/documentar-decisao-tecnica/SKILL.md` (ADRs para decisões arquiteturais)
|
||||
- `.agent/rules/limite-linhas.global.md` — máximo 250 linhas
|
||||
- `.agent/rules/estrutura-vue.global.md` — defineComponent, setup, CSS, dispatch
|
||||
- `.agent/rules/jsdoc-padrao.global.md` — JSDoc, casts, TODOs
|
||||
- `.agent/rules/typescript-sem-any.global.md` — proibição de any
|
||||
- `.agent/rules/zod-validacao-padrao.global.md` — validação de entradas externas
|
||||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,9 @@
|
|||
---
|
||||
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
|
||||
|
|
@ -191,44 +195,8 @@ import { Filter, Plus, X, Trash2, Eye } from "@lucide/vue"
|
|||
|
||||
**Catálogo de referência**: https://lucide.dev/icons — buscar pelo nome do ícone em inglês.
|
||||
|
||||
#### CSS do projeto
|
||||
|
||||
```css
|
||||
/* Escala primária — Verde floresta */
|
||||
--cor-eli-primaria-bg: #EEF3D0;
|
||||
--cor-eli-primaria-zebra: #F6F9E8;
|
||||
--cor-eli-primaria-suave: #BFC99C;
|
||||
--cor-eli-primaria-clara: #D4E290;
|
||||
--cor-eli-primaria-media: #ADCC44;
|
||||
--cor-eli-primaria-acao: #8AAF00;
|
||||
--cor-eli-primaria: #688C00;
|
||||
--cor-eli-primaria-escura: #4A6500;
|
||||
--cor-eli-primaria-texto: #2E3F00;
|
||||
|
||||
/* Escala de apoio — Âmbar terroso */
|
||||
--cor-eli-alerta-bg: #FAF3DF;
|
||||
--cor-eli-alerta-clara: #F5DC8A;
|
||||
--cor-eli-alerta: #DDB847;
|
||||
--cor-eli-alerta-forte: #8C6A00;
|
||||
|
||||
/* Escala neutra — Cinza musgo */
|
||||
--cor-eli-fundo: #F2F3EE;
|
||||
--cor-eli-borda: #D5D8CC;
|
||||
--cor-eli-borda-forte: #B5BAA8;
|
||||
--cor-eli-neutro: #5E6553;
|
||||
--cor-eli-neutro-escuro: #3E4436;
|
||||
--cor-eli-superficie: #FFFFFF;
|
||||
|
||||
/* Semânticas */
|
||||
--cor-eli-sucesso: #2E7D32;
|
||||
--cor-eli-sucesso-bg: #E8F5E9;
|
||||
--cor-eli-erro: #C62828;
|
||||
--cor-eli-erro-bg: #FFEBEE;
|
||||
--cor-eli-info: #1565C0;
|
||||
--cor-eli-info-bg: #E3F2FD;
|
||||
```
|
||||
|
||||
> **⚠️ Regra crítica para componentes distribuídos como biblioteca**: todo token CSS novo (`--cor-eli-primaria-zebra`, `--cor-eli-primaria-suave`, etc.) deve ter **fallback hardcoded** no CSS do componente: `var(--token, #valorhex)`. Projetos destino podem não ter a versão mais recente do `design-tokens.css` e a variável resolverá como `undefined`, tornando a propriedade invisível.
|
||||
> 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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue