Guía de "Business Rule Change"

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 — sin necesidad de saber programar.

Nombre funcional: "Cambio de regla de negocio". Se usa cuando una regla que ya estaba documentada y probada cambia intencionalmente (no es un bug, es una decisión de negocio) y hace falta actualizar solo lo que ese cambio afecta.

1. Conceptos clave antes de arrancar

1.1 — Playbook y Skill

¡Qué es un Playbook?

Es por ejemplo la checklist que sigue un piloto antes de despegar: no improvisa cada vez, sigue una secuencia probada de pasos. Un playbook es esa misma idea aplicada a probar una aplicación: una receta escrita que le indica al modelo de IA, paso a paso, qué hacer usando diferentes elementos/herramientas llamadas "Skills".

¿Qué es una "Skill"?

Una skill es la herramienta puntual que ejecuta cada paso del playbook. Interactúa con el playbook — el asistente se encarga de usar la herramienta correcta en cada momento.

1.2 — Regla de negocio y "base de prueba"

Una regla de negocio es una condición que la aplicación tiene que cumplir sí o sí porque así lo decidió el negocio (negocio = area que solicita el requerimiento a crear ) — no es una preferencia de diseño, es una norma. Ejemplos: "la contraseña debe tener mínimo 8 caracteres", "una transferencia de más de $50.000 pide un segundo factor de autenticación", "en roaming, los primeros 500MB son gratis".

El documento (o conjunto de documentos) donde esa regla queda escrita es una historia de usuario, en terminología de testing, base de prueba: es el material contra el que se decide si la aplicación está bien o mal, es el material con el que el tester/QA usara como base de su analisis apra generara todos los casos de prueba que luego ejecutara (si no tuviera un agente). Cuando la regla cambia, lo primero que cambia es la base de prueba (se actualiza la historia y por ende los casos de prueba)..

1.3 — Historia de usuario y criterio de aceptación (AC)

Una historia de usuario describe una funcionalidad desde el punto de vista de quien la usa, sin entrar en detalles técnicos de cómo está construida. Dentro de una historia hay varias reglas puntuales: cada una de esas reglas es un criterio de aceptación (AC) — pensalo como una línea suelta de una lista de inspección de un auto ("el freno de mano sostiene en pendiente"). Cuando una regla de negocio cambia, en general lo que cambia puntualmente es uno o varios AC de la historia: se agregan, se reescriben o se eliminan.

1.4 — Caso de prueba (Test Case)

Un caso de prueba es una prueba puntual y concreta: tiene pasos de entrada, una condición de partida, y un resultado esperado — está pensada para comprobar una sola cosa, por lo general un solo criterio de aceptación. Es como una única pregunta de examen: no evalúa toda la materia, evalúa un punto puntual del programa.

Cuando una regla cambia, los casos de prueba que validaban la regla vieja quedan desactualizados — no porque estén mal escritos, sino porque preguntan por algo que ya no es la norma vigente por lo que siempre debeeran atualizarse.

1.5 — Prueba de regresión (Regression Testing)

Una prueba de regresión es volver a correr las pruebas que ya existían, después de un cambio, para confirmar que ese cambio no rompió nada de lo que ya andaba bien (casos de pruebas anteriores, ya existente, no relacionados con esta user story actual). Es como cuando el mecánico, después de arreglarte los frenos, también prueba las luces y la dirección — no porque sospeche de ellas, sino para confirmar que tocar una parte del auto no desacomodó otra.

Este playbook corre una regresión del módulo completo (no solo de los casos que tocan la regla que cambió), porque un cambio de regla puede tener efectos en flujos vecinos del mismo módulo que a simple vista no parecen relacionados. No corre la aplicación entera — el alcance queda acotado al módulo de la historia de usuario que cambió.

1.6 — Mantenimiento y retiro de casos de prueba (archivado)

El mantenimiento de pruebas es la tarea de mantener al día los casos de prueba existentes a medida que la aplicación (o la regla que describen) cambia — para que sigan detectando problemas reales y no queden hablando de un comportamiento que ya no existe.

Parte de ese mantenimiento es el retiro de casos de prueba que quedaron obsoletos: cuando un caso ya no corresponde a ninguna regla vigente, se archiva — se lo mueve a una carpeta aparte con la razón por la que quedó fuera de vigencia — pero no se borra. Guardarlo (en vez de borrarlo) preserva la trazabilidad: en el futuro, cualquiera puede abrir ese archivo y entender qué regla validaba y por qué dejó de aplicar, en vez de encontrarse con un vacío sin explicación.

