O que uma versão 2 realmente exige: 206 commits de estados honestos

A maioria dos lançamentos "versão 2" é uma pilha de funcionalidades novas com um número maior por cima. A v2 do GeekBye foi o oposto. Quase não trouxe nenhuma capacidade nova visível para o utilizador. Os seus 206 commits miravam uma única ideia, pouco glamorosa:

A app nunca deve mostrar-te um estado que não seja verdadeiro.

Parece óbvio até contares de quantas formas uma app de desktop mente em silêncio. Mostra um visto num upload que ainda está a caminho. Diz "ligado" sobre um socket que morreu há um minuto. Fica calada enquanto a tua transcrição é deitada fora. Nada disto são crashes. São piores do que crashes, porque a app parece estar bem enquanto está errada — e só descobres mais tarde, quando a gravação de que precisavas não está lá.

A v2 foi o lançamento em que fomos à caça de cada uma dessas pequenas mentiras.

A mentira que mais odiávamos: o upload que "funcionou"

O GeekBye pode fazer backup das tuas gravações no Google Drive. Na v1, a ligação ao Drive era tratada como um detalhe em segundo plano — se funcionasse, ótimo; se não, a falha era quase invisível. A app continuava a parecer ligada. Assumias que as tuas gravações estavam a salvo. Às vezes não estavam.

A v2 reconstruiu isto em torno de estados de ligação honestos. O Drive está agora sempre num de poucos estados explícitos e verdadeiros — ligado, a reconectar, desligado — e a app difunde cada mudança desse estado a toda a interface no instante em que acontece. Quando a ligação está em baixo, um banner global de reconexão diz-to, em todo o lado, com clareza. A app já não finge que um upload teve sucesso quando não teve. Se o teu backup não pode acontecer agora mesmo, ficas a saber agora mesmo — não na próxima semana, quando fores procurar o ficheiro.

Por baixo, isto é uma pequena arquitetura, não um slogan: uma única fonte de verdade para a ligação, um evento que se espalha para cada parte da interface quando muda, e um banner que lê diretamente desse estado. Não há nenhum caminho em que a ligação esteja em baixo e a interface pareça estar ativa, porque ambas leem do mesmo facto.

A mentira da gravação perdida

O segundo grande arranjo de honestidade foi a recuperação de gravações. A transcrição em tempo real precisa de uma ligação viva. Na v1, se essa ligação tropeçava a meio da sessão — um piscar de Wi-Fi, um túnel, uma reconexão de VPN — o áudio durante a falha podia simplesmente desaparecer. A transcrição ficava com um buraco, e nada te avisava.

A v2 mudou o contrato: o áudio é preservado localmente durante uma quebra de ligação e reconciliado depois. Quando o elo cai, o GeekBye mantém o áudio a salvo na tua máquina; quando volta, esse áudio em buffer é enviado e costurado na transcrição no sítio certo. Trinta maus segundos de rede já não te custam trinta segundos de reunião. Este é o alicerce sobre o qual os lançamentos de fiabilidade posteriores construíram diretamente — a maquinaria de reconexão-e-buffer de porque é que o teu notetaker com IA para com mau Wi-Fi é a mesma ideia, endurecida.

A mentira da tempestade de popups

Há uma desonestidade mais subtil na forma como as apps reportam problemas: reportam a mais. Um único momento instável de rede pode disparar o mesmo erro cinco vezes, e de repente tens uma pilha de avisos vermelhos idênticos a enterrar a única mensagem que importa. Isso também não é honesto — é ruído a fingir-se de informação.

Por isso a v2 adicionou limitação de avisos por categoria e encaminhamento de erros. Os erros são agrupados pelo que realmente são, e cada categoria é limitada em frequência para que um único problema subjacente produza uma mensagem clara, não uma rajada. Um problema de limite de taxa é encaminhado para uma mensagem de limite de taxa; um problema de ligação é encaminhado para uma mensagem de ligação. A app diz-te o que é verdadeiro, uma vez — a mesma disciplina que mais tarde impediu um 429 de se fazer passar por um logout em o dia em que a nossa app fez DDoS a si própria.

