Envie solicitações de incorporação feitas por IA a um framework de código aberto com revisão humana

## Marque o trabalho da IA e faça push só em branches criados pelo agente Trate gravações externas, propriedade de tickets, ramos e atribuição como ações controladas. - Identifique claramente como geradas por IA as descrições de solicitações de incorporação, os comentários de revisão e os comentários em tickets, e informe o operador humano quando o projeto exigir. - Determine a identidade do operador ou autor por uma fonte autenticada. Nunca presuma uma identidade; omita o nome se a consulta falhar. - Adicione o rodapé de coautoria de IA exigido aos commits assistidos por IA. - Quando esse for o limite do projeto, não abra mais de 10 solicitações de incorporação por operador por dia; priorize poucas alterações completas e bem testadas. - Trabalhe apenas em tickets elegíveis e não atribuídos. Atribua o ticket ao operador e mova-o para o estado ativo antes da implementação. - Envie alterações somente para um ramo criado pelo agente. Não envie alterações para o ramo de um colaborador sem permissão explícita. - Prefira uma bifurcação pessoal a encher o repositório principal com ramos não limpos, use um nome de ramo útil que contenha o assunto e o identificador do ticket e remova o ramo após a incorporação ou rejeição. Mantenha atualizados os metadados da solicitação de incorporação. Depois de cada envio, atualize o título e a descrição para que continuem representando corretamente o conjunto completo de alterações. ## Leia o histórico do código e os tickets anteriores antes de mudar o código Não presuma que um código aparentemente errado tem defeito. Sistemas de longa duração costumam incorporar restrições anteriores que não aparecem na implementação atual. 1. Reproduza e valide o problema relatado; questione pressupostos incompletos ou equivocados. 2. Examine o histórico do arquivo e os dados de autoria por linha; depois, leia as mensagens de commit pertinentes e os tickets vinculados para entender por que o código existe. 3. Pesquise tickets relacionados para encontrar abordagens rejeitadas, discussões anteriores e decisões intencionais. 4. Leia os documentos de projeto da área afetada, especialmente os relativos a segurança, telemetria, contexto de logs e contratos públicos de nomenclatura. 5. Se um módulo substituiu outro, diferencie alterações intencionais de omissões acidentais. 6. Se a correção proposta reverter uma alteração intencional anterior, pare e reconsidere. Se a reversão continuar justificada, explique por que ela é necessária apesar da justificativa original. Antes de implementar, apresente ao operador as descobertas, os riscos, as ambiguidades e a possível invalidade do problema. Aplique o mesmo rigor ao revisar uma solicitação de incorporação. Verifique as versões, as publicações e o comportamento atuais das dependências externas em fontes oficiais. Nunca faça afirmações conclusivas sobre projetos externos em evolução com base apenas no conhecimento de treinamento do modelo. ## Troque as pausas fixas dos testes por esperas com tempo limite Nunca use pausas de duração fixa em testes. Elas tornam os testes lentos, instáveis e não determinísticos. - Se um componente tiver asserções temporizadas nativas, use-as para as condições que ele já representa. - Use um utilitário de espera assíncrona para outras condições, como aguardar uma contagem intermediária antes da próxima ação. - Não envolva uma asserção bloqueante nativa em um utilitário de sondagem; isso adiciona sondagens redundantes ao redor de uma trava já existente. - Sempre defina um tempo limite máximo explícito ao usar um utilitário de espera. - Use uma condição com asserção ou um predicado claro; nunca use um laço de espera ocupada. - Ao modificar um teste que contenha uma pausa fixa, migre-o para a asserção temporizada nativa ou para o utilitário geral de espera. Por exemplo, `MockEndpoint.assertIsSatisfied()` já espera internamente, enquanto Awaitility é adequado para condições que `MockEndpoint` não consegue expressar. Testes novos não devem introduzir `Thread.sleep()`. ## Defina em quem confiar e relate vulnerabilidades de forma privada Use o modelo de ameaças oficial do projeto para decidir em quem confiar, onde ficam os limites de confiança e o que pertence à responsabilidade da estrutura. - Considere os autores do código e os operadores de implantação confiáveis quando eles configurarem intencionalmente rotas executáveis, expressões, segredos, exposição de rede e parâmetros de execução. - Considere não confiáveis os remetentes externos de mensagens e todos os dados que fluem por uma rota confiável. - A própria estrutura não deve transformar dados não confiáveis em execução de código, leitura de arquivos, falsificação de solicitações ou desvio de autorização. - A execução intencional de código por um autor confiável, uma configuração incorreta do operador e um comportamento perigoso habilitado por adesão explícita não constituem, por si sós, vulnerabilidades da estrutura. Descobertas válidas demonstram uma violação do limite de confiança em uma configuração padrão ou razoavelmente esperada. Classes comuns incluem desserialização insegura, XXE, injeção de expressões, travessia de caminhos, SSRF, abuso de despacho por cabeçalhos, desvio de autenticação ou autorização, exposição de segredos, valores padrão inseguros e injeção em consultas construídas pela estrutura. Esgotamento de recursos sem os controles exigidos, superfícies administrativas expostas deliberadamente, descobertas em dependências transitivas inalcançáveis e resultados de scanner sem prova de violação do limite normalmente ficam fora do escopo da estrutura. Nunca divulgue uma possível vulnerabilidade em um ticket público, uma solicitação de incorporação, uma lista de discussão ou outro canal público. Siga o processo de comunicação privada e interrompa o trabalho público. ## Bloqueie dados recebidos não confiáveis e deixe desativados os padrões de segurança arriscados Revise cada consumidor, analisador, formato de dados, conversor de tipos, armazenamento de agregação e opção relacionada à segurança diante de caminhos concretos de abuso. - Filtre os cabeçalhos internos da estrutura em mensagens de entrada não confiáveis, antes do despacho, com uma estratégia rigorosa que não diferencie maiúsculas de minúsculas. - Não desserialize objetos não confiáveis sem um filtro de entrada adequado. - Marque segredos como metadados secretos e classifique controles de configuração inseguros por sua família de risco. - Mantenha bloqueados os valores padrão sensíveis à segurança, a menos que sejam habilitados explicitamente. Relaxar um padrão exige uma nota de atualização e a aprovação explícita de um mantenedor. - Verifique se as opções de autenticação e autorização validam o emissor, o público-alvo, a assinatura e cada subcaminho anunciado que afirmam proteger. Nas implantações, use o perfil de segurança de produção, resolva segredos por um cofre aprovado, configure TLS verificado, desabilite serialização insegura em consumidores não confiáveis e mantenha consoles de gestão e administração do ambiente de execução em redes confiáveis. A revisão de segurança deve diferenciar o comportamento de uma rota confiável do comportamento da estrutura e, ao mesmo tempo, impedir que dados não confiáveis atravessem o limite. ## Inclua testes e documentação em cada mudança e faça commit dos arquivos gerados Cada funcionalidade ou correção de erro deve incluir testes adequados e documentação voltada ao usuário. Documente no guia pertinente os valores padrão alterados, o comportamento de descoberta, as opções renomeadas ou removidas, as mudanças em cabeçalhos, as alterações de API ou SPI, as descontinuações e as migrações. - Execute, para o escopo alterado, as verificações oficiais do repositório de formatação, ordem de importação, estilo, testes unitários, testes de integração e código-fonte. - Gere novamente e inclua em um commit os artefatos gerados; não deixe para a CI descobrir primeiro as alterações geradas. - Evite introduzir novos defeitos de análise estática, regressões de manutenibilidade, padrões comuns de fraqueza e APIs descontinuadas, mesmo quando uma validação local não executar todos os analisadores. - Importe classes e use nomes simples, em vez de nomes de classe totalmente qualificados, exceto quando duas classes tiverem o mesmo nome simples. Preserve as exclusões explícitas de código gerado. - Adicione a marca de versão de introdução exigida a cada novo tipo e método de API pública, use a versão da próxima publicação e coloque-a depois das demais marcas de documentação. - Atualize todos os registros de metadados que descobrem extensões aninhadas; apenas um diretório de código-fonte pode não tornar uma extensão visível para compilações, catálogos ou documentação gerada. - Em contêineres de testes de integração, verifique todas as arquiteturas compatíveis. Use um espelho de registro aprovado ou exclusões explícitas por arquitetura quando não existir uma imagem. - Use referências internas para páginas internas e verifique âncoras entre versões no destino publicado, não apenas no ramo de desenvolvimento. Ao descontinuar uma funcionalidade, atualize em conjunto os metadados de compilação, as anotações de API, o título da documentação e o guia de atualização. ## Peça dois revisores e uma aprovação humana antes de incorporar Solicite revisão apenas quando a solicitação de incorporação estiver pronta, nunca enquanto estiver como rascunho. - Identifique os mantenedores ativos pertinentes pelo histórico recente dos arquivos e pelos dados de autoria, e solicite a revisão de pelo menos 2 revisores adequados. - Depois de tratar todos os comentários e restaurar o estado de sucesso das verificações, solicite novamente a revisão dos revisores existentes. - Nunca incorpore enquanto houver qualquer conversa de revisão não resolvida. - Exija pelo menos 1 aprovação humana e nunca aprove a própria solicitação de incorporação do agente. - Derive o marco da publicação do ramo de destino e defina tanto o marco quanto a versão de correção do ticket antes de fechá-lo. - Determine por programa o autor da solicitação de incorporação, atribua corretamente a solicitação e o ticket e aplique o rótulo de categoria sustentado pelo ticket e pela alteração. - Coloque a publicação e a incorporação depois de uma única cadeia bem-sucedida de verificações de formatação, tipos, lint, testes e segurança. - Preserve a coautoria de IA exigida no commit final de incorporação. - Após a incorporação, resolva o ticket com a versão de correção e um link para a solicitação de incorporação e remova o ramo. Resuma o comportamento visível ao usuário, a validação significativa, o impacto na documentação, o risco não resolvido e qualquer verificação que não tenha sido executada. Um teste local não comprova o sucesso da CI, e evidências incompletas não justificam afirmar que a publicação está pronta.