Thank you — the CLI scope fix worked. Using VERCEL_ORG_ID set to my personal account ID (not the team ID/slug) resolved the “Could not retrieve Project Settings” error, and vercel --prod --yes completed a real deployment through the build pipeline: • Deployment ID: dpl_GmoWZP84yGwJaBoa2oGxT3DmXfYB • readyState: READY, target: production, aliased to https://liveyourbeastlife.com
However, this did not resolve the original issue. Both script routes still return 404 on the live domain after this CLI-built deployment: • https://www.liveyourbeastlife.com/2DqTyuSFzJXsH9N92Dm3l421K/script.js → 404 • https://www.liveyourbeastlife.com/0jzk2llPkZ1EpdSU1gS65rmvviJ/script.js → 404 One detail from the CLI output that may be relevant: during the build, the CLI printed this warning even though the deployment succeeded and was aliased correctly: WARN! Failed to read build logs: Error: Not authorized: Trying to access resource under scope “lotus-enterprise”. You must re-authenticate to this scope or use a token with access to this scope. (403) This suggests my account may have a scope-resolution inconsistency specific to this project/team setup — my token’s team appears to be my personal account’s default scope rather than a true multi-seat team (GET /v2/teams returns an empty list for this account, while GET /v2/user shows defaultTeamId matching the team ID used everywhere else). It’s possible the analytics route injection step is being blocked by this same scope-authorization gap, even though the deployment itself completes. Could you check server-side whether the analytics/speed-insights route generation for deployment dpl_GmoWZP84yGwJaBoa2oGxT3DmXfYB actually ran, and if not, why it would be skipped for an otherwise-successful CLI production deployment?