feat(arthur): Planejamento inicial e estruturacao do PRD e TODO do Agente Arthur

Porque foi feita essa alteracao?
Nova funcionalidade. Foi realizado o planejamento completo, definicao da stack tecnologica, fluxo de atendimento via e-mail e integracao com Zabbix/Financeiro para o Agente Arthur (Suporte N2).

Quais testes foram feitos?
Validacao documental e alinhamento tecnico com o usuario sobre hardware (Xeon E5-2699 v3), limites de RAM (128GB) e logica de multitenancy.

A alteracao gerou um novo teste que precisa ser implementado no pipeline de testes?
Nao, por se tratar de documentacao de requisitos e planejamento.

.gemini/PRD_Suporte_Tecnico_N2.md

@@ -1,32 +1,83 @@
 # PRD - Agente de Suporte Técnico N2 (Arthur)
 
 ## 1. Visão Geral
-[Descreva aqui o propósito do agente Arthur e como ele deve auxiliar no Suporte Técnico N2.]
+O Agente Arthur é um sistema de IA soberano projetado para Suporte Técnico N2 de alta performance, operando exclusivamente em CPU com máxima eficiência de memória. Ele atua como um orquestrador que correlaciona dados em tempo real (Zabbix), histórico de eventos recentes e bases de conhecimento técnico para fornecer diagnósticos precisos e remediação assistida em ambientes multitenant (múltiplos clientes).
 
 ## 2. Objetivos do Produto
-- [ ] Objetivo 1
-- [ ] Objetivo 2
+- **Otimização Extrema (CPU-Only):** Utilizar modelos quantizados e estratégias de extração de dados para manter o consumo de RAM mínimo sem perder capacidade lógica.
+- **Rastreabilidade e Auditabilidade:** Utilizar o E-mail como canal oficial para garantir logs permanentes e auditáveis de cada diagnóstico e interação.
+- **Raciocínio Correlacional:** Identificar se um problema atual está vinculado a alertas gerais de infraestrutura ou a chamados abertos nas últimas 24 horas.
+- **Isolamento Multitenant:** Gerenciar conhecimentos específicos de diferentes empresas (ex: OESTEPAN, ENSEG) garantindo o isolamento de dados.
+- **Integração de Dados Direta:** Utilizar APIs diretas (Zabbix) para evitar o overhead de protocolos intermediários.
 
 ## 3. Escopo
+
 ### 3.1 Incluso
-- [ ] Funcionalidade A
-- [ ] Funcionalidade B
+- **Interface via E-mail (IMAP/SMTP):** Monitoramento de caixa postal (`mail.itguys.com.br`) e resposta de chamados com trilha de auditoria.
+- **RAG Multitenant:** Base de conhecimento segmentada por cliente com suporte a ingestão de manuais.
+- **Correlação Temporal (24h):** Análise de eventos recentes para identificar problemas globais ou recorrentes.
+- **Dispatcher Unificado:** Chamada de ferramentas (Zabbix, DB) via interface padronizada.
+- **Ciclo de Feedback:** Encerramento de chamados e aprendizado via interpretação de respostas de técnicos.
 
 ### 3.2 Não Incluso
-- [ ] Exclusão A
+- **Treinamento de Base Model:** O projeto utiliza modelos pré-treinados (Llama, Phi, Qwen) e aplica fine-tuning via LoRA, não o treinamento do zero.
+- **Suporte Nível 1 (Básico):** O foco é em problemas que exigem raciocínio técnico e acesso a monitoramento.
 
 ## 4. Funcionalidades Principais
-[Detalhe as capacidades de inteligência e integração do agente.]
 
-## 5. Requisitos Não Funcionais
-- **Hardware:**
-- **Segurança:**
-- **Latência:**
+| ID | Funcionalidade | Descrição |
+| :--- | :--- | :--- |
+| **FR01** | Integração Zabbix via API | Conexão direta via JSON-RPC para telemetria em tempo real e verificação de saúde da infraestrutura. |
+| **FR02** | Ferramenta de Ingestão de RAG | CLI ou endpoint específico para processar manuais técnicos (.md, .pdf) e injetá-los na base do cliente correto. |
+| **FR03** | Correlação de Eventos Cruzados | Capacidade de consultar chamados de outros colaboradores do mesmo cliente nas últimas 24h para identificar padrões. |
+| **FR04** | Dispatcher de Ferramentas Unificado | Interface única de comunicação onde o modelo 1B gera chamadas padronizadas, reduzindo erros de sintaxe e consumo de tokens. |
+| **FR05** | Memória Histórica Comparativa | Verifica se o chamado atual é uma reincidência ou se possui relação com problemas globais registrados. |
+| **FR06** | Biblioteca de Ferramentas Extensível | Estrutura modular que permite adicionar novas integrações (AD, Firewall, M365) sem necessidade de retreinar os modelos. |
+| **FR07** | Agrupamento e Deduplicação | Capacidade de correlacionar múltiplos alertas do Zabbix em um único diagnóstico de causa raiz, reduzindo o ruído e notificações duplicadas. |
+
+## 5. Requisitos Não Funcionais (NFR)
+- **NFR01 - Soberania:** 100% de execução local sem dependências de APIs de nuvem externas.
+- **NFR02 - Latência:** Resposta inicial (TTFT) abaixo de 800ms para modelos de 8B e instantânea para modelos 1B.
+- **NFR03 - Segurança:** Implementação de Llama Guard para filtrar inputs maliciosos e Human-in-the-loop para ações críticas.
+- **NFR04 - Estabilidade:** Isolamento de processos via Docker para garantir resiliência.
 
 ## 6. Stack Tecnológica
