FACTORY ZERO

TECNOLOGIA / CÓDIGO ABERTO

Peças comuns. Montadas uma vez.

Toda venture precisa de um backend, e nenhuma deveria construir um. As peças de que uma empresa precisa para existir são escritas uma única vez, como um harness de código aberto em Rust. Uma venture escolhe os módulos que quer, liga tudo em um arquivo e é entregue como um único worker sem estado, com seu próprio banco de dados.

GITHUB.COM/CRATEFIELD/HARNESS →

A fábrica em números

ventures
2317 validação · 1 protótipo · 5 lançamento
na stack
17de 23 ventures, as partes compartilhadas
open source
118 MIT · 3 Apache-2.0
rodam no harness
1818 ativas hoje · 1 planejada
registros de decisão
30no repositório do harness

COMO UMA VENTURE É CONSTRUÍDA

Um arquivo dá nome à empresa.

O backend de uma venture é um pequeno projeto em Rust. Ele lista os módulos que usa, os adapters que os conectam ao mundo, e o nome e o domínio da própria venture. Todo o resto é o harness. Compile e o resultado é um único worker que contém exatamente esses módulos e nada além.

Se um módulo precisa de algo que o runtime não oferece, ou dois módulos reivindicam a mesma tabela, o build falha antes de qualquer deploy. Uma venture mal configurada não chega à produção.

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. Passo 1

    Nomeie

    A venture, seu domínio, seus módulos e os adapters que respondem por eles. Um arquivo.

  2. Passo 2

    Componha

    O build recusa um módulo cuja port o runtime não fornece, e dois módulos que reivindicam a mesma tabela ou rota.

  3. Passo 3

    Publique

    Um worker sem estado contendo exatamente os módulos listados, com seu próprio banco de dados, segredos e domínio.

AS CAMADAS

Seis camadas, do runtime até os produtos.

Leia de baixo para cima: onde o código roda, o harness a partir do qual todo backend é compilado, os backends, os produtos compartilhados, os agentes que operam a empresa e as ventures independentes. Chips sólidos estão ativos hoje, chips com contorno estão no harness, chips tracejados são planejados.

01RUNTIME

Cloudflare Workers, compilados para WebAssembly

Onde roda todo worker de venture. Dados e e-mail ficam ao lado, e o mesmo código pode rodar em um servidor.

Workers (wasm32)Banco de dados D1E-mail via ResendKVTurnstileLimitação de taxaPostgres, runtime nativo
02HARNESS

Cratefield: o núcleo open source em Rust

As ports, o roteador e os módulos. Um módulo pede uma port; um adapter responde.

Cratefield

Ports

DatabaseMailerCaptchaRateLimiterKeyValueSigner

Módulos

email-signuplista de espera
03BACKENDS

Um worker e um banco de dados por venture

Cada venture é composta a partir do harness e implantada separadamente. Ativas no harness hoje:

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

A stack: produtos aos quais toda venture se conecta

Os produtos compartilhados, organizados em prateleiras pelo que fazem. Cada um é uma empresa com seus próprios clientes.

Entregar e operar

  • VibeCaddie
  • Keep Shipping
  • release.show
  • Shoal

Comunicação

  • Owlpost
  • Squeezin

Segurança

  • promptdecode
  • Sealbin

Clientes

  • SupportGenius
  • PosPlugin
  • Ledgers

Conteúdo e IA

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

Cinco camadas, um agente para cada função

Cada função em cada camada é um agente. O Colonizer executa os agentes de código da camada de construção.

  • DESCOBRIR3 agentes
  • CONSTRUIR4 agentes
  • OPERAR4 agentes
  • DISTRIBUIR3 agentes
  • APRENDER3 agentes

Colonizer: agentes de código que transformam issues do GitHub em pull requests

06PRODUTOS

As ventures independentes

Ventures fora da stack. Elas herdam a fundação e não acrescentam a ela.

Undercover RockstarsYogininiFindsYou.workGroove GuruBloodrankratecla.im

As seis camadas, de baixo para cima

  1. runtime: Cloudflare Workers, compilado para WebAssembly. Onde roda todo worker de venture. Dados e e-mail ficam ao lado, e o mesmo código pode rodar em um servidor.
  2. harness: Cratefield: o núcleo open source em Rust. As ports, o roteador e os módulos. Um módulo pede uma port; um adapter responde.
  3. backends: Um worker e um banco de dados por venture. Cada venture é composta a partir do harness e implantada separadamente. Ativas no harness hoje:
  4. prateleiras: A stack: produtos aos quais toda venture se conecta. Os produtos compartilhados, organizados em prateleiras pelo que fazem. Cada um é uma empresa com seus próprios clientes.
  5. agentes: Cinco camadas, um agente para cada função. Cada função em cada camada é um agente. O Colonizer executa os agentes de código da camada de construção.
  6. produtos: As ventures independentes. Ventures fora da stack. Elas herdam a fundação e não acrescentam a ela.

