Fork vs Upstream · Houston Hack Camp

Houston Hack Camp · Pista A · Dev Track

What we built on Houston
that upstream doesn't have

A fork-vs-upstream inventory. Three layers of divergence from gethouston/houston, capped today by a live multi-agent sprint that answers the hackathon's core tension — scale to ~100,000 agents at once — head-on.

gethouston/houston @ v0.4.18 → broomva fork ● Live build · 2026-06-06 built across 4 parallel Conductor worktrees

60PRs merged
over upstream

89commits ahead
of v0.4.18

+74.9klines added
1,013 files

5new engine
crates

4features shipped
today

Source of truth: git diff gethouston/houston:main … broomva/hawthorne:v2/m1-graft-brain plus the live worktree warsaw. Every claim below is a real commit.

01The lineage — three forks deep, then today

We didn't just patch upstream. The fork is a staged divergence: a friendly fork of the OSS engine, then a rename + a grafted orchestration brain, then today's hackathon compute layer on top.

UPSTREAM

gethouston/houston @ v0.4.18 (release #427)

The OSS Tauri + Rust engine. Pod-per-agent desktop app. Our baseline — untouched reference.

FORK

broomva/houston +60 PRs · +89 commits

Friendly fork with attribution (BROOMVA.md, PROVENANCE.md, daily sync-upstream Action). Adds 3 engine crates (houston-life, houston-linear, houston-claude-hooks), an Advanced feature-flag surface, bun migration, CI, and a 32-doc knowledge base.

broomva/hawthorne v2/m0-rename · v2/m1-graft-brain

Houston → Hawthorne rename + OSS hygiene (BRO-1403), then the brain graft: new crate hawthorne-orchestration with the fs-canonical object model Initiative → Project → Task → Cycle → Run (BRO-1405).

TODAY

Live worktree · warsaw 2026-06-06 hackathon sprint

The compute plane: houston-sandbox (#66), cloud-deploy the engine (#68), context enablement (#67), the guided writer (#69). Built in parallel agent worktrees, not yet upstreamed.

02The brief's tension — and our answer

Pista A, slide 07: “Ahora escálalo: ~100.000 agentes a la vez.” Houston Teams ≈ 10,000 users × ~10 agents. Two ways to host them — both broken at scale:

Option 1 — breaks on economics

Un pod por agente

Clean, simple isolation — but 100k pods is a cost / scheduling / cold-start nightmare. Density and economics collapse.

Option 2 — breaks on isolation

Un pod por engine

Dense and cheap — but you must impose hard tenant boundaries inside a shared host. “Eso es justo lo que falla hoy.”

Our answer — houston-sandbox (shipped today, #66)

Make the boundary a runtime choice under one declarative policy

Get pod-per-engine density with per-agent Firecracker-grade walls — by splitting the problem into two orthogonal axes and only owning the thin one.

Axis A — boundary primitive (“how strong is the wall?”)

Firecracker microVM by default — an implementation detail selected at runtime
Swappable backend: local (host child — dev/bench floor) + fly (managed Firecracker)

Axis B — control surface (“who picks the wall?”)

One SandboxPolicy { fs, net, identity, limits } → pluggable backend REGISTRY
restricted() baseline: egress Deny, no shared identity, deny_unknown_fields
sandbox-bench harness — p50/p95/p99 provisioning percentiles at load

19 files · same ProviderAdapter + REGISTRY + Provider pattern Houston already uses for AI providers, re-applied to isolation backends. Two planes that scale oppositely: the relay plane ships on Cloudflare Durable Objects; this is the compute plane — one hard-isolated sandbox per agent.

03Mapped to “Cómo se gana” (slide 15)

Every rubric criterion, with the concrete fork additions that satisfy it. green = shipped today blue = already in the fork

Eje	Criterio (rúbrica 1–5)	Nuestra evidencia
Infraestructura	Conocimiento de infraestructura enfocada a agentes One hard-isolated sandbox per agent; two-plane (relay vs compute) model; one image deploys everywhere.	houston-sandbox · Axis A/B #66 cloud-deploy engine · Railway + /healthz #68 sandbox-bench harness always-on/ Docker·compose·systemd·railway.json houston-relay (CF Durable Objects)
Infraestructura	Seguridad enfocada a agentes Per-tenant boundaries inside a shared host — the exact failure the brief calls out.	SandboxPolicy fs/net/identity/limits restricted() egress-Deny baseline deny_unknown_fields typed enums banned-patterns linter (No-Silent-Failures) /healthz public vs /v1/* bearer-gated
Producto	La UI se siente integrada con los componentes ya usados	Advanced settings + feature-flag infra context_meter · git_panel · timeline · tile_layout Linear board view in agent shell AskUserQuestion (MCP) across the stack
	UX para usuarios no técnicos	Context-enablement wizard · import + synthesize #67 “Help me write this” guided writer #69 i18n en/es/pt voice input
	Relevancia de la feature agéntica	Native cross-review · request_review tool #65 context bootstrap synthesis (corpus→draft) orchestration brain: Initiative→…→Run houston-life runtime client (UDS)
Entrega (ambas)	Resuelve el problema	pod-per-engine density + Firecracker walls via one policy → the 100k-agent tension, directly
	Uso de herramientas	Conductor parallel worktrees Omnara checkpoints bun · Biome · cargo · gh Railway / Fly Machines
	Skills construidos	built-in skill: write-my-job-description advanced slash-skills catalog 32-doc knowledge base

04Today's live arc — built with agents, in worktrees

The whole sprint ran in parallel Conductor worktrees, each an isolated agent, all collapsing into the warsaw tree. This is the “build live with other agents” story — and the rubric's uso de herramientas.

cloud-sandbox → houston-sandbox #66 engine-container → cloud-deploy #68 hawthorne-cloud-backend → Houston Cloud surface login-relay-device-code-race → auth fix #70

11:51

#66 Axis-B cloud sandbox control surface + benchmark harness

New crate engine/houston-sandbox — SandboxPolicy → registry, local + Fly/Firecracker backends, sandbox-bench. The centerpiece.

12:26

#67 Context enablement — import + synthesize workspace/user context

Rust context_bootstrap (corpus → redact → synthesize → draft) + a 3-screen wizard, i18n en/es/pt. UX for non-technical onboarding.

12:52

#69 Guided “Help me write this” job-description writer OPEN PR

Built-in skill write-my-job-description + voice input. The non-technical, agentic product surface.

13:23

#68 Cloud-deploy the engine — Railway runbook + public /healthz + PaaS entrypoint

“Same code, two doors.” One image → Railway/Fly/K8s via $PORT; /healthz unauth liveness, /v1/* stays bearer-gated. Dogfooded: 200 vs 401 proven.

05The full additions ledger

Everything in the fork that upstream doesn't have, grouped by surface.

🛰️

Agent cloud infrastructure
5 new engine surfaces

engine/houston-sandbox — isolation control plane today
cloud/ — Houston Cloud managed-deploy vision
always-on/ — Dockerfile · compose · systemd · railway.json
knowledge-base/cloud-compute.md — two-planes model
.dockerignore + PaaS $PORT entrypoint

🧠

Orchestration brain
v2 graft from vaulted v1

engine/hawthorne-orchestration crate
fs-canonical model: Initiative→Project→Task→Cycle→Run
markdown + YAML frontmatter; child-edge authoritative
multi-stage blocked_by; RunRef worktree
11/11 ported unit tests green

🔗

New engine crates
vs upstream

houston-linear — full Linear tracker (C1–C16): OAuth, webhooks, mirror, board view
houston-life — Life runtime client over UDS (Stage 0 e2e)
houston-claude-hooks — install/uninstall hooks in Claude Code
Native cross-review: request_review tool + second-opinion doctrine

✨

Product & UX
integrated, non-technical

Context-enablement wizard today
“Help me write this” guided writer today
Advanced feature-flag surface: context_meter, git_panel, timeline, tile_layout, checkpoints, worktrees
Mobile: Capacitor native shell + session handoff
Tunnel/Notify push pipeline (APNs/FCM loc-keys)
i18n en/es/pt across new surfaces

🛠️

Tooling & skills
uso de herramientas

32-doc knowledge-base/ (cloud-compute, cross-review, advanced-*, tracker…)
Built-in skill: write-my-job-description + slash-skills catalog
houston-doctor.sh · check-cli-deps.sh · lint-banned-patterns.sh · cargo-sync-check.sh
bun (from pnpm) · Biome · PR CI workflow · husky pre-commit

⚖️

Governance & provenance
friendly-fork hygiene

BROOMVA.md attribution + friendly-fork policy
PROVENANCE.md · HOUSTON-LINEAGE.md · NOTICE
.control/ metalayer · CLAUDE.md · AGENTS.md
Daily sync-upstream GitHub Action (stay current)
docs/specs/*.html · docs/handoffs/