Ongoing case study

Cinder

Case
cinder
Status
Historical chapter preserved; proof-run chapter is green
Study type
Single-case historical + live dogfood record
Primary claim
Gateproof can keep the original Cinder chapter intact while adding new live chapters on top of it without rewriting the old record.
Method
Freeze each completed chapter, then tighten the next claim until the live system earns the next green chapter.
Observed outcome
This page now shows the original fixture proof, the first real Gateproof dogfood proof, and the connected-repo proof-run chapter as one continuous Cinder story.
Limitations
This page summarizes three proof chapters but does not itself execute the live loop. The current proof-run chapter depends on public infra and secrets to reproduce live. Future chapters still need to be earned through the same proof-loop discipline rather than added narratively.

Abstract

Cinder is one ongoing Gateproof case study. Chapter one preserves the original historical Cargo fixture proof. Chapter two records the first green proof where Cinder connected Gateproof, ran Gateproof's real docs deploy workflow on a self-hosted Cinder runner, and verified the deployed site. Chapter three records the next step: Cinder can now start and report proof runs for that connected repo while keeping the runtime checks green. The page keeps all earned chapters visible without rewriting the earlier record.

The historical fixture chapter remains preserved, and the current proof-run chapter is backed by a real green workflow run.

Case boundary

  • System under study: Cinder on Cloudflare.
  • Case structure: one preserved historical fixture chapter, one live dogfood chapter, and one current proof-run chapter.
  • Historical artifacts remain fixed and inspectable rather than reinterpreted.
  • Current proof-run artifacts point at public repos and a successful witness workflow run.
  • Out of scope for this page: turning every future proof into a separate standalone case-study route.

Procedure

  1. 1. Freeze the historical chapter and keep its artifacts public.
  2. 2. Promote the current proof contract to the next truthful claim rather than rewriting the old one.
  3. 3. Run the live loop against the new claim until the first failing gate is honestly green.
  4. 4. Publish the resulting proof artifacts before updating the public narrative.
  5. 5. Present the earned chapters on one page so the case study reads as one continuous story.

Chapter findings

  • Chapter one remains preserved as the historical Cargo-fixture proof.
  • Chapter two proves Gateproof's docs deploy through Cinder against the real Gateproof repo using Cinder's own repo connect, list, status, and dispatch path.
  • Chapter three proves Cinder can start and report proof runs for a connected repo through its own API and CLI.
  • The same case study can extend forward without rewriting the original proof chapters.
  • Public artifact links now point at the museum-style historical record plus the live dogfood proof.

Chapters

Chapter 1: Historical fixture proof

Status
Historical completed study
Primary claim
Cinder was first built through a proof loop that kept running until the target checks passed.
Method
One historical run with preserved input and output repos, fixed artifacts, and no mid-run human edits.
Observed outcome
This chapter reports a preserved record of the repo, proof file, and provisioning artifacts instead of rerunning the old system live.

Artifacts

Input repository

Preserved pre-loop repository state for the historical run.

Open artifact

Output repository

Preserved post-loop repository state for the historical run.

Open artifact

Proof contract

Historical plan.ts preserved as the proof contract for the run record.

Open artifact

Provisioning

Historical alchemy.run.ts preserved as the provisioning artifact for the run record.

Open artifact

Evidence

Run conditions Operating constraints recorded for the historical run.
  • Agent: Codex desktop, GPT-5.3.
  • No human edits, review, or audit during the loop.
  • The historical description states that the loop was started once and allowed to iterate to completion.
Artifact notes Preserved repositories and what each artifact represents.
  • Input repository: Preserved pre-loop repository state for the historical run.
  • Output repository: Preserved post-loop repository state for the historical run.
  • Proof contract: Historical plan.ts preserved as the proof contract for the run record.
  • Provisioning: Historical alchemy.run.ts preserved as the provisioning artifact for the run record.
Proof contract notes How the proof contract is framed in the historical record.
  • The proof contract is stored in plan.ts.
  • The contract is described as defining observe, act, and assert conditions against the live system.
  • The artifact is preserved for inspection and linked directly from this page.
Provisioning notes How the environment was provisioned for the historical run.
  • Provisioning is stored in alchemy.run.ts.
  • The provisioning artifact is treated as a fixed historical input rather than a live deployment action on this page.
  • The artifact is preserved for inspection and linked directly from this page.

Limitations

  • This chapter does not execute a fresh live proof loop.
  • The recorded outcome is interpreted from preserved artifacts and accompanying project notes.
  • Reproduction still depends on external Cloudflare resources and environment secrets.
  • The record concerns one system and one bounded historical study.

Chapter 2: Gateproof docs dogfood proof

