Everythink Studio
Arquitectura Global del Sistema

Seis secciones, un sistema

De la visión de producto a la implementación real: backend en Rust, frontend en Next.js, despliegue y hoja de ruta.

El espacio es el router

Cada persona tiene su propia organización personal y se suscribe a n organizaciones. Cada organización — empresa · gobierno · sindicato · comunidad — contiene n redes; cada red contiene n comunidades; cada comunidad contiene n salas. Cada nodo tiene su propio multipolígono: la contención corre hacia adentro (comunidades fragmentadas dentro del polígono de la red) o hacia afuera (comunidades fuera del polígono). La topología es fractal en el sentido matemático: cada nivel es una copia autosimilar del anterior — S = ⋃ fᵢ(S), el atractor del operador de Hutchinson (teorema del punto fijo de Banach). Las redes interoperan entre sí (federación): una red se conecta a otra compartiendo solo lo público. Cuando una persona se une a una organización, gana acceso a sus n comunidades y n salas. El trabajo que realiza en la organización se registra en la org y se refleja en su organización personal: genera reputación por persona, se destila en problemas resueltos, y estos se copian a su red personal, que les hace seguimiento. A partir de las respuestas acumuladas, HAI construye una capa de contexto por usuario.

Las cuatro capas de la plataforma

Cada capa superior compone las garantías de las capas inferiores sobre interfaces tipadas. Productos (módulos v1): HAI, Matchmaking, Chat, Calendario, Mercado, Social. Sobre las 4 capas, 10 instanciaciones sectoriales.

Tres principios que gobiernan la arquitectura

Cada principio es una garantía verificable, no una declaración de intenciones. Juntos establecen la regla de composición (extremo a extremo), la regla de multiplicación sectorial (herencia sin modificación) y la regla de honestidad (implementado y medido = garantía).

Motor HAI — 13 tipos de pregunta

En producción desde 2016. Una premisa deliberadamente estrecha y componible: una interacción es un flujo de preguntas tipadas, y la plataforma es una topología geolocalizada para que cada respuesta caiga en un contexto bien definido. En v2 el motor corre sobre dos capas de inferencia: la red aprendida (determinista, sin LLM) y la inferencia A2A, que rellena los nodos que no existen y colapsa la red.

Calendario — vender servicios y gestionar la agenda

Un vendedor ofrece servicios (type_event) con precio, categoría y disponibilidad; los clientes reservan (event) con asistente, fecha y ubicación. En modo marca blanca, cualquier vendedor de la misma red es visible y ordenable — "otros venden en mi red". El pago crea un merchant en la red y busca productos por product_key.

Market — vender productos y dejar que otros vendan en mi red

El vendedor publica productos (market_product) con merchant, proveedor y precio, y les adjunta ofertas/cupones. El cliente arma el carrito (market_item) y paga (merchant_tx) con la clave de red estampada en json_data. Disputas y calificaciones en ambos lados. Los merchants quedan ligados a la red por merchant.network — "otros venden en mi red".

HAI + matchmaking + chat — la red personal de cada usuario

HAI llena la red personal de cada usuario entendiendo lo que busca: las redes se pueblan automáticamente desde el sitio web o documento de la empresa/gobierno/comunidad/sindicato, se generan los flujos de pregunta y también los enlaces cruzados entre matchings de distintas salas (de la misma o de distinta comunidad). El matchmaking automatiza procesos: una intención del usuario → una orden de compra en el canal de despacho de la comunidad, geolocalizada en la sala destino. Chat en tiempo real sobre socket + FCM. Los flujos son transversales (cruzan salas) y corren sobre las dos capas de inferencia: la red aprendida + A2A, que rellena y colapsa.

Social — promociones de la red e interacción de usuarios

La red corre promociones en su espacio y los usuarios interactúan en un módulo social: noticias/stories con likes y comentarios, categorías definidas por el admin. El feed social vive en la topología — la red publica, la comunidad fragmenta, la sala recibe.

Dos capas de inferencia — la red neuronal que colapsa

Todos los módulos viven en salas de una red y son transversales: un dataflow (HAI) desde una sala de pre-venta se conecta con el de un cliente con soporte técnico. A diferencia de v1 (grafos estáticos), aquí hay redes neuronales: si el nodo siguiente no existe, A2A determina los pasos siguientes, los guarda, y la red colapsa. El alcance es finito — lo que un usuario pregunta en una red se guarda para todos — y el consumo de LLM vía A2A disminuye con el tiempo, nunca crece.

