Producto: Estrategia De Versiones

Estado: regla de producto

Fecha: 2026-05-05

Objetivo

OPS Center necesita poder cerrar una version estable aunque sigan apareciendo ideas, modulos y capacidades nuevas. La creatividad no debe bloquear el lanzamiento.

La regla principal:

> Ninguna funcionalidad experimental debe impedir cerrar una version estable. Todo lo nuevo entra por flags, entitlements y permisos hasta superar validacion.

Carriles De Producto

Stable Core

Funcionalidades listas para clientes o usuarios reales.

Incluye:

• cuentas y workspaces
• usuarios y roles
• tareas y colas
• PRDs/specs basicos
• credenciales seguras
• deployment targets
• admin SaaS basico
• documentacion y runbooks

Reglas:

• no romper compatibilidad sin migracion
• cambios pequenos y testeados
• smoke final obligatorio
• UX clara y sin mensajes experimentales

Roadmap

Funcionalidades previstas, documentadas y priorizables.

Ejemplos:

• mejora visual del admin SaaS
• asistente OPS
• bridge con agentes de escritorio
• integracion Flowkit/Flowtitude
• billing futuro

Reglas:

• puede estar documentado sin implementarse
• debe tener tarea o epic en OPS
• no bloquea version estable

Experimental

Funcionalidades desplegadas pero limitadas a owner, testers, cuentas concretas o workspaces concretos.

Ejemplos:

• asistente en beta
• automatizaciones IA nuevas
• modulos de builder
• integraciones con plugins externos
• workflows no validados

Reglas:

• no visible para usuarios sin permiso
• API protegida, no solo UI oculta
• etiqueta visual de experimental cuando aparezca
• apagable sin redeploy
• auditoria de uso
• salida a stable solo tras validacion

Idea Inbox

Ideas crudas que aparecen mientras se trabaja, se prueba o se piensa.

Reglas:

• se anotan sin obligacion de ejecucion inmediata
• si parecen estrategicas, pasan a roadmap
• si necesitan prueba, pasan a experimental
• si son esenciales, entran al core tras plan y criterios de aceptacion

Feature Flags

Los flags deben permitir activar funcionalidades por:

• plataforma
• cuenta
• workspace
• usuario
• plan

La UI solo debe mostrar lo permitido, pero la API debe validar siempre el acceso.

Criterios Para Pasar De Experimental A Stable

1. Tiene propietario funcional.
2. Tiene documentacion minima.
3. Tiene permisos claros.
4. Tiene smoke o checklist manual.
5. No expone secretos.
6. No rompe flujos existentes.
7. Tiene rollback o apagado rapido.
8. Ha sido probado por owner/tester.

Aplicacion Practica

Cuando aparezca una idea nueva:

1. Anotarla como Idea Inbox.
2. Decidir si va a roadmap, experimental o stable.
3. Si va a experimental, crear flag y entitlement antes de abrir UI.
4. Si va a stable, exigir criterios de cierre.

Esto permite que el producto avance con cabeza inquieta, pero version estable.