Preguntas abiertas

Registro de lo que no está definido. Nada de esto se resuelve por inferencia: o lo responde el usuario, o se convierte en un ADR propuesto con su fundamento explícito.

Última actualización: 2026-08-24

Estados: Abierta · Respondida · Escalada a ADR · Descartada

Situación: 12 abiertas, 7 respondidas. De las abiertas, 5 son insumos que existen y aún no tengo (PA-005 a PA-009) — no son decisiones pendientes. Ya no quedan bloqueantes: PA-018 quedó respondida por DEC-061 (retención) y PA-019 por DEC-060 (roles de plataforma).

Índice

Inconsistencias de la documentación de origen

PA-001

GitLab aparece dos veces en "Integraciones operativas". En el documento maestro, la lista de integraciones incluye GitLab en dos viñetas con redacciones distintas: una menciona pipelines y tests unitarios, la otra ramas, commits y merge requests. Presumiblemente es una duplicación por edición, no dos integraciones distintas. No se corrige en Notion sin autorización. Impacto: cosmético. Se documenta una sola integración GitLab.

PA-002

El alcance del MVP se contradice entre los dos documentos.

La presentación ejecutiva es la que se mostró a stakeholders, así que la expectativa externa probablemente incluye ambas cosas. Decisión provisoria (2026-08-20): no se producen dev specs en esta fase; primero el análisis funcional. La pregunta de si dev specs y GitLab entran al MVP se resuelve después de terminar el análisis, no antes. Impacto: define si el Portal del Desarrollador y los widgets GitLab del dashboard son Fase 1 o Fase 2. Actualización (2026-08-24 · DEC-059): la parte de dev specs se resolvió — se producen como historias de usuario en docs/05-especificaciones/. Queda abierta solo la parte de GitLab y el Portal del Desarrollador, que se resuelve junto con PA-003.

PA-003

El roadmap de Fase 2 difiere entre documentos. El maestro define Fase 2 como "Dev specs y trazabilidad avanzada"; la ejecutiva como "Integración Desarrollo: GitLab, pipelines, tests unitarios y Portal del Desarrollador". Se resuelve junto con PA-002.

PA-004

RESPONDIDA (2026-08-20) — el snapshot está al día. La búsqueda reportaba última edición el 2026-08-20T14:30Z mientras la API devolvía contenido marcado as of 2026-08-11T22:56:50Z. Se releyó la página completa con un conector distinto y el contenido es idéntico al snapshot. La discrepancia era del metadato de la búsqueda, no del contenido. No hay ediciones perdidas.

Insumos requeridos del usuario

Estas no son decisiones, son datos que existen y aún no tengo. Cada una bloquea una parte concreta de la especificación.

PA-005

¿Cuál es el estándar técnico de backend y de API de Flagare? DEC-014 y DEC-015 comprometen a Argos QA con "el estándar existente", pero no sé cuál es. Necesito un repositorio de referencia o la documentación de arquitectura. Bloquea: 03-arquitectura/arquitectura-general.md. No bloquea el análisis funcional.

PA-006

¿Dónde está documentada la API de Argos Operaciones? DEC-009 afirma que existe y está documentada. Sin ella no puedo especificar la importación de proyectos (DEC-025) ni la creación de bugs (DEC-010) más allá del comportamiento deseado. Bloquea: contratos de integración y el detalle de varios casos de uso.

PA-007

¿Cuál es el contrato del JWT y del servicio /me de Flagare? El JWT es solo una llave de validación (identidad): faltan emisor, forma de validar la firma y refresh. Los permisos —incluido el rol de plataforma— los entrega el servicio /me de identity.flagare: falta su contrato —forma de la respuesta, nombres de los permisos/roles de plataforma, y comportamiento ante indisponibilidad—. Bloquea: el origen de los permisos de plataforma (roles-y-permisos.md, RN-008, RN-085) y el flujo de autenticación (HU-001).

PA-008

¿Qué gestor de secretos usa Flagare? DEC-026 compromete la integración con "un vault existente". Necesito saber cuál, cómo se autentica Argos QA contra él y si el acceso es por servicio o por usuario. Bloquea: el caso de uso de preparación de ambiente.

