Guía de "Hotfix Fast Track"

Esta guía está pensada para entender qué hace el asistente de IA cuando ejecuta este playbook. La idea es que puedas leerla, entender qué pasa en cada paso, y saber qué información tenés que darle al asistente para que el trabajo salga bien.

1. ¿Qué es un "playbook"?

Pensalo como una receta de cocina para el asistente de IA. Vos le decís "quiero hacer esto" (por ejemplo, "quiero validar este arreglo urgente antes de liberarlo") y el playbook es la receta que el asistente sigue paso a paso, en orden, sin saltarse nada, para que el resultado sea siempre el mismo sin importar quién lo pida.

Cada paso de la receta usa una herramienta puntual (en la jerga técnica se las llama "skills"), algo así como un utensilio de cocina: uno sirve para pelar, otro para cortar, otro para hornear. Vos no necesitás saber cómo funciona cada utensilio por dentro — solo necesitás saber qué ingrediente hay que poner en cada paso (por ejemplo, qué se corrigió, o en qué URL está desplegado el arreglo) para que el plato final salga bien.

En resumen: un playbook = una guía ordenada de pasos. Una skill = la herramienta puntual que ejecuta cada paso. Interactuás con el playbook — el asistente se encarga de usar la herramienta correcta en cada momento.

2. ¿Qué hace el playbook "Hotfix Fast Track"?

Es el playbook que usás cuando ya existe un arreglo urgente aplicado (un "hotfix") y necesitás confirmar en minutos, no en horas, si es seguro liberarlo a producción.

Es importante entender la diferencia con otros playbooks: acá el arreglo ya está hecho. El foco no es acompañar al developer a corregir el bug (para eso existe el playbook "Bug Fix Cycle") — el foco es validar rápido que ese arreglo funciona y que no rompió nada crítico, para poder decidir en el momento: ¿se libera o no se libera?

Para lograr esa velocidad, este playbook no revisa toda la aplicación de punta a punta. En cambio:

Corre únicamente un conjunto mínimo de pruebas críticas ya existente (la "smoke" — las pruebas de las funciones más importantes de ese módulo, como quien revisa solo los frenos y las luces de un auto antes de salir a la ruta, no el auto entero).
Actúa como un semáforo automático: si esas pruebas críticas pasan, da luz verde para avanzar; si alguna falla, frena todo de inmediato.
Si dio luz verde, deja guardada una prueba automática puntual que en el futuro va a vigilar que ese arreglo específico no se rompa de nuevo.
Escribe un reporte breve (pensado para leerse en un minuto, no una página larga) con el resultado y la fecha exacta, para que quede registro de que el hotfix fue validado antes de salir.

Al terminar, el hotfix queda con:

Un veredicto claro: aprobado para liberar o freno total con el motivo documentado.
Una prueba automática nueva que protege ese arreglo puntual hacia el futuro (si el tiempo lo permitió).
Un reporte mínimo con fecha y hora, que sirve como respaldo de que el hotfix no se liberó "a ciegas".

3. ¿Cuándo tengo que usar este playbook?

Usalo cuando estés frente a alguna de estas situaciones:

Situación	Ejemplo de negocio
Hay un arreglo urgente ya aplicado y hace falta subirlo a producción cuanto antes	Un cliente de TechStore descubre un viernes a la tarde que, al aplicar un cupón de descuento válido en el checkout, el total no se recalcula — el cliente termina pagando de más. Un developer ya aplicó el arreglo y está esperando el OK para liberarlo.
No hay tiempo para un ciclo completo de prueba (reproducir, escribir prueba en rojo, esperar el fix, verificar en verde)	El equipo de TechStore necesita liberar el arreglo del checkout antes de que arranque el pico de tráfico del viernes a la noche — no hay margen para un ciclo largo.
Se necesita un "semáforo" automático antes de aprobar el release	El líder de QA de TechStore no quiere aprobar el release del hotfix "de palabra" — quiere que un conjunto mínimo de pruebas críticas confirme que nada esencial se rompió.
El ticket o la rama ya están marcados como hotfix	El developer subió el arreglo a una rama llamada `hotfix/checkout-discount` o el ticket tiene la etiqueta `hotfix`.

¡IMPORTANTE!

Este playbook necesita que ya exista un conjunto mínimo de pruebas críticas ("smoke") para el módulo afectado. Si no existe ninguna, el playbook se detiene de inmediato y no continúa — primero hay que crear al menos una prueba crítica para ese módulo. Esto es no negociable: sin esa red de seguridad mínima, no se puede garantizar que el hotfix sea seguro.
Este playbook asume que el arreglo ya está aplicado y desplegado. Si el bug todavía no fue corregido, no es este playbook — es el playbook "Bug Fix Cycle", que sí acompaña todo el proceso de corregirlo.
Es un playbook pensado para la urgencia: prioriza velocidad por sobre cobertura exhaustiva. No reemplaza una regresión completa cuando sí hay tiempo disponible.
Si el proyecto todavía no tiene la configuración básica de QA automatizado (el archivo qa-stack.yaml), primero hay que correr el playbook "New Project Bootstrap".

