Crie um serviço de agentes de programação que recebe pedidos do chat e do sistema de chamados

## Dê uma só tarefa a cada função de execução e deixe a revisora só lendo Atribua uma responsabilidade clara a cada função de execução: - um grafo principal de agentes de programação cria um agente novo para cada thread, enquanto o estado durável permanece no ambiente isolado e nos metadados da thread; - um grafo revisor realiza análise de código somente para leitura por meio de um modelo de constatações e de uma ação específica de publicação, sem ferramentas de alteração, commit, push ou abertura de revisão; - um grafo analisador cria orientações de revisão específicas para o repositório nos modos de inicialização e aprendizado contínuo, salvando-as por meio de uma única ferramenta específica; - uma aplicação web recebe webhooks da plataforma de hospedagem de código, do sistema de acompanhamento de chamados e do chat, determina uma thread estável e inicia ou transmite continuamente a execução do grafo correspondente; - um painel administrativo gerencia o acesso, os perfis de usuário, os padrões da equipe, os repositórios habilitados, a administração do estilo de revisão e a API de threads usada pela interface. Disponibilize os procedimentos do analisador como capacidades virtuais versionadas e somente para leitura, em vez de copiá-los para cada ambiente isolado. Registre o refinamento contínuo agendado somente após a conclusão da inicialização. Mantenha todos os pontos de entrada dos grafos e todas as rotas da aplicação em um único manifesto de execução, permitindo tanto um ambiente completo de desenvolvimento quanto um processo mais restrito, dedicado apenas à aplicação web. ## Escolha um único conjunto de ferramentas e rode primeiro o menor teste Defina um único gerenciador de dependências, executor de testes, analisador de estilo, formatador, verificador de tipos, versão mínima da linguagem e versão do ambiente de execução implantado. O repositório deve continuar válido tanto para a versão mínima compatível quanto para qualquer versão mais recente fixada pelos metadados de implantação. Forneça comandos documentados para: 1. instalar as dependências de desenvolvimento; 2. iniciar o ambiente completo de grafos e da aplicação web; 3. iniciar somente a aplicação web; 4. executar todo o diretório de testes unitários; 5. executar um único arquivo ou caso de teste; 6. verificar estilo e formatação sem realizar alterações; 7. aplicar o formatador e correções automáticas seguras; 8. verificar os tipos do código de produção e de teste. Use testes unitários por padrão. Reserve um diretório específico para testes de integração e trate a ausência de um conjunto de testes de integração como uma operação nula explícita, não como uma falha ambígua. Durante o desenvolvimento, execute um único teste ou o menor conjunto relevante antes das verificações amplas do repositório. ## Mantenha um ambiente isolado por thread e recrie-o quando falhar Mantenha em memória um cache de ambientes isolados indexado pelo identificador da thread e persista o identificador do ambiente isolado nos metadados da thread. Trate explicitamente o estado do ciclo de vida: 1. Se houver um ambiente isolado em cache, teste-o; recrie-o quando o teste falhar e, quando estiver íntegro, atualize seu proxy de rede autenticado. 2. Se os metadados contiverem um marcador sentinela de criação, mas não houver ambiente isolado em cache, remova o marcador obsoleto antes de criar um substituto. 3. Se não houver ambiente isolado, grave o marcador sentinela de criação, crie o ambiente e substitua o marcador pelo identificador real. 4. Se os metadados contiverem um identificador, mas o cache do processo estiver vazio, restabeleça a conexão e recorra à recriação caso a reconexão falhe. Para provedores que aceitam um proxy autenticado, obtenha uma credencial de instalação nova e de curta duração a cada criação ou atualização. Permita que o proxy injete a autenticação da plataforma de hospedagem de código e da API, para que os comandos no ambiente isolado possam usar um valor substituto inofensivo em vez de armazenar a credencial real. Provedores sem esse recurso devem ignorar explicitamente o caminho do proxy. Reaplique a configuração de identidade da automação em toda execução. Ambientes reutilizados ou reconectados podem perder configurações globais, e verificações posteriores de implantação podem rejeitar commits cuja identidade de autoria não seja reconhecida. ## Rode as camadas intermediárias em volta das chamadas ao modelo em ordem fixa Execute as camadas intermediárias em torno das chamadas ao modelo em uma sequência deliberada: 1. higienizar e normalizar as entradas das ferramentas; 2. limitar as chamadas ao modelo e encerrar de forma controlada ao atingir o limite; 3. converter exceções das ferramentas em mensagens de ferramenta; 4. anexar instruções aplicáveis de diretórios ancestrais às leituras de arquivos uma única vez por execução; 5. inserir, antes da próxima chamada ao modelo, as mensagens de chamados ou do chat que chegaram durante a execução; 6. atualizar indicadores externos do estado do assistente; 7. substituir uma resposta vazia do modelo por uma chamada sintética de ferramenta para continuar ou confirmar a conclusão; 8. notificar o canal de origem quando o limite geral de etapas for atingido; 9. acionar um disjuntor após falhas repetidas do ambiente isolado; 10. adicionar um modelo alternativo somente quando houver um modelo alternativo distinto configurado; 11. remover blocos de raciocínio malformados e específicos do provedor imediatamente antes das chamadas ao provedor. Combine a instrução de sistema para continuar agindo com a proteção contra respostas vazias, para que o trabalho não termine silenciosamente. Mantenha as camadas intermediárias do revisor mais enxutas quando ele não precisar de instruções de arquivo delimitadas por escopo, inserção da fila de mensagens, modelo alternativo ou recuperação do ambiente isolado. A existência de um componente de camada intermediária não utilizado não o torna ativo; registre explicitamente cada nova camada na posição correta. ## Dê a cada função só as ferramentas de que ela precisa Mantenha um registro pequeno e plano de ferramentas próprias. O agente principal pode receber solicitações de rede aprovadas, pesquisa, ações no sistema de acompanhamento de chamados, solicitações de revisão, reativações programadas e respostas no chat. O revisor deve receber apenas ferramentas de rede voltadas à leitura, além da criação, atualização e listagem de constatações e da publicação da revisão. O analisador deve receber somente a ação necessária para salvar as orientações de revisão. Deixe que a estrutura de agentes forneça recursos genéricos para arquivos, terminal, pesquisa, tarefas e planejamento. Não duplique essas ferramentas no registro próprio. Não dependa de uma proteção posterior ao agente para publicar o trabalho. O fluxo de trabalho do agente deve executar explicitamente cada commit, push, abertura ou atualização de revisão autorizada e cada resposta ao canal de origem. Um revisor somente para leitura nunca deve herdar essas capacidades de alteração. ## Escolha o modelo numa ordem fixa e criptografe as credenciais Determine o modelo e o nível de raciocínio de cada execução nesta ordem: 1. configuração específica da thread fornecida pelo evento acionador ou pela interface; 2. substituição definida no perfil do usuário identificado; 3. padrão da equipe. Centralize os identificadores de modelos compatíveis, as regras de nível de raciocínio, os argumentos do provedor, a construção e a seleção do modelo alternativo. Mantenha sinalizadores de comportamento, como a permissão para criar revisões automaticamente, no perfil do usuário, em vez de espalhá-los pelo código dos webhooks. Criptografe as credenciais de autorização do usuário quando armazenadas e mantenha-as em cache apenas dentro do processo durante uma execução. Quando não houver uma credencial do usuário, recorra a uma credencial de instalação da aplicação de curta duração. Use a mesma credencial da aplicação para configurar um proxy autenticado no ambiente isolado, mas nunca persista a credencial bruta dentro desse ambiente. Verifique a autenticidade do webhook antes de rotear um evento. Mantenha as verificações de assinatura da plataforma de hospedagem de código, a verificação do chat, a verificação do sistema de acompanhamento de chamados e o tratamento do acesso ao painel administrativo em seus respectivos módulos responsáveis. ## Leve as mensagens seguintes de volta à mesma thread e ao mesmo ambiente isolado Derive identificadores estáveis de thread a partir da identidade da conversa externa, para que toda interação subsequente no mesmo chamado, thread de chat, ramo ou revisão retorne ao mesmo estado do agente e ao mesmo ambiente isolado. Atribua às execuções do revisor um espaço de nomes determinístico separado e registre o tipo de thread nos metadados. Quando chegarem mensagens durante uma execução, coloque-as na fila da thread e insira-as antes da próxima chamada ao modelo. Isso preserva a continuidade sem abandonar a execução atual nem criar um agente concorrente. Alinhe as atualizações de estado aos limites das chamadas ao modelo, para que usuários externos possam distinguir trabalho ativo, conclusão e encerramento pelo limite de etapas. ## Rode o reparo automático de CI só quando ele estiver ligado Um fluxo automatizado de reparo pode reagir a verificações com falha, conflitos de mesclagem ou comentários que exijam ação em uma revisão criada por um agente. Localize a thread de origem por meio dos metadados duráveis da revisão e, em seguida, despache uma execução de reparo condicionada a um nível de confiança no grafo do agente principal. Exija habilitação em camadas: - um sinalizador de automação por usuário; - adesão explícita do repositório; - uma substituição por revisão para ativar ou desativar. Centralize as regras de omissão para falhas já presentes no ramo de base, commits feitos por pessoas, processamento repetido da mesma revisão de ponta, agrupamento enquanto outra execução de reparo estiver ativa e um limite rígido de ciclos. Use um monitor periódico apenas como recurso alternativo que varre revisões abertas criadas por agentes em busca de eventos perdidos. ## Adicione provedores e ferramentas nos seus registros e mantenha o código assíncrono Adicione um provedor de ambientes isolados ao respectivo módulo de integração e registre-o no mapa de fábrica de provedores. Adicione uma ferramenta própria ao pacote de ferramentas, exporte-a uma única vez e inclua-a somente na lista de ferramentas da função que precisa dela. Adicione uma camada intermediária em seu próprio módulo, exporte-a e posicione-a deliberadamente na pilha ordenada. Adicione os pontos de acesso do painel administrativo ao roteador montado e os novos grafos ao manifesto de execução. Mantenha assíncrona uma aplicação exclusivamente assíncrona. Não crie implementações síncronas paralelas. Omita o método síncrono quando a interface permitir; quando um contrato abstrato o exigir, forneça apenas um método mínimo que gere um erro de operação não compatível. Use testes unitários por padrão, reserve a área específica de testes de integração para integrações reais e mantenha os comentários raros. Os comentários devem explicar uma razão não evidente ou uma restrição de ordem, não repetir a implementação.