Lo que un cambio no debe hacer

101. Objetivo de aprendizaje

Después de esta lección, podrás redactar una mutación principal permitida y dos invariantes independientes para una mecánica, distinguir las reglas protegidas de las preferencias y rechazar una mutación propuesta que exceda el alcance solicitado.

102. Por qué importa

Un comportamiento solicitado puede parecer correcto y, al mismo tiempo, modificar otra regla. Un buen límite de cambio indica tanto lo que puede cambiar como lo que debe seguir siendo cierto. Así puedes inspeccionar una propuesta antes de autorizar una edición.

103. Conocimientos previos

Debes poder redactar un invariante observable para una mecánica. Esta lección no requiere editar el proyecto ni interpretar un diff archivo por archivo.

104. Concepto central: el límite del cambio

Un límite de cambio tiene cuatro partes:

• Mutación principal permitida: el único comportamiento o valor que puede cambiar.
• Invariantes: condiciones protegidas e independientes que deben seguir siendo ciertas.
• Mutaciones prohibidas: cambios propuestos que violan un invariante o alteran una regla no relacionada.
• Preferencias: decisiones de implementación o presentación que no constituyen reglas de juego.

Dos invariantes aportan información independiente cuando uno puede incumplirse aunque el otro siga cumpliéndose.

Considera esta petición hipotética sobre un objeto de salud:

Cambia el objeto para que restaure 15 puntos de salud en vez de 10. La salud máxima actual es 100.

Un límite útil sería:

• Mutación permitida: cambiar de 10 a 15 la cantidad de curación.
• Invariante 1 — Valor de salud máxima: la salud máxima sigue siendo 100.
• Invariante 2 — Límite de salud: la salud final del jugador nunca supera la salud máxima actual.

Estas reglas protegen propiedades distintas. La salud máxima podría aumentar a 120 y la salud seguiría estando dentro del máximo: se incumpliría el Invariante 1, pero no el Invariante 2. También podría mantenerse el máximo en 100 y, debido a un fallo, quedar la salud final en 105: se incumpliría el Invariante 2, pero no el Invariante 1.

Por tanto, usar el objeto con la salud completa es una prueba de caso límite del invariante de límite de salud, no un segundo invariante. Si la salud empieza en 100, el valor final tras la acción no debe superar 100.

105. Puntos de comprobación observables

106. Ejemplo resuelto

Para la petición hipotética, un artefacto completo podría decir:

Cambio solicitado: restaurar 15 puntos de salud en vez de 10.

Mutación principal permitida: cambiar únicamente de 10 a 15 la cantidad de curación.

Invariante 1 — Valor de salud máxima: la salud máxima sigue siendo 100. Evidencia: comparar el valor visible o proporcionado de salud máxima antes y después de la propuesta.

Invariante 2 — Límite de salud: la salud final nunca supera la salud máxima. Evidencia: usar el objeto cerca del máximo y con la salud completa; inspeccionar el valor final tras cada intento.

Mutaciones prohibidas: no aumentar la salud máxima ni cambiar valores de daño no relacionados.

Preferencia: se puede usar un nombre más claro para el valor de curación si no cambia el comportamiento.

La comprobación con la salud completa aporta evidencia para el Invariante 2. No debe repetirse como si fuera otra regla protegida.

107. Propuesta fija para inspeccionar

Usa esta propuesta en lugar de depender de una respuesta impredecible de la IA:

Propuesta simulada

1. Cambiar de 10 a 15 la cantidad de salud que restaura el objeto.
2. Aumentar la salud máxima de 100 a 120 para que el objeto más potente resulte más útil.
3. Cambiar el nombre del valor de curación de heal a healingAmount para que sea más claro.

Clasifica cada elemento antes de comparar tu respuesta con una IA:

Si una preferencia de implementación es ambigua o podría ocultar un cambio de comportamiento, pide una aclaración en vez de aceptarla automáticamente.

108. Flujo de trabajo con IA

Usa la IA como apoyo para aclarar e inspeccionar, no como editora del proyecto:

1. Indica el cambio solicitado.
2. Nombra exactamente una mutación principal permitida.
3. Redacta dos invariantes independientes y explica qué propiedad distinta protege cada uno.
4. Asocia evidencia observable a cada invariante.
5. Clasifica por tu cuenta cada elemento de la propuesta fija.
6. Si quieres, pide a una IA que clasifique los mismos elementos y explique su razonamiento.
7. Compara su clasificación con tu límite. No trates la respuesta de la IA como una prueba.

Usa esta estructura:

Mecánica:
Cambio solicitado:
Mutación principal permitida:
Invariante 1 y propiedad protegida:
Invariante 2 y propiedad protegida:
Evidencia observable:
Mutaciones prohibidas:
Preferencias:
Fuera de alcance:

109. Contexto opcional de Git

En esta lección, Git solo aporta contexto. Si el docente facilita una transcripción del repositorio, anota la rama y el resumen del último commit que aparezcan en ella. Si ya tienes acceso a un repositorio, puedes ejecutar de forma opcional:

git status --short --branch
git log -1 --oneline

No edites archivos, prepares cambios, crees commits, cambies de rama, restablezcas, fusiones ni publiques nada. Tampoco interpretes aquí un diff ruta por ruta. Si no hay repositorio ni transcripción, escribe: «Contexto del repositorio no disponible». Esto no impide completar la lección.

110. Práctica guiada

Utiliza la propuesta fija:

1. Copia el cambio solicitado en la plantilla.
2. Escribe exactamente una mutación principal permitida.
3. Redacta el invariante del valor de salud máxima y el invariante del límite de salud.
4. Explica en una frase por qué protegen propiedades distintas.
5. Para cada invariante, indica un punto de comprobación observable y la evidencia que registrarías.
6. Clasifica los elementos 1–3 como aceptar, rechazar o pedir aclaración. Puedes marcar una preferencia aceptada como opcional.
7. Justifica por qué debe rechazarse el elemento 2 en vez de incorporarlo al encargo.
8. Identifica la situación de salud completa como una prueba de caso límite del invariante de límite de salud.
9. Si quieres, registra el contexto básico de Git descrito anteriormente.

111. Actividad práctica puntuada

Entrega un artefacto de límites para la propuesta fija. Estará completo cuando incluya:

• el cambio solicitado;
• exactamente una mutación principal permitida;
• dos invariantes independientes con nombre;
• una explicación de la propiedad distinta que protege cada uno;
• evidencia observable basada en el estado previo, la respuesta inmediata mostrada, el estado final o la repetición de un caso límite;
• una decisión para los tres elementos de la propuesta;
• una justificación para rechazar la modificación de la salud máxima; y
• una preferencia claramente separada de las reglas de juego.

Asigna un punto a cada requisito. Un artefacto completo obtiene 8 de 8. Corrige cualquier requisito ausente o confundido antes de continuar.

112. Errores comunes

• Tratar el uso con la salud completa como un segundo invariante, en vez de como una prueba del límite de salud.
• Aceptar una mutación fuera de alcance porque la propuesta también contiene el cambio solicitado.
• Presentar una preferencia de nomenclatura como una regla de juego.
• Afirmar que existe evidencia procedente de un estado interno que no puede observarse.
• Tratar el estado del repositorio o una explicación de la IA como prueba de que se cumplen las reglas durante la ejecución.

113. Puntos clave

• Define una sola mutación permitida antes de evaluar una propuesta.
• Usa invariantes independientes que protejan propiedades distintas de la mecánica.
• Comprueba los invariantes mediante puntos observables y casos límite relevantes.
• Rechaza las mutaciones de juego no relacionadas en vez de ampliar el encargo para incluirlas.
• Mantén las preferencias inocuas separadas del comportamiento obligatorio.

114. Siguiente lección

A continuación, inspeccionarás un diff pequeño y describirás en lenguaje sencillo qué hizo. La creación de commits y la reversión de cambios aparecerán más adelante en la secuencia de checkpoints.

115. Comprobación