deploy-qalisted

# Deploy QA What to test after a push, decided from what actually changed. Two failure modes this exists to prevent. One is testing nothing, because the change "was small". The other is running the same forty step checklist for every change, which people stop doing honestly by the third time, and a checklist that gets rubber stamped is worse than none: it produces a record saying the thing was verified. The depth comes from blast radius, not from habit. Read `.claude/project-profile.md` for the deployed URL and the commands. This skill runs **after** the release: [`deploy`](../deploy/) gets the build out, this one checks whether it survived contact with production. ## Step 0 · Prove the new build is live Before testing anything, confirm you are testing the new code. This step exists because of how often it is the answer. A deploy reports success and serves the previous bundle. A platform shows green while the container failed its health check and rolled back. Someone spends forty minutes concluding the fix did not work, and the fix was never there. Check, in order: 1. **The platform says the new version is healthy.** Not "deploy finished". Healthy, and running the commit you expect. 2. **The served artifact changed.** Asset hash, build id, or a version endpoint. Compare against what was there before. This is the one that catches the lie. 3. **The logs are clean on boot.** Repeated 404s on your own API usually mean a handler that exists in the repo and was ne