4. Ejemplo guía: "TechStore", una tienda online con carrito de compras

Vamos a seguir el mismo caso de negocio que en la guía de "New Project Bootstrap": TechStore, una tienda online de electrónica con carrito de compras.

Es viernes a las 17hs. Un cliente reporta lo siguiente:

"Aplico el cupón DESC10 en el checkout, la web me dice que el cupón es válido, pero el total a pagar no cambia — termino pagando el precio completo."

El equipo confirma el bug: la regla de negocio dice "al aplicar un cupón válido, el total debe recalcularse con el descuento aplicado", y hoy eso no está pasando. Es un bug crítico porque afecta directamente los cobros. Un developer ya identificó el problema y subió el arreglo a la rama hotfix/checkout-discount, desplegado en staging. El equipo necesita confirmar en minutos si es seguro liberarlo antes de que arranque el pico de tráfico del viernes a la noche.

Ese es exactamente el escenario para el que se usa este playbook.

5. Antes de arrancar: lo que necesitás tener a mano

No hace falta saber programar, pero sí tener a mano estos datos:

Dato	Ejemplo con TechStore
Identificador del hotfix o ticket	`HOTFIX-17`
Módulo o historia afectada	Checkout / aplicación de cupones de descuento
Qué fue corregido, en palabras simples	"El total del checkout no se recalculaba al aplicar un cupón de descuento válido"
Qué regla de negocio cubre el arreglo	"Al aplicar un cupón válido, el total debe recalcularse con el descuento aplicado"
En qué ambiente está desplegado el arreglo	`https://techstore-staging.com`, rama `hotfix/checkout-discount`
Confirmar que existe un conjunto mínimo de pruebas críticas para el módulo de checkout	Si TechStore nunca armó pruebas críticas para el checkout, hay que crear al menos una antes de seguir

Si no tenés certeza sobre el último punto (si existen o no pruebas críticas para ese módulo), no pasa nada — el propio playbook lo va a chequear en el primer paso y te va a avisar si falta.

6. Cómo arrancar

Antes del Paso 1, contale al asistente el hotfix en cuestión, con la mayor cantidad de detalle posible:

Quiero validar el siguiente hotfix antes del release:
- ID del hotfix: HOTFIX-17
- Módulo afectado: checkout / cupones de descuento
- Qué fue corregido: el total no se recalculaba al aplicar un cupón válido
- Regla que cubre: "al aplicar un cupón válido, el total debe recalcularse
  con el descuento aplicado"
- La app está en https://techstore-staging.com, rama hotfix/checkout-discount

No ejecutes ningún comando todavía, solo guardá esta información como contexto.

La última línea es útil para pedirle al asistente que espere tu confirmación antes de empezar a correr pruebas — así podés revisar los datos antes de arrancar.

7. Paso a paso

Paso 0 — "¿Existe una red de seguridad mínima?" (pre-chequeo)

Qué pasa: antes de tocar nada, el asistente revisa si el módulo afectado ya tiene un conjunto mínimo de pruebas críticas guardado (la "smoke"). Es como preguntar "¿esta ruta ya tiene barandas de seguridad?" antes de circular rápido por ella.

Resultado	Qué significa	Qué se hace
Sí existen pruebas críticas para el módulo	Hay una red de seguridad mínima	Se avanza al Paso 1
No existen pruebas críticas para el módulo	No hay forma de garantizar que el hotfix sea seguro	El playbook se detiene acá mismo — hay que crear al menos una prueba crítica para ese módulo antes de continuar

Este chequeo no es opcional. Es la razón por la que este playbook puede ser tan rápido en los pasos siguientes: confía en que ya existe una base mínima de pruebas confiables.

Paso 1 — "Semáforo rápido: correr las pruebas críticas"

Qué pasa: el asistente corre únicamente las pruebas críticas ya existentes del módulo afectado — no toda la aplicación, solo lo esencial. Actúa como un semáforo: no intenta "arreglar" nada si algo falla, solo informa el resultado tal cual es.

Con TechStore, esto significa correr las pruebas críticas del módulo de checkout (por ejemplo: "el cliente puede completar una compra", "el total se calcula correctamente", "los cupones válidos se aplican") y ver si todas siguen funcionando con el arreglo ya aplicado.

Checkpoint 1 — Semáforo de release:

Resultado	Semáforo	Qué se hace
Todas las pruebas críticas pasan	🟢 Verde	Se avanza al Paso 2
Alguna prueba crítica falla	🔴 Rojo	Freno total. No se avanza a los Pasos 2 y 3 tal como estaban planeados — se va directo a armar el reporte (Paso 3) documentando el bloqueo, y el hotfix no se libera hasta resolverlo

Este es el corazón del playbook: si el semáforo da rojo, no hay vuelta atrás automática — hace falta que el developer revise qué otra cosa se rompió con el hotfix antes de volver a intentar.

Paso 2 — "Dejar una prueba que vigile este arreglo para siempre"

Solo se ejecuta si el Paso 1 dio 🟢 verde.

Qué pasa: el asistente escribe una prueba automática puntual, dedicada específicamente a este arreglo, que confirma que el comportamiento correcto (el cupón se aplica y el total se recalcula) sigue funcionando. A diferencia del playbook "Bug Fix Cycle", acá esta prueba nace directamente en verde — no hace falta verla fallar primero, porque el arreglo ya estaba aplicado desde el principio.

Es como instalar una cámara de seguridad apuntando exactamente al lugar donde antes había un problema: de ahora en más, si ese problema puntual volviera a aparecer, algo lo va a detectar solo.

Qué te queda al final de este paso: un archivo de prueba automática nuevo, guardado en el historial del proyecto, dedicado a este hotfix.

Si la urgencia es tan extrema que no hay ni minutos para este paso, se puede saltar — pero queda registrado en el reporte final como una tarea pendiente, para no perder el rastro de que falta cubrirlo.

Paso 3 — "Reporte exprés"

Qué pasa: el asistente arma un reporte breve — pensado para leerse en un minuto — con el resultado del semáforo, si se generó o no la prueba de vigilancia, y la fecha y hora exacta de la validación.

Qué te queda al final de este paso: un documento corto que responde una sola pregunta clave: ¿este hotfix quedó validado y es seguro liberarlo, o no? Si el semáforo dio rojo, el reporte también deja documentado por qué se frenó.

8. ¿Qué me queda al finalizar todos los pasos?

Qué obtenés	Para qué te sirve
Un veredicto claro de semáforo (verde o rojo)	Saber, en minutos, si el hotfix es seguro para liberar
Una prueba automática que vigila el arreglo puntual (si hubo tiempo)	Protege ese arreglo específico de romperse en el futuro sin que nadie se dé cuenta
Un reporte breve con fecha y hora	Evidencia de que el hotfix no se liberó "a ciegas" — queda registro de la validación
Si el semáforo dio rojo: el motivo documentado	El equipo sabe exactamente qué revisar antes de volver a intentar el release

A partir de acá, el equipo de TechStore puede decidir con información real si sube el arreglo del cupón de descuento antes del pico de tráfico del viernes — y si en algún momento se necesita cobertura más completa sobre ese módulo, se puede complementar después con otro playbook, sin que eso frene la urgencia de hoy.

9. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
El playbook se detiene en el Paso 0 diciendo que no hay pruebas críticas	El módulo afectado nunca tuvo una suite mínima ("smoke") armada	Crear al menos una prueba crítica para ese módulo antes de volver a intentar este playbook
El semáforo del Paso 1 da rojo después de aplicar el hotfix	El arreglo urgente rompió otra funcionalidad importante del mismo módulo	No liberar; coordinar con el developer para revisar qué otro comportamiento se vio afectado
La prueba del Paso 2 pasa, pero el asistente tuvo que "ayudarla" a pasar	Puede haber selectores o datos frágiles en la prueba generada	Revisar el resultado; si el arreglo es de fondo, no debería depender de ajustes automáticos
No hay tiempo ni para el Paso 2	Urgencia extrema	Se puede diferir — queda registrado como pendiente en el reporte final, no se pierde de vista
El proyecto no tiene `qa-stack.yaml`	Nunca se corrió el bootstrap inicial	Correr primero el playbook "New Project Bootstrap"

10. Resumen visual del flujo

Hotfix ya aplicado (ej: TechStore, arreglo del cupón de descuento en checkout)
            │
            ▼
Paso 0 — ¿Existe una red de seguridad mínima (pruebas críticas)?
            │
    ┌───────┴────────┐
    │                │
   NO                SÍ
    │                │
    ▼                ▼
STOP: crear     Paso 1 — Semáforo: correr las pruebas críticas
pruebas antes            │
de continuar     ┌───────┴────────┐
                  │                │
               🔴 Rojo          🟢 Verde
                  │                │
                  ▼                ▼
          Reporte de freno   Paso 2 — Dejar una prueba
          (no se libera)     que vigile este arreglo
                  │                │
                  │                ▼
                  │         Paso 3 — Reporte exprés
                  │                │
                  └────────┬───────┘
                           ▼
              Veredicto final: liberar o no liberar