otimização do agent para docuemntação
This commit is contained in:
parent
1a25edc274
commit
890eddc464
60 changed files with 1807 additions and 1435 deletions
|
|
@ -1,212 +1,105 @@
|
|||
---
|
||||
name: documentar-regras-negocio
|
||||
description: Criar ou atualizar o arquivo {modulo}.regras-negocio.md na Wiki de Desenvolvimento (../../wiki/dev/<modulo>/) e garantir consistência com o código TypeScript.
|
||||
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.
|
||||
updatedAt: "2026-09-01"
|
||||
---
|
||||
|
||||
# Skill: Documentar Regras de Negócio em Módulos
|
||||
# Workflow / Skill: Documentar Regras de Negócio de um Módulo
|
||||
|
||||
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.
|
||||
Use este workflow para criar ou atualizar o arquivo de regras de negócio de qualquer módulo TypeScript com lógica não-trivial, armazenado na **Wiki de Desenvolvimento** em `../../wiki/dev/<modulo>/`.
|
||||
|
||||
---
|
||||
|
||||
## Quando usar esta skill
|
||||
[1] Ler o módulo TypeScript completamente
|
||||
|
||||
- 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
|
||||
Identificar e anotar:
|
||||
|
||||
- Nome do arquivo e localização exata no código
|
||||
- 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 BullMQ, e-mails, serviços)
|
||||
|
||||
---
|
||||
|
||||
## PASSO 1 — Identificar o escopo das regras
|
||||
[2] Verificar se já existe a documentação de regras na Wiki de Desenvolvimento
|
||||
|
||||
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
|
||||
```bash
|
||||
ls ../../wiki/dev/<modulo>/*regras-negocio*.md 2>/dev/null
|
||||
```
|
||||
|
||||
Se o módulo for arquivo isolado (não pasta):
|
||||
```
|
||||
CRONS/
|
||||
_cron_nome.ts
|
||||
_cron_nome.regras-negocio.md ← mesmo diretório
|
||||
```
|
||||
- **Existe** → ler e identificar o que está desatualizado → ir para o passo [4]
|
||||
- **Não existe** → ir para o passo [3]
|
||||
|
||||
---
|
||||
|
||||
## PASSO 3 — Preencher com o template
|
||||
[3] Criar o arquivo de regras na Wiki de Desenvolvimento
|
||||
|
||||
```markdown
|
||||
# Regras de Negócio — [Nome Legível do Módulo]
|
||||
**Localização:** `../../wiki/dev/<modulo>/{nome-do-modulo}.regras-negocio.md` (ou `../../wiki/dev/<modulo>/regras-negocio/`).
|
||||
|
||||
Módulo: `_arquivo.ts`
|
||||
Localização: `caminho/relativo/ao/workspace`
|
||||
Preencher com a estrutura padrão:
|
||||
- Contexto operacional
|
||||
- Critérios de Entrada
|
||||
- Regras de Processamento (numeradas em ordem estrita)
|
||||
- Casos de Revisão Manual
|
||||
- Estratégia de Saída / Persistência de Campos
|
||||
- Dependências Externas (tabelas, filas, CRONs)
|
||||
|
||||
---
|
||||
|
||||
## Contexto
|
||||
[4] Adicionar ou verificar a referência no `.ts`
|
||||
|
||||
[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):
|
||||
Garantir que a primeira linha útil do arquivo TypeScript seja:
|
||||
|
||||
```typescript
|
||||
// Regras de negócio: ver {modulo}.regras-negocio.md
|
||||
|
||||
import { ... } from "..."
|
||||
// Regras de negócio: ver ../../wiki/dev/<modulo>/{modulo}.regras-negocio.md
|
||||
```
|
||||
|
||||
Se já existia e está correto → sem mudança necessária.
|
||||
|
||||
---
|
||||
|
||||
## PASSO 5 — Limpar JSDoc duplicados
|
||||
[5] Estruturar JSDoc com aplicação prática e referência ao `.regras-negocio.md`
|
||||
|
||||
Percorrer os JSDoc do módulo e:
|
||||
Percorrer cada função do módulo:
|
||||
|
||||
| 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 |
|
||||
- Inserir JSDoc explicando a aplicação prática da função no sistema (rule `rules/jsdoc-padrao.md`).
|
||||
- Referenciar o arquivo `.regras-negocio.md` para a lista detalhada de regras e critérios de decisão.
|
||||
- Manter `@param` com contexto do domínio, `@returns` e `@throws`.
|
||||
- Manter comentários inline (`//`) explicando cálculos pontuais ou regras de exceção.
|
||||
|
||||
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
|
||||
*/
|
||||
[6] Verificar consistência — código ↔ `.regras-negocio.md`
|
||||
|
||||
// ✅ 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
|
||||
*/
|
||||
Para cada regra listada no `.regras-negocio.md`:
|
||||
|
||||
- [ ] Existe `if` correspondente no código
|
||||
- [ ] A ordem de avaliação bate entre `.regras-negocio.md` e código
|
||||
- [ ] Campos com separador de concatenação batem entre documentação 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
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 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`)
|
||||
Zero erros = concluído.
|
||||
|
||||
---
|
||||
|
||||
## Checklist Final
|
||||
[8] Sincronizar com a Wiki de Desenvolvimento e Memórias
|
||||
|
||||
- [ ] 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
|
||||
Se o módulo introduziu ou alterou arquitetura ou regras consolidadas do módulo:
|
||||
|
||||
---
|
||||
|
||||
## Referências
|
||||
|
||||
- Rule: `global/rules/regras-negocio-md`
|
||||
- Workflow: `global/workflows/documentar-regras-negocio`
|
||||
- Atualizar a especificação técnica na **Wiki de Desenvolvimento** em `../../wiki/dev/<modulo>/`.
|
||||
- Criar ou atualizar ADR em `../../wiki/dev/<modulo>/adrs/` via skill `documentar-decisao-tecnica`.
|
||||
- Registrar decisões e ações na memória em `<base_projeto>/memorias-ia/`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue