ComandeskHelp Inicio

Experimental Modules And Assistant Bridge

Estado: fase futura propuesta

Fecha: 2026-05-05

Objetivo

OPS Center debe poder desplegar funcionalidades experimentales para el owner, testers o equipos concretos sin abrirlas a todos los clientes. Tambien debe poder integrarse con Flowtitude Builder Bridge y Flowkit como un ecosistema donde cada producto funcione de forma independiente, pero pueda colaborar cuando comparten cuenta, workspace o proyecto.

Problemas Que Resuelve

  1. Probar modulos nuevos en produccion sin exponerlos al publico.
  2. Permitir que Flowkit, Flowtitude y OPS compartan contexto de trabajo sin quedar acoplados.
  3. Crear un asistente conversacional que convierta intencion en tareas, PRDs, planes, especificaciones y ejecuciones.
  4. Invertir el flujo actual: no solo agentes que reclaman tareas, sino usuarios que hablan con un asistente y lanzan trabajo hacia agentes/colas.

Feature Flags Y Modulos Experimentales

La app debe separar disponibilidad en tres niveles:

  • public: disponible para todos los clientes del plan.
  • private: disponible solo para cuentas/workspaces permitidos.
  • experimental: disponible para owner, testers o usuarios concretos.

La decision se debe resolver en API, no solo en UI.

Modelo Propuesto

Tablas futuras:

  • feature_modules

- slug

- name

- status: public|private|experimental|disabled

- description

- metadata

  • feature_entitlements

- module_slug

- account_id

- workspace_id

- user_id

- enabled

- expires_at

Regla

Un modulo experimental solo se muestra y solo responde en API si el usuario tiene entitlement activo.

Ecosistema Flowkit / Flowtitude / OPS

Cada producto debe seguir funcionando solo:

  • Flowkit: tema, UI, componentes y asistente de sitio.
  • Flowtitude Builder Bridge: puente con builder, automatizaciones y generacion.
  • OPS Center: tareas, agentes, colas, PRDs, planificacion, credenciales y ejecucion.

La colaboracion debe ocurrir mediante contratos, no mediante dependencias internas fragiles.

Contratos Compartidos

  1. workspace
  2. project
  3. prd
  4. task
  5. agent_profile
  6. artifact
  7. assistant_session

Flowkit podria crear una especificacion visual. Flowtitude podria convertirla en cambios de builder. OPS podria crear tareas, asignarlas a agentes y coordinar validacion/deploy.

Asistente OPS

El asistente debe ser una capa propia, no solo un chat pegado a la UI.

Capacidades MVP

  • crear tareas desde conversacion
  • convertir una idea en PRD breve
  • generar plan por fases
  • proponer agente/perfil/modelo
  • buscar contexto del workspace
  • preparar checklist de deploy
  • pedir confirmacion humana antes de acciones sensibles
  • enviar trabajo a cola manual, interactiva o auto

Entidades Futuras

  • assistant_sessions

- workspace, user, title, mode, status

  • assistant_messages

- session, role, content, metadata

  • assistant_actions

- session, action_type, payload, status, result, approved_by

Herramientas Del Asistente

El asistente no debe tocar la DB directamente. Debe usar herramientas internas:

  • create_task
  • create_prd
  • create_project_plan
  • assign_agent
  • queue_dispatch
  • read_workspace_context
  • read_runtime_inventory
  • request_human_approval

Conexion Con Agentes De Escritorio

El flujo objetivo no debe depender de que el usuario abra un agente y reclame una tarea manualmente.

Modelo Propuesto

  1. El usuario conversa con el asistente en OPS.
  2. El asistente crea tarea, PRD o plan.
  3. OPS asigna agente/perfil y modo.
  4. El dispatcher publica la tarea en cola.
  5. Un conector de escritorio o worker local reclama tareas autorizadas para ese usuario/workspace.
  6. El agente ejecuta y devuelve output, archivos o comentarios.
  7. OPS muestra el resultado y solicita aprobacion si aplica.

Conectores De Escritorio

Opciones futuras:

  • worker local autenticado por device token
  • desktop agent que se registra en OPS
  • CLI que mantiene heartbeat y reclama tareas
  • bridge por WebSocket/SSE para notificaciones

El conector debe tener permisos por workspace y nunca recibir secretos que no necesite.

Seguridad

  • Los modulos experimentales deben estar ocultos por API y UI.
  • Las acciones del asistente deben auditarse.
  • Las herramientas sensibles requieren confirmacion humana.
  • Los secretos se resuelven solo en runtime.
  • Cada conector de escritorio debe tener token revocable.

Fases Propuestas

Fase A: Feature Flags Reales

  • Crear tablas de modulos y entitlements.
  • API GET /api/features por usuario/workspace.
  • UI para activar modulo por cuenta/workspace/user.
  • Middleware para proteger endpoints experimentales.

Fase B: Assistant Core

  • Crear sesiones, mensajes y acciones.
  • UI lateral o modal de asistente.
  • Tool calling interno para crear tareas y PRDs.
  • Guardrails de aprobacion.

Fase C: Desktop Agent Bridge

  • Registrar dispositivos/conectores.
  • Heartbeat local.
  • Reclamar tareas por workspace.
  • Devolver output y logs.

Fase D: Ecosistema Flowkit/Flowtitude

  • Definir contrato de artifacts.
  • Importar PRDs/specs desde Flowkit.
  • Crear tareas OPS desde Flowtitude.
  • Sincronizar estados sin acoplar bases de datos.

Detalle de fase 2 para sitios conectados por MCP: docs/architecture/mcp-site-connectors-flowtitude.md.

Decision Recomendada

Implementarlo, pero no ahora en el core critico. Debe entrar como fase futura despues de cerrar el admin SaaS visual y la seguridad runtime basica.

Nombre sugerido de fase: Experimental Modules + OPS Assistant Bridge.