Prompt para agente DSPy com Engenharia Compounding (aprendizado local de repositório)

Objetivo: criar um agente DSPy que trate o repositório como um ambiente de aprendizado de longa duração e implemente o conceito de Compounding Engineering. O agente deve rodar um loop repetido sobre o código, sem depender de prompts únicos estáticos, e com as seguintes fases fixas: 1) Review – realizar uma análise profunda e estruturada do repositório; 2) Triage – extrair TODOs, bugs, padrões recorrentes e áreas de melhoria; 3) Plan – gerar planos de correção, propostas de recursos e mudanças de arquitetura; 4) Learn – persistir insights de forma local para que a próxima iteração tenha mais contexto; 5) Repeat – cada iteração deve trazer melhorias significativas em precisão, cobertura de código e qualidade das propostas.

Requisitos de projeto:
- Local-first: rodar totalmente offline sempre que possível; armazenamento local para histórico, métricas e itens aprendidos; não depender de embeddings como recurso principal.
- Não é um assistente inline estilo Copilot; o objetivo é analisar, planejar e aprender com a história do código, fornecendo saídas acionáveis e propostas de alto nível, não sugestões automáticas de código embutidas no editor.
- Não abandonar a infraestrutura de avaliação: inclua métricas de melhoria entre iterações (p. ex., redução de bugs reportados, melhoria na cobertura de TPs, tempo de resolução de issues).
- Arquitetura modular: defina claramente os componentes Review, Triage, Plan, Learn e explique como eles trocam informações (formatos de dados: JSON/YAML; stores locais; estrutura de logs).
- Persistência: desenhe um modelo simples de armazenamento local para manter estado entre iterações (por exemplo, JsonDB/arquivos, ou um pequeno cache SQLite) com versionamento de iterações.
- Como lidar com escalabilidade: descreva pontos de gatilho para migrar para modelos em nuvem apenas quando necessário (por exemplo, análise de grandes bases de código, dependência de modelos mais potentes), mantendo operação offline como baseline.

Saída esperada em cada iteração:
- Review: relatório estruturado com principais áreas do código, padrões, anti-padrões, riscos de segurança; mapeamento de stakeholders e impacto.
- Triage: lista de TODOs, bugs, melhorias de documentação, refatorações sugeridas e patterns recorrentes com prioridade.
- Plan: plano de ação com tarefas ordenadas, estimativas de esforço, critérios de aceite e dependências entre itens.
- Learn: registro de insights, decisions log, links para artefatos gerados naquela iteração e um resumo de como o contexto adicional afeta a próxima rodada.
- Repeat: descrição das mudanças de contexto para a próxima iteração (o que foi aprendido, o que foi persistido, o que requer reavaliação).

Formato de saída recomendado:
- Use JSON estruturado para cada estágio com campos como: etapa, items, metrics, aprendizados, context_update.
- Inclua um pequeno snippet de código (pseudo ou real) apenas para ilustrar como a saída de Learn seria consumida pela próxima iteração (sem necessariamente gerar código de produção repetitivo).

Exemplos de prompts de partida para cada estágio:
- Review: "Liste as áreas de maior complexidade no código, identifique dependências críticas, documente padrões de design e riscos de segurança." 
- Triage: "Quais TODOs são de maior impacto? Quais bugs bloqueiam funcionalidades principais? Quais padrões recorrentes merecem uma resolução?" 
- Plan: "Gere um plano de ações com prioridades, entregáveis e critérios de aceite para as melhorias identificadas." 
- Learn: "Armazene insights de forma estruturada, atualize o modelo de conhecimento local e explique como isso afeta a próxima iteração." 

Governança e segurança:
- Evite vazamento de segredos; utilize variáveis de ambiente/secret stores locais; não registre conteúdo sensível em logs; forneça versões de artefatos para reprodutibilidade.
- Mensure a confiabilidade: registre métricas de qualidade de código, cobertura de testes, tempo entre iterações e a qualidade das decisões tomadas.

Interoperabilidade:
- Estruture os dados de saída de cada estágio para facilitar a ingestão por pipelines subsqeuentes (por exemplo, uma função que recebe o Learn e atualiza o estado para a próxima iteração).

Caso de uso sugerido:
- Aplique o pipeline a um repositório existente para ver como a baseline evolui ao longo de várias iterações, sem depender de serviços externos para o funcionamento básico.

Sugestão de implementação:
- Linguagem/ambiente: Python, com módulos para leitura de código (ast/tokenize), armazenamento local (SQLite/JSON), e uma camada de orquestração simples; mantenha a fachada de prompts para ser adaptável a diferentes repositórios.

Observação: este prompt inspira a construção de um agente que aprende de maneira acumulativa. A ideia central é que o repositório vira um dataset de aprendizado para o próprio revisor de IA, elevando a qualidade das decisões ao longo do tempo.