Máquinas de estado

Estado: Borrador · Última actualización: 2026-08-24 Deriva de: "Estados Iniciales Sugeridos" del documento maestro -- que define estados para caso de uso, escenario, ejecución y bug -- y de las decisiones DEC-028 a DEC-033. Los estados de plan de pruebas, bloqueo y proyecto no vienen de la fuente: se propusieron en este análisis y quedaron validados por DEC-054, con RF-139, RF-140 y RF-141 enumerándolos.

Toda transición no dibujada aquí es inválida. El sistema debe rechazarla, no ignorarla.

1. Caso de uso

stateDiagram-v2
    [*] --> Draft: creación manual o generación IA
    Draft --> EnRevision: completa los campos obligatorios (RN-020)
    EnRevision --> Draft: requiere cambios
    EnRevision --> Validado: revisión conforme
    Validado --> EnRevision: se detecta un problema
    Validado --> EnRevision: se edita el contenido (RN-077)
    Validado --> Congelado: aprueba el Product Manager (RN-022)
    Congelado --> Obsoleto: lo declara el Product Manager
    Draft --> Obsoleto: se abandona la propuesta (RN-079)
    EnRevision --> Obsoleto: se abandona la propuesta (RN-079)
    Validado --> Obsoleto: se abandona la propuesta (RN-079)
    Congelado --> [*]: inmutable para siempre
    Obsoleto --> [*]

    state "En revisión" as EnRevision

Reglas de la máquina

Lo que no existe: no hay transición de salida desde Congelado hacia ningún estado editable. Modificar un caso congelado se hace creando una versión nueva, que es una instancia distinta con su propia máquina de estados (RN-023).

Versionado

flowchart LR
    A["CU-007 v1<br/>Congelado"] -.->|"crear versión nueva"| B["CU-007 v2<br/>Draft"]
    B --> C["CU-007 v2<br/>Congelado"]
    A -->|"permanece intacta"| A2["CU-007 v1<br/>consultable siempre"]
    C -.->|"marca desactualizados"| D["Escenarios derivados de v1"]

Al congelarse v2, los escenarios que derivaban de v1 se marcan como desactualizados (RN-024). No se retiran: siguen ejecutables con advertencia (RN-037), porque bloquearlos detendría la operación por un cambio que quizá no los afecta.

2. Escenario de prueba

stateDiagram-v2
    [*] --> Generado: generación IA o creación manual
    Generado --> EnRevision: se envía a revisar
    EnRevision --> Aprobado: cumple RN-032 y su caso está Congelado (RN-031)
    EnRevision --> RequiereCambios: revisión con observaciones
    RequiereCambios --> EnRevision: corregido
    Aprobado --> RequiereCambios: se detecta un problema
    Aprobado --> Retirado: deja de aplicar
    RequiereCambios --> Retirado: se descarta
    Generado --> Retirado: se descarta
    Retirado --> [*]

    state "En revisión" as EnRevision
    state "Requiere cambios" as RequiereCambios

Solo los escenarios en Aprobado son ejecutables (RN-034), y únicamente si el plan que los contiene está aprobado.

Desactualizado no es un estado

Es un indicador independiente que puede acompañar a cualquier estado. Un escenario puede estar Aprobado y desactualizado a la vez: significa que sigue siendo válido para ejecutar, pero el caso de uso del que nació cambió y alguien debe revisarlo.

Modelarlo como estado obligaría a sacar el escenario de Aprobado y bloquear la ejecución, que es exactamente lo que RN-037 quiere evitar.

El indicador se limpia cuando un usuario revisa el escenario contra la versión vigente del caso de uso y confirma que sigue siendo correcto.

3. Plan de pruebas

stateDiagram-v2
    [*] --> Borrador
    Borrador --> PendienteAprobacion: se envía a aprobar
    PendienteAprobacion --> Aprobado: aprueba el Product Manager (RN-033)
    PendienteAprobacion --> Borrador: devuelto con observaciones
    Aprobado --> PendienteAprobacion: se agrega o modifica un escenario (RN-035)

    state "Pendiente de aprobación" as PendienteAprobacion

