github-pages-deploy-verificationlisted

# GitHub Pages deploy verification ## Problem Two failure modes when verifying that a deploy is live via `curl`: 1. **False-positive poll predicate.** Polling `until curl ... | grep -q "<selector>"; do sleep; done` succeeds instantly if the selector existed before the deploy too. The loop exits on the OLD content; you think you've verified the new state and you haven't. 2. **Blocked timing chain.** `sleep 35 && curl ...` looks reasonable but the Claude Code harness blocks long leading sleeps inside Bash to prevent dead polling. Worse, even short `sleep N && curl` followed by additional pipes can hit "Blocked: sleep N followed by:" errors that cancel parallel tool calls. Both bugs hit one session inside ~30 minutes. They are not in the same family but they ride the same task. ## Context / Trigger Conditions Any of: - About to push to a branch where merge = production deploy (GitHub Pages legacy mode, Netlify Git, Vercel Git, etc.) - The platform's own deploy-status API is known to lag (e.g., `gh api repos/.../pages/builds/latest` can report stale `building` long after content is live, or report `built` before the CDN catches up) - A task isn't "done" until you've confirmed the new HTML/CSS/JS is served, not just merged ## Solution ### Pick the poll predicate correctly The string you grep for **must be content that did not exist pre-deploy**. Concretely: - ✅ Grep for a new CSS rule, new class, new token value, new copy string, new commit hash