NestJS Git deployment fails with TS2353, but vercel build succeeds locally

We're seeing a discrepancy between Vercel's local CLI build and Git-triggered cloud deployments for a NestJS monorepo.

Repository:

Turborepo
NestJS API
Next.js frontend
Node 22

What we've verified:

✅ pnpm install ✅ pnpm build ✅ pnpm typecheck ✅ GitHub Actions passes ✅ vercel build --yes passes locally (including Vercel's TypeScript 5.9.3 compilation)

However, Git-triggered deployments consistently fail during the additional NestJS/@vercel/node compilation with TS2353 errors stating that status and updatedAt do not exist.

We've already verified:

generated declarations
package exports
path mappings
clean rebuilds
cache-disabled deployments
fresh clones
complete type-chain audit

No repository-side issue has been found.

We also tried:

vercel deploy --prebuilt

but that currently fails before upload with:

File does not exist: apps/api/node_modules/reflect-metadata

So we have not yet been able to determine whether a prebuilt deployment avoids the TS2353 issue.

Has anyone encountered a situation where:

vercel build succeeds locally
but the Git-based cloud build fails with different TypeScript results?

If so, what differences between the local CLI build and the cloud Git builder should we inspect?

Deployment ID: dpl_77oaB3xv8M35gyX27fB2VFsZJGrS

The cleanest next test would be a remote source deployment of the exact same commit, without --prebuilt.

From the monorepo root, linked to the same Vercel project:

git checkout <failing-commit-sha>
vercel deploy --target=preview --force --logs

This differs from vercel build: the source is uploaded and built remotely, but the deployment does not originate from the Git integration.

The result should narrow the boundary considerably:

If it fails with the same TS2353 errors, the Git integration is probably not the differentiator. The next place to inspect is the entrypoint and TypeScript configuration selected by the additional @vercel/node compilation.
If it succeeds, the stronger suspects are the Git deployment's source boundary and project configuration, particularly Root Directory, lockfile detection, and whether files outside the Root Directory are included.

I would keep the reflect-metadata error from --prebuilt separate for now. A prebuilt deployment uploads .vercel/output, so that error may point to a missing or unresolved reference inside the generated output rather than the cause of the TS2353 errors.