Un plan que vuelve a Pendiente de aprobación no interrumpe los ciclos en curso: las ejecuciones ya iniciadas continúan con los escenarios que estaban aprobados al abrirse el ciclo. Tampoco impide la ejecución fuera de ciclo de un escenario que siga Aprobado (RN-034, DEC-055). Lo único que se bloquea es abrir un ciclo nuevo.

4. Ciclo de QA

stateDiagram-v2
    [*] --> Abierto: se abre contra un ambiente
    Abierto --> Cerrado: cierre con confirmación
    Cerrado --> Abierto: reapertura auditada (RN-045)
    Cerrado --> [*]

Al abrirse, el ciclo captura el snapshot inmutable del ambiente (RN-029). Al cerrarse, el sistema advierte si quedan escenarios en Not run, Fail, Retest required o Blocked, y exige confirmación explícita.

La apertura de un ciclo no emite evento de dominio —es una acción interna que no notifica a terceros—; el único evento del ciclo es cycle.completed, al cerrarse. La ausencia es deliberada, no un hueco del catálogo (HU-015).

5. Ejecución

stateDiagram-v2
    [*] --> NotRun: escenario incorporado al ciclo
    NotRun --> Pass: todos los pasos conformes
    NotRun --> Fail: al menos un paso no conforme
    NotRun --> Blocked: impedimento para probar
    Fail --> RetestRequired: el bug pasa a Listo para retest (RN-041)
    Fail --> RetestRequired: reejecución con motivo, sin bug (RN-078)
    Blocked --> RetestRequired: se resuelve el bloqueo (RN-058)
    Blocked --> NotRun: se descarta el bloqueo, no era real (RN-058)
    RetestRequired --> PassedAfterFix: reejecución conforme
    RetestRequired --> Fail: reejecución no conforme
    RetestRequired --> Blocked: nuevo impedimento
    Pass --> [*]
    PassedAfterFix --> [*]

    state "Not run" as NotRun
    state "Retest required" as RetestRequired
    state "Passed after fix" as PassedAfterFix

Precisión importante. Las ejecuciones son inmutables (RN-040, RN-044): una reejecución crea un registro nuevo. Lo que este diagrama describe es el estado del escenario dentro del ciclo, que avanza a medida que se acumulan registros de ejecución. El historial completo queda visible.

Passed after fix se distingue de Pass a propósito: un escenario que pasó a la primera y uno que pasó después de corregir un defecto no son la misma señal de calidad.

Restricciones

• Un paso en Fail o No ejecutado impide un resultado global Pass (RN-043).
• Blocked exige un bloqueo asociado (RN-039).
• Fail siempre tiene salida: por bug (RN-041) o por reejecución con motivo (RN-078).
• Ningún resultado se registra sin evidencia (RN-013, RN-046).

6. Bug

stateDiagram-v2
    [*] --> Nuevo
    Nuevo --> Asignado
    Asignado --> EnDesarrollo
    EnDesarrollo --> ListoParaRetest
    ListoParaRetest --> Resuelto: retest conforme
    ListoParaRetest --> Reabierto: retest no conforme
    Reabierto --> Asignado
    Resuelto --> Cerrado
    Cerrado --> Reabierto: reaparece, con motivo y evidencia (RN-055)
    Resuelto --> Reabierto: reaparece, con motivo y evidencia
    Cerrado --> [*]

    state "En desarrollo" as EnDesarrollo
    state "Listo para retest" as ListoParaRetest

La sincronización con Argos Operaciones es una dimensión aparte

Pendiente de sincronizar no es un estado del ciclo de vida del bug: un bug puede estar En desarrollo y aún no sincronizado. Se modela como un atributo independiente:

