(starter) `Cleanup preview deployments` fails on EVERY PR close — the repo has no Vercel config, so a workflow with nothing to do red-lights every merged PR

Found while confirming MOTIR-2690's merge. PR #13's own checks are green — Lint + Prettier, TypeScript, Unit tests, Next.js build, Playwright E2E all pass, and CI on main is green after the merge. The single red X is a different workflow, on a different event, that has been failing since long before this card.

What fails

.github/workflows/cleanup-preview-deployments.yml runs on pull_request: closed and hard-exits in its first step:

##[error]Missing required configuration: secrets.VERCEL_TOKEN vars.VERCEL_ORG_ID vars.VERCEL_PROJECT_ID
env:
  VERCEL_TOKEN:
  VERCEL_ORG_ID:
  VERCEL_PROJECT_ID:

None of the three is set on this repo. The step is written to exit 1 when any is missing, so the job dies in ~2 seconds having done nothing.

It is not new, and not caused by any recent diff

Same failure on every PR close in the run list:

The workflow has nothing to clean up

• gh api repos/…/deployments returns 0.
• No vercel.json, no .vercel/ — the repo is not linked to a Vercel project.
• motir-core carries no such workflow; this is starter-only, from MOTIR-24.

So it is not failing to do its job. It is failing to do nothing.

Why the loud failure exists — and where it overshoots

The hard exit is deliberate and the reasoning in the file's header is sound: with the Vercel-Neon Marketplace lifecycle, DB preview branches are reaped by deployment deletion, not branch deletion, so a cleanup job that silently no-ops lets branches accumulate until previews start failing with Resource provisioning failed. A silent skip there would be the same fail-open shape MOTIR-2499 and MOTIR-2690 exist to remove.

But that reasoning covers partial configuration — a token set and a project id forgotten — which really is a misconfiguration worth shouting about. It does not cover zero configuration, which just means this repo does not use Vercel previews. Treating "never opted in" the same as "half configured" is what produces a permanently red check.

Acceptance criteria

• With none of the three values set, the workflow does not report failure. A clean skip (job-level if:) or an explicit early success is fine; a red X is not.
• With some but not all set, it still fails loudly and names exactly which are missing — that path is a real misconfiguration and must not be softened.
• With all three set, behaviour is unchanged: enumerate and delete, 404 tolerated, any other non-2xx a hard failure, an API .error a hard failure.
• The header comment records the three-way split so the next reader does not re-soften the partial case.
• Whatever the mechanism, a scaffolded project's first merged PR does not show a red check attributable to config its author was never asked for. If a skipped job still renders a neutral check, say so in the README's CI section rather than leaving it unexplained.

Context refs

• nextjs-prisma-vercel-starter/.github/workflows/cleanup-preview-deployments.yml — the workflow; the Verify required config is set step is the exit.
• Run 31532687190 — the failing job on #13.
• nextjs-prisma-vercel-starter/.github/workflows/acceptance-video.yml — the MOTIR-1958 precedent for a lane that is absent rather than failing when it does not apply.
• MOTIR-24 — where the workflow came from.