Establecer un límite seguro para los cambios

2112. Identidad de la lección

Módulo

5.5 — Seguridad del cambio

Lección

Establecer un límite seguro para los cambios

Tipo académico

Flujo de trabajo

Tipo de esquema

Mixto

Orden

1

Tiempo estimado

30–40 minutos, incluida la práctica

Esta lección establece un paso de preparación repetible antes de pedirle a un sistema de IA que modifique un proyecto de juego. El objetivo no es eliminar el riesgo. El objetivo es dejar explícitos el cambio previsto, sus límites, la referencia verificada de la línea base y la evidencia necesaria para decidir si una edición está lista para autorizarse.

2113. Objetivo de aprendizaje

Al finalizar esta lección, podrás elaborar un plan de seguridad para un cambio acotado que identifique una línea base verificada y una referencia estable de Git, evalúe el impacto y la probabilidad, defina el trabajo incluido y excluido, especifique evidencias de validación y elija un plan de recuperación adecuado al estado del repositorio antes de autorizar cualquier edición.

2114. Por qué importa

Un cambio asistido por IA puede ser correcto en una parte y aun así dañar comportamientos, escenas, datos o configuración que no estaban relacionados. Un límite seguro te da un punto de comparación antes del cambio y una regla de decisión. Un identificador de commit, u otra referencia estable aprobada por el repositorio, convierte esa línea base en algo localizable, no solo recordado. También entrega a la IA una tarea más precisa y hace que la revisión sea más objetiva.

2115. Conocimientos previos

Debes poder inspeccionar el contexto del proyecto, detectar fuentes obsoletas o engañosas y describir la incertidumbre antes de solicitar una modificación. Esta lección continúa 5.4 L2 — Detectar contexto obsoleto o engañoso. También debes saber cómo inspeccionar el estado del repositorio y usar los procedimientos de Git aprobados en el proyecto para registrar una línea base y tratar archivos rastreados, en staging, no rastreados o generados.

2116. Concepto central

Un límite seguro para el cambio es un contrato escrito alrededor de una modificación. Sus cinco partes conceptuales son:

1. Línea base: Qué es cierto y está verificado antes del cambio.
2. Riesgo: Qué podría verse afectado, y con qué impacto o probabilidad.
3. Alcance: Qué puede cambiar la solicitud y qué debe quedar fuera.
4. Validación: Qué comprobaciones observables decidirán si el cambio es aceptable.
5. Recuperación: Cómo volver a la línea base si el resultado falla las comprobaciones o excede el alcance.

Estas cinco partes describen la estructura de la decisión. El modelo BOUNDARY que aparece a continuación —un mnemónico en inglés— las amplía a ocho elementos operativos para preparar el cambio y decidir si está listo para autorizarse. Los ocho elementos no sustituyen a las cinco partes: la línea base corresponde a B, el riesgo a O, el alcance a U y N, la validación a D y A, y la recuperación a R. Y conserva la evidencia que sostiene la decisión previa a la edición. En español, usa las cinco partes como estructura principal; las letras son una ayuda de memoria, no una segunda lista rival.

En este flujo, define la línea base con un identificador de commit u otra referencia estable aprobada por el repositorio. Registra evidencia de que la prueba relevante de línea base pasa y de que el árbol de trabajo está limpio, o explica cada entrada esperada del estado. Un plan de recuperación debe coincidir con el estado posible del repositorio: las ediciones rastreadas sin confirmar pueden exigir el procedimiento aprobado para descartarlas; las ediciones en staging pueden necesitar quitarse de staging antes de restaurarse; un commit aceptado puede exigir el procedimiento aprobado de revert, que crea un commit inverso; y los archivos no rastreados o generados deben tratarse según la política del repositorio, porque revertir un commit no los elimina. No prescribas un reset destructivo. Anota la acción aprobada que corresponda y exige volver a ejecutar la prueba de línea base después de cualquier recuperación.

El límite solo sirve cuando cada parte es lo bastante concreta para que otra persona —o un agente de IA— pueda actuar y revisar el resultado. Una línea base es más que una copia de archivos o un mensaje de commit. Registra el comportamiento relevante, el estado del proyecto que lo sostiene, la evidencia con la que lo verificaste y el identificador de commit u otra referencia estable que lo conserva.

El riesgo no es una predicción de que el cambio fallará. Es una razón para elegir controles más fuertes. Califica el impacto y la probabilidad por separado como bajo, medio o alto. El impacto describe la consecuencia si el cambio causa un problema; la probabilidad describe cuán plausible es que el alcance o las dependencias propuestas lo provoquen. Usa la dimensión más alta como calificación global por defecto, salvo que documentes otra regla aprobada por el repositorio, y nombra el control añadido por esa calificación. Por ejemplo, un cambio de impacto medio y probabilidad baja es medio en conjunto y necesita comprobaciones lo bastante amplias para cubrir el comportamiento afectado y su dependencia más cercana. Un cambio en un valor de texto aislado puede necesitar comprobaciones más ligeras que otro que afecte código de juego compartido, referencias de escenas, datos de guardado o ajustes del proyecto.

El alcance es un límite, no una sugerencia. Declara tanto el cambio permitido como la expansión prohibida. «Ajustar el valor de enfriamiento de esta habilidad» está acotado. «Mejorar la habilidad» invita a rediseños no solicitados.

2117. Modelo mental

Usa el modelo BOUNDARY antes de solicitar un cambio de proyecto. Trátalo como una ampliación operativa del límite de cinco partes, no como una segunda lista de comprobación independiente. Recuerda que BOUNDARY es un mnemónico inglés:

Las cinco partes ayudan a razonar sobre la decisión de seguridad. Los ocho elementos de BOUNDARY convierten ese razonamiento en evidencia de preparación. No pides a la IA que «lo deje mejor» esperando que la revisión posterior descubra el coste. Defines el límite, verificas la referencia de línea base y el estado del repositorio, y decides si la solicitud está lista para autorizarse. La evidencia de implementación y la decisión final de aceptar, revisar o recuperar pertenecen a la lección siguiente.

2118. Ejemplo concreto

Supón que la tarea acotada es: reducir de 2,0 a 1,5 segundos el enfriamiento de una habilidad de impulso.

Una solicitud débil sería:

Haz que el impulso responda mejor.

No aclara el valor afectado, los sistemas relacionados ni los criterios de aceptación.

Un plan más seguro sería:

• Línea base: El impulso se activa, entra en enfriamiento y vuelve a estar disponible después de 2,0 segundos en la prueba de movimiento existente. Registra el valor actual, una ejecución correcta y un identificador de commit u otra referencia estable aprobada, más evidencia de que el árbol de trabajo está limpio o está completamente explicado.
• Riesgo: El impacto es medio porque un error podría alterar la activación repetida, el uso de recursos, la señal de interfaz o una configuración compartida de habilidades. La probabilidad es media porque el valor puede estar compartido o referenciado fuera de la habilidad visible. La calificación global es, por tanto, media. Controles añadidos: inspeccionar las referencias de configuración pertinentes y planear comprobaciones de activación repetida, coste de recurso, señal de interfaz y una habilidad no relacionada.
• Incluido: Cambiar únicamente el valor de enfriamiento de esta habilidad.
• Excluido: No cambiar la velocidad de movimiento, la duración de invulnerabilidad, el coste de resistencia, el texto de interfaz, otras habilidades ni el manejo de entrada.
• Validación: Confirmar que el impulso sigue activándose, que el enfriamiento medido es de 1,5 segundos, que las activaciones repetidas se bloquean durante el enfriamiento, que el movimiento no relacionado permanece igual y que el diff solo contiene el cambio permitido.
• Plan de recuperación: Registrar el identificador de commit de la línea base u otra referencia estable aprobada y la evidencia de un árbol de trabajo limpio. Si más adelante hay que abandonar el trabajo, elegir la acción aprobada por el repositorio según el estado real: descartar ediciones rastreadas sin confirmar, quitar de staging y restaurar ediciones en staging, revertir un commit aceptado con un commit inverso, y tratar archivos no rastreados o generados según la política del repositorio. Después de recuperarse, volver a ejecutar la prueba de línea base.

El ejemplo no demuestra que 1,5 segundos sea una buena decisión de diseño. Demuestra cómo convertir la decisión en algo comprobable, revisable y reversible.

2119. Flujo de trabajo nativo de IA

Usa la IA para aclarar el plan sin permitirle modificar el proyecto en esta lección:

1. Prepara tú el límite. Escribe la línea base verificada, las calificaciones separadas de impacto y probabilidad, el riesgo global, el control añadido, el alcance, los no objetivos, las comprobaciones previstas, los criterios de interrupción y los escenarios de recuperación.
2. Verifica la referencia de línea base. Ejecuta la prueba relevante, registra un identificador de commit u otra referencia estable aprobada, y captura evidencia de que el árbol de trabajo está limpio o de que cada entrada esperada del estado se comprende.
3. Proporciona solo el contexto relevante. Incluye la tarea, la ubicación afectada, las restricciones conocidas, la referencia de línea base, la evidencia del estado del repositorio y el resultado de la prueba. No concedas permiso general para rediseñar.
4. Pide a la IA que reformule el límite. Exige que enumere los archivos o sistemas propuestos, las suposiciones, los riesgos, las comprobaciones y las ambigüedades sin editar ningún archivo.
5. Compara su reformulación con tu plan. Rechaza el alcance inventado, las suposiciones sin respaldo, los controles ausentes o una propuesta de recuperación que no contemple los estados rastreado, en staging, confirmado, no rastreado y generado.
6. Toma la decisión previa a la edición. Registra listo para autorizar solo si el límite está completo, la referencia de línea base está verificada, las comprobaciones propuestas coinciden con el riesgo y el plan de recuperación es adecuado al estado. En caso contrario, registra no listo e identifica qué debe corregirse.

