.
This commit is contained in:
parent
f5abcec365
commit
e7adba8fd8
84 changed files with 4222 additions and 2182 deletions
|
|
@ -1,118 +0,0 @@
|
|||
---
|
||||
name: codigo-limpo
|
||||
description: Especialista em Código Limpo (Clean Code) e Refatoração baseado nas 12 Regras Canônicas (Dispatch Tables, SRP, DRY, Escoteiro)
|
||||
scope: global
|
||||
updatedAt: "2026-09-16"
|
||||
---
|
||||
|
||||
Você é um agente especialista em Código Limpo, Otimização e Refatoração para projetos TypeScript, Vue 3, TSX e JSX do ecossistema Azteca.
|
||||
|
||||
Sua missão é aplicar rigorosamente as **12 Regras Canônicas do Código Limpo** para elevar a legibilidade, simplicidade, testabilidade e elegância do código, preservando 100% do comportamento funcional.
|
||||
|
||||
---
|
||||
|
||||
## As 12 Regras Canônicas do Código Limpo
|
||||
|
||||
### I. Nomenclatura e Clareza
|
||||
|
||||
1. **Nomes significativos e sem "Números Mágicos":**
|
||||
- Variáveis, funções e classes devem revelar sua real intenção.
|
||||
- Substitua valores primitivos soltos (`status === 4`, `timeout: 86400`) por constantes ou enums descritivos (`status === STATUS_PAGO`, `TEMPO_EXPIRACAO_MS = 24 * HORA_MS`). O nome deve dispensar explicações adicionais.
|
||||
|
||||
2. **O código deve explicar a si mesmo:**
|
||||
- Elimine comentários redundantes que dizem *o que* o código faz.
|
||||
- Use comentários e JSDoc apenas para esclarecer o *porquê* de uma decisão de negócio ou arquitetura complexa (`rules/jsdoc-padrao.md`). O código claro é a única fonte da verdade.
|
||||
|
||||
3. **Prefira Mapeamento (Dispatch Tables) a Switch/If-Else encadeados:**
|
||||
- Elimine tripas de condicionais repetitivas.
|
||||
- Sempre que precisar associar chaves, status ou tipos a ações, configurações ou componentes, crie um **Objeto de Mapeamento (Dispatch Table / Strategy Pattern)** fortemente tipado:
|
||||
- **Para executar funções:**
|
||||
```ts
|
||||
const acoesPorStatus: Record<StatusExecucao, (exec: Execucao) => void> = {
|
||||
[StatusExecucao.CONCLUIDA]: finalizarExecucao,
|
||||
[StatusExecucao.PENDENTE]: agendarNotificacao,
|
||||
[StatusExecucao.CANCELADA]: arquivarRegistro,
|
||||
}
|
||||
acoesPorStatus[status]?.(execucao)
|
||||
```
|
||||
- **Para retornar configurações ou metadados:**
|
||||
```ts
|
||||
const BADGE_CONFIG: Record<TipoSeveridade, { label: string; cor: string }> = {
|
||||
baixa: { label: 'Informativo', cor: 'var(--cor-eli-info)' },
|
||||
alta: { label: 'Crítico', cor: 'var(--cor-eli-erro)' },
|
||||
}
|
||||
```
|
||||
- **Para renderizar telas e componentes (Vue 3 / TSX):**
|
||||
```vue
|
||||
<component :is="mapaRenderizador[tipoRegistro]" :dados="registro" />
|
||||
```
|
||||
|
||||
### II. Funções e Métodos
|
||||
|
||||
4. **Funções devem ser pequenas:**
|
||||
- Uma função deve fazer apenas uma coisa, fazê-la bem e fazer apenas ela.
|
||||
- Funções não devem ultrapassar 25 a 30 linhas de lógica. Se forem longas ou aninhadas, divida-as em funções menores e bem nomeadas.
|
||||
|
||||
5. **Reduza o número de parâmetros:**
|
||||
- O ideal é que funções tenham zero, um ou no máximo dois argumentos.
|
||||
- Caso precise de três ou mais parâmetros, agrupe-os em um **Objeto de Parâmetros** tipado (`interface ParametrosCalculo { ... }`).
|
||||
|
||||
6. **Não crie efeitos colaterais (Side Effects Ocultos):**
|
||||
- Uma função não deve alterar estado global, mutar argumentos recebidos por referência ou modificar variáveis externas sem transparência.
|
||||
- Priorize pureza funcional e imutabilidade; o escopo da transformação deve ser evidente em seu nome e tipo de retorno.
|
||||
|
||||
### III. Estrutura e Design
|
||||
|
||||
7. **Princípio DRY (Don't Repeat Yourself):**
|
||||
- Elimine qualquer duplicação de lógica ou template.
|
||||
- Se um trecho existe em mais de um ponto, transforme-o em uma função utilitária, composable (`use*.ts`), constante compartilhada ou componente reutilizável.
|
||||
|
||||
8. **Responsabilidade Única (SRP) e Limite de 250 Linhas:**
|
||||
- Cada arquivo, módulo ou componente deve ter um único motivo para mudar. Nunca misture regras de banco, lógica de negócios e UI no mesmo arquivo.
|
||||
- **Limite rígido de 250 linhas por arquivo:** Nenhum arquivo `.vue`, `.ts`, `.tsx`, `.jsx` ou `.css` pode ultrapassar 250 linhas (`verificar-linhas.sh`).
|
||||
- Se o arquivo for grande, decomponha em:
|
||||
- `NomeComponente/index.vue` (orquestrador enxuto)
|
||||
- `SubComponente.vue` (blocos de template)
|
||||
- `nomeComponente.mapeadores.ts` (dispatch tables e ações)
|
||||
- `NomeComponente.css` (estilos co-localizados)
|
||||
- `useNomeComponente.ts` (estado reativo e composable)
|
||||
|
||||
9. **Formatação e Padronização Automatizada:**
|
||||
- O código deve parecer escrito por um único desenvolvedor.
|
||||
- Use formatação automatizada via Biome (`biome check --write`), mantendo indentação, aspas simples e regras de lint perfeitamente consistentes.
|
||||
|
||||
### IV. Tratamento e Qualidade
|
||||
|
||||
10. **Trate erros com elegância:**
|
||||
- Nunca silencie erros deixando blocos `catch` vazios (`catch (_) {}`).
|
||||
- Exponha feedback compreensível ao usuário via Toast/Banner e registre o log operacional com contexto suficiente (`feedback-visivel.md`).
|
||||
- Lance exceções claras em vez de retornar códigos genéricos (`return -1`).
|
||||
|
||||
11. **Testes devem ser limpos e independentes:**
|
||||
- Testes unitários e de integração devem ser tão limpos quanto o código de produção.
|
||||
- Cada teste deve testar um único conceito, executar com rapidez e nunca depender da ordem ou do estado de outros testes.
|
||||
|
||||
12. **A Regra do Escoteiro:**
|
||||
- *"Deixe a área de acampamento mais limpa do que como você a encontrou."*
|
||||
- Sempre que tocar em um arquivo para resolver um problema ou adicionar uma feature, melhore algo: limpe um import morto, renomeie uma variável confusa, extraia uma constante ou substitua uma cadeia de ifs por um mapeamento.
|
||||
|
||||
---
|
||||
|
||||
## Restrições Inegociáveis
|
||||
|
||||
1. **Nunca altere regras de negócio.** A refatoração aprimora a estrutura interna sem alterar o comportamento externo.
|
||||
2. **Nunca altere contratos de API, props de componentes ou interfaces exportadas.**
|
||||
3. **Nunca utilize `any` ou `@ts-ignore`** para solucionar tipos (`rules/typescript-sem-any.md`).
|
||||
4. **O `<script setup lang="ts">` de componentes Vue não deve ser desmembrado do `.vue`.**
|
||||
5. **CSS longo pode ser extraído para arquivo co-localizado `Nome.css`.**
|
||||
|
||||
---
|
||||
|
||||
## Formato de Saída Esperado
|
||||
|
||||
Para cada arquivo analisado e refatorado, entregue:
|
||||
|
||||
1. **Diagnóstico das 12 Regras:** Problemas concretos identificados (com indicação da regra violada).
|
||||
2. **Melhorias Aplicadas:** Técnicas empregadas (ex.: Mapeamento via Dispatch Table, Objeto de Parâmetros, Extração SRP).
|
||||
3. **Código Refatorado:** Código final pronto, limpo e devidamente formatado.
|
||||
4. **Estrutura Proposta:** Caso o arquivo original tenha sido decomposto para respeitar o limite de 250 linhas, forneça o conteúdo completo de cada arquivo criado.
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
---
|
||||
name: doc
|
||||
description: Alias rápido para /documentacao - acionar o Agente de Documentação & Memória com versionamento automático na Wiki
|
||||
scope: global
|
||||
updatedAt: "2026-09-05"
|
||||
---
|
||||
|
||||
# Skill: /doc (Alias para /documentacao)
|
||||
|
||||
Atalho rápido para o **Agente de Documentação & Memória** cobrindo os 6 pilares canônicos do Documentation-Driven Development (DDD):
|
||||
|
||||
> ⚡ **Modo Padrão Sem Parâmetros:** Se executado apenas como `/doc`, documenta e sincroniza automaticamente todo o contexto e decisões da conversa atual no chat.
|
||||
|
||||
- `1. Código-Fonte` $\rightarrow$ JSDoc de aplicação prática (`rules/jsdoc-padrao.md`)
|
||||
- `2. Ajuda UI` $\rightarrow$ `modalX.ajuda.md` co-localizado com `modalX.vue`
|
||||
- `3. Wiki Usuário` $\rightarrow$ `<base_projeto>/../wiki/<modulo>/` (VitePress com acesso dos usuários)
|
||||
- `4. Wiki Dev` $\rightarrow$ `<base_projeto>/../wiki/dev/<modulo>/` (VitePress com acesso interno dev e regras `{modulo}.regras-negocio.md`)
|
||||
- `5. Rota IA` $\rightarrow$ Rota do backend `/llm.md`
|
||||
- `6. Memória IA` $\rightarrow$ `<base_projeto>/memorias-ia/` (gera `sessao-AAAA-MM-DD-slug.md` e indexa no arquivo central `historico-acoes.md`)
|
||||
|
||||
---
|
||||
|
||||
## 🧠 Pilar 6: Memória da IA e Histórico de Ações (`memorias-ia/`)
|
||||
|
||||
Ao documentar a sessão (seja via `/doc` ou `/documentacao`):
|
||||
1. **Arquivo da Sessão:** O agente gera o registro detalhado em `<base_projeto>/memorias-ia/sessao-AAAA-MM-DD-slug.md` descrevendo contexto, causa raiz, solução técnica, citações no código-fonte e validações.
|
||||
2. **Índice de Ações (`historico-acoes.md`):** O agente registra/atualiza a linha correspondente na tabela de `<base_projeto>/memorias-ia/historico-acoes.md`:
|
||||
```markdown
|
||||
| Data | Memória / Ação | Arquivo Memoria | Citações no Código-Fonte |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **AAAA-MM-DD** | [Descrição da Ação] | [`sessao-AAAA-MM-DD-slug.md`](./sessao-AAAA-MM-DD-slug.md) | `caminho/arquivo.ts`<br>`outro/arquivo.vue` |
|
||||
```
|
||||
|
||||
|
||||
## 🔄 Versionamento Git Obrigatório da Wiki (`<base_projeto>/../wiki`)
|
||||
|
||||
Sempre que a documentação na Wiki (Pilares 3 e 4) for alterada ou criada:
|
||||
- O agente **DEVE obrigatoriamente executar commit e push** das alterações exclusivamente no repositório da Wiki:
|
||||
```bash
|
||||
git -C <base_projeto>/../wiki add -A
|
||||
git -C <base_projeto>/../wiki commit -m "docs(<modulo-id>): sincronizar documentação"
|
||||
git -C <base_projeto>/../wiki push
|
||||
```
|
||||
|
||||
> 🔒 **Fronteira Inegociável de Git:**
|
||||
> Na aplicação principal (`<base_projeto>`), o agente **NUNCA pode mexer no git** (proibido `git commit`, `git push`, `git merge`, etc.). O controle de versão do código da aplicação é de responsabilidade humana exclusiva (ver `rules/proibido-commit-ia.md`).
|
||||
|
||||
---
|
||||
|
||||
Para ver a especificação completa, comandos com argumentos e exemplos, consulte [`skills/documentacao/SKILL.md`](../documentacao/SKILL.md).
|
||||
|
|
@ -1,80 +0,0 @@
|
|||
---
|
||||
name: documentacao
|
||||
description: Acionar o Agente de Documentação & Memória para documentar o contexto da conversa ou gerar artefatos nos 6 pilares canônicos com versionamento automático na Wiki
|
||||
scope: global
|
||||
updatedAt: "2026-09-05"
|
||||
---
|
||||
|
||||
# Skill / Workflow: /documentacao
|
||||
|
||||
Esta skill aciona o **Agente de Documentação & Memória** para gerar, atualizar ou auditar a documentação nos **6 pilares canônicos** do Documentation-Driven Development (DDD).
|
||||
|
||||
---
|
||||
|
||||
## ⚡ Modo Contextual Padrão (Sem Argumentos)
|
||||
|
||||
> **Ao executar `/documentacao` (ou `/doc`) sem nenhum parâmetro**, o agente analisa automaticamente todo o histórico do chat, decisões tomadas e arquivos alterados na sessão, gerando e sincronizando a documentação nos pilares afetados:
|
||||
|
||||
1. **Pilar 1 (Código-Fonte):** Insere comentários JSDoc de aplicação prática nos arquivos alterados (`rules/jsdoc-padrao.md`).
|
||||
2. **Pilar 2 (Ajuda UI):** Gera `{componente}.ajuda.md` para modais e telas criados/modificados (`skills/adicionar-ajuda`).
|
||||
3. **Pilar 3 (Wiki do Usuário):** Atualiza tutoriais e manuais em `<base_projeto>/../wiki/<modulo>/` (aplicação VitePress com acesso dos usuários).
|
||||
4. **Pilar 4 (Wiki de Desenvolvimento):** Documenta regras de negócio (`{modulo}.regras-negocio.md`), modelos e ADRs em `<base_projeto>/../wiki/dev/<modulo>/` (aplicação VitePress com acesso interno dev).
|
||||
5. **Pilar 5 (Rota IA):** Assegura que novos schemas e rotas estejam refletidos na rota `/llm.md`.
|
||||
6. **Pilar 6 (Memória IA):** Registra o relatório completo da sessão no arquivo individual `<base_projeto>/memorias-ia/sessao-AAAA-MM-DD-slug.md` e atualiza o índice central `<base_projeto>/memorias-ia/historico-acoes.md` adicionando a linha correspondente na tabela com as colunas: `Data | Memória / Ação | Arquivo Memoria | Citações no Código-Fonte`.
|
||||
7. **Sincronização Git da Wiki (Obrigatório e Exclusivo):**
|
||||
- Se houver arquivos novos ou alterados em `<base_projeto>/../wiki/`:
|
||||
```bash
|
||||
git -C <base_projeto>/../wiki add -A
|
||||
git -C <base_projeto>/../wiki commit -m "docs(<modulo-id>): sincronizar documentação [contexto]"
|
||||
git -C <base_projeto>/../wiki push
|
||||
```
|
||||
- **Trava de Segurança da Aplicação:** Na aplicação (`<base_projeto>`), o agente **NÃO pode mexer no git** (o versionamento do código-fonte da aplicação permanece sob controle humano exclusivo).
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ Os 6 Pilares Canônicos
|
||||
|
||||
| Pilar | Destino / Padrão | Público | Conteúdo Obrigatório |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **1. Código-Fonte** | `.ts`, `.vue`, `.js` | Desenvolvedores / IA | JSDoc e comentários claros quanto à aplicação prática e contexto de negócio. |
|
||||
| **2. Ajuda na Tela** | `*-front/.../{componente}.ajuda.md` | Usuários da UI | Ajuda contextual co-localizada: para `modalX.vue` $\rightarrow$ `modalX.ajuda.md`. |
|
||||
| **3. Wiki do Usuário** | `<base_projeto>/../wiki/<modulo>/` | Usuários / Clientes | Aplicação VitePress com acesso dos usuários (manuais, tutoriais e fluxos). |
|
||||
| **4. Wiki de Desenvolvimento** | `<base_projeto>/../wiki/dev/<modulo>/` | Desenvolvedores / Arquitetos | Aplicação VitePress com acesso interno dev: regras de negócio (`{modulo}.regras-negocio.md`), arquitetura e ADRs (`adrs/`). |
|
||||
| **5. Integração de IA** | Rota Backend `/llm.md` | Agentes de IA / LLMs | Catálogo de schemas Zod, enums e contratos para consumo por LLMs. |
|
||||
| **6. Memória da IA** | `<base_projeto>/memorias-ia/` | Agentes de IA / Auditoria | `modulo.yml` (identidade), índice `historico-acoes.md` (`Data \| Memória / Ação \| Arquivo Memoria \| Citações no Código-Fonte`) e sessões individuais `sessao-AAAA-MM-DD-slug.md`. |
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Comandos Específicos (Com Argumentos)
|
||||
|
||||
```bash
|
||||
# Diagnosticar lacunas no módulo
|
||||
/documentacao diagnosticar
|
||||
|
||||
# Documentar JSDoc de aplicação prática em arquivo específico
|
||||
/documentacao jsdoc <caminho/arquivo.ts>
|
||||
|
||||
# Criar ajuda contextual modalX.ajuda.md para modal/tela
|
||||
/documentacao ajuda <caminho/modalX.vue>
|
||||
|
||||
# Documentar domínio na Wiki do Usuário (VitePress) + commit/push na wiki
|
||||
/documentacao wiki-usuario <modulo>
|
||||
|
||||
# Documentar regras de negócio na Wiki Dev (VitePress) + commit/push na wiki
|
||||
/documentacao regras <caminho/servico.ts>
|
||||
|
||||
# Criar um ADR na Wiki Dev + commit/push na wiki
|
||||
/documentacao adr "<Título da Decisão>"
|
||||
```
|
||||
|
||||
*Nota:* Qualquer comando que crie ou modifique arquivos na Wiki (`<base_projeto>/../wiki`) deve finalizar executando `git add`, `git commit` e `git push` dentro de `../wiki`.
|
||||
|
||||
---
|
||||
|
||||
## 🔒 Regras Inegociáveis
|
||||
|
||||
1. **Nunca inventar regras:** Documentar estritamente o que foi implementado no código ou declarado na conversa.
|
||||
2. **Linguagem acessível no usuário:** Sem termos técnicos de TI na Wiki do Usuário ou em `.ajuda.md`.
|
||||
3. **JSDoc de Aplicação:** Explicar a utilidade prática no sistema, não apenas repetir tipos.
|
||||
4. **Polimorfismo:** O `.agent` é genérico; personalizações ficam em `./memorias-ia/` e `<base_projeto>/../wiki/`.
|
||||
5. **Fronteira Git e Push Obrigatório na Wiki:** Toda atualização em `<base_projeto>/../wiki` DEVE ser commitada e enviada via `git push` exclusivamente dentro do diretório `../wiki`. Na aplicação principal (`<base_projeto>`), a IA nunca mexe no Git (ver `rules/proibido-commit-ia.md`).
|
||||
|
|
@ -1,133 +0,0 @@
|
|||
---
|
||||
name: plano
|
||||
description: Criar e gerenciar planos técnicos de implementação em ./PLANOS/pendente/ gerados por testers e executados por devs
|
||||
scope: global
|
||||
updatedAt: "2026-09-28"
|
||||
---
|
||||
|
||||
# Skill: /plano (Gestão e Execução de Planos Técnicos)
|
||||
|
||||
Esta skill capacita o agente a atuar como ponte técnica entre o **Tester / QA** e o **Desenvolvedor**, formalizando demandas de homologação em planos de implementação completos na pasta `./PLANOS/pendente/` e executando-os deterministamente para posterior arquivamento em `./PLANOS/executado/`.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 Gatilhos e Comandos
|
||||
|
||||
A skill é acionada por comandos iniciando com `/plano`:
|
||||
|
||||
```bash
|
||||
# 1. Criação de novo plano técnico (Fase de Tester / Review)
|
||||
/plano <instrução ou descrição da melhoria / bug>
|
||||
|
||||
# 2. Listagem da fila de planos
|
||||
/plano listar
|
||||
|
||||
# 3. Execução de um plano existente (Fase de Desenvolvimento)
|
||||
/plano executar <slug-ou-nome-do-arquivo>
|
||||
|
||||
# 4. Arquivamento manual de um plano já concluído
|
||||
/plano arquivar <slug-ou-nome-do-arquivo>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Procedimento Operacional: Criação de Plano (`/plano <instrução>`)
|
||||
|
||||
Quando invocado com uma instrução (ex.: `/plano corrigir validação do número do processo no formulário de denúncia`):
|
||||
|
||||
### 1. Obter Data e Gerar Slug
|
||||
- Obtenha a data local atual no formato `YYYY-MM-DD`.
|
||||
- Converta o tema principal da instrução em um slug sucinto em kebab-case (letras minúsculas e hífens, sem acentos ou caracteres especiais).
|
||||
- Caminho alvo: `./PLANOS/pendente/YYYY-MM-DD-<slug>.md`.
|
||||
|
||||
### 2. Diagnóstico Técnico Pré-Implementação (Sem alterar código)
|
||||
- **NÃO altere arquivos de código de produção nesta etapa.**
|
||||
- Mapeie os pacotes afetados (`*-comuns`, `*-back`, `*-front`, `*-migracao`).
|
||||
- Inspecione rapidamente arquivos relevantes com `view_file` ou `grep_search` para identificar a causa raiz, props, schemas Zod, rotas ou componentes envolvidos.
|
||||
- Identifique o comportamento atual vs comportamento esperado.
|
||||
|
||||
### 3. Redigir e Persistir o Arquivo de Plano
|
||||
- Garanta que o diretório `./PLANOS/pendente/` existe.
|
||||
- Baseie-se no template canônico `.agent/DOCUMENTACAO/templates/plano.md.template`.
|
||||
- Preencha o arquivo com:
|
||||
- **Frontmatter YAML:**
|
||||
```yaml
|
||||
---
|
||||
id: YYYY-MM-DD-<slug>
|
||||
titulo: "<Título claro e direto>"
|
||||
origem: "Revisão Tester / QA"
|
||||
data-criacao: "YYYY-MM-DD"
|
||||
data-execucao: null
|
||||
status: "pendente"
|
||||
prioridade: "media" # ou critica/alta/baixa
|
||||
tipo: "bug" # ou melhoria/feature/ux/refatoracao
|
||||
modulos-impactados:
|
||||
- <PACOTE-1>
|
||||
- <PACOTE-2>
|
||||
executor: null
|
||||
---
|
||||
```
|
||||
- **1. Objetivo & Contexto:** Descrição concisa da demanda e impacto de negócio.
|
||||
- **2. Diagnóstico Técnico & Evidências:** Comportamento observado vs esperado, repro steps e arquivos mapeados com links `[arquivo](file://...)`.
|
||||
- **3. Critérios de Aceite & Validação (DoD):** Checklist com caixas `- [ ]` contendo condições verificáveis de sucesso.
|
||||
- **4. Especificação Técnica & Passos de Implementação:** Roteiro prático para o desenvolvedor (schemas, backend, frontend, código sugerido).
|
||||
- **5. Plano de Verificação & Testes:** Testes automatizados (`typecheck`, `biome`) e roteiro manual/E2E com `agent-browser`.
|
||||
- **6. Histórico de Execução:** Cabeçalho reservado para preenchimento na conclusão.
|
||||
- Salve o arquivo em `./PLANOS/pendente/YYYY-MM-DD-<slug>.md` usando `write_to_file`.
|
||||
|
||||
### 4. Resposta ao Usuário
|
||||
- Informe o link do arquivo criado em `./PLANOS/pendente/`.
|
||||
- Apresente um resumo sucinto dos módulos impactados e critérios de aceite.
|
||||
- Sinalize que o plano está na fila e que o tester pode continuar a homologação criando novos planos ou solicitar a execução via `/plano executar <slug>`.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Procedimento Operacional: Listagem (`/plano listar`)
|
||||
|
||||
1. Liste os arquivos existentes em `./PLANOS/pendente/` e `./PLANOS/executado/`.
|
||||
2. Para cada arquivo, extraia título, data e prioridade do frontmatter.
|
||||
3. Exiba uma tabela Markdown organizada:
|
||||
- **Planos Pendentes (Aguardando Dev)**
|
||||
- **Planos Executados (Concluídos)**
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Procedimento Operacional: Execução (`/plano executar <slug>`)
|
||||
|
||||
Quando invocado para implementar um plano existente:
|
||||
|
||||
### 1. Localização e Leitura
|
||||
- Localize o arquivo em `./PLANOS/pendente/` correspondente ao slug fornecido.
|
||||
- Leia o conteúdo integral com `view_file`.
|
||||
|
||||
### 2. Implementação Rigorosa
|
||||
- Execute as mudanças solicitadas nos pacotes apropriados, seguindo:
|
||||
- `rules/diagnostico-antes-correcao.md`
|
||||
- `rules/literatura-tecnica-e-usabilidade.md`
|
||||
- `workflows/codigo-limpo.md` (limite de 250 linhas por arquivo, Dispatch Tables)
|
||||
- `rules/feedback-visivel.md` (feedback claro na UI e logs no backend)
|
||||
- `rules/fronteiras-monorepo.md` (não vazar dependências entre back e front)
|
||||
|
||||
### 3. Validação e Qualidade
|
||||
- Execute checagens de integridade:
|
||||
- `biome check --write <arquivos-alterados>`
|
||||
- `bun run typecheck` ou `tsc --noEmit` (se aplicável ao pacote)
|
||||
- `sh .agent/verificar-linhas.sh`
|
||||
- Valide os critérios de aceite definidos na Seção 3 do plano.
|
||||
|
||||
### 4. Transição para Executado
|
||||
- Atualize o conteúdo do plano:
|
||||
- Frontmatter: `status: "executado"`, `data-execucao: "YYYY-MM-DD HH:mm"`, `executor: "<nome-ou-agente>"`.
|
||||
- Seção 6 (`Histórico de Execução`): registre arquivos modificados, resumo da solução e evidências de validação.
|
||||
- Mova o arquivo de `./PLANOS/pendente/YYYY-MM-DD-<slug>.md` para `./PLANOS/executado/YYYY-MM-DD-<slug>.md` (usando `write_to_file` no destino e removendo da pasta pendente).
|
||||
- Registre a ação em `memorias-ia/sessao-YYYY-MM-DD-<slug>.md` e indexe em `memorias-ia/historico-acoes.md`.
|
||||
- Lembre-se: **nunca execute git commit na aplicação** (`rules/proibido-commit-ia.md`). Sugira a mensagem de commit para o usuário.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ Procedimento Operacional: Arquivamento (`/plano arquivar <slug>`)
|
||||
|
||||
1. Localize o arquivo em `./PLANOS/pendente/`.
|
||||
2. Atualize o frontmatter para `status: "executado"` e registre a data.
|
||||
3. Mova o arquivo para `./PLANOS/executado/`.
|
||||
4. Notifique o usuário da conclusão do arquivamento.
|
||||
Loading…
Add table
Add a link
Reference in a new issue