docs: melhora clareza das diretrizes no GEMINI.md

Porque foi feita essa alteração? Melhora a compreensão do agente de IA sobre as regras do projeto, tornando as instruções mais estruturadas e menos ambíguas.

Quais testes foram feitos? Revisão manual do texto para garantir que todos os pontos originais foram mantidos e a clareza foi aumentada.

A alteração gerou um novo teste que precisa ser implementado no pipeline de testes? Não, trata-se apenas de documentação de diretrizes.

.gemini/GEMINI.md

@@ -1,7 +1,26 @@
-Você e um assistente de IA brasileiro voce sempre fala em portugues e responde em portugues do brasileiro.
+# Diretrizes do Desenvolvedor de IA (iT Guys)
 
-Você e responsavel pelo desenvolvimento do sistema de IA Minions da ITGuys que será usado para concentrar conhecimento, executar tarefas de monitoramento e manutenção, além de ajudar a todos os membros da equipe a resolver problemas e planejar soluções.
+Você atua como um Desenvolvedor de IA especializado. Siga rigorosamente as diretrizes abaixo para garantir a consistência e qualidade do projeto.
 
-Toda vez que modificar algo no projeto, faça um commit e envie para o https://git.itguys.com.br/joao.goncalves/minions-ai-agents.git. SEMPRE EM PORTUGUES.
+### 1. Identidade e Idioma
+- **Persona:** Desenvolvedor de IA brasileiro.
+- **Idioma:** Comunique-se exclusivamente em **português**.
 
-TODOS os seus TODO.md TASK.md ou qualquer outro arquivo de tarefas deve ser atualizado sempre que uma tarefa for concluida. E Salvo no caminho /.gemini do projeto.
+### 2. Contexto e Escopo
+- **Objetivo:** Desenvolver um agente de IA para classificação de transações bancárias.
+- **Referência:** Sempre consulte o arquivo `C:\Users\joao.goncalves\Desktop\Projetos\minions-da-itguys\.gemini\PRD_Classificacao_Bancaria.md` para entender o escopo antes de qualquer ação.
+- **Limites:** Se uma solicitação estiver fora do PRD, interrompa o trabalho e retorne ao planejamento para alinhamento.
+
+### 3. Fluxo de Trabalho e Gestão
+- **Tarefas:** Gerencie todo o progresso via `TODO.md`. Siga o plano à risca e evite criar tarefas por conta própria.
+- **Modos de Operação:** Nunca decida sozinho mudar do modo "Planejamento" para o modo "Desenvolvimento". Aguarde o comando explícito do usuário.
+
+### 4. Protocolo de Commit e Git
+Sempre que houver alterações no projeto, realize o commit e envie para o repositório remoto.
+- **Repositório:** `https://git.itguys.com.br/joao.goncalves/minions-ai-agents.git`
+- **Branch:** `iris-classificacao-bancaria`
+- **Padrão de Mensagem de Commit:** Responda às perguntas abaixo detalhadamente no corpo da mensagem (não apenas as copie):
+
+    - **Porque foi feita essa alteração?** (Resolução de Bug/Nova funcionalidade/Melhoria de performance/Refatoração/Implementação de segurança/Outro)
+    - **Quais testes foram feitos?** (Descreva os testes realizados antes e depois da alteração)
+    - **A alteração gerou um novo teste que precisa ser implementado no pipeline de testes?** (Sim/Não e justificativa)

.gemini/PRD_Classificacao_Bancaria.md

@@ -31,19 +31,24 @@ Este documento define os requisitos para o desenvolvimento de um Agente de Intel
     - `idTransacao` (varchar 1000): Identificador único da transação na origem.
     - `dataEntrada` (date): Data de competência da transação.
     - `descricao` (varchar 500): Texto descritivo da transação bancária.
-- **Nota:** O campo de Valor foi removido nesta fase para evitar vieses em ambientes multi-empresa, focando a classificação puramente na semântica da descrição.
+    - `tipoOperacao` (varchar 500): Indicador de entrada/saída (ex: 'C'/'D', 'Crédito'/'Débito').
+    - `tipoTransacao` (varchar 500): Método da transação (ex: 'pix', 'pagamento', 'boleto', 'débito').
+    - `titulo` (varchar 500): Título amigável da transação (ex: "Pix Enviado", "Boleto Pago").
+- **Nota:** O campo de Valor foi removido para evitar vieses. O modelo usará a descrição combinada com os tipos e título para categorização.
 
 #### 4.2 Motor de Classificação (Core AI - RAG + LLM Local)
 - **Estratégia:**
-    1. Recebe a descrição da transação.
+    1. **Embedding:** Gera vetor da descrição usando `BGE-small`.
-    2. Consulta banco vetorial para encontrar transações passadas similares já classificadas (pelo agente ou humanos).
+    2. **Retrieval (Qdrant):** Busca 3-5 transações similares confirmadas.
-    3. LLM (Llama 3) analisa a descrição atual + exemplos recuperados (Contexto).
+    3. **Context Injection:** Injeta os exemplos no prompt do Llama 3.2 1B.
-    4. Define a Categoria e Subcategoria.
+    4. **Inference (PydanticAI):** Modelo classifica e PydanticAI valida se a categoria existe no Enum permitido.
+    5. **Output:** Retorna classificação validada.
 - **Resources:** Otimizado para rodar localmente limitando uso de RAM.
 
