Inspecciona y decide

174. Identidad de la lección

Módulo

1.ai-partner — Dirigir al compañero de IA

Título

Inspecciona y decide

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

Lección 2 del módulo

Tiempo estimado de contenido y práctica

25–40 minutos

175. Objetivo de aprendizaje

Después de esta lección, podrás usar el artefacto de reglas de 1.3 como punto de control, inspeccionar un diff propuesto y aceptar, rechazar o pedir una revisión más acotada a partir de la evidencia del artefacto, el brief y el diff.

176. Por qué importa

La explicación de una IA es una afirmación sobre un cambio, no una prueba de que sea correcto. El artefacto de reglas de 1.3 establece los límites propios del proyecto. El brief acotado define el resultado solicitado y las exclusiones. El diff visible muestra qué pretende cambiar la IA.

Necesitas las tres fuentes antes de decidir. Una explicación convincente no justifica un archivo fuera del alcance, un valor modificado, una condición de seguridad eliminada, un símbolo renombrado o un efecto secundario no solicitado.

Esta lección termina con la decisión de inspección. Aquí no aplicarás el cambio ni probarás el comportamiento en ejecución. La siguiente lección aborda la validación después de aplicar un cambio aprobado.

177. Conocimientos previos

Debes haber completado la Lección 1 de 1.ai-partner, El brief es el trabajo, y el módulo 1.3, incluido su artefacto de reglas. Debes poder localizar el artefacto e identificar las reglas, áreas o archivos permitidos y áreas prohibidas que correspondan al cambio propuesto. No necesitas dominar un lenguaje de programación; inspeccionarás parches pequeños y anotados.

178. Concepto central

La explicación no es evidencia.

Usa tres fuentes para inspeccionar una propuesta:

1. El artefacto de reglas de 1.3 establece el límite aplicable del proyecto.
2. El brief indica el resultado solicitado, el alcance permitido y las exclusiones.
3. El diff revela los archivos, condiciones, valores y comportamientos que la IA propone cambiar.

Un diff muestra el límite entre el antes y el después:

• Las líneas añadidas pueden introducir comportamiento, datos o efectos secundarios.
• Las líneas eliminadas pueden borrar un comportamiento o una condición de seguridad.
• Las líneas modificadas pueden alterar condiciones, tiempos, valores o responsabilidades.
• Las ediciones no relacionadas demuestran un exceso de alcance, aunque parezcan inofensivas.

La decisión debe apoyarse en evidencia visible. Usa uno de estos tres resultados:

• Aceptar cuando la propuesta respeta el alcance permitido y representa el resultado solicitado.
• Rechazar cuando la propuesta incumple una regla o un límite explícito.
• Pedir una revisión más acotada cuando una parte válida puede separarse de las ediciones fuera de alcance o cuando el resultado solicitado no está definido con suficiente precisión para juzgar el comportamiento propuesto.

179. Modelo mental

Usa Punto de control de reglas → Afirmación → Diff → Decisión:

Establece el punto de control antes de usar la explicación de la IA como justificación. Así reduces el sesgo de confirmación: primero defines el límite y después comparas con él la afirmación y el diff.

Mantén visible el ciclo de trabajo del módulo:

ACTUAR → RESPONDER → CAMBIAR → OTRA VEZ

Actúas al entregar un brief acotado. La IA responde con una propuesta. La inspección determina si el cambio puede continuar. Si la evidencia revela un problema, repites el ciclo con un rechazo, una petición de aclaración o un brief más preciso.

La inspección es el punto de decisión entre RESPONDER y CAMBIAR. Las comprobaciones del comportamiento en ejecución y de la recepción de la acción corresponden a la siguiente lección.

180. Ejemplo concreto

Supón que la regla aplicable de 1.3 permite añadir una respuesta en un controlador de acciones existente, pero prohíbe cambiar asignaciones de entrada, constantes de movimiento y la presentación de la interfaz. El brief acota aún más ese límite:

Añade una respuesta de dash al controlador de acciones existente. Cambia únicamente PlayerController.js. No renombres acciones, no alteres la velocidad de movimiento ni modifiques la interfaz. Mueve al jugador 10 unidades una sola vez cuando se reciba la acción dash.

La IA afirma:

Añadí el soporte para dash y mantuve sin cambios el movimiento existente.

El diff propuesto es:

--- a/PlayerController.js
+++ b/PlayerController.js
@@
 function handleAction(action) {
+  if (action === "dash") {
+    player.position.x += 10;
+  }
   if (action === "move-left") {
     player.position.x -= player.speed;
   }
 }

El diff modifica únicamente el archivo indicado, comprueba la acción solicitada y representa el movimiento único pedido. Si el artefacto de reglas permite esa edición del controlador, es razonable aceptar la propuesta con la evidencia disponible.

La decisión no demuestra que el juego en ejecución entregue la acción ni que el cambio aplicado funcione. Esas comprobaciones corresponden a L3.

Ahora considera una propuesta dividida en grupos:

