Motir

Repo: motir-core. No PR — this starts as a LOG READ. Surfaced while getting MOTIR-1150's CI green: every other check on that PR passes and the Vercel context does not. It is not that branch's diff.

The evidence that it is repo-wide, not one branch

Vercel commit status on origin/main, newest last:

And on the open PRs, checked the same day: #1910, #1913, #1916 and #1914 all show Vercel: fail. So the failure is not a property of any one diff — and the one green in the middle (44e55eff, a Markdown-only change) suggests it is not deterministic on content either.

The build is NOT the failure. Next.js build passes in GitHub Actions on every one of those commits, and next build passes locally on the MOTIR-1150 branch. Whatever Vercel is refusing happens after or around the build — a platform-side condition (quota / build minutes / plan limits / a project-setting or env change) rather than a compile error.

Why this is manual and starts with a human

The only diagnosis that means anything is the deployment's own log, and reading it needs the Vercel account:

npx vercel inspect dpl_5ZFSzTNNHp2rK2rXwiZHJm4Bx6C3 --logs

(that id is MOTIR-1150's; any of the failures above will do). A coding agent has no Vercel credential and must not go looking for one, so guessing from the outside is exactly the "a config file is a claim about the deployment, not a reading of it" trap — read the platform, don't theorise.

What to do

1. Read the log for one failing deployment (command above, or the dashboard). Record the actual error on this card — that is the deliverable of step 1, and it decides everything after.
2. Check the account-level conditions the log will point at: build-minutes / bandwidth quota, plan limits, a payment state, and whether Production and Preview env vars still carry what next.config.ts and the app's process.env reads expect.
3. Then either fix it in the dashboard (a manual step, done here) or split out a code card if the log names one — do not fold a code fix into an unrelated PR.

Why it matters more than a red tick

• Every PR's preview URL is dead, so nobody can look at a change before merging it — on a repo whose review protocol is Yue accepting Stories BY HAND (Principle #18), that removes the acceptance surface.
• main failing to deploy means production is running whatever last deployed successfully, which is now several merges behind. Anything merged since ad7e402a is on main and not on the site.
• A red check that everyone learns to ignore is worse than no check: the next real deployment failure will look identical to this one.

Acceptance criteria

• The actual Vercel error is quoted on this card, from the deployment log — not inferred from the GitHub status line, which says only "Deployment has failed".
• A deployment on main succeeds, and the commit is named here.
• A PR's preview deployment succeeds, and its URL is named here.
• If the cause was an account/quota/settings condition, the setting and its new value are recorded, so the next occurrence is diagnosable from this card alone.
• If the cause was in the repo, the fix ships as its OWN card and PR, cross-referenced here.

Context refs

• The failing deployment on MOTIR-1150's PR: dpl_5ZFSzTNNHp2rK2rXwiZHJm4Bx6C3 — https://vercel.com/zhuyue11s-projects/motir-core/5ZFSzTNNHp2rK2rXwiZHJm4Bx6C3
• On main @ 8c42971c: dpl_9EU5ZYVXxj2h5EaokTaVVdMcrmTb
• .github/workflows/ci.yml — the Next.js build job that passes, which is what makes this a deploy-side question rather than a compile one.
• next.config.ts — carries outputFileTracingIncludes as of MOTIR-1150; noted only so the log read can rule it in or out, NOT as a hypothesis (the failures predate it).