Épica D — Casos de uso

Estado: Borrador · Última actualización: 2026-08-24 · Índice: README

Cubre el ciclo de vida del caso de uso: el análisis del requerimiento con IA, la generación asistida y la creación manual de casos, la revisión y el congelamiento como línea base inmutable, y el versionado de un caso congelado. Reglas de negocio del bloque: RN-020 a RN-025, RN-037, RN-077, RN-079, más las reglas de IA RN-064 a RN-068. Toda operación de IA media una acción explícita del usuario y ninguna es condición para avanzar: lo que la IA propone, un humano puede crearlo y editarlo a mano.

HU-007 — Analizar un requerimiento con IA

Épica: D · Casos de uso · Deriva de: CU-004 · Cubre: RF-025–RF-028, RF-124, RF-126, RF-127, RF-130 · Reglas: RN-064, RN-066, RN-068 · Decisiones: DEC-056 · Estado: Borrador

Historia

Como QA, quiero lanzar sobre un requerimiento un análisis de IA que extraiga su estructura funcional y saque a la luz lo ambiguo, para tener una base revisada desde la que redactar casos de uso, sin que ninguna imprecisión del texto se pierda.

Objetivo / valor. Convertir un texto en materia prima estructurada —actores, objetivos, restricciones, reglas, supuestos, dependencias, ambigüedades y riesgos— y dejar las ambigüedades como preguntas abiertas con estado propio, no diluidas en la prosa.

Alcance

• Dentro: la solicitud explícita del análisis, la estimación de costo previa y su

confirmación, la ejecución asíncrona como job, la revisión de la propuesta (aceptar, editar, descartar por elemento), el registro de las ambigüedades como preguntas abiertas del requerimiento y el registro del job de IA.

• Fuera: la generación de casos de uso (HU-008), la carga y el versionado del documento

de origen (HU-006), y el diseño del contrato con el proveedor de IA (documentado, no diseñado).

Actores y permisos

Precondiciones

• Existe un requerimiento con al menos un documento de origen.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El usuario abre el requerimiento y solicita explícitamente el análisis —

nunca se dispara solo (RN-064). Si el documento es extenso, el sistema muestra una estimación de costo y pide confirmación (RF-130, DEC-056). Confirmado, el sistema encola un job y devuelve el control: el análisis es asíncrono. Al completarse, presenta la propuesta —actores, objetivos, restricciones, reglas de negocio, supuestos, dependencias, ambigüedades y riesgos funcionales— como propuesta editable, elemento a elemento. El usuario acepta, edita o descarta cada uno. Las ambigüedades aceptadas quedan como preguntas abiertas del requerimiento en estado Abierta. El sistema registra el job con tarea, modelo, tokens de entrada y salida, duración y costo estimado (RF-124).

• Alternativo A1 — Reanalizar. Tras cargar una versión nueva del documento (HU-006), el

usuario relanza el análisis; el análisis anterior se conserva asociado a su versión.

• Alternativo A2 — Resolver una pregunta abierta. El usuario responde una ambigüedad y la

marca Resuelta, dejando la respuesta registrada.

• Error E1 — El proveedor de IA no responde. El sistema reintenta un número **acotado y

visible** de veces (RF-127) y, si falla, informa sin bloquear el requerimiento; el usuario puede seguir creando casos de uso a mano (HU-009).

• Error E2 — Respuesta que no valida. Si el modelo devuelve una estructura inválida, el

sistema descarta la respuesta completa e informa; no persiste resultados parciales (RN-068).

• Error E3 — El usuario cancela ante el costo. El job no se ejecuta y no se registra

consumo.

Datos y campos (funcional, no esquema)

• Entrada: el documento de origen del requerimiento (la versión vigente).
• Propone la IA (editable): actores, objetivos, restricciones, reglas de negocio,

supuestos, dependencias, ambigüedades detectadas, riesgos funcionales.

• Persiste el sistema: elementos aceptados/editados; preguntas abiertas con su estado

(Abierta / Resuelta) y su respuesta; registro del job (tarea, modelo, tokens I/O, duración, costo, usuario, proyecto).

Reglas de negocio aplicables

• RN-064 — ninguna operación de IA se dispara sola; el análisis exige acción explícita.
• RN-066 — toda invocación al proveedor de IA se registra como job con su medición.
• RN-068 — una respuesta que no valida se descarta íntegra; reintentos acotados y

visibles.

Integraciones (documentado, el dev implementa)

• Proveedor de IA (Bedrock) — recibe el contenido del documento y devuelve la propuesta

