FACTORY ZERO

TECNOLOGÍA / CÓDIGO ABIERTO

Piezas ordinarias. Ensambladas una vez.

Todo venture necesita un backend, y ninguno debería construir uno. Las piezas que una empresa necesita para existir se escriben una sola vez, como un harness de código abierto en Rust. Un venture elige los módulos que quiere, los conecta en un solo archivo y se despliega como un único worker sin estado con su propia base de datos.

GITHUB.COM/CRATEFIELD/HARNESS →

La fábrica en números

ventures
2317 validación · 1 prototipo · 5 lanzamiento
en el stack
17de 23 ventures, las partes compartidas
código abierto
118 MIT · 3 Apache-2.0
se ejecutan sobre el harness
1818 activos hoy · 1 planificado
registros de decisión
30en el repositorio del harness

CÓMO SE CONSTRUYE UN VENTURE

Un archivo nombra a la empresa.

El backend de una venture es un proyecto pequeño en Rust. Enumera los módulos que usa, los Adapters que los conectan con el mundo y el nombre y el dominio propios de la venture. Todo lo demás es el harness. Lo compilas y el resultado es un Worker que contiene exactamente esos módulos y nada más.

Si un módulo necesita algo que el runtime no puede ofrecer, o dos módulos reclaman la misma tabla, la compilación falla antes de desplegar nada. Un venture mal configurado no puede llegar a producción.

Harness::builder() .venture(Venture::new("factory0", "factory0.ventures") .cors_origins(["https://factory0.ventures"])) .module(EmailSignup::new().double_opt_in(true)) .module(Waitlist::new() .products(["kontinuum", "undercover-rockstars"])) .runtime(Cloudflare::new() .db("DB") .mailer(Resend::from_env()) .captcha(Turnstile::from_env())) .build()?
  1. Paso 1

    Ponle nombre

    La venture, su dominio, sus módulos y los Adapters que responden por ellos. Un archivo.

  2. Paso 2

    Compónlo

    La compilación rechaza un módulo cuyo Port no ofrece el runtime, y dos módulos que reclaman la misma tabla o ruta.

  3. Paso 3

    Despliégalo

    Un Worker sin estado que contiene exactamente los módulos enumerados, con su propia base de datos, secretos y dominio.

LAS CAPAS

Seis capas, desde el runtime hasta los productos.

Léelo de abajo arriba: dónde se ejecuta el código, el harness desde el que se compila cada backend, los backends, los productos compartidos, los agentes que dirigen la empresa y las ventures independientes. Las fichas sólidas están activas hoy, las fichas con contorno están en el harness y las fichas discontinuas están planificadas.

01RUNTIME

Cloudflare Workers, compilados a WebAssembly

Donde se ejecuta cada Worker de venture. Los datos y el correo están a su lado, y el mismo código puede ejecutarse en un servidor.

Workers (wasm32)Base de datos D1Correo de ResendKVTurnstileLimitación de tasaPostgres, runtime nativo
02HARNESS

Cratefield: el núcleo de código abierto en Rust

Los Ports, el router y los módulos. Un módulo pide un Port; un Adapter responde.

Cratefield

Ports

DatabaseMailerCaptchaRateLimiterKeyValueSigner

Módulos

email-signuplista de espera
03BACKENDS

Un Worker y una base de datos por venture

Cada venture se compone a partir del harness y se despliega por su cuenta. Activas hoy en el harness:

ColonizerFindsYou.workSupportGeniuspromptdecodeGroove GuruPosPluginKeep ShippingOwlpostBloodrankratecla.imSealbinrelease.showLiving BrainShoalTokkerLedgersGhostwritin'SqueezinYoginini
04ESTANTES

El stack: productos a los que se conecta cada venture

Los productos compartidos, ordenados en estantes según lo que hacen. Cada uno es una empresa con sus propios clientes.

Entregar y operar

  • VibeCaddie
  • Keep Shipping
  • release.show
  • Shoal

Comunicación

  • Owlpost
  • Squeezin

Seguridad

  • promptdecode
  • Sealbin

Clientes

  • SupportGenius
  • PosPlugin
  • Ledgers

Contenido e IA

  • Kontinuum
  • Living Brain
  • Tokker
  • Ghostwritin'
05AGENTES

Cinco capas, un agente para cada función

Cada función de cada capa es un agente. Colonizer ejecuta los agentes de programación de la capa de construcción.

  • DESCUBRIR3 agentes
  • CONSTRUIR4 agentes
  • OPERAR4 agentes
  • DISTRIBUIR3 agentes
  • APRENDER3 agentes

Colonizer: agentes de programación que convierten issues de GitHub en pull requests

06PRODUCTOS

Las ventures independientes

Ventures fuera del stack. Heredan la fundación y no aportan a ella.

Undercover RockstarsYogininiFindsYou.workGroove GuruBloodrankratecla.im

Las seis capas, de abajo arriba

  1. runtime: Cloudflare Workers, compilado a WebAssembly. Donde se ejecuta cada Worker de venture. Los datos y el correo están a su lado, y el mismo código puede ejecutarse en un servidor.
  2. harness: Cratefield: el núcleo de código abierto en Rust. Los Ports, el router y los módulos. Un módulo pide un Port; un Adapter responde.
  3. backends: Un Worker y una base de datos por venture. Cada venture se compone a partir del harness y se despliega por su cuenta. Activas hoy en el harness:
  4. estantes: El stack: productos a los que se conecta cada venture. Los productos compartidos, ordenados en estantes según lo que hacen. Cada uno es una empresa con sus propios clientes.
  5. agentes: Cinco capas, un agente para cada función. Cada función de cada capa es un agente. Colonizer ejecuta los agentes de programación de la capa de construcción.
  6. productos: Las ventures independientes. Ventures fuera del stack. Heredan la fundación y no aportan a ella.

UNA SOLICITUD, DE PUNTA A PUNTA

Quién hace qué cuando un visitante se registra.

Dibujado solo a partir de los enlaces del registro. Una línea continua está activa hoy y transporta tráfico; una línea discontinua está planificada y aún no transporta ninguno.

  1. Visitante

    una persona en el sitio de una venture

  2. Worker de la venture

    un Worker por venture, sobre el harness de Cratefield

    activo

  3. Owlpost

    correo para los ventures

    activo

  4. SupportGenius

    reportes de errores y soporte

    planificado

  5. Colonizer

    agentes de programación, sobre el harness

    activo

  6. Living Brain

    conocimiento que conserva lo que funcionó

    planificado

Los enlaces de este flujo: visitante al worker del venture, solicitud HTTPS: activo. Worker del venture a Owlpost, correo de confirmación: activo. Worker del venture a SupportGenius, los errores se convierten en issues: planificado. SupportGenius a Living Brain, el soporte alimenta el conocimiento: planificado. Colonizer a Living Brain, los agentes alimentan el conocimiento: activo.

Registrarse en una venture y a dónde va el mensaje después. Las flechas muestran la dirección de cada enlace; el estado es el del registro.

LOS MÓDULOS SOLO VEN PORTS

Ports de un lado. Adapters del otro.

Un módulo pide un Port y nunca un proveedor. El runtime responde a través de un Adapter. Los Adapters son propios del harness; el estado indica dónde los usa hoy una venture activa.

  • Database

    tablas, consultas y migraciones

    • D1 (activo)
    • Postgres (en el harness)
    • SQLite (en el harness)

  • Mailer

    correo transaccional

    • Resend (activo)
    • Owlpost (planificado)

  • Captcha

    una verificación de bots, que falla en cerrado

    • Turnstile (en el harness)

  • KeyValue

    estado clave-valor pequeño

    • Cloudflare KV (en el harness)

  • RateLimiter

    presupuestos de solicitudes por clave

    • Cloudflare Rate Limiting (en el harness)
    • Redis (en el harness)

  • Payments

    checkout y facturación

    • Polar (planificado)
    • Stripe (en el harness)

  • TextModel

    una respuesta de un modelo

    • Anthropic (en el harness)
    • Compatible con OpenAI (en el harness)

  • Push

    avisos a dispositivos

    • APNs (en el harness)
    • FCM (en el harness)
    • Web Push (en el harness)

  • Signer

    firma por referencia de clave

    • Turnkey (en el harness)

