ci: ramp production from Actions, and stop trusting an empty variable

[oddharsh]

Four release steps ran on a workstation or not at all. Three move to the repo here.

The ramp

.github/workflows/ramp.yml is new, and CLAUDE.md has described it since
2026-08-06 without it ever existing: no such workflow in any commit, environments
copilot/production rather than the canary/full pair, and no write token. What
landed that day was the release-guard.mjs rewrite alone, which asks whether a
process can authenticate rather than whether it is CI. That rewrite is what makes
this possible; the pipeline it was clearing the way for is what was missing.

It splits at the human instead of removing them:

job	traffic	environment	gate
canary	10%	production-canary	none, runs on its own
full	50% then 100%	production-full	required reviewer
verify	none	none, no credential	runs dcz:check

A merge reaches a tenth of traffic by itself and stops. Approving full in the
Actions tab is the same decision you were making at a terminal. A workstation ramp
keeps working unchanged, and rollback stays a workstation command.

Three parts are load-bearing rather than incidental:

• It checks out production, never main. The ramp writes the D1 changelog by
  diffing the checked-out checkpoints.json against D1, so the tree has to be the
  one that was built and uploaded. That is gotcha 24 solved rather than relocated:
  CI cannot ramp from a stale tree, and cannot ramp from one running ahead of
  what is serving either.
• full refuses a version the canary never saw. Approval is asynchronous and
  Workers Builds uploads a version for every push, so re-resolving the newest
  production build after an approval could put traffic on something nothing
  canaried, silently, with every downstream check passing because a version that
  built returns 200s.
• Every step goes through pnpm run. deploy-promote.mjs shells out to npx wrangler, and npx resolves whatever it can find: measured in a tree with no
  node_modules, npx wrangler --version answered 4.105.0 from its own cache
  while this repo pins 4.120.0. Under pnpm run, node_modules/.bin comes
  first.

Both environments restrict deployments to main, which is not tidiness.
workflow_dispatch can target any branch carrying the workflow file, so without a
branch policy anyone able to push a branch could ship a modified ramp.yml and
read the token out of it.

checkpoints:check

Deliberately unwired until now ("NOT wired into the PR job by default", its own
header) because it needs a D1 read. It needs no new credential: D1:Read is
already one of the six scopes on CLOUDFLARE_API_TOKEN.

Fatal on drift, which is safe because the script already tells a staged release
apart from a rewrite: rows above D1's newest that form a contiguous tail report as
pending. So a PR staging v187 passes, and only a row rewritten below D1's newest,
or a broken sequence, fails. Tiered on the token the way infra:check is, since
failing a fork PR for not holding a secret is a worse check than no check.

og-cards

og-cards.yml bakes the cards on a runner and opens a PR, with an only input
mapping to OG_ONLY.

Dispatch-only, never scheduled. The cards capture production so data-driven
demos render populated, and the photo grid, live counters and routing prober are
not deterministic between runs, so a nightly job would open a PR of changed PNGs
every night that meant nothing. dictionary-roll.yml can be nightly because its
output is a pure function of what production serves; this is not that.

An empty variable, found on the way

ci.yml passed CLOUDFLARE_ACCOUNT_ID: ${{ vars.CLOUDFLARE_ACCOUNT_ID }} to
infra:check, and no repository variable of that name has ever existed (gh variable list returns nothing), so it expanded to "" on every run. It reads
scripts/print-account-id.mjs now.

This is hardening, not a repair, and an earlier version of this PR body claimed
otherwise. checkApi() falls back to GET /accounts and only degrades when the
count is not exactly 1; the scoped CI token sees exactly one, so the account tier
was asserting normally. Measured on either side of this change: infra ok: 44 checks passed, 1 skipped or advisory, with the one advisory being the documented
CodeQL default-setup note and no token sees N accounts warning in either run.
The two-account fact belongs to the owner's interactive wrangler login, which is a
different credential from the CI token, and conflating them is what produced the
wrong claim.

What the helper buys here: a value that cannot be silently empty, cannot drift
from the account the deploy targets (it is that string), and one fewer API call.
Where it is genuinely required is the ramp — release-guard.mjs returns an
error unless CLOUDFLARE_ACCOUNT_ID is set in CI, unconditionally, so the canary
and full jobs cannot authenticate without it.

What did not need building

Checked rather than assumed:

• md twins are build output, regenerated every build, with checkTwinFacts()
  pinning the hand-written ones against the Worker in both directions.
• photos already have photo-pipeline.yml plus photos:check in CI.
• dictionaries already have dictionary-roll.yml.

Before merging

You have to mint the token; I can't. Create a Cloudflare API token scoped to
Workers Scripts:Edit + D1:Edit and nothing more, then add it as
CLOUDFLARE_API_TOKEN_RAMP on both environments (Settings, Environments) —
never as a repo secret. Until it exists the canary job fails at the first
wrangler call, having moved nothing.

The two environments are already created and configured: production-full has you
as required reviewer, both are restricted to main.

One gap left on purpose. The environments are not declared in infra.json, so
deleting the required reviewer would remove the gate silently, which is exactly the
failure the ruleset declarations exist to catch. Asserting environments in
check-infra.mjs is the follow-up, kept out of the change that created them.

244 contract tests, typecheck, build and pages:check pass; checkpoints:check
passes against live D1 (122 released, newest v186).

[github-actions]

Wire-size diff vs merge base

95b5670 → 47b6ed5

Brotli q11, the quality the edge serves. Every number here is deterministic:
an unchanged file produces no row. Advisory — this check fails on nothing.

Client assets

No change. 19 files, 68.07 KiB Brotli total.

Pages

No change. 48 files, 492.15 KiB Brotli total.

Worker bundle

No change. 276.59 KiB gzip.

Dictionary deltas (pd/)

No change. 144 deltas, 444.99 KiB total.

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Updated (UTC)
✅ Deployment successful! View logs	aadhar-sh	1afac19	Aug 12 2026, 09:10 PM

[oddharsh]

On the two bot comments

Neither needs a change, and one of them is good news.

wire size vs merge base: no change on every category — client assets, pages,
Worker bundle and dictionary deltas all flat. Worth noting because on #340 this same
job reported +484 KiB from a base that measured zero; that was the reorg renaming
the asset root out from under the measurement script. It reads www on both sides
now and reports normally, which is the confirmation that artifact is gone.

cloudflare-workers-and-pages is a success notice for the branch build.

On github-advanced-security

Failed for the eighth recorded time with the same crash, and it never read the diff:

Error creating PR review request: SessionModelError: Execution failed:
CAPIError: 400 The requested model is not supported.

title: null, summary: null, and Analyze (actions) + CodeQL both passed on
this commit. That is CLAUDE.md gotcha 27, it is not a required check, and no push
turns it green.

What I fixed anyway

Not because the bot asked, since it never looked. A PR that adds workflows handling
a write-scoped secret deserves reading for the hazard specific to workflow code, so
I grepped my own YAML for expressions interpolated straight into run: blocks and
found four (a76ea18).

A ${{ }} expansion is substituted into the script text before bash parses it,
so a value carrying shell metacharacters executes. The one that mattered was
inputs.base in og-cards.yml: a URL somebody types into the dispatch form. The
other three were already constrained (a hex prefix the canary matched with a regex,
and a literal true/false).

All four go through env: now. Dispatching needs write access so this was hygiene
rather than a hole, but the safe shape should be the habit rather than a judgement
call per value.