DEV Community: Othmane ETTAIB

I don't review AI code. My build does.

Othmane ETTAIB — Tue, 01 Sep 2026 22:47:16 +0000

Originally published on indiecore.net.

There's a ratio I spent a while pretending not to know about. Claude produces a plausible
two-hundred-line diff in roughly a minute. Reading two hundred lines of plausible code
properly — not skimming for shape, actually checking it — takes me fifteen or twenty. That
gap is the whole problem with "never merge AI-generated code without reading it," which is
advice I agree with and could not follow.

For a few months I scrolled diffs, recognised the shape of things, and merged. It felt like
reviewing.

What eventually gave it away was the kind of bug getting through. None of them were subtle
logic errors that careful reading would have caught. They were dull, mechanical things: a
dead internal link left behind by a route rename, an <img> with no alt, a canonical URL
pointing at the wrong host, two cache rules that turned out to concatenate. Every one was
something a fifty-line script could find in milliseconds, and none of them were things I was
ever going to reliably catch by eye at eleven at night.

So I stopped trying to read faster.

The verifier

scripts/verify.mjs is 169 lines of dependency-free Node. It walks the built dist/
directory and exits non-zero on anything I've decided must never ship.

npm run check      # build + verify — the same gate CI runs

It runs on every pull request and the deploy job depends on it, so a branch that fails it
doesn't reach the internet. Not because I'm disciplined; because the pipeline is wired that
way. (That plumbing is in the Cloudflare Workers post,
along with the five traps that cost me an evening.)

The link and image checks are the whole idea in miniature. Resolve every site-absolute URL
against what's actually on disk:

/** does a site-absolute URL resolve to a real file? */
const resolves = url => {
  const clean = url.split('#')[0].split('?')[0];
  if (!clean || clean === '/') return fs.existsSync(path.join(DIST, 'index.html'));
  const p = path.join(DIST, clean);
  if (fs.existsSync(p) && fs.statSync(p).isFile()) return true;
  return fs.existsSync(path.join(p, 'index.html'));
};