Ports y sus Adapters: Database (tablas, consultas y migraciones): D1 (activo), Postgres (en el harness), SQLite (en el harness). Mailer (correo transaccional): Resend (activo), Owlpost (planificado). Captcha (una verificación de bots, que falla en cerrado): Turnstile (en el harness). KeyValue (estado clave-valor pequeño): Cloudflare KV (en el harness). RateLimiter (presupuestos de solicitudes por clave): Cloudflare Rate Limiting (en el harness), Redis (en el harness). Payments (checkout y facturación): Polar (planificado), Stripe (en el harness). TextModel (una respuesta de un modelo): Anthropic (en el harness), compatible con OpenAI (en el harness). Push (avisos a dispositivos): APNs (en el harness), FCM (en el harness), Web Push (en el harness). Signer (firma por referencia de clave): Turnkey (en el harness).

REGLAS DE DISEÑO

Cuatro reglas que mantiene el diseño.

  • 01

    Los módulos solo ven puertos.

    Un módulo pide una base de datos, un servicio de correo, un captcha. Nunca toca un binding de Cloudflare ni un cliente de proveedor. Responden los adaptadores. Esa única regla es lo que hace que el cambio posterior fuera de Cloudflare sea cuestión de un solo crate.

    móduloMailerAdapter

  • 02

    La composición ocurre en tiempo de compilación.

    Sin carga de plugins, sin servicio de registro, sin sorpresas en tiempo de ejecución. El Worker contiene lo que la venture enumeró, y el compilador es el primer revisor. Un módulo cuyo código fuente no deba entrar en la compilación compartida puede ejecutarse como su propio Worker, montado en la misma ruta mediante un service binding. Sigue estando compuesto, solo que no en el mismo binario.

    compilarrechazardesplegar

  • 03

    Un venture, una base de datos.

    No se comparte nada en tiempo de ejecución entre empresas. Cada una tiene su propio worker, sus propios datos y sus propios secretos. Un venture se puede respaldar, mover o cerrar sin tocar a otro.

    Workerbase de datossecretos
    Workerbase de datossecretos
    Workerbase de datossecretos

    ningún runtime compartido

  • 04

    Sin estado por construcción.

    Nada sobrevive a una petición salvo lo que se escribe en la base de datos. Los enlaces de confirmación y de baja son tokens firmados, así que no hay almacén de sesiones que ejecutar, escalar o filtrar.

    solicitudWorkerbase de datos

    sin almacén de sesiones

ESTADO

Dónde está el harness.

El progreso se sigue como issues e hitos, de forma abierta.

  1. M0hecho

    Fundación

    Herramientas del workspace, el núcleo, el runtime de Cloudflare, los Adapters de Resend y Turnstile, el Adapter de SQLite, la CLI fz y el kit de pruebas.

  2. M1hecho

    Primeros módulos

    Registro por correo, lista de espera, plantillas, la base de seguridad y la observabilidad.

  3. M2en curso

    Primera venture activa

    Publicación en crates.io, documentación, versionado de contratos y la primera venture en su propio dominio de API.

  4. M3hecho

    Portabilidad autoalojada

    El Adapter de Postgres, el runtime nativo, una suite de paridad sobre SQLite y Postgres, y la exportación e importación de datos.

DISEÑO
30 registros de decisión, todos en el repositorio
ARQUITECTURA
12 secciones en el documento de arquitectura
PRIMEROS MÓDULOS
Registro por correo y lista de espera, construido
PUBLICADO
La mayoría de los crates están en crates.io. Hay una ronda de publicación pendiente.
SERVICIO GESTIONADO
Aún no construido. El plano de control está diseñado, no escrito.

