Dirigir, revisar y validar la implementación

2443. Identidad de la lección

Módulo

5.16 — Proyecto final

Lección

Dirigir, revisar y validar la implementación

Tipo académico

Construcción guiada

Tipo de esquema

práctica

Orden

2 del módulo

Tiempo estimado

90–120 minutos, incluida la implementación, la revisión, las pruebas y la validación mediante juego

2444. Objetivo de aprendizaje

Al terminar esta lección, podrás dirigir y completar un cambio real y acotado en la implementación del proyecto final con asistencia de IA, revisarlo frente al brief aprobado y producir evidencias para cada criterio requerido.

2445. Por qué importa

Un proyecto final no está terminado porque una herramienta de IA haya generado código ni porque el juego se ejecute una vez. La implementación debe respetar el alcance aprobado, conservar el comportamiento existente y superar comprobaciones técnicas y de juego. Una revisión disciplinada convierte una afirmación vaga de finalización en evidencia que otra persona puede inspeccionar. Aquí practicas una habilidad central de estudio: dirigir el trabajo sin ceder tu criterio a la herramienta.

2446. Conocimientos previos

Debes haber completado la L1 — Definir el alcance y redactar el brief del proyecto final de 5.16 — Proyecto final, incluido un criterio de implementación explícitamente seleccionado y acotado, sus criterios de aceptación, sus objetivos excluidos, la definición de terminado y la lista de evidencias requeridas. Ese criterio es la entrega rectora de esta lección; no lo sustituyas por una solicitud de funcionalidades más amplia. También debes poder usar el flujo de trabajo con IA establecido en el curso, realizar un cambio pequeño en el repositorio, ejecutar el proyecto y hacer las pruebas o comprobaciones pertinentes enseñadas anteriormente.

2447. Concepto central

El concepto central son las pasadas controladas de implementación. No pidas a la IA que “termine el proyecto final” en una operación sin límites. Dirige una pasada acotada, inspecciona el resultado, valida y solo entonces continúa. La implementación se acepta únicamente cuando el comportamiento aprobado, el cambio de código, las comprobaciones de regresión y la validación mediante juego coinciden.

Una pasada útil tiene cuatro partes:

1. Contexto: proporciona el brief, los archivos relevantes, las restricciones y el estado actual.
2. Directiva: solicita un solo cambio específico con límites explícitos.
3. Revisión: inspecciona el diff y compáralo con los criterios de aceptación.
4. Validación: ejecuta las comprobaciones adecuadas y prueba la ruta relevante en el juego.

2448. Modelo mental

Usa el modelo GATE para cada requisito aprobado. Conserva las mismas cuatro puertas en el mismo orden:

La puerta no se supera si falta una fila. Una ejecución exitosa sin revisar el diff está incompleta; un diff limpio sin validación en juego también lo está cuando el criterio afecta al jugador.

2449. Ejemplo concreto

Supón que el brief aprobado exige una interacción visible para el jugador, un estado de éxito, un estado de fracaso y una ruta para reiniciar. Dirige el trabajo en pasadas separadas:

1. Pide a la IA que identifique la escena, el script y las transiciones de estado relevantes, sin editar nada.
2. Revisa ese contexto y solicita únicamente la regla de interacción y el cambio de estado asociado.
3. Inspecciona el diff. Rechaza el formato no relacionado, los archivos renombrados, las funciones especulativas y los cambios fuera del brief.
4. Ejecuta el proyecto y verifica la ruta de éxito.
5. Restablece el estado y verifica la ruta de fracaso.
6. Reinicia el encuentro y comprueba que la interacción pueda intentarse de nuevo.
7. Registra los pasos exactos y el resultado de cada criterio de aceptación.

El ejemplo es deliberadamente pequeño. Si el cambio no puede describirse como una secuencia acotada de comprobaciones observables, primero hay que aclarar el alcance.

2450. Flujo de trabajo nativo de IA