UMA REQUISIÇÃO, DE PONTA A PONTA

Quem faz o quê quando um visitante se cadastra.

Desenhado apenas a partir dos links do registro. Uma linha contínua está ativa hoje e carrega tráfego; uma linha tracejada é planejada e ainda não carrega nenhum.

  1. Visitante

    uma pessoa em um site de venture

  2. Worker da venture

    um worker por venture, no harness do Cratefield

    no ar

  3. Owlpost

    e-mail para os ventures

    no ar

  4. SupportGenius

    relatos de bugs e suporte

    planejado

  5. Colonizer

    agentes de código, no harness

    no ar

  6. Living Brain

    conhecimento que guarda o que funcionou

    planejado

As ligações neste fluxo: Visitante para o worker do venture, requisição HTTPS: ao vivo. Worker do venture para o Owlpost, e-mail de confirmação: ao vivo. Worker do venture para o SupportGenius, erros viram issues: planejado. SupportGenius para o Living Brain, o suporte alimenta o conhecimento: planejado. Colonizer para o Living Brain, agentes alimentam o conhecimento: ao vivo.

Um cadastro em uma venture e para onde a mensagem vai em seguida. As setas mostram a direção de cada link; o status é o do registro.

MÓDULOS SÓ VEEM PORTS

Ports de um lado. Adapters do outro.

Um módulo pede uma port e nunca um fornecedor. O runtime responde por meio de um adapter. Os adapters são do próprio harness; o status indica onde uma venture ativa usa um hoje.

  • Database

    tabelas, consultas e migrações

    • D1 (ativo)
    • Postgres (no harness)
    • SQLite (no harness)

  • Mailer

    e-mail transacional

    • Resend (ativo)
    • Owlpost (planejado)

  • Captcha

    uma verificação de bots, que falha fechada

    • Turnstile (no harness)

  • KeyValue

    pequeno estado chave-valor

    • Cloudflare KV (no harness)

  • RateLimiter

    limites de requisições por chave

    • Cloudflare Rate Limiting (no harness)
    • Redis (no harness)

  • Payments

    checkout e cobrança

    • Polar (planejado)
    • Stripe (no harness)

  • TextModel

    uma conclusão de modelo

    • Anthropic (no harness)
    • Compatível com OpenAI (no harness)

  • Push

    avisos para dispositivos

    • APNs (no harness)
    • FCM (no harness)
    • Web Push (no harness)

  • Signer

    assinatura por referência de chave

    • Turnkey (no harness)

Ports e seus adapters: Database (tabelas, consultas e migrações): D1 (ativo), Postgres (no harness), SQLite (no harness). Mailer (e-mail transacional): Resend (ativo), Owlpost (planejado). Captcha (uma verificação de bots, que falha fechada): Turnstile (no harness). KeyValue (pequeno estado chave-valor): Cloudflare KV (no harness). RateLimiter (limites de requisições por chave): Cloudflare Rate Limiting (no harness), Redis (no harness). Payments (checkout e cobrança): Polar (planejado), Stripe (no harness). TextModel (uma conclusão de modelo): Anthropic (no harness), compatível com OpenAI (no harness). Push (avisos para dispositivos): APNs (no harness), FCM (no harness), Web Push (no harness). Signer (assinatura por referência de chave): Turnkey (no harness).

REGRAS DE DESIGN

Quatro regras que o design mantém.

  • 01

    Os módulos só enxergam ports.

    Um módulo pede um banco de dados, um serviço de e-mail, um captcha. Ele nunca toca um binding da Cloudflare nem um cliente de fornecedor. Os adapters respondem. Essa única regra é o que faz com que a saída posterior da Cloudflare seja a troca de um único crate.

    móduloMaileradapter

  • 02

    A composição acontece em tempo de compilação.

    Sem carregamento de plugins, sem serviço de registro, sem surpresas em runtime. O worker contém o que a venture listou, e o compilador é o primeiro revisor. Um módulo cujo código-fonte não deve entrar no build compartilhado pode rodar como seu próprio worker, montado no mesmo caminho por meio de um service binding. Ele continua composto, só que não no mesmo binário.

    compilarrecusarimplantar

  • 03

    Uma venture, um banco de dados.

    Nada é compartilhado em runtime entre as empresas. Cada uma tem seu próprio worker, seus próprios dados, seus próprios segredos. Uma venture pode ser copiada, movida ou desligada sem tocar em outra.

    workerbanco de dadossegredos
    workerbanco de dadossegredos
    workerbanco de dadossegredos

    nenhum runtime compartilhado

  • 04

    Sem estado por construção.

    Nada sobrevive a uma requisição, exceto o que é gravado no banco de dados. Os links de confirmação e de cancelamento de inscrição são tokens assinados, então não há armazenamento de sessão para operar, escalar ou vazar.

    requisiçãoworkerbanco de dados

    sem armazenamento de sessão

STATUS

Em que ponto está o harness.

