Inspeccionar, validar y recuperar

2126. Identidad de la lección

Módulo

5.5 — Seguridad de los cambios

Lección

Inspeccionar, validar y recuperar

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

2

Tiempo estimado

35–45 minutos, incluida la práctica

Este laboratorio utiliza el límite de cambio definido en 5.5 L1 — Establecer un límite seguro para los cambios. Inspeccionarás un cambio propuesto, compararás su diferencia con el alcance autorizado, ejecutarás las comprobaciones previstas y elegirás una acción de recuperación basada en evidencias.

2127. Objetivo de aprendizaje

Al finalizar esta lección, podrás utilizar una línea base, una diferencia y resultados de validación para aceptar un cambio acotado, solicitar una corrección acotada o revertir el cambio y documentar la decisión.

2128. Por qué importa

Que el código se ejecute no significa que el cambio sea seguro. Una edición generada por IA puede compilar y aun así modificar un archivo excluido, alterar un comportamiento relacionado o incumplir un criterio de aceptación. La revisión se vuelve fiable cuando la decisión se vincula con el límite autorizado y con evidencias observables. El objetivo no es conservar todas las líneas generadas, sino proteger el comportamiento previsto del juego y controlar el cambio.

2129. Conocimientos previos

Debes haber completado 5.5 L1 — Establecer un límite seguro para los cambios. Lleva su evidencia de línea base, el checkpoint o commit de Git identificado, la solicitud dentro del alcance, los no objetivos, las comprobaciones de validación y la condición de reversión. También debes poder inspeccionar un diff de Git y ejecutar las comprobaciones o pruebas manuales establecidas para el proyecto.

2130. Concepto central

Una revisión puede terminar en tres resultados:

• Aceptar: La diferencia permanece dentro del alcance, el comportamiento previsto supera la validación y no aparece una regresión relevante.
• Corregir: El cambio está cerca de ser aceptable, pero contiene un defecto concreto que puede corregirse sin ampliar el alcance. Después hay que revisar y validar de nuevo.
• Revertir: Restaura la línea base nombrada cuando los efectos no intencionados siguen sin explicarse, no pueden aislarse con confianza, o restaurar la línea base limpia es más seguro que una corrección acotada. Una comprobación fallida o una infracción de alcance hacen inaceptable el diff actual, pero no prohíben automáticamente una corrección acotada si cada edición no intencionada está identificada.

La decisión debe seguir a las evidencias, no a la confianza en la IA ni al apego al código generado. Una diferencia pequeña también puede ser incorrecta, y una diferencia grande no es automáticamente incorrecta; el alcance y el comportamiento determinan la decisión.

2131. Modelo mental

Utiliza la secuencia de revisión TRACE:

No pases directamente de Revisión a Aceptar. La diferencia explica la modificación de implementación; la validación demuestra si el juego todavía cumple el contrato.

2132. Ejemplo concreto

Usa la tarea acotada de la lección anterior: aclarar el mensaje que aparece cuando al jugador no le alcanza la moneda para usar un objeto. El cálculo de moneda, el coste del objeto, el resultado de la compra y los demás mensajes están excluidos.

Imagina que la revisión produce estas evidencias:

• La diferencia cambia el mensaje previsto y también modifica la comparación del coste del objeto, de currency >= cost a currency > cost.
• El mensaje nuevo aparece en el caso de moneda insuficiente.
• Una comprobación confirma que el mensaje es más claro.
• Otra comprobación muestra que ya no se puede usar un objeto cuando el jugador tiene exactamente la moneda necesaria para pagar su coste. Con currency > cost, la igualdad se rechaza aunque currency >= cost permitiría la compra; esto constituye una regresión de comportamiento en un área excluida.

El diff actual no es aceptable tal como está porque cruza un no objetivo explícito y falla una comprobación de comportamiento. Sin embargo, ese hallazgo no determina por sí solo el mecanismo de recuperación. Elige una corrección acotada si la inspección demuestra que se han identificado todas las ediciones no previstas, que se comprenden sus efectos y que pueden eliminarse sin salir del límite original. En este caso, podría restaurarse currency >= cost, conservar únicamente el cambio de mensaje autorizado, inspeccionar el diff resultante y repetir todas las comprobaciones pertinentes.

Elige revertir cuando los efectos no previstos no se comprendan por completo, no puedan aislarse con confianza o sea más seguro restaurar una línea base limpia que modificar un cambio mezclado. Después de revertir, verifica tanto el estado del repositorio como el caso de igualdad frente a la línea base identificada. Ambas decisiones solo son defendibles si las respaldan el diff de Git sin resumir, el código circundante, los resultados de validación y las evidencias de recuperación: la infracción de alcance impide aceptar el cambio, pero no obliga automáticamente a revertirlo.

2133. Flujo de trabajo nativo de IA

Usa la IA como asistente de inspección, no como autoridad para decidir si su propio trabajo es seguro:

1. Entrégale el alcance autorizado, los no objetivos, la referencia de línea base, la diferencia y los resultados de validación.
2. Pídele que resuma cada archivo o valor modificado, detecte posibles infracciones de alcance y relacione cada cambio con la solicitud.
3. Compara ese resumen con la diferencia real. Si el resumen omite o describe mal un cambio, la diferencia es la fuente de verdad.
4. Pídele hipótesis sobre las comprobaciones fallidas, pero trátalas como hipótesis hasta verificarlas mediante inspección o pruebas.
5. Si procede corregir, indica exactamente qué puede corregirse y qué debe permanecer intacto. No autorices una limpieza general.
6. Después de cualquier corrección, inspecciona la nueva diferencia frente a la línea base original y repite todas las validaciones pertinentes.
7. Registra tu propia decisión —aceptar, corregir o revertir— y las evidencias que la sustentan.

La explicación de la IA puede ayudar a localizar un defecto, pero no sustituye la diferencia, el resultado de ejecución ni la verificación de recuperación.

2134. Error común

El error común es evaluar el cambio a partir del prompt o del resumen de la IA, en lugar de hacerlo a partir de la diferencia real y del comportamiento observado. Otro error es deshacer manualmente solo una parte después de una comprobación fallida, dejando el proyecto en un estado incierto. Cuando los efectos no previstos siguen sin explicarse, no pueden aislarse con confianza, o restaurar el punto de recuperación de Git nombrado es más seguro que una corrección acotada, restáuralo mediante el flujo establecido del proyecto y verifica de nuevo la línea base.

2135. Práctica guiada

Realiza este ejercicio en un repositorio pequeño preparado o en una rama desechable de tu proyecto de aprendizaje. Utiliza una solicitud acotada sobre un texto o mensaje de interfaz cuyo comportamiento puedas observar durante la ejecución. No trabajes directamente en una rama que no puedas restaurar con seguridad.

1. Registra la línea base. Antes de aplicar el cambio propuesto, guarda la referencia del commit o checkpoint, captura la salida de git status --short y ejecuta al menos una comprobación de comportamiento pertinente. Anota los pasos, el resultado esperado y el resultado real.
2. Crea un cambio mezclado. Aplica o solicita el cambio acotado del mensaje. En la rama desechable, asegúrate de que el cambio incluya también una edición claramente ajena al alcance y una modificación de lógica adyacente que pueda afectar un comportamiento observable. Registra quién introdujo cada edición; no sustituyas las evidencias del repositorio por un resumen.
3. Inspecciona el repositorio. Captura la lista de archivos modificados con git diff --name-only, examina el git diff completo y lee suficiente código circundante para comprender cada bloque. Clasifica cada bloque como incluido, cuestionable o fuera de alcance y relaciónalo con la solicitud o con un no objetivo.
4. Valida el comportamiento. Repite la comprobación original y ejecuta al menos otra dirigida a la modificación de lógica adyacente. Conserva los comandos o pasos manuales, los resultados esperados y reales, y cualquier salida pertinente de la ejecución.
5. Decide a partir de las evidencias. Acepta solo si todo el diff está dentro del alcance y todas las comprobaciones pasan. Elige una corrección acotada solo si has identificado todas las ediciones y efectos no previstos y puedes eliminarlos dentro del límite original. Revierte si quedan efectos sin explicar, no puedes aislarlos con confianza o resulta más seguro restaurar el estado limpio.
6. Ejecuta la decisión. Si corriges, elimina únicamente las ediciones no previstas que hayas identificado. Si reviertes, usa el checkpoint registrado y el procedimiento de recuperación establecido para el repositorio. No te limites a describir lo que harías.
7. Verifica el estado final. Captura git status --short y el diff final o la referencia del commit. Repite las comprobaciones de ejecución afectadas y compáralas con la línea base registrada. Si corregiste, confirma que solo permanece el cambio autorizado; si revertiste, confirma que el estado del repositorio y el comportamiento coinciden con la línea base.
8. Entrega un registro de decisión. Incluye la referencia de línea base, los hallazgos del diff completo, la lista de archivos modificados, la clasificación de cada bloque, las evidencias de validación, la acción elegida, la corrección o recuperación ejecutada, el estado final del repositorio, las evidencias de comportamiento posteriores y una justificación breve.

Una infracción de alcance hace que el cambio mezclado sea inaceptable tal como está, pero no obliga automáticamente a revertirlo. Tu registro debe explicar por qué la corrección o la reversión fue la opción más segura según las evidencias observadas. La confianza de la IA no cuenta como evidencia.

2136. Validación / evidencia

2137. Ideas clave

• Revisa la diferencia real antes de juzgar un cambio generado por IA.
• Aceptar exige cumplir el alcance y superar las comprobaciones de comportamiento.
• Corregir solo es apropiado cuando el defecto es concreto y puede mantenerse dentro del límite original.
• Una comprobación fallida o una infracción de alcance hacen inaceptable el diff actual, pero no descartan automáticamente una corrección acotada. Revierte cuando los efectos no intencionados no pueden aislarse con confianza o restaurar la línea base limpia es más seguro.
• La decisión final corresponde al desarrollador y debe apoyarse en evidencias conservadas.

2138. Próxima lección

Siguiente: 5.6 — Estrategia para repositorios grandes. Conserva la referencia de la línea base, los hallazgos del diff, las evidencias de validación y el registro de decisión. En la próxima lección usarás estas evidencias para identificar límites de propiedad, dependencias afectadas, ubicaciones seguras para realizar cambios y riesgos probables en un repositorio desconocido.

2139. Comprobación