Crie uma ferramenta que revisa e corrige código com IA sem perder o código do usuário

## Leia a build e os documentos de responsáveis antes de mudar o código Antes de alterar o código, leia o ponto de entrada, o mapa de pacotes, a definição de compilação e os documentos de responsabilidade do repositório. Trate cópias geradas e resumos de conveniência como referências, não como fontes da verdade concorrentes. ### Orientação no repositório - Localize os pontos de entrada executáveis, os pacotes de implementação, a infraestrutura compartilhada e o sistema de compilação. - Use a definição de compilação como lista atual de comandos, em vez de copiar comandos para orientações que podem ficar desatualizadas. - Identifique qual documento ou arquivo-fonte é responsável por cada comportamento público, chave de configuração, variável de ambiente e invariante operacional. - Mantenha explícitos os adaptadores específicos de cada host. Fixe as premissas sobre versões de ferramentas externas de linha de comando e use alternativas de API estáveis quando o estado da árvore de trabalho tornar os comandos de alto nível pouco confiáveis. ### Portões de verificação - Formate e execute o linter antes da entrega, incluindo verificações de divergência dos artefatos gerados. - Execute testes focados durante a iteração e, em seguida, as suítes normativas de testes unitários, de integração, de condições de corrida e de ponta a ponta exigidas pelo limite alterado. - Prefira testes de ponta a ponta para comportamentos de processos, E/S, configuração, Git, daemon e fixtures gravadas; use testes unitários em auxiliares puros para obter rapidez e localizar falhas. - Compile o executável real após alterações não triviais. - Use desenvolvimento orientado a testes para correções de erros e funcionalidades e mantenha o trabalho não resolvido no rastreador de issues, em vez de ocultá-lo em alterações não relacionadas. ## Encerre todos os processos filhos ao cancelar e passe o diretório do Git de forma explícita Uma automação de longa duração deve controlar seu cancelamento, seus descendentes, seu estado compartilhado e seus efeitos no sistema de arquivos em todos os sistemas operacionais compatíveis. ### Disciplina de processos - Propague contextos de cancelamento por trabalhos de longa duração, subprocessos e operações de rede. - Derive tempos-limite delimitados para limpeza, sondagens e chamadas HTTP. - Coloque subprocessos canceláveis dentro de um limite de árvore de processos, para que o cancelamento encerre os descendentes, não apenas o filho direto. - Recolha os grupos de processos na saída normal, no erro e também no cancelamento; pipes herdados e processos netos vazados não podem sobreviver a uma execução. - Aplique a proteção de processos filhos específica da plataforma por meio de um único wrapper idempotente, para que o trabalho em segundo plano nunca abra consoles indesejados. - Proteja o estado mutável compartilhado com primitivas de sincronização padrão e torne explícita a responsabilidade por goroutines, canais, árvores de trabalho e diretórios temporários. ### Disciplina de sistema de arquivos e Git - Use auxiliares de caminho da plataforma, raízes de estado pertencentes ao aplicativo e modos de arquivo documentados. - Resolva links simbólicos quando aliases da plataforma puderem fazer com que caminhos equivalentes sejam comparados de maneira diferente. - Encaminhe operações Git de repositórios bare por um auxiliar que informe explicitamente o diretório Git; nunca dependa da descoberta pelo diretório atual sob configurações reforçadas do Git. - Remova ou substitua um estado somente quando os registros de responsabilidade e ciclo de vida comprovarem que isso é seguro. ## Defina quais comandos rodam só pela configuração do branch confiável Uma configuração que seleciona comandos ou agentes executáveis é código. Carregue-a somente de uma revisão confiável e trate configurações e instruções controladas por colaboradores como dados não confiáveis. ### Entradas confiáveis - Resolva o branch padrão confiável com uma nova busca remota e fixe o commit exato antes de ler configurações que executam código. - Interrompa se não for possível buscar, ler ou analisar o commit confiável ou sua configuração atual. Uma árvore confiável legível sem configuração pode ser válida se o contrato permitir. - Leia seletores de comandos, seletores de agentes, política de documentação, opções de exclusão de instruções do projeto e permissão de comandos do repositório somente na cópia confiável. - Mantenha desabilitada por padrão a permissão de comandos do repositório. Um branch enviado nunca deve poder habilitar seus próprios privilégios de execução nem enfraquecer a política confiável. - Mantenha separadas as configurações de funcionalidades que não executam código, para que o comportamento específico de um branch não atravesse o limite de execução. ### Tratamento com falha segura - Higienize textos de controle adversariais e oculte segredos antes de inserir conteúdo do usuário ou do repositório nos prompts dos agentes. - Antes de iniciar, confirme que qualquer opção de supressão de instruções funciona no adaptador selecionado. - Nunca simule confiança após uma falha de busca, análise ou autorização. - Adicione testes de regressão que comprovem que o conteúdo enviado não pode autorizar a si próprio a executar comandos, substituir a política confiável nem contornar o comportamento de falha segura. ## Rode um único serviço em segundo plano e recuse paradas com jobs ativos Serviços de todo o sistema precisam de defesas independentes para responsabilidade singleton, segurança de sockets, recuperação e comandos destrutivos de ciclo de vida. ### Singleton e recuperação - Obtenha um bloqueio exclusivo do sistema operacional antes do trabalho de recuperação ou da vinculação de sockets e mantenha-o durante toda a vida do processo. - Trate um bloqueio de kernel mantido como prova de um proprietário ativo; não invente heurísticas de obsolescência para ele. - Sonde um socket existente antes de removê-lo e limite separadamente os tempos de conexão e de verificação de integridade. - Inicie a execução do serviço somente por um modo explícito. Variáveis de ambiente herdadas não podem reinterpretar sondagens comuns como workers. - Faça com que a limpeza de inicialização considere o estado: nunca remova uma árvore de trabalho nem um recurso cujo registro de tarefa esteja pendente ou em execução. ### Controles de ciclo de vida - Recuse parar, reiniciar ou atualizar enquanto houver tarefas ativas, a menos que o operador forneça a substituição destrutiva explícita. - Não permita que opções de confirmação não interativas contornem a proteção de tarefas ativas. - Liste as tarefas bloqueadoras e audite cada chamada de ciclo de vida com a atribuição do processo e do processo pai. - Trate os limites de monitoramento da integração contínua como tempos-limite de inatividade: rearme-os somente diante de progresso verificado na origem anterior, nunca reduza o prazo existente e falhe com segurança quando não for possível verificar o progresso. - Torne idempotentes as operações de cancelamento de órfãos e mantenha os carimbos de data e hora de espera por agente apenas como observação: defina-os somente enquanto um portão estiver efetivamente estacionado e nunca os use para alterar a resolução do portão. ## Separe as sessões de revisão e correção e compare as mudanças com o objetivo A revisão deve comparar a alteração completa com a intenção verificável na fonte, sem permitir que texto não confiável, momento da entrega ou justificativa do agente de correção distorçam a decisão. ### Intenção e constatações - Preserve a proveniência da intenção. Trate uma intenção explícita como critérios de aceitação normativos e uma intenção inferida somente como indício de baixa confiança. - Aplique a mesma higienização, ocultação de segredos e proteção contra execução a ambas as formas. - Converta uma alteração do agente de correção que contradiga critérios explícitos em uma constatação de consulta ao usuário que estacione a execução. - Durante a revisão anterior à entrega, exclua somente resultados cuja responsabilidade pertença a etapas posteriores do pipeline; continue impondo requisitos externos ou preexistentes do ciclo de vida. - Falhe com segurança quando uma ação para uma constatação estiver ausente ou for desconhecida: classifique-a como consulta ao usuário, nunca como corrigível automaticamente. ### Disciplina de sessões e correções - Mantenha uma sessão durável de revisor por execução e outra sessão durável separada para o agente de correção; as funções nunca devem compartilhar estado. - Reutilize as sessões somente no ciclo de revisão, persista metadados mínimos de identidade e nunca persista prompts nem transcrições. - Se a retomada não for compatível ou falhar, descarte essa identidade e repita do zero a rodada da mesma função. Não tente novamente após um cancelamento. - Toda nova revisão continua sendo uma revisão adversarial completa de todo o diff do branch. - Em uma rodada de correção, aplique primeiro todas as correções e execute uma única verificação focada, limitada à área alterada. Deixe os portões normativos da suíte completa de testes e do linter para suas etapas dedicadas. ## Regenere a documentação pela fonte e não envie prompts nem código nas métricas Mantenha um único responsável por cada fato, regenere as orientações derivadas a partir da fonte e separe as evidências de diagnóstico locais das análises remotas limitadas. ### Documentação e conteúdo gerado - Mantenha concisos os documentos de visão geral; coloque os fatos de referência detalhados no responsável designado e crie links para eles nos guias. - Atualize os mapas de responsabilidade quando uma atribuição mudar. - Edite a fonte das orientações geradas para agentes, regenere o artefato com a compilação aprovada e deixe o linter falhar em caso de divergência. - Altere em conjunto as orientações de origem e a saída de comando no ponto de uso quando ambas expressarem o mesmo contrato operacional. - Se uma única passagem de agente combinar tarefas de documentação e de linter, consuma cada resultado exatamente uma vez e recorra a uma passagem independente sempre que uma saída for ignorada, inválida ou não confiável. - Limite as alterações de documentação ao material que ficou desatualizado pela alteração atual; não reintroduza varreduras exaustivas do corpus. ### Observabilidade com proteção da privacidade - Superfícies somente leitura não devem emitir nenhuma visualização de página; condicione o evento remoto de comando delas a uma mudança de estado e a um intervalo limitado. - Mantenha fidelidade total nos eventos de mutação, mas armazene evidências detalhadas de desempenho somente no ambiente local. - Nunca armazene prompts, saídas, diffs, segredos nem argumentos brutos de comandos nas métricas de invocação e nunca envie identificadores de execução, caminhos, identidades de sessão nem registros individuais de invocação para análises remotas. - Envie somente contagens agregadas e limitadas nos eventos terminais. - Atribua as definições de métricas e os limites temporais a uma única implementação normativa. Represente valores indisponíveis como null, não como um zero inventado, e calcule o uso por rodada a partir das diferenças entre valores cumulativos da sessão quando necessário. ## Confira o remoto antes de um force push e assine cada build de release A invariante principal é preservar o código do usuário. Recuse uma sincronização ou entrega insegura, em vez de tentar uma recuperação engenhosa que possa sobrescrever trabalho não observado. ### Segurança do repositório e dos branches - Mantenha o roteamento da base do pull request separado de um destino opcional de push para fork. Quando um host não puder oferecer roteamento de fork de ponta a ponta, ignore a criação em vez de abrir incorretamente um pull request para o próprio repositório. - Limite a sincronização comum a um fast-forward estrito e limpo ou a um deslocamento de divergência comprovadamente equivalente, ancorado no head exato do pipeline. - Um status passivo não deve buscar nem alterar. Caminhos bloqueados não devem redefinir, guardar em stash, mesclar, fazer rebase, forçar, trocar, excluir nem atualizar um remoto externo. - Persista o commit exato enviado, a identidade de destino sem credenciais e a geração e, imediatamente antes de aplicar uma sincronização, verifique novamente todas as premissas mutáveis. - Preserve o trabalho terminal não publicado sob uma referência de recuperação. A recuperação só pode mover uma árvore de trabalho limpa por fast-forward estrito; a preservação de trabalho local deve atualizar o portão por comparação e troca sem acionar um novo pipeline. - Derive as bases de rebase de referências remotas normativas recém-buscadas. Estacione a execução quando commits não enviados do branch padrão ampliarem silenciosamente uma alteração. - Antes de um push forçado, releia o head remoto e prossiga somente diante de um branch novo, um head igual, um head observado anteriormente e inalterado ou commits adicionados remotamente cuja equivalência já tenha sido comprovada pela identidade do patch. Qualquer falha de consulta ou comprovação deve falhar com segurança. - Mantenha como âncora de lease o último head que a execução realmente observou, nunca uma ponta buscada imediatamente antes de forçar. ### Segurança de versões e dependências - Em uma plataforma com contrato permanente de assinatura, assine cada artefato oficial com a identidade fixa do aplicativo, runtime reforçado e carimbo de tempo seguro antes de arquivá-lo ou calcular sua soma de verificação. - Restrinja as credenciais de assinatura à tarefa de versão, importe-as para armazenamento efêmero e remova-as tanto em caso de êxito quanto de falha. - Faça a verificação da versão falhar diante de assinatura ausente ou ambígua, identidade ou arquitetura incorreta, requisito de identidade mutável, reforço ausente ou carimbo de tempo ausente. - Trate notarização, formatos de empacotamento e binários universais como escopos separados, a menos que o contrato da versão os inclua. - Antes de adicionar uma dependência, consulte a documentação normativa atual e converse sobre a alteração com o usuário. - Não declare prontidão até que formatação, linting, testes focados, testes de integração, suíte completa, verificações de compilação, verificações de documentação e verificação específica da versão tenham resultados reais.