scripts/cf-error-pages/ (PR #656) carries two hand-maintained copies of facts that live elsewhere in the repo. Neither has a guard, and both fail silently — the pages keep deploying, they just stop being correct.
1. Design tokens. build.mjs inlines the :root palette from packages/ui/dist/uploads-ui.css:
const TOKENS = `
--bg: #0a0a0b;
--panel: #121214;
--line: #232327;
...
`;
The inlining is deliberate and can't be removed — a page shown because the origin is unreachable cannot fetch a stylesheet from that origin. But if the DS palette shifts, the error pages keep rendering in the old colors until someone notices and reruns build + deploy.
2. The storage host set. pages.mjs hardcodes which hosts the custom error rule matches:
expression: '(http.host in {"storage.uploads.sh" "store.uploads.sh" "embed.uploads.sh"} and http.response.code eq 404)',
This has already gone wrong once. The first pass omitted store.uploads.sh — documented in the "Dual public hosts" table in docs/ops.md as a durable public URL, resolving objects identically — so dead links there still returned the generic 27 KB Cloudflare page until it was caught during PR review. A fourth public storage host added later would reintroduce exactly that gap, silently.
Suggested fix
A test in the root vitest project asserting both:
- every
--<name>: <value> in TOKENS matches the corresponding declaration in packages/ui/dist/uploads-ui.css
- the host set in the rule expression matches the storage hosts documented in
docs/ops.md (or, better, a single exported constant that both the rule and the docs table are generated from)
The second is the higher-value half — the token drift is cosmetic and self-evident once someone looks at a page, whereas a missing host is invisible until a user hits a dead link.
Notes
- The build is not currently wired into CI at all; it only runs when someone deploys. A test would be the first thing that exercises it on every PR.
- Rendered HTML is gitignored (
dist/), so a golden-file snapshot test would need to build first — cheap, the build is pure string templating with no network or browser.
Context: docs/ops.md → "Cloudflare error pages".
scripts/cf-error-pages/(PR #656) carries two hand-maintained copies of facts that live elsewhere in the repo. Neither has a guard, and both fail silently — the pages keep deploying, they just stop being correct.1. Design tokens.
build.mjsinlines the:rootpalette frompackages/ui/dist/uploads-ui.css:The inlining is deliberate and can't be removed — a page shown because the origin is unreachable cannot fetch a stylesheet from that origin. But if the DS palette shifts, the error pages keep rendering in the old colors until someone notices and reruns build + deploy.
2. The storage host set.
pages.mjshardcodes which hosts the custom error rule matches:This has already gone wrong once. The first pass omitted
store.uploads.sh— documented in the "Dual public hosts" table indocs/ops.mdas a durable public URL, resolving objects identically — so dead links there still returned the generic 27 KB Cloudflare page until it was caught during PR review. A fourth public storage host added later would reintroduce exactly that gap, silently.Suggested fix
A test in the root vitest project asserting both:
--<name>: <value>inTOKENSmatches the corresponding declaration inpackages/ui/dist/uploads-ui.cssdocs/ops.md(or, better, a single exported constant that both the rule and the docs table are generated from)The second is the higher-value half — the token drift is cosmetic and self-evident once someone looks at a page, whereas a missing host is invisible until a user hits a dead link.
Notes
dist/), so a golden-file snapshot test would need to build first — cheap, the build is pure string templating with no network or browser.Context:
docs/ops.md→ "Cloudflare error pages".