Everythink Studio
Arquitetura Global do Sistema

Seis seções, um sistema

Da visão de produto à implementação real: backend em Rust, frontend em Next.js, implantação e roadmap.

O espaço é o roteador

Cada pessoa tem a sua própria organização pessoal e assina n organizações. Cada organização — empresa · governo · sindicato · comunidade — contém n redes; cada rede contém n comunidades; cada comunidade contém n salas. Cada nó tem o seu próprio multipolígono: a contenção corre para dentro (comunidades fragmentadas dentro do polígono da rede) ou para fora (comunidades fora do polígono). A topologia é fractal no sentido matemático: cada nível é uma cópia autossimilar do anterior — S = ⋃ fᵢ(S), o atrator do operador de Hutchinson (teorema do ponto fixo de Banach). As redes interoperam entre si (federação): uma rede conecta-se a outra compartilhando apenas o que é público. Quando uma pessoa entra em uma organização, ela ganha acesso às suas n comunidades e n salas. O trabalho que ela realiza na organização é rastreado na org e espelhado para a sua org pessoal: gera reputação por pessoa, é destilado em problemas resolvidos, e estes são copiados para a sua rede pessoal, que os rastreia. A partir das respostas acumuladas, o HAI constrói uma camada de contexto por usuário.

As quatro camadas da plataforma

Cada camada superior compõe as garantias das camadas inferiores sobre interfaces tipadas. Produtos (módulos da v1): HAI, Matchmaking, Chat, Calendar, Market, Social. Sobre as 4 camadas, 10 instanciações setoriais.

Três princípios que governam a arquitetura

Cada princípio é uma garantia verificável, não uma declaração de intenção. Juntos, estabelecem a regra de composição (ponta a ponta), a regra de multiplicação setorial (herança sem modificação) e a regra de honestidade (implementado e medido = garantia).

Motor HAI — 13 tipos de pergunta

Em produção desde 2016. Uma premissa deliberadamente estreita e combinável: uma interação é um fluxo de trabalho de perguntas tipadas, e a plataforma é uma topologia geolocalizada para que toda resposta caia em um contexto bem definido. Na v2, o motor roda em duas camadas de inferência: a rede aprendida (determinística, sem LLM) e a inferência A2A, que preenche os nós que não existem e colapsa a rede.

Calendar — vender serviços e gerenciar o calendário

Um vendedor oferece serviços (type_event) com preço, categoria e disponibilidade; clientes reservam (event) com participante, data e local. No modo white-label, qualquer vendedor da mesma rede fica visível e pode receber pedidos — "outros vendem na minha rede". O pagamento cria um merchant na rede e busca produtos por product_key.

Market — vender produtos e deixar que outros vendam na minha rede

O vendedor lista produtos (market_product) com merchant, provider e preço, e anexa a eles ofertas/cupons. O cliente monta o carrinho (market_item) e conclui a compra (merchant_tx) com a chave da rede carimbada em json_data. Disputas e avaliações em ambos os lados. Merchants ficam vinculados à rede por merchant.network — "outros vendem na minha rede".

HAI + matchmaking + chat — a rede pessoal de cada usuário

O HAI popula a rede pessoal de cada usuário ao entender o que ele procura: as redes são povoadas automaticamente a partir do site ou documento da empresa/governo/comunidade/sindicato, fluxos de perguntas são gerados, e também os elos cruzados entre matchings de salas diferentes (da mesma comunidade ou não). O matchmaking automatiza processos: uma intenção do usuário → um pedido de compra no canal de despacho da comunidade, geolocalizado na sala-alvo. Chat em tempo real sobre socket + FCM. Os fluxos são transversais (atravessam salas) e rodam nas duas camadas de inferência: a rede aprendida + A2A, que preenche e colapsa.

Social — promoções da rede e interação entre usuários

A rede executa promoções no seu espaço e os usuários interagem em um módulo social: notícias/stories com curtidas e comentários, categorias definidas pelo admin. O feed social vive na topologia — a rede publica, a comunidade fragmenta, a sala recebe.

Duas camadas de inferência — a rede neural que colapsa

