Taller del hito

538. Identidad de la lección

Módulo

1.micro-loop — El microbucle jugable

Lección

Taller del hito

Tipo académico

Integración

Tipo de esquema

Práctica

Orden

3 de 3 en este módulo

Tiempo estimado

45–90 minutos; la revisión externa puede completarse de forma asíncrona

Propósito

Armar el paquete de evidencias.

Concepto principal

Prueba, no pulido.

Capacidad

Ejecutar el bucle, mostrar los criterios y presentar evidencias de IA y Git.

539. Objetivo de aprendizaje

Después de esta lección, podrás armar y defender un paquete de evidencias que demuestre que un microbucle funciona, relacione el comportamiento observado con criterios explícitos, distinga las responsabilidades de entrada, regla, presentación y retroalimentación, y registre el checkpoint y las decisiones que respaldan el cambio.

540. Por qué importa

Un resultado jugable es solo una parte de un hito creíble. También debes mostrar qué debía ocurrir, qué probaste, qué estado cambió, quién era responsable de cambiarlo y qué modificación produjo el resultado. Las observaciones durante la ejecución prueban el comportamiento. Los registros de IA explican cómo dirigiste el trabajo, mientras que Git permite inspeccionar su historial y alcance.

Una comprobación realizada por alguien que no construyó el cambio permite saber si las instrucciones y evidencias son reproducibles. Esa persona puede ser un docente, un compañero, un revisor asíncrono u otra persona disponible más adelante. No disponer de alguien durante la sesión no supone un fallo de capacidad: marca la comprobación como pendiente y entrega instrucciones utilizables para revisarla después.

541. Conocimientos previos

Antes de este hito, debes poder definir una acción pequeña dirigida al jugador, distinguir una mecánica de su presentación, describir el ciclo ENTRADA → REGLA → PRESENTACIÓN → RETROALIMENTACIÓN, formular un cambio acotado con criterios de aceptación y exclusiones, dirigir una implementación pequeña, ejecutar el proyecto desde un estado conocido e identificar los archivos relevantes. También debes conservar el intercambio con la IA y el historial de Git generados durante la implementación anterior.

542. Concepto central

Prueba, no pulido significa evaluar el hito mediante criterios observables, no por su acabado visual. Un paquete de pruebas conecta cuatro elementos:

1. Intención: el comportamiento acotado que solicitaste.
2. Implementación: el cambio realizado en el proyecto.
3. Observación: el comportamiento reproducido durante la ejecución.
4. Evidencia: los artefactos que permiten inspeccionar la afirmación.

Antes de realizar otra corrección, conserva un checkpoint recuperable. Mantén un cambio solo si los criterios siguen cumpliéndose y el diff permanece dentro del alcance. De lo contrario, reviértelo y registra el motivo.

543. Responsabilidades canónicas del bucle

Usa directamente las etiquetas canónicas:

• ENTRADA: detecta la acción del jugador. No decide el resultado.
• REGLA: evalúa las condiciones y cambia el estado que gestiona o controla.
• PRESENTACIÓN: representa el estado resultante para que pueda percibirse. No se apropia del cambio de estado que corresponde a la regla.
• RETROALIMENTACIÓN: confirma el resultado mediante una señal inmediata.

Registra por separado si el bucle está listo para recibir otra entrada mediante el campo preparación para repetir. La retroalimentación puede ayudar al jugador a comprender el resultado, pero no controla la siguiente entrada salvo que la implementación le asigne de forma explícita esa responsabilidad adicional.

544. Modelo mental

Usa Afirmar → Guardar checkpoint → Ejecutar → Registrar → Inspeccionar:

Este modelo organiza el resultado para evaluarlo; no sustituye el bucle canónico.

545. Ejemplo concreto

Supón que el cambio acotado es: “Al usar el control existente, el estado activo cambia de color; no modifiques el manejo de la entrada, la regla subyacente, la retroalimentación ni archivos no relacionados”.

La evidencia distingue las responsabilidades:

• ENTRADA: el control existente detecta una activación.
• REGLA: la regla existente cambia el estado activo.
• PRESENTACIÓN: el color mostrado representa ese estado.
• RETROALIMENTACIÓN: una señal inmediata confirma el resultado.
• Preparación para repetir: después de reiniciar o restablecer, puede probarse de nuevo la misma acción.

Antes de intentar una corrección, registra el commit actual y el comportamiento base. Realiza solo la corrección propuesta. Consérvala si cumple los criterios y el diff sigue dentro del alcance; reviértela si rompe el bucle o introduce trabajo no relacionado. El paquete necesita evidencias suficientes para respaldar la afirmación y declarar las limitaciones, no un rediseño visual.

546. Flujo de trabajo nativo de IA

1. Conserva la solicitud acotada, la prueba de aceptación y las exclusiones de la lección anterior.
2. Selecciona las partes útiles del intercambio con la IA: solicitud, cambio propuesto y cualquier instrucción de corrección o verificación.
3. Toma exactamente una decisión explícita de aceptar o rechazar una propuesta de IA.
4. Relaciona el motivo con los criterios de aceptación, el alcance o la mantenibilidad.
5. Si aceptas un cambio, verifícalo durante la ejecución. Si lo rechazas, identifica el criterio o límite que habría incumplido y no apliques esa propuesta.
6. Etiqueta la evidencia de IA como dirección y trazabilidad, no como prueba del comportamiento en ejecución.

547. Flujo de trabajo con Git

1. Inspecciona el estado de trabajo y el diff actual.
2. Identifica los archivos relacionados con el cambio acotado.
3. Antes de una corrección nueva, crea o identifica un commit de checkpoint, un punto de rama o un estado recuperable equivalente.
4. Registra su identificador y el comportamiento base.
5. Realiza el cambio mínimo necesario y revisa el nuevo diff.
6. Registra una decisión de conservar o revertir relacionada con los criterios y el alcance.
7. Registra la rama, el checkpoint, el commit final, los archivos relevantes y cualquier trabajo no relacionado o limitación.

Git demuestra el historial y el alcance del cambio, no su comportamiento durante la ejecución. Un estado de trabajo limpio no prueba que el bucle funcione.

548. Errores comunes

• Tratar una captura o una pantalla pulida como prueba de todo el hito.
• Dar a entender que la PRESENTACIÓN realiza el cambio de estado que corresponde a la REGLA.
• Combinar la RETROALIMENTACIÓN con la preparación para la siguiente entrada en lugar de registrarlas por separado.
• Modificar el proyecto antes de conservar un checkpoint.
• Entregar toda la conversación con la IA sin seleccionar la evidencia que explica la decisión.
• Suponer que una ejecución propia demuestra que otra persona puede seguir las instrucciones.

549. Práctica guiada

Crea un paquete de evidencias para el cambio de microbucle de la lección anterior. Sigue esta secuencia:

1. Escribe una frase que indique el comportamiento que debe cumplirse y otra que indique qué no debe cambiar.
2. Convierte esa declaración en dos a cuatro criterios de aceptación observables. Cada criterio debe poder probarse durante la ejecución o mediante la inspección del cambio.
3. Añade un mapa canónico del bucle:

Mapa canónico del bucle:
- ENTRADA: [acción del jugador y cómo se detecta]
- REGLA: [condición evaluada, estado modificado y valor resultante]
- PRESENTACIÓN: [cómo se representa el estado resultante]
- RETROALIMENTACIÓN: [señal inmediata que confirma el resultado]
- Preparación para repetir: [cómo sabes que puede comenzar otro intento]

4. Añade una nota sobre la gestión del estado:

Nota sobre la gestión del estado:
- Estado gestionado: [estado o valor que cambia]
- Responsable del estado: [regla, componente o función responsable de cambiarlo]
- Leído por: [responsabilidad de presentación o retroalimentación que lo observa o representa]
- Límite: [qué no deben cambiar la presentación ni la retroalimentación]

