Reglas de negocio — MVP

Estado: Borrador · Última actualización: 2026-08-24 Catálogo canónico. Otros documentos pueden reformular una regla para que se lea en contexto, pero el texto que manda es el de aquí.

Una regla de negocio describe una restricción o invariante del dominio: algo que debe cumplirse siempre, con independencia de la interfaz o la tecnología. Los requerimientos funcionales describen qué hace el sistema; las reglas describen qué no puede dejar de cumplirse mientras lo hace.

Roles y acceso

RN-001. Los roles de proyecto se asignan por la dupla usuario + proyecto. No existe rol de proyecto global; los roles de plataforma (RN-085) son un nivel aparte.

RN-002. Un usuario puede tener más de un rol en el mismo proyecto. Sus permisos efectivos son la unión de los permisos de cada rol, nunca la intersección.

RN-003. Un usuario puede tener roles distintos en proyectos distintos.

RN-004. Un usuario sin rol en un proyecto no puede verlo, listarlo ni acceder a ninguno de sus recursos, ni siquiera conociendo su identificador.

RN-005. Todo proyecto debe tener al menos un Product Manager. No se puede revocar el último.

RN-006. El rol Client es excluyente: quien lo tenga en un proyecto no puede tener otro rol en ese mismo proyecto.

RN-007. La asignación y revocación de roles es facultad del Product Manager del proyecto y queda registrada en auditoría.

RN-008. El JWT de identity.flagare valida la identidad del usuario; sus permisos de plataforma (Admin / Product Manager) los entrega el servicio /me de identity.flagare, no el token. Los roles de proyecto los administra Argos QA. Sujeto a PA-007.

RN-085. La autorización de plataforma proviene de los permisos que entrega el servicio /me de identity.flagare (el JWT solo valida la identidad); Argos QA los consulta al iniciar sesión y no los administra. Es independiente del perfil por proyecto que Argos QA sí gestiona (RN-001). Son dos: Admin, con acceso total a Argos QA y a todos los proyectos; y Product Manager, que habilita importar/crear proyectos de QA. Quien importa con permiso de plataforma Product Manager (o Admin) queda como Product Manager de proyecto del proyecto creado (RN-005). El Admin puede actuar en cualquier proyecto sin rol de proyecto asignado.

Restricciones absolutas

Ningún rol, en ninguna circunstancia, puede infringirlas.

RN-009. Un caso de uso en estado Congelado no se edita, no se descongela y no se elimina.

RN-010. La evidencia no se elimina. Solo desaparece por vencimiento de la política de retención.

RN-011. El registro de auditoría no se edita ni se borra.

RN-012. Argos QA no almacena el valor de ningún secreto o credencial.

RN-013. No se registra un resultado de ejecución sin evidencia adjunta.

RN-014. No existe un proyecto de QA sin proyecto correspondiente en Argos Operaciones.

Proyectos e integración con Argos Operaciones

RN-015. Un proyecto de Argos Operaciones se corresponde con exactamente un proyecto de Argos QA. No se admite duplicar la importación.

RN-016. La re-sincronización con Argos Operaciones actualiza únicamente los datos importados. Nunca sobrescribe información propia de Argos QA: roles, ciclos, escenarios, ejecuciones, evidencia ni bugs.

RN-017. La indisponibilidad de Argos Operaciones degrada, no detiene. Los proyectos ya importados siguen operativos; solo se bloquean la importación de proyectos nuevos y la creación de tickets espejo, esta última de forma diferida (RN-054).

RN-082. Un proyecto no puede archivarse mientras tenga un ciclo Abierto. Archivar y reactivar es facultad del Product Manager y queda en auditoría. El archivado no detiene la sincronización pendiente de bugs con Argos Operaciones: el ticket espejo debe crearse igual. DEC-051.

Requerimientos

RN-018. Solo se aceptan requerimientos en texto plano y Markdown. Cualquier otro formato se rechaza explícitamente, sin extracción parcial ni conversión silenciosa.

RN-019. El documento de origen es inmutable. Corregirlo significa cargar una versión nueva; la anterior se conserva y sigue siendo la fuente de los artefactos que ya derivaron de ella.

Casos de uso y versionado

RN-020. Un caso de uso no puede pasar de Draft a En revisión si le falta alguno de sus campos obligatorios: objetivo, actores, precondiciones, flujo principal y postcondiciones.

