Story: Bootstrap a static site

Related

• GitHub:dashecorp/rig-docs#184

Hook

On 2026-04-23, Stig filed a two-line issue on dashecorp/infra: “New site: carrots.dashecorp.com” with the agent-ready label. No spec, no wireframe, no handholding. Within two minutes the rig had picked it up. Two hours later a live Astro site was serving HTML at that domain. Between those two events: five PRs, one Cloudflare error with its own Wikipedia entry, and a recovery the rig ran without a human rewriting a single prompt.

---

Act I — The happy path lands

Dev-E-node consumed the conductor webhook and began work on dashecorp/infra#119. The rig already had for_each patterns for Cloudflare Pages and GitHub repos, so the implementation was mechanical.

PR infra#120 opened in under five minutes with three files changed:

File	Change
cloudflare/pages.tf	Added carrots entry to for_each map
cloudflare/dns.tf	Added CNAME to the Pages project
github/repos.tf	Added carrots to repos for_each map

It merged, OpenTofu applied cleanly, and three resources appeared: a GitHub repo, a Cloudflare Pages project named carrots, and a CNAME pointing carrots.dashecorp.com at carrots.pages.dev. rig-conductor saw the merge and filed dashecorp/carrots#1 — “Bootstrap Astro content.”

Cycle 1 — infra#120

Changed: TF resources for repo, Pages project, DNS. Result: Applied cleanly.

---

Act II — Three fixes that didn’t

The workspace replay

Dev-E-node created two feature branches for dashecorp/carrots#1 — the conductor dispatched the event twice, and Dev-E committed to the second branch, then closed the issue without opening a PR. A human re-opened it and manually created PR carrots#2 from the good branch.

Cycle 2 — carrots#2 (human assist)

Changed: Astro scaffold pushed. What didn’t work: Dev-E closed the issue prematurely; duplicate workspace is a known conductor replay edge case.

The skipped deploy

The deploy workflow ran immediately after merge and logged one line before exiting:

CLOUDFLARE_API_TOKEN not set — skipping.

TF had created the repo but not its secrets. CF_API_TOKEN, CF_ACCOUNT_ID, and RIG_BOT_PAT didn’t exist on dashecorp/carrots — a gap in the infra module.

Cycle 3 — deploy skipped

Changed: Nothing. Workflow exited cleanly with skip logic. Secrets gap not yet diagnosed.

CF error 1014

With secrets still missing, the DNS went live but the custom domain binding stalled. The site returned HTTP 403 / CF error 1014 — “CNAME Cross-User Banned.”

This is a documented Cloudflare edge case: when a Pages project name matches a binding stuck in CF’s global registry — often from a prior account — CF refuses the CNAME handshake. Dev-E filed three infra PRs in sequence:

• depends_on inversion — create DNS only after Pages project is active. Applied cleanly. 1014 persisted.
• replace_triggered_by taint — force destroy/recreate of the Pages project. Applied cleanly. 1014 persisted (same name, same stuck binding).
• Gray-cloud DNS — set the CNAME to DNS-only to rule out proxy interference. Applied cleanly. 1014 persisted.

All three applied without error. All three were ineffective. The problem was not in the TF config — it was in Cloudflare’s internal state for the name carrots.

Cycles 4a–4c — three infra PRs, CF 1014 each time

Changed: Dependency order, resource taint, proxy mode. What didn’t work: All three. CF’s binding is stuck per project name, not per resource state. depends_on and replace_triggered_by cannot fix an upstream CF registry conflict.

---

Act III — The real fix

After three failed attempts, Dev-E diagnosed the pattern: every fix preserved the project name carrots. The name itself was the problem.

PR infra#124 renamed the Pages project to carrots-site:

carrots = {
  name = "carrots-site"  # was "carrots"
  ...
}

A fresh name has no prior binding in CF’s registry. The custom domain handshake completed.

PR infra#125 provisioned the missing repo secrets (CLOUDFLARE_API_TOKEN, CF_ACCOUNT_ID, RIG_BOT_PAT) on dashecorp/carrots.

Dev-E re-triggered the deploy. Wrangler authenticated, pushed to carrots-site, and the domain resolved.

Cycle 5 — infra#124 + infra#125

Changed: Pages project name → carrots-site; repo secrets provisioned. Result: Custom domain binding completes; deploy succeeds.

---

Closing

<title>Carrots — Orange. Crunchy. Chronically Underrated.</title>

Five PRs. Two hours. The human’s only interventions were recovering a duplicate branch and knowing that three clean TF applies weren’t the fix — the fix was a name change no resource-level remediation could surface.

The rig’s value isn’t “runs perfectly.” It’s “iterates faster than a human dev can diagnose, and documents every failed attempt along the way.” The CF 1014 / project-name collision is now in memory; the next agent skips three cycles and goes straight to the rename.

See also: The Autonomous Engineering Rig for the full architecture picture, and Demo: Five-minute walkthrough for a narrated version of this story.

Next story: when Dev-E runs as multiple concurrent instances on a shared conductor queue — and how the rig keeps them from stepping on each other.