PA-009

¿Cuál es el contrato de notifications.flagare? DEC-012 define publicación por API y consumo en vivo por SSE. Falta: forma del payload de evento, si el SSE lo expone notifications o lo debe exponer Argos QA, autenticación del canal, y comportamiento ante desconexión. Bloquea: el catálogo de eventos de dominio y los RF de notificación.

Definiciones pendientes

PA-010

No hay techo de gasto mensual definido (DEC-019). Sin cifra, los RNF de costo se escriben como "medible y limitable", no como "menor a X". El documento de Notion aporta estimaciones referenciales, no un presupuesto aprobado. Propuesta: definir el techo antes de habilitar Bedrock en producción.

PA-011

Bedrock no está habilitado: falta región y modelos (DEC-017). La disponibilidad de Nova y Claude varía por región, y la región condiciona el model routing completo y la latencia. También hay que confirmar si existe una restricción de residencia de datos que impida enviar contenido de clientes a la región elegida. Impacto: la capa de IA debe especificarse tras una interfaz de proveedor para no quedar amarrada a Bedrock si la habilitación se demora.

PA-012

RESPONDIDA (2026-08-20) — el Product Manager aprueba, QA conduce. QA Lead queda absorbido por el rol QA, que diseña el plan y conduce los ciclos. Tech Lead desaparece: no hay aprobación técnica formal en el MVP. El Product Manager es el único rol que aprueba: congela casos de uso (DEC-037) y aprueba el plan de pruebas (DEC-029). Además, el rol QA es un sombrero asignable por proyecto: un developer puede tenerlo, porque no existe QA dedicado (DEC-035). Ver roles y permisos.

PA-013

RESPONDIDA (2026-08-20) — solo indicadores agregados. El rol Client accede exclusivamente a cobertura, porcentaje de éxito, avance y conteo de bugs por severidad de su propio proyecto. No accede a casos de uso, escenarios, evidencia, comentarios internos ni descripción de bugs (DEC-034, RN-061). La restricción se aplica en el backend, no ocultando en la interfaz (RNF-028).

PA-014

RESPONDIDA (2026-08-20) — se bloquea, sin excepciones. No existe proyecto de QA sin contraparte en Argos Operaciones. Los pilotos y las pruebas del propio Argos QA deben crearse primero en Argos Operaciones (DEC-038, RN-014). El sistema no ofrece ninguna vía de creación manual (RF-010).

PA-015

RESPONDIDA (2026-08-20) — español completo. La interfaz está íntegramente en español, con los estados del dominio traducidos (DEC-036). Los nombres técnicos en inglés se conservan en la API, la base de datos y los eventos; la traducción es de presentación y su mapeo debe ser único y documentado (RNF-030, RNF-031). Sin i18n en el MVP.

Abiertas por definir

PA-016

¿Cómo se mapea un bug de Argos QA a un ticket de Argos Operaciones? DEC-033 exige creación automática del ticket espejo, pero falta el detalle: qué tipo de ítem se crea en Argos Operaciones, cómo se mapea la escala de severidad de Argos QA (Bloqueante/Crítica/Mayor/Menor/Cosmética) a la de Argos Operaciones, qué campos son obligatorios allá, si la evidencia se adjunta o se enlaza, y qué ocurre si alguien cierra el ticket en Argos Operaciones mientras el bug sigue abierto en Argos QA. Impacto: RF-095 a RF-100 quedan especificados a nivel de comportamiento deseado, no de contrato. Se resuelve junto con PA-006.

PA-017

¿El reporte formal de calidad tiene un formato exigido? RF-113 define el contenido, no el formato. Falta saber si existe una plantilla institucional, si el reporte debe alimentar a Flagare CAB Manager para la aprobación de pasos a producción, y en qué formatos debe exportarse (PDF, HTML, ambos). Impacto: menor para el análisis funcional; relevante para el diseño de la salida.

Bloqueantes

Detectadas en la revisión del 2026-08-24 (hallazgos-revision.md, H-01 y H-02). A diferencia del resto, impiden implementar y probar la funcionalidad que condicionan: quien construya tendría que inventar la regla. Ambas quedaron resueltas: PA-018 por DEC-061 y PA-019 por DEC-060.

PA-018

¿Cuál es el plazo exacto de retención de screenshots y logs, y de qué depende?

RESPONDIDA (2026-08-24 · DEC-061) — dos valores por resultado. Retención de screenshots y logs: ejecuciones Pass 90 días; Fail/Blocked 12 meses (honra RF-090). Con esto: (1) la diferenciación por resultado queda resuelta; (2) RF-091 es en el MVP una vista informativa de evidencia por vencer —la retención extendida manual es Fase 2—; (3) la fila «evidencia de entregas formales / política del proyecto» de DEC-020 queda fuera del MVP. El análisis original se conserva abajo.

La tabla adoptada por DEC-020 declara rangos, no valores: "6 a 12 meses" para screenshots y logs. Quien implemente el proceso automático de RNF-029 y las lifecycle policies de RNF-044 tiene que elegir un número. Hay tres problemas encadenados:

1. RF-090 exige diferenciar la retención por resultado de la ejecución, y la tabla solo

lo hace en las filas de video, que DEC-006 excluye del MVP. Para screenshots y logs no existe criterio por resultado.

1. La fila "Evidencia de entregas formales — según política del proyecto" invoca un

concepto, política del proyecto, que no existe en ningún artefacto.

1. RF-091 permite consultar qué evidencia está por vencer "para poder retenerla", pero

ningún RF ni RN define el mecanismo de retención extendida, y RN-010 con RF-089 declaran la expiración como la única vía por la que la evidencia desaparece.

Opciones, sin recomendación: (a) un valor único por tipo, eliminando la diferenciación por resultado en el MVP —obliga a reescribir RF-090—; (b) dos valores según resultado (Pass corto, Fail/Blocked largo) —la política pasa a depender de un estado mutable—; (c) retención configurable por proyecto con un default global —hay que definir quién la configura, con qué techo, y aparece un permiso nuevo—. Impacto: RF-089, RF-090, RF-091, RNF-029 y RNF-044 no se pueden implementar ni probar. Condiciona el diseño del bucket, que RNF-044 exige configurar desde el despliegue inicial.

PA-019

¿Quién está autorizado a importar un proyecto desde Argos Operaciones?

RESPONDIDA (2026-08-24 · DEC-060) — por rol de plataforma. La autorización para importar es un rol de plataforma (Product Manager o Admin), provisto por identity.flagare en el JWT y distinto de los roles de proyecto (RN-085). Quien importa queda como Product Manager de proyecto del proyecto creado (RN-005); así se rompe el círculo, porque el permiso para crear el primer proyecto no depende de un rol de proyecto inexistente. La matriz movió "Importar" a la tabla de acciones de plataforma. Queda pendiente solo el contrato del claim de rol en el JWT (PA-007). El análisis de opciones original se conserva abajo como registro.

La matriz de permisos otorga "Importar un proyecto desde Argos Operaciones" exclusivamente al Product Manager. Pero RN-001 establece que el rol se asigna por la dupla usuario + proyecto y que no existe rol global, y CU-001 dice que el rol Product Manager se crea como consecuencia de la importación. Antes de importar nadie tiene rol en un proyecto que todavía no existe: la fila de la matriz no es satisfacible por nadie y el primer proyecto de la plataforma no puede crearse. RF-009 y RF-010 describen la operación sin decir quién la ejecuta, y RF-003 crea el usuario local al primer acceso sin asignarle ningún rol.

Opciones, sin recomendación: (a) cualquier usuario con JWT válido importa y queda PM del proyecto que importó —cualquier persona de Flagare podría crear proyectos de QA y volverse su aprobador único—; (b) un rol de plataforma fuera de los cuatro de DEC-024 —rompe "no existe rol global" y agrega un quinto rol—; (c) la autorización depende del rol que el usuario tenga en Argos Operaciones sobre ese proyecto —queda condicionada al contrato de PA-006—. Impacto: CU-001 completo, RF-009, RF-010, la fila correspondiente de la matriz de permisos y RN-001. Es la puerta de entrada del producto: sin resolverlo, nada del resto del flujo se puede ejercitar.