[Decisão] #117 / PR #123: a origem pública do site depende de um checkbox da Vercel que nenhum agente enxerga

[caioross]

O que está em jogo

A produção anuncia hoje uma origem que não serve o site:

$ curl -s https://code-racer-three.vercel.app/robots.txt
Host: https://coderacer.app
Sitemap: https://coderacer.app/sitemap.xml

$ curl -sIL https://coderacer.app/
301 → https://www.coderacer.app   (Squarespace)
503                                (Heroku)

Esse valor alimenta o canonical, o og:image, o <loc> do sitemap e o JSON-LD. Efeito prático:
todo link de sala compartilhado está sem preview, e a indexação é atribuída a um domínio de
terceiro. É a issue #117.

O que a frota fez e onde travou

A PR #123 troca o literal https://coderacer.app por uma origem derivada do deploy. Passou por
dois quóruns adversariais (3 lentes cada). O primeiro (afc4f10) foi 3×VETA; reparei; o segundo
(a80cdef) foi vetado de novo. O §7.2 manda escalar depois de um reparo — e aqui a escalada não
é formalidade: o desfecho correto depende de um fato que só você enxerga.

A cadeia derivada depende das System Environment Variables do projeto na Vercel. A doc da
plataforma diz que VERCEL=1 significa literalmente "system environment variables have been
exposed" — ou seja, VERCEL e VERCEL_PROJECT_PRODUCTION_URL estão atrás do mesmo checkbox:

checkbox "Enable access to System Environment Variables"	o que acontece no deploy
ligado	origem = domínio de produção do projeto → #117 resolvida
desligado	nenhuma variável existe → produção anuncia http://localhost:3000 em silêncio

Tentei observar o projeto para eliminar a dúvida e não consigo: o code-racer vive no team
caiorossi-projects1, que responde 403 ao token da frota (get_project, build_logs). O
preview da PR também está atrás do SSO da Vercel. Nenhum agente consegue saber qual das duas
linhas é a verdadeira antes do merge — e merge é deploy.

Opções

A) Você define NEXT_PUBLIC_SITE_URL no painel da Vercel (Settings → Environment Variables, os
três ambientes), com a URL que realmente serve o site — https://code-racer-three.vercel.app ou o
domínio próprio que você pretenda apontar.
· Resolve a #117 hoje, sem código e sem risco — essa variável tem precedência sobre tudo, no
código atual e no da PR.
· A #123 vira endurecimento opcional (a parte dela que ninguém vetou: sanear a origem antes de ela
ir para o robots.txt/sitemap/JSON-LD).
· É a minha recomendação.

B) Você autoriza a frota a tornar a guarda independente do checkbox. O sinal passaria a ser
NODE_ENV === "production" só na fase de build (nunca em runtime — ver o achado abaixo), mais
uma linha de env no .github/workflows/ci.yml para a CI não quebrar. Mexer na CI é área de quórum
(§7.2), não núcleo, mas prefiro seu aval porque muda o que acontece quando um deploy futuro perde
a variável: passa a falhar o build em vez de publicar origem errada.

C) Nada de guarda: a #123 fica só com o saneamento da origem + o risco documentado honestamente,
e um curl pós-deploy confere o resultado. Se o checkbox estiver desligado, a produção troca um
domínio 503 por localhost até alguém notar.

Por que não mergeei mesmo com a PR "pronta"

Além do impasse acima, o meu próprio reparo introduziu um defeito que as lentes pegaram e eu
confirmo: o throw que eu adicionei vive em escopo de módulo, e site.ts é importado por
layout.tsx, opengraph-image.tsx (edge), robots.ts, sitemap.ts e manifest.ts — então ele
não é uma guarda de build, roda a cada cold start. Medido: servindo um build bom com a variável
ausente em runtime, /, /room/<code>, /leaderboard e /opengraph-image devolvem HTTP 500.
Trocaria dano de SEO por indisponibilidade. Isso será desfeito seja qual for a opção escolhida.

O que preciso de você

Uma linha basta: o checkbox de System Environment Variables está ligado no projeto code-racer?
E, se você preferir a opção A, qual origem é a canônica — https://code-racer-three.vercel.app ou
um domínio próprio que você vá apontar?

Enquanto isso a PR #123 fica em DRAFT com decisao-dono, e a #117 segue aberta.