Os links de Dockerfile/Jenkinsfile/k8s apontavam para caminhos
absolutos do WSL de uma máquina específica (quebrados desde o
primeiro commit). Trocados por caminhos relativos.
Adiciona: fluxo de build/start local de produção, passo a passo de
aplicar o secret via create-secret.sh, explicação do patch em
patches/ (postinstall) e nota sobre o preset node-server do nitro.
Essas funções tocam módulos *.server.* (sessão em cookie, conexão
SQL Server) mas eram funções soltas, então o TanStack Start acusava
"import denied in client environment" ao analisar o grafo de import
que chega em auth.ts a partir de rotas renderizadas no cliente.
Na prática já eram seguras (só chamadas de dentro de handlers
createServerFn, que rodam só no servidor), mas createServerOnlyFn
torna isso explícito e reconhecido pela análise estática do
framework, além de lançar erro em vez de rodar se algum dia forem
chamadas do lado do cliente por engano.
@tanstack/start-server-core cria o defaultCsrfMiddleware de forma
incondicional assim que o módulo carrega. Isso caía numa corrida de
inicialização com o import circular que o nitro gera nos chunks de
SSR (server-D-dARpA7.mjs <-> server-D-dARpA72.mjs), fazendo toda
requisição no build de produção falhar com "createCsrfMiddleware is
not a function".
Reproduzido de forma determinística tanto com preset node-server
quanto cloudflare-module, e com múltiplas versões do nitro — não é
regressão de versão, é a inicialização eager em si colidindo com a
ordem de avaliação do ciclo.
Patch (via patch-package, reaplicado no postinstall) adia a criação
do defaultCsrfMiddleware para dentro de uma função, eliminando a
corrida sem mudar nenhum comportamento. Validado com reinstalação
limpa de node_modules + build + smoke test em /healthz, / e /auth.
Remove .lovable/, AGENTS.md (banner de sync), bun.lock/bunfig.toml
(não usados, o build é via npm), lovable-error-reporting.ts, a
dependência @lovable.dev/vite-tanstack-config e o branding Lovable nas
metatags. vite.config.ts passa a configurar os plugins do TanStack
Start/Tailwind/nitro diretamente, sem o wrapper deles.
Nisso, corrige um bug crítico: o preset do nitro estava em
cloudflare-module (gera um Cloudflare Worker), mas o Dockerfile roda
o build direto com `node`. O container subiria sem escutar em porta
nenhuma e o /healthz falharia sempre. Preset trocado para node-server.
Credenciais reais (senha do SQL Server e SESSION_SECRET) estavam
commitadas em texto plano. O arquivo segue local (ignorado pelo git);
as chaves esperadas ficam documentadas em .env.example.
joao.herculano