install.sh: o sentinela 000 do curl é código morto — v_supabase_url aceita URL de Supabase inalcançável

[melgarafael]

Medido na main 9249e6f, achado durante a triagem do PR #188 (@ygorebos).

O defeito

hostgator-setup-kit/install.sh:195:

code="$(curl -s -o /dev/null -w '%{http_code}' -m 15 "$1/auth/v1/health" 2>/dev/null || echo 000)"
if [ "$code" = "000" ]; then
  echo "Não consegui alcançar $1 — confira se o projeto existe, está ativo …"
  return 1
fi

Quando o curl não alcança o host ele faz duas coisas: imprime 000 por causa do
-w '%{http_code}' e sai com código ≠ 0. Aí o || echo 000 dispara e acrescenta um segundo
000. A variável fica com 000000, que nunca é igual a "000" — o ramo da recusa é código morto.

$ c="$(curl -s -o /dev/null -w '%{http_code}' -m 5 https://nao-existe-xyz.invalid/x 2>/dev/null || echo 000)"
$ printf '%s' "$c" | od -c | head -1
0000000    0   0   0   0   0   0

O efeito no usuário

O instalador aceita uma URL de Supabase inalcançável. Medido na main 9249e6f, chamando o
validador pelo mesmo caminho que a suíte usa (INSTALL_SH_LIB=1 . ./install.sh):

$ v_supabase_url "https://abcdefgh.supabase.co"   # projeto que não existe; curl sai 6 (não resolve)
rc=0    # aceitou, sem imprimir nada

Ou seja: quem digita a URL do projeto errado, ou cola a de um projeto pausado, passa da Fase 1. É a
classe falha-em-verde de triagem/references/complemento-do-ci.md §7 — num produto que a pessoa
instala sozinha, ninguém está olhando.

É classe, não instância

O mesmo || echo 000 está em 5 lugares de install.sh — linhas 195, 228, 235, 292 e 306. Os
outros quatro comparam por case e a duplicação cai no ramo *), com sintomas diferentes:

onde	intenção do 000)	o que acontece de verdade
v_supabase_url (195)	recusar	aceita (o único que falha ABERTO)
v_sb_key (228, 235)	avisar e seguir	recusa com Resposta inesperada do Supabase ao testar a chave (000000)
v_anthropic (292)	avisar e seguir	segue, dizendo a Anthropic respondeu 000000
v_openai (306)	avisar e seguir	segue, dizendo a OpenAI respondeu 000000

O de v_sb_key é o que morde quem instala com Supabase próprio: um host que o instalador não
resolve vira uma recusa dura com um número que não existe em lugar nenhum.

⚠ Consertar SÓ um sítio inverte o sinal — os 5 vão juntos

Isto foi medido, e é a parte contraintuitiva desta issue. A tabela acima destaca o sítio de
v_sb_key como "o que morde quem instala com Supabase próprio", e a tentação é começar por ele.
Não comece — e não pare nele.

v_sb_key é hoje a barreira que segura uma URL que não é Supabase: o v_supabase_url aceita
(porque o 000 está morto) e o v_sb_key recusa logo depois. Consertando só o sítio de
v_sb_key, o 000 volta a ser reconhecido lá — e o ramo 000) dele é avisar e seguir, não
recusar. Resultado medido, aplicando o conserto isoladamente:

# com o conserto SÓ em v_sb_key, sobre a árvore que já tem o PR #188
url=https://zzzz-nao-existe.supabase.co   passo1_rc=0  passo2_rc=0  "⚠ não consegui checar a chave online; sigo com ela."
url=https://nao-existe-zzz.invalid        passo1_rc=0  passo2_rc=0  idem

Ou seja: a cadeia inteira abre para qualquer https:// inalcançável. O conserto parcial é pior
que o bug. v_supabase_url (linha 195) nunca pode ficar de fora do mesmo commit.

A correção

Uma linha em cada, tirando o echo de dentro da substituição:

code="$(curl -s -o /dev/null -w '%{http_code}' -m 15 "$1/auth/v1/health" 2>/dev/null)" || code=000

Medido:

padrão atual     code=[000000]  casa com "000"? NAO
padrão corrigido code=[000]     casa com "000"? SIM
caminho feliz    code=[200]     (não regride)

Por que nenhum gate pegou

hostgator-setup-kit/test-validators.sh cobre os validadores — mas nenhum job de CI o executa
(pnpm test:shell roda só tests/shell/update-guard.test.sh). Ver a issue irmã sobre isso.

E há um agravante de modelo mental: test-validators.sh:664 documenta o dublê de curl com o
comentário "Só o v_supabase_url exige resposta online (000 reprova); os outros toleram" — a
afirmação que este bug torna falsa. O comentário está certo sobre a intenção e errado sobre o
comportamento.

Aceite

• as 5 ocorrências corrigidas
• caso em test-validators.sh que reprova se o ramo 000 voltar a ser inalcançável (sabotar a correção tem de ficar vermelho)
• o comentário de test-validators.sh:664 conferido contra o comportamento novo

[melgarafael]

Corrigido no PR #242 — e a issue subestimava o alcance em duas direções.

São seis sítios, não cinco. v_openrouter nasceu depois desta issue, no PR do OpenRouter, copiando o mesmo padrão. Consertar os cinco listados deixaria a irmã para trás.

Eram dois defeitos opostos, e o não-relatado é pior. Medido com controle negativo na versão de main:

	antes	depois
v_supabase_url, host que não resolve	rc=0, saída vazia — aceitava	rc=1, "Não consegui alcançar…"
v_service, chave certa, rede fora do ar	rc=1, "Confira a chave e o projeto"	rc=0, "sigo com ela"

O de baixo é o que mais dói na instalação: numa VPS com rede instável o instalador acusa a chave certa e prende a pessoa num laço do qual não se sai digitando certo. O código sempre quis avisar e seguir — o ramo 000) está escrito lá; era a variável 000000 que não deixava chegar nele.

Sobre o comentário de test-validators.sh que a issue cita: ele estava certo sobre a intenção e errado sobre o comportamento, e a causa é que o dublê de curl da suíte é printf 200 incondicional — o ramo 000 dos seis nunca foi exercitado por nenhum dos 163 casos. O PR traz um dublê que imita o curl de verdade (imprime 000 e sai com erro) e cobra os dois lados. Os três validadores de IA cobram o texto do ramo, não só o desfecho: sem isso, o *) disfarçado de 000 — que era o que acontecia — passaria por correto.

Sabotagem: revertendo os 6 sítios, 6 de 6 casos novos reprovam, cada um citando o 000000 real.