cloudflare-pages-stale-assetslisted

# Cloudflare Pages Stale Assets Use this before changing UI code again. First prove whether the failure is deployment, domain routing, edge/browser cache, or runtime JavaScript. ## Workflow 1. Confirm the repo state: - Read project agent rules first. - Check the current branch, latest commit, and dirty files. - Identify the exact generated/static output directory used by Pages. 2. Compare every live hostname: - Fetch `https://<pages-project>.pages.dev/`, the apex custom domain, and `www`. - Add a cache-busting query to HTML, CSS, and JS URLs, for example `?codex_check=<timestamp>`. - Record status, redirect target, `ETag`, `CF-Cache-Status`, `Age`, and whether the expected new code appears. 3. Distinguish failure layers: - Deployment: latest commit is not in the live HTML. - Domain routing: `pages.dev` is current but custom domain is stale or SSL/route-broken. - Asset cache: HTML is current but references unversioned old CSS/JS. - Browser cache: network fetch is current but the user's browser still displays old assets. - Runtime: assets are current but console errors prevent enhancement. 4. Fix at the owning layer: - If production branch is wrong, fix Pages branch control or redeploy the intended branch. - If custom domain differs, fix Pages custom domain binding and DNS before editing UI. - If stale CSS/JS is plausible, version static asset URLs in every HTML page, such as `style.css?v=<release-id>` and `language.js?v=<release-id>