-- **LLM:**
-- **Framework:**
-- **Banco de Dados:**
+- **Linguagem:** Python 3.11/3.12.
+- **LLMs (Local):** Llama 3.1 (8B), Qwen 2.5 (7B), Llama 3.2 (1B) via Ollama/llama.cpp.
+- **Orquestração:** LangGraph para fluxos cíclicos e PydanticAI para validação de output.
+- **Banco Vetorial:** Qdrant (com suporte a On-Disk storage para economia de RAM).
+- **Integração:** Model Context Protocol (MCP) e `zabbix_utils`.
+- **Monitoramento de IA:** Langfuse (local) para tracing de execução.
+
+## 7. Arquitetura de Hardware (Referência)
+- **CPU:** Intel Xeon E5-2699 v3 (18 Cores / 36 Threads).
+- **RAM:** 128 GB DDR4 ECC (Foco em largura de banda).
+- **Storage:** SSD NVMe (Mínimo 3000MB/s leitura) - Essencial para `on_disk` do Qdrant.
+- **Rede:** Interna Gbit (Baixa latência para chamadas de API Zabbix).
+
+## 8. Estimativa de Recursos por Componente
+Esta tabela detalha o consumo esperado para cada parte do sistema em estado de operação, permitindo identificar gargalos de otimização.
+
+| Componente | CPU (Threads) | RAM (Est.) | Disco (I/O) | Observação de Otimização |
+| :--- | :--- | :--- | :--- | :--- |
+| **Inferência 1B (Triagem)** | 2 - 4 | 800MB - 1.2GB | Baixo | Modelo Q8 (Quantizado) para máxima precisão na extração. |
+| **Inferência 8B (N2)** | 8 - 12 | 5GB - 8GB | Médio | Modelo Q4_K_M. Otimizado para GGUF/llama.cpp. |
+| **Qdrant (Vector DB)** | 2 - 4 | 1GB - 2GB* | **Alto** | *Com `on_disk: true`. Exige alta performance de IOPS do NVMe. |
+| **Orquestrador (Python)** | 1 | 256MB - 512MB | Irrelevante | Apenas gestão de fluxo e chamadas de API. |
+| **PostgreSQL (Histórico)** | 1 - 2 | 1GB - 2GB | Baixo | Armazena metadados e histórico de chamados curtos. |
+| **Langfuse (Tracing/IA)** | 2 | 2GB - 4GB | Médio | Pode ser desligado em produção se o hardware estiver no limite. |
+
+**Capacidade de Escalabilidade:** Com 128GB de RAM, o sistema suporta até **10 instâncias simultâneas do Arthur** (cada uma com seu próprio contexto 8B) sem atingir o limite de memória. O gargalo real será a contenção de threads na CPU Xeon durante a geração de texto.
+
+## 9. Lógica de Atendimento e Encerramento (Workflow do Arthur)
+1. **Captura via E-mail ou Alerta Crítico:** Arthur monitora a caixa de entrada ou recebe gatilhos de alertas críticos filtrados pelo Zabbix.
+2. **Análise de Causa Raiz e Vizinhança (Python):** Antes de processar, o sistema consulta hosts vizinhos no Zabbix para identificar se o alerta é um sintoma de uma falha central (ex: queda de switch ou link).
+3. **Triagem e Coleta (Modelo 1B + Dispatcher):** O modelo 1B decide as ferramentas de busca. O sistema agrupa alertas correlacionados em um único contexto.
+4. **Análise e Resposta (Modelo 8B):** O especialista formula o diagnóstico consolidado e a solução, enviando o e-mail auditável.
+5. **Ciclo de Feedback e Aprendizado:** Encerramento via resposta do técnico ou normalização do monitoramento, alimentando a memória episódica.
+
+## 10. Governança, Segurança e Extensibilidade
+- **Interface Unificada:** Força a comunicação agente-ferramenta por um único esquema (Schema Enforcement via Pydantic), eliminando alucinações de formato.
+- **Isolamento de Tenant:** Filtro obrigatório de `customer_id` em todas as consultas.
+- **Modularidade:** Novas ferramentas são registradas no Dispatcher; o modelo 1B as "descobre" via System Prompt.
 
-## 7. Próximos Passos
-- [ ] Definir requisitos detalhados

.gemini/TODO_Arthur.md

@@ -1,20 +1,58 @@
-# TODO - Arthur (Suporte Técnico N2)
+# TODO - Projeto Arthur (Agente de Suporte Técnico N2)
 
