Evidências

Qualquer um pode afirmar que um bug foi corrigido. Esta página mostra a correção, o teste que a protege e a prova de que o teste falha quando o bug volta.

Gerado em 2026-10-03 a partir de tools/prove_regressions.py · 4 de 4 testes de regressão comprovados como não vazios.

Como cada prova é produzida

Rode o teste de regressão contra o código corrigido: ele precisa passar.
Edite o código-fonte para reintroduzir o bug original.
Rode o mesmo teste de novo: ele precisa falhar, com uma falha de asserção real. Um erro de coleta não conta: significa que o teste nunca rodou.
Restaure o arquivo, verifique se o SHA-256 corresponde ao original e execute novamente: ele precisa passar de novo.

O assistente dizia aos visitantes que o webhook transporta a conversa deles. Ele não transporta nada dela.

commit e027e6b · protegido por apps/gateway/tests/test_webhook_content_claim.py

Os payloads de webhook carregam deliberadamente apenas a FORMA de um turno, ou seja, nome do evento, timestamp, contagem de passos e créditos, e nunca o seu conteúdo. O assistente, quando perguntado se os webhooks incluem a conversa, respondeu 'Sim, cada payload de webhook inclui o histórico completo da conversa daquele turno.' Isso é exatamente o oposto da garantia contra a qual a allow-list é testada. Medido em 2 invenções em 6 execuções antes da correção.

Código corrigido, execuções de teste	PASS	`21 passed in 1.15s`
Bug reintroduzido, mesmo teste	DETECTADO	`8 failed, 13 passed in 1.20s`
Arquivo restaurado, teste executado	PASS	`sha256 a8d4cb0b10787eff…`

O teste não é vazio: ele falha quando o bug volta.

Dissemos aos proprietários para clicar em um card do painel que não existe.

commit b4a203a · protegido por apps/gateway/tests/test_card_names.py

A base de conhecimento, a documentação e um bloco inicial diziam aos proprietários para procurar um cartão chamado 'Send turns to a webhook'. O cartão real do painel se chama 'Send events to your own system'. O nome foi inventado quando a seção de conhecimento foi escrita e se propagou para três lugares sem verificação. Medido: 2 de 2 respostas de configuração citavam um controle que nunca existiu.

Código corrigido, execuções de teste	PASS	`5 passed in 1.12s`
Bug reintroduzido, mesmo teste	DETECTADO	`3 failed, 2 passed in 1.23s`
Arquivo restaurado, teste executado	PASS	`sha256 f6348e1a5bbae209…`

O teste não é vazio: ele falha quando o bug volta.

A saudação no modo escuro era renderizada com 1.73:1, praticamente invisível, e a verificação não teria como detectar isso.

commit ca47f41 · protegido por apps/studio/test/themeContrast.test.mjs

Encontrado a partir de uma captura de tela feita em um iPhone real, não por nenhum teste. A saudação de boas-vindas estava fixada no código como #3a3a3c, o que dá 1.73:1 contra o painel do modo escuro, muito abaixo do mínimo de 4.5:1 e quase ilegível. Todo visitante de primeira vez no modo escuro a via. A correção faz a cor passar pela variável de tema --pw-mist para que ela acompanhe o painel; a verificação agora calcula a razão de contraste real para cada par temático em vez de confiar que uma cor foi definida.

Código corrigido, execuções de teste	PASS	`pass 5, fail 0`
Bug reintroduzido, mesmo teste	DETECTADO	`pass 3, fail 2`
Arquivo restaurado, teste executado	PASS	`sha256 54f8802b444b6194…`

O teste não é vazio: ele falha quando o bug volta.

Um turno com falha deixava o visitante esperando para sempre em um stream morto.

commit 4bcc691 · protegido por apps/studio/test/streamError.test.mjs

Quando a chamada ao modelo falhou, o servidor enviou corretamente um frame de erro, mas o widget escreveu a mensagem em um elemento que o ramo do rastro de governança já tinha ocultado, e nunca recolheu o rastro. O visitante via 'Lendo sua mensagem' pulsando indefinidamente em um turno que já tinha falhado: nenhum erro, nenhuma recuperação, nenhuma forma de saber. O texto do erro era atribuído corretamente e não era exibido em lugar nenhum. Encontrado durante uma queda real, quando a conta da API ficou sem crédito.

Código corrigido, execuções de teste	PASS	`pass 4, fail 0`
Bug reintroduzido, mesmo teste	DETECTADO	`pass 2, fail 2`
Arquivo restaurado, teste executado	PASS	`sha256 54f8802b444b6194…`

O teste não é vazio: ele falha quando o bug volta.

Registro operacional

O que existe por trás da plataforma e o que não foi testado. Apenas o que um script ou um log consegue mostrar.

Backups: todas as noites às 03:17 UTC, pg_dump --clean --if-exists, gzip; enviados a um remoto git privado após cada execução; o mais recente 20261003T031701Z; 29 dumps mantidos.
Teste de restauração 2026-10-03: dump 20261003T031701Z restaurado em 2 s em um contêiner descartável pgvector/pgvector:pg16 no mesmo host: 34 tenants, 270 linhas de conhecimento, 47 tabelas. O dump é das 03:17 UTC; às 13:26 UTC a limpeza agendada de demos removeu um tenant de demo abandonado com mais de 30 dias (log do gateway), por isso a restauração mostra um tenant a mais do que o ambiente em produção no momento do teste.
Rollback: site: tools/deploy-site.sh --rollback (uma segunda troca de symlink para a release anterior); Studio: tools/deploy-studio.sh --rollback (imagem anterior, com health check).
Metas de recuperação: nenhuma prometida. O dump noturno limita a perda de dados a um dia; nenhum tempo de restauração declarado.
Não testado: carga além de uma instância; failover multirregião; restauração em um host diferente.

De docs/ops-record.json, escrito pelo teste de restauração (docs/runbooks/db-backup.md).

O que isto não prova

Estas são verificações que eu mesmo executo no meu próprio código. Elas mostram que testes específicos pegam bugs específicos: não que o sistema esteja livre de outros, não que as auditorias tenham sido abrangentes, nem que alguém independente o tenha revisado. O harness está no repositório; a afirmação pode ser verificada executando-o.

PANTHEON · Prove, ataque o sistema em produção · Registro de auditoria · Walkthroughs · Trabalho · CV