1.7 — Reparación automática de pruebas ("self-healing")

Detecta cuándo un caso de prueba falló por un motivo menor y esperable (por ejemplo, el resultado correcto cambió de valor porque la regla cambió) y ajustarlo a solas, sin que una persona tenga que reescribir el código de la prueba a mano. A esta capacidad se la llama reparación automática o "self-healing".

Es una ayuda real — ahorra horas de trabajo manual — pero no es infalible: por eso este playbook incluye un control humano específico para revisar lo que la reparación automática decidió (ver 1.9).

1.8 — Falso negativo (y por qué "todo en verde" no siempre alcanza en los reportes)

Un falso negativo es cuando una prueba da por buena una situación que en realidad está mal: la prueba "pasa" (queda en verde), pero no porque la aplicación esté correcta, sino porque la prueba dejó de exigir lo que debía exigir. Es como un detector de humo al que le sacaron la pila: no suena, pero no porque no haya humo — no suena porque no puede detectar nada.

Este es el riesgo concreto de la reparación automática (1.7): si ajusta una prueba para que pase, pero el valor nuevo que acepta no coincide con lo que en verdad pide la regla actualizada, la suite completa queda en verde tapando un problema real. Por eso, en este playbook, cada ajuste automático se revisa a mano antes de darlo por bueno.

1.9 — Supervisión humana (por qué hay pasos que no se delegan)

No toda decisión de este proceso conviene dejarla en manos del asistente. Decidir qué caso de prueba archivar (¿es realmente obsoleto, o todavía sirve para otra cosa?) y validar que un ajuste automático es correcto (¿el nuevo valor realmente coincide con la regla nueva?) son juicios que requieren criterio de negocio — contexto que el asistente no siempre tiene completo. Por eso este playbook tiene dos puntos de control marcados como manuales, en los que el trabajo se detiene hasta que una persona confirma antes de seguir.

2. ¿Qué hace el playbook "Business Rule Change"?

Es el playbook que usás cuando una regla de negocio que ya estaba documentada y probada cambió — a propósito, por una decisión del negocio — y la historia de usuario ya se actualizó para reflejar ese cambio.

En vez de rehacer todo el plan de pruebas del módulo desde cero, este playbook:

Detecta exactamente qué cambió comparando la historia actualizada contra el plan de pruebas anterior (el "antes" contra el "después").
Regenera solo los casos de prueba de las reglas nuevas o modificadas — deja intactos los que no se tocaron.
Archiva (no borra) los casos de prueba que la nueva regla dejó sin sentido, con la razón documentada.
Corre la suite completa del módulo para confirmar que el cambio de regla no generó efectos colaterales en otras partes.
Entrega un reporte que deja asentado, en un solo documento: qué regla cambió (antes → después), qué casos se archivaron y por qué, y qué quedó cubierto.

3. ¿Cuándo tengo que usar este playbook (y cuándo no)?

Situación	¿Este playbook?
Una regla de negocio cambió intencionalmente y la historia ya está actualizada	✅ Sí
Un criterio de aceptación fue reescrito, agregado o eliminado	✅ Sí
Necesitás actualizar solo los casos de prueba afectados, sin rehacer el módulo entero	✅ Sí
Necesitás que quede registro de qué casos quedaron obsoletos y por qué, sin perderlos	✅ Sí
Lo que cambió es un comportamiento no intencional (algo se rompió solo)	❌ No — es un bug: usá el playbook "Bug Reproduction" o "Bug Fix Cycle"
El código se refactorizó pero la regla de negocio sigue siendo la misma	❌ No — usá el playbook "Regression on Module"
El módulo todavía no tiene ningún plan ni suite de pruebas	❌ No — usá primero "New Project Bootstrap"

¡IMPORTANTE!

Este playbook no arranca de cero: necesita que ya exista un plan de pruebas anterior y una suite previa del módulo. Si no existen, no hay nada contra qué comparar el cambio.
La decisión de qué casos de prueba archivar y la de validar los ajustes automáticos son manuales — el asistente prepara la información, pero la confirmación final la das vos (ver 1.9).