stateDiagram-v2
    [*] --> Pendiente: bug creado
    Pendiente --> Sincronizado: ticket creado en Argos Operaciones
    Pendiente --> Error: fallo tras agotar reintentos
    Error --> Pendiente: reintento manual
    Sincronizado --> [*]

El bug vive con normalidad en Argos QA mientras la sincronización esté pendiente. Un fallo de Argos Operaciones no puede costarle al ejecutor el hallazgo que acaba de encontrar (RN-054).

7. Bloqueo

stateDiagram-v2
    [*] --> Abierto: se detecta el impedimento
    Abierto --> EnGestion: alguien se hace cargo
    EnGestion --> Resuelto: el impedimento desaparece
    EnGestion --> Descartado: no era un bloqueo real
    Abierto --> Descartado: no era un bloqueo real
    Resuelto --> Abierto: reaparece
    Resuelto --> [*]
    Descartado --> [*]

    state "En gestión" as EnGestion

Al pasar a Resuelto, todas las ejecuciones que dependían del bloqueo pasan automáticamente a Retest required (RN-058). Al pasar a Descartado, esas ejecuciones vuelven a Not run —el resultado Blocked fue inválido, no hay nada que retestear— y el sistema debe advertir que fueron marcadas Blocked sin causa válida: es un síntoma de mal uso del estado. El Blocked descartado permanece en el historial y en auditoría (RN-058).

8. Proyecto

stateDiagram-v2
    [*] --> Activo: importado desde Argos Operaciones
    Activo --> Archivado: sin ciclos abiertos (RN-082)
    Archivado --> Activo: reactivación por el Product Manager (RF-138)
    Archivado --> [*]

Un proyecto Archivado es de solo lectura: conserva toda su información, evidencia y trazabilidad, pero no admite ciclos, ejecuciones, bugs ni ediciones nuevas.

No se puede archivar con un ciclo Abierto: hay que cerrarlo antes, para que la confirmación de RF-081 obligue a mirar los escenarios pendientes (RN-082). Lo único que sigue corriendo tras el archivado es el reintento de sincronización de bugs hacia Argos Operaciones.

9. Resumen de estados terminales

10. Mapeo de estados: nombre técnico ↔ etiqueta

Fuente única del mapeo que exige RNF-031. La columna izquierda es el identificador que viaja por la API, la base de datos y los payloads de evento; la derecha es lo que ve el usuario (RNF-030, DEC-036). Un estado se nombra igual en todas las entidades donde aparezca el mismo concepto, y ningún par se reutiliza para conceptos distintos. DEC-057.

Caso de uso (RF-033)

Escenario de prueba (RF-050)

El indicador independiente de RN-024 es outdated / desactualizado, y no es un estado.

Plan de pruebas (RF-139)

Ciclo de QA

Ejecución (RF-074)

Resultado por paso (RF-073): pass / conforme, fail / no conforme, not_executed / no ejecutado. not_executed es del paso, no de la ejecución: no confundir con not_run, que es el estado del escenario dentro del ciclo antes de correrlo.

Bug (RF-098)

Sincronización con Argos Operaciones, dimensión independiente (RN-054): pending / pendiente de sincronizar, synced / sincronizado, error / error de sincronización.

Bloqueo (RF-140)

Proyecto (RF-141)

Notas del mapeo

• Los nombres técnicos van en snake_case, sin acentos ni eñes, y no cambian nunca: un

estado renombrado en la interfaz conserva su identificador técnico.

• pass, fail, blocked, not_run, retest_required y passed_after_fix se conservan

tal como los fija RNF-031 y los usa el dominio.

• in_review y approved aparecen en más de una entidad con el mismo significado; se

desambiguan por el tipo del recurso, no por el nombre.

• Las etiquetas en español de los estados de la ejecución son las únicas que el corpus

venía usando en inglés (Pass, Fail, Blocked…). Se conservan en inglés dentro de esta documentación, por convención del dominio y por CLAUDE.md; la columna de etiqueta fija lo que la interfaz muestra al usuario final.