O que é de fato uma release de 127 commits

Existe uma versão deste artigo que apenas lista tudo o que vem no GeekBye v1.7.0 — uma tela inicial redesenhada, um fluxo de calibração, uma barra lateral recolhível, novas configurações, e assim por diante. Seria exata e não te ensinaria nada. Porque a história honesta de uma release de 127 commits não é a lista. É a forma.

Aqui está a forma. Cento e vinte e sete commits soam como cento e vinte e sete coisinhas. Quase nunca são. O v1.7.0 foram duas grandes funcionalidades, construídas em paralelo em branches de longa duração ao longo de cerca de onze dias, entrelaçadas no fim. Entender uma release grande significa entender esses dois fios — e o único lugar onde construímos algo no ponto errado e tivemos que arrancá-lo de volta em pleno voo.

Fio um: calibração

O primeiro fio era a calibração — uma avaliação por voz com IA das suas habilidades de comunicação. Você inicia uma chamada ao vivo com um "coach de carreira" de IA, percorre um conjunto estruturado de fases (aquecimento, comportamental, comunicação técnica, resposta sob pressão, definição de metas), e no fim recebe uma nota em seis dimensões: confiança, clareza, especificidade, engajamento, compostura, relevância. Por baixo, ela também mede métricas concretas da fala: seu ritmo ao falar, a frequência de vícios de linguagem, se suas pausas soam como estratégicas ou hesitantes.

O resultado não é uma nota, é um ponto de partida. A calibração produz seus pontos fortes, suas áreas de crescimento e — crucialmente — uma dificuldade recomendada para começar a praticar. Ela calibra onde o produto deve te encontrar. Cada habilidade volta como um cartão de feedback expansível com um resumo, uma sugestão concreta e uma frase citada literalmente da sua própria chamada como exemplo. É a funcionalidade sobre a qual o resto da experiência de prática é construído.

Fio dois: uma janela totalmente nova

O segundo fio era um redesign premium — e chamá-lo de redesign o subestima. Não era uma nova pintura das telas existentes; era efetivamente uma segunda janela da aplicação, desenvolvida em seis fases explícitas: uma barra lateral recolhível no estilo Notion, um dropdown de cabeçalho que substituiu a antiga lista de sessões, navegação no estilo navegador com histórico e trilha de navegação, e reconstruções premium de Início, Perfis, Reuniões e Configurações.

Duas grandes funcionalidades. É isso que 127 commits foram de fato. E a parte mais difícil de lançá-las não foi escrever nenhuma das duas — foi o entrelaçamento. As duas branches eram interdependentes; uma foi mesclada na outra, e a branch de calibração teve que puxar a branch main quatro vezes distintas só para não se desviar enquanto o redesign se movia por baixo. A contagem de commits não é o custo de uma release grande. Branches de longa duração e a ordem de integração, sim.

A parte que vale a leitura: construímos a calibração no lugar errado

Aqui está o erro, e é um bom erro porque é muito comum.

O GeekBye tem uma regra arquitetural firme: todas as operações de IA vivem no backend. O cliente é uma casca fina que fala com um servidor. Todo mundo sabia disso.

E ainda assim a calibração foi primeiro construída no banco de dados local do cliente. Uma tabela dedicada, uma migração de banco de dados, um repositório de 254 linhas, handlers de IPC e um banco de 515 linhas de perguntas de avaliação — tudo vivendo na máquina do usuário. Funcionava. Também violava silenciosamente o contrato sobre o qual todo o app é construído.

Três dias depois, um commit apagou 680 linhas espalhadas por oito arquivos para mover tudo ao backend, onde os dados de calibração viraram um modelo próprio do lado do servidor, e a lógica das perguntas e a pontuação viraram uma preocupação do servidor. Outro commit apagou de vez o banco de perguntas de 515 linhas do cliente. O diff é quase engraçado: uma inserção, seiscentas e oitenta remoções.

Ninguém se propôs a escrever 680 linhas de código descartável. Aconteceu do jeito que isso sempre acontece: o atalho do cliente está bem ali, é mais rápido prototipar localmente, e "depois a gente move para o backend" parece inofensivo. Mas quando sua arquitetura já te diz onde vive a fonte da verdade, construí-lo em qualquer outro lugar não é um atalho — é retrabalho que você agendou para si mesmo com antecedência. A lição que ficou: coloque onde o contrato manda, de primeira, mesmo quando a versão local seja mais rápida de montar.

O bug que só a integração podia encontrar

Mais um comprovante, porque é o modo de falha característico das releases grandes. Uma vez que a calibração e a nova navegação foram conectadas e realmente rodando, o app começou a disparar um limite de taxa — HTTP 429 — sem motivo aparente.

A causa era pura integração. O status da calibração estava sendo buscado no nível do componente, então cada navegação o buscava de novo — e o strict mode do React, que invoca os effects de propósito duas vezes em desenvolvimento para revelar bugs, dobrou isso novamente. O resultado foram quatro a oito requisições de calibração idênticas disparando a cada troca de tela, o suficiente para acionar o limitador de taxa do servidor. A correção consolidou o fetching em umas duas chamadas na montagem.

Você não poderia ter encontrado esse bug testando a calibração sozinha, ou a navegação sozinha. Ele só existe na emenda — onde duas funcionalidades independentemente corretas se encontram. Esse é o imposto que uma release grande cobra: a última milha não é construir as funcionalidades, é descobrir tudo o que só quebra quando elas finalmente estão na mesma sala.

Três coisas que uma release grande ensinou

1. Uma release de 127 commits são dois ou três grandes temas, não cem pequenos. Encontre os fios. O trabalho — e o risco — vive em como eles se entrelaçam, não na contagem.
2. Coloque a fonte da verdade onde o contrato diz que ela vive, de primeira. Apagamos 680 linhas realocando a calibração do cliente para o backend. O atalho local é retrabalho agendado com antecedência; a arquitetura já tinha te dado a resposta.
3. A integração revela falhas que o isolamento não pode. A tempestade de 429 vivia na emenda entre duas funcionalidades corretas e só apareceu quando elas rodaram juntas. Reserve orçamento para uma passada de integração, não só testes por funcionalidade.

Este é um primo da era v1 de uma história que contaríamos de novo em escala muito maior — veja o que uma versão 2 realmente exige: 206 commits de estados honestos (v2.0.0), onde a mesma verdade de "um número grande são na verdade poucas ideias grandes" se desenrola por toda a reescrita da v2. Para o capítulo anterior na história da v1, como transmitir um relatório ao vivo sem o piscar (v1.6.13); e para todo o arco, a anatomia de publicar software até a perfeição.