estructurada. La región, los modelos y una posible restricción de residencia de datos están pendientes en PA-011; el comportamiento se especifica tras una interfaz de proveedor para no quedar amarrado a Bedrock. El costo se estima antes de invocar y el job se mide después.

Eventos que emite. Ninguno de dominio; la invocación queda registrada como job (RF-124).

Criterios de aceptación

• CA-080

> Dado un requerimiento con documento de origen > Cuando el usuario no ha solicitado explícitamente el análisis > Entonces el sistema no ejecuta ninguna operación de IA sobre él.

• CA-081

> Dado un requerimiento cuyo documento es extenso > Cuando el usuario solicita el análisis > Entonces el sistema muestra una estimación de costo y exige confirmación antes de encolar el job.

• CA-082

> Dado un análisis confirmado > Cuando el sistema acepta la solicitud > Entonces encola el job, devuelve el control al usuario y el análisis se procesa de forma asíncrona.

• CA-083

> Dado un job de análisis completado > Cuando el sistema presenta la propuesta > Entonces cada elemento (actores, objetivos, restricciones, reglas, supuestos, dependencias, ambigüedades, riesgos) puede aceptarse, editarse o descartarse por separado.

• CA-084

> Dado que el usuario acepta una ambigüedad detectada > Cuando confirma la revisión > Entonces queda registrada como pregunta abierta del requerimiento en estado Abierta, con estado propio.

• CA-085

> Dado un job de análisis completado > Cuando el sistema lo cierra > Entonces registra tarea, modelo, tokens de entrada y salida, duración y costo estimado, atribuidos al usuario y al proyecto.

• CA-086

> Dado que el proveedor de IA devuelve una estructura inválida o no responde tras los reintentos acotados > Cuando el análisis termina en error > Entonces el sistema descarta cualquier resultado parcial, informa el fallo y no bloquea el requerimiento, que puede seguir con creación manual de casos.

• CA-087

> Dado que el usuario cancela ante la estimación de costo > Cuando rechaza la confirmación > Entonces el job no se ejecuta y no se registra consumo de IA.

Dependencias y bloqueos

• PA-011 (región y modelos de Bedrock) — condiciona el contrato de IA; el comportamiento

local y la degradación no dependen de ella.

• HU-006 (cargar un requerimiento) provee el documento de origen. HU-008 consume el

contexto analizado. HU-026 (orquestación de IA) gobierna jobs, model routing y costos.

Casos borde / notas. El techo de gasto mensual y el umbral de "documento extenso" están en PA-010; mientras no se fijen, avisar antes de gastar es la única contención (DEC-056).

HU-008 — Generar casos de uso con IA

Épica: D · Casos de uso · Deriva de: CU-005 · Cubre: RF-029, RF-031, RF-032, RF-124, RF-126 · Reglas: RN-020, RN-021, RN-064 · Estado: Borrador

Historia

Como QA, quiero generar casos de uso a partir de un requerimiento con la IA, para partir de una propuesta estructurada y revisable en lugar de una hoja en blanco.

Objetivo / valor. Acelerar la redacción sin ceder el control: la IA propone casos completos en Draft, marcados como generados, y una persona decide cuáles se quedan.

Alcance

• Dentro: la solicitud de generación, la ejecución asíncrona como job, la presentación de

los casos propuestos en Draft marcados como IA, la revisión (aceptar parcial, editar, descartar), la trazabilidad al requerimiento y al job, y la emisión del evento.

• Fuera: el análisis previo del requerimiento (HU-007), la revisión y el congelamiento

(HU-010) y el diseño del contrato con el proveedor de IA.

Actores y permisos

Precondiciones

• Existe un requerimiento analizado (HU-007) o, al menos, con documento de origen.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El usuario solicita la generación desde el requerimiento (RN-064). El

sistema encola el job y avisa que el resultado llegará asíncrono. Al completarse, presenta los casos propuestos, cada uno con objetivo, actores, precondiciones, flujo principal, flujos alternativos, flujos de error y postcondiciones. Cada caso queda marcado de forma visible como generado por IA y en estado Draft. El usuario revisa, edita y descarta. El sistema registra en cada caso persistido el requerimiento de origen y el job que lo produjo (RN-021), y emite use_case.generated.

• Alternativo A1 — Generación parcial. El usuario acepta unos casos y descarta otros; solo

los aceptados se persisten.

• Alternativo A2 — Regenerar. El usuario pide una nueva propuesta; los casos ya aceptados