Aislamiento multi-tenant verificable

Empresas, gobiernos, ONG y comunidades comparten un único sustrato de IA desde 2016, manteniendo lo privado demostrablemente privado. Mediación total por el Reference Monitor; el único canal permitido = los ámbitos públicos.

Redes federadas y matchmaking estable

Las redes federan sobre sus proyecciones públicas. El matchmaking opera solo en ámbitos públicos dentro de un radio de proximidad; aceptación diferida → matching estable.

Elicitación tipada — aprender en pocas preguntas

El sistema pregunta, el usuario responde, y la respuesta se vuelve contexto. La elicitación es tipada (el motor computa sin sorpresas), fiel y eficiente. Corre sobre la capa 1 (red aprendida, determinista); cuando un nodo no existe, la capa 2 (A2A) determina los pasos, los persiste y la red colapsa — aprender en pocas preguntas, y cada pregunta nueva queda guardada para todos.

Flujos agénticos — el sobre

Algunos nodos exigen trabajo abierto: un agente LLM que intercala razonamiento con llamadas a herramientas (estilo ReAct) hasta obtener una respuesta del tipo correcto. Esto es la capa de inferencia 2 (A2A): cuando el nodo siguiente no existe en la red aprendida, el agente determina los pasos, los persiste y la red colapsa — el consumo de LLM disminuye con el tiempo, nunca crece. El sobre acota los tres modos de falla.

Asistencia proactiva — el valor de la información

Lo inverso a un chatbot reactivo: inicia en lugar de esperar. Lo difícil es la contención — hablar solo cuando el valor neto esperado de actuar supera el valor de guardar silencio.

Autoridad acotada y procedencia

Un agente que puede actuar — gastar dinero, contactar terceros, mover datos — debe estar acotado por lo que el usuario consintió, usar la información solo para el fin dado, y dejar un rastro que permita explicar y deshacer.

Redes autónomas al servicio de las redes humanas

Delegación acotada, asignación contract-net (announce → bid → award), y el límite honesto de la coordinación: liveness solo con sincronía parcial.

Seguridad y el protocolo de evidencia

Diez instanciaciones sectoriales

Cada despliegue sectorial instancia las capas 1–4 sin modificarlas y hereda sus garantías.

Producción / diseño / proyectado

17 crates, hexagonal, un solo Postgres

Raíz de composición (api) → casos de uso ×10 → adaptadores (ledger, a2a, courier) → dominio (core, ZERO I/O). Un único Postgres (Timescale pg17 + pgvector) para todo: ledger, eventos, embeddings, geo-cache de jobs/whisper. SQL verificado en tiempo de compilación (caché offline .sqlx/, 107 consultas).

Puertos & adaptadores — el dominio al centro

El dominio (everythink-core) no conoce I/O. Los adaptadores implementan los puertos para DB, email, A2A. Los casos de uso orquestan. La raíz de composición (everythink-api) conecta todo.

Por qué tantos crates — un rol explícito por crate

Cada crate tiene un rol: raíz de composición (api), clientes (sdk, cli), caso de uso ×10, adaptador de infra (a2a, courier), puertos + persistencia (ledger), dominio (core).

17 crates confluyen en core

everythink-api es el hub; todo depende de core (ZERO I/O). El SDK vive dentro del workspace (backend/crates/everythink-sdk) porque está acoplado a core.

De la autenticación a la persistencia — una petición completa

Cliente → api (auth + rate-limit + validate) → loom (ejecutar) → ledger (resolver perfil vía el trait de repositorio) → sisters (fan out) → oracle (merge → Ensemble normalizado) → ledger (persistir) → 200 OK.

Seis casos de uso: orquestación, autenticación y datos

loom — orquestación: persiste vía el puerto LoomStore / adaptador LoomPersistence. ingest — pipeline de señales: procesa las señales entrantes. scry — sentimiento: el puerto de referencia SentimentReader / PgSentimentReader. eval — arnés de regresión: evaluación continua. warden — auth: JWT access/refresh, Google OAuth, IP-binding. whisper — webhooks firmados con HMAC y entrega exactamente una vez.

Cadena de middleware — trace → timeout → CORS → routing