--- a/PlayerController.js
+++ b/PlayerController.js
@@
 function handleAction(action) {
+  if (action === "dash") {
+    player.position.x += 10;
+  }
 }
--- a/InputMap.js
+++ b/InputMap.js
@@
-  dash: "Shift",
+  dash: "Space",
--- a/HUD.js
+++ b/HUD.js
@@
-  drawActionLabel(currentAction);
+  drawActionLabel("DASH READY");

El grupo del controlador representa el comportamiento solicitado, pero los demás cambian una asignación de entrada y la presentación de la interfaz. Rechaza la propuesta completa o pide una revisión que incluya únicamente la edición permitida de PlayerController.js. Que el primer grupo sea válido no autoriza los demás.

181. Flujo de trabajo con IA

1. Lee la sección aplicable del artefacto de reglas de 1.3. Anota las áreas o archivos permitidos y prohibidos.
2. Lee el brief acotado. Identifica el resultado solicitado, el alcance permitido y las exclusiones explícitas.
3. Registra la afirmación de la IA sin tratarla como una prueba.
4. Inspecciona todos los archivos y grupos del diff propuesto.
5. Revisa las condiciones añadidas o eliminadas, los valores modificados, los símbolos renombrados y las ediciones no relacionadas.
6. Marca cada cambio como dentro del alcance, fuera del alcance o incierto.
7. Decide:
   • Acepta solo cuando el comportamiento representado y todas las ediciones cumplen las reglas y el brief.
   • Rechaza cuando alguna edición incumple una regla o un límite explícito.
   • Pide una revisión más acotada cuando las ediciones permitidas pueden separarse de las prohibidas.
   • Pide una aclaración cuando el brief no define el resultado con suficiente precisión para decidir si el comportamiento propuesto es correcto.
8. Cita la evidencia antes de permitir cualquier cambio.
9. No apliques la edición ni hagas comprobaciones de ejecución, recepción de entradas o validación posterior en esta lección.

182. Errores comunes

Dejar que la explicación defina el límite

Una explicación segura puede hacer que un comportamiento no solicitado parezca aceptable. El artefacto de reglas y el brief definen el límite; la explicación no lo hace.

Aceptar un comportamiento que el brief nunca especificó

Un brief como “añade una respuesta a interact” no indica si esa respuesta debe abrir, resaltar, recoger o inspeccionar el objetivo. Si el diff llama a target.open() con ese brief ambiguo, la decisión correcta es incierto: pide una aclaración o un brief más preciso. No deduzcas el resultado solicitado a partir de la implementación propuesta.

Inspeccionar únicamente el primer grupo válido

Cada archivo y grupo necesita su propia inspección. Una edición permitida del controlador no autoriza cambios en las entradas, el movimiento, el diálogo o la interfaz.

Tratar el diff como prueba de ejecución

Esta lección determina mediante inspección si la propuesta puede continuar. L3 valida el resultado aplicado y su comportamiento en ejecución.

183. Práctica guiada

Usa el artefacto de reglas de 1.3 de tu proyecto o de los materiales del curso. No edites un proyecto ni pruebes el comportamiento en ejecución. Basa cada decisión en la evidencia mostrada.

1. Establece el punto de control

Antes de leer la explicación de la IA, escribe un punto de control breve:

1. Nombra la regla o el grupo de reglas aplicable.
2. Indica el archivo o área permitida.
3. Indica al menos un área o cambio prohibido.
4. Marca cualquier límite que el artefacto deje incierto. No sustituyas la incertidumbre por una suposición.

Después, compara ese punto de control con el siguiente brief acotado:

Cuando InteractionController reciba la acción interact y exista un objetivo de interacción actual, abre ese objetivo exactamente una vez. Cambia únicamente InteractionController.js. No cambies el nombre de la acción, la velocidad del jugador, el texto del diálogo, las asignaciones de entrada ni la lectura de entradas. Si no existe un objetivo de interacción, no hagas nada.

Los criterios de aceptación son, por tanto:

• Solo cambia InteractionController.js.
• La condición exige tanto action === "interact" como la existencia de un objetivo.
• El objetivo actual recibe exactamente una llamada a open() por cada ejecución del controlador.
• No cambia ningún comportamiento de entrada, movimiento o diálogo.

2. Inspecciona la propuesta pequeña

Explicación de la IA:

Añadí la respuesta de interacción sin afectar los controles existentes.

Diff propuesto:

--- a/InteractionController.js
+++ b/InteractionController.js
@@
 function handleAction(action, target) {
+  if (action === "interact" && target) {
+    target.open();
+  }
 }

Escribe tres notas:

1. Límite: relaciona la regla aplicable y el brief con el archivo permitido y el resultado solicitado.
2. Evidencia: identifica el archivo, la condición y el comportamiento modificados. Marca cada punto como dentro del alcance, fuera del alcance o incierto.
3. Decisión: acepta, rechaza o pide una revisión más acotada de forma explícita. Cita la línea inspeccionada y el límite aplicable.