4. Ejemplos reales de negocio

E-commerce — TechStore refuerza la seguridad de las contraseñas


Regla anterior	La contraseña debía tener un mínimo de 8 caracteres.
Regla nueva	La contraseña debe tener mínimo 12 caracteres, con al menos una mayúscula, un número y un símbolo.
Por qué cambió	Una decisión de seguridad del área de producto, tras una auditoría.
Qué hace el playbook	Archiva los casos que probaban el límite de 8 caracteres, genera casos nuevos para los 12 caracteres y los tres requisitos agregados, y confirma que el resto del formulario de registro sigue funcionando igual.

Telecomunicaciones — límite de datos gratis en roaming


Regla anterior	Los primeros 500MB de datos en roaming eran gratuitos.
Regla nueva	El límite gratuito sube a 1GB, y a partir de ahí se cobra por MB adicional.
Por qué cambió	Una nueva promoción comercial vigente desde el mes siguiente.
Qué hace el playbook	Archiva los casos que validaban el corte en 500MB, genera casos nuevos para el corte en 1GB (incluyendo el borde exacto: 999MB, 1000MB, 1001MB), y corre la regresión del módulo de consumo para confirmar que el cobro por excedente sigue funcionando bien.

Banca — monto máximo de transferencia sin doble factor


Regla anterior	Las transferencias de hasta $50.000 no pedían un segundo factor de autenticación.
Regla nueva	El monto libre de segundo factor baja a $20.000, por una nueva política de prevención de fraude.
Por qué cambió	Una decisión de riesgo del área de seguridad del banco.
Qué hace el playbook	Archiva los casos que probaban el límite de $50.000, genera casos nuevos para el límite de $20.000 (incluyendo transferencias de exactamente $19.999, $20.000 y $20.001), y valida que las transferencias por debajo del nuevo límite y por encima sigan comportándose como corresponde.

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

Dato	Ejemplo (TechStore)
Qué regla cambió, en palabras simples, antes y después	"La contraseña pasó de pedir mínimo 8 caracteres a pedir mínimo 12, con mayúscula, número y símbolo"
La historia de usuario ya actualizada, con los criterios de aceptación nuevos	`user-stories/TS-US-14.md`
Dónde está el plan de pruebas anterior de ese módulo	`specs/TS-US-14-test-plan.md`
Dónde está la suite de pruebas anterior de ese módulo	`tests/TS-US-14/`
Un identificador de la historia (US-ID)	`TS-US-14`
El proyecto ya inicializado para trabajar con el asistente de QA (existe una configuración base del stack)	Si el proyecto todavía no la tiene, hay que correr antes el playbook "New Project Bootstrap"
(Recomendado, no obligatorio) Los hallazgos de una exploración anterior de ese módulo	Si existen, el asistente los reutiliza para no tener que volver a explorar la pantalla; si la regla nueva agregó o movió elementos en pantalla, va a hacer falta una exploración puntual de todos modos (ver sección 9)
Alguien que pueda confirmar qué casos de prueba archivar y validar los ajustes automáticos	El referente de QA o de producto del módulo afectado

Si no tenés alguno de estos datos a mano (por ejemplo, no sabés la ruta exacta del plan anterior), no pasa nada — se lo podés preguntar al asistente y él te ayuda a ubicarlo.

6. Cómo arrancar

Antes del Paso 1, contale al asistente qué regla cambió y dónde está la historia actualizada:

Reglas de negocio cambiaron en user-stories/TS-US-14.md.
Qué regla cambió: la contraseña pasó de mínimo 8 caracteres a mínimo 12,
con mayúscula, número y símbolo.
El plan y la suite previos del módulo ya están en specs/ y tests/TS-US-14/.
No ejecutes nada todavía, solo guardá este contexto.

Con ese contexto, el asistente ya puede recorrer todos los pasos siguientes sin que se lo tengas que repetir cada vez.

7. Paso a paso

Paso 1 — "Releer la historia y detectar qué cambió"

Qué pasa: el asistente relee la historia actualizada, extrae los criterios de aceptación vigentes, y los compara contra el plan de pruebas anterior. A cada criterio le asigna una etiqueta:

Etiqueta	Qué significa
Nuevo	No existía antes — hay que generar casos de prueba desde cero
Modificado	Ya existía, pero la regla cambió — hay que regenerar los casos que lo cubrían
Sin cambios	Sigue igual — no se toca
Eliminado / superado	La nueva regla lo dejó sin sentido — candidato a archivar