RN-021. Todo caso de uso declara el requerimiento del que deriva. Si lo generó la IA, declara además el job que lo produjo.

RN-022. Solo el Product Manager del proyecto congela casos de uso. El congelamiento registra quién, cuándo y sobre qué versión, de forma inmutable.

RN-023. Modificar un caso congelado solo es posible creando una versión nueva, que nace en Draft heredando el contenido. La versión congelada permanece intacta y consultable para siempre.

RN-024. Al congelarse una versión nueva de un caso de uso, todos los escenarios derivados de la versión anterior quedan marcados como desactualizados. No se eliminan ni se retiran automáticamente: se marcan para forzar revisión humana.

RN-025. Las versiones de un caso de uso se numeran de forma correlativa y ascendente dentro del caso. Un número de versión, una vez asignado, no se reutiliza.

RN-077. Editar el contenido de un caso de uso en estado Validado lo devuelve automáticamente a En revisión. La validación acredita el contenido exacto que se revisó, no el caso como entidad. Es la regla análoga a RN-035 para el plan de pruebas. No aplica a cambios que no son de contenido —comentarios, adjuntos, metadatos de trazabilidad—, que no alteran el estado. DEC-040.

RN-079. Un caso de uso puede marcarse Obsoleto desde cualquier estado, y solo lo hace el Product Manager. Es la única vía para retirar un caso: los casos de uso no se eliminan (RN-076). Un caso que se vuelve obsoleto sin haber pasado por Congelado nunca fue línea base, así que no genera hueco de cobertura ni computa en ningún indicador de RN-036. DEC-047.

Ambientes y secretos

RN-026. Las credenciales de un ambiente se registran exclusivamente como referencia: identificador del secreto en el vault, ubicación y responsable de entregarlo. Jamás el valor.

RN-027. El sistema rechaza los valores que aparenten ser credenciales en los campos de texto libre del ambiente. Ante la duda, rechaza.

RN-028. Un checklist de readiness incompleto no impide abrir un ciclo, pero la advertencia y el estado del checklist quedan registrados en el ciclo. Un fallo posterior debe poder atribuirse a un ambiente mal preparado.

RN-029. Al abrir un ciclo se captura un snapshot inmutable de la configuración del ambiente. Los cambios posteriores al ambiente no alteran el snapshot de un ciclo abierto. Es la condición para poder reproducir una ejecución.

RN-030. Un ambiente pertenece a un único proyecto. No se comparten ambientes entre proyectos, aunque apunten a la misma infraestructura.

Plan de pruebas y escenarios

RN-031. Ningún escenario puede pasar a Aprobado si su caso de uso de origen no está en estado Congelado. La exigencia es del escenario, no del método: rige igual para la generación asistida y para la creación manual. Probar contra una definición móvil produce resultados que no significan nada.

Crear y editar un escenario cuyo caso de origen aún no está congelado sí está permitido: el escenario vive en Generado o En revisión y espera ahí. Lo único que el congelamiento habilita es la transición a Aprobado, y con ella la ejecución (RN-034). DEC-041.

RN-032. Un escenario no puede pasar a Aprobado si le falta alguno de sus campos obligatorios: objetivo, precondiciones, ambiente requerido, datos de prueba, rol necesario, pasos con resultado esperado, criterio de aprobación, evidencia requerida y caso de uso de origen. La condición de estado de ese caso de origen la fija RN-031.

RN-033. El plan de pruebas requiere aprobación del Product Manager para habilitar la ejecución.

RN-034. Solo se ejecutan escenarios en estado Aprobado. La exigencia de plan aprobado rige para abrir un ciclo y para ejecutar dentro de él; la ejecución fuera de ciclo (RF-070) depende solo del estado del escenario, no del plan: un escenario Aprobado se puede verificar puntualmente aunque el plan haya vuelto a Pendiente de aprobación por la edición de otro escenario. No computa en ninguna métrica (RF-071). DEC-055.

RN-035. Agregar o modificar escenarios en un plan aprobado devuelve el plan a estado pendiente de aprobación.

RN-036. Un caso de uso congelado sin ningún escenario aprobado que lo cubra constituye un hueco de cobertura de diseño y debe reportarse como tal (RN-081).

RN-037. Un escenario marcado como desactualizado (RN-024) sigue siendo ejecutable, pero el sistema debe advertirlo antes de ejecutar y registrar la advertencia en la ejecución resultante.

Ciclos y ejecución

RN-038. Las ejecuciones realizadas fuera de un ciclo se registran con trazabilidad y evidencia completas, pero no computan en las métricas de cobertura ni de avance.

RN-039. Marcar una ejecución como Blocked exige asociarla a un bloqueo.

RN-040. Las ejecuciones son inmutables una vez registradas. Reejecutar un escenario crea un registro nuevo; nunca sobrescribe el anterior.

RN-041. Cuando un bug pasa a Listo para retest, las ejecuciones fallidas que lo originaron pasan a Retest required.

RN-042. Toda ejecución hereda el snapshot de ambiente del ciclo al que pertenece. Una ejecución fuera de ciclo captura su propio snapshot, en el momento de ejecutarse, del ambiente que el ejecutor eligió (RN-080).

RN-043. El resultado global de un escenario no puede ser Pass si alguno de sus pasos está marcado como Fail o No ejecutado: un Pass afirma que se verificó todo.

RN-044. Una ejecución registrada no se edita. Un error de registro se corrige reejecutando, dejando ambos registros visibles.

RN-045. Un ciclo cerrado no admite ejecuciones nuevas. Para continuar hay que reabrirlo, y la reapertura queda auditada.

RN-078. Un escenario en Fail sin bug asociado puede pasar a Retest required por decisión de quien puede ejecutar, y esa decisión exige un motivo escrito que queda en auditoría. Es la vía para los fallos que no son defectos del producto —dato de prueba incorrecto, error del ejecutor, ambiente mal preparado— sin obligar a abrir un bug (RF-092 mantiene el bug como opcional). Un Fail con bug asociado no usa esta vía: transita por RN-041 cuando el bug queda Listo para retest. DEC-044.

RN-080. Una ejecución fuera de ciclo se realiza contra un ambiente elegido explícitamente por el ejecutor, entre los del proyecto cuyo tipo coincide con el ambiente requerido por el escenario. Sin ambiente compatible registrado no hay ejecución fuera de ciclo. Dos ejecuciones fuera de ciclo del mismo escenario solo son comparables si declaran el mismo ambiente. DEC-048.

RN-084. Una ejecución detenida antes de agotar sus pasos debe cerrarse igual, con resultado global Fail o Blocked, y los pasos que no se corrieron quedan marcados No ejecutado. No existe la ejecución abandonada sin resultado: si alguien empezó a probar y no terminó, el registro debe decir hasta dónde llegó y por qué se detuvo. Sigue rigiendo RN-013: también este cierre exige evidencia. DEC-053.

Evidencia

RN-046. Todo resultado de ejecución exige al menos un elemento de evidencia, incluido Pass. Es la regla que distingue una validación de una afirmación.

RN-047. Cada elemento de evidencia registra automáticamente usuario, timestamp, ejecución, paso, escenario, ciclo, ambiente, tipo, tamaño y hash del contenido. Esta metadata no la edita el usuario.

RN-048. Los binarios viven en S3. La base de datos guarda metadata y referencias.

RN-049. El acceso a la evidencia es siempre por URL firmada de vigencia limitada. No existe acceso público ni enlace permanente.

RN-050. Toda visualización y descarga de evidencia queda auditada.

Bugs y bloqueos

RN-051. Un bug creado desde una ejecución hereda automáticamente su contexto: escenario, caso de uso, paso, ciclo, ambiente, snapshot de configuración, ejecutor, timestamp y evidencia. Este contexto no se edita a mano.

RN-052. Un bug no puede registrarse sin severidad, pasos para reproducir, resultado esperado, resultado obtenido y al menos un elemento de evidencia.

RN-053. Todo bug genera automáticamente su ticket espejo en Argos Operaciones, y ambos quedan enlazados de forma permanente.

RN-054. Si la creación del ticket en Argos Operaciones falla, el bug persiste localmente en Pendiente de sincronizar y se reintenta de forma automática y acotada. Un fallo de integración nunca provoca la pérdida del hallazgo ni bloquea al ejecutor.

RN-055. La reapertura de un bug exige motivo y evidencia nueva.

RN-056. Un bug mantiene de forma permanente el enlace con su ejecución, escenario, criterio de aceptación, caso de uso y ticket de Argos Operaciones.

RN-057. Un bug es un defecto del producto. Un bloqueo es un impedimento para poder probar: ambiente, datos, accesos, dependencias o definiciones pendientes. No se registran como lo mismo, porque no se resuelven igual ni impactan igual las métricas.

RN-058. Al resolverse un bloqueo, todas las ejecuciones que dependían de él pasan a Retest required. Al descartarse un bloqueo —se determina que no era real— esas ejecuciones vuelven a Not run: el resultado Blocked fue inválido, así que no hay nada que retestear. El Blocked descartado se conserva en el historial de la ejecución y en auditoría, y el sistema advierte del mal uso del estado. DEC-045.

RN-083. Un bug se asigna a un miembro del proyecto con rol Product Manager, QA o Developer. Nunca a un Client: ese rol no accede a la descripción de un bug (RN-061), así que no puede ser responsable de resolverlo. Asignar es facultad de esos mismos tres roles, y es condición para que el bug salga de Nuevo. DEC-052.

Observabilidad y reportes

RN-059. Las ejecuciones Blocked no computan como fallo del producto en el porcentaje de éxito. Se reportan en su propia categoría.

RN-060. La cadena de trazabilidad debe poder recorrerse completa y en ambos sentidos: requerimiento → caso de uso → escenario → criterio → ejecución → evidencia → bug → ticket → resolución.

RN-061. El rol Client accede exclusivamente a indicadores agregados de su propio proyecto. Nunca a casos de uso, escenarios, evidencia, comentarios internos ni descripción de bugs.

RN-062. Las métricas de cobertura y avance del ciclo se calculan solo sobre las ejecuciones pertenecientes a ese ciclo (consecuencia de RN-038).

RN-063. Un reporte formal de calidad referencia siempre las versiones congeladas de los casos de uso vigentes al momento de generarse. Un reporte no cambia de contenido porque después se haya creado una versión nueva.

RN-081. "Cobertura" no se usa sin calificar. Son dos indicadores distintos: cobertura de diseño, la proporción de casos de uso congelados con al menos un escenario aprobado que los cubre; y cobertura ejecutada, la proporción de casos congelados con al menos un escenario aprobado y ejecutado con resultado registrado. Toda vista, exportación o reporte que muestre una de las dos debe nombrarla. Las ejecuciones fuera de ciclo no computan en ninguna de las dos (RN-038, RN-062). DEC-049.

Inteligencia artificial

RN-064. Ninguna operación de IA se dispara de forma automática. Siempre media una acción explícita del usuario.

RN-065. La IA nunca es condición para avanzar. Todo artefacto que la IA puede proponer, un humano puede crearlo y editarlo a mano.

RN-066. Toda invocación al proveedor de IA registra tarea, modelo, tokens de entrada y salida, duración, costo estimado, usuario y proyecto.

RN-067. Se usa el modelo más económico capaz de resolver la tarea. La asignación tarea → modelo es configuración, no código.

RN-068. Una respuesta de IA que no valida contra la estructura esperada se descarta íntegra y se informa. No se persiste parcialmente. Los reintentos son acotados y visibles.

Eventos y notificaciones

RN-069. La emisión de un evento nunca puede hacer fallar la operación de negocio que lo originó, ni perderse por indisponibilidad del consumidor. Se persiste antes de publicarse.

RN-070. El canal en vivo se reconecta automáticamente y recupera los eventos ocurridos durante la desconexión.

RN-071. Un usuario solo recibe eventos de proyectos donde tiene rol asignado, con la excepción del rol Client, que no se suscribe al canal de eventos en ninguna circunstancia. Tener rol asignado es condición necesaria, no suficiente: el Client accede únicamente a indicadores agregados por consulta (RN-061, RNF-028, DEC-034), y el canal en vivo revelaría por sí mismo que un escenario falló o que se abrió un bug. La exclusión se aplica al establecer la suscripción, no filtrando el payload. DEC-043.

RN-072. Cada evento lleva un identificador único que permite descartar duplicados provocados por reintentos.

Auditoría e integridad

RN-073. Todo cambio sobre un artefacto crítico registra usuario, fecha y hora, acción, artefacto, valor anterior, valor nuevo y justificación cuando aplique.

RN-074. Toda entrada de auditoría declara su origen: Usuario, IA, Integración o Automatización. Con la IA escribiendo artefactos, distinguir la autoría deja de ser un detalle.

RN-075. El registro de auditoría es append-only.

RN-076. Los identificadores de artefacto son estables y no se reutilizan. Un artefacto con derivados no se elimina: se retira o se marca obsoleto. La cadena de trazabilidad no se rompe nunca.