bld-util-deploylisted

# Deploy an app (GitHub → Vercel) Take an existing local app folder and put it online with a shareable `*.vercel.app` URL. ## First: is this app ALREADY deployed? Check for `<app>/.vercel/project.json` (and a git remote). **If it exists, skip the whole first-time sequence below — "deploy" now just means push the current changes:** ```bash git -C <app> add -A git -C <app> status --short # sanity: no real .env/secret staged git -C <app> commit -m "<what changed>" git -C <app> push # auto-redeploys via the connected repo (~30s) ``` Then verify the new build actually went live (the production alias sometimes lags): ```bash vercel ls <app> --cwd <app> # newest deployment should be ● Ready # If the alias is stale, promote the deployment that is ALREADY built: vercel promote <deployment-url> --yes --cwd <app> # `vercel --prod` is NOT a promote. It uploads and builds whatever is on disk # right now, which is only the same thing if the working tree matches the commit # that was pushed. Reach for it to deploy, never to fix a stale alias. ``` That's the entire job for an established app. The rest of this file is **first-time setup only**. > Note: `git push` already redeploys — you do **not** run `/bld-util-deploy` after every > change. Deploy is an explicit, user-requested step (see the deploy-discipline rule > in the workspace `CLAUDE.md`). Develop and verify locally; ship when the user says so. ## Ground rules - Repos go on the **perso