no se ven afectados.

• Error E1 — El proveedor de IA falla. El sistema informa tras los reintentos acotados; el

usuario puede continuar con creación manual (HU-009).

• Error E2 — Propuesta incompleta. Un caso al que le falten campos obligatorios se persiste

en Draft, pero el sistema impide avanzarlo a En revisión hasta completarlo (RN-020).

Datos y campos (funcional)

• Propone la IA (editable, Draft): objetivo, actores, precondiciones, flujo principal,

flujos alternativos, flujos de error, postcondiciones.

• Registra el sistema: marca de "generado por IA", requerimiento de origen, job productor.

Reglas de negocio aplicables

• RN-064 — la generación exige acción explícita; nunca es automática.
• RN-020 — un caso al que le falte objetivo, actores, precondiciones, flujo principal o

postcondiciones no puede pasar de Draft a En revisión.

• RN-021 — cada caso declara su requerimiento de origen y, si lo generó la IA, el job.

Estados y transiciones. Los casos nacen en Draft según la máquina de estados del caso de uso.

Integraciones (documentado, el dev implementa)

• Proveedor de IA (Bedrock) — genera la propuesta en formato estructurado, que se valida

antes de persistir (RF-126). Contrato pendiente de PA-011; el job se registra como en HU-007.

Eventos que emite. use_case.generated.

Criterios de aceptación

• CA-088

> Dado un requerimiento del proyecto > Cuando el usuario solicita la generación de casos de uso > Entonces el sistema encola el job, avisa que el resultado es asíncrono y no procesa nada sin la solicitud explícita.

• CA-089

> Dado un job de generación completado > Cuando el sistema presenta los casos propuestos > Entonces cada uno aparece en estado Draft, marcado de forma visible como generado por IA, con su estructura completa (objetivo, actores, precondiciones, flujos y postcondiciones).

• CA-090

> Dado un conjunto de casos propuestos > Cuando el usuario acepta unos y descarta otros > Entonces solo los aceptados se persisten, cada uno con su requerimiento de origen y el job que lo produjo.

• CA-091

> Dado que se persisten casos generados por IA > Cuando la generación concluye > Entonces el sistema emite use_case.generated.

• CA-092

> Dado un caso generado al que le falta un campo obligatorio > Cuando el usuario intenta pasarlo a En revisión > Entonces el sistema lo impide, lo mantiene en Draft y señala qué falta.

Dependencias y bloqueos

• PA-011 (Bedrock) — condiciona el contrato de IA, no el comportamiento local.
• HU-007 aporta el contexto analizado; HU-009 es la vía manual equivalente; HU-010

toma los casos en Draft hacia la línea base. HU-026 gobierna el job.

Casos borde / notas. Regenerar no toca los casos ya aceptados. Un caso reescrito por completo a partir de una propuesta conserva la trazabilidad al job con la anotación de reescritura (ver HU-009 A1).

HU-009 — Crear un caso de uso manualmente

Épica: D · Casos de uso · Deriva de: CU-006 · Cubre: RF-030–RF-032 · Reglas: RN-020, RN-021, RN-065 · Decisiones: DEC-027 · Estado: Borrador

Historia

Como QA, quiero crear un caso de uso completamente a mano, para no depender de la IA y poder trabajar aunque el proveedor no esté disponible.

Objetivo / valor. Garantizar que la IA nunca es condición para avanzar: un caso creado a mano tiene la misma estructura, obligaciones y trazabilidad que uno generado.

Alcance

• Dentro: la creación de un caso en blanco asociado a un requerimiento, la captura de su

estructura completa, el guardado en Draft y el envío a En revisión cuando está completo.

• Fuera: la generación con IA (HU-008) y el congelamiento (HU-010).

Actores y permisos

Precondiciones

• Existe un requerimiento en el proyecto al cual asociar el caso.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El usuario crea un caso en blanco y selecciona el requerimiento de origen.

Completa objetivo, actores, precondiciones, flujo principal, flujos alternativos, flujos de error, postcondiciones, reglas aplicables y supuestos. El sistema guarda en Draft. Cuando los campos obligatorios están completos, el usuario lo envía a En revisión. La disponibilidad de IA no es condición en ningún punto (RN-065).

• Alternativo A1 — Partir de una propuesta de IA. El usuario toma un caso generado y lo

reescribe por completo; conserva la trazabilidad al job con la anotación de que fue reescrito.

• Error E1 — Campos obligatorios incompletos. El sistema impide la transición a

En revisión y señala qué falta (RN-020).

