Meu quality gate ganhou um mission control

O primeiro dashboard que fiz para o meu quality gate cumpria o papel. Listava projetos, listava execuções e mostrava uma execução passando pelo pipeline. Aí eu comecei a abrir ele todo dia, e cada pergunta significava alguns cliques e um carregamento de página.

Por que esse check tirou 30? Abre a execução, rola, acha o check, expande. O health-tracker está melhorando ou piorando? Abre o projeto, troca de aba, aperta os olhos num gráfico. Tem alguma coisa rodando agora? Recarrega.

Então refiz. Foram 480 arquivos alterados no commit principal, umas 23.500 linhas entrando e 12.200 saindo, e o Chart.js foi embora. Tenho chamado o layout novo de "mission control", porque eu queria uma tela que eu entendesse só de bater o olho, sem ficar clicando por aí.

Clicou, ganhou um resumo

Se eu só pudesse manter uma mudança, seria essa.

Todo check, dimensão, bloqueio, teste, execução e projeto abre um painel lateral com um resumo do que foi clicado. Você continua na mesma página. O painel entra pela direita e tem a própria pilha de volta (o check, depois a dimensão dele, depois volta). O estado fica na URL, então dá pra colar um link de "esse check nessa execução" e ele abre exatamente isso. No celular ele vira um bottom sheet.

O motivo é sem graça. A maioria das minhas perguntas é "por quê", e "por quê" é um resumo mais a evidência. No vídeo, o check de convenções tirou 30 porque dez funções e arquivos daquela entrega passaram do limite, e eu cheguei nisso em dois cliques sem sair da execução.

A Home mostra o que está acontecendo agora

A Home tem três coisas, de cima pra baixo: o que está rodando, o que acabou de terminar e como cada projeto está indo. Uma execução iniciada pela CLI, por um hook ou pelo próprio dashboard aparece como um card com a etapa atual (entrega, testes, checks, juiz, placar) e um cronômetro. Embaixo fica o feed de execuções recentes e, do lado, um bloco de saúde por projeto com o último veredito, a nota, um sparkline e a variação em relação às execuções anteriores.

Atrás de tudo tem uma constelação bem discreta desenhada num canvas. Enquanto uma execução está ao vivo, as linhas puxam pra cor de destaque e os pontos andam 1,5× mais rápido; quando não tem nada rodando, ela acalma. Está limitada a 30 fps, começa depois da primeira pintura, congela em aba escondida e nem é renderizada com movimento reduzido. Medi o contraste do texto no ponto mais claro atrás dele antes de decidir manter.

Não é necessário. Mas eu olho pra essa tela todo dia, e gosto de saber que tem algo rodando sem ler uma palavra.

A página da execução se monta sozinha

A página da execução é uma linha do tempo de passos que vai sendo preenchida conforme os eventos chegam por SSE: entrega carregada, comandos de teste, cada check determinístico, as chamadas do juiz, o placar. O anel da nota vai subindo conforme as dimensões entram e mostra "partial · 3/8 dimensions" até a execução terminar.

Esse vídeo é o gate avaliando o próprio redesign só com os checks determinísticos, sem juiz. Reprovou com 74,7 e um bloqueio de score-regression, porque ficou 17 pontos abaixo da mediana das últimas 10 execuções. Sem o juiz, cobertura de requisitos e fidelidade do PR não têm nota, e a verificação ficou em 40. Deixei essa execução no vídeo de propósito, porque foi isso que o gate disse.

Gráficos clicáveis

Cada projeto agora tem uma página com quatro abas: Runs, Trends, Calibration e Weights. Os gráficos foram pro Apache ECharts atrás de uma porta pequena que é do próprio app, então nenhum componente importa a biblioteca direto. Os gráficos de nota desenham as faixas de PASS e WARN atrás da linha, e uma execução abaixo de 65 já parece errada antes de você ler o eixo. Clicou num ponto, abre o painel daquela execução.

Ctrl/⌘+K

Uma paleta de comandos com busca aproximada em projetos, execuções e abas, mais ações como "Run gate on health-tracker" ou "Switch to light theme". Hoje eu uso ela mais do que a barra de ícones.

Tema claro, e no celular

O escuro é o padrão. O claro é um segundo tema completo, com as próprias cores de status, e falha é magenta nos dois. Nenhum status aparece só pela cor: sempre tem um ícone e um rótulo junto do tom.

Por baixo

Junto com o redesign foram três coisas que não aparecem num print.

Primeiro, o retry. Uma execução que falhou por causa de um teste instável pode rodar de novo só os passos que falharam. Os testes que passaram são reaproveitados dos eventos da execução anterior, todo check é avaliado de novo e o cache de respostas do juiz reaproveita as respostas que já estavam boas. O cabeçalho da execução mostra "Retry of" com o link pra original.

Depois, ESLint para práticas e convenções. Um achado só conta quando a entrega adicionou aquela linha, ou fez uma função, classe ou arquivo passar do limite. Não quero cobrar de um agente por código que ele não tocou. Onde o ESLint analisou o arquivo, as regras de regex que se sobrepõem a ele saem da frente, então nada é cobrado duas vezes.

E o Claude Haiku 5.5 virou o juiz padrão. O retry do health-tracker desses prints reaproveitou o juiz Haiku mais antigo da execução original; as nove chamadas do juiz em três dimensões custaram US$ 0,75.

O que eu diria pra mim antes de começar

O redesign adicionou pouquíssima informação. Quase tudo que está nessas telas já existia no dashboard antigo em algum lugar; eu só tinha que cavar pra achar. A maior parte do trabalho foi colocar cada resposta a um clique da tela onde a pergunta aparece.

Se você já fez uma ferramenta interna que abre todo dia, fiquei curioso pra saber o que você cortaria primeiro aqui: os painéis laterais, a paleta ou o fundo. Eu fico indo e voltando sobre o fundo.