-## Fase 1: Planejamento e Definição
-- [ ] Preencher o PRD com os requisitos detalhados
-- [ ] Definir a arquitetura técnica
-- [ ] Mapear fontes de dados para o conhecimento (Wiki, Tickets, etc.)
+Este documento serve como o roteiro técnico detalhado para a implementação do Agente Arthur. O foco é soberania (local-only), otimização de CPU e integração auditável via e-mail.
 
-## Fase 2: Configuração do Ambiente
-- [ ] Configurar ambiente virtual específico
-- [ ] Definir variáveis de ambiente (.env)
-- [ ] Configurar monitoramento (Langfuse/Zabbix)
+## Fase 1: Planejamento e Arquitetura de Dados
+- [x] **Consolidação do PRD N2:** Definição de escopo, hardware e lógica de atendimento.
+- [ ] **Mapeamento do Tenant Resolver (Financeiro):**
+    - Definir endpoints/queries no Sistema Financeiro de Produção para buscar: `ID`, `Nome`, `Domínios de E-mail` e `Status`.
+    - Criar esquema Pydantic para o objeto `TenantContext`.
+- [ ] **Design do Schema de Auditoria:**
+    - Criar modelo de banco de dados (PostgreSQL) para registrar: `TicketID`, `Remetente`, `Contexto Coletado`, `Pensamento do Modelo`, `Resposta Enviada` e `Status de Resolução`.
 
-## Fase 3: Desenvolvimento do Core
-- [ ] Implementar integração com base de conhecimento
-- [ ] Configurar orquestração de prompts
-- [ ] Desenvolver conectores de entrada/saída
+## Fase 2: Infraestrutura e Conectores Core (Músculos)
+- [ ] **Ambiente de Inferência Local:**
+    - Configurar Ollama ou llama.cpp para rodar Llama 3.2 1B (Triagem) e Llama 3.1 8B (Especialista) em CPU.
+    - Otimizar threads (Xeon v3) para evitar contenção.
+- [ ] **Configuração do Qdrant Multitenant:**
+    - Inicializar Qdrant com persistência `on_disk: true`.
+    - Definir coleção com suporte a `payload filtering` por `customer_id`.
+- [ ] **Módulo de Comunicação (Mail Client):**
+    - Implementar `MailListener` (IMAP) para `mail.itguys.com.br`.
+    - Implementar `MailResponder` (SMTP) com suporte a threads de e-mail (Headers Message-ID/References).
+- [ ] **Conector Zabbix API:**
+    - Implementar wrapper usando `zabbix_utils`.
+    - Criar funções específicas: `get_host_status`, `get_active_problems`, `get_neighbor_alerts` (Causa Raiz).
 
-## Fase 4: Testes e Validação
-- [ ] Testes de acurácia técnica
-- [ ] Validação de fluxos de suporte
+## Fase 3: Orquestração e Raciocínio (Cérebro)
+- [ ] **Desenvolvimento do Multi-Agent Dispatcher:**
+    - Criar o orquestrador (LangGraph) que gerencia o estado do chamado.
+- [ ] **Implementação do Agente de Triagem (1B):**
+    - Prompt Engineering para extração de entidades (Cliente, Tecnologia, Problema).
+    - Lógica de decisão de ferramentas (Single Dispatcher).
+- [ ] **Desenvolvimento do Analista de Causa Raiz:**
+    - Código Python para comparar alertas do host atual com alertas de sub-rede/vizinhança no Zabbix.
+- [ ] **Implementação do Agente Especialista (8B):**
+    - Prompt de Resolução N2: Recebe o "Contexto Enriquecido" (Zabbix + Histórico 24h + Manuais RAG) e gera a resposta técnica final.
+
+## Fase 4: Flywheel e Qualidade (Aprendizado)
+- [ ] **Pipeline de Ingestão de RAG:**
+    - Criar script para processar diretórios de Markdowns/PDFs técnicos e indexar no Qdrant com metadados de tecnologia.
+- [ ] **Parser de Feedback de Encerramento:**
+    - Desenvolver lógica para ler respostas de e-mail dos técnicos e identificar se o caso foi "Resolvido" ou "Reaberto".
+- [ ] **Módulo de Memória Episódica:**
+    - Lógica para salvar casos resolvidos como "Lições Aprendidas" para futuras consultas similares.
+
+## Fase 5: Implantação e Monitoramento
+- [ ] **Configuração do Langfuse Local:**
+    - Subir Langfuse via Docker para rastreamento (tracing) de todos os chamados.
+- [ ] **Teste de Stress e Latência:**
+    - Validar tempo de resposta com 5+ chamados simultâneos (Contenção de CPU Xeon).
+- [ ] **Homologação com Sistema Financeiro:**
+    - Validar a busca dinâmica de clientes em tempo real.
+
+---
+### Diretrizes para Agentes de Execução:
+1. **CPU Only:** Nunca tente usar bibliotecas que exijam CUDA/GPU sem autorização expressa.
+2. **Auditabilidade:** Toda decisão do Arthur deve gerar um log no PostgreSQL.
+3. **Isolamento:** Garanta que os dados da ENSEG nunca vazem para um diagnóstico da OESTEPAN via filtros de Payload no Qdrant.