Status
Completed live proof
Primary claim
Cinder connected Gateproof through its own CLI, started the real docs deploy workflow, ran it on a self-hosted Cinder runner, and the deployed site passed smoke.
Method
Deploy Cinder, connect Gateproof, list and inspect the repo through Cinder, dispatch the real CI workflow, watch the webhook and queue, run the deploy job through the local agent, and verify the deployed site.
Observed outcome
From committed code, Cinder connected Gateproof, listed and inspected the repo, dispatched Gateproof CI, handled the workflow_job webhook, returned the queued deploy job with runner details, ran the real Deploy Demo Site job through the local cinder-agent, and got a 200 smoke response from gateproof.dev.

Artifacts

Cinder dogfood proof

Public Cinder commit where the Gateproof dogfood proof is green from committed code.

Open artifact

Cinder proof contract

Canonical Gateproof product-path contract: repo connect, repo list, repo status, repo dispatch, webhook, queue, runner, and deploy-smoke against Gateproof.

Open artifact

Cinder provisioning

Existing-repo onboarding path that targets Gateproof without writing fixture files into the repo.

Open artifact

Gateproof witness commit

Gateproof commit used as the witness repo under the green dogfood proof.

Open artifact

Successful dogfood workflow run

Real Gateproof CI run whose Deploy Demo Site job completed through Cinder.

Open artifact

Evidence

Webhook delivery witness The proof used GitHub's own webhook delivery record to show that Cinder received the job event.
  • Gateproof CI was dispatched through workflow_dispatch on the real CI workflow.
  • The proof checked the real workflow_job delivery history for the Gateproof webhook that points at Cinder.
  • The green run recorded a successful workflow_job delivery with status_code 200 after dispatch.
Queue payload After dispatch, Cinder returned the exact Gateproof deploy job the agent was supposed to run.
  • Cinder connected Gateproof before dispatch.
  • 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 execution The local cinder-agent registered an ephemeral GitHub runner and executed the real deploy job.
  • The local agent logged starting github runner for the Gateproof deploy job.
  • The agent configured a real ephemeral runner for acoyfellow/gateproof.
  • The Deploy Demo Site job completed with result Succeeded on that runner.
Deployed site smoke The same workflow run ended with the public docs site returning HTTP 200.
  • The proof's deploy-smoke gate requested https://gateproof.dev after the deploy job completed.
  • The smoke check returned HTTP 200 and captured the homepage HTML.
  • The public witness run for this chapter is GitHub Actions run 22772337017.

Limitations

  • This chapter proves the Gateproof docs deploy path, not every historical Cargo cache/speed claim from chapter one.
  • A live rerun still requires Cloudflare infrastructure, GitHub access, and the Cinder environment secrets.
  • The witness repo and workflow are real, but the proof is still scoped to one ongoing case study rather than a generalized benchmark suite.
  • Repo proof runs are not part of this chapter's claim; they were earned in the following chapter.

Chapter 3: Connected repo proof runs

Status
Current green proof
Primary claim
Cinder can start a proof run for a connected repo and show that proof run back to the user, while the old Gateproof runtime checks still pass.
Method
Connect Gateproof through Cinder, list and inspect the repo, dispatch the real workflow through Cinder, start a proof run for that repo, then require webhook, queue, runner, and deploy-smoke to stay green.
Observed outcome
From committed code, Cinder created a proof-run record for the connected Gateproof repo through its own CLI and HTTP API, returned that record through GET /proof-runs/:id, and still drove the real Gateproof Deploy Demo Site job to a successful smoke-checked deploy.

Artifacts

Cinder proof-run chapter

Public Cinder commit where repo proof runs became part of the connected-repo product path.

Open artifact

Cinder proof-run contract

Canonical proof contract including repo connect, repo list, repo status, repo dispatch, repo proof run, webhook, queue, runner, and deploy-smoke.

Open artifact

Gateproof worker-loop foundation

Gateproof commit that provided the reusable self-fixing worker-loop substrate consumed by this chapter.

Open artifact

Successful proof-run witness

Real Gateproof CI run whose Deploy Demo Site job completed during the proof-run chapter.

Open artifact

Evidence

Proof-run API Cinder added its own proof-run API for the connected Gateproof repo.
  • 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.
Earlier repo steps still worked Adding proof runs did not break the repo connection work that Cinder had already earned.
  • 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 runtime still passed This chapter only counted because the old runtime checks still passed after proof runs were added.
  • 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.

Limitations

  • This chapter is still scoped to one connected repo at a time.
  • A live rerun still requires Cloudflare infrastructure, GitHub access, and the Cinder environment secrets.
  • Multi-repo onboarding, repo isolation, stale-run recovery, and agent fleet behavior are later chapters.