Datos y campos (funcional)

• Captura el usuario: requerimiento de origen, objetivo, actores, precondiciones, flujo

principal, flujos alternativos, flujos de error, postcondiciones, reglas aplicables, supuestos.

• Deriva el sistema: identificador, título, estado Draft, autor, timestamps.

Reglas de negocio aplicables

• RN-065 — la IA nunca es condición para avanzar; todo lo que propone, un humano lo crea

y edita a mano.

• RN-020 — sin objetivo, actores, precondiciones, flujo principal y postcondiciones no

hay paso de Draft a En revisión.

• RN-021 — el caso declara el requerimiento del que deriva.

Estados y transiciones. Draft → En revisión según la máquina de estados del caso de uso, condicionada por los campos obligatorios (RN-020).

Eventos que emite. Ninguno propio de la creación manual.

Criterios de aceptación

• CA-093

> Dado un requerimiento del proyecto > Cuando el usuario crea un caso de uso en blanco > Entonces el caso nace en Draft, asociado al requerimiento seleccionado, sin necesidad de intervención de la IA.

• CA-094

> Dado el proveedor de IA no disponible > Cuando el usuario crea y edita un caso de uso a mano > Entonces la creación y la edición operan con normalidad.

• CA-095

> Dado un caso en Draft con todos los campos obligatorios completos > Cuando el usuario lo envía a En revisión > Entonces el sistema acepta la transición.

• CA-096

> Dado un caso en Draft con un campo obligatorio incompleto > Cuando el usuario intenta enviarlo a En revisión > Entonces el sistema lo impide y señala qué campo falta.

• CA-097

> Dado un caso generado por IA > Cuando el usuario lo reescribe por completo a mano > Entonces el caso conserva la trazabilidad al job con la anotación de que fue reescrito.

• CA-098

> Dado un caso creado a mano y uno generado por IA > Cuando ambos se envían a En revisión > Entonces rigen para los dos las mismas obligaciones de estructura y trazabilidad; la vía de creación no cambia sus reglas.

Dependencias y bloqueos

• HU-008 (generación con IA) es la vía alternativa; HU-010 toma el caso hacia la línea

base. No hay PA-### que bloquee esta HU: es la ruta que garantiza operación sin IA.

HU-010 — Revisar y congelar un caso de uso

Épica: D · Casos de uso · Deriva de: CU-007 · Cubre: RF-033–RF-037, RF-041, RF-042 · Reglas: RN-009, RN-022, RN-025 · Decisiones: DEC-028, DEC-037, DEC-040, DEC-047 · Estado: Borrador

Historia

Como Product Manager, quiero fijar una versión aprobada del caso de uso como línea base inmutable, para que las pruebas y la evidencia se anclen a una definición estable y auditable.

Objetivo / valor. El congelamiento es el hito de gobierno: solo el PM lo ejecuta, deja registro inmutable de quién, cuándo y sobre qué versión, y a partir de él nada del caso cambia sin crear una versión nueva.

Alcance

• Dentro: la revisión del caso y sus preguntas abiertas heredadas, la validación, el

congelamiento con confirmación explícita, la marca de obsolescencia y la consulta del historial de versiones.

• Fuera: la creación de la versión nueva tras congelar (HU-011), la generación de

escenarios desde el caso congelado (Épica E) y la edición ordinaria del contenido (HU-008, HU-009).

Actores y permisos

Precondiciones

• El caso está en En revisión o Validado (para congelar).
• Para congelar y para marcar Obsoleto, el usuario tiene rol Product Manager en el

proyecto.

Comportamiento funcional

• Principal. El PM abre el caso y revisa su contenido, supuestos y las preguntas abiertas

heredadas del requerimiento. Marca el caso como Validado y ejecuta la acción de congelar. El sistema pide confirmación explicando que la versión quedará inmutable y que cualquier cambio posterior exigirá una versión nueva. Confirmado, el caso pasa a Congelado y el sistema registra quién congeló, cuándo y sobre qué número de versión, de forma inmutable (RN-022, RN-025). Emite use_case.frozen.

• Alternativo A1 — Devolver a revisión. El PM detecta un problema y devuelve el caso a

En revisión en lugar de congelarlo.

• Alternativo A2 — Editar un Validado. Editar el contenido de un caso Validado lo

devuelve automáticamente a En revisión; el sistema advierte antes de confirmar el cambio (DEC-040).

• Alternativo A3 — Declarar obsoleto. El PM marca un caso como Obsoleto **desde cualquier