Petición entrante → Trace + request_id → Timeout 60s → 408 → CORS + compresión → subárbol de rutas con 5 ramas.

Tres regímenes de autenticación coexisten en un router

Público (probes/register/login/refresh) · Eye-Key (HMAC, rate limit deslizante de 60s) · JWT de usuario (warden, Consola) · Atlas WS (autenticación propia, topes por usuario).

RBAC sin herencia — una función, una matriz explícita

can(role, action) como const fn: Owner → true; Profile Read/Write Self → true; match explícito en (role, action); el resto → solo Owner. AUTHORIZE en el handler → 403 ante una denegación.

Un almacén de datos para todo

timescale/timescaledb-ha:pg17 + pgvector (vector(1024) + HNSW). Un solo pool. Seis dominios de datos: Ledger, Simulaciones, Usuarios, Embeddings, geo_signals, Jobs. Health check: pg_isready en docker-compose (service_healthy).

Persistencia vía un puerto, nunca vía un concreto

TRAIT de repositorio · Pg*Repository (todo el SQL vive aquí) · MockRepository (tests sin DB) · AppState: Arc<dyn Repository> · los casos de uso llaman al TRAIT.

SQL verificado en tiempo de compilación, migraciones reversibles

Editar .up.sql + .down.sql (en pares) → just sqlx-prepare → hacer commit de .sqlx/*.json (107 consultas) → build/CI con SQLX_OFFLINE=true y sin DB viva.

Health checks + SQLX offline — deploys precisos

docker-compose: postgres (pg_isready, 10s/5s/10) → dragonfly (redis-cli ping, 10s/3s/10) → api (service_healthy). app/admin: health check deshabilitado (distroless/static). CI: SQLX_OFFLINE=true con la caché .sqlx/ versionada en el repo.

SSE (Tide) + WebSocket (GeoHub) — fan-out por tile

TideBroker: SSE con tópicos compuestos, broadcast 256, keep-alive 15s, reconexión con Last-Event-ID. GeoHub: WS con DashMap[Tile → broadcast 64], guiado por viewport, gzip opt-in.

Seis casos de uso de orquestación y datos

everythink-warden — autenticación de usuarios

everythink-whisper — webhooks firmados y entrega durable

A2A (protocolo) y Courier (email)

everythink-cli y everythink-sdk

Seis invariantes que jamás se violan

4 apps, 13 paquetes, una identidad

web (:3000) · app (:3001) · admin (:3002) · mobile (Expo). Paquetes: types, sdk-core + facades, domain, ui, auth, api-client, telemetry, config.

Cuatro superficies, un backend, tres actores

Actores: usuario final (invitado → autenticado) · developer (Eye-Key) · admin/operador (staff). Superficies: web/app/admin/mobile. API del backend (REST + SSE bajo /api/v1).

Contenedores — el monorepo completo

4 apps + capa SDK (6 facades) + servicios (4) + sistema de diseño + tooling + types (hoja). Usa el zoom para explorar.

web, app, admin, mobile — una por audiencia

Seis facades, un core, cero endpoints en el core

sdk-core (HttpClient, consumeSSE, TokenProvider) · sdk-guest · sdk-auth · sdk-atlas · sdk-eye · sdk-admin.

Servicios de aplicación, UI y build

domain (mappers) · telemetry (outbox) · api-client (legacy) · auth (NextAuth v5 + RBAC) · ui (kit + tokens) · config (presets eslint) · types (Zod, hoja).

sdk-core sabe CÓMO, nunca QUÉ

Los endpoints viven SOLO en las facades; sdk-core valida cada respuesta con Zod contra @everythink/types; un árbol SdkError con ContractViolation ante drift.

Feature-Sliced Design + MVVM — los imports fluyen hacia abajo

Screen (View) → hook view-model → feature.repository.ts (LA única puerta al SDK). Borde ESLint no-restricted-imports (INV-1). Capas FSD: shared → entities → features → widgets → app.

Un login, un origen, cuatro superficies

apps/web /auth (un origen) → cookie httpOnly 'everythink_at' → token en memoria + semilla en localStorage → EverythinkAuthGuard + resolveMe (GET /api/v1/auth/me) → puerta según rol.

can(role, action) — matriz explícita, sin herencia

3 capas: (1) allowedRoles en el auth.ts de cada app → (2) middleware → (3) can() en la UI + server actions. Refleja everythink_core::rbac del backend.

Una hoja de estilos, tokens semánticos, Tailwind v4

Una única fuente de verdad del diseño: tokens CSS en :root, mapeo semántico vía @theme (Tailwind v4) y NativeWind para mobile con tokens espejados. Las apps consumen componentes semánticos (bg-accent, text-foreground, font-display/mono), jamás hexes crudos. Paleta cosmic-purple: --gold: #d9ab5c, --violet: #9d7df5, --emerald: #10B981.

Zod en el borde de la red — un único contrato

Los tipos del wire se definen una única vez en @everythink/types con Zod. El SDK valida cada respuesta del backend (z.parse(response)); un payload inválido lanza ApiError, jamás un crash. Los componentes jamás ven JSON crudo: *.repository.ts parsea, @everythink/domain mapea DTO → modelo, y el view-model expone estado tipado a la View.

apps/mobile — Expo, expo-router, NativeWind

React Native con expo-router (enrutamiento basado en archivos) y NativeWind (Tailwind para RN). El sistema de temas espeja los tokens del sistema de diseño web (tailwind.config.js + src/theme/index.ts). Consume sdk-guest, sdk-auth, sdk-atlas, domain y telemetry. Excluida del CI web: --filter=!@everythink/mobile.

Cuatro reglas aplicadas mecánicamente

Reglas verificables por ESLint + TypeScript, no convenciones: (1) INV-1: solo *.repository.ts importa un SDK (no-restricted-imports); (2) capas FSD: los imports fluyen hacia ABAJO (shared → entities → features → widgets → app), entre features solo vía el barrel público; (3) Inicio de sesión compartido: web + app comparten localStorage('everythink:auth') + resolveMe(); (4) RBAC de 3 capas: allowedRoles en auth.ts → middleware → can(role, action) en la UI + server actions.

docker-compose.prod.yml — el stack completo

ALB (TLS) → nginx :80 → api (:18081, migraciones al arrancar) · web (Next standalone) · app/admin (estáticos distroless) · postgres (timescale/timescaledb-ha:pg17 + pgvector) · dragonfly (compatible con Redis). 7 servicios: postgres · dragonfly · api · web · app · admin · nginx.

nginx como único punto de entrada

nginx :80 es el único punto de entrada interno. Enruta /api/v1/* → api:18081, / → web:3000, /app/* → estáticos, /admin/* → estáticos. web habla con api vía EVERYTHINK_API_INTERNAL_URL (http://api:18081). api depende de postgres y dragonfly con condition: service_healthy.

backend/.env — el único lugar para secretos

docker-compose.prod.yml monta backend/.env vía env_file en los servicios api y web. api contiene todos los secretos (JWT_SECRET, EYE_KEY_HMAC_SECRET, GOOGLE_CLIENT_ID, BREVO_API_KEY). web solo recibe variables NEXT_PUBLIC_* — jamás contiene BREVO_API_KEY. app/admin son estáticos distroless sin secretos en el build.

Preprod directo vs la puerta CI/CD

Dos caminos de deploy: preprod despliega directo desde el árbol de trabajo (sin pasar por main); prod exige merge a main y la puerta de integridad. La regla es crítica: NO uses el workflow deploy para preprod, porque trae el :latest de main y sobrescribe el deploy directo.

affected en los PR, integridad en main

Un pipeline de 2 niveles: el nivel de PR corre solo lo afectado (backend: ci-affected-crates.sh; frontend: turbo --affected), el nivel de main corre la integridad completa (backend + frontend/mobile completos + E2E + seguridad). main se mantiene verde y desplegable.

Nodos self-hosted federados · BYOK · DAO por red

Dirección de hoja de ruta para v2. Nada de lo siguiente es una capacidad existente. Flujo: el operador genera un par Ed25519 local → solo el fingerprint va al controlador (BYOK) → nodo self-hosted → anclaje del ledger → federación solo sobre proyecciones públicas → DAO de la red.

Cinco fases hacia v2

Arquitectura de referencia de la chain candidata

Arquitectura de referencia para notarizar compromisos de hash del ledger de Postgres: Solana v0.8.13 (Yakovenko) — PoH como reloj criptográfico, consenso PoS con bonds/slashing, PoRep para almacenamiento. La elección de chain es una decisión explícita del operador; esto es una referencia, no una implementación.