Usa la IA como colaboradora de implementación sensible al contexto, no como responsable del proyecto final.

Pasada 1: Preparar el contexto

Proporciona solo la información necesaria para la pasada actual:

• el criterio de aceptación relevante;
• el comportamiento aprobado y los objetivos explícitamente excluidos;
• los archivos o símbolos pertinentes;
• las restricciones del proyecto existente;
• la validación que realizarás después.

Pide a la herramienta que indique los archivos propuestos y los riesgos antes de editar. Si supone que existe un archivo, sistema o comportamiento que no existe, detente y corrige el contexto.

Pasada 2: Dirigir un solo cambio

Usa una directiva como esta:

Implementa únicamente el criterio C-02 del brief aprobado. Modifica la lógica de interacción identificada y su presentación. No añadas funciones, no reorganices código no relacionado y no cambies el comportamiento fuera de este criterio. Antes de editar, indica los archivos que modificarás y cómo validarás el resultado.

Una buena directiva define límites y validación. “Haz que esto sea mejor” no define ninguno de los dos.

Pasada 3: Revisar el resultado

Lee el diff por tu cuenta. Pide a la IA que explique la lógica modificada solo después de formar una primera evaluación propia. Compara su explicación con el código real. Comprueba:

• que el comportamiento coincide con el brief;
• que no haya lógica duplicada o inalcanzable;
• que el estado se reinicie correctamente;
• que no existan supuestos inseguros sobre referencias, valores nulos o tiempos;
• que no se hayan modificado sistemas no relacionados;
• que no queden código de depuración, atajos temporales o recursos no solicitados.

Las explicaciones de la IA son insumos para la revisión, no pruebas.

Pasada 4: Validar y registrar

Ejecuta las comprobaciones técnicas pertinentes y después prueba en el juego la ruta exacta que usaría el jugador. Si una comprobación falla, informa del fallo observado, el resultado esperado, la evidencia relevante y la corrección mínima siguiente. No pidas a la IA que oculte un fallo ni que reescriba el criterio de aceptación.

2451. Flujo de trabajo con Git

Usa el historial del repositorio como límite de seguridad y crea un punto de control revisable para el cambio acotado:

1. Confirma la rama, la revisión actual y el estado del repositorio antes de editar.
2. Revisa y registra cualquier trabajo sin confirmar. No lo incluyas silenciosamente en el cambio del proyecto final; si impide una línea base limpia, detente y resuelve o documenta el límite.
3. Establece la línea base registrando la revisión inicial, el estado y el comportamiento existente pertinente antes de implementar.
4. Realiza una pasada coherente de implementación para el criterio aprobado.
5. Inspecciona el diff y el estado; elimina los cambios no relacionados.
6. Ejecuta las comprobaciones y la validación de juego antes de considerar completa la pasada.
7. Crea o conserva un punto de control revisable según el flujo del proyecto, como un commit enfocado o una revisión claramente identificada. Registra su identificador y relaciónalo con el criterio aprobado y el registro de evidencias.

No mezcles limpieza no relacionada, actualizaciones de dependencias, experimentos con recursos ni refactorizaciones amplias con el cambio del proyecto final. Si el flujo del repositorio requiere un commit, su mensaje debe describir el cambio acotado, no afirmar que todo el proyecto está terminado.

2452. Error común

El error más común es aceptar la salida de la IA porque compila, se inicia o parece correcta. Compilar solo demuestra que se evitó una clase limitada de errores técnicos. No demuestra que el comportamiento aprobado funcione, que las rutas de fracaso y reinicio sean correctas ni que se haya conservado el comportamiento no relacionado. Revisa el cambio y prueba por separado la ruta que experimenta el jugador. Otro error es validar desde una línea base de Git poco clara, lo que impide distinguir el cambio aprobado del trabajo previo.

2453. Práctica guiada

Completa la siguiente sesión de implementación supervisada usando el brief aprobado del proyecto final.

1. Establece la línea base — 10 minutos

