Arquitectura

Owner: maintainers de LEMN UI Decision: 2026-07-17

Decision

LEMN expone una superficie UI neutral formada por capacidades open source battle-tested seleccionadas individualmente. El proveedor de registro conserva el comportamiento funcional. LEMN posee API publica, adaptador semantico, catalogos/blocks, provenance, conformance y release.

La fuente es BrandingDefinition v1. Publicacion guarda el objeto compilado completo e inmutable en R2 privado y firma una proyeccion minima por cada mode permitido. Runtime entrega solo la proyeccion verificada del mode seleccionado. Los componentes no parsean el JSON fuente.

Responsabilidades

Limite	Posee	No posee
@lemn-ltd/brand-contract	Schema, validation, compiler, diagnostics, artefacto privado y contratos de proyeccion firmada, tokens, provider themes	Persistence, auth, publicacion, seleccion activa
@lemn-ltd/brand-runtime	Adapters server, verificacion, proyeccion, SSR, fallback embedded	Browser resolution, cookies, routing, authoring, credenciales
@lemn-ltd/ui	Components, charts, styles, blocks, catalogs	APIs producto, auth, routing, estado global, JSON fuente
@lemn-ltd/brand-studio	Wizard/preview controlado e intents	Fetching, secrets, persistence, autoridad de publicacion
Provider registry	Un provider por capacidad, origen/licencia/conformance	Estado runtime o auto-update
UI Portal	Evidencia publica de catalogo y experimentos/proposals protegidos por Access en un deploy	Estado durable, activacion o deploy desde browser
AgentOps	Workspaces, BrandingVersions, Postgres, R2, publicacion, activacion, previews, MCP, audit	Forks UI o del contrato
Product host	Datos/plataforma, identidad Workspace, SSR, props/actions	Forks compartidos o imports upstream

registry + providers -> @lemn-ltd/ui
@lemn-ltd/brand-contract -> full object -> R2 privado
                         -> signed mode projections -> AgentOps runtime
@lemn-ltd/brand-studio -> typed intents --------------^
@lemn-ltd/brand-runtime <- un mode para el SSR consumer

Postgres es autoridad de estado; R2 privado almacena objetos completos content-addressed y sus proyecciones minimas firmadas; caches por hash solo aceleran. Un Workspace tiene un Branding y multiples BrandingVersions. Solo un humano activa una version publicada. Light/dark son modes completos de la misma identidad, no familias de branding.

Plataforma frontend permanece fuera del contrato visual y los consumidores usan versiones publicadas exactas, nunca workspace links en produccion.

Transporte runtime e identidad de workload

Los consumidores Cloudflare de la misma cuenta usan RPC Service Binding hacia un WorkerEntrypoint dedicado de Branding Runtime. El deployment fija ctx.props inmutables con workspaceId, consumerId y el permiso branding:resolve. El binding solo expone resolveBranding, exchangeBrandingPreview y resolveBrandingPreview; no es un Fetcher HTTP anonimo y sus inputs no eligen tenant ni llevan credenciales runtime reusables.

Los servers externos usan HTTPS autenticado y guardan un WorkspaceRuntimeCredential least-privilege solo en secrets/configuracion del server. Nunca se serializa en HTML, bootstrap, URLs, logs ni storage del browser. La ubicacion de red y el Service Binding no bastan como autorizacion: runtime valida el grant estatico del workload en cada llamada RPC.