Todos os módulos vivem em salas de uma rede e são transversais: um fluxo de dados (HAI) de uma sala de visitantes com pré-vendas conecta-se a um fluxo de um cliente com suporte técnico. Diferente da v1 (grafos estáticos), aqui existem redes neurais: se o nó seguinte não existe, a A2A determina os próximos passos, salva-os e a rede colapsa. O escopo é finito — o que um usuário pergunta em uma rede é salvo para todos — e o consumo de LLM via A2A diminui com o tempo, nunca cresce.

Isolamento multi-tenant verificável

Empresas, governos, ONGs e comunidades compartilham um único substrato de IA desde 2016, mantendo o que é privado provadamente privado. Mediação completa pelo Reference Monitor; o único canal permitido = escopos públicos.

Redes federadas e matchmaking estável

As redes federam-se sobre as suas projeções públicas. O matchmaking opera apenas em escopos públicos dentro de um raio de proximidade; aceitação diferida → matching estável.

Elicitação tipada — aprendizado em poucas perguntas

O sistema pergunta, o usuário responde, e a resposta vira contexto. A elicitação é tipada (o motor computa sem surpresas), fiel e eficiente. Ela roda na camada 1 (rede aprendida, determinística); quando um nó não existe, a camada 2 (A2A) determina os passos, persiste-os e a rede colapsa — aprendizado em poucas perguntas, e cada nova pergunta é salva para todos.

Fluxos de trabalho agênticos — o envelope

Alguns nós exigem trabalho aberto: um agente de LLM que intercala raciocínio com chamadas de ferramentas (estilo ReAct) até obter uma resposta do tipo correto. Esta é a camada de inferência 2 (A2A): quando o nó seguinte não existe na rede aprendida, o agente determina os próximos passos, persiste-os e a rede colapsa — o consumo de LLM diminui com o tempo, nunca cresce. O envelope limita os três modos de falha.

Assistência proativa — o valor da informação

O inverso de um chatbot reativo: ele inicia em vez de esperar. A parte difícil é a contenção — falar apenas quando o valor líquido esperado de agir excede o valor de permanecer em silêncio.

Autoridade limitada e procedência

Um agente que pode agir — gastar dinheiro, contatar terceiros, mover dados — deve estar limitado ao que o usuário consentiu, usar a informação apenas para a finalidade dada e deixar um rastro que permita explicar e desfazer.

Redes autônomas a serviço de redes humanas

Delegação limitada, alocação contract-net (anunciar → licitar → adjudicar) e o limite honesto da coordenação: vivacidade apenas com sincronia parcial.

Segurança e o protocolo de evidência

Dez instanciações setoriais

Cada implantação setorial instancia as camadas 1–4 sem modificá-las e herda as suas garantias.

Produção / projeto / projeção

17 crates, hexagonal, um Postgres

Raiz de composição (api) → use-cases ×10 → adapters (ledger, a2a, courier) → domínio (core, ZERO I/O). Um único Postgres (Timescale pg17 + pgvector) para tudo: ledger, eventos, embeddings, geo-cache de jobs/whisper. SQL verificado em tempo de compilação (cache offline .sqlx/, 107 consultas).

Ports & adapters — domínio no centro

O domínio (everythink-core) não conhece E/S. Os adapters implementam ports para DB, e-mail, A2A. Os use-cases orquestram. A raiz de composição (everythink-api) conecta tudo.

Por que tantos crates — um papel explícito por crate

Cada crate tem um papel: raiz de composição (api), cliente (sdk, cli), use-case ×10, adapter de infraestrutura (a2a, courier), ports + persistência (ledger), domínio (core).

17 crates fluem para o core

everythink-api é o hub; tudo depende do core (ZERO I/O). O SDK vive dentro do workspace (backend/crates/everythink-sdk) porque é acoplado ao core.

Da autenticação à persistência — uma requisição completa

Cliente → api (auth + rate-limit + validação) → loom (execução) → ledger (resolve o perfil via o trait de repositório) → sisters (fan-out) → oracle (merge → Ensemble normalizado) → ledger (persiste) → 200 OK.

Seis use-cases: orquestração, autenticação e dados

loom — orquestração: persiste via o port LoomStore / adapter LoomPersistence. ingest — pipeline de sinais: processa os sinais que chegam. scry — sentimento: o port de referência SentimentReader / PgSentimentReader. eval — harness de regressão: avaliação contínua. warden — autenticação: JWT access/refresh, Google OAuth, vínculo de IP. whisper — webhooks assinados com HMAC com entrega exatamente única.

Cadeia de middleware — trace → timeout → CORS → roteamento

Requisição que chega → Trace + request_id → Timeout 60s → 408 → CORS + compressão → subárvore de rotas com 5 ramos.

Três regimes de autenticação coexistem em um único router

Público (probes/register/login/refresh) · Eye-Key (HMAC, rate limit deslizante de 60s) · user-JWT (warden, Console) · Atlas WS (auto-autenticado, limites por usuário).

RBAC sem herança — uma função, uma matriz explícita

can(role, action) como const fn: Owner → true; Profile Read/Write Self → true; correspondência explícita em (role, action); o resto → somente Owner. AUTHORIZE no handler → 403 em caso de negação.

Um datastore para tudo

timescale/timescaledb-ha:pg17 + pgvector (vector(1024) + HNSW). Um pool. Seis domínios de dados: Ledger, Simulations, Users, Embeddings, geo_signals, Jobs. Health check: pg_isready no docker-compose (service_healthy).

Persistência via um port, nunca via um concreto

Repository TRAIT · Pg*Repository (todo o SQL vive aqui) · MockRepository (testes sem DB) · AppState: Arc<dyn Repository> · os use-cases chamam o TRAIT.

SQL verificado em tempo de compilação, migrações reversíveis