Escribe el criterio que implementarás, sus objetivos excluidos, los archivos o sistemas probablemente involucrados y las evidencias requeridas. Confirma la rama, la revisión inicial y el estado del repositorio. Revisa cualquier trabajo sin confirmar y registra si queda fuera del alcance de la lección. Inicia el proyecto desde un estado conocido y confirma el comportamiento existente relacionado con el criterio. Si la línea base ya está rota, regístralo antes de hacer cambios.

2. Dirige la pasada de contexto — 10 minutos

Pide a la IA que inspeccione el contexto relevante y devuelva:

• los archivos y símbolos que considera involucrados;
• el comportamiento actual que infiere;
• el cambio mínimo propuesto;
• los riesgos y la secuencia de validación prevista.

No permitas ediciones durante esta pasada. Compara la respuesta con el brief y corrige cualquier suposición falsa.

3. Implementa un cambio acotado — 20–30 minutos

Aprueba una directiva precisa para la primera pasada de implementación. Exige que la herramienta se mantenga dentro de los archivos y comportamientos nombrados, salvo que identifique una dependencia concreta. Si aparece una dependencia, detente y decide si pertenece al alcance o si requiere revisar el brief.

4. Revisa antes de reparar — 15–20 minutos

Inspecciona el diff línea por línea. Clasifica cada sección modificada como:

• requerida por el criterio;
• soporte necesario para el criterio;
• no relacionada o no respaldada.

Elimina o rechaza la tercera categoría. Para las dos primeras, escribe una frase que explique por qué el cambio es seguro. Después pide a la IA una revisión centrada en casos límite y compara sus hallazgos con los tuyos. Registra la revisión o el identificador del punto de control para que otra persona pueda inspeccionar el mismo cambio.

5. Valida técnicamente — 10–15 minutos

Ejecuta las comprobaciones pertinentes del flujo del proyecto. Registra el comando o la acción, el resultado y cualquier advertencia que requiera seguimiento. Un resultado exitoso no basta si una advertencia afecta al criterio.

6. Valida mediante juego — 15–20 minutos

Juega la ruta exacta descrita por los criterios de aceptación. Prueba la ruta principal y cada condición alternativa requerida, incluido el comportamiento en caso de fallo o reinicio cuando corresponda. Usa un registro breve de evidencias:

Criterio:
Contexto inicial y revisión de la línea base:
Directiva utilizada:
Punto de control de seguridad o identificador del historial:
Archivos modificados y revisión del diff:
Estado inicial:
Acciones del jugador:
Resultado observado:
Resultado esperado:
Comprobación técnica:
Superado / requiere corrección:
Ubicación o nota de evidencia:

7. Corrige y vuelve a comprobar — 10–15 minutos

Si alguna puerta falla, describe la diferencia con precisión y dirige la corrección mínima. Vuelve a inspeccionar el nuevo diff, actualiza el punto de control o registro del historial y repite toda validación afectada por la corrección. No marques el criterio como completo basándote solo en la primera ruta exitosa.

La decisión obligatoria es esta: elige si el cambio está listo para aceptación, necesita una corrección acotada o debe volver a revisión de alcance. Justifica la decisión con el brief, la directiva, el punto de control de seguridad o historial, el diff y el registro de evidencias.

2454. Validación / evidencia

2455. Puntos clave

• Dirige la IA mediante pasadas acotadas, no mediante una petición de finalización sin límites.
• Establece y registra una línea base de Git antes de editar y conserva un punto de control revisable.
• Revisa el diff real; la explicación de la IA no demuestra que el cambio sea correcto.
• Combina comprobaciones técnicas con validación desde la experiencia del jugador.
• Acepta un criterio solo cuando su contexto, directiva, punto de control e historial del repositorio, revisión del diff, comprobaciones técnicas y evidencias de juego sean trazables y completas.

2456. Siguiente lección

Continúa con 5.16 L3 — Defiende la decisión y documenta el trabajo.

2457. Comprobación