estado** (DEC-047). Los escenarios derivados se marcan como desactualizados, el caso deja de contar para la cobertura y permanece consultable. Emite use_case.obsoleted.

• Error E1 — El usuario no es Product Manager. El sistema no ofrece congelar ni marcar

Obsoleto, y rechaza el intento por API (RN-022).

• Error E2 — Intento de editar un caso Congelado. El sistema lo rechaza en cualquier

circunstancia, sin excepción por rol, y ofrece crear una versión nueva (RN-009, HU-011).

Datos y campos (funcional)

• Captura el PM: la validación y la decisión de congelar u obsoletar.
• Registra el sistema (inmutable): autor del congelamiento, timestamp, número de versión

congelada; el historial de todas las versiones con estado, fecha, autor y diferencias respecto de la anterior (RF-042).

Reglas de negocio aplicables

• RN-022 — solo el Product Manager congela; el registro de quién, cuándo y qué versión

es inmutable.

• RN-009 — un caso Congelado no se edita, no se descongela y no se elimina.
• RN-025 — las versiones se numeran correlativa y ascendentemente; un número no se

reutiliza.

Estados y transiciones. Sigue la máquina de estados del caso de uso: En revisión ↔ Validado → Congelado, con → Obsoleto desde cualquier estado y sin salida desde Congelado salvo a Obsoleto. Editar un Validado fuerza → En revisión (RN-077, DEC-040).

Eventos que emite. use_case.frozen al congelar; use_case.obsoleted al declarar obsoleto. La validación no emite evento (DEC-050).

Criterios de aceptación

• CA-099

> Dado un caso de uso en Validado y un usuario con rol Product Manager > Cuando el PM ejecuta la acción de congelar y confirma el aviso de inmutabilidad > Entonces el caso pasa a Congelado, el sistema registra quién, cuándo y sobre qué número de versión de forma inmutable, y emite use_case.frozen.

• CA-100

> Dado un caso de uso en En revisión o Validado > Cuando un usuario con rol QA o Developer intenta congelarlo > Entonces el sistema no ofrece la acción y la rechaza si se intenta por API.

• CA-101

> Dado un caso de uso en Congelado > Cuando cualquier usuario, incluido el PM, intenta editar su contenido, descongelarlo o eliminarlo > Entonces el sistema lo rechaza y ofrece crear una versión nueva.

• CA-102

> Dado un caso de uso en Validado > Cuando el usuario edita su contenido > Entonces el sistema advierte antes de confirmar y, al confirmar, el caso vuelve a En revisión.

• CA-103

> Dado un caso de uso en cualquier estado > Cuando el Product Manager lo marca como Obsoleto > Entonces el caso pasa a Obsoleto, sus escenarios derivados se marcan como desactualizados, deja de contar para la cobertura, permanece consultable y el sistema emite use_case.obsoleted.

• CA-104

> Dado un caso de uso con varias versiones > Cuando el usuario consulta su historial > Entonces el sistema muestra cada versión con su estado, fecha, autor y las diferencias respecto de la versión anterior.

Dependencias y bloqueos

• HU-011 (versión nueva) es la única vía para modificar un caso congelado. La generación

de escenarios (Épica E) consume el caso Congelado. No hay PA-### que bloquee esta HU.

Casos borde / notas. Obsoleto es la única vía de retiro: no existe eliminación (DEC-047). Un caso Congelado solo puede salir hacia Obsoleto; cualquier otro cambio se hace en una versión nueva.

HU-011 — Crear una versión nueva de un caso congelado

Épica: D · Casos de uso · Deriva de: CU-008 · Cubre: RF-038–RF-040, RF-042 · Reglas: RN-023, RN-024, RN-037 · Decisiones: DEC-028 · Estado: Borrador

Historia

Como QA, quiero crear una versión nueva de un caso de uso congelado, para reflejar un cambio del negocio sin destruir la línea base contra la cual ya se probó.

Objetivo / valor. El versionado protege la trazabilidad: la versión congelada queda intacta y la nueva recorre el ciclo por su cuenta; al congelarse, los escenarios de la versión anterior se marcan para que alguien los revise en vez de romperse en silencio.

Alcance

• Dentro: la creación de la versión siguiente en Draft con el contenido heredado, su

edición, la coexistencia con la congelada, y el marcado automático de escenarios desactualizados al congelar la nueva versión, con su desfase visible.

• Fuera: el congelamiento en sí (lo cubre HU-010, al que la versión nueva llega por el

ciclo normal) y la revisión de cada escenario desactualizado (Épica E).