O número 206 é o ponto

Estados honestos, banner de reconexão, recuperação de gravações, encaminhamento de avisos — são quatro ideias. O lançamento foram 206 commits. Para onde foi o resto?

Para a longa cauda pouco glamorosa que "nunca mostrar um estado falso" realmente exige. Cada sítio onde a interface antiga podia dessincronizar-se da realidade teve de ser encontrado e recabeado para ler da verdade em vez de uma cópia estagnada. Cada caminho de reconexão teve de ser obrigado a atualizar o estado partilhado em vez de adivinhar localmente. Dezenas de pequenos arranjos de fiabilidade ao longo da gravação, transcrição e uploads — cada um a fechar uma falha específica onde a app podia parecer certa enquanto estava errada.

Isto é o que uma "versão 2" a sério custa quando o objetivo é a confiança em vez de funcionalidades. Não há um único commit de destaque. Há 206 pequenos, e o lançamento só parece uma única coisa — calma — porque os 206 puxam na mesma direção.

O lançamento quase não saiu

Eis a história de guerra, e é boa, porque é sobre a nossa própria app a mentir-nos.

Quando preparas um lançamento, um script de mudança de versão carimba o número novo por todo o projeto. Na v2.0.0 atualizou a versão da app — mas o package-lock.json, o registo exato de dependências do npm, ficou a apontar para a versão antiga, 1.9.0. Localmente, estava tudo bem; ninguém reinstala dependências só para compilar. Mas a CI corre npm ci, e o trabalho inteiro do npm ci é recusar-se a prosseguir se o lockfile discordar do manifesto. É uma funcionalidade de rigor — e fez exatamente o que devia, fazendo falhar a compilação do maior lançamento que alguma vez tínhamos preparado.

Depois um segundo, mais traiçoeiro, surgiu por baixo. Um npm mais recente tinha podado uma dependência transitiva opcional — o pacote encoding que o node-fetch arrasta — do lockfile, por a considerar desnecessária. Só que a instalação limpa da nossa CI precisava dela, por isso a instalação quebrou de uma forma que não tinha nada a ver com o nosso código e tudo a ver com o registo estar subtilmente errado.

Ambos eram arranjos de uma linha: ressincronizar o lockfile para a versão real, restaurar a entrada podada. Ambos são também exemplos perfeitos e humildes daquilo mesmo de que a v2 tratava — um estado que dizia ser verdadeiro e não era. O lockfile é suposto ser o registo honesto daquilo de que a app depende. Quando derivou da realidade, a compilação fez exatamente o que a nossa app faz agora pelos utilizadores: recusou-se a fingir que estava tudo bem. Lançar um lançamento de fiabilidade acaba por ser um problema de fiabilidade até ao fundo.

Três coisas que a v2 nos ensinou

1. As falhas perigosas são as silenciosas. Um crash anuncia-se a si próprio. Um falso "ligado", um upload de sucesso fantasma, uma transcrição com um buraco invisível — esses custam-te confiança precisamente porque nada parece estar mal. Caça as mentiras silenciosas.
2. A honestidade é uma arquitetura, não uma mensagem. Não podes aparafusar "diz a verdade" a uma interface como um banner. O banner tem de ler da mesma única fonte de verdade que tudo o resto, ou torna-se mais uma coisa que pode estar errada. Um facto, espalhado — nunca duas cópias que possam discordar.
3. Uma versão 2 que mereça o número é, na maior parte, invisível. Se a tua v2 é uma lista de funcionalidades, é uma v1.5 com marketing. Uma v2 a sério são 206 commits que ninguém consegue apontar individualmente, a somar num produto que simplesmente deixa de te mentir.

A v2.0.0 do GeekBye é o alicerce sobre o qual cada lançamento desde então construiu. Para o que esse alicerce carrega, vê porque é que o teu notetaker com IA para com mau Wi-Fi, o dia em que a nossa app fez DDoS a si própria (v2.0.1) e transcrição em direto quando a firewall bloqueia os WebSockets (v2.0.8). Para a calma ao serviço da qual tudo isto esteve, as novidades do GeekBye v2.