5. Inspecciona el estado de trabajo y registra la línea base. Antes de realizar un cambio nuevo, crea o identifica un checkpoint recuperable y registra su identificador y comportamiento base.
6. Ejecuta el bucle al menos dos veces desde un estado inicial conocido. En cada ejecución, registra ENTRADA, resultado de la REGLA, PRESENTACIÓN, RETROALIMENTACIÓN y preparación para repetir.
7. Si necesitas una corrección, realiza solo ese cambio acotado. Decide si lo conservas o lo reviertes y explica el motivo mediante un criterio o límite de alcance.
8. Revisa el intercambio con la IA y toma exactamente una decisión de aceptar/rechazar una propuesta. Registra la decisión y el motivo.
9. Relaciona cada criterio de aceptación con una evidencia concreta. Marca cualquier criterio que no hayas probado.
10. Inspecciona el diff de Git y registra la rama, el checkpoint, el commit final, los archivos relevantes y cualquier problema de alcance.
11. Entrega el paquete y las instrucciones a un docente, compañero, revisor asíncrono u otra persona que no haya construido el cambio. Pídele que realice la prueba sin asistencia verbal. Si no hay nadie disponible durante la sesión, marca la revisión externa como pendiente, entrega las instrucciones y programa o solicita una revisión posterior.
12. Arma el paquete con esta plantilla:

Hito: [nombre breve]
Afirmación: [comportamiento que debe cumplirse]
Exclusiones: [comportamiento o archivos fuera del alcance]

Criterios de aceptación y mapa de evidencias:
- Criterio: [criterio observable]
  Evidencia: [registro de ejecución, diff u otro artefacto pertinente]
  Resultado: aprobado / fallido / no probado
- Criterio: [criterio observable]
  Evidencia: [artefacto]
  Resultado: aprobado / fallido / no probado

Mapa canónico del bucle:
- ENTRADA: [acción del jugador y detección]
- REGLA: [condición, estado gestionado y valor resultante]
- PRESENTACIÓN: [representación del estado resultante]
- RETROALIMENTACIÓN: [confirmación inmediata]
- Preparación para repetir: [evidencia de que puede comenzar otro intento]

Nota sobre la gestión del estado:
- Estado gestionado:
- Responsable del estado:
- Leído por:
- Límite:

Checkpoint antes del cambio:
- Rama base:
- Commit del checkpoint o estado recuperable:
- Comportamiento base:

Prueba en ejecución:
- Estado inicial:
- ENTRADA:
- Resultado de la REGLA:
- PRESENTACIÓN:
- RETROALIMENTACIÓN:
- Preparación para repetir:
- Resultado del primer intento:
- Resultado del segundo intento:

Decisión sobre el cambio:
- Cambio intentado:
- Decisión: conservar / revertir
- Motivo:
- Evidencia anterior y posterior:

Evidencia de IA:
- Solicitud acotada:
- Dirección o corrección relevante:
- Propuesta de IA:
- Decisión: aceptar / rechazar
- Motivo:

Evidencia de Git:
- Rama:
- Checkpoint:
- Commit final:
- Archivos relevantes:
- Revisión del alcance:

Comprobación ejecutable externa:
- Tipo de revisor: docente / compañero / revisor asíncrono / otro / pendiente
- Estado: completada / pendiente
- ¿Pudo ejecutar la prueba siguiendo estas instrucciones? sí / no / pendiente
- Resultado observado:
- Aclaración necesaria:
- Próximo paso de revisión si está pendiente:

Limitaciones o seguimiento:
[nota honesta, o “No se identificaron”]

550. Validación / evidencia

551. Ideas clave

• Un hito demuestra una afirmación acotada; no tiene que parecer terminado.
• La REGLA controla o gestiona el cambio de estado; la PRESENTACIÓN representa el estado y la RETROALIMENTACIÓN confirma el resultado.
• La preparación para repetir se registra por separado de la retroalimentación.
• La evidencia en ejecución demuestra el comportamiento, la evidencia de IA explica la dirección y las decisiones, y Git hace inspeccionables el alcance y el historial.
• La comprobación externa puede ser sincrónica o asíncrona; no debe considerarse fallida solo porque no había una persona disponible durante el taller.

552. Siguiente lección

El paquete verificado se convierte en la línea base de la Etapa 2. La siguiente lección transformará el bucle en un contrato explícito del sistema que cubra actores, entradas, reglas, resultados y el comportamiento vecino que debe permanecer protegido.

553. Comprobación