Cloudflare Workers Safe Overlay

# Cloudflare Workers Safe Overlay

Built by Dead Brands (deadbrands.co).

Ship Worker or Pages changes as small overlays: know the live version first, deploy narrowly, verify bytes, keep a rollback id.

## Purpose

Teach an outside operator how to update a Cloudflare Worker or Pages project without wiping newer files, and how to prove the public URL matches what you meant to ship.

## When to use

- You are patching one route, one asset, or one Worker script on an already-live project.
- A previous full upload erased newer content.
- You need a rollback id before touching production.

## Limits

- Do not print API tokens, account secrets, or private bindings in receipts or chats.
- Prefer overlay / single-file deploys over full-directory publishes when only a slice changed.
- DNS, custom domains, and plan changes need an owner gate.
- "Deploy succeeded" in the CLI is not proof — fetch the public URL.
- This skill does not change your Cloudflare plan or billing.

## Steps

1. Record the current live version id (Worker version or Pages deployment id) before any change.
2. Diff only the paths you intend to change; stage those paths alone.
3. Deploy the overlay; capture the new version id as the rollback target for the next change.
4. Fetch the public URLs for every changed path; compare status code and a content hash or clear substring.
5. Fetch one unchanged control path to confirm you did not clobber neighbors.
6. File a short receipt: previous version, new version, paths, verify times, pass/fail.

## Examples

Input: Patch `/hub/skills/index` copy on a Pages project; leave blog posts untouched.

Output:
- Previous deployment id saved.
- Overlay uploads only the skills index files.
- Live fetch of the skills index shows the new sentence; a blog post URL still matches its prior hash.
- Receipt lists both version ids and the control-path check.