O progresso é acompanhado como issues e marcos, de forma aberta.

  1. M0concluído

    Fundação

    Ferramentas do workspace, o core, o runtime da Cloudflare, os adapters Resend e Turnstile, o adapter SQLite, a CLI fz e o kit de testes.

  2. M1concluído

    Primeiros módulos

    Cadastro por e-mail, lista de espera, templates, a base de segurança e observabilidade.

  3. M2em andamento

    Primeira venture ativa

    publicação no crates.io, documentação, versionamento de contratos e a primeira venture em seu próprio domínio de API.

  4. M3concluído

    Portabilidade para auto-hospedagem

    O adapter Postgres, o runtime nativo, uma suíte de paridade em SQLite e Postgres, e exportação e importação de dados.

DESIGN
30 registros de decisão, todos no repositório
ARQUITETURA
12 seções no documento de arquitetura
PRIMEIROS MÓDULOS
Cadastro por e-mail e lista de espera, construídos
PUBLICADO
A maioria dos crates está no crates.io. Uma rodada de release está pendente.
SERVIÇO GERENCIADO
Ainda não construído. O plano de controle está projetado, não escrito.

Números do harness: lidos de Cratefield/harness em 2026-10-21.

MARCOS →

SEGURANÇA E PRIVACIDADE

Seis camadas entre uma requisição e os dados.

Cada camada é um controle documentado pelo harness. A lista completa está nos documentos de segurança e privacidade dele.

  1. 01 · BORDA

    Apenas as origens da própria venture

    O Worker da venture responde no próprio domínio. O CORS permite apenas as origens que a venture lista, e toda resposta devolve um id de requisição.

  2. 02 · ABUSO

    Bots e inundações

    Turnstile, falhando fechado. Limites de taxa em toda escrita pública, por meio da port RateLimiter.

  3. 03 · REQUISIÇÕES

    Erros e logs sem endereços

    Os erros são problem+json com um slug fixo para cada caso. Uma linha estruturada por requisição, nunca um endereço de e-mail.

  4. 04 · TOKENS

    Links, não sessões

    Os links de confirmação e de cancelamento de inscrição são assinados com HMAC, com rotação de chaves. Não há armazenamento de sessão para operar, escalar ou vazar.

  5. 05 · SEGREDOS

    Criptografia de envelope

    Os segredos são criptografados em envelope e vinculados à sua linha. O provedor de arquivo local da port de KMS recusa produção.

  6. 06 · ISOLAMENTO

    Uma venture, um banco de dados

    Nenhum runtime é compartilhado entre empresas. Cada uma tem seu próprio worker, seus dados e segredos, e pode ser movida ou desligada separadamente.

SECURITY.md →   PRIVACY.md →

O QUE ESTÁ ABERTO

O chão de fábrica é público. As receitas não são.

O harness, seu runtime, seus adapters e os dois primeiros módulos têm licença MIT e são desenvolvidos de forma aberta. Qualquer pessoa pode construir um backend sobre eles, e toda venture que operamos faz isso. Os módulos que codificam como a Factory Zero opera suas empresas permanecem privados. O backend próprio de cada venture também é privado.

Uma venture é o próprio harness. O Cratefield pega o harness de código aberto e adiciona a camada gerenciada em volta: ele provisionaria o worker, o banco de dados e os segredos dentro da sua própria conta Cloudflare e depois os operaria. O harness é real e está rodando; esse plano de controle está projetado e ainda não foi escrito. É também onde a fronteira dos módulos se paga: um cliente pode construir e fazer deploy de um módulo próprio sem que o código-fonte jamais chegue a nós.

As decisões são registradas conforme são tomadas. O documento de arquitetura e os registros de decisão estão no repositório, inclusive aquele que registra por que uma primeira tentativa foi descartada.

Licenças em toda a stack

Dos 17 ventures da stack, 11 são open source, cada um com um repositório público sob uma licença OSI. A barra e os blocos são desenhados a partir do campo de licença do registro.

  • KontinuumMIT
  • CratefieldMIT
  • ColonizerMIT
  • SupportGeniusMIT
  • promptdecodeMIT
  • Keep ShippingMIT
  • LedgersMIT
  • Ghostwritin'MIT
  • SealbinApache-2.0
  • Living BrainApache-2.0
  • TokkerApache-2.0
  • VibeCaddieNão open source
  • PosPluginNão open source
  • OwlpostNão open source
  • release.showNão open source
  • ShoalNão open source
  • SqueezinNão open source

Ventures da stack por licença: Kontinuum: MIT. Cratefield: MIT. VibeCaddie: Não open source. Colonizer: MIT. SupportGenius: MIT. promptdecode: MIT. PosPlugin: Não open source. Keep Shipping: MIT. Owlpost: Não open source. Sealbin: Apache-2.0. release.show: Não open source. Living Brain: Apache-2.0. Shoal: Não open source. Tokker: Apache-2.0. Ledgers: MIT. Ghostwritin': MIT. Squeezin: Não open source.