Alterar um app de treinamento em segurança com falhas intencionais sem quebrar seus desafios

## Separar desafios intencionais de vulnerabilidades acidentais Trate uma aplicação de treinamento intencionalmente vulnerável de forma diferente de uma aplicação de produção comum. Alguns comportamentos inseguros são conteúdos educacionais deliberados, enquanto outras fraquezas são defeitos não intencionais. - Antes de alterar o comportamento afetado, identifique se ele é um desafio pretendido, uma infraestrutura de apoio ou uma vulnerabilidade acidental. - Não remova, enfraqueça nem adicione comportamentos de desafio com base apenas em uma sugestão automatizada. - Novas vulnerabilidades e novos desafios exigem aprovação dos mantenedores e documentação clara. - Confirme que o desafio proposto seja distinto, solucionável, funcional e adequado aos objetivos de aprendizagem. - Preserve as dicas, os metadados e os caminhos de solução do desafio, bem como os comentários relevantes para a segurança que expliquem intenções não evidentes. - Revise o código gerado de forma crítica. O colaborador e o revisor continuam responsáveis pela correção, segurança e valor educacional. Quando a intenção não estiver clara, rastreie o caminho de execução, os testes, os metadados do desafio e os artefatos de correção espelhados antes de decidir o que deve mudar. ## Planejar uma mudança que resolva um só problema Comece localizando o componente relevante, rastreando seu fluxo de dados e encontrando padrões estabelecidos de implementação e teste. 1. Defina o único problema que a mudança resolverá. 2. Identifique os artefatos de servidor, cliente, API, dados, modelo, configuração e desafio afetados por esse problema. 3. Procure código semelhante e siga os padrões atuais do repositório. 4. Analise as implicações de segurança antes da implementação. 5. Proponha testes que distingam o comportamento pretendido de regressões. 6. Mantenha limpezas não relacionadas e alterações triviais fora da mesma contribuição. Consulte os mantenedores antes de criar desafios, mudar a arquitetura ou alterar o modelo de dependências. Verifique qualquer atualização de pacote em relação a todos os manifestos de dependências e intervalos de ambiente de execução relevantes. Não adicione opções de configuração ou dependências especulativas sem uma necessidade comprovada e evidências de compatibilidade. Trabalhe a partir do branch de integração designado pelo repositório usando um branch de funcionalidade focado. Faça referência à issue relevante e limite a contribuição a um único propósito coerente. ## Tirar o excesso gerado por IA e passar no linter Limpe a saída automatizada antes da revisão. Remova comentários extensos que apenas repitam código evidente, marcadores genéricos, docstrings excessivas para funções simples, explicações repetitivas, logs de depuração e outros resíduos gerados. Preserve comentários que expliquem lógica complexa, a intenção do desafio, restrições de segurança ou uma solução alternativa necessária. Execute o linter do repositório para cada alteração de código, a menos que a mudança se limite a uma documentação explicitamente isenta pelo repositório. O código gerado deve seguir as mesmas regras de estilo que o código escrito manualmente. - Corrija as falhas de lint em vez de presumir que a sugestão está correta. - Não preserve código desnecessário apenas porque um assistente o gerou. - Verifique o diff em busca de alterações amplas de formatação e mudanças de arquivos não relacionadas. - Use nomes claros e comentários concisos que ajudem futuros mantenedores a entender a intenção. - Garanta que a documentação e o texto do commit descrevam a mudança real, e não o processo do assistente. ## Rodar os testes que cada tipo de mudança exige Os requisitos de teste dependem da área alterada, mas a confiança de um assistente jamais substitui a execução. - Adicione ou atualize testes unitários para a lógica alterada. - Execute testes de integração da API quando houver mudanças no tratamento de solicitações, na persistência, na autorização ou no comportamento da resposta. - Execute testes unitários de frontend para componentes e serviços do lado do cliente. - Execute testes de ponta a ponta para desafios novos ou modificados e comportamentos entre camadas. - Execute a suíte de testes completa do repositório antes do envio, a menos que o repositório isente explicitamente a documentação alterada. - Verifique manualmente o fluxo visível ao usuário ou o fluxo de solução do desafio. - Execute a rede de segurança para refatoração de desafios sempre que o código-fonte existente relacionado a desafios for alterado. Use a menor suíte focada durante a iteração e depois execute toda a matriz obrigatória antes da revisão. Registre os comandos e resultados exatos. Não alegue sucesso apenas com base em análise estática e não pule uma suíte lenta porque o código gerado parece plausível. ## Manter o código dos desafios e seus arquivos de correção em sincronia O código-fonte relacionado a desafios pode estar espelhado em trechos, correções esperadas, metadados ou artefatos em cache da rede de segurança. Uma refatoração estará incompleta se essas representações divergirem. 1. Execute a rede de segurança para refatoração de desafios do repositório após alterar código relacionado a desafios. 2. Se ela falhar, inspecione todas as diferenças relatadas em vez de atualizar o cache imediatamente. 3. Determine se a diferença é uma regressão não intencional ou uma parte intencional da mudança. 4. Em uma refatoração intencional, aplique a mudança equivalente aos artefatos de correção e trechos correspondentes. 5. Atualize o cache de diferenças aprovadas somente depois que o código-fonte, o comportamento do desafio e os artefatos espelhados estiverem consistentes. 6. Execute novamente a rede de segurança e o fluxo de desafio relevante. Nunca use uma atualização de cache para ocultar diferenças não explicadas. Comportamentos de desafio novos ou alterados também exigem comprovação de ponta a ponta de que o desafio continua acessível, solucionável e detectado corretamente. ## Enviar traduções pela plataforma aprovada e fazer as verificações finais Não edite diretamente arquivos de localização gerados ou gerenciados externamente. Envie as alterações de tradução pela plataforma de localização aprovada pelo repositório para manter sincronizados o texto-fonte, o histórico de revisão e os arquivos gerados. Antes do envio: - Confirme que as verificações de estilo foram aprovadas e que o ruído gerado foi removido. - Confirme que todas as verificações unitárias, de integração, de frontend, de ponta a ponta e da rede de segurança exigidas pela mudança foram aprovadas. - Verifique o comportamento manualmente e inspecione o diff final em busca de alterações não intencionais. - Confirme a compatibilidade das dependências e do ambiente de execução. - Garanta que os commits atendam à política de sign-off do repositório. - Baseie a contribuição no branch de integração obrigatório e faça referência às issues relacionadas. - Documente a lógica complexa, a intenção de segurança, os testes executados e todas as exceções aprovadas. - Confirme que todas as verificações de integração contínua foram aprovadas. Se alguma verificação obrigatória não puder ser executada, declare explicitamente essa limitação. Não apresente uma verificação parcial como uma revisão completa de segurança ou da integridade do desafio.