Qué te queda al final de este paso: una lista clara de qué cambió y qué no. Con TechStore, por ejemplo: "el criterio de mínimo 8 caracteres queda ELIMINADO, y se agregan cuatro criterios NUEVOS: mínimo 12 caracteres, mayúscula obligatoria, número obligatorio y símbolo obligatorio".

Checkpoint: tenés la lista de criterios etiquetados y, para cada uno, qué archivos de prueba lo cubren hoy. Sin esta lista, el archivado del Paso 3 sería a ciegas.

Paso 2 — "Regenerar el plan de los flujos afectados"

Qué pasa: con la lista del Paso 1, el asistente reescribe el plan de pruebas: agrega escenarios para los criterios nuevos y modificados, deja intactos los escenarios de los criterios que no cambiaron, y saca del plan los escenarios de los criterios eliminados.

Con TechStore, esto significa que el plan queda con escenarios nuevos para "contraseña de 11 caracteres" (debe rechazarse), "contraseña de 12 caracteres exactos" (debe aceptarse), "contraseña sin mayúscula", "sin número" y "sin símbolo" — y sin ningún escenario que hable del viejo límite de 8.

Checkpoint: el plan regenerado tiene al menos un escenario por cada criterio nuevo y modificado, cubre los casos límite de la regla nueva (por ejemplo, justo en el número exacto que separa "válido" de "inválido"), y ya no menciona los escenarios del criterio eliminado.

🔴 Checkpoint humano — "Decidir qué se archiva" (pausa, no delegable)

Qué pasa: el asistente te entrega una lista de candidatos a archivar — los casos de prueba que cubrían un criterio eliminado o superado — con la razón de cada uno. Esta decisión no la toma el asistente solo: para cada candidato, alguien del equipo confirma una de estas tres opciones:

Decisión	Qué significa
Archivar	El caso valida una regla que ya no existe → se archiva, con su razón
Conservar	El caso sigue siendo válido para otra cosa que la nueva regla no tocó → no se toca
Regenerar	Es del mismo flujo, pero la regla nueva cambió lo que se espera → lo cubre el Paso 3, no se archiva

Con TechStore, el caso que probaba "contraseña de 8 caracteres es válida" se archiva — esa regla ya no existe —, mientras que un caso que probara, por ejemplo, "el campo contraseña no puede quedar vacío" se conserva, porque esa regla no cambió.

Por qué es manual: distinguir "esto ya no sirve para nada" de "esto todavía sirve, aunque de otra forma" requiere conocer el negocio — no es algo que se pueda automatizar de forma confiable (ver 1.9).

Paso 3 — "Archivar lo obsoleto y regenerar la suite"

Qué pasa: con la decisión del checkpoint anterior ya tomada, el asistente:

Mueve (no borra) los casos marcados como "archivar" a una carpeta aparte, dejando escrita la razón directamente en el archivo movido.
Genera los casos de prueba nuevos y regenerados según el plan del Paso 2.

Con TechStore: el caso viejo de "8 caracteres" queda guardado en una carpeta de archivo, con una nota que dice cuándo y por qué se dejó de usar — y se crean los casos nuevos para los 12 caracteres y los tres requisitos agregados.

Checkpoint: los archivos archivados están efectivamente fuera de la ejecución normal (no se van a correr por error), y los casos nuevos corresponden exactamente a los criterios nuevos y modificados del Paso 1.

Paso 4 — "Ejecutar y reparar la suite completa del módulo"

Qué pasa: el asistente corre todos los casos de prueba del módulo (no solo los nuevos), porque un cambio de regla puede afectar flujos vecinos que a primera vista no parecen relacionados. Si algún caso falla por un motivo esperado — por ejemplo, un caso que comparaba contra el valor viejo de la regla —, el asistente intenta repararlo automáticamente (ver 1.7), ajustando el resultado esperado al valor que dicta la regla nueva.

Qué te queda al final de este paso: cuántos casos pasaron y cuántos fallaron antes de la reparación, cuántos quedaron reparados y con qué valor nuevo, y el estado final de la suite.

🔴 Checkpoint humano — "Validar los ajustes automáticos" (pausa, no delegable)