Edite .up.sql + .down.sql (emparelhados) → just sqlx-prepare → faça commit de .sqlx/*.json (107 consultas) → build/CI com SQLX_OFFLINE=true e sem DB ativo.

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 desativado (distroless/static). CI: SQLX_OFFLINE=true com o cache .sqlx/ commitado.

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

TideBroker: SSE com tópicos compostos, broadcast 256, keep-alive 15s, reconexão por Last-Event-ID. GeoHub: WS com DashMap[Tile → broadcast 64], direção de viewport, gzip opcional.

Seis use-cases de orquestração e dados

everythink-warden — autenticação de usuários

everythink-whisper — webhooks assinados e entrega durável

A2A (protocolo) e Courier (e-mail)

everythink-cli e everythink-sdk

Seis invariantes que nunca são violados

4 apps, 13 pacotes, uma identidade

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

Quatro superfícies, um backend, três atores

Atores: usuário final (guest → autenticado) · desenvolvedor (Eye-Key) · admin/operador (staff). Superfícies: web/app/admin/mobile. API do backend (REST + SSE sob /api/v1).

Containers — o monorepo completo

4 apps + camada SDK (6 facades) + serviços (4) + design system + tooling + types (folha). Use o zoom para explorar.

web, app, admin, mobile — um por público

Seis facades, um core, zero endpoints no core

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

Serviços de aplicação, UI e tempo de build

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

sdk-core sabe o COMO, nunca o QUÊ

Os endpoints vivem SOMENTE nas facades; o sdk-core valida toda resposta com Zod contra @everythink/types; uma árvore de SdkError com ContractViolation em caso de drift.

Feature-Sliced Design + MVVM — os imports fluem para baixo

Screen (View) → hook de view-model → feature.repository.ts (A única porta para o SDK). Regra de fronteira ESLint no-restricted-imports (INV-1). Camadas FSD: shared → entities → features → widgets → app.

Um login, uma origem, quatro superfícies

apps/web /auth (uma origem) → cookie httpOnly 'everythink_at' → token em memória + semente no localStorage → EverythinkAuthGuard + resolveMe (GET /api/v1/auth/me) → gate por papel (role).

can(role, action) — matriz explícita, sem herança

3 camadas: (1) auth.ts allowedRoles por app → (2) middleware → (3) can() na UI + server actions. Espelha everythink_core::rbac do backend.

Uma folha de estilos, tokens semânticos, Tailwind v4

Uma única fonte da verdade para o design: tokens CSS em :root, mapeamento semântico via @theme (Tailwind v4) e NativeWind para o mobile com tokens espelhados. Os apps consomem componentes semânticos (bg-accent, text-foreground, font-display/mono), nunca hexes brutos. Paleta cosmic-purple: --gold: #d9ab5c, --violet: #9d7df5, --emerald: #10B981.

Zod na fronteira de rede — um único contrato

Os tipos de rede são definidos uma única vez em @everythink/types com Zod. O SDK valida toda resposta do backend (z.parse(response)); um payload inválido lança ApiError, nunca um crash. Os componentes nunca veem JSON bruto: *.repository.ts faz o parse, @everythink/domain mapeia DTO → model, e o view-model expõe estado tipado para a View.

apps/mobile — Expo, expo-router, NativeWind

React Native com expo-router (roteamento baseado em arquivos) e NativeWind (Tailwind para RN). O sistema de tema espelha os tokens do design system web (tailwind.config.js + src/theme/index.ts). Ele consome sdk-guest, sdk-auth, sdk-atlas, domain e telemetry. Excluído do CI web: --filter=!@everythink/mobile.

Quatro regras aplicadas mecanicamente

Regras verificáveis por ESLint + TypeScript, não convenções: (1) INV-1: somente *.repository.ts importa um SDK (no-restricted-imports); (2) Camadas FSD: os imports fluem PARA BAIXO (shared → entities → features → widgets → app), consumo entre features somente via o barrel público; (3) Login compartilhado: web + app compartilham localStorage('everythink:auth') + resolveMe(); (4) RBAC de 3 camadas: auth.ts allowedRoles → middleware → can(role, action) na UI + server actions.

docker-compose.prod.yml — a stack completa

ALB (TLS) → nginx :80 → api (:18081, migrações na inicialização) · web (Next standalone) · app/admin (estático distroless) · postgres (timescale/timescaledb-ha:pg17 + pgvector) · dragonfly (compatível com Redis). 7 serviços: postgres · dragonfly · api · web · app · admin · nginx.

nginx como ponto de entrada único

nginx :80 é o único ponto de entrada interno. Ele roteia /api/v1/* → api:18081, / → web:3000, /app/* → estático, /admin/* → estático. O web fala com o api via EVERYTHINK_API_INTERNAL_URL (http://api:18081). O api depende do postgres e do dragonfly com condition: service_healthy.

backend/.env — o único lugar para segredos

O docker-compose.prod.yml monta backend/.env via env_file nos serviços api e web. O api detém todos os segredos (JWT_SECRET, EYE_KEY_HMAC_SECRET, GOOGLE_CLIENT_ID, BREVO_API_KEY). O web recebe apenas variáveis NEXT_PUBLIC_* — ele nunca detém a BREVO_API_KEY. app/admin são estáticos distroless, sem segredos no build.

Preprod direto vs o gate de CI/CD

Dois caminhos de deploy: o preprod faz deploy diretamente da árvore de trabalho (sem passar pelo main); o prod exige um merge no main e o gate de integridade. A regra é crítica: NÃO use o workflow de deploy para o preprod, porque ele puxa a :latest do main e sobrescreve o deploy direto.

affected nos PRs, integridade no main

Um pipeline de 2 níveis: o nível de PR roda apenas o que é afetado (backend: ci-affected-crates.sh; frontend: turbo --affected), o nível de main roda a integridade completa (backend completo + frontend/mobile + E2E + segurança). O main permanece verde e implantável.

Nós self-hosted federados · BYOK · DAO por rede

Direção do roadmap para a v2. Nada do que segue é uma capacidade existente. Fluxo: o operador gera um par Ed25519 local → somente o fingerprint vai para o controller (BYOK) → nó self-hosted → ancoragem do ledger → federação apenas sobre projeções públicas → DAO da rede.

Cinco fases rumo à v2

Arquitetura de referência da chain candidata

Referência de arquitetura para notarizar compromissos de hash do ledger Postgres: Solana v0.8.13 (Yakovenko) — PoH como um relógio criptográfico, consenso PoS com bonds/slashing, PoRep para armazenamento. A escolha da chain é uma decisão explícita do operador; isto é uma referência, não uma implementação.