Cifras del harness: leídas de Cratefield/harness el 2026-10-21.

HITOS →

SEGURIDAD Y PRIVACIDAD

Seis capas entre una solicitud y los datos.

Cada capa es un control que documenta el harness. La lista completa está en sus documentos de seguridad y privacidad.

  1. 01 · BORDE

    Solo los orígenes propios de la venture

    El Worker de la venture responde en su propio dominio. CORS solo permite los orígenes que la venture enumera, y cada respuesta devuelve un id de solicitud.

  2. 02 · ABUSO

    Bots e inundaciones de tráfico

    Turnstile, que falla en cerrado. Límites de tasa en cada escritura pública, a través del Port RateLimiter.

  3. 03 · SOLICITUDES

    Errores y logs sin direcciones

    Los errores son problem+json con un slug fijo para cada caso. Una línea estructurada por solicitud, nunca una dirección de correo.

  4. 04 · TOKENS

    Enlaces, no sesiones

    Los enlaces de confirmación y de baja están firmados con HMAC, con rotación de claves. No hay almacén de sesiones que operar, escalar ni filtrar.

  5. 05 · SECRETOS

    Cifrado de sobre

    Los secretos se cifran con cifrado de sobre y quedan ligados a su fila. El proveedor de archivo local del Port KMS rechaza producción.

  6. 06 · AISLAMIENTO

    Una venture, una base de datos

    Ningún runtime se comparte entre empresas. Cada una tiene su propio Worker, sus datos y sus secretos, y puede moverse o apagarse por separado.

SECURITY.md →   PRIVACY.md →

QUÉ ESTÁ ABIERTO

El taller de la fábrica es público. Las recetas, no.

El harness, su runtime, sus Adapters y los dos primeros módulos tienen licencia MIT y se desarrollan de forma abierta. Cualquiera puede construir un backend sobre ellos, y todas las ventures que operamos lo hacen. Los módulos que codifican cómo Factory Zero opera sus empresas siguen siendo privados. El backend propio de cada venture también es privado.

Un venture es el propio harness. Cratefield toma el harness de código abierto y le añade la capa gestionada alrededor: aprovisionaría el worker, la base de datos y los secretos dentro de tu propia cuenta de Cloudflare y luego los operaría. El harness es real y funciona; ese plano de control está diseñado y aún no escrito. También es donde el límite de módulos justifica su existencia: un cliente puede construir y desplegar un módulo propio sin que el código fuente llegue nunca a nosotros.

Las decisiones se escriben a medida que se toman. El documento de arquitectura y los registros de decisión están en el repositorio, incluido el que explica por qué se descartó un primer intento.

Licencias en todo el stack

De los 17 ventures del stack, 11 son de código abierto, cada uno con un repositorio público bajo una licencia OSI. La barra y las fichas se generan a partir del campo de licencia del registro.

  • KontinuumMIT
  • CratefieldMIT
  • ColonizerMIT
  • SupportGeniusMIT
  • promptdecodeMIT
  • Keep ShippingMIT
  • LedgersMIT
  • Ghostwritin'MIT
  • SealbinApache-2.0
  • Living BrainApache-2.0
  • TokkerApache-2.0
  • VibeCaddieNo es código abierto
  • PosPluginNo es código abierto
  • OwlpostNo es código abierto
  • release.showNo es código abierto
  • ShoalNo es código abierto
  • SqueezinNo es código abierto

Ventures del stack por licencia: Kontinuum: MIT. Cratefield: MIT. VibeCaddie: No es código abierto. Colonizer: MIT. SupportGenius: MIT. promptdecode: MIT. PosPlugin: No es código abierto. Keep Shipping: MIT. Owlpost: No es código abierto. Sealbin: Apache-2.0. release.show: No es código abierto. Living Brain: Apache-2.0. Shoal: No es código abierto. Tokker: Apache-2.0. Ledgers: MIT. Ghostwritin': MIT. Squeezin: No es código abierto.