Qué pasa: antes de dar la suite por buena, alguien del equipo revisa, uno por uno, cada ajuste que hizo la reparación automática del Paso 4. Para cada ajuste, la pregunta es siempre la misma:

Pregunta	Si la respuesta es "no"
¿El valor nuevo coincide con lo que pide la regla actualizada?	Es un falso negativo (ver 1.8) — hay que revertir el ajuste y reportarlo como un problema real
¿El caso sigue probando lo mismo que decía probar?	El ajuste automático se desvió — hay que corregirlo a mano

Por qué importa: "todo en verde" no alcanza si algún ajuste quedó mal hecho — sería un falso negativo tapando un problema real (ver 1.8). Este control es la razón por la que el proceso completo no queda 100% automatizado.

Paso 5 — "Reporte: cambio de regla + impacto en cobertura"

Qué pasa: el asistente arma un único reporte que deja asentado, en el mismo documento:

La regla que cambió, expresada como "antes" y "después".
Los casos de prueba que se archivaron, con su razón y su nueva ubicación.
Los ajustes automáticos que se hicieron durante la reparación, ya validados en el checkpoint anterior.
El resultado final de la regresión completa del módulo.

Qué te queda al final de este paso: un documento único, con fecha y hora, que sirve como evidencia formal de que el cambio de regla quedó cubierto y de que nada más se rompió en el proceso — ideal para adjuntar al ticket o mostrarle a un stakeholder.

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

Qué obtenés	Para qué te sirve
El plan de pruebas actualizado, con la regla nueva reflejada	Documenta, de una vez, cuál es la regla vigente hoy
Los casos de prueba nuevos y regenerados	Cubren exactamente la regla actualizada, con sus bordes incluidos
Los casos obsoletos archivados (no borrados), con su razón	Trazabilidad completa de qué se probaba antes y por qué se dejó de probar
Confirmación de que el resto del módulo sigue funcionando	El cambio de regla no generó efectos colaterales
Un reporte único con el "antes" y el "después"	Evidencia formal para cerrar el ticket o informar al equipo

9. Problemas comunes (y qué hacer)

Lo que ves	Por qué puede pasar	Qué hacer
Un caso de la regla vieja sigue corriendo y fallando	Quedó archivado, pero no se lo excluyó de la ejecución normal	Confirmar con el equipo técnico que el archivo quedó fuera del grupo de pruebas que se ejecuta
La suite queda toda en verde, pero la regla nueva no parece bien cubierta	La reparación automática ajustó un caso a un valor que no coincide con la regla nueva (falso negativo, ver 1.8)	Revisar ese ajuste puntual en el checkpoint post-reparación, revertirlo y regenerar el caso correctamente
Al generar la suite, algunos casos quedan marcados como pendientes	La regla nueva movió o agregó elementos en la pantalla que todavía no se exploraron	Explorar primero esa pantalla (playbook "Bug Reproduction" o el paso de exploración correspondiente) y volver a generar
Tras varios intentos de reparación, algo sigue sin pasar	Puede ser una regresión real, no solo un ajuste esperado	Leer el detalle del motivo antes de forzar que quede en verde — puede haber un problema genuino
No se detecta ningún criterio eliminado	El plan anterior no está disponible o está desactualizado	Recuperar el plan anterior antes de arrancar, o reconstruir a mano qué cambió

10. Resumen visual del flujo

Regla de negocio cambió (ej: TechStore sube el requisito de contraseña)
            │
            ▼
Paso 1 — Releer la historia y detectar qué cambió   → criterios etiquetados (nuevo/modificado/sin cambios/eliminado)
            │
            ▼
Paso 2 — Regenerar el plan de los flujos afectados  → plan actualizado
            │
            ▼
🔴 Checkpoint humano — decidir qué se archiva        [MANUAL]
            │
            ▼
Paso 3 — Archivar lo obsoleto + regenerar la suite  → casos nuevos + casos archivados (con razón)
            │
            ▼
Paso 4 — Ejecutar y reparar la suite completa       → resultado + ajustes automáticos
            │
            ▼
🔴 Checkpoint humano — validar los ajustes           [MANUAL]
            │
            ▼
Paso 5 — Reporte: cambio de regla + impacto          → documento único, antes/después
            │
            ▼
Regla nueva cubierta, obsoletos archivados con trazabilidad