cloudflare-opslisted

# Cloudflare Ops Operational Cloudflare/Wrangler work: project wiring, D1/KV/R2, env layout, and safe migrations. **Deploy-and-prove** remains the skill for “ship immutable source and prove production serves it.” ## Safety - Confirm account/target (workers.dev vs custom domain, preview vs production) before mutating remote state. - Never print secret values, commit `.dev.vars` with real secrets, or broaden public env prefixes to make a build pass. - Prefer read-only inventory first (`wrangler whoami`, list DBs/buckets, show migrations pending). - Back up D1 (or export) before destructive migrate/reset when data may exist. - Do not treat a successful `wrangler deploy` CLI exit alone as product proof — hand live behavioral proof to `deploy-and-prove` when the user wants “is it live?” ## Workflow 1. Read repo Cloudflare docs: `wrangler.toml` / `wrangler.jsonc`, `package.json` scripts, existing D1/KV/R2 bindings, and environment names. 2. Inventory remote vs local: login, account, workers/pages projects, D1 databases, KV namespaces, R2 buckets, pending migrations. 3. Plan ops explicitly: create resource, bind, migrate, backup, secret set, multi-env split, or proxy/route change. Call out data risk. 4. Apply the smallest authorized change with official Wrangler/CLI (no house wrapper scripts unless product-specific glue is required). 5. Verify with independent readback: resource exists, binding name matches code, migration applied, secret keys present (not values), routes/DNS a