Detente aquí. En 5.5 L2 — Inspeccionar, validar y recuperar implementarás o inspeccionarás el cambio, examinarás su diff, ejecutarás las comprobaciones, elegirás aceptar, revisar o recuperar, aplicarás una acción de recuperación aprobada si hace falta y verificarás la restauración volviendo a ejecutar la prueba de línea base. La responsabilidad humana cubre tanto la autorización previa a la edición como el resultado posterior basado en evidencia.

2120. Error común

El error común es tratar una copia de seguridad, un «checkpoint» sin nombre o cualquier commit como si fuera el plan completo de seguridad. Una línea base necesita un identificador de commit registrado u otra referencia estable aprobada, una prueba de línea base que pase, y evidencia de un árbol de trabajo limpio o completamente explicado. Otro error es usar revert como sinónimo universal de deshacer. Las ediciones rastreadas sin confirmar, las ediciones en staging, los commits aceptados y los archivos no rastreados o generados exigen un trato distinto, aprobado por el repositorio. Planifica los estados pertinentes, usa criterios de interrupción observables, evita prescribir un reset destructivo y exige que la prueba de línea base vuelva a pasar después de recuperarse.

2121. Práctica guiada

Elabora un plan de seguridad para esta tarea acotada:

Cambia el texto que aparece cuando el jugador no tiene suficiente moneda para usar un objeto. El mensaje debe ser más claro. No cambies el cálculo de moneda, el coste del objeto, el resultado de la compra ni otros mensajes.

Completa estos pasos:

1. Escribe una afirmación de línea base verificada. Incluye el mensaje actual, el comportamiento que debe continuar funcionando y el resultado de la prueba de línea base.
2. Califica el impacto y la probabilidad por separado como bajo, medio o alto. Obtén la calificación global usando la dimensión más alta, o justifica otra regla aprobada por el repositorio.
3. Nombra al menos un sistema que podría verse afectado por accidente y un control añadido por la calificación global.
4. Define el cambio incluido en una sola oración.
5. Enumera al menos tres no objetivos.
6. Escribe tres comprobaciones previstas de aprobado o fallido, incluida una que proteja el comportamiento no relacionado. Explica por qué su amplitud coincide con la calificación de riesgo.
7. Declara el resultado exacto de alcance o validación que exigiría detener el trabajo.
8. Registra el identificador de commit u otra referencia estable aprobada de la línea base verificada. Incluye evidencia de que el árbol de trabajo está limpio o explica cada entrada esperada del estado.
9. Planifica la recuperación para cada estado pertinente: ediciones rastreadas sin confirmar, ediciones en staging, un commit aceptado y archivos no rastreados o generados. Remite a acciones aprobadas por el repositorio, evita instrucciones de reset destructivo y exige volver a ejecutar la prueba de línea base después de recuperarse.
10. Redacta una solicitud breve para la IA que incluya el límite y la referencia de línea base, y le pida reformular el plan sin editar.
11. Registra una decisión previa a la edición de listo para autorizar o no listo, apoyada en la evidencia de línea base, los controles de riesgo, el alcance, las comprobaciones, los criterios de interrupción y el plan de recuperación.

Hay dos decisiones obligatorias: determinar el riesgo global a partir del impacto y la probabilidad, y decidir si la solicitud está lista para autorizarse. Defiende ambas conectando el riesgo identificado con la amplitud de las comprobaciones y de los controles de recuperación previstos.

2122. Validación / evidencia

2123. Ideas clave

• Las cinco partes dan estructura a la decisión de seguridad; BOUNDARY, un mnemónico inglés, las amplía a ocho elementos de preparación.
• Un cambio seguro comienza con una prueba de línea base que pasa, un identificador de commit o referencia estable aprobada, y un árbol de trabajo limpio o completamente explicado.
• Califica el impacto y la probabilidad por separado, obtén el riesgo global y añade controles cuya amplitud coincida con esa calificación.
• El alcance debe incluir no objetivos explícitos para evitar rediseños accidentales.
• La planificación de la recuperación debe distinguir estados no confirmados, en staging, confirmados, no rastreados y generados, y debe exigir volver a ejecutar la prueba de línea base.
• Esta lección termina con una decisión justificada de seguir o no antes de editar; la implementación, la inspección del diff, la validación y la ejecución de la recuperación pertenecen a la lección siguiente.

2124. Próxima lección

Continúa con 5.5 L2 — Inspeccionar, validar y recuperar.

2125. Comprobación