Plataforma SaaS en Sevastopol

Propósito

La plataforma SaaS del frontend cubre las tres operaciones diarias de un SUPER_ADMIN sobre la infraestructura: provisionar empresas clientes, vigilar quién está conectado en tiempo real y revisar la salud del host.

Ninguna de las tres islands usa useActiveTenant — operan sobre el universo total de la plataforma, no sobre el tenant activo del operador.

Decisiones de UX

Decisión	Motivo
Tres islands separadas en vez de un dashboard único	Tenants es CRUD, Sessions es lista volátil con kill switch, Monitoring son gauges del host. Mezclarlos forzaría jerarquía visual incompatible.
Alta de tenant en dos pasos	POST /api/tenant crea el registro; POST /api/tenant-db/create provisiona la base postgres. La UI los encadena pero el operador ve cada paso por separado.
Validación de RUT en cliente	validateRut aplica módulo 11 antes de enviar — evita ida al servidor para errores triviales.
Filtro de estado en tabs (all / active / inactive)	Lo más usual es ver activos; el filtro persistente acelera la vista habitual.
Sessions: kill switch protegido contra sesión propia	La island compara session_id con validate.user.sessionId y desactiva el botón “Kill” para la sesión actual — fuerza usar logout.
Monitoring sin auto-refresh	El operador refresca al abrir; el dashboard no es de monitoreo continuo (eso vive en Grafana).
Colores por umbral (verde < 50%, ámbar < 80%, rojo)	Lectura visual instantánea de carga CPU/RAM/Disco sin números explícitos.

Islands del subdominio

Island	Endpoint base	Documentación
TenantsViewIsland	/api/tenant + /api/tenant-db/create	Tenants
SessionsViewIsland	/api/sessions	Sesiones
MonitoringViewIsland	/api/monitoring	Monitoring

Backend de referencia

TenantService, SessionService y MonitoringService en el Orchestrator. Las tres restringen a SUPER_ADMIN en el middleware.

Relación con otros dominios

• Auth revalida rol en cada acción destructiva.
• Plan de cuentas (otro subdominio de Command) opera sobre los tenants que se mantienen aquí.
• Administración del tenant consume el tenant activo provisionado aquí — pero no opera sobre el listado.

Estas relaciones se documentan en cada destino, no aquí.