for (const href of attr(html, /href="(\/[^"#][^"]*)"/g)) {
  if (!resolves(href)) fail(where, `dead internal link → ${href}`);
}

Nothing clever. It's the kind of check that's tedious for a person to do on every page of
every build and free for a machine to do forever.

Every check has a bug behind it

I didn't sit down and write a best-practices linter. Each rule went in on the day something
got past me:

The check	What it's remembering
exactly one `<h1>` per page	a generated template that emitted two
`alt` on every `<img>`	accessibility regressions Lighthouse caught days later
dead internal links	a renamed route that left pages pointing at a 404
`_redirects` targets resolve	a redirect pointing at a page I'd since deleted
no placeholder or filler copy	draft text left in a page, one merge from production
Blogger markup in output	migration leftovers surfacing weeks after the migration
every page listed in `sitemap.xml`	new pages that silently never got submitted

Resist the urge to write the exhaustive rulebook up front. I tried; you end up with forty
rules, six of which ever fire, and the other thirty-four generate enough noise that you stop
reading the output at all. Which is worse than having no verifier, because now you also
believe you have one.

The checks that pay for themselves are invisible

The rules I'd least want to lose guard things I would never notice by looking at the site,
because the site looks fine.

This one validates the IndexNow key file:

// scripts/seo-ping.mjs submits URLs under this key; the crawlers reject the
// submission unless the matching file is live at the site root.
const key = fs.readFileSync(KEY_FILE, 'utf8').trim();
if (!/^[a-f0-9]{8,128}$/.test(key)) fail('indexnow', `key is not 8-128 hex chars: "${key}"`);
else if (!fs.existsSync(p))         fail('indexnow', `missing key file /${key}.txt`);

Ask an agent to "add IndexNow submission" and you'll get a correct submission script and no
key file, because nothing in the request mentions one. It isn't being careless. It has no way
to know what the silent failure costs, and a missing key file fails silently by design — the
crawler just ignores you. Same story with app-ads.txt, which is read by ad networks and
nobody else, and which is now parsed field-by-field at build time against the IAB spec.

Numbers for the things a script can't see

Alongside the verifier there's a Lighthouse budget, and it isn't negotiable:

performance ≥ 90, accessibility ≥ 100, best-practices ≥ 100, seo ≥ 100

This catches the failure the verifier can't: slow drift. No single change makes a site slow;
twenty changes, each fine on its own, do, and you never see the moment it happens because you
were looking at diffs rather than at scores.

A real one: the grey I use for code comments in these posts failed WCAG contrast. It looked
deliberate. Honestly, it looked good. One-line fix, and I would never have found it by
reading a stylesheet — the budget found it on the pull request (commit d64bce0, if you're
curious).

Performance measurement on shared CI runners is noisy, so the gate re-measures instead of
failing on one bad sample:

// Only performance is re-measured, and only when it misses.
while (scores.performance < BUDGET.performance && attempts < RETRIES) { … }

That detail matters more than it looks. A gate that fails at random gets ignored, then
disabled, then deleted. Flaky checks teach you to click through failures, which is the exact
habit you built the gate to prevent.

Write the error message for the agent

One thing I'd underrated. Compare:

  ERROR  /blog/index.html: dead internal link → /games/word-slot

with a generic "validation failed". The first I can paste straight into a session and get a
correct fix in one turn; the second starts a conversation. Good error messages were always
worth writing. They're worth roughly double now, because the agent reads them too, and a
precise message is the difference between a fix and a guess.

What it doesn't do

It has no opinion about whether the code is any good. It won't tell me a function is a mess,
that an abstraction is wrong, or that the feature was a bad idea in the first place. That's
still my job, and now it's the only reviewing job I have — which is a better trade than it
sounds, because the mechanical layer is where all the volume is.

It also can't tell me the agent touched something it shouldn't have gone near at all. That's
a different problem and I handle it differently; it's in
the blast radius rule.

The transferable bit isn't "write a verifier for your static site." It's the question I now
ask every time I catch something in a diff: could a script have caught this? When the answer
is yes, writing the script beats remembering the lesson, because I don't reliably remember
lessons and the script doesn't get tired.

Originally published at I don't review AI code. My build does..

The code is on GitHub: Both scripts, ready to drop in

The blast radius rule for AI coding

Othmane ETTAIB — Tue, 01 Sep 2026 22:34:35 +0000

Originally published on indiecore.net.

My domain carries email as well as the website. When I moved this site to Cloudflare I sat
looking at the DNS panel for a good ten minutes before touching anything, because deleting
the wrong record there wouldn't break something I could see. It would break mail delivery:
quietly, days later, for messages that no longer existed to resend.

I have never once felt that way about a stylesheet.

That gap is what I use now to decide how much of a task an agent does on its own. Not how
hard the task is, and not how much I trust the model. Just one question — how expensive is
this to undo after it ships?

The sorting mistake I made first

My instinct was to hand over the tedious work and keep the interesting work. Boilerplate,
config, CSS, build scripts, redirect maps: all yours. The "real" logic: mine.

That's backwards, and it took me an embarrassingly long time to see why. The tedious stuff is
tedious because it's plumbing, and plumbing is precisely the part that touches things
outside your repository — DNS, caches, crawlers, store metadata, ad configuration. Difficulty
and consequence aren't correlated at all. Some of the most trivial edits in this project are
the ones I'd least like to get wrong.

There's a well-documented pattern now of projects that moved fast with AI for a few months
and then hit a wall: features breaking other features, a codebase nobody understands, a
rewrite costing more than the original build. Reading through those post-mortems, the thing
that struck me is that it isn't mainly a code-quality problem. It's a reversibility problem.
You don't hit a wall because the code is ugly. You hit it because too many changes went
somewhere you can't cheaply back out of.

Zone 1 — one command undoes it

Anything that lives in the repo, renders into dist/, and can be reverted with git revert
plus a redeploy. Page copy, styles, the generator, build scripts, blog posts, most refactors.

The agent works alone here. I describe what I want, it does it, CI checks it, I open the
preview URL. If it's wrong it's wrong for about two and a half minutes (the length of a
deploy) and the fix is one command. At that price, reading every line is a worse use of my
attention than occasionally fixing something.

This is the bulk of the work, and it's where all the speed comes from.

Zone 2 — recoverable, but only if you notice

Things that are technically in the repo but whose failure mode is silence. Cache headers,
redirect maps, robots.txt, canonical URLs, structured data, the sitemap. Anything consumed
by a crawler, a browser cache or a third party instead of by a person.

Reverting isn't the issue. Nothing tells you. The site looks perfect, and it goes on looking
perfect for three weeks, until you notice traffic is off or a cache never invalidated or a
page was never indexed at all.

My cache rules looked completely fine in the diff:

/assets/images/*
  Cache-Control: public, max-age=31536000, immutable

/assets/*
  Cache-Control: public, max-age=86400

Here's what came back over the wire:

cache-control: public, max-age=86400, public, max-age=31536000, immutable

Overlapping rules concatenate. Browsers take the first value, so the year-long immutable
cache did precisely nothing. Nobody reading that diff would flag it, human or model, because
the diff is fine. Only the response was wrong.

So the rule in Zone 2 isn't "read more carefully." Reading was never going to find that. It's
verify against reality: either the check goes into the build, which is
what I mostly do now, or I curl the deployed thing and read
what actually came back. "The deploy succeeded" and "the new behaviour is live and correct"
are two different claims and only one of them is checkable.

Zone 3 — the undo doesn't live in git

Here I don't delegate, and it isn't about competence. It's that I need to be the person who
typed it.

DNS records. See above. MX and TXT are a category of their own.
Google Play Console. Store listings, content ratings, data safety declarations. Rolled out to production, a wrong answer is a policy problem rather than a bug, and the round trip to fix it is measured in days.
Any URL somebody else has already published. The privacy policy URL for each of my games is entered in its Play Console listing. Those aren't mine to break. They get a 301 and a build check, permanently.
Secrets, tokens, scopes. A permission set is a decision, not a task.
Anything where the dashboard uses the word "delete".

The common property isn't danger exactly. It's that git revert can't fix it. If the undo
isn't in version control, I do it by hand, slowly, with the docs open in another window.

Why the agent can't make this call

An agent optimises for finishing the task you described, and it's genuinely good at that.
What it can't weigh is what you'd lose if it's wrong, because that information isn't in the
repository and mostly isn't written down anywhere.

Nothing in my code says "these five routes are referenced from live Play Store listings that
take days to update." They look like any other routes. When an agent renames one it isn't
being reckless — it's being exactly as careful as the information it was handed.

Which points at the fix. Write the constraint into the repo, where the work happens. Mine
sits near the top of the README in plain language:

It also hosts the privacy policy for every game. Those URLs are referenced from Google
Play Console listings — they must not break.

I wrote that sentence for a future human. It happens to work just as well on an agent, which
turned out to be a much bigger deal than I expected and is
a whole post of its own.

Shrinking the radius beats classifying it

The real leverage isn't getting better at sorting. It's moving work down a zone until the
sorting stops mattering.

Move	What it converts
Never commit to `main`; everything is a PR	production mistakes → preview-URL mistakes
A preview deploy per branch	"looks right in the diff" → "I loaded it"
Config in version control, not the dashboard	untracked drift → a reviewable diff
Build-time checks for the silent stuff	Zone 2 → Zone 1
One deploy pipeline, not two	racing publishes → one gated publish

That last row bit me. Cloudflare offers to connect your Git repository directly, and if
you're already deploying from GitHub Actions you quietly end up with two pipelines publishing
the same site: yours, which runs checks, and theirs, which doesn't. Whichever finishes last
wins. A build my pipeline had correctly refused to ship could get published anyway. Two paths
to production means your gate is advisory, and an advisory gate is decoration.

Every row there is dull infrastructure work. Together they're the reason it's reasonable to
let an agent write most of the code — not because the code got more trustworthy, but because
being wrong got cheap.

In practice

Before handing something over I ask what it costs me if this ships broken and I find out in a
week. Two minutes and a revert, and I let it run without reading every line. Wouldn't find
out in a week, and I stop and build a check instead, because reading doesn't catch silent
failures and never has. Undo isn't in git, and I do it myself; it's ten minutes, once, and
it's the ten minutes that was actually worth my time.

The useful property of that rule is that it has nothing to do with how good the model is.
It's held up unchanged through three of them.

Originally published at The blast radius rule for AI coding.

Deploying a static site to Cloudflare Workers

Othmane ETTAIB — Tue, 01 Sep 2026 21:40:38 +0000

Originally published on indiecore.net.

I moved this site off a hosted blogging platform onto Cloudflare, with GitHub Actions doing
the building and Cloudflare doing the serving. It costs nothing, deploys in about two and a
half minutes, and refuses to publish anything that fails its checks.

Getting there took longer than it should have. Here is the setup, and the five things that
tripped me up — none of which are obvious from the documentation.

The shape of it

git push
   └─ GitHub Actions
        ├─ build          generate the site
        ├─ verify         dead links, missing images, bad metadata, broken redirects
        ├─ Lighthouse     fail if performance/accessibility/SEO drop below budget
        └─ deploy         upload to Cloudflare

The important part is that deploy depends on the checks. A broken build never reaches
the internet. Pull requests get a preview URL; merges to main go live.

The triggers and permissions that make that safe:

ci-cd.yml — triggers and permissions

name: CI/CD

# Build and verify every change; deploy previews for PRs and production from main.
# Deploy jobs depend on the quality gates, so nothing ships unverified.

on:
  push:
    branches: [main]
    # The SEO watch ledger is machine-written, is never part of dist/, and is
    # committed daily. Deploying the site again for it would be pure noise — and
    # would re-trigger the SEO ping through workflow_run every single day.
    paths-ignore:
      - '_source/seo-watch.json'
      # hub/ publishes to a different repo entirely and never reaches dist/,
      # so a change to it alone has nothing to deploy.
      - 'hub/**'
  pull_request:
    branches: [main]
  workflow_dispatch:

# Least privilege by default; individual jobs elevate only what they need.
permissions:
  contents: read

# Supersede in-flight runs for a branch, but never interrupt a production deploy.
concurrency:
  group: ci-cd-${{ github.ref }}
  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}

env:
  # wrangler ships as a pinned devDependency; never phone home from CI
  WRANGLER_SEND_METRICS: "false"

permissions: contents: read at the top means every job starts with the minimum, and only
the one that comments on pull requests gets more. The concurrency block cancels superseded
runs on a branch but never interrupts a production deploy.

Trap 1: "Upload assets" gives you a Worker, not Pages

Cloudflare has two products that host static sites: Pages, the older one, and Workers,
the current one. Their dashboard now puts the Upload assets button under Workers.

So you follow a guide that says "create a Pages project", you click the obvious button, and
you end up with a Worker. Your site is live at something.workers.dev, and the
something.pages.dev address every tutorial tells you to visit returns:

DNS_PROBE_FINISHED_NXDOMAIN

Nothing is broken. You simply never created a Pages project.

Both products work. Workers is the one Cloudflare is investing in, and it supports
everything a static site needs — I verified each of these on a live deployment:

Feature	Workers static assets
`_redirects`	yes
`_headers`	yes
Custom 404 page	yes
Custom domains	yes, if the nameservers are Cloudflare's

Pick Workers and stop worrying about pages.dev.

Trap 2: the API token needs the right template

To deploy from CI you create a scoped API token. The obvious move is to build a custom one
with a single permission. Don't.

A Worker deploy needs several permissions working together — Workers Scripts, plus read
access to account and user details. Miss one and you get:

Authentication error [code: 10000]

which tells you nothing about which permission is absent. Use the built-in
"Edit Cloudflare Workers" template instead; it ticks exactly the right boxes. Scope it to
your account and your zone, and give it an expiry.

If you already made a Cloudflare Pages · Edit token because you thought you were using
Pages, it will not deploy a Worker.

Test it before wiring it into CI:

export CLOUDFLARE_API_TOKEN=...
npx wrangler whoami

Ten seconds, and it prints the permissions it actually has.

Trap 3: wrangler turns things off when you're not looking

This one cost me the most time. Once you add a wrangler.jsonc, that file becomes the
complete description of your Worker — and anything absent from it is treated as disabled.

Deploy with a minimal config and you get:

▲ [WARNING] Because 'workers_dev' is not in your Wrangler file,
  it will be disabled for this deployment by default.

▲ [WARNING] Because your 'workers.dev' route is disabled and your
  'preview_urls' setting is not in your Wrangler file, Preview URLs
  will be disabled for this deployment by default.

Two warnings among the normal output, and easy to skim past. The result: my staging URL
started returning 404, and per-version preview URLs stopped being generated — which would
have silently broken pull request previews, since the CI job reads the preview URL out of
wrangler versions upload.

This is the job that publishes a preview per pull request, and reads the URL back out of
wrangler's output:

ci-cd.yml — preview job

  preview:
    name: Deploy preview
    needs: [build, lighthouse]
    # Skip where secrets are unavailable rather than failing:
    #  - fork PRs never receive them
    #  - Dependabot runs use a separate secret store, so repository secrets are
    #    empty even though the branch lives in this repo
    if: >-
      github.event_name == 'pull_request' &&
      github.event.pull_request.head.repo.full_name == github.repository &&
      github.actor != 'dependabot[bot]'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
      contents: read
      pull-requests: write
    environment:
      name: preview
      url: ${{ steps.deploy.outputs.url }}
    steps:
      - name: Checkout
        uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Set up Node
        uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7.0.0
        with:
          node-version-file: .nvmrc
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Download site
        uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # v8.0.1
        with:
          name: dist
          path: dist

      - name: Upload preview version
        id: deploy
        env:
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
        run: |
          set -o pipefail
          npx wrangler versions upload 2>&1 | tee upload.log
          url=$(grep -oE 'https://[a-z0-9-]+\.[a-z0-9-]+\.workers\.dev' upload.log | head -1)
          if [ -z "$url" ]; then
            echo "::warning::could not parse a preview URL from wrangler output"
          else
            echo "url=$url" >> "$GITHUB_OUTPUT"
          fi

      - name: Comment preview URL
        if: steps.deploy.outputs.url != ''
        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0
        env:
          PREVIEW_URL: ${{ steps.deploy.outputs.url }}
        with:
          script: |
            const marker = '<!-- cf-preview -->';
            const body = `${marker}\n**Preview deployed** → ${process.env.PREVIEW_URL}`;
            const { owner, repo } = context.repo;
            const issue_number = context.issue.number;
            const comments = await github.rest.issues.listComments({ owner, repo, issue_number });
            const mine = comments.data.find(c => c.body?.startsWith(marker));
            if (mine) await github.rest.issues.updateComment({ owner, repo, comment_id: mine.id, body });
            else await github.rest.issues.createComment({ owner, repo, issue_number, body });

A dashboard-created Worker has both on by default. Writing a config turns them off. Say so
explicitly — this is the whole config this site runs on:

wrangler.jsonc

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "name": "my-site",
  "compatibility_date": "2026-08-26",

  // Keep the *.workers.dev URL alive as a staging target, and keep per-version
  // Preview URLs on — the CI preview job publishes with `wrangler versions
  // upload` and reads the preview URL from its output. Wrangler disables both
  // by default when they are absent from this file.
  "workers_dev": true,
  "preview_urls": true,

  // Static-assets-only Worker: no server code, Cloudflare serves dist/ directly.
  // _headers and _redirects inside dist/ are honoured natively.
  "assets": {
    "directory": "./dist",
    // /about/ -> about/index.html, and strip .html from URLs
    "html_handling": "auto-trailing-slash",
    // unknown paths get dist/404.html with a real 404 status
    "not_found_handling": "404-page"
  },

  // Attaching the domains here rather than in the dashboard: `wrangler deploy`
  // creates the custom domains and their DNS records, and re-asserts them on
  // every deploy. custom_domain:true means Cloudflare manages the record and
  // the TLS certificate for each hostname.
  "routes": [
    { "pattern": "www.example.com", "custom_domain": true },
    { "pattern": "example.com", "custom_domain": true }
  ]
}

not_found_handling: "404-page" serves your 404.html with a real 404 status.
auto-trailing-slash makes /about/ resolve to about/index.html.

Trap 4: the Custom Domain dialog matches zones, not hostnames

Adding www.example.com through the dashboard gave me:

No zones match www.example.com.

I own the domain. www is a subdomain of it, covered by the same zone. But the dialog was
matching against zone names — typing example.com found it, typing www.example.com found
nothing.

The error offers a helpful-looking link to "add the domain to Cloudflare". Do not click
it. That wizard creates a separate zone for www.example.com and offers to import DNS
records into it. You would end up with two overlapping zones and a genuine mess.

The fix is to skip the dashboard. Those routes entries above create the custom domains and
their DNS records on deploy, and re-assert them every time — so the configuration can't drift.

One thing to know: attaching fails while an old record is in the way.

Hostname 'example.com' already has externally managed DNS records (A, CNAME, etc).
Delete them first or try a different hostname. [code: 100117]

Delete the old records for that hostname, then deploy again.

Trap 5: overlapping `_headers` rules concatenate

Cache headers looked right in my config:

/assets/images/*
  Cache-Control: public, max-age=31536000, immutable

/assets/*
  Cache-Control: public, max-age=86400

What actually came back over the wire:

cache-control: public, max-age=86400, public, max-age=31536000, immutable

Every matching rule is applied and the values are joined. An image matches both, so it
gets two max-age values in one header. Browsers take the first — 1 day — and the year-long
immutable cache silently does nothing.

I only caught it because I curled the response headers after deploying. Make the rules
non-overlapping:

/assets/images/*
  Cache-Control: public, max-age=31536000, immutable

/assets/fonts/*
  Cache-Control: public, max-age=31536000, immutable

/assets/app.js
  Cache-Control: public, max-age=86400

If your domain also handles email

This is the part that makes people nervous, so it's worth being plain about it.

Your domain has two independent groups of records:

Email lives in MX and TXT records (SPF, DKIM)
Website lives in A and CNAME records

Mail servers only read the first group. Browsers only read the second. Repointing your
website cannot affect mail delivery. The only way to break email is to delete an MX or
TXT record by hand.

So: change records one at a time, never use a bulk delete, and if a screen offers to remove
MX or TXT records, say no. Take a zone export first — Cloudflare has an Export records
button — and check afterwards:

dig +short MX example.com
dig +short TXT example.com | grep spf

Then send a real test email. DNS looking correct is not the same as mail flowing.

One deployment system, not two

The Worker's settings page offers to connect a Git repository. If you are deploying from
GitHub Actions, leave it empty.

Connecting it enables Cloudflare's own build system, and you end up with two pipelines
publishing the same site: yours, which runs checks, and Cloudflare's, which doesn't. They
race, and whichever finishes last wins. A build your pipeline correctly refused to ship can
get published anyway.

GitHub pushes to Cloudflare. Cloudflare never pulls.

Worth doing while you're in there

Verify the deploy actually landed. Change something with a visible fingerprint — a header, a version string — and curl for it. "The deploy succeeded" and "the new build is serving" are different claims.
Redirect old URLs, don't drop them. A _redirects file with 301 lines preserves search ranking and keeps any link you've published elsewhere working.
Budget your Lighthouse scores in CI. A number that only gets checked when you remember to check it will drift.

None of this is exotic. It is a static site on free hosting. But the gap between "it
deployed" and "it deployed correctly, and nothing else broke" is where the evening goes.

Originally published at Deploying a static site to Cloudflare Workers.

The code is on GitHub: Both files, ready to copy

DEV Community: Othmane ETTAIB

I don't review AI code. My build does.

The verifier

Every check has a bug behind it

The checks that pay for themselves are invisible

Numbers for the things a script can't see

Write the error message for the agent

What it doesn't do

The blast radius rule for AI coding

The sorting mistake I made first

Zone 1 — one command undoes it

Zone 2 — recoverable, but only if you notice

Zone 3 — the undo doesn't live in git

Why the agent can't make this call

Shrinking the radius beats classifying it

In practice

Deploying a static site to Cloudflare Workers

The shape of it

Trap 1: "Upload assets" gives you a Worker, not Pages

Trap 2: the API token needs the right template

Trap 3: wrangler turns things off when you're not looking

Trap 4: the Custom Domain dialog matches zones, not hostnames

Trap 5: overlapping _headers rules concatenate

If your domain also handles email

One deployment system, not two

Worth doing while you're in there

Trap 5: overlapping `_headers` rules concatenate