Dashboard en Sevastopol

Propósito

El Dashboard de Sevastopol (/dashboard) es la página de aterrizaje operativa. Tres widgets montados como islands independientes en pages/dashboard.astro cubren la información de primer vistazo:

• DailyBriefingWidget — tareas del agent (Nostromo Cortex).
• SystemStatusWidget — salud del backend.
• DocumentationWidget — enlace estático al manual operativo.

Cada widget se monta con client:visible (lazy hydration) y opera de forma independiente — no comparten contexto ni hooks de tenant/período.

Layout

Widget	Grid (lg)	Min-height
DailyBriefingWidget	col-span-7	340px
SystemStatusWidget	col-span-5	240px
DocumentationWidget	col-span-5	240px

DailyBriefingWidget

Tareas del agent ordenadas por prioridad y estado. Consume /api/agent/tasks (Orchestrator → nostromo_cortex.tasks en Mongo).

Decisiones de UX

Decisión	Motivo
Refresh automático cada 60s	setInterval en onMount con cleanup. El operador deja la pestaña abierta y ve actualizaciones sin recargar.
Resumen 3 columnas (Pendientes / En curso / Cerradas)	Computado en cliente desde tasks(). Lectura instantánea del estado del día.
Estados con código de color	pending → gris; in_progress → ámbar + pulse animation; completed → emerald. Visualiza progreso sin texto.
Prioridad como badge tipado	high rojo, medium azul, low zinc. Permite ordenar visualmente sin abrir cada tarea.
Empty state vs error state	Sin tareas → “No hay tareas abiertas” (positivo). Error → banner rojo + botón “Reintentar” inline.
Skeleton durante carga inicial	animate-pulse placeholder hasta que llegan los datos. Evita layout shift.
Locale es con date-fns	Día formateado como “miércoles 14 de mayo”; hora HH:mm.

Datos visibles

Campo	Origen
id, title	Identificación.
status	pending / in_progress / completed.
priority	high / medium / low.
createdAt	Hora del día en el card.

Endpoint

Método + ruta	Uso
GET /api/agent/tasks	Tareas del agent. Refresh cada 60s.

SystemStatusWidget

Lectura rápida de salud del backend. Consume /api/monitoring.

Decisiones de UX

Decisión	Motivo
Solo muestra CPU + memoria	El endpoint /api/monitoring devuelve más (tenants, sessions, disk, errors), pero el widget filtra a las 2 métricas que el operador necesita ver de un vistazo. El detalle vive en Monitoring (UI).
Refresh automático cada 30s	Más frecuente que el briefing porque salud es señal temprana — el operador quiere ver caídas rápido.
Status pill tricolor	Verde “Operativo” / Ámbar “Actualizando” / Rojo “Incidencia”. Lectura instantánea del estado del fetch.
Una decimal en porcentajes	cpu_load_pct.toFixed(1) — precisión suficiente sin ruido visual.
Footer explicativo del rol	”Usa este bloque como señal temprana antes de entrar a monitoreo detallado” — redirige al operador al dashboard completo cuando necesita más.

Datos visibles

Campo	Origen	Display
CPU	system_health.cpu_load_pct	XX.X% font-mono.
Memoria	system_health.memory_usage_pct	XX.X% font-mono.

Endpoint

Método + ruta	Uso
GET /api/monitoring	Métricas de salud. Refresh cada 30s.

DocumentationWidget

Acceso al manual operativo. No es realmente un widget reactivo — es un panel estático con un CTA.

Decisiones de UX

Decisión	Motivo
Sin fetch, solo link estático	El widget no consulta nada — solo redirige a /docs. Mantenerlo “siempre disponible” con pill verde fija.
CTA full-width al pie	”Abrir documentación” como botón primario que toma todo el ancho — claridad de la acción única.
Lista de qué se resuelve	3 bullets (“Guías de uso”, “Procedimientos”, “Referencias”) explican el alcance antes de hacer click.

Endpoint

Ruta	Uso
/docs (link relativo)	Manual operativo embebido en la app. Sirve el sitio público en producción.

Hooks compartidos

Ninguno de los tres widgets usa useActiveTenant ni useActivePeriod — operan al nivel del usuario y la plataforma, no del tenant contable.

Backend de referencia

• DailyBriefingWidget → /api/agent/tasks en el Orchestrator, que lee nostromo_cortex.tasks de Mongo.
• SystemStatusWidget → MonitoringService — mismo endpoint que la island completa de Monitoring, pero el widget consume solo dos campos.

Relación con otros dominios

• Command (Monitoring) comparte el endpoint /api/monitoring. El widget es el resumen; la island es el detalle.
• Nostromo alimenta agent/tasks desde su Cortex (Mongo local).
• Auth valida la sesión en cada fetch (authenticatedFetch + handleAuthResponse).

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