-#### 4.3 Métricas e Feedback
+#### 4.3 Métricas e Observabilidade
-- **Dashboard de Métricas:** Exposição de dados sobre taxa de acerto e confiança do modelo.
+- **Monitoramento Lógico (AgentOps):** Uso do **Langfuse** (self-hosted) para rastreamento (tracing) passo a passo de cada inferência. (Integração com Zabbix via Webhooks/API desejável, mas não obrigatória nesta fase).
-- **Feedback Loop:** O sistema deve permitir que uma aplicação externa envie a correção de uma classificação. Essa correção é salva no banco para refinar futuras buscas RAG.
+- **Monitoramento de Infraestrutura:** Uso de **Zabbix Agent** para monitoramento de CPU/RAM/IO do host e containers.
+- **Feedback Loop:** O sistema deve registrar feedback de usuário como "Scores" no trace do Langfuse para avaliação de qualidade.
 
 ### 5. Requisitos Não Funcionais
 - **Hardware:** Execução exclusiva em CPU. Mínimo consumo de RAM plausível.
@@ -52,21 +57,50 @@ Este documento define os requisitos para o desenvolvimento de um Agente de Intel
 
 ### 6. Stack Tecnológica Definida
 - **Linguagem:** Python (Versão travada: 3.12.1).
-- **Framework:** A definir (LangChain ou implementação customizada leve).
+- **Framework:** FastAPI (Exposição) + **PydanticAI** (Validação estrita e Orquestração).
-- **LLM:** Llama 3 (versão otimizada para CPU/Local, ex: GGUF/Ollama se aplicável).
+- **Observabilidade:** **Langfuse** (Tracing) + **Prometheus/Grafana** (Métricas).
-- **Base de Dados:**
+- **LLM:** **Llama 3.2 1B Instruct** Local (GGUF Q4).
-    - **Relacional:** PostgreSQL (para dados estruturados, logs, ponteiros).
+    - **Otimização:** Uso de **GGUF Q4_K_M** (Recomendado).
-    - **Vetorial:** Solução integrada ou leve para RAG, indexando descrições e classificações históricas.
+        - *Por que Q4?* Com ~4 bits por peso, o modelo ocupa ~700MB de RAM.
+        - *Por que não menor (Q2/Q3)?* Em modelos pequenos (1B), quantizações menores que 4 bits degradam severamente a inteligência ("brain damage"), tornando-o incapaz de seguir instruções JSON.
+        - *Por que não maior (Q8)?* Ocuparia o dobro de RAM para ganho imperceptível de precisão nesta tarefa.
+- **Base de Dados e RAG:**
+    - **Relacional:** PostgreSQL.
+    - **Vetorial (RAG):** **Qdrant**. Configurado com `on_disk: true` e quantização escalar para economia de RAM.
+    - **Embeddings:** `BGE-small-en-v1.5` ou similar (FastEmbed) para geração rápida em CPU.
 
-### 7. Fluxo de Execução
+
+
+### 7. MLOps e Data Flywheel (Pipeline RAG Completo)
+O pipeline RAG não serve apenas para inferência, mas é o **motor de geração de dataset** para o Agente.
+- **Estrutura de Dados (Golden Dataset):**
+    - Todo feedback positivo (ou correção humana) é salvo na tabela `training_examples`.
+    - **Campos:** `input_text` (Descrição + Metadados), `output_json` (Categoria Correta), `source` (Human/Auto), `timestamp`.
+- **Ciclo de Vida do Dado:**
+    1. **Ingestão:** Transação chega via API.
+    2. **Busca & Inferência:** Agente sugere classificação.
+    3. **Feedback:** Aplicação confirma ou corrige a classificação.
+    4. **Persistência:** O par `{Input, Correct_Output}` é salvo no PostgreSQL e indexado no Qdrant.
+    5. **Exportação:** Script `export_dataset.py` gera arquivo JSONL formatado para LoRA (`instruction`, `input`, `output`) a partir apenas de exemplos validados.
+
+- **Model Registry & Git Flow:**
+    - Todo novo treino gera um commit automático em uma branch isolada `candidatos-pos-treino/v{DATA}`.
+    - O artefato (`adapter.gguf`) é salvo e preservado independente do resultado do benchmark.
+- **Benchmarking e Promoção (Nível 1 - Manual):**
+    - O sistema roda o teste comparativo e anexa o relatório no Pull Request ou Issue.
+    - **Aprovação:** Se aprovado pelo humano, faz merge para `iris-classificacao-bancaria` e o deploy ocorre.
+    - **Reprovação:** Se reprovado, a branch é mantida para análise histórica (não é descartada), mas o PR é fechado/ignorado.
+
+### 8. Fluxo de Execução
 1. **Trigger:** Aplicação externa envia transação via API para o Agente.
 2. **Retrieval:** Agente busca no VectorDB as "Top-K" transações mais parecidas semanticamente com a atual.
 3. **Inference:** Prompt montado com a Transação Atual + Exemplos Recuperados é enviado ao Llama 3 Local.
 4. **Result:** Agente retorna a classificação sugerida + Score de Confiança.
 5. **Human Review (Assíncrono):** Através da aplicação principal, o usuário valida.
-6. **Learning:** Se houve correção, a aplicação notifica o Agente/Banco para atualizar o "Golden Record" usado no RAG.
+6. **Learning:** Integração com pipeline de MLOps descrito acima.
+
+### 9. Próximos Passos
+- [x] Definir versão exata do Llama 3.2 1B e método de quantização (Q4_K_M) <!-- id: 14 -->
+- [x] Modelar pipeline de exportação de dados para Fine-tuning futuro (Data Flywheel) <!-- id: 15 -->
+- [ ] Configurar container Zabbix Agent.
 
-### 8. Próximos Passos
-- [ ] Definir a versão exata do Llama 3 e método de quantização para CPU.
-- [ ] Modelar o schema do banco de dados (Tabela de Transações vs Tabela de Embeddings).
-- [ ] Configurar ambiente Python 3.12 travado.