Arquitectura

Implementado. Describe la topología que existe en el repositorio.

Dos mitadesCopiar enlace

navegador / apps / CLI
        │  HTTP (cookie de sesión en el BFF; Bearer en el resto)
        ▼
   servicios Bun/Elysia ──── bus NATS JetStream (órdenes, consultas, eventos)
        │ socket de control (spire)            │
        ▼                                      ▼
   styx-media-daemon (Zig) ◄── bytes de vídeo directos al cliente (HTTP/3, WebTransport, MoQT)

• Control (Bun/TypeScript). identity, catalog, playback, sources, workers y realtime, más una web (TanStack Start). Deciden permisos, planes y catálogo. Un servicio de extensiones está previsto y todavía no tiene código.
• Datos (Zig). El daemon lee ficheros bajo las raíces declaradas, empaqueta con los motores zig o libav y entrega los bytes al cliente. Los bytes de vídeo no atraviesan JavaScript ni el bus.

Reglas que verás en todas partesCopiar enlace

• Un contenedor o proceso por responsabilidad, sin modo monolito.
• Un único punto de seguridad de comunicaciones (spire, dec-0119): el bus y el socket de control comparten sobres firmados y capacidades; las políticas y la ACL de NATS salen de una tabla única de rutas (BUS_ROUTES).
• Capacidades (SCT) en vez de sesiones hacia el daemon: un token firmado, de corta vida y de un solo propósito (read, publish, ingest…), que emite playback-svc y verifica el daemon.
• El navegador no tiene tokens (dec-0118): la web habla con los servicios por ti y guarda una cookie HttpOnly.
• Contratos primero: los tipos de la API y del bus viven en @styx/api-contracts (TypeBox y JSON Schema) y de ahí salen clientes y validaciones.
• No se reimplementa lo genérico del data plane: se consume zkit, y los SDK de mensajería (spire) y de ingesta (conduit) se fijan por URL y hash (dec-0103, dec-0120, dec-0121).

Qué sigueCopiar enlace

La referencia de cada servicio, del bus y de los protocolos binarios se generará del código bajo referencia/ (propuesta de track/docs, aún sin lock).