Actores y permisos

Precondiciones

• Existe un caso de uso en estado Congelado.
• El usuario tiene rol PM, QA o Developer en el proyecto.

Comportamiento funcional

• Principal. El usuario abre el caso congelado y solicita crear una versión nueva. El

sistema crea la versión siguiente en Draft con el contenido heredado (RN-023, numeración correlativa por RN-025). El usuario edita lo que cambió. La versión nueva recorre el ciclo normal hasta congelarse (HU-010). Al congelarse, el sistema marca como desactualizados todos los escenarios derivados de la versión anterior (RN-024) y deja visible, en cada escenario y en el plan, qué versión lo originó y cuál es la vigente (RF-040). La versión congelada anterior permanece intacta y consultable.

• Alternativo A1 — Revisar un escenario desactualizado. El usuario compara el escenario con

la versión vigente, confirma que sigue siendo correcto y limpia el indicador; el escenario no cambia de estado.

• Alternativo A2 — El escenario debe cambiar. El usuario lo devuelve a Requiere cambios y

lo ajusta.

• Error E1 — Ya existe una versión en curso. Si el caso tiene una versión posterior en

Draft o En revisión, el sistema lo indica y ofrece continuarla en lugar de abrir otra.

Datos y campos (funcional)

• Hereda la versión nueva: todo el contenido de la versión congelada anterior.
• Deriva el sistema: número de versión siguiente (correlativo, no reutilizado), estado

Draft, vínculo a la versión de origen; en cada escenario afectado, la marca de desactualizado y la versión que lo originó frente a la vigente.

Reglas de negocio aplicables

• RN-023 — modificar un caso congelado solo es posible creando una versión nueva que nace

en Draft heredando el contenido; la congelada permanece intacta.

• RN-024 — al congelar la versión nueva, los escenarios derivados de la anterior quedan

marcados como desactualizados; no se eliminan ni se retiran, se marcan para forzar revisión humana.

• RN-037 — un escenario desactualizado sigue siendo ejecutable, pero el sistema lo

advierte antes de ejecutar y registra la advertencia en la ejecución resultante.

Estados y transiciones. La versión nueva sigue la máquina de estados del caso de uso desde Draft; ambas versiones coexisten (la anterior Congelado, la nueva en curso). El marcado de escenarios desactualizados es efecto del congelamiento de la nueva versión, no de su creación.

Eventos que emite. Al congelarse la versión nueva, use_case.frozen (lo emite HU-010). La creación de la versión no emite evento propio.

Criterios de aceptación

• CA-105

> Dado un caso de uso en Congelado > Cuando el usuario solicita crear una versión nueva > Entonces el sistema crea la versión siguiente en Draft con el contenido heredado y un número correlativo, y la versión congelada permanece intacta y consultable.

• CA-106

> Dado un caso con una versión posterior ya en Draft o En revisión > Cuando el usuario intenta crear otra versión nueva > Entonces el sistema lo indica y ofrece continuar la versión en curso en lugar de abrir otra.

• CA-107

> Dado una versión nueva de un caso que llega a congelarse > Cuando se ejecuta el congelamiento > Entonces todos los escenarios derivados de la versión anterior quedan marcados como desactualizados, sin eliminarse ni bloquearse.

• CA-108

> Dado un escenario marcado como desactualizado > Cuando el usuario consulta el escenario o el plan > Entonces el sistema muestra qué versión del caso lo originó y si esa versión sigue siendo la vigente.

• CA-109

> Dado un escenario marcado como desactualizado > Cuando el usuario lo ejecuta de todos modos > Entonces el sistema advierte antes de ejecutar y registra la advertencia en la ejecución resultante.

• CA-110

> Dado un escenario desactualizado que el usuario compara con la versión vigente y confirma correcto > Cuando limpia el indicador de desactualizado > Entonces el escenario deja de estar marcado y no cambia de estado.

Dependencias y bloqueos

• HU-010 (revisar y congelar) provee el caso Congelado de partida y congela la versión

nueva. La revisión y ejecución de los escenarios desactualizados vive en las Épicas E y G. No hay PA-### que bloquee esta HU.

Casos borde / notas. Un escenario desactualizado sigue siendo ejecutable con advertencia (RN-037): la marca fuerza revisión, no detiene la ejecución. La distinción entre "sigue correcto" (A1, limpia el indicador) y "debe cambiar" (A2, Requiere cambios) decide si el escenario se ajusta o solo se reconfirma.