Gateproof

Case study

Cinder

What this is

Cinder is a CI runner built on Cloudflare. It's the first system validated end-to-end by a gateproof plan. This page documents three chapters — each one earned by running the loop until every gate passed.

Current state

Cloudflare hosts the control plane. A separate machine still handles compute. Hosted execution is next.

How to read this

Each chapter makes a claim, then proves it with artifacts you can click through. Nothing here is retroactive — chapter one was frozen before chapter two started, and so on. If a chapter says green, there's a public workflow run backing it up.

Chapters

Chapter 1: The original build

Status
Historical record
Claim
Cinder was built by an AI agent running a gateproof loop until every check passed, with no human edits during the run.
What happened
A Codex agent (GPT-5.3) was given a plan.ts and told to iterate. It ran the observe/act/assert cycle until the target system was up and all assertions were green. The input repo, output repo, and proof contract are all preserved.

What happened

What happened

The original build was recorded as a preserved historical run, not a live rerun.

  • A Codex agent (GPT-5.3) was given a plan.ts and told to iterate until every check passed.
  • The observe/act/assert loop ran until the target system was up and the assertions were green.
  • The input repo, output repo, proof contract, and provisioning script were preserved as the historical record.

Artifacts

Input repo Output repo Proof contract Provisioning

Provisioning

The provisioning script used for the original build.

Open artifact

What this doesn't prove

  • This chapter is a historical record.
  • It does not re-run live on this page.
  • Reproducing it still requires Cloudflare resources and environment secrets.

Chapter 2: Deploying Gateproof's own docs through Cinder

Status
Green
Claim
Cinder can connect a real repo, dispatch its CI workflow, run the job on a separate machine, and the deployed site comes back 200.
What happened
Gateproof's own repo was connected to Cinder via its CLI. Cinder dispatched the real Deploy Demo Site workflow. GitHub sent a workflow_job webhook back to Cinder. Cinder queued the job. A separate machine running cinder-agent picked it up, registered an ephemeral GitHub runner, executed the deploy, and gateproof.dev returned HTTP 200.

The proof chain

Webhook

GitHub's delivery log shows that Cinder received the workflow_job event with HTTP 200.

  • Gateproof's real Deploy Demo Site workflow was dispatched through GitHub Actions.
  • GitHub's workflow_job webhook targeted Cinder and was delivered successfully.

Queue

Cinder returned the queued Gateproof deploy job with the expected repo, labels, and runner token.

  • The queue payload resolved repo_full_name as acoyfellow/gateproof.
  • The payload included self-hosted and cinder labels.
  • The payload included a real repo-scoped runner registration token for the Gateproof job.

Runner

A separate machine running cinder-agent picked up the job and executed the deploy.

  • cinder-agent logged picking up the Gateproof deploy job.
  • It registered an ephemeral GitHub runner for acoyfellow/gateproof.
  • The Deploy Demo Site job completed with result Succeeded.

Smoke test

After deploy, gateproof.dev returned HTTP 200.

  • The proof requested https://gateproof.dev after the deploy completed.
  • The public witness run for this chapter is GitHub Actions run 22772337017.

Artifacts

Cinder dogfood proof Cinder proof contract Gateproof witness commit Workflow run

Cinder dogfood proof

The Cinder commit where this chapter went green.

Open artifact

Cinder proof contract

The proof contract covering connect, list, dispatch, webhook, queue, runner, and smoke.

Open artifact

Gateproof witness commit

The Gateproof repo state used during the proof.

Open artifact

Workflow run

The actual GitHub Actions run that went through Cinder.

Open artifact

What this doesn't prove

  • Compute still ran on a separate machine, not hosted on Cloudflare.
  • This is one repo and one workflow, not a generalized benchmark.

Chapter 3: Proof runs as a product feature

Status
Green
Claim
Cinder can start a proof run for a connected repo, return the result through its API, and everything from chapter 2 still works.
What happened
Cinder added cinder repo prove acoyfellow/gateproof to its CLI. Running it creates a proof_run record with an ID, status, and timestamps. The same record is retrievable via GET /proof-runs/:id. Meanwhile, the full chapter 2 chain — webhook, queue, runner, deploy smoke — stayed green on the same machine.

What was checked

What was checked

The proof-run chapter only counted because the new API path worked and the earlier runtime path stayed green.

  • The CLI added cinder repo prove acoyfellow/gateproof.
  • Cinder returned a proof_run_id, repo, triggered_run_id, status, and timestamps through its own HTTP API.
  • The proof fetched the same proof-run record back from GET /proof-runs/:id and used that as the direct check.
  • Repo connect was still the way Gateproof entered Cinder state.
  • Repo list and repo status still showed that the connected repo was visible and inspectable.
  • Repo dispatch still triggered the real Gateproof workflow before the proof-run record was created.
  • The webhook gate still observed the real workflow_job delivery after dispatch.
  • The queue gate still observed the intended self-hosted Gateproof deploy job with the runner details already filled in.
  • The runner and deploy-smoke gates still ended on a successful Deploy Demo Site job and 200 responses from the public routes.

Artifacts

Cinder proof-run chapter Cinder proof-run contract Gateproof worker-loop commit Workflow run

Cinder proof-run chapter

The Cinder commit where proof runs were added.

Open artifact

Cinder proof-run contract

The updated contract including the proof-run gate.

Open artifact

Gateproof worker-loop commit

The reusable loop substrate this chapter consumed.

Open artifact

Workflow run

The GitHub Actions run that completed during this chapter.

Open artifact

What this doesn't prove

  • Still one repo at a time.
  • Still a separate machine for compute.
  • Multi-repo, isolation, stale-run recovery, and fleet behavior are future chapters.

What's next

Hosted execution — running compute inside the user's own Cloudflare account instead of on a separate machine. That's not an earned claim yet. When it is, it'll be chapter 4.