otimização do agent para docuemntação

skills/adicionar-ajuda/SKILL.md

@@ -1,118 +1,109 @@
 ---
-type: workflow
 name: adicionar-ajuda
-description: Adicionar ou atualizar botão de ajuda e documentação em telas (Frontend)
-scope: local
-updatedAt: "2026-06-01"
+description: Adicionar ou atualizar botão de ajuda e documentação contextual em telas e modais (Frontend)
+scope: global
+updatedAt: "2026-09-01"
 ---
 
-# Workflow: Adicionar Ajuda em Telas
+# Skill / Workflow: Adicionar Ajuda Contextual em Telas e Modais
 
-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.
+Este guia estabelece o padrão para criação e manutenção de arquivos de **ajuda contextual ao usuário** exibidos diretamente na interface da aplicação.
 
-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.
+O objetivo da ajuda em tela é **auxiliar o usuário final a compreender e operar a interface de forma autônoma**, explicando o funcionamento da tela/modal de forma clara, amigável 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.
+## 1. Padrão Canônico de Nomenclatura e Co-Localização
 
-## 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:
+Sempre que uma tela ou modal possuir ajuda contextual, o arquivo Markdown de documentação **DEVE** ser co-localizado com o componente na mesma pasta, adotando o sufixo `.ajuda.md`:
 
 ```
-
-TelaCadastroUsuario.tsx
-TelaCadastroUsuario.ajuda.md
-
+modalExportarPdf.vue       → modalExportarPdf.ajuda.md
+modalParametros.vue        → modalParametros.ajuda.md
+telaCadastroPonto.vue      → telaCadastroPonto.ajuda.md
 ```
 
-ou
+> ⚠️ **Regra Estrita**: Para qualquer componente `modalX.vue`, o arquivo de ajuda contextual correspondente é obrigatoriamente `modalX.ajuda.md`.
 
-```
+---
 
-TelaCadastroUsuario.vue
-TelaCadastroUsuario.ajuda.md
+## 2. Conteúdo Obrigatório do `.ajuda.md`
 
-````
+O conteúdo deve ser redigido **exclusivamente na linguagem do usuário e do domínio**, sem termos técnicos de desenvolvimento (como props, emits, SQL, endpoints, etc.).
 
-### 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:
+Estrutura recomendada:
 
 ```markdown
-# Ajuda: [Nome da Tela]
+# Ajuda: [Nome da Tela / Modal]
 
-## Objetivo da Tela
+## Objetivo
+Explique resumidamente para que serve esta tela ou modal dentro do fluxo de trabalho do usuário.
 
-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.
+## Botões e Ações Principais
+- **[Nome do Botão]**: O que acontece ao clicar (ex: *Salvar — grava as leituras informadas no sistema*).
+- **[Nome do Botão]**: Ação de cancelamento ou descarte.
 
 ## Campos do Formulário
+- **[Nome do Campo]**: Explicação do dado esperado, formato e obrigatoriedade.
+- **[Nome do Campo]**: Regra de preenchimento ou limites aplicáveis.
 
-- **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 Passo a Passo
+1. Passo inicial do usuário.
+2. Preenchimento e conferência.
+3. Conclusão da ação.
 
-## Fluxo de Uso
+## Regras de Validação e Normas (quando aplicável)
+Explique prazos, limites legais ou critérios ambientais relevantes para a operação.
+```
 
-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)
+## 3. Posicionamento do Botão de Ajuda na UI
 
-Explique regras técnicas, normas ou exigências legais relacionadas à funcionalidade da tela.
-````
+O botão de ajuda (ex: `BotaoAjuda`, ícone `HelpCircle` ou `v-icon`) deve ser posicionado de maneira consistente:
 
-### 4. Posicionamento do Botão de Ajuda
+### Em Modais (`modalX.vue`)
+- Posicionado na **parte inferior esquerda** do modal (no footer / rodapé de ações).
+- Nunca sobrepor botões principais de ação (como Salvar, Fechar, Excluir).
+- Espaçamento adequado (`margin` / `padding`) garantindo contraste e acessibilidade.
 
-O botão deve ser inserido de forma consistente e não pode interferir na interface da aplicação.
+### Em Páginas / Telas (`telaX.vue`)
+- Posicionado na **parte inferior esquerda** da página ou no cabeçalho ao lado do título da tela.
+- Não sobrepor barras de navegação nem componentes flutuantes.
 
-#### 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.
+## 4. Integração Técnica no Vue 3
 
-#### Modais e Diálogos
+O componente de ajuda carrega dinamicamente o arquivo `.ajuda.md` co-localizado (via import raw `?raw` ou serviço de documentação local) e o renderiza em diálogo limpo:
 
-* 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.
+```vue
+<!-- Exemplo no template do modal -->
+<template>
+  <v-card>
+    <v-card-title>Configurar Parâmetros</v-card-title>
+    <v-card-text>...</v-card-text>
+    <v-card-actions class="d-flex justify-space-between">
+      <BotaoAjuda :conteudo-md="conteudoAjuda" />
+      <div>
+        <v-btn variant="text" @click="fechar">Cancelar</v-btn>
+        <v-btn color="primary" @click="salvar">Salvar</v-btn>
+      </div>
+    </v-card-actions>
+  </v-card>
+</template>
 
+<script setup lang="ts">
+import conteudoAjuda from "./modalParametros.ajuda.md?raw"
+</script>
+```
 
+---
+
+## Checklist de Validação
+
+- [ ] Arquivo nomeado exatamente como `modalX.ajuda.md` para `modalX.vue`?
+- [ ] Arquivo co-localizado na mesma pasta do componente?
+- [ ] Texto em português claro, sem jargões de TI?
+- [ ] Botões, campos e fluxo passo a passo documentados?
+- [ ] Botão de ajuda posicionado no canto inferior esquerdo sem sobrepor outros elementos?

skills/aprimora-ia/SKILL.md

@@ -22,11 +22,16 @@ O conhecimento do agente está organizado em **três tipos de artefatos**, cada
 
 | 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 do Projeto** | — | `./.memoria-ia/` | Decisões de negócio, contexto do produto, especificações e ADRs (raiz do pai, versionado pelo pai) |
-| **Evoluções da IA** | `.agent/memory/` | — | Relatórios de sessões `/aprimora-ia`, otimizações dos agentes e melhorias da IA (versionado pelo submódulo) |
+| **Rules** | `.agent/rules/` | `.agent/rules/` | Restrições e convenções que o agente **deve respeitar sempre** |
+| **Workflows** | `.agent/workflows/` | `.agent/workflows/` | Processos sequenciais com passos numerados para tarefas bem definidas |
+| **Skills** | `.agent/skills/` | `.agent/skills/` | Guias operacionais completos e reutilizáveis para tarefas complexas recorrentes |
+| **Memória das Ações da IA** | — | `<base_projeto>/memorias-ia/` | Registros de sessões, otimizações dos agentes, decisões e relatórios da IA (raiz do pai) |
+
+> 🧩 **Polimorfismo do `.agent` e Personalização por Projeto**:
+> O `.agent` é polimórfico e genérico. A personalização de cada projeto específico é mantida fora do `.agent`:
+> - `./memorias-ia/` (na raiz do projeto pai): Registros de ações, sessões e decisões da IA.
+> - `../../wiki/<modulo>/`: Documentação funcional com acesso dos usuários na aplicação VitePress.
+> - `../../wiki/dev/<modulo>/`: Documentação técnica com acesso interno dev na aplicação VitePress.
 
 ### Diferenças entre os artefatos
 

skills/diagnosticar-lacunas-documentacao/SKILL.md

@@ -1,96 +1,104 @@
 ---
 name: diagnosticar-lacunas-documentacao
 description: >
-  Diagnóstico de lacunas de documentação: funções sem JSDoc, módulos sem
-  regras de negócio documentadas, documentação desatualizada.
-scope: local
+  Diagnóstico de lacunas de documentação cobrindo os 6 pilares: comentários de aplicação no código,
+  ajuda na tela (.ajuda.md), wiki de usuário, wiki dev, rota /llm.md e memórias da IA.
+scope: global
+updatedAt: "2026-09-01"
 ---
 
-# Skill: Diagnosticar Lacunas de Documentação
+# Skill: Diagnosticar Lacunas de Documentação e Memória
 
 ## Objetivo
 
-Identificar proativamente onde a documentação está ausente, incompleta ou desatualizada antes de criar ou corrigir documentação.
+Identificar proativamente onde a documentação e memórias estão ausentes, incompletas ou desatualizadas antes de criar ou corrigir código.
 
-## Etapas
+---
 
-### 1. Verificar JSDoc em Funções Compartilhadas
+## Etapas de Diagnóstico nos 6 Pilares
+
+### 1. Pilar 1 — Comentários e JSDoc no Código-Fonte
 
 ```sh
 # Listar funções exportadas sem JSDoc
-rg "^export (const|function|async function)" --include='*.ts' <modulo>-comuns/src/ -n | while read line; do
+rg "^export (const|function|async function)" --include='*.ts' <modulo>-comuns/src/ <modulo>-back/src/ -n | while read line; do
   file=$(echo "$line" | cut -d: -f1)
   lineno=$(echo "$line" | cut -d: -f2)
   prev=$((lineno - 1))
   if ! sed -n "${prev}p" "$file" | grep -q "*/"; then
-    echo "SEM JSDOC: $line"
+    echo "SEM JSDOC DE APLICAÇÃO: $line"
   fi
 done
 ```
 
-### 2. Verificar Regras de Negócio Documentadas
+### 2. Pilar 2 — Ajuda na Tela (UI) em `.ajuda.md`
 
 ```sh
-# Listar módulos com lógica complexa
-rg "if.*&&|switch|\.length\s*>" --include='*.ts' <modulo>-back/src/servicos/ -c | awk -F: '$2>5' | sort -t: -k2 -rn
-
-# Verificar quais têm .regras-negocio.md
-fd ".regras-negocio.md" <modulo>/ -l
-
-# Detectar lógica complexa sem documentação de regras
-# (comparar os dois resultados acima)
+# Listar modais/telas Vue que não possuem arquivo .ajuda.md correspondente
+find <modulo>-front/src -name "modal*.vue" -o -name "Modal*.vue" | while read vueFile; do
+  dir=$(dirname "$vueFile")
+  base=$(basename "$vueFile" .vue)
+  ajudaFile="$dir/$base.ajuda.md"
+  if [ ! -f "$ajudaFile" ]; then
+    echo "MODAL SEM AJUDA: $vueFile → falta $base.ajuda.md"
+  fi
+done
 ```
 
-### 3. Verificar Documentação de API
+### 3. Pilar 3 — Wiki do Usuário (`../../wiki/<modulo>/`)
 
 ```sh
-# Listar rotas sem comentário explicativo
-rg "router\.(get|post|put|patch|delete)" --include='*.ts' <modulo>-back/src/rotas/ -n
-
-# Verificar quais rotas têm JSDoc
-rg "/\*\*" --include='*.ts' <modulo>-back/src/rotas/ -c
+# Verificar se existe documentação de usuário do módulo
+ls -la ../../wiki/<modulo>/*.md 2>/dev/null || echo "WIKI DE USUÁRIO AUSENTE EM ../../wiki/<modulo>/"
 ```
 
-### 4. Detectar Dessincronia Código ↔ Docs
+### 4. Pilar 4 — Wiki de Desenvolvimento (`../../wiki/dev/<modulo>/`)
 
 ```sh
-# Buscar campos mencionados em .regras-negocio.md que não existem no código
-# (verificação manual por arquivo)
-
-# Buscar decisões técnicas que deveriam estar na Memória
-rg "DECISÃO|ADR|NOTA|IMPORTANTE" --include='*.ts' --include='*.md' <modulo>/ -n
+# Verificar se existe documentação de desenvolvimento, regras de negócio ({modulo}.regras-negocio.md) e ADRs
+ls -la ../../wiki/dev/<modulo>/*.md 2>/dev/null || echo "WIKI DEV AUSENTE EM ../../wiki/dev/<modulo>/"
 ```
 
-### 5. Gerar Relatório
+### 5. Pilar 5 — Rota de Integração de IA (`/llm.md`)
+
+```sh
+# Verificar se o backend possui a rota /llm.md registrada
+rg "llm\.md" --include='*.ts' <modulo>-back/src/ -n || echo "ROTA /llm.md NÃO ENCONTRADA NO BACKEND"
+```
+
+### 6. Pilar 6 — Memória das Ações da IA (`<base_projeto>/memorias-ia/`)
+
+```sh
+# Verificar memórias registradas para o projeto
+ls -la memorias-ia/ 2>/dev/null || echo "DIRETÓRIO memorias-ia/ NÃO ENCONTRADO NA RAIZ DO PROJETO"
+```
+
+---
+
+## Relatório Consolidado de Diagnóstico
 
 ```markdown
-# Diagnóstico de Documentação — [nome do módulo]
+# Diagnóstico de Documentação e Memória — [Módulo]
 
-## Resumo
-- **Funções compartilhadas sem JSDoc:** N
-- **Módulos complexos sem .regras-negocio.md:** N
-- **Rotas sem documentação:** N
+## Resumo dos 6 Pilares
+- **Código-fonte sem JSDoc de aplicação:** N
+- **Modais/Telas sem .ajuda.md co-localizado:** N
+- **Wiki de Usuário (../../wiki/<modulo>/):** Presente / Ausente
+- **Wiki de Desenvolvimento (../../wiki/dev/<modulo>/):** Presente / Ausente
+- **Rota /llm.md no backend:** Configurada / Ausente
+- **Registros em memorias-ia/:** N registros
 
-## Lacunas Encontradas
-
-### 🔴 Crítico — Lógica Complexa Não Documentada
-| Arquivo | Complexidade | O que documentar |
-|---------|-------------|-----------------|
-
-### 🟡 Moderado — JSDoc Ausente
-| Arquivo | Função | Tipo |
-|---------|--------|------|
-
-### 🟢 Baixo — Melhorias
-| Arquivo | O que melhorar |
-|---------|---------------|
-
-## Plano de Documentação (priorizado)
+## Ações Recomendadas
 1. ...
 ```
 
+---
+
 ## Referências
 
-- Rule: `global/rules/diagnostico-antes-correcao`
-- Rule: `global/rules/jsdoc-padrao`
-- Rule: `global/rules/regras-negocio-md`
+- Rule: `rules/ddd-documentacao-primeiro.md`
+- Rule: `rules/jsdoc-padrao.md`
+- Rule: `rules/regras-negocio-md.md`
+- Skill: `skills/adicionar-ajuda/SKILL.md`
+- Skill: `skills/documentar-dominio-modulo/SKILL.md`
+- Skill: `skills/documentar-decisao-tecnica/SKILL.md`

skills/doc/SKILL

@@ -0,0 +1,21 @@
+---
+name: doc
+description: Alias rápido para /documentacao - acionar o Agente de Documentação & Memória
+scope: global
+updatedAt: "2026-09-01"
+---
+
+# Skill: /doc (Alias para /documentacao)
+
+Atalho rápido para o **Agente de Documentação & Memória** cobrindo os 6 pilares canônicos:
+
+> ⚡ **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$ `../../wiki/<modulo>/` (VitePress com acesso dos usuários)
+- `4. Wiki Dev` $\rightarrow$ `../../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/`
+
+Para ver a documentação completa e exemplos, consulte [`skills/documentacao/SKILL.md`](file:///home/luiz/Arquivos/DEV/Industria/SIGMA2026/.agent/skills/documentacao/SKILL.md).

skills/doc/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: doc
+description: Alias rápido para /documentacao - acionar o Agente de Documentação & Memória
+scope: global
+updatedAt: "2026-09-01"
+---
+
+# Skill: /doc (Alias para /documentacao)
+
+Atalho rápido para o **Agente de Documentação & Memória** cobrindo os 6 pilares canônicos:
+
+> ⚡ **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$ `../../wiki/<modulo>/` (VitePress com acesso dos usuários)
+- `4. Wiki Dev` $\rightarrow$ `../../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/`
+
+Para ver a documentação completa e exemplos, consulte [`skills/documentacao/SKILL.md`](file:///home/luiz/Arquivos/DEV/Industria/SIGMA2026/.agent/skills/documentacao/SKILL.md).

skills/documentacao/SKILL

@@ -0,0 +1,69 @@
+---
+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
+scope: global
+updatedAt: "2026-09-01"
+---
+
+# 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 `../../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 `../../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 em `<base_projeto>/memorias-ia/`.
+
+---
+
+## 🏛️ 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** | `../../wiki/<modulo>/` | Usuários / Clientes | Aplicação VitePress com acesso dos usuários (manuais, tutoriais e fluxos). |
+| **4. Wiki de Desenvolvimento** | `../../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 | Registros de sessões, otimizações executadas e decisões históricas. |
+
+---
+
+## 🚀 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)
+/documentacao wiki-usuario <modulo>
+
+# Documentar regras de negócio na Wiki Dev (VitePress)
+/documentacao regras <caminho/servico.ts>
+
+# Criar um ADR na Wiki Dev
+/documentacao adr "<Título da Decisão>"
+```
+
+---
+
+## 🔒 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 `../../wiki/`.

skills/documentacao/SKILL.md

@@ -0,0 +1,69 @@
+---
+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
+scope: global
+updatedAt: "2026-09-01"
+---
+
+# 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 `../../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 `../../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 em `<base_projeto>/memorias-ia/`.
+
+---
+
+## 🏛️ 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** | `../../wiki/<modulo>/` | Usuários / Clientes | Aplicação VitePress com acesso dos usuários (manuais, tutoriais e fluxos). |
+| **4. Wiki de Desenvolvimento** | `../../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 | Registros de sessões, otimizações executadas e decisões históricas. |
+
+---
+
+## 🚀 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)
+/documentacao wiki-usuario <modulo>
+
+# Documentar regras de negócio na Wiki Dev (VitePress)
+/documentacao regras <caminho/servico.ts>
+
+# Criar um ADR na Wiki Dev
+/documentacao adr "<Título da Decisão>"
+```
+
+---
+
+## 🔒 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 `../../wiki/`.

skills/documentar-decisao-tecnica/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: documentar-decisao-tecnica
 scope: global
-updatedAt: "2026-06-01"
+updatedAt: "2026-09-01"
 description: >
-  Guia operacional para registrar decisões técnicas e arquiteturais como ADRs (Architecture Decision Records).
+  Guia operacional para registrar decisões técnicas e arquiteturais como ADRs (Architecture Decision Records) na Wiki de Desenvolvimento (../../wiki/dev/<modulo>/adrs/).
 ---
 
 # Skill: Documentar Decisão Técnica (ADR)
@@ -17,23 +17,23 @@ O objetivo é garantir que **nenhuma decisão fique apenas na cabeça** ou perdi
 ## 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 padrão arquitetural (ex: de REST para GraphQL, uso de BullMQ, schemas Zod)
+- Escolha de ferramenta ou biblioteca entre alternativas
+- Decisão de breaking change de contrato
+- Migração de tecnologia ou banco de dados
 - Mudança de estratégia de deploy ou CI/CD
-- Qualquer decisão que alguém pode questionar daqui 3 meses
+- Qualquer decisão técnica relevante para o time ou para a IA
 
 ---
 
-## PASSO 1 — Criar o Diretório de ADRs (se não existir)
+## PASSO 1 — Localizar o Diretório de ADRs
+
+Convenção de diretório: `../../wiki/dev/<modulo>/adrs/` (na Wiki de Desenvolvimento) ou `.agent/DOCUMENTACAO/arquitetura/`.
 
 ```bash
-mkdir -p .docs/adrs
+mkdir -p ../../wiki/dev/<modulo>/adrs
 ```
 
-Convenção de diretório: `.docs/adrs/` na raiz do monorepo.
-
 ---
 
 ## PASSO 2 — Criar o Arquivo ADR
@@ -110,10 +110,10 @@ 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/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 |
+| 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/` |
+| Registra histórico de ação da IA | Gravar na memória em `<base_projeto>/memorias-ia/` |
 
 ---
 
@@ -152,10 +152,14 @@ Antes de considerar completo:
 - [ ] 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?
+- [ ] O ADR foi salvo em `../../wiki/dev/<modulo>/adrs/` ou `.agent/DOCUMENTACAO/arquitetura/`?
+- [ ] A decisão foi registrada na memória em `<base_projeto>/memorias-ia/`?
 - [ ] Alguém de fora do contexto entenderia este ADR?
 
+---
+
 ## Referências
 
-- Workflow: `global/workflows/aprimorar-IA` (seção de classificação de artefatos)
-- Workflow: `global/workflows/otimizar-codigos`
+- Rule: `rules/ddd-documentacao-primeiro.md`
+- Workflow: `global/workflows/aprimora-ia.md`
+- Wiki de Desenvolvimento: `../../wiki/dev/<modulo>/adrs/`

skills/documentar-dominio-modulo/SKILL.md

@@ -1,18 +1,19 @@
 ---
 name: documentar-dominio-modulo
 scope: global
-updatedAt: "2026-06-01"
+updatedAt: "2026-09-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.
+  Guia para documentar o domínio científico/técnico de cada módulo nas wikis
+  de usuário (../../wiki/<modulo>/) e de desenvolvimento (../../wiki/dev/<modulo>/).
 ---
 
 # 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.
+Cada módulo opera em uma disciplina diferente da ciência/gestão ambiental (licenciamento, efluentes, bombeamento, resíduos, projetos, etc.). O repositório `../../wiki` é uma **aplicação VitePress**, onde a base factual do domínio é estruturada em dois níveis de acesso:
+1. **Wiki do Usuário (`../../wiki/<modulo>/`):** Aplicação VitePress com **acesso dos usuários e clientes** (linguagem funcional, conceitos, glossário, fluxos e manuais operacionais).
+2. **Wiki de Desenvolvimento (`../../wiki/dev/<modulo>/`):** Aplicação VitePress com **acesso interno exclusivo da equipe de desenvolvimento e arquitetura** (arquitetura técnica, diagramas, modelos de banco, regras de negócio e ADRs).
 
 ---
 
@@ -20,112 +21,82 @@ Cada módulo opera em uma disciplina diferente da ciência/gestão ambiental (li
 
 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 |
+| Exemplo de módulo | Domínio | Destino Usuário | Destino Dev |
+|---|---|---|---|
+| SIGMA | Monitoramento ambiental (efluentes, piezometria, bombeamento) | `../../wiki/e-licencie.sigma/` | `../../wiki/dev/e-licencie.sigma/` |
+| Licenciamento | Gestão de licenças (LP, LI, LO, condicionantes) | `../../wiki/e-licencie/` | `../../wiki/dev/e-licencie/` |
+| Resíduos | Gestão de resíduos sólidos (PGRS, MTR, MTR-e) | `../../wiki/e-licencie.residuos/` | `../../wiki/dev/e-licencie.residuos/` |
+| Qualificação | Qualificação e conformidade de fornecedores | `../../wiki/e-licencie.qualifica/` | `../../wiki/dev/e-licencie.qualifica/` |
 
 ---
 
-## PASSO 2 — Criar o Arquivo de Domínio
+## PASSO 2 — Criar Documentação na Wiki do Usuário (`../../wiki/<modulo>/`)
 
-Criar documento no arquivo `.regras-negocio.md` do módulo:
+Estruturar o guia do usuário e conceitos de negócio em linguagem clara e acessível:
 
 ```markdown
-# Domínio: <Nome do Módulo>
+# [Nome do Módulo] — Guia do Usuário
 
-## Área de Conhecimento
-Breve descrição da disciplina (1-3 linhas).
-
-## Glossário do Módulo
+## Visão Geral
+Breve descrição do propósito do módulo para o gestor e operador.
 
+## Glossário do Domínio
 | 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 |
-| ... | ... | ... |
+| Ponto de Monitoramento | Local físico onde são coletadas amostras | PM |
+| Parâmetro Ambiental | Variável físico-química monitorada (ex: DBO, DQO) | — |
 
-## 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" |
+## Fluxos Operacionais do Usuário
+1. Cadastro de pontos de monitoramento.
+2. Lançamento e importação de medições.
+3. Emissão de relatórios e acompanhamento de conformidade.
 ```
 
 ---
 
-## PASSO 3 — Validar com o Operador
+## PASSO 3 — Criar Documentação na Wiki de Desenvolvimento (`../../wiki/dev/<modulo>/`)
 
-Antes de consolidar:
+Estruturar a especificação técnica, modelos de banco e arquitetura:
 
-- [ ] 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?
+```markdown
+# [Nome do Módulo] — Arquitetura e Engenharia
+
+## Modelo de Dados e Entidades
+- **Tabelas principais:** `sigma_pontos`, `sigma_medicoes`, `sigma_parametros`
+- **Schemas Zod canônicos:** `zPontoCriar`, `zMedicaoRegistrar` em `*-comuns`
+
+## Processamento Assíncrono e Filas (BullMQ)
+- **Fila `calcular_agenda`:** Recalcula status e prazos de monitoramento.
+
+## Rotas e Integração de IA
+- **Rota `/llm.md`:** Disponibiliza catálogo dinâmico de endpoints e contratos.
+```
 
 ---
 
-## PASSO 4 — Conectar com as Rules
+## PASSO 4 — Conectar com Código e UI
 
-Após documentar o domínio:
-
-1. Verificar se labels e mensagens no código usam o vocabulário definido (rule `mensagens-usuario`)
-2. Verificar se schemas Zod têm mensagens de erro no idioma do domínio (rule `zod-validacao-padrao`)
-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`)
+1. Verificar se mensagens e labels na UI seguem o vocabulário definido (rule `mensagens-usuario`).
+2. Verificar se componentes e modais Vue possuem `modalX.ajuda.md` co-localizado (skill `adicionar-ajuda`).
+3. Garantir que funções centrais e serviços possuem comentários claros de aplicação (rule `jsdoc-padrao`).
+4. Assegurar que regras com 3+ critérios possuam `.regras-negocio.md` co-localizado (rule `regras-negocio-md`).
 
 ---
 
 ## Checklist Final
 
-- [ ] Arquivo `.regras-negocio.md` do módulo criado e validado?
-- [ ] 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?
+- [ ] Documentação de usuário criada/atualizada em `../../wiki/<modulo>/`?
+- [ ] Documentação técnica criada/atualizada em `../../wiki/dev/<modulo>/`?
+- [ ] Glossário com os termos centrais do domínio documentado?
+- [ ] Regras e entidades técnicas alinhadas com os schemas Zod do `*-comuns`?
+- [ ] Rota `/llm.md` no backend reflete o módulo?
+
+---
 
 ## Referências
 
-- Rule: `global/rules/mensagens-usuario`
-- Rule: `global/rules/regras-negocio-md`
-- Workflow: `agents/comercial/workflows/comercial`
-- Workflow: `agents/front/workflows/adicionar-ajuda`
+- Rule: `rules/ddd-documentacao-primeiro.md`
+- Rule: `rules/jsdoc-padrao.md`
+- Rule: `rules/regras-negocio-md.md`
+- Skill: `skills/adicionar-ajuda/SKILL.md`
+

skills/documentar-regras-negocio/SKILL.md

@@ -1,15 +1,13 @@
 ---
-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
+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"
+updatedAt: "2026-09-01"
 ---
 
-# Workflow: Documentar Regras de Negócio de um Módulo
+# Workflow / Skill: 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` de qualquer módulo TypeScript com lógica de negócio não-trivial.
+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>/`.
 
 ---
 
@@ -17,20 +15,20 @@ Use este workflow com `/documentar-regras-negocio.global` para criar ou atualiza
 
 Identificar e anotar:
 
-- Nome do arquivo e localização exata
+- 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, e-mails, serviços)
+- Dependências externas (filas BullMQ, e-mails, serviços)
 
 ---
 
-[2] Verificar se já existe um `.regras-negocio`
+[2] Verificar se já existe a documentação de regras na Wiki de Desenvolvimento
 
 ```bash
-ls $(dirname <arquivo>)/*.regras-negocio.md 2>/dev/null
+ls ../../wiki/dev/<modulo>/*regras-negocio*.md 2>/dev/null
 ```
 
 - **Existe** → ler e identificar o que está desatualizado → ir para o passo [4]
@@ -38,17 +36,17 @@ ls $(dirname <arquivo>)/*.regras-negocio.md 2>/dev/null
 
 ---
 
-[3] Criar o arquivo `.regras-negocio`
+[3] Criar o arquivo de regras na Wiki de Desenvolvimento
 
-Nomenclatura: `{nome-sem-_inicial}.regras-negocio` na mesma pasta do módulo.
+**Localização:** `../../wiki/dev/<modulo>/{nome-do-modulo}.regras-negocio.md` (ou `../../wiki/dev/<modulo>/regras-negocio/`).
 
-Preencher com o template da skill `documentar-regras-negocio.global`:
-- Contexto
+Preencher com a estrutura padrão:
+- Contexto operacional
 - Critérios de Entrada
-- Regras de Processamento (numeradas)
+- Regras de Processamento (numeradas em ordem estrita)
 - Casos de Revisão Manual
-- Estratégia de Saída / Fusão de Campos
-- Dependências Externas
+- Estratégia de Saída / Persistência de Campos
+- Dependências Externas (tabelas, filas, CRONs)
 
 ---
 
@@ -57,30 +55,31 @@ Preencher com o template da skill `documentar-regras-negocio.global`:
 Garantir que a primeira linha útil do arquivo TypeScript seja:
 
 ```typescript
-// Regras de negócio: ver {modulo}.regras-negocio.md
+// Regras de negócio: ver ../../wiki/dev/<modulo>/{modulo}.regras-negocio.md
 ```
 
 Se já existia e está correto → sem mudança necessária.
 
 ---
 
-[5] Simplificar JSDoc que duplicam as regras
+[5] Estruturar JSDoc com aplicação prática e referência ao `.regras-negocio.md`
 
 Percorrer cada função do módulo:
 
-- JSDoc com lista de regras de negócio → substituir por referência ao ``
-- Manter apenas `@param` e `@returns` com informação técnica precisa
-- Comentários inline (`//`) explicando lógica pontual são aceitos → manter
+- 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.
 
 ---
 
-[6] Verificar consistência — código ↔ ``
+[6] Verificar consistência — código ↔ `.regras-negocio.md`
 
-Para cada regra listada no ``:
+Para cada regra listada no `.regras-negocio.md`:
 
 - [ ] Existe `if` correspondente no código
-- [ ] A ordem de avaliação bate entre `` e código
-- [ ] Campos com separador de concatenação batem entre `` e 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
 
@@ -97,9 +96,10 @@ Zero erros = concluído.
 
 ---
 
-[8] Registrar no sistema de conhecimento (se regras novas)
+[8] Sincronizar com a Wiki de Desenvolvimento e Memórias
 
-Se o workflow revelou novos padrões de negócio relevantes ao projeto:
+Se o módulo introduziu ou alterou arquitetura ou regras consolidadas do módulo:
 
-- Criar ou atualizar ADR via skill `documentar-decisao-tecnica`
-- Verificar se alguma rule precisa ser atualizada
+- 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/`.