Con la evidencia mostrada, aceptar es apropiado solo si el artefacto de reglas de 1.3 permite esta edición del controlador. El diff se limita a InteractionController.js, exige la acción interact y la existencia de un objetivo, e incluye una sola llamada a target.open(). Esos hechos coinciden con el resultado y los criterios de aceptación definidos en el brief.

No uses suposiciones sobre la recepción de la acción durante la ejecución como evidencia en esta lección.

3. Inspecciona la propuesta amplia

Ahora inspecciona esta propuesta independiente sin aplicarla:

--- a/InteractionController.js
+++ b/InteractionController.js
@@
 function handleAction(action, target) {
+  if (action === "interact" && target) {
+    target.open();
+  }
 }
--- a/InputMap.js
+++ b/InputMap.js
@@
-  interact: "E",
+  interact: "F",
--- a/DialogueBox.js
+++ b/DialogueBox.js
@@
-  show(text);
+  show(text.toUpperCase());

Trata cada archivo como un grupo independiente y registra una decisión para cada uno:

• InteractionController.js representa la respuesta solicitada y puede aceptarse si el artefacto de reglas la permite.
• InputMap.js cambia una asignación de entrada que el brief excluye de forma explícita.
• DialogueBox.js cambia la presentación del diálogo, también excluida por el brief.

Rechaza la propuesta completa o pide una revisión que contenga únicamente el grupo permitido del controlador. No aceptes toda la propuesta porque uno de sus grupos sea válido.

4. Inspecciona una condición eliminada

Supón que otra revisión contiene este diff:

 function handleAction(action, target) {
-  if (action === "interact" && target) {
+  if (action === "interact") {
     target.open();
   }
 }

La eliminación de && target contradice el criterio “si no existe un objetivo de interacción, no hagas nada”. Rechaza esta propuesta o pide que se restaure la condición. La evidencia exacta es la condición eliminada, no una predicción sobre lo que podría ocurrir durante una prueba en ejecución.

184. Validación y evidencia

185. Comprobación de conocimientos

186. Puntos clave

• Establece el límite a partir del artefacto de reglas y el brief antes de usar la explicación de la IA como justificación.
• La explicación es una afirmación; el diff es evidencia que puedes inspeccionar.
• El brief debe definir el resultado solicitado con suficiente precisión para juzgar la implementación.
• Inspecciona todos los archivos, grupos, condiciones, valores, símbolos renombrados y condiciones eliminadas.
• Una edición válida no autoriza cambios no relacionados.
• La inspección se sitúa entre RESPONDER y CAMBIAR.
• L2 decide si una propuesta puede continuar; L3 valida el resultado aplicado y el comportamiento en ejecución.

187. Próxima lección

Continúa con 1.ai-partner L3 — Valida lo que cambió.

188. Laboratorio de depuración — Entrada rota (fix-broken-input)

Abre academy-fixtures/labs/broken-input. Ejecuta node diagnose.mjs. Predice pulse-en-beat-0. Restaura la mutación de simulación en tu copia de Pulse Loop; no falsifiques la presentación. Evidencia: JSON de diagnose + validate posterior. Git: checkpoint antes del arreglo.

189. Independencia frente a la IA (fix-ai-bounded-change)

Abre academy-fixtures/labs/ai-bounded-change. Ejecuta node run.mjs. Acota la tarea, inspecciona la propuesta, ejecuta un oráculo independiente, RECHAZA quitar la comprobación de energía del dash. La IA es una colaboradora acotada, no quien decide.

190. Comprobación

- if (action === "interact" && target) {
+ if (action === "interact") {
    target.open();
  }
```**

A. Aceptar, porque el nombre de la acción no cambia
B. Aceptar, porque `open()` sigue apareciendo exactamente una vez en el código
C. Rechazar o pedir una corrección porque eliminar `&& target` incumple el criterio para cuando no existe un objetivo
D. Pedir una aclaración porque el brief no especifica qué hacer cuando no existe un objetivo

<details>
<summary>Mostrar respuesta y explicación</summary>

*Respuesta:* Rechazar o pedir una corrección porque eliminar `&& target` incumple el criterio para cuando no existe un objetivo

*Por qué:* La condición eliminada `&& target` demuestra que la propuesta contradice un criterio de aceptación explícito. No hace falta una prueba en ejecución para tomar esta decisión de inspección.

</details>

**Un brief solo indica: «Añade una respuesta cuando se reciba `interact`». El `diff` propuesto llama a `target.open()`, pero no se define el resultado esperado. ¿Qué debes hacer?**

A. Rechazarlo de forma definitiva porque `open()` nunca es una interacción válida
B. Aplicarlo primero y dejar que el resultado en ejecución defina el requisito
C. Aceptar porque abrir es una interacción habitual
D. Pedir una aclaración o un brief más preciso antes de aceptar el comportamiento

<details>
<summary>Mostrar respuesta y explicación</summary>

*Respuesta:* Pedir una aclaración o un brief más preciso antes de aceptar el comportamiento

*Por qué:* La implementación propuesta no puede definir el requisito. Sin un resultado especificado, `open()` es una interpretación incierta, no una solución demostrada; por eso corresponde pedir una aclaración.

</details>