chore(agent): remover permissoes de commit da IA no projeto e wiki (apenas sugerir texto) e manter push automatico exclusivo no .agent
This commit is contained in:
parent
212d2578f4
commit
26a4f98dab
116 changed files with 1162 additions and 1315 deletions
|
|
@ -1,39 +0,0 @@
|
|||
# Registro de Otimizações da Sessão — Aprimoramento da IA
|
||||
|
||||
**Data:** 10/08/2026
|
||||
**Sessão / Contexto:** Resolução de inconsistências de histórico de eventos, consultas SQL de banco e formatação visual no módulo Qualifica (Empresa / Formulários / Avaliação).
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principais Aprendizados e Regras Consolidadas
|
||||
|
||||
### 1. Escopo e Filtragem de Histórico (Avaliação Pai vs Formulário)
|
||||
- O histórico da **Avaliação Pai** deve exibir estritamente eventos cujo `tabela_origem === 'avaliacoes'`.
|
||||
- O histórico de um **Formulário específico** deve exibir eventos do próprio formulário E de todos os seus campos associados (`ev.codigo_origem === formId || ev.codigo_resposta_formulario === formId`).
|
||||
|
||||
### 2. Esquema do Banco PostgreSQL (`respostas_avaliacao`)
|
||||
- A tabela `respostas_avaliacao` **não possui** a coluna `codigo_resposta_formulario`.
|
||||
- Consultas Knex não devem selecionar nem filtrar diretamente por `codigo_resposta_formulario` nessa tabela (evita erro SQL `42703` `errorMissingColumn`).
|
||||
- O relacionamento entre respostas de campo e formulários deve ser resolvido via `codigo_avaliacao` e mapeado em memória usando a hierarquia de seções/perguntas de `todasPerguntas`.
|
||||
|
||||
### 3. Cores Dinâmicas e Identidade Visual dos Status
|
||||
- Os badges e ícones de status em linhas do tempo devem consumir as propriedades de cores dinâmicas (`cor`, `textoCor`, `corVuetify`) exportadas por `qualifica-comuns` (`statusFormularioDetalhes`, `statusAvaliacaoMacroDetalhes`, `classificacaoRespostaDetalhes`).
|
||||
- Cores estáticas ou *hardcoded* (como fundo azul fixo `#EBF8FF` ou verde fallback `#688C00`) são proibidas para status com cores do domínio.
|
||||
|
||||
### 4. Formatação de Textos de Eventos (Quebras de Linha e Nomes)
|
||||
- Textos de descrição e justificativa em cartões e timelines de eventos devem conter explicitamente as regras CSS:
|
||||
`white-space: pre-wrap; word-break: break-word; line-height: 1.5;`
|
||||
- Nomes de autores devem ser sanitizados para remover marcas repetidas (ex: `(Sistema)` prefixado indevidamente).
|
||||
|
||||
### 5. Botão de Histórico Universal por Campo
|
||||
- O componente `CampoRespostaBase.vue` (invocado por todos os tipos de entrada de campo) contém um botão universal `<History />` com tooltip `"Ver histórico do campo"`.
|
||||
- O modal `ModalHistoricoEventos.vue` aceita `:eventos-direct` para renderizar o histórico diretamente da memória do componente quando pre-carregado.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist de Verificação de Artefatos
|
||||
|
||||
- [x] Artefatos dependentes revisados
|
||||
- [x] Nenhuma regra ficou implícita
|
||||
- [x] Referências cruzadas e linters validados (`pnpm run biome`, `tsc --noEmit`)
|
||||
- [x] Nomes de funções e variáveis mantidos conforme contratos
|
||||
|
|
@ -1,40 +0,0 @@
|
|||
---
|
||||
titulo: "Aprimoramento do Ecossistema .agent e Compatibilidade com Antigravity Skills & Rules"
|
||||
data: "2026-08-10"
|
||||
categoria: "otimizacao-ia"
|
||||
tipo: "relatorio-sessao"
|
||||
autor: "@agente"
|
||||
---
|
||||
|
||||
# Registro de Aprimoramento da IA — Sessão 2026-08-10
|
||||
|
||||
## 🎯 Objetivo
|
||||
Resolver a incompatibilidade na invocação do workflow `/aprimorar-ia` e garantir o reconhecimento nativo de todas as regras, skills e workflows pelo Antigravity IDE/CLI.
|
||||
|
||||
## 📋 Diagnóstico Realizado
|
||||
1. **Extensão `.md` ausente**:
|
||||
- Os arquivos em `.agent/global/rules/` e `.agent/agents/*/rules/` não continham a extensão `.md`.
|
||||
- As habilidades em `.agent/global/skills/*/` possuíam arquivos `SKILL` sem a extensão `.md`.
|
||||
- O Antigravity ignora arquivos de customização sem a extensão `.md` explícita (`SKILL.md` para skills, `*.md` para regras).
|
||||
|
||||
2. **Estrutura de pastas**:
|
||||
- O Antigravity realiza indexação nativa das regras em `.agent/rules/*.md` e skills em `.agent/skills/<skill>/SKILL.md`.
|
||||
|
||||
## 🛠️ Modificações Aplicadas
|
||||
1. **Normalização dos arquivos em `.agent`**:
|
||||
- Todas as 26 regras foram renomeadas com a extensão `.md` e mapeadas em `.agent/rules/`.
|
||||
- Todas as 27 skills/workflows foram normalizadas com `SKILL.md` em `.agent/skills/`.
|
||||
- Atualizado o arquivo `.agent/manifesto.json` para refletir as extensões `.md`.
|
||||
|
||||
2. **Atualização da Documentação**:
|
||||
- Atualizado `AGENTS.md` alinhando os nomes dos workflows (`aprimorar-ia` e `aprimora-ia`).
|
||||
|
||||
3. **Duas camadas de memória ativas**:
|
||||
- Mantida e estruturada a pasta `./.memoria-ia/` na raiz do repositório pai para regras de negócio e ADRs.
|
||||
- Registrado este relatório em `.agent/memory/` e em `./.memoria-ia/diario/`.
|
||||
|
||||
## ✅ Checklist de Verificação Final
|
||||
- [x] Artefatos dependentes revisados
|
||||
- [x] Ausência de conflitos entre regras e skills
|
||||
- [x] Referências cruzadas válidas e testadas
|
||||
- [x] Staging git realizado em `.agent`
|
||||
|
|
@ -1,23 +0,0 @@
|
|||
---
|
||||
titulo: "Evolução do Ecossistema AGENT-IA e Arquitetura de Memória em Duas Camadas"
|
||||
data: "2026-08-10"
|
||||
categoria: "decisoes"
|
||||
tipo: "adr"
|
||||
autor: "@agente"
|
||||
---
|
||||
|
||||
# Registro de Evolução da IA — Sessão 2026-08-10
|
||||
|
||||
## 🎯 Arquitetura de Memória em Duas Camadas
|
||||
|
||||
Estabelecida a separação formal de armazenamento de memórias entre o projeto pai e o submódulo `.agent`:
|
||||
|
||||
1. **`./.memoria-ia/` (na raiz do projeto pai):** Armazena as **memórias do projeto** (decisões de negócio, contexto do produto, especificações funcionais e ADRs). Versionada no repositório do projeto pai.
|
||||
2. **`.agent/memory/` (no submódulo `.agent`):** Armazena as **evoluções da IA** (registros de sessões `/aprimora-ia`, otimizações dos agentes e melhorias da arquitetura multiagente). Versionada diretamente no repositório do submódulo.
|
||||
|
||||
## 📋 Aprimoramentos Executados na Sessão
|
||||
|
||||
- Simplificação de handles (`@ag-*` → `@*`).
|
||||
- Exclusão do módulo `adaptadores/` e scripts legados.
|
||||
- Expulsa integração externa de API, adotando armazenamento em arquivos Markdown.
|
||||
- Auditoria e unificação de 11 agentes e 46 arquivos de documentação (máximo 250 linhas).
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
# Registro de Otimizações da Sessão — Aprimoramento da IA (Parte 2)
|
||||
|
||||
**Data:** 11/08/2026
|
||||
**Sessão / Contexto:** Eliminação de erros de consulta à tabela removida `usuarios` (`select "codigo", "nome", "categoria"` - `code 42703`) e padronização da integração via SSO (`e-licencie.drive`).
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principais Aprendizados e Regras Consolidadas
|
||||
|
||||
### 1. Gestão de Usuários e Perfis via `e-licencie.drive` (SSO)
|
||||
- A tabela `usuarios` **não existe** no banco de dados PostgreSQL local dos schemas dos inquilinos. A identificação, listagem e auditoria de usuários (operadores e usuários externos da categoria `externo`) são providas exclusivamente pelo pacote `p-e-licencie-drive` (`eliDrive`).
|
||||
- É **estritamente proibido** realizar chamadas `knex("usuarios")` ou `knex(enumTabelas.usuarios)`. Toda consulta de usuários em endpoints ou tarefas em segundo plano (CRON) deve invocar `eliDrive({ token }).listarUsuarios()`.
|
||||
|
||||
### 2. Tratamento de Depreciação e Tabela Undefined no Knex
|
||||
- Ao chamar `knex(prop)` quando `prop` é `undefined`, o Knex executa `knex()` sem nome de tabela, emitindo o aviso de depreciação `calling knex without a tableName is deprecated. Use knex.queryBuilder() instead` e gerando queries SQL inválidas (`SELECT ...` sem cláusula `FROM`).
|
||||
- Qualquer utilitário ou tabela que tenha sido removida do esquema deve ter suas referências completamente limpas da biblioteca `qualifica-comuns` (em `_tabelas_registros.ts`) para evitar que a chave acesse propriedades `undefined` via Proxy.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist de Verificação de Artefatos
|
||||
|
||||
- [x] Artefatos dependentes revisados
|
||||
- [x] Nenhuma regra ficou implícita
|
||||
- [x] Referências cruzadas e linters validados (`pnpm run biome`, `npx tsx`)
|
||||
- [x] Padrão `eliDrive` unificado em todas as rotas de listagem de eventos e tarefas de envio de e-mail
|
||||
|
|
@ -1,29 +0,0 @@
|
|||
# Registro de Otimizações da Sessão — Aprimoramento da IA
|
||||
|
||||
**Data:** 11/08/2026
|
||||
**Sessão / Contexto:** Resolução de erro de "Acesso Negado — Você não possui permissão" ao acessar a rota pública `/publico/painel-empresa/:token/avaliacao/:id` do Qualifica.
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principais Aprendizados e Regras Consolidadas
|
||||
|
||||
### 1. Distinção entre Eventos Operacionais/Notificações e Eventos de Status Macro
|
||||
- A tabela `eventos` registra múltiplos tipos de eventos associados a uma avaliação (`tabela_origem = 'avaliacoes'`), incluindo tanto mudanças de **status macro** (`rascunho`, `aberta`, `correcao_solicitada`, `aprovada`, `aprovada_ressalvas`, `reprovada`, `vencida`, `cancelada`) quanto **notificações/auditorias operacionais** (`alerta_prazo`, `acesso_painel`, `acesso_formulario`).
|
||||
- Toda consulta SQL / Knex que determine o `statusAtual` de uma avaliação a partir da tabela `eventos` **DEVE** conter obrigatoriamente a restrição `.whereIn("status", zStatusAvaliacaoMacro.options)` (ou no SQL: `AND ev.status IN (...)`).
|
||||
|
||||
### 2. Validação Estrita de Schemas Zod em Rotas Públicas (`zApiPublica`)
|
||||
- A rota pública `publico_painel_empresa_detalhe` e `publica_formulario_perguntas` utilizam o schema `zStatusAvaliacaoMacro` para validar o campo `status_avaliacao` no payload de resposta.
|
||||
- Caso a consulta ao banco retorne um evento operacional como `'alerta_prazo'`, a validação Zod falha com `ZodError`, forçando o wrapper da API a retornar `{ eErro: true }`. No frontend, isso se traduz no fallback de erro `token_invalido` ("Acesso Negado"), disfarçando um erro de schema do backend como uma falha de autenticação.
|
||||
- **Regra:** Todo valor retornado para o frontend em um campo validado por enum Zod DEVE ser sanitizado e validado defensivamente contra os membros do enum (`zStatusAvaliacaoMacro.options`) antes de ser montado no objeto de resposta.
|
||||
|
||||
### 3. Tracing de Diagnóstico Prévia a Qualquer Modificação
|
||||
- Conforme a regra `diagnostico-antes-correcao.md`, o agente investigou a causa raiz testando os componentes isoladamente (Token JWT -> Zod schema `zTokenPublico` -> Query Knex -> Zod schema `zApiPublica`). Isso permitiu identificar exatamente a linha onde o `ZodError` ocorria (`zStatusAvaliacaoMacro`), evitando refatorações desnecessárias em autenticação ou rotas Vue Router.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist de Verificação de Artefatos
|
||||
|
||||
- [x] Artefatos dependentes revisados
|
||||
- [x] Nenhuma regra ficou implícita
|
||||
- [x] Referências cruzadas e linters validados (`pnpm run biome`, `npx tsx`)
|
||||
- [x] Contratos Zod preservados e validados estritamente
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# Registro de Otimizações da Sessão — Aprimoramento da IA
|
||||
|
||||
**Data:** 18/08/2026
|
||||
**Sessão / Contexto:** Padronização do Parecer do Avaliador, Validação Pré-Envio de Avaliações, Modularização (<250 linhas) e Recálculo Global de Hashes `info`.
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principais Aprendizados e Regras Consolidadas
|
||||
|
||||
### 1. Recálculo Global e Cache de Hashes (`hash_INFOS.json`)
|
||||
- O controle de integridade e versão das funções geradoras de `info` (`qualifica-back/src/INFO`) é persistido no arquivo `DADOS-LOCAIS/controle/hash_INFOS.json` (resolvido por `caminhoLocal(["controle"], "hash_INFOS.json")`).
|
||||
- Para **forçar a reconstrução total** de todos os dados de `info` em todos os inquilinos e tabelas do sistema:
|
||||
- **Ação Direta:** Deletar o arquivo `DADOS-LOCAIS/controle/hash_INFOS.json` (ou `/hash_INFOS.json`).
|
||||
- **Ação via Fila (BullMQ):** Disparar o job passando o parâmetro `{ ignoreHash: true }`.
|
||||
- O worker `recalcular_todos_infos` gera novamente o arquivo de hashes ao término de uma varredura completa.
|
||||
- Documentação co-localizada: `qualifica-back/src/_FILAS/_recalcular_todos_infos.regras-negocio.md`.
|
||||
|
||||
### 2. Exibição e Formatação do Parecer do Avaliador no Painel da Empresa
|
||||
- Estrutura visual em 3 linhas:
|
||||
1. Identificação: `@<codigo>:` (onde `<codigo>` são os 8 primeiros caracteres do UUID do avaliador).
|
||||
2. Status/Ação: `Solicitado Correção`, `Reprovado` ou `Aprovado`.
|
||||
3. Texto do Parecer: mensagem preenchida pelo avaliador no evento de avaliação.
|
||||
- Bloqueio estrito de logs de sistema e transições automáticas (`PADROES_SISTEMA_BLOQUEADOS` e `STATUS_SEM_PARECER`).
|
||||
|
||||
### 3. Validação Pré-Envio vs. Progresso da Avaliação
|
||||
- `validarPayloadEExibirAlertaInvalido` não deve exigir preenchimento estrito de anexos para perguntas:
|
||||
- Já marcadas como `conforme`, `aprovado`, `nao_aplicavel` ou `isento`.
|
||||
- Opcionais (`obrigatorio: false`) com preenchimento parcial ou rascunho.
|
||||
- Permite que avaliações com 100% de progresso sejam transmitidas sem bloqueio falso de pendência.
|
||||
|
||||
### 4. Limite de Linhas e Modularização (Workflow `otimizar-codigos`)
|
||||
- Respeitado o limite de 250 linhas por arquivo em todo o módulo `qualifica`:
|
||||
- `PainelNivel3Campos.vue` (219 linhas) modularizado com `PainelNivel3Header.vue` (133 linhas).
|
||||
- `parecer-avaliador.ts` (182 linhas) modularizado com `parecer-avaliador-filtros.ts` (187 linhas).
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist de Verificação de Artefatos
|
||||
|
||||
- [x] Artefatos dependentes revisados
|
||||
- [x] Nenhuma regra ficou implícita
|
||||
- [x] Referências cruzadas e linters validados
|
||||
- [x] Memória do projeto e da IA atualizadas
|
||||
- [x] Build de produção verificado com sucesso (`exit code 0`)
|
||||
|
|
@ -1,33 +0,0 @@
|
|||
# Registro de Otimizações da Sessão — Aprimoramento da IA
|
||||
|
||||
**Data:** 26/08/2026
|
||||
**Sessão / Contexto:** Implementação do sistema de Alertas de Não Conformidade por Plano de Monitoramento, observância do enum `usuarioCategoria` / `usuario_categoria`, exclusão de usuários de sistema nos alertas, exibição de pontos e destinatários na tabela de planos, e otimizações de consultas na camada `info`.
|
||||
|
||||
---
|
||||
|
||||
## 📌 Principais Decisões e Padrões Consolidados
|
||||
|
||||
### 1. Destinatários de Alertas de Não Conformidade (`usuarios_notificacao`)
|
||||
- **Padrão de Entidade**: Os destinatários configurados em `agendamentos_planos` seguem a estrutura padronizada com `codigo_origem`, `codigo_usuario` (UUID do sistema), `canais: { email: boolean, push: boolean }`, snapshot em `info` e campos padrão de auditoria.
|
||||
- **Persistência JSONB**: Armazenados na coluna `usuarios_notificacao` de `agendamentos_planos`, indexados e consultáveis sem necessidade de tabela intermediária.
|
||||
|
||||
### 2. Tratamento de Categorias de Usuários e Exclusão de Contas de Sistema
|
||||
- **Enum Oficial**: A categoria de usuário do e-Licencie Drive segue o enum oficial `usuarioCategoria` (`zUsuarioCategoria`: `externo`, `suporte`, `usuario`).
|
||||
- **Exclusão de Contas de Sistema**: Ao listar destinatários para planos de monitoramento, contas de sistema (`usuario_categoria === 'sistema'` ou `categoria === 'sistema'`) são estritamente filtradas tanto no backend (`obterUsuarios` / `_usuarios_listar.ts`) quanto no frontend (`useSeletorUsuariosNotificacao.ts`), impedindo que contas de serviço/robô recebam alertas de campo.
|
||||
|
||||
### 3. Tabela de Planos de Monitoramento (`PaginaConsultaPlanos.tabela.ts`)
|
||||
- **Coluna `Pontos`**: Exibe diretamente os identificadores amigáveis e nomes dos pontos de monitoramento associados ao plano (ex: `P-01, P-02`), substituindo a contagem genérica anterior.
|
||||
- **Coluna `Destinatários`**: Exibe a lista dos nomes dos usuários configurados para receber alertas no plano com suporte a truncamento.
|
||||
|
||||
### 4. Otimização de Performance e Consultas via Camada `info`
|
||||
- **Busca Multifatorial Indexada**: O gerador de `info.texto_busca` em `_agendamentos_planos.ts` consolida o nome do plano, descrição, identificadores/nomes de pontos e nomes/e-mails de destinatários. Uma única busca `LIKE` sobre `info.texto_busca` resolve filtros em milissegundos sem JOINs.
|
||||
- **Eliminação de Consultas N+1**: O snapshot `info.pontos` armazena `{ codigo, id, nome }` de cada ponto no plano, permitindo renderização imediata de tabelas com uma única requisição.
|
||||
|
||||
---
|
||||
|
||||
## 🔍 Checklist de Verificação de Artefatos
|
||||
|
||||
- [x] Regras de negócio documentadas em `DOCUMENTAÇÃO/regras-negocio/notificacao-nao-conformidade-plano.md`
|
||||
- [x] Schemas Zod atualizados em `sigma-comuns` (`zUsuarioNotificacao`, `zInfoUsuarioNotificacao`, `zUsuarios`)
|
||||
- [x] Regra de limite de linhas (máximo 250 linhas) respeitada em todos os arquivos Vue/TS
|
||||
- [x] `tsc --noEmit` & `biome check` com 0 erros em todos os 4 pacotes (`comuns`, `migracao`, `back`, `front`)
|
||||
Loading…
Add table
Add a link
Reference in a new issue