Command en Sevastopol

Propósito

Command es el bounded context que opera la plataforma SaaS desde Sevastopol. Las islands del dominio están restringidas a SUPER_ADMIN y consumen los servicios documentados en /dev/orchestrator/command/.

El frontend agrupa las islands en dos subdominios coherentes con el corte del backend:

• Plataforma SaaS — provisión de tenants, sesiones activas, dashboard ejecutivo.
• Plan de cuentas — gestión del template contable maestro, sincronización contra tenants y mantenimiento del manual contable.

Subdominios

Subdominio	Islands	Responsabilidad
Plataforma	Tenants, Sessions, Monitoring	Operación SaaS multi-tenant — alta/baja de empresas, kill switch de sesiones, salud del host.
Plan de cuentas	Plan de Cuentas (unificado), Manual Panel, Búsqueda Manual	Template contable maestro + sync contra tenants + manual editor + búsqueda.

Decisiones de UX

Decisión	Motivo
Bounded context separado de administración del tenant	command opera la plataforma; administracion opera el tenant. Mismas habilidades técnicas, distintos niveles de impacto (afectar un tenant vs. afectar todos).
SUPER_ADMIN exigido por todas las islands	El frontend valida el rol con POST /api/auth/validate antes de mostrar acciones destructivas; el backend revalida.
Plan de cuentas unificado en una sola island grande	PlanCuentasCommandIsland agrupa 4 tabs (overview, detail, template, manual). Separar en islands obligaría a cargar el template tres veces.
Banner cross-island desde ChartOfAccountsViewIsland	La vista read-only del tenant tiene un banner ámbar que redirige a la island de edición. Visible solo para SUPER_ADMIN; el resto solo ve dónde se gestiona.
Handoff de manual via sessionStorage + eventos	ManualSearchIsland setea manual-cuentas:open-editor en sessionStorage y dispara el evento — PlanCuentasCommandIsland lo consume al montarse o vía listener. Evita acoplamiento directo.
AdminWorkspace como lenguaje compartido	Las islands de command usan los mismos tokens de WorkspaceTheme que las de administración del tenant; el AdminWorkspace.tsx solo re-exporta.

Lenguaje compartido

Las islands de Command usan tokens de AdminWorkspace (alias de WorkspaceTheme):

Componente	Uso
AdminWorkspaceHeader	Header con controls y pills.
WorkspaceSectionCard	Sección con eyebrow, title, description, pills.
WorkspaceTabBar	Tabs en PlanCuentasCommandIsland (overview/detail/template/manual).
InlineMetricPill	Métricas inline (tenants, KPIs de divergencia, estados).

Hooks compartidos

Ninguna island de Command consume useActiveTenant ni useActivePeriod — operan sobre el universo de la plataforma, no sobre un tenant ni un periodo. La selección de tenant cuando aplica (ej. apertura de diff) se hace dentro de la propia island.

Backend de referencia

Service	Frontend
TenantService	tenants (UI)
SessionService	sessions (UI)
MonitoringService	monitoring (UI)
PlanCuentasSyncService + ChartOfAccountsService	plan-de-cuentas (UI)
Manual de cuentas (Mongo)	manual-panel, manual-search (UI)

Endpoints base

Proxy	Cubre
/api/tenant + /api/tenant-db/create	CRUD de tenants + provisión de la base por tenant.
/api/sessions	Sesiones activas + kill switch.
/api/monitoring	Dashboard ejecutivo de la plataforma.
/api/admin/chart-of-accounts	Plan de cuentas (read-only desde el tenant).
/api/command/plan-cuentas/*	Template del plan + diff + sync por tenant.
/api/command/manual-cuentas/*	Manual editor (admin).
/api/manual-cuentas/*	Manual read (tenant).
/api/auth/validate	Validación de rol previa a acciones destructivas.

Relación con otros dominios

• Administración del tenant consume el plan de cuentas via /api/admin/chart-of-accounts (read). La edición vive aquí.
• Manual de cuentas lo consumen islands de cualquier dominio que necesiten contexto contable de una cuenta — emiten plan-cuentas:select para abrir el panel.
• Auth es transversal — el rol SUPER_ADMIN se valida en cada montaje.

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