Modificar una app de formación en seguridad con fallos intencionados sin romper sus retos

## Distinguir los retos intencionados de las vulnerabilidades accidentales Trata una aplicación de formación deliberadamente vulnerable de manera diferente a una aplicación de producción ordinaria. Algunos comportamientos inseguros son contenido educativo deliberado, mientras que otras debilidades son defectos involuntarios. - Antes de cambiar el comportamiento afectado, determina si se trata de un reto previsto, infraestructura de apoyo o una vulnerabilidad accidental. - No elimines, debilites ni añadas comportamientos del reto basándote únicamente en una sugerencia automatizada. - Las nuevas vulnerabilidades y los nuevos retos requieren la aprobación de los mantenedores y documentación clara. - Confirma que el reto propuesto sea diferenciado, resoluble, funcional y adecuado para los objetivos de aprendizaje. - Conserva las pistas del reto, los metadatos, las rutas de solución y los comentarios relevantes para la seguridad que expliquen una intención que no sea evidente. - Revisa de forma crítica el código generado. El contribuidor y el revisor siguen siendo responsables de la corrección, la seguridad y el valor educativo. Cuando la intención no esté clara, rastrea la ruta de ejecución, las pruebas, los metadatos del reto y los artefactos de corrección replicados antes de decidir qué debe cambiar. ## Planificar un cambio que resuelva un solo problema Comienza por localizar el componente pertinente, rastrear su flujo de datos y encontrar los patrones de implementación y pruebas establecidos. 1. Define el único problema que resolverá el cambio. 2. Identifica los artefactos de servidor, cliente, API, datos, plantilla, configuración y reto afectados por ese problema. 3. Busca código similar y sigue los patrones actuales del repositorio. 4. Revisa las implicaciones de seguridad antes de la implementación. 5. Propón pruebas que distingan el comportamiento previsto de las regresiones. 6. Mantén la limpieza no relacionada y los cambios triviales fuera de la misma contribución. Consulta a los mantenedores antes de crear retos, cambiar la arquitectura o modificar el modelo de dependencias. Verifica cualquier actualización de paquetes con respecto a todos los manifiestos de dependencias y rangos de ejecución pertinentes. No añadas opciones de configuración ni dependencias especulativas sin una necesidad demostrada y pruebas de compatibilidad. Trabaja desde la rama de integración designada por el repositorio y utiliza una rama de funcionalidad específica. Haz referencia al issue pertinente y limita la contribución a un único propósito coherente. ## Quitar el relleno generado por IA y pasar el linter Limpia la salida automatizada antes de la revisión. Elimina los comentarios extensos que se limiten a repetir código evidente, los marcadores de posición genéricos, las cadenas de documentación excesivas para funciones simples, las explicaciones repetitivas, los registros de depuración y otros residuos generados. Conserva los comentarios que expliquen lógica compleja, la intención del reto, restricciones de seguridad o una solución alternativa necesaria. Ejecuta el linter del repositorio para cada cambio de código, salvo que el cambio se limite a documentación que el repositorio haya eximido explícitamente. El código generado debe seguir las mismas reglas de estilo que el código escrito a mano. - Corrige los fallos de lint en lugar de dar por hecho que la sugerencia es correcta. - No conserves código innecesario solo porque lo haya generado un asistente. - Comprueba el diff en busca de cambios masivos de formato y modificaciones de archivos no relacionadas. - Utiliza nombres claros y comentarios concisos que ayuden a futuros mantenedores a comprender la intención. - Asegúrate de que la documentación y el texto del commit describan el cambio real y no el proceso del asistente. ## Ejecutar las pruebas que exige cada tipo de cambio Los requisitos de prueba dependen del área modificada, pero la confianza de un asistente nunca sustituye la ejecución. - Añade o actualiza pruebas unitarias para la lógica modificada. - Ejecuta pruebas de integración de la API cuando cambien la gestión de solicitudes, la persistencia, la autorización o el comportamiento de la respuesta. - Ejecuta pruebas unitarias de frontend para componentes y servicios del lado del cliente. - Ejecuta pruebas de extremo a extremo para retos nuevos o modificados y para comportamientos entre capas. - Ejecuta la suite de pruebas completa del repositorio antes del envío, salvo que el repositorio exima explícitamente la documentación modificada. - Verifica manualmente el flujo visible para el usuario o el flujo de resolución del reto. - Ejecuta la red de seguridad para la refactorización de retos siempre que cambie código fuente existente relacionado con un reto. Durante la iteración, utiliza la suite específica más pequeña; después, ejecuta la matriz completa requerida antes de la revisión. Registra los comandos y resultados exactos. No afirmes que se ha tenido éxito basándote únicamente en el análisis estático ni omitas una suite lenta porque el código generado parezca plausible. ## Mantener sincronizados el código de los retos y sus archivos de corrección El código fuente relacionado con el reto puede estar replicado en fragmentos, correcciones esperadas, metadatos o artefactos almacenados en caché de la red de seguridad. Una refactorización está incompleta si estas representaciones divergen. 1. Ejecuta la red de seguridad para la refactorización de retos del repositorio después de cambiar código relacionado con un reto. 2. Si falla, inspecciona todas las diferencias notificadas en lugar de actualizar inmediatamente la caché. 3. Determina si la diferencia es una regresión involuntaria o una parte intencionada del cambio. 4. Para una refactorización intencionada, aplica el cambio equivalente a los artefactos de corrección y fragmentos correspondientes. 5. Actualiza la caché de diferencias aprobadas solo después de que el código fuente, el comportamiento del reto y los artefactos replicados sean coherentes. 6. Vuelve a ejecutar la red de seguridad y el flujo pertinente del reto. Nunca utilices una actualización de la caché para ocultar diferencias sin explicar. El comportamiento nuevo o modificado de un reto también requiere una prueba de extremo a extremo de que el reto sigue siendo accesible, resoluble y detectado correctamente. ## Enviar traducciones por la plataforma aprobada y hacer las comprobaciones finales No edites directamente los archivos de localización generados o gestionados externamente. Envía los cambios de traducción a través de la plataforma de localización aprobada por el repositorio para que el texto fuente, el historial de revisiones y los archivos generados permanezcan sincronizados. Antes del envío: - Confirma que las comprobaciones de estilo se superen y que el ruido generado haya desaparecido. - Confirma que se superen todas las comprobaciones unitarias, de integración, de frontend, de extremo a extremo y de la red de seguridad que requiera el cambio. - Verifica manualmente el comportamiento e inspecciona el diff final en busca de cambios involuntarios. - Confirma la compatibilidad de las dependencias y el entorno de ejecución. - Asegúrate de que los commits cumplan la política de sign-off del repositorio. - Basa la contribución en la rama de integración requerida y haz referencia a los issues relacionados. - Documenta la lógica compleja, la intención de seguridad, las pruebas ejecutadas y cualquier excepción aprobada. - Confirma que se superen todas las comprobaciones de integración continua. Si no se pudo ejecutar alguna comprobación requerida, indica explícitamente esa limitación. No presentes una verificación parcial como una revisión completa de seguridad o de integridad del reto.