Os quatro apareceram ao exercitar o layout de runtime da imagem — apenas
node_modules de produção, src, scripts e migrations — e nenhum aparecia na
suíte de testes nem no build. Os dois primeiros formavam uma armadilha mútua.
1. O CLI do `tsx` cria processo filho (PIDs medidos: 20840 contra 21096).
O SIGTERM do `docker stop` pararia no pai, o worker nunca rodaria o
handler, o lock esperaria o TTL de 120s e o `stop_grace_period` só
atrasaria um SIGKILL. Passa a ser `node --import tsx`, mesmo processo.
2. Top-level await nos scripts falha com `--import tsx`, porque sem
`"type": "module"` o esbuild gera CJS. `migrate`, `worker`, `seed-staging`,
`flag`, `cleanup` e `check-bucket` não executariam: a migração não rodaria
e o worker não subiria. `runScript`/`runWithDb` resolvem sem mudar o
module type do projeto.
3. `import "server-only"` em `worker-loop.ts`: o pacote lança fora do bundler
do Next, e o worker morria no start.
4. `@react-pdf/renderer` carregado no import de `process-job.ts` falha com
ERR_PACKAGE_PATH_NOT_EXPORTED ao resolver a hifenização fora do bundler,
derrubando worker e cleanup. O PDF sai sob demanda no download, então o
import passou a ser tardio, dentro do ramo que o usa.
Além disso:
- O loop do worker saiu do script para `worker-loop.ts`, testável sem subir
processo. O script cuida só de sinais, cadência e bootstrap.
- Desligamento gracioso espera o tick corrente para o `finally` liberar o
lock. Um job que ainda não começou fica `queued`: nada pela metade.
- Heartbeat por tick, lido pelo healthcheck do contêiner. Processo vivo mas
travado passa em qualquer verificação de PID.
- O worker recusa iniciar com migration pendente, e relê o contexto do dono a
cada job: papel e feature flag podem ter mudado desde o enfileiramento.
- `verify-config`, `check-bucket`, `seed-staging` e `smoke-staging` novos. O
smoke tem fase autenticada que só roda com credencial fornecida pela
operação e, sem ela, reporta PENDENTE em vez de aprovado.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- `/api/health/live` não toca dependência: distingue processo vivo de
dependência fora do ar. `/api/health/ready` passou a tocar banco, migrations
pendentes, Redis com PING, bucket com listagem, configuração e modo de job,
e reporta em `reasons` só o nome do erro — nunca connection string.
- Configuração inválida encerra o processo. Antes o servidor ficava no ar
respondendo 500 em todas as rotas, inclusive no liveness, enganando o
orquestrador: pior que não subir.
- CSP, HSTS, Permissions-Policy e COOP, além dos três cabeçalhos que já
existiam. `unsafe-inline` em script-src é exigência do bootstrap do App
Router sem nonce; o resto é fechado e connect-src só aceita o próprio host,
o Supabase do ambiente e o Sentry.
- `onRequestError` registrado: sem esse export os erros de rota e de render
do servidor não chegavam ao Sentry. O ambiente do evento deriva de
ADAPTER_ENV, então homologação e produção não se misturam.
- `withSentryConfig` só atua quando organização, projeto e token existem no
build, para não quebrar build local nem CI.
- `output: "standalone"` para a imagem de runtime.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Duas lacunas impediam qualquer uso de homologação. Primeira: sem SSO do Elo
Pro e sem o login local, não havia como entrar. Segunda, mais grave: nada no
repositório gravava o cookie `elo_pro_workspace_id`, que era lido como origem
do workspace ativo — mesmo com sessão válida a resposta era sempre "sem
workspace".
- `identity-provider.ts` define o contrato de identidade. Trocar o Supabase de
homologação pelo SSO do Elo Pro passa a ser acrescentar uma implementação;
nenhum outro arquivo conhece o mecanismo.
- `/api/auth/staging/session` autentica com `signInWithPassword` no projeto
Supabase de homologação. Há senha, emitida e validada pelo Supabase, e o
Adaptador continua sem tabela de usuário, senha ou sessão própria.
- O login local sem senha existe apenas em `ADAPTER_ENV=development`, e não
por configuração: fora de development o provedor nem entra na lista.
- `workspace.ts` resolve o workspace por associação real lida sob RLS. O
cookie passa a ser preferência, não prova: aceitá-lo como autorização
transformava um valor editável pelo cliente em credencial.
- `/api/auth/workspace` grava a preferência só depois de confirmar a
associação, e `/selecionar-workspace` existe para quem participa de mais de
um workspace.
- Rate limiting por usuário e bucket nas rotas do módulo, com Retry-After.
Upload e processamento custam muito mais que leitura.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`next start` força NODE_ENV=production, então homologação não tinha como se
distinguir de produção: o login local ficava desligado (correto) e o módulo
exigia o SSO do Elo Pro, que ainda não existe. Não havia terceiro caminho.
- `ADAPTER_ENV` com development, staging e production, independente de
NODE_ENV. Toda política passa a derivar dele.
- Fail-fast de configuração em `fail-fast.ts`, separado de `env.ts` porque
`process.exit` não existe no Edge Runtime.
- `requireDatabaseUrl` elimina o fallback silencioso para PGlite: um segredo
ausente em staging migrava um arquivo local e parecia sucesso.
- Shim de identidade passa a ser decisão explícita via
`ADAPTER_APPLY_IDENTITY_SHIM`; aplicá-lo sobre o schema real do Elo Pro é
destrutivo em potencial.
- `migration-manifest.ts` responde o estado do schema consultando só o banco.
Ler o diretório numa rota fazia o Next tracear o projeto inteiro para a
saída standalone, levando docs, testes e fontes para a imagem.
- Redis e Supabase viram singleton por processo. Criar um ioredis por
requisição vazava conexão: o cliente é lazy, abre no primeiro uso e nunca
fecha.
- Namespace de chaves deriva de ADAPTER_NAMESPACE e do ambiente lógico, não
de SENTRY_ENVIRONMENT. Observabilidade e isolamento de dados são decisões
diferentes, e a variável única fazia homologação e produção colidirem.
- Listagem do bucket passa a paginar e descer em subpastas. Parando em 1000
entradas, a limpeza por TTL deixava de ver arquivos e temporários venciam
sem nunca ser removidos.
- `ping` e `hit` no coordenador, e `healthcheck` no armazenamento, para o
health check tocar as dependências de verdade.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas.
Co-authored-by: Cursor <cursoragent@cursor.com>
