Quem cresceu nos anos 90 e 2000 certamente se lembra de passar horas na frente do PC jogando Elifoot 98. Por mais de duas décadas, circularam em fóruns de internet dezenas de mitos e teorias sobre o funcionamento do jogo: Será que zagueiro agressivo desarma melhor? Por que jogar sem meio-campo parecia tão roubado? Existe bônus por nacionalidade?

Resolvi investigar a fundo e decidi fazer engenharia reversa do executável original (ELIFOOT.EXE) no Debian 12, usando o Ghidra e o Cheat Engine sobre a camada winevdm.

Descobri que o binário original foi compilado em Borland Delphi 1.0 (16-bit) e consegui descompilar as funções responsáveis pela simulação de partidas, cálculo de força dos setores e evolução dos jogadores.

🔍 Principais Descobertas:

1. O Mito da Nacionalidade era Real (+3 de Bônus): O código pré-jogo compara a sigla de país do clube com a do jogador (CompareStr) e adiciona +3 pontos fixos no setor para cada titular local (FUN_17fb_397d). Escalar 11 jogadores locais dá +33 pontos brutos de vantagem.
2. A Assimetria do Mando de Campo: O mandante roda Random(6000) < Força, enquanto o visitante roda Random(7000) < Força. O time da casa tem cerca de +16,7\% de vantagem matemática pura na criação de lances.
3. Por que o 5-0-5 quebra o jogo: Médios diluem a força (50\% ataque / 50\% defesa). Como não há punição por falta de meio-campo no código, jogar com 5 Defesas e 5 Atacantes maximiza o poder ofensivo e defensivo simultaneamente.
4. Comportamento não ajuda no desarme: No duelo de dividida (FUN_17fb_81ed), a vitória depende 100\% da força nominal. A agressividade serve unicamente como peso em uma roleta de faltas e cartões (FUN_17fb_100b).
5. Goleiros demoram o dobro para evoluir: Na rotina de evolução (FUN_17fb_4a41), goleiros precisam passar por um teste extra de 50\% (Random(2) == 0) para ganhar força.

Documentei todas as structs de memória, as fórmulas descompiladas em C e os prints da análise no repositório do projeto:

🔗 Repositório no GitHub: https://github.com/trsthales/desvendando-elifoot-98

Feedbacks, dúvidas e contribuições são muito bem-vindos!

Fala pessoal do TabNews! 👋

Se você joga no PC ou trabalha com várias abas e ferramentas pesadas abertas ao mesmo tempo, provavelmente já passou por isso: abrir o Discord oficial só para conversar com amigos em call e ver o Gerenciador de Tarefas acusar 500MB a 800MB+ de memória RAM e picos de uso de CPU que provocam aqueles micro-stutters (micro-engasgos) chatos no meio de uma partida.

O motivo é conhecido: o Discord oficial roda sobre o Electron (Chromium + Node.js), o que significa carregar um navegador web completo em segundo plano.

Incomodado com isso, decidi encarar um desafio: é possível recriar a essência do Discord — chat de texto e canais de voz com áudio de alta fidelidade — em um binário nativo ultra-leve em Rust?

O resultado é o Litecord, um projeto 100% open source que consome menos de 35MB de RAM e < 0.1% de CPU em idle. Compartilho abaixo as decisões de arquitetura e os desafios técnicos que enfrentei.

🛠️ A Escolha da Stack: Por que não usar WebView/Tauri?

A primeira tentação seria usar Tauri (que substitui o Chromium pelo WebView do sistema). Porém, para atingir o objetivo de performance máxima e consumo irrisório de memória, decidi ir direto ao metal:

• Linguagem: Rust (2021 Edition) — controle total de memória, zero runtime overhead e segurança para processamento de áudio concorrente em tempo real.
• Interface Gráfica: Slint UI — um framework moderno de GUI declarativa compilada nativamente. O Slint não renderiza HTML/CSS; ele compila o layout direto para instruções gráficas nativas (via FemtoVG/OpenGL ou renderizador de software), gerando uma interface fluida a 60 FPS com menos de 10MB de pegada de memória.
• Pipeline de Áudio: CPAL (Cross-Platform Audio Library) + decodificador nativo Opus (48kHz).
• Async Runtime: Tokio para orquestrar WebSockets, chamadas REST da API do Discord e o loop de eventos de interface sem travar a thread principal.

🔬 Desafios Técnicos Interessantes

1. Voz em Tempo Real e Criptografia DAVE (E2EE)

O Discord recentemente começou a implementar o protocolo DAVE (MLS - RFC 9420) para criptografia de ponta a ponta nas chamadas de voz.

• Para garantir que a voz não pipocasse ou ficasse "robótica" quando a GPU/CPU do computador estivesse em 100% de carga (durante um jogo pesado), implementamos Opus PLC (Packet Loss Concealment) com um jitter buffer adaptativo de 40ms e resampler cúbico Hermite a 48kHz.

2. Login Seguro por QR Code (Discord Remote Auth v2)

Em vez de pedir para o usuário colar tokens manualmente ou inspecionar cabeçalhos de rede:

• O Litecord implementa o protocolo Remote Auth v2 do Discord via WebSocket com pares de chaves RSA-2048 transitórias.
• O app gera um QR Code na tela; você escaneia pelo aplicativo do Discord no celular e autoriza o login com 1 toque.
• No Windows, o token da sessão é persistido no disco criptografado através da API nativa Windows DPAPI (CryptProtectData), garantindo que nenhum outro processo ou usuário não autorizado no PC consiga ler o segredo.

3. Ducking de Fala Dinâmico (Foco no IGL / Líder do Squad)

Em chamadas com muitas pessoas falando ao mesmo tempo ou bots de música tocando no canal, a comunicação tática fica caótica. Criamos um sistema de Prioridade de Fala (P:1, P:2, etc.):

• Quando o líder/shot-caller fala, o volume de todos os outros participantes e bots é atenuado suavemente em tempo real (ducking inteligente), voltando ao normal assim que ele termina a frase.

4. DeepSleep na Bandeja do Sistema

Ao minimizar o Litecord para a bandeja do sistema (System Tray):

• Todos os loops de renderização visual e atualizações de UI do Slint são completamente suspensos (0.0% de CPU).
• Apenas a thread assíncrona leve de recepção de áudio RTP/Opus continua ativa, consumindo recursos praticamente imperceptíveis enquanto você joga.

📊 Comparativo: Discord Oficial vs Litecord

📦 Código Aberto & Como Testar

O projeto é 100% open source sob licença MIT e já conta com executáveis prontos gerados pelo GitHub Actions:

• 🪟 Windows: Instalador .exe e versão Portátil .zip

• 🐧 Linux: Pacote nativo .tar.gz (testado e compatível com Ubuntu/Arch)

• 🔗 Repositório no GitHub: https://github.com/Ak4ai/Litecord

• 🌐 Página do Projeto: https://ak4ai.github.io/Litecord/

💬 Gostaria do Feedback de Vocês!

Quais outras otimizações ou recursos essenciais vocês acham que fariam sentido manter em um cliente focado puramente em leveza e baixo consumo? Fiquem à vontade para testar, abrir issues ou mandar PRs! 🦀🚀

Entrei no TabNews há pouco tempo, então esta é uma das minhas primeiras contribuições por aqui. Ainda estou conhecendo a comunidade e quero começar compartilhando algo que pode ser útil para quem coloca IA em produção.

Eu trabalho na equipe de San Jose por trás da Flatkey, uma camada de roteamento com API compatível com OpenAI. Estou deixando isso claro porque o texto também apresenta nosso produto.

Sobre este post: vou usar o DeepSeek como exemplo para mostrar como uma equipe pode avaliar e reduzir o custo do seu software. Também quero apresentar nossa plataforma. Em praticamente todo o catálogo, a Flatkey garante pelo menos 20% de desconto em relação ao preço oficial do modelo equivalente, considerando o mesmo tipo de uso. Como acabei de chegar ao TabNews, quero deixar uma pequena cortesia para a comunidade: os 50 primeiros usuários que se cadastrarem recebem US$ 5 em crédito gratuito, por ordem de chegada. Resgatar o crédito de boas-vindas.

Nas últimas semanas, os fabricantes chineses anunciaram vários modelos importantes. Em 13 de agosto, o DeepSeek V4 Pro foi lançado oficialmente em versão GA no app, na web e na API. A Z.ai lançou o GLM-5.3 em 14 de agosto; e a MiniMax lançou, também em agosto, o H3, um modelo de geração de vídeo que compete com o Seedance 2.5. Em algumas tarefas, esses modelos entregam resultados comparáveis aos nomes mais conhecidos, como GPT e Claude, por um preço menor. Todos estão disponíveis no catálogo de modelos da Flatkey.

Para desenvolvedores independentes, geeks e equipes pequenas, a Flatkey pode ser uma opção prática: uma chave e um saldo para mais de 100 modelos oficiais e mais de 1.000 ferramentas cobradas por uso, com menos contas e integrações para manter.

O preço do token conta, mas não conta sozinho

Uma tabela de preços normalmente mostra entrada e saída. O orçamento real também absorve chamadas que falham, respostas que precisam ser refeitas, prompts maiores do que o necessário e horas gastas mantendo integrações diferentes.

Por isso, gosto mais de medir o custo por tarefa aprovada: tokens consumidos, repetições, fallbacks e custo operacional divididos pelo número de tarefas que realmente entraram no produto.

Um modelo barato pode sair caro se a resposta exigir três tentativas. Um modelo mais forte pode compensar o preço quando resolve a tarefa de primeira. A única forma de saber é medir no seu fluxo.

O que a DeepSeek publicou sobre o V4

Eu conferi o changelog e a página de preços oficiais antes de escrever isto:

• Em 24 de abril, V4 Pro e V4 Flash apareceram na API como preview.
• Em 31 de julho, a DeepSeek publicou o DeepSeek-V4-Flash-0731. A própria documentação ainda o chama de public beta.
• Em 13 de agosto, o DeepSeek-V4-Pro-0813 chegou a GA no app, na web e na API.

Os IDs públicos são deepseek-v4-pro e deepseek-v4-flash. A documentação informa contexto de até 1 milhão de tokens, saída máxima de 384 mil tokens, tool calls, JSON output, Responses API e compatibilidade com a API da Anthropic. São especificações do fornecedor. A qualidade no seu caso precisa ser testada por você.

Como eu dividiria as tarefas

Não mandaria tudo para o mesmo modelo. Uma aplicação costuma ficar mais barata quando usa um modelo econômico para tarefas repetitivas, reserva o Pro para código e raciocínio mais difíceis e mantém um fallback para os casos em que a primeira chamada falha.

Também separaria as chaves por projeto ou ambiente. Assim fica possível responder uma pergunta que quase sempre aparece tarde demais: qual funcionalidade está consumindo o orçamento?

O teste leva poucas mudanças

Quem já usa o SDK da OpenAI não precisa reescrever a integração. Basta trocar o endpoint, a chave e o ID do modelo; a equipe pode então comparar o V4 Pro com o modelo que já usa no próprio fluxo de produção. A Flatkey verifica os endpoints oficiais a cada hora e tem failover entre canais, duas coisas que eu colocaria no mesmo teste de custo.

Outro detalhe de cobrança: chamadas que falham do lado da Flatkey não consomem saldo. Isso não elimina retries causados pelo seu próprio código ou pelo provedor, mas evita pagar por um erro na camada de roteamento.

Quero ouvir quem já colocou IA em produção

Qual tarefa vocês testariam primeiro no V4 Pro: código, agentes, suporte ou extração de dados?

Vocês acompanham apenas tokens ou sabem quanto custa cada tarefa concluída?

E o que uma camada entre a aplicação e o provedor precisa mostrar para vocês confiarem nela em produção?

Quem quiser testar pode usar a página da API DeepSeek da Flatkey. A Flatkey também oferece um programa de convites para que outras pessoas possam receber créditos. Se encontrar uma diferença entre a documentação, o preço exibido e o comportamento da API, prefiro que aponte nos comentários.

Fontes oficiais: changelog da DeepSeek, preview do V4 e modelos e preços.

Semana passada tentei assistir uma série com minha namorada usando a live do Discord. Não deu: se você não vive debaixo de uma porta, provavelmente sabe que desde 12 de agosto o recurso está suspenso no Brasil inteiro, por ordem da ANPD, depois que investigadores encontraram que a plataforma não consegue inspecionar uma transmissão em tempo real.

Esse guia não é sobre burlar a suspensão. É sobre o fato de que a comunicação inteira de um grupo pode depender de uma ferramenta que ninguém do grupo controla, e sumir por uma decisão tomada em outro lugar.

Testei a alternativa essa semana e documentei o processo inteiro: um servidor TeamSpeak 6 rodando numa VPS Oracle Cloud, camada Always Free, gratuita pra sempre. Uma hora do início ao fim, confortável pra 10 a 30 pessoas, sem custo nenhum e com compartilhamento de tela e com o deslumbre da antiga interface amável do TeamSpeak.

O motivo de eu trazer isso pra cá, e não só deixar no blog: a parte que mais gente trava é justamente a que a maioria dos tutoriais por aí pula. Uma instância Oracle fica atrás de dois firewalls independentes, a Security List da VCN e o iptables local, e os dois precisam liberar o tráfego. Isso é o que separa documentar que funciona de ser reproduzível por qualquer pessoa que seguir o passo a passo. Testei do zero, incluindo a persistência depois de um reboot.

Guia completo aqui: https://luanncurioso.dev/blog/self-hosting-teamspeak-oracle-free-vps

Ainda acho que os desenvolvedores de plantão que estão atrás de desenvolver uma plataforma para ocupar o lugar do discord irão se espantar com a simples ideia do custo inicial de um projeto desse em produção, portanto, mesmo que não perfeito, são apenas mais etapas para ter o que foi perdido durante esse período meio conturbado.

Recentemente, a empresa onde trabalho decidiu implantar um SSO para acesso aos sistemas internos. Com isso, começamos a integrar nossas aplicações ao novo provedor de identidade.

No entanto, com o surgimento de novos projetos, percebemos que o mesmo trabalho de implementar repetidamente os fluxos de autenticação OAuth 2.0 e OpenID Connect acabava se repetindo. Foi então que surgiu a ideia de desenvolver uma biblioteca simples e objetiva, capaz de agilizar esse processo e permitir que os desenvolvedores direcionassem seus esforços para a lógica de negócio da aplicação.

O FastOIDC é uma biblioteca Python que abstrai o fluxo de autenticação OAuth 2.0 + OpenID Connect, permitindo configurar clientes OAuth rapidamente em backends desenvolvidos com FastAPI.

A biblioteca implementa o fluxo de autenticação, utilizando PKCE e mecanismos de proteção contra CSRF, além de oferecer renovação automática de tokens e gerenciamento da sessão do usuário.

Até o momento, o FastOIDC foi testado com os seguintes provedores de identidade: Google, WSO2, Keycloak, Auth0 e GitHub. Na documentação mostro alguns exemplos para você copiar e rodar na sua máquina.

Para quem não conhece, o OAuth é um protocolo de autorização que permite que um aplicativo acesse seus dados em outra aplicação em seu nome de forma segura, sem você precisar fornecer sua senha.

Já o OpenID Connect (OIDC) é uma camada de autenticação construída em cima do OAuth 2.0, ou seja, ele diz a aplicação quem você é através de um ID Token, que é um JWT assinado contendo os dados básicos de que fez o login (e-mail, nome, foto de perfil, etc). Sabe quando você vai acessar um site e na página de login mostra um "Entrar com Google"? Isso é o OIDC.

Existem 4 papéis principais no OAuth:
1 - Resource Owner: Quem é dono dos dados e pode conceder o acesso a eles.
2 - Client: A aplicação que quer acessar seus dados e precisa do seu consentimento para isso.
3 - Authorization Server: O Servidor que verifica quem você é, obtém o consentimento e emite tokens de acesso para o client acessar seus dados (Exemplo: Google, Github, Keycloak, etc).
3 - Resource Server: O Servidor que contém dados protegidos que só podem ser acessados por quem fornecer um token de acesso válido (Exemplo: APIs do Google, API do Github, etc).

O fluxo OAuth + OIDC funciona da seguinte forma:

1 - Início do login: Quando você clica em "Entrar com o google", por exemplo, você é redirecionado para a tela de login com o google, onde você consentirá o acesso aos seus dados pela aplicação.
2 - Código de autorização: O Google redireciona você para a aplicação, passando um código temporário (authorization_code) na URL.
3 - Troca do código por tokens: A aplicação usa esse código para solicitar os tokens de acesso para o Google e recebe um access_token, um id_token e, opcionalmente, um refresh_token.
4 - Acesso aos dados: A aplicação valida o id_token, extrai os dados do usuário (e-mail, nome, foto de perfil, etc) e usa o access_token para acessar os recursos protegidos do Resource Server.

Abaixo está o diagrama que fiz para mostrar de forma didática o que cada papel faz no fluxo OAuth.

Quem quiser conhecer o projeto FastOIDC, utilizá-lo ou contribuir com seu desenvolvimento pode acessar o repositório no GitHub.

Alguns recursos interessantes sobre o tema abordado:

• https://www.oauth.com/playground/
• https://www.youtube.com/watch?v=uLY1CuLi9ac
• https://developer.okta.com/blog/2019/10/21/illustrated-guide-to-oauth-and-oidc

Eu estava procurando alguma coisa diferente para colocar no meu README do GitHub quando encontrei uma opção que me chamou bastante atenção: adicionar uma carta de Pokémon ao perfil.

A animação do botão já tinha me convencido a clicar. Fui ver como funcionava e descobri que dava para escolher a carta e configurar alguns detalhes antes de colocar no README.

A carta

Como eu não tinha nenhum motivo específico para colocar uma carta de Pokémon no meu GitHub, achei que o mínimo seria escolher uma que realmente chamasse atenção.

Acabei escolhendo uma de US$ 1 milhão.

Infelizmente, o card não vem acompanhado dos US$ 1 milhão.

O resultado

Depois de colocar tudo no lugar, ficou assim:

Agora meu GitHub tem:

• 1 README bonito;
• 1 carta de Pokémon de US$ 1 milhão.

Talvez tenha sido o melhor investimento que eu já fiz. Vai que o próximo recrutador é colecionador de Pokémon? Aí estou feito.

O mais curioso é que encontrei tudo isso completamente por acaso. Entrei para mexer no README e comecei a explorar as opções disponíveis. Quando percebi, estava configurando uma carta de Pokémon milionária para colocar no meu perfil.

E acho que é justamente essa a parte legal de projetos open source: você entra procurando uma coisa e acaba encontrando outra completamente aleatória.

A ferramenta que usei para fazer tudo isso se chama GitAscii. É um projeto open source para montar READMEs de um jeito mais visual e personalizável.

Se curtir a ideia, uma ⭐ é bem-vinda.

Recentemente vivi uma experiência que mudou minha percepção sobre evolução profissional em QA.

Objetivo do ciclo: sanidade pós-correção de incidente.
Atributo principal: confiabilidade — verificar perdas, duplicidades e pedidos presos.
Condição aplicada: carga/concorrência controlada.
Camada: integração/E2E — API, fila, estoque e banco.

Eu já havia estudado alguns conceitos relacionados a testes de confiabilidade, concorrência e desempenho. Ainda assim, esse tipo de trabalho parecia distante da minha realidade cotidiana. Até um incidente que gerou a necessidade de uma correção no menor tempo possível e consequetemente a validação da mesma. É muito diferente conhecer um assunto em um curso e precisar aplicá-lo durante a validação de uma correção originada por um incidente real.

Quando a demanda chegou, senti uma certa insegurança em saber como inciar a demanda. Reunião com a liderança do squad de Q.AS, reunião com o techlead do produto e a partir disso uma estratégia para seguir. Havia uma correção importante aguardando validação e o resultado dos testes ajudaria a equipe a decidir se ela estava segura para seguir para produção.

O desafio

O incidente envolvia um fluxo de pedidos processados de forma assíncrona. A API aceitava a solicitação, mas a conclusão dependia de outras etapas, como fila, processamento e disponibilidade de estoque.

Por isso, uma resposta de sucesso da API não era evidência suficiente. Um pedido poderia ser aceito e, ainda assim, permanecer em um estado intermediário ou não chegar ao resultado esperado pelo negócio.

A pergunta principal deixou de ser apenas “a API respondeu?” e passou a ser:

Todos os pedidos aceitos foram realmente processados até o estado final esperado, sem perdas, duplicidades ou pedidos indevidamente parados na fila?

Essa mudança de pergunta direcionou toda a validação.

Começando pelo que eu já conhecia

Iniciei os testes pelo Insomnia, ferramenta que já faz parte da minha rotina. Com ele, repeti o fluxo de criação de pedidos e observei o comportamento da fila.

Essa primeira etapa foi importante para validar o funcionamento básico da correção. Também me ajudou a perceber que repetir requisições em sequência não representava completamente o cenário do incidente, que havia ocorrido durante um volume concentrado de solicitações.

Eu precisava validar duas situações diferentes: o comportamento da fila ao processar vários pedidos e o comportamento do sistema quando pedidos chegavam concorrentemente.

Foi nesse momento que o k6 entrou na validação. Até então, eu o conhecia mais pelos estudos do que pela aplicação em uma demanda real. Utilizá-lo não foi somente escolher outra ferramenta, mas compreender qual risco ainda não estava coberto pelos testes que eu já havia executado.

Um passo de cada vez

Durante a preparação, nem tudo funcionou na primeira tentativa. Encontrei erro de rota, falha de autenticação e uma massa de teste que não representava corretamente o fluxo real.

Em vez de tratar isso como fracasso, passei a analisar um problema de cada vez. Primeiro confirmei a rota, depois a autenticação, o formato do pedido, a quantidade adequada e, somente então, aumentei o volume.

Essa forma de avançar foi essencial. Antes de executar centenas de pedidos, validei apenas um. Quando tive segurança de que a requisição estava correta, aumentei gradualmente a carga, sempre observando os resultados.

Também precisei respeitar as limitações do ambiente de homologação. O objetivo não era descobrir o limite máximo da plataforma, mas verificar com segurança se a correção se mantinha confiável diante do cenário que havia provocado o incidente.

A importância das evidências

Uma das partes mais marcantes dessa experiência foi entender que o teste não terminava na ferramenta que enviava as requisições.

Além de observar as respostas da API, registrei os horários, os tempos de resposta e os resultados de cada execução. Depois, cruzei essas informações com os registros do banco de dados para confirmar o estado final dos pedidos.

Esse cruzamento permitiu verificar se tudo o que havia sido aceito pela API realmente existia no banco, possuía o item esperado, recebeu estoque e chegou ao estado final correto.

Ao final do principal ciclo, foram criados 500 pedidos independentes. Todos foram aceitos pela API, encontrados no banco de dados e concluídos no estado esperado. Não houve falhas HTTP, perda de requisições nem pedidos indevidamente parados em estado intermediário.

Também foram realizados cenários regressivos com pedidos de estruturas diferentes, como combo e múltiplas variações, para verificar se a correção não havia afetado comportamentos relacionados.

Mais importante do que dizer “o teste passou” foi conseguir demonstrar por que ele passou.

O que essa experiência me ensinou

O primeiro aprendizado foi que uma resposta de sucesso técnico nem sempre representa o sucesso do negócio. Em fluxos assíncronos, é necessário acompanhar o processamento até a sua conclusão.

Também aprendi que repetição e concorrência cobrem riscos diferentes. Uma ferramenta conhecida pode ser suficiente para uma parte da validação, mas o contexto deve orientar quando é necessário ampliar a estratégia.

Outro ponto importante foi perceber que as próprias evidências precisam ser conferidas. Durante os testes, identifiquei uma contagem que poderia transmitir uma conclusão incorreta. Isso reforçou que não basta automatizar: é preciso questionar se o resultado apresentado realmente corresponde ao que foi executado.

Por fim, entendi que testes de confiabilidade e desempenho não se resumem a gerar grandes volumes. Eles exigem uma hipótese clara, um ambiente conhecido, limites responsáveis e critérios que conectem o resultado técnico ao comportamento esperado pelo negócio.

Evoluir como QA

Para mim, evoluir como QA não significa necessariamente seguir um único caminho ou buscar obrigatoriamente um cargo específico. Significa ampliar a capacidade de investigar riscos, compreender o sistema e oferecer informações confiáveis para que a equipe tome decisões melhores.

Mesmo com os estudos prévios, eu não comecei essa atividade me sentindo completamente preparado. A segurança foi sendo construída durante o processo: perguntando, pesquisando, testando em pequena escala, analisando os erros e compreendendo cada etapa antes de avançar.

Depois de concluir a validação, foi muito satisfatório apresentar as evidências dos testes executados e perceber que o trabalho ajudou a sustentar uma decisão mais segura. Não foi somente uma tarefa técnica concluída. Foi a sensação de ter apoiado um desenvolvimento mais íntegro e confiável.

O desafio que inicialmente parecia distante passou a fazer parte da minha experiência profissional. E talvez uma parte importante da evolução seja justamente essa: não esperar que o frio na barriga desapareça, mas aprender a transformá-lo em investigação, método e evidência. Saber pedir direcionamento para os colegas e agir na estratégia mas sem receio de sugerir teses.

Moro numa casa off-grid no alto de uma montanha e trabalho remoto. Nesse cenário, monitorar o consumo de energia é necessidade constante: no verão os painéis solares recebem sol a partir das 6-7h da manhã, mas no inverno isso só acontece por volta das 9-10h. A decisão de "assistir mais um episódio antes de dormir" ou "guardar energia" é literalmente a diferença entre ter ou não energia elétrica para trabalhar nos próximos dias nublados.

Para tomar essa decisão eu precisava consultar o aplicativo da bateria e a previsão do tempo — dois aplicativos, várias telas e atenção dividida. Então construí um dashboard que consulta os dados da bateria e uma API de previsão do tempo e exibe tudo em um display embutido na parede:

Neste write-up, conto o processo por trás do projeto: as limitações que guiaram cada decisão de arquitetura, as semanas de engenharia reversa para conseguir os dados da bateria e a solução para responder o "e amanhã, vai ter sol?".

Se quiser o contexto completo (o problema que motivou tudo isso), leia o post anterior no meu blog.

As limitações do cenário off-grid

A maior restrição do projeto pode ser resumida em uma frase: não tenho internet disponível 24 horas por dia. Essa é uma limitação derivada de não ter geração de energia constante — e é justamente o problema que este projeto busca quantificar e deixar visível.

Consequência direta: todo o sistema precisava funcionar com ou sem acesso à internet.

Onde comecei

Meu ponto de partida foi ver o que eu já tinha em mãos:

• dados da bateria via aplicativo mobile do fabricante
• APIs públicas de previsão do tempo
• hardware barato e de baixo consumo de energia (um CYD — placa ESP32 com tela TFT de 2.8" soldada)

O primeiro problema: eu sempre usei o próprio roteador da Starlink. Com ela desligada, eu ficava não só sem internet, mas também sem rede nenhuma — os dispositivos não conseguiam nem se falar entre si.

A solução foi adicionar um roteador wifi simples (Intelbras), que funciona 24h por dia independente da Starlink. Ele disponibiliza uma rede exclusiva para a bateria e o display, e se conecta via cabo ethernet à Starlink para dar acesso à internet quando ela está online.

Os dados: o capítulo da engenharia reversa

Conseguir os dados da bateria foi um longo processo de exploração que levou algumas semanas. Eu sabia que deveria haver algum modo de acessá-los, afinal a bateria enviava os dados para o aplicativo do fabricante.

Na primeira exploração, identifiquei a bateria na rede, mas não encontrei nenhum serviço aberto no IP dela. Descompilei o aplicativo, fiz engenharia reversa, monitorando o tráfego da minha rede — dias de frustração e nenhum caminho à frente.

Esgotadas minhas ideias, decidi fazer o caminho inverso: pegar os dados do aplicativo em vez da bateria. Não era o que eu queria, pois eu só teria acesso aos dados com internet, mas não ia deixar o projeto travar antes de sair do papel. Com isso, implementei a v0: a tela mostrava o estado de carga da bateria e uma estimativa de carga/descarga.

Satisfeito com a vitória e usando o dashboard há algumas semanas, decidi fazer um segundo round de exploração. Afinal, não faz sentido acessar um servidor na China para ler os dados de um dispositivo que está a 20 metros de mim, na mesma rede local.

Depois de muita pesquisa e leitura de várias versões de manuais, encontrei uma funcionalidade escondida no aplicativo: ele consegue acessar os dados da bateria sem internet, conectando-se diretamente a ela na rede local. Descoberta promissora.

A partir daí, instalei aplicativos de monitoramento de rede no celular e gravei o tráfego enquanto usava o aplicativo da bateria. Rede não é meu forte, e analisar aqueles logs manualmente levaria muito tempo, com risco de deixar algo passar. Então usei o Claude Code para analisar os logs, informando quais ações eu tinha feito durante a gravação — e ele identificou exatamente quais requests traziam os dados que eu via no app. Com alguns scripts Python, passei a replicar essas requests sem depender do aplicativo.

Para quem tem uma bateria da Felicity ou quer entender o protocolo por baixo dos panos, documentei tudo no repositório do projeto.

Com isso, a v1 estava de pé: dados da bateria sem nenhuma dependência de internet.

Temos o hoje, mas e amanhã?

Com a situação atual resolvida, faltava responder: vai ter sol amanhã? Posso esbanjar ou preciso economizar?

Depois de comparar APIs, escolhi a Open-Meteo. Melhor que previsão do tempo, ela disponibiliza a previsão de radiação solar — uma métrica muito mais precisa para o meu problema do que "nublado", "sol" ou "chuva".

Aqui esbarrei de novo na limitação de internet, e também na do hardware do display. A solução mais simples seria o próprio display consultar a API, mas isso significaria implementar em C uma série de redundâncias e caches para falhas de internet ou da API. Optei por uma solução um pouco mais complexa, porém mais simples de manter:

• um serviço em Go rodando na VPS busca os dados na Open-Meteo de hora em hora, aplica cache e cálculos, e sobrescreve um arquivo JSON estático
• o serviço nunca fica exposto na internet: se a API retornar erro, ele simplesmente não faz nada — o próprio arquivo vira a camada de cache
• o display faz uma requisição para esse arquivo: se der erro, continua mostrando os últimos dados que tinha; se voltar, compara a data e atualiza o que está na tela
• para falhas de conexão não passarem despercebidas, a tela mostra há quantas horas foi a última atualização bem-sucedida

Instalação

Para simplificar, aproveitei uma tomada com adaptador USB: liguei os fios 220v na tomada e o CYD na saída USB, tudo em uma única peça. Removi as outras entradas da tomada, aumentei o buraco do espelho e embuti o CYD dentro da caixa — instalar ficou simples como instalar qualquer outra tomada.

O sistema completo

               wifi                      ethernetBateria Felicity <-----> Roteador Intelbras <-----> Starlink (internet)       ^                      ^       |                      |       +---- wifi ------------+                     |                     v            +--------------+            |  CYD (tela)  |            +--------------+                     ^                     | http (arquivo JSON)                     |Open-Meteo --https--> Serviço Go (VPS) --sobrescreve--> JSON estático

Componentes: bateria Felicity, roteador Intelbras, CYD (ESP32 + tela), serviço Go na VPS, API Open-Meteo, tomada USB.

Código do firmware e do serviço: github.com/marcosvpj/felicity-cyd

Conclusão

Não é porque moro off-grid, no alto de uma montanha, que não posso usar tecnologia para melhorar minha vida. A principal questão é entender as limitações vigentes e trabalhar com elas — e ao redor delas.

E isso serve para tudo: muitas vezes queremos fazer as coisas do melhor modo possível, com a melhor arquitetura possível, quando simplesmente disponibilizar um arquivo JSON estático já resolve.

Desde 17/08 o compartilhamento de tela, vídeo e Go Live do Discord estão suspensos no Brasil (ordem da ANPD, sem data pra voltar — afirmação de produto, não jurídica). Mesa de RPG, watch party, coaching, estudo em call: todo mundo ficou sem a ferramenta principal.

Eu venho construindo o pqp — um chat de voz/texto open source, estilo Discord — e essa semana ele virou a minha resposta pra isso:

• Tela compartilhada e câmera nas chamadas funcionando, direto do navegador, sem instalar nada (tem app desktop também)
• De graça, no pqp.gg, ou self-host na sua máquina
• Código aberto (AGPL-3.0): https://github.com/rafaelcg/pqp
• Servidores em São Paulo
• Stack: React 19 + Node + Postgres, voz por WebRTC

Sendo honesto: é beta aberto. O ecossistema é zero perto do Discord — bots, integrações, apps polidos de loja, dez anos de estrada. Eu mantenho uma página de comparação que lista onde o Discord ainda ganha: pqp.gg/vs-discord.

Uma coisa que estou testando: caça-bugs como atividade. Achou um bug de verdade e reportou (tem uma caixinha de feedback nas configurações)? Bug confirmado ganha um selo 🐛 permanente no seu perfil público.

Feedback duro é bem-vindo — de arquitetura a copy. E se quiser quebrar alguma coisa, melhor ainda: me conta como.

Fala, pessoal!
​A Cidadela do Pracinha é o projeto da minha vida. A ideia é criar um universo vivo rodando direto no navegador, onde uma simulação de carreira de futebol se cruza com economia virtual e um RPG de investigação/suspense.
​A engrenagem do ecossistema funciona assim:
​Mundo vivo com Agentes de IA: Os habitantes da Cidadela (jornalistas, dirigentes, rivais) têm memória e contexto de dados reais.
​Impacto em tempo real: Suas declarações em entrevistas coletivas são interpretadas pela IA e registradas no Supabase. Isso gera reações imediatas: mensagens no celular virtual, matérias de imprensa e até oscilações de ativos na Bolsa interna do jogo.
​Economia com Ledger Próprio: Toda a movimentação financeira e os ativos da Cidadela são gerenciados por um sistema de registro interno.
​Camada Narrativa: Para quem quer ir além dos relvados, há todo um mistério investigativo escondido na Cidadela.
​Como o TabNews reúne referências em engenharia e produto, preciso da ajuda de vocês para evoluir o ecossistema.
​Quem puder navegar na Cidadela e testar a aplicação, gostaria muito de receber feedback sobre:
​Ideias de integração: Que novas mecânicas ou camadas de tecnologia ficariam interessantes para expandir essa simulação?
​Experiência de Uso (UX/UI): Como está a usabilidade do PWA no mobile e no desktop?
​Arquitetura & IA: Sugestões para otimizar o consumo de contexto dos agentes e a resposta do banco de dados.
​Toda crítica construtiva, apontamento de bug ou ideia de funcionalidade será fundamental para o desenvolvimento do projeto. Valeu demais!

Falaa pessoal, faz alguns dias vi um cara fazendo o port de um driver de impressora que só existia pra Windows pro Mac dele usando uma IA, e pra mim foi um dos cases de uso mais legais que vi recentemente. Aquilo me deu uma ideia na hora.

Faz um tempo como tenho usado só mac e não achava um investimento bom comprar um outro pc só pra jogar um ou dois jogos, fui buscar as ferramentas pra entender como funcionava, passei por GPTK, crossover, wine e até consegui jogar vários jogos antigos que gostava, porém, apenas um eu não consegui rodar, o bom e velho Brasfoot. O Brasfoot tem uma particularidade, apesar de ser um jogo leve ele roda sob o java ele verifica se JAVA existe de uma forma específica, que é pelo path do ambiente do Windows. No mac não consegui funcionar. Tentei também com o GPTK, Crossover, e neles acabava batendo no mesmo problema, pq os contâineres que ele criava não conseguiam simular direito o JAVA ou a versão não que tinha compatível com a ferramenta.

Como eu ja tinha uma ideia de onde tava o problema e porque ele não rodava, iniciei por criar uma camada de abstração, basicamente um launcher que já sabe onde o Java está e passa os parâmetros certos pro executável. Joguei o problema pro Claude com esses detalhes. E papo de uma hora, depois de pegar alguns logs de erros no sistema e vibe coding, o jogo estava rodando.

Foi uma das experiências mais legais que tive usando uma IA e mostra o poder que essas ferramentas tem quando são usadas pra algo mais que criar uma landing page ou uma calculadora ou coisa do tipo.

Enfim, se você tem Mac e sempre quis jogar Brasfoot, aqui está:

https://github.com/codenicolai/brasfoot_mac

Super leve, simples de rodar, e mais importante, agora tem como.

PS: o jogo não foi pirateado. É a versão original do instalador, disponibilizada gratuitamente pelo Emanuel. e ainda precisa registrar (registro disponível no site oficial do brasfoot)

Se conseguir rodar, deixa uma ⭐ no repositório, ajuda muito!

Esses dias implementei uma feature de rollback no Hangar e fiquei curioso para saber como vocês lidam com isso hoje.

Imagina o cenário:

Você faz um deploy, aparentemente está tudo certo, e alguns minutos depois percebe que quebrou produção.

Normalmente dá para fazer um git revert, voltar para o commit anterior e disparar outro deploy.

Funciona, mas dependendo do projeto você ainda precisa passar novamente por build, geração da imagem e todo o processo de deploy.

No Hangar resolvi fazer diferente.

Quando o rollback está ativado, a cada deploy eu salvo a imagem que foi compilada naquela versão.

Então se eu tiver:

Deploy #54 ← produção atual
Deploy #53
Deploy #52
Deploy #51

e o deploy #54 quebrar alguma coisa, o usuário pode simplesmente escolher o #53 e clicar em Rollback.

Como aquela imagem já foi compilada anteriormente, não fazemos o build novamente.

Em poucos segundos aquela versão volta para produção.

O que achei interessante nessa abordagem é que você não está reconstruindo um commit antigo. Você está colocando em produção exatamente a mesma imagem que já estava funcionando anteriormente.

Claro que existe um custo nisso, principalmente armazenamento das imagens antigas, então deixei a funcionalidade opcional.

Estou construindo o Hangar, um PaaS brasileiro, e fiquei curioso para saber como vocês resolvem isso hoje.

Vocês fazem git revert + novo deploy? Guardam imagens anteriores? Usam alguma funcionalidade da própria plataforma?

O reajuste ocorre em meio à forte demanda por componentes de IA, que pressiona a capacidade de produção. A procura de clientes chineses tem sido especialmente alta, mas a empresa não consegue atender todos os pedidos porque também precisa produzir para clientes dos EUA e reservar parte da capacidade para seus próprios chips.

A Spirit Airlines encerrou as operações em maio e colocou os dados à venda durante a liquidação. O Google venceu o leilão por 10 milhões de dólares e terá acesso a 100 milhões de e-mails, 537,5 milhões de registros do Teams, OneDrive e SharePoint, além de mais de 45 milhões de gravações de chamadas e chats de atendimento ao cliente. A venda ainda depende de aprovação judicial e informações pessoais devem ser removidas antes da transferência.

A listagem também torna a empresa a primeira do setor a abrir capital em uma bolsa da China continental. No ano passado, a companhia despachou mais de 5.500 robôs humanoides e registrou lucro líquido de 41,3 milhões de dólares.

O satélite Link, lançado no mês passado e do tamanho de uma geladeira, seria usado para capturar o Swift com três braços robóticos e elevar sua órbita, mas sofreu problemas contínuos de controle de altitude. A NASA queria evitar a reentrada porque ela encerraria as operações do observatório, que ainda poderia continuar produzindo dados científicos sobre explosões de raios gama. Ele está em órbita há 21 anos e deve reentrar na atmosfera ainda em 2026.

Segundo a empresa, alguns títulos podem parar de responder, fechar inesperadamente, exibir o erro “EXCEPTION_ACCESS_VIOLATION” ou até reiniciar o dispositivo. Os relatos surgiram após o lançamento da KB5121003 e a companhia apura se o problema foi causado pela atualização ou por drivers de terceiros.

O fornecedor anuncia um modelo novo. O modelo que você usa ganha data de saída. Entre um aviso e outro, aparece um seletor na interface e a troca parece tão simples quanto mudar uma configuração.

A API continua aceitando mensagens. A resposta continua sendo texto. Talvez os testes unitários até passem. Dias depois, porém, o agente começa a chamar ferramentas em outra ordem, ignora uma etapa de validação ou gasta mais para resolver a mesma issue.

É aí que a falsa simplicidade do seletor cobra a conta.

No ecossistema do GitHub Copilot, por exemplo, o anúncio da chegada do Gemini 3.7 Flash veio no mesmo período em que outros modelos receberam uma data de depreciação. O Copilot cloud agent também passou a permitir a escolha do nível de raciocínio por execução, com impacto possível no consumo de tokens ou créditos. São mudanças diferentes, mas apontam para o mesmo cuidado operacional: modelo e esforço fazem parte da rota de execução do produto.

Trocar essa rota exige o mesmo cuidado que uma migração de dependência importante. Não precisa virar um projeto de três meses. Precisa ser pequena, observável e reversível.

O seletor esconde uma dependência de comportamento

Duas opções compatíveis com a mesma API não são, necessariamente, equivalentes no seu workflow. A troca pode alterar:

• como o agente interpreta uma instrução ambígua;
• quando ele decide chamar uma ferramenta;
• o formato e a consistência da saída estruturada;
• a quantidade de tentativas até concluir uma tarefa;
• a latência e o custo da execução;
• o ponto em que ele considera o trabalho encerrado.

Essa diferença importa pouco em uma conversa casual. Importa bastante quando o modelo edita código, usa credenciais, abre um pull request ou chama um serviço externo.

Fixar a rota atual traz alguma estabilidade, mas não elimina a migração. Só adia o momento. Se o fornecedor já definiu uma data de depreciação, esperar até a última semana reduz justamente o que você mais precisa para trocar com segurança: tempo para comparar o comportamento.

Atualizar automaticamente resolve o problema oposto. Você recebe novidades sem esforço manual, mas aceita mudanças antes de entender como elas afetam o seu fluxo. Para um agente em produção, nenhuma das duas escolhas funciona bem sozinha. É melhor ter uma política explícita de versão, avaliação e promoção.

Escreva o contrato antes de escolher o candidato

Comparar modelos por uma resposta isolada quase sempre favorece o texto mais convincente. O produto, no entanto, depende do fluxo completo.

Antes de testar o candidato, descreva o comportamento que precisa sobreviver à troca. Use poucos casos reais e declare o que será observado em cada um. Um contrato enxuto pode registrar:

rota: corrigir-bug-frontendentrada:  - issue com passos de reprodução  - repositório em uma branch isoladasaída_obrigatória:  - arquivos alterados  - resumo curto da causa  - testes executadosferramentas_permitidas:  - leitura e edição do repositório  - terminal com comandos aprovados  - navegador de testelimites:  tentativas: 3  custo_por_execução: definido_pelo_timecondições_de_parada:  - pedir contexto se a reprodução falhar  - parar antes de qualquer deployvalidação:  - testes automatizados  - console sem erro novo  - critérios da issue reproduzidos no navegador

Esse arquivo não precisa virar uma especificação universal. Ele só precisa expor o que hoje está escondido no prompt, no código ou na cabeça de quem montou o agente.

Também vale evitar um contrato que descreve o comportamento do modelo atual em vez da necessidade do produto. “Responder com o mesmo estilo e o mesmo número de passos” pode congelar uma peculiaridade sem valor. “Entregar JSON válido, executar os testes aprovados e preservar o estado de erro do formulário” define algo que o usuário realmente percebe.

Tire modelo e esforço da regra de negócio

Se o identificador do modelo aparece espalhado por handlers, jobs e scripts, cada migração vira uma caça ao texto. O risco não está apenas em esquecer um ponto. Rotas diferentes podem acabar usando versões distintas sem que isso seja intencional.

Concentre a decisão em uma configuração versionada:

rotas:  corrigir-bug-frontend:    modelo: modelo-atual    esforco: medio    fallback: modelo-anterior  revisar-pull-request:    modelo: modelo-atual    esforco: alto    fallback: desabilitado

O formato é menos importante que a separação. A regra de negócio pede “corrija este bug com estes limites”; a camada de roteamento decide qual modelo e qual nível de esforço executam a tarefa.

Essa camada também deve registrar a rota que foi usada de verdade. Um log útil inclui modelo, configuração de esforço, versão do prompt, ferramentas liberadas, duração, custo, resultado da validação e motivo de fallback.

Sem isso, o fallback vira uma fonte de confusão. A tarefa termina, mas ninguém sabe que ela passou pelo modelo de reserva. A disponibilidade parece boa enquanto uma regressão fica escondida nos bastidores.

Fallback explícito não significa anunciar detalhes técnicos ao usuário em toda resposta. Significa deixar a substituição visível para quem opera e avalia o sistema.

Uma migração curta em seis passos

Você não precisa reproduzir toda a produção. Uma amostra pequena, escolhida a partir de falhas e tarefas frequentes, costuma revelar mais que um benchmark genérico.

1. Inventarie a rota atual. Localize identificadores de modelo, níveis de esforço, fallbacks, prompts, limites de custo e ferramentas disponíveis.
2. Salve um baseline. Execute os casos representativos com a configuração atual e guarde saídas, validações, latência, custo e falhas.
3. Rode o candidato nas mesmas condições. Se possível, use execução em sombra ou uma branch descartável para impedir efeitos externos.
4. Revise diferenças, não só acertos. Observe chamadas de ferramenta, tentativas extras, omissões, formato de saída e condições de parada.
5. Libere para uma amostra pequena. Comece por tarefas reversíveis e acompanhe a rota usada em cada execução.
6. Mantenha o rollback por um prazo definido. Preserve a configuração anterior enquanto o novo caminho ganha volume suficiente para revelar regressões menos óbvias.

Rodar duas rotas custa mais tokens e créditos. É um custo temporário para obter evidências antes da virada. Se o orçamento for apertado, reduza a quantidade de casos, não a qualidade dos critérios. Três tarefas bem escolhidas são mais úteis que cinquenta prompts genéricos.

Exemplo: um agente que corrige bugs de frontend

Imagine um agente interno que recebe issues pequenas. A rota atual altera o código, executa os testes e valida o fluxo no navegador. Para avaliar um novo modelo, o time separa três casos:

• um formulário que precisa preservar os dados depois de um erro da API;
• uma tela que quebra em largura de celular;
• um componente que perdeu o nome acessível após uma refatoração.

O candidato pode produzir um diff elegante e ainda reprovar. Se limpar o formulário depois do erro, corrigir apenas o viewport usado no teste ou ignorar a regressão de acessibilidade, o comportamento importante não foi preservado.

A avaliação deveria comparar pelo menos quatro tipos de evidência:

• o diff e os arquivos tocados;
• o resultado dos testes;
• erros novos no console;
• a reprodução dos critérios no navegador.

Suponha que o candidato acerte o código, mas pare antes da validação visual. Isso não prova que o modelo seja ruim. A causa pode estar no prompt, no nível de esforço, na ferramenta disponível ou no limite de tentativas. Como o contrato separa essas partes, o time consegue ajustar uma variável por vez em vez de escolher outra opção no seletor e torcer.

Esse detalhe evita uma armadilha comum: transformar toda falha em comparação de inteligência. Às vezes, o modelo tinha capacidade para concluir a tarefa, mas a rota não lhe deu tempo, permissão ou um critério de parada adequado.

Rollback de configuração não desfaz o mundo

Voltar ao identificador anterior é simples quando o roteamento está isolado. Isso restaura a configuração para as próximas execuções. Não apaga uma mensagem enviada, não reverte automaticamente um deploy e não desfaz uma gravação feita em um serviço externo.

Por isso, a primeira fase da migração deve privilegiar tarefas reversíveis. Para ações externas, use aprovação humana, idempotência, modo de simulação ou uma operação compensatória quando o sistema oferecer esse caminho.

O rollback precisa responder a duas perguntas diferentes:

1. como voltar a executar tarefas com a rota anterior;
2. como tratar os efeitos que a rota nova já produziu.

Misturar as duas dá uma sensação de segurança que não existe.

O que revisar antes da troca

Uma última checagem ajuda a evitar a migração feita no impulso:

• onde o modelo atual está configurado?
• quais tarefas representam o uso real?
• quais saídas e ferramentas fazem parte do contrato?
• existe um teto de custo e uma condição clara de parada?
• a telemetria mostra modelo, esforço e fallback usados?
• o candidato foi testado sem receber a fila inteira?
• há um prazo para manter a rota anterior disponível?
• efeitos externos exigem aprovação ou compensação?

Modelos vão entrar, melhorar, mudar de disponibilidade e sair de catálogo. Tentar impedir esse ciclo só torna a próxima troca mais urgente.

A saída mais prática é fazer do modelo uma dependência substituível e do comportamento um contrato verificável. Assim, o nome no seletor pode mudar sem transformar cada novidade ou depreciação em uma aposta na produção.

Fontes

• Upcoming August 2026 model deprecations in GitHub Copilot
• Gemini 3.7 Flash is now available in GitHub Copilot
• Customize the reasoning level for Copilot cloud agent

Senadores e deputados estariam usando versões básicas do ChatGPT e Claude para redigir os documentos, contendo informações incorretas e falta de profundidade, o que tem atrasado processos de tramitação devido à necessidade de revisões frequentes.

Fala, galera! Beleza?

Tenho visto muita gente quebrando a cabeça para achar formas reais de fazer uma renda extra hoje em dia. Com tanta inteligência artificial por aí, dá para automatizar muita coisa e criar negócios digitais do zero sem precisar manjar de programação.

Assisti esse vídeo super legal com 5 ideias de negócios práticos e validados. Quem quiser dar uma olhada e pegar os insights, o vídeo completo tá aqui:👉 https://www.youtube.com/watch?v=op0GvHqDOFQ

O Slack Code cria canais abertos e dedicados por projeto para que desenvolvedores trabalhem em conjunto sem precisar alternar entre diferentes ferramentas. O recurso inclui abas de usuários, comparação de mudanças no código e prévia da saída em HTML. A novidade já está disponível para todos e funciona com agentes do marketplace do Slack, além de Claude Code, Devin, Vercel Agent e GitHub Copilot.

Para ela, isso significa que a IA entrou em uma nova fase de rápida transformação da economia, evidenciada, entre outros fatores, pelo forte aumento na criação de novas empresas. Nesse cenário, manter-se privada permitirá tomar decisões de longo prazo com mais liberdade e agilidade, afirma a Stripe, sem pressão de acionistas e do mercado.

Neste post irei demonstrar e explicar como funciona a codificação de números negativos e positivos.

Usarei o termo encoding ao invés de codificação por ser mais familiar para os devs.

Os exemplos estarão em Rust.

O que é Encoding

O que é encoding? Bem, encoding é o processo de mapear uma sequência de bits para um valor X.

Considere a seguinte sequência de bits:

0000

Aqui temos 4 bits. Todos os bits tem 0 como seu valor. Você já deve saber que, quando todos os bits são 0, ele normalmente representa o 0 em decimal.

Irei trabalhar com decimais por ser simples e direto. No entanto, a notação funciona para Octal e Hexadecimal também, caso reste dúvidas.

No entanto, o bit 0 pode ser o que eu quiser. Eu posso "encode" o bit 0 para a seguinte string: "The Elder Scrolls: Skyrim". Eu posso mapear 00 para uma coisa complemente diferente, tal como valor numérico: 101.

Bits não significam nada sozinhos. O seu valor depende inteiramente do contexto. Isso significa que uma mesma sequência de bits pode representar infitas coisas dependendo do contexto. O que muda não são os bits, mas a interpretação deles. Iremos trabalhar com números nestes post.

Por debaixo dos panos, o mesmo ocorre quando escrevemos let x = 10. Como é de conhecimento comum, computadores usam base 2 (binária). Então como estamos vendo o número 10? Eu não só estou vendo o número 10, como é rotineiro manipular informação usando decimais ao invés de base binária!

Enconding Unsigned numbers

Para quem vêm do Python, JavaScript, e linguagens de alto nível, normalmente não se preocupam com multiplos tipos para valores numéricos, tais como u8, u16, u32, u64, u128 e outras variantes. Para que fique de fácil entendimento, um número unsigned é um valor pertencente ao conjunto dos números naturais. Ou seja, não é fracionário e nem pode ser negativo.

Eu não irei entrar em comprovação matemática. Eu irei demonstrar na prática com código de alto nível como funciona.

Considere a seguinte sequência de bits:

0 0 0 1 <- bit sequence3 2 1 0 <- bit index

Temos um bit de valor 1 e o restante com o valor de 0, totalizando 4 bits.

Dizemos que, quando um bit tem o valor de 1, ele contribui x \times 2^i onde x é o valor do bit, e i é o posicionamento dele. Vamos fazer o processo passo a passo:

0 0 0 1 1 x 2^0 = 10 x 2^1 = 0 0 x 2^2 = 00 x 2^3 = 00 + 0 + 0 + 1 = 1 

Se você não entendeu o que aconteceu aqui, você provavelmente não sabe, ou não lembra como funciona potenciação e multiplicação por zero. Ensinar isto foge do escopo do post.

Perceba que no final, após calcular a contribuição de cada bit, somamos tudo e é retornado o valor decimal: 1. Isto significa que, 0001 é equivalente ao número 1. Portanto, ao escrever:

let x = 1;

Nós vemos um decimal, mas o computador trabalha com 0001.

Um detalhe importante. Eu usei 4 bits por questões de simplicidade. Normalmente trabalhamos com 8 bits em diante. A boa nóticia é que zero a esquerda não altera o valor, portanto:

0001 = 00000001

São equivalentes. Daqui em diante, continuarei usando 4 bits.

Um ponto interessante é que, podemos determinar o valor mínimo e máximo que uma sequência de bits pode representar da seguinte forma para unsigned numbers:

0 a 2^n onde n é o comprimento da sequência de bits. Neste caso é 4, portanto o valor máximo que eu posso expressar usando 4 bits é 2^4 = 15.

Antes que alguém corra para me corrigir, o valor é 15 porque o 0 esta incluso. Porém entendemos que na matemática seria 16.

Existe uma propriedade que garante os números nunca colidam. Isso significa que cada sequência de bit representa apenas uma única coisa, e que o processo de decimal para bits, e de bits para decimal sempre retorna o mesmo valor. Esta propriedade é matemática e foge do escopo do post.

Encoding signed numbers

Signed numbers representa números do conjunto de números inteiros. Portanto isto engloba números negativos, aumentando a complexidade da coisa.

Apesar de relativamente mais difícil de entender conceitualmente, a ideia é praticamente a mesma. A diferença reside no bit mais a esquerda.

1001

Para quem teve o trabalho de mapear sequências de bits do 0 até o 15, assim como eu, sabe que 1001 é o mesmo que 9 em decimal. No entanto, quando estamos lidando com números signed , não é 9, mas -7.

A cabeça pode está explodindo agora, mas calma, relaxa.

Antes de mais nada, é importante ressaltar que, estamos usando um algoritmo específico para este exemplo, o two's complement, que é o mais popular.

Lembra que eu disse que um bit não significa nada por si só? Agora é o momento de trabalharmos em cima disto!

Temos uma sequência de 4 bits. Sabemos que para números unsigned, temos um total de 15 diferentes sequências de bits, onde cada uma representa um número diferente. Agora pense, temos uma sequência de 4 bits, e agora passamos a representar não só positivos, mas valores negativos também, a minha interpretação sobre estas sequências precisa mudar.

O bit mais a esquerda determina se o valor é positivo ou negativo. Se o bit for igual a 1, o resultado final será negativo. Se for 0, valor final será positivo. Na prática, quando estamos trabalhando com signed numbers, ao invés de calcular da seguinte forma x \times 2^i, calculamos da desta forma o último bit: x \times -2^i.

Considere o seguinte exemplo:

1 x 2^0 = 10 x 2^1 = 00 x 2^2 = 01 x -2^3 = -8-8 + 0 + 0 + 1 = -7

A forma que interpretamos o último bit mudou. Calculamos ele de forma diferente de como faziamos antes. Graças a isto somos capazes de representar números negativos também!

Detalhes

Eu me referi a uma cadeia de bits como sequência de bits, mas o termo comum é bit vector.

signed numbers pode representar apenas metade do que os unsigned numbers. Isto porque não aumentamos ou diminuimos a quantidade de bits, apenas pegamos os mesmos bits e mudamos a nossa interpretação em relação a eles. Considere:

MAX usigned = 15;
MIN usigned = 0;
MAX signed = 7;
MIN signed = -8;

O valor máximo positivo para signed é 7 e não 8 porque esta sendo considerado também.

Para que fique de fácil visualização, imagine uma casa. A casa é grande, porém decimos dividir os comôdos entre duas pessoas. Ainda é a mesma casa, mas pessoa X tem acesso a menos espaço que antes agora que Y esta presente.

Conclusão

Como sempre, eu não considero minha explicação adequada como a de um professor, mas espero que ao menos uma pessoa tenha apreciado o que eu trouxe.

Agradeço pela a leitura até aqui!

Meu pai gosta bastante de Lotofácil e sempre teve o costume de fazer contas de fechamento e desdobramento no papel.

Era aquela coisa: várias dezenas anotadas, combinações, contas, conferência de jogos... e um monte de papel espalhado.

Um dia parei para entender exatamente o que ele estava fazendo.

Depois de algumas conversas, comecei a transformar aquilo em código.

A ideia inicial nem era criar algo público. Eu só queria facilitar a vida dele.

No fim nasceram duas ferramentas:

Calculadora de Fechamento da Lotofácil
https://valorfinal.com.br/calculadora-fechamento-lotofacil

Calculadora de Desdobramento da Lotofácil
https://valorfinal.com.br/calculadora-desdobramento-lotofacil

As duas são gratuitas.

O mais engraçado é que meu pai realmente gostou.

Virou a nova diversão dele. Detalhe ele tem 75 anos.

Agora ele fica horas colocando dezenas, testando combinações, gerando jogos e depois conferindo os resultados. Basicamente trocou o papel pela ferramenta.

E para mim acabou sendo um projeto bem legal porque eu não conhecia praticamente nada sobre fechamento e desdobramento de loterias antes disso. Precisei primeiro entender a lógica que ele fazia manualmente para depois conseguir transformar aquilo em uma ferramenta que realmente fosse útil.

Como já estava funcionando bem para ele, resolvi disponibilizar para todo mundo.

Se alguém aqui também joga Lotofácil ou tem pai, mãe, avô, amigo que gosta dessas contas, manda para a pessoa testar.

E se encontrarem alguma coisa que possa ser melhorada, podem falar,toda sugestão é bem-vinda.

Obrigado

Muitas são as preocupações de que a AI irá substituir os humanos. Bem, o mesmo aconteceu com outras tecnologias no passado.

Porém, as preocupações de agora são até validas. Porque a AI consegue fazer coisas no nível humano, e até melhor! É diferente de qualquer outra coisa antiga, em que era só uma ferramenta e o ser humano no controle é quem dava a forma. Sabe, agora a AI consegue fazer coisas no nível humano quando um humano dá um comando a ela. Ops… peraí. Quando um humano dá um comando a ela? Sim e aí o humano não precisa pensar, ele delega a AI, que vai tomar todas as decisões por ele, e quando algo dá errado, a culpa é dela. Ops.. como é? Pois é, parece que estamos vivendo em um momento delicado.

Uma AI consegue fazer coisas no nível humano quando um humano dá um comando a ela

Ao mesmo tempo, a AI, consegue nos substituir, mas ao mesmo tempo não consegue. Parece que falta alguma coisa. E parece que a palavra é “decisão”. Essa palavra tem peso. Afinal, se algo existe, é porque houve alguma decisão, pequena ou grande, mas houve. E se houve uma decisão, houve um responsável. Se alguém é responsável, então a ação parte dele. Pensar assim é interessante. Por exemplo, a AI desenha uma linda “pintura” onde há uma casa e uma linda paisagem, e você vê em uma rede social. Quem fez isso? Alguém diz: a AI. Porém ela não faria isso se não tivesse alguém que tomou uma decisão de propositalmente transformar uma onda cerebral (ou seja, um pensamento) em uma ação. E por mais ínfima que pareça, essa é uma decisão interessante. Passou por:

1. Ter um entendimento do que é uma AI;
2. Escolher uma dentre tantas;
3. Formular um prompt;
4. Por fim, clicar em “Enviar";

Mas o fim está longe de terminar. Foi preciso:

5. Escolher propositalmente uma rede social;
6. Fazer o upload do arquivo, talvez (6.1) escrever alguma legenda e então
7. Clicar em “Postar”.

Você viu? E ainda tem gente que diz que foi a AI que fez.

Mas claro que tudo parece muito óbvio. Teve mesmo que ter um humano por trás. O humano é que é o problema, não a tecnologia. E aí podemos ampliar esse exemplo para qualquer outra coisa que foi a AI que fez. Se algo existe é porque houve uma decisão. Se houve uma decisão, alguém foi responsável. Desde uma função em algum programa a um vídeo de gatinho tomando leite. E o que será que podemos dizer dos agentes de IA, que tomamam incontáveis decisões "sem um responsável"?

A IA não faria algo se não tivesse alguém que tomou uma decisão de propositalmente transformar um pensamento em uma ação

Mas talvez estamos só divagando aqui. Pois não chegamos em lugar algum. Às vezes, só o fato de pensar e analisar algo, já é melhor do que um resultado concreto. Afinal qualquer ação começa no pensamento.

Mas a pergunta é:

A AI pode substituir humanos? Olha, depende.

Veja só… é na questão da responsabilidade.

É claro que com a evolução da tecnologia, muitas funções acabam sendo centralizadas em uma pessoa. Isso é algo natural.

Imagine quantas tarefas cotidianas do seu trabalho ou vida pessoal a AI está agilizando. Talvez você antes demorava horas para fazer algo. Agora leva minutos. Isso é algo natural. Não escrevemos mais tanto a mão, nós digitamos e agora pedimos pra IA escrever. Levamos menos tempo. (Embora nesse texto, IA nenhuma tocou)

Mas veja o seguinte cenário: uma empresa pode até reduzir seu pessoal, afinal a AI reduz o tempo das coisas.

Porém, veja essa situação: um designer pede pra AI fazer uma função de um sistema complexo. A AI implementou, ele testou e tudo funcionou. Perfeito! Não precisamos mais de um programador! Bem, uma semana depois aquela função começa a bugar e o sistema quebra. O designer vai lá, faz outro prompt. A AI conserta. Tudo funcionando. E isso acontece algumas vezes. Dali uns dias, o sistema até não quebrou mais, porém algumas coisas não estão funcionando como antes. Alguns comportamentos estão estranhos. Outras coisas estão sendo salvas, mas o banco de dados está com bugs. Alguns dispositivos dão erro, enquanto em outros aparentemente está certo.. Parece que está tudo meio “mexido”. E agora? quem vai arrumar essa bagunça? (parece que o agente inteligente artificial tomou algumas liberdades)

Bem, chegamos numa das extremidades da AI. Ela até faz. Mas quem deu o comando é responsável. Quem deu o comando sabia o que estava fazendo? Ele tinha em mente as limitações e detalhes? Nesse caso, não. Apenas um conhecimento superficial. E de quem é a responsabilidade? Da AI, ou “ai” de quem fez?

Se fosse um programador com conhecimento de causa, tudo seria diferente. Poderia dar problemas? Com certeza. (e sempre tem bugs de todas as espécies). Mas ele saberia usar um log para investigar, e ir até a causa raiz do problema.

Poderíamos inverter essa situação para um programador backend que pede à AI fazer um design de uma landing page. Mas ele não sabe nada sobre branding ou CTA, ou como se deve estruturar uma página.

Novamente, isso tudo poderia ser concentrado em uma pessoa — desde que saiba o que está fazendo. Pois a AI não sabe. Ela só obedece o que alguém pede. E alguém sim pediu.

Então, a AI pode substituir humanos? Depende. Eu acredito fortemente que os que tomam decisão (pequena ou grande) sem saber, serão substituídos por aqueles que entendem do assunto e usam AI para fazer o trabalho braçal

Passando aqui pra compartilhar um repositório que particularmente eu acredito, fiz um teste de um framework que criei e funcionou muito bem, e achei tão bom e tão chato que estou aqui passando pra compartilhar com vocês e coletar feedback também.

Basicamente o que eu fiz é o dever de casa que todo dev deveria fazer, mas na prática não é o que fazemos, muitas vezes não temos paciência em aplicar git hooks e técnicas de CI e CD, então basicamente fiz um rep onde você pode instalar gates de QA (Quality Assurance) na seu projeto e pronto.

Esse trabalho resolve isso de algumas maneiras:

1. System prompts, o mínimo.
2. Git hooks: executa scripts de validação localmente, pra verificar segredos e complexidade de código.
3. Github Actions:
4. 1. QA structural gates: duplicação de código, complexidade assintótica limitada, hardcoded secrets.
5. 2. Megalinter.
6. 3. Testes de unidade automatizados.

A grande ideia é não confiar na IA pra garantir qualidade, e sim usar indicadores estáticos de qualidade, assim o commit só sobe se seguir um padrão semantico de nome e passar nos testes locais, a PR só aprova se a complexidade ciclomática estiver abaixo de 10, se o arquivo tiver menos de 300 linhas, e se não tiverem mais de 6 funções em um mesmo arquivo.

É claro que todos esses indicadores são adaptáveis a cada projeto, mas essa é uma maneira aceitável de garantir o mínimo. Isso torna o trabalho revisável e melhora muito a manutenção do código. Você basicamente força a IA a não ser relaxada (e ela tenta).

Por fim, esse rep não resolve qualidade sozinho, mas te ajuda com o mínimo, ter prompts forçando a tua IA a não escrever código que não responde as tuas regras de negócio e forçando a ter o mínimo de padrões código limpo.

Obs: como disse, precisa ainda garantir que o código atende as regras de negócio que você tem, e isso é trabalho só seu. E lançar esse rep em um projeto já em andandamento pode te levar a um ciclo de refatoração infindável, por isso veja quais gates fazem sentido serem ativados no seu projeto.

Aqui o link: https://github.com/PedroOSilv/qagates

Quero ouvir de vocês o que pensam disso.

Salve Lucas Montano, seu vídeo me inspirou a fazer esse projeto ...

Se você leu até aqui, obrigado pela atenção!

O oh-my-agent 12.4.0 acaba de receber um refactor guard cross-vendor e avaliação isolada de harness. Quando um agent edita linhas demais em um único arquivo sem refatorar, o runtime agora bloqueia o evento de parada e despacha um refactor engineer dedicado para limpar a bagunça antes de devolver o controle.

Novidades

• Cross-vendor refactor guard: O novo hook refactor_guard rastreia o orçamento de linhas entre as ferramentas de edição. Se um agent ultrapassar 500 linhas em um único arquivo, o hook bloqueia a finalização e despacha o refactor-engineer. Isso funciona em todos os 9 vendors suportados.
• Isolated harness evaluation: O comando oma harness agora compara overlays .agents com escopo fechado em workspaces temporários pareados, usando verificações determinísticas de artefatos e record and replay vinculados a hashes.
• Agent Plugins support: Um git clone padrão do repositório agora atua como um pacote instalável do Agent Plugins 1.0.0, expondo plugin.json, mcp.json e a árvore de skills diretamente na raiz do repositório.
• Translation profiles: O oma-translator agora usa perfis por idioma (en, ko, ja, zh) para isolar registros de sistema e regras de tipografia da taxonomia de padrões compartilhada.

Controlar o contexto de um agent exige precisão. O novo refactor guard garante que grandes mudanças sejam forçadas a passar por uma fase de refatoração antes do fim da sessão, mantendo os arquivos manuteníveis.

Correções

• Decisões de SCM, como splits de commit e merges, não são mais gravadas como fatos duráveis no armazenamento de memória do agent. Elas já estão no histórico do git, e ignorá-las evita que metadados do repositório ofusquem as reais decisões cross-session.
• O comando oma link agora renderiza a união de hooks de vendors e subagents para arquivos compartilhados como o AGENTS.md, impedindo que o arquivo fique alternando de estado quando diferentes vendors disparam o merge.
• Servidores MCP adicionados pelo usuário em .cursor/mcp.json são preservados durante as atualizações. A CLI agora faz o merge dos servidores que ela gerencia em vez de sobrescrever o arquivo inteiro.
• As verificações de autenticação do OpenCode agora derivam o provedor corretamente a partir da especificação do modelo, resolvendo falsos reportes de estado offline quando usuários se autenticavam com provedores alternativos.

Melhorias

• Substituímos as alegações inatingíveis de orçamento de contexto na documentação por custos de tokens medidos e reprodutíveis. O design de skills em duas camadas evita cerca de 75% do overhead de carregamento de skills em tarefas complexas.
• Limitamos a proteção de Single Source of Truth (SSOT) estritamente aos arquivos de definição. Os agents agora recebem instruções explícitas de que os outputs em .agents/results/ são esperados, impedindo que deletem o estado de handoff da sessão na tentativa de restaurar a proteção.
• As traduções em coreano em todas as 22 páginas foram sincronizadas para paridade com a fonte em inglês, normalizando os registros de instrução e corrigindo desvios estruturais legados.

Instalação

# macOS / Linuxcurl -fsSL https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.sh | bash

# Windows (PowerShell)irm https://raw.githubusercontent.com/first-fluke/oh-my-agent/main/cli/install.ps1 | iex

O oh-my-agent é construído para equipes que orquestram mais do que escrevem prompts. O próximo passo: primitivas de rollback em múltiplos turnos para loops de raciocínio travados.

Texto original (em inglês): https://dev.to/gracefullight/oh-my-agent-cross-vendor-refactor-guards-and-isolated-eval-4c9o

https://github.com/first-fluke/oh-my-agent

Introdução#

Publicar uma biblioteca .NET no NuGet.org não é apenas empacotar um projeto e enviar o .nupkg para o servidor. O ponto mais importante é tratar a API pública como um contrato que outras pessoas e outros times vão consumir. Se eu publicar uma API sem pensar em compatibilidade, o problema não fica só no pacote: ele se espalha para dependências, pipelines e aplicações que dependem do mesmo assembly. Por isso, a publicação segura combina três pilares: contrato estável, versionamento consciente e validação real do artefato em um ambiente de consumidor separado.

A ideia deste artigo é explicar a jornada completa de uma biblioteca .NET: preparar a API, decidir o tipo de distribuição, validar localmente, publicar em um ambiente de teste e, por fim, divulgar a versão estável em nuget.org. Também vou mostrar quando o pacote deve ficar em um feed público e quando ele precisa ir para Azure Artifacts ou GitHub Packages. O objetivo é dar uma visão prática para quem está publicando o primeiro pacote ou tentando organizar a distribuição interna da empresa.

Se você já usou pacotes NuGet em projetos de aplicação, sabe que o fluxo de consumo parece simples na superfície: restaurar, compilar e executar. O ponto delicado é o contrato. A biblioteca que parece compatível no build pode gerar erros de runtime quando o pacote é consumido em um projeto externo com metadados ou dependências diferentes. Por isso, vale separar a publicação em etapas: feed local, ambiente de teste do NuGet, publicação pública e feeds privados. O percurso é simples de entender, mas a disciplina é o que evita retrabalho e quebrar clientes.

⚠️ Atenção: o ambiente de teste do NuGet não substitui um feed privado. Ele serve para validar o fluxo de publicação antes de subir a versão definitiva. Azure Artifacts e GitHub Packages existem para distribuição interna persistente e autenticada.

Pré-requisitos#

Antes de empacotar o primeiro pacote, eu gosto de validar alguns preceitos básicos para evitar a sensação de que a publicação foi bem-sucedida e, depois, o pacote não ficou útil para quem vai consumir. Em primeiro lugar, você precisa do .NET SDK instalado e funcional; a checagem mínima é dotnet --info. O lado operacional também importa: uma conta no nuget.org e uma API key com escopo limitado para o pacote. Isso reduz o impacto de vazamento ou uso indevido.

O próximo passo é separar o cenário de distribuição. Se o pacote é público, um fluxo de publicação no nuget.org exige revisão e indexação. Se ele é interno, a melhor alternativa costuma ser Azure Artifacts ou GitHub Packages, com autenticação e controle de acesso. Em qualquer caso, o ideal é nunca expor tokens em arquivos versionados ou em comandos de terminal que fiquem no histórico do shell.

Também vale deixar claro que esse processo não é só de “empacotar e publicar”. É de “empacotar e validar”. A rotina de publicação tem um exercício importante: criar um projeto consumidor separado e instalar o pacote que acabou de ser gerado. Só assim é possível verificar se README, dependências, arquivos e metadados estão corretos.

Defina o Contrato e a Estratégia de Versionamento SemVer#

A publicação de bibliotecas .NET exige que o versionamento seja tratado como parte do contrato público. O SemVer é a convenção mais usada no ecossistema e define que a versão siga a estrutura MAJOR.MINOR.PATCH. Cada componente comunica algo diferente:

• MAJOR indica alteração incompatível de API pública
• MINOR indica adição de funcionalidade compatível
• PATCH indica correção de defeito sem mudar a API
  Não é só uma convenção estética. O número da versão comunica ao consumidor o risco da atualização. Se eu remover um método público ou mudar o comportamento de forma que um cliente dependa do antigo contrato, a mudança é de MAJOR. Se eu adiciono um novo método a uma API que não quebra ninguém, a mudança é de MINOR. Se eu corrijo um bug internalmente sem alterar a interface, a mudança é de PATCH.

Eu também gosto de reforçar a importância das versões pré-release. Em bibliotecas, 1.5.0-beta.1, 1.5.0-rc.1 e 1.6.0-alpha.3 são úteis para validar uma funcionalidade antes de o pacote ser publicado como estável. Isso reduz o risco de anunciar uma versão definitiva sem testar os impactos reais. A regra mais importante é simples: uma versão publicada é imutável. Se ela estiver errada, você corrige em uma nova versão, não reescreve a antiga.

💡 Dica: o chamado SemVer 2 também permite pré-releases com rótulos e regras de normalização que o NuGet aceita. Isso é importante quando você quer testar uma nova funcionalidade com consumidores que ainda não querem depender dela em produção.

Prepare a Biblioteca para Distribuição#

Uma biblioteca pode ser pequena e ainda assim precisa de itens mínimos de qualidade para ser publicada. O projeto de exemplo usado neste artigo está no repositório de exemplos do blog e chama-se Contoso.TextRules. Ele expõe regras reutilizáveis para validação e normalização de texto. A estrutura do pacote é simples, mas a forma como ele é descrito no .csproj é o que permite que o NuGet gere uma página útil no site e que o pacote seja reconhecido corretamente pelo tooling do .NET.

No arquivo de projeto, alguns metadados são fundamentais:

• PackageId — identifica o pacote
• Version — define a versão da distribuição
• Authors — informa autoria
• Description — resumo útil para busca e descoberta
• PackageTags — pesquisa e classificação no NuGet.org
• PackageReadmeFile — inclui README dentro do pacote
• PackageLicenseExpression — licença SPDX para transparência
• RepositoryUrl e RepositoryType — ajuda na navegação e rastreabilidade
  Além disso, vale empacotar símbolos quando a biblioteca é relevante para depuração e diagnósticos. O dotnet pack também consegue incluir arquivos do pacote, como README.md e LICENSE, o que melhora bastante a experiência de quem vai consumir a biblioteca.

A separação entre abstração e implementação também é relevante como boa prática. O NuGet tem uma cultura muito forte de pacotes pequenos e de responsabilidade clara. Em projetos maiores, é comum separar um contrato da implementação: por exemplo, projetar uma biblioteca de abstração com interfaces e contratos e outra biblioteca com a implementação concreta. Isso evita que consumidores dependam de todo o conjunto de funcionalidades e permite que a API pública evolua com mais clareza. Isso não é obrigatório para todo projeto pequeno, mas é um padrão útil para bibliotecas de plataforma ou componentes de domínio.

📂 Código Fonte: O exemplo completo está disponível no repositório de exemplos do blog:
BlogSamples/Packaging/NuGetPublish/

Empacote e Valide Localmente Antes do Push#

Depois de preparar a biblioteca, o próximo passo é empacotar o artefato em modo Release. Isso é o ponto em que eu verifico se o projeto realmente gera um pacote completo. O comando principal é:

dotnet pack src/BlogSamples/Packaging/NuGetPublish/Contoso.TextRules/Contoso.TextRules.csproj -c Release

O resultado esperado é um .nupkg na pasta bin/Release. Mas o simples fato de existir um arquivo não basta. Eu sempre inspeciono o pacote para confirmar que ele contém o README, a licença e as dependências corretas. O pacote pode compilar e ainda assim ter metadados incompletos ou arquivos faltando, o que costuma aparecer quando a biblioteca é consumida por um projeto externo.

A validação mais importante é consumir o pacote em outro projeto. Isso muda o cenário: o consumidor não está dentro do mesmo repositório nem do mesmo assembly. Ele instala o pacote via dotnet add package ou via feed local, e aí aparecem erros de integração que os testes da própria biblioteca não capturam. Um erro clássico é um arquivo que fica ausente no pacote ou um README que não foi incluído corretamente. O pacote precisa funcionar como um item distribuído, não apenas como um projeto compilado localmente.

Valide no Ambiente de Teste do NuGet#

Depois que o pacote está funcionando localmente, o próximo ambiente natural é o teste do NuGet. O endereço oficial é https://int.nugettest.org. Esse ambiente foi criado para validar o fluxo de publicação antes do envio ao feed público. O objetivo não é substituir o processo de produção, e sim confirmar que o pacote pode ser enviado, restaurado e consumido em um cenário semelhante ao real.

Em geral, o fluxo é simples: configurar uma fonte de pacote nomeada para o ambiente de teste, autenticar com o usuário e enviar a versão. Com o pacote em mãos, um projeto consumidor diferente pode restaurá-lo e executar o código real. Essa validação reduz o risco de uma falha de packaging ou de uma API pública que ainda não está pronta para o feed público.

ℹ️ Informação: a documentação oficial do NuGet usa int.nugettest.org como ambiente para testar a publicação antes do nuget.org. Pacotes enviados para esse ambiente podem não ser preservados, por isso ele é útil para validação, não para distribuição persistente.

Publique uma Versão Estável no NuGet.org#

Quando a API pública está pronta e o pacote passou pela validação de consumo, a próxima etapa é publicar a versão estável em nuget.org. Esse processo exige uma API key do NuGet com escopo mínimo: o ideal é restringir o token ao prefixo do pacote e ao tempo de validade necessário. Isso reduz muito o impacto de vazamento de credenciais.

O comando mais comum é o dotnet nuget push, geralmente com o pacote já empacotado em Release:

dotnet nuget push ./artifacts/Contoso.TextRules.1.0.0.nupkg --api-key $NUGET_API_KEY --source https://api.nuget.org/v3/index.json

Na prática, a publicação no nuget.org não é o fim do processo: ela também dispara a indexação e a disponibilidade do pacote para busca e restauração. O pacote passa por validações do NuGet e, em alguns casos, demora alguns minutos para aparecer como disponível para instalação. Isso é normal e faz parte do fluxo oficial. Também vale deixar claro que a decisão de usar unlist faz sentido para remover uma versão da visibilidade pública sem apagá-la por completo; já “excluir” uma versão não é a abordagem recomendada para distribuir um artefato público de forma segura.

A regra mais importante é reservar a primeira estável 1.0.0 para o momento certo. Em bibliotecas, eu prefiro validar a API em pré-release primeiro. Isso dá tempo de ajustar comportamento sem a pressão de “uma versão potencialmente quebrada” já disponível publicamente.

Distribua Bibliotecas Internas com Azure Artifacts e GitHub Packages#

Nem todo pacote merece ir para nuget.org. Quando a biblioteca é interna, um feed privado é a opção mais segura e fácil de operar. Azure Artifacts e GitHub Packages atendem a esse cenário com autenticação e controle de acesso. A decisão geralmente depende da assinatura da plataforma usada pela organização.

Azure Artifacts#

O Azure Artifacts funciona muito bem quando a organização já usa Azure DevOps e tem pipelines centralizados. O feed de pacotes fica associado à organização e ao projeto do Azure DevOps, e a autenticação pode ser integrada a pipelines e regras de segurança. Para times usando Azure como plataforma principal, essa é uma forma natural de publicar bibliotecas internas com políticas de acesso e revisão de versões.

GitHub Packages#

O GitHub Packages se encaixa bem em times que já vivem dentro do GitHub. A autenticação usa token com escopo e permissões mínimas, e a integração com GitHub Actions costuma ser direta. Isso facilita muito a publicação de componentes internos, bibliotecas compartilhas e dependências para repositórios privados e públicos em diferentes fluxos de desenvolvimento.

⚠️ Atenção: nunca deixe tokens em NuGet.Config versionado. O arquivo de configuração pode apontar para diferentes fontes, mas os segredos devem sair do repositório e entrar por variáveis de ambiente ou secret stores do CI.

Automatize Releases sem Quebrar Consumidores#

A automação de publicação é importante, mas ela precisa ser um guard rail, não um atalho. O fluxo ideal de CI/CD para uma biblioteca .NET é: validar testes, empacotar, verificar se a versão já existe no feed e só então publicar. Isso evita que uma tentativa de push reescreva uma versão já publicada ou publique um pacote quebrado para o feed errado.

Uma boa estratégia é separar release e publicação em dois momentos. O processo de tag e changelog fica em Git; a publicação de pré-release pode ir para feed privado ou ambiente de teste; a versão estável vai para nuget.org somente após revisão de compatibilidade. Isso ajuda a manter o controle da API pública e faz com que a decisão de publicar uma nova versão seja uma decisão mais consciente.

Em pipelines, a regra é proteger os segredos. O principal é manter o token em um secret do CI, usá-lo em um passo específico de publish e restringir as permissões. O código da biblioteca pode ser automático, mas a decisão de liberar uma nova versão estável continua sendo algo que exige atenção humana e documentação de breaking change.

Exemplo Prático#

Vou usar o mesmo cenário do projeto de exemplo: uma biblioteca chamada Contoso.TextRules com regras de validação reutilizáveis. O objetivo é demonstrar a parte do contrato: a API pública fica estável, a versão de pacote inicia como 1.0.0-alpha.1, e a promoção para 1.0.0 acontece depois que a biblioteca é validada em um ambiente de consumidor separado.

Primeiro, a biblioteca em si. O trecho principal mostra como a API pública é simples e previsível:

namespace BlogSamples.Packaging.NuGetPublish;public sealed class TextRuleSet{    public bool IsValidEmail(string value)    {        ArgumentException.ThrowIfNullOrWhiteSpace(value);        return value.Contains('@')            && value.Contains('.')            && value.IndexOf('@', StringComparison.Ordinal) > 0;    }    public string NormalizeWhitespace(string value)    {        ArgumentException.ThrowIfNullOrWhiteSpace(value);        return string.Join(' ', value.Split(' ', StringSplitOptions.RemoveEmptyEntries | StringSplitOptions.TrimEntries));    }}

📂 Código Fonte: O exemplo completo está disponível no repositório de exemplos do blog:
BlogSamples/Packaging/NuGetPublish/Contoso.TextRules/

Em seguida, acrescento os metadados importantes para o pacote:

<Project Sdk="Microsoft.NET.Sdk">  <PropertyGroup>    <TargetFramework>net10.0</TargetFramework>    <PackageId>Contoso.TextRules</PackageId>    <Version>1.0.0-alpha.1</Version>    <PackageReadmeFile>README.md</PackageReadmeFile>    <PackageLicenseExpression>MIT</PackageLicenseExpression>    <RepositoryUrl>https://github.com/lzocateli/blog-zocateli-sample</RepositoryUrl>    <RepositoryType>git</RepositoryType>  </PropertyGroup></Project>

A geração do pacote acontece em Release:

dotnet pack src/BlogSamples/Packaging/NuGetPublish/Contoso.TextRules/Contoso.TextRules.csproj -c Release

Para consumo em um projeto separado, eu também gosto de configurar uma fonte local ou de teste e instalar o pacote em um consumidor mínimo:

dotnet new classlib -n Contoso.TextRules.Consumercd Contoso.TextRules.Consumerdotnet add package Contoso.TextRules --version 1.0.0-alpha.1 --source /caminho/para/o/feed

Esse passo é essencial. Ele confirma que a biblioteca não depende apenas do projeto em que ela foi compilada, mas do artefato que será entregue ao consumidor final. Depois da validação, a promoção para 1.0.0 fica muito mais segura e a decisão de publicar em nuget.org passa a ser uma escolha tecnológica, não só uma sensação de “está funcionando”.

Dicas e Boas Práticas#

• Trate a API pública como contrato. Qualquer alteração de assinatura, comportamento observável ou semântica documentada precisa ser avaliada pelo impacto em consumidores antes de escolher a versão SemVer.
• Consuma o .nupkg em outro projeto. Testar apenas a biblioteca compilada não verifica se o pacote contém README, dependências e assemblies corretos.
• Crie API keys e tokens com escopo mínimo. Uma credencial limitada ao prefixo do pacote e à operação de push reduz o impacto de vazamento acidental.
• Nunca reutilize uma versão publicada. Corrija o problema em uma nova versão PATCH ou publique uma nova pré-release; isso preserva reprodutibilidade de restore.
• Separe fontes públicas e privadas no NuGet.Config. Dê nomes claros às fontes, restrinja mapeamento de pacotes quando apropriado e evite que dependências internas sejam procuradas no nuget.org.
• Automatize, mas preserve revisão. O CI deve garantir testes e empacotamento repetíveis; a decisão de uma release estável ainda exige revisão de compatibilidade e changelog.

📖 Artigo completo com exemplos de código: Como Publicar uma Biblioteca .NET no NuGet.org

Normalmente jogar o jogo de tabuleiro WAR é bastante demora por conta das batalhas de dados, pensando nisso, criei usando o cloud um "gerenciador" de WAR, para agilizar as partidas. Confira:
Online: https://manager-online-war.vercel.app/

Github: https://github.com/leodeymison/manager-online-war

Olá Devs,

A um tempo atrás eu estava com um hiperfoco sinistro no Fabio Akita, e fiz algumas anotações e hoje, quis compartilhar com vocês!

Aprendendo a Aprender

• Todo curso online é um tutorial ou coisa simples, superficial e não se aprofunda.
• Vocë não pode aprender arte usando um livro passo a passo de como desenhar o naruto, você até vai desenhar o naruto, mas não vai saber desenhar, e talvez nem saber desenhar o mesmo naruto sem o passo a passo.
• Os estagiarios devem entender e aprender a estudar, e não entregar, afinal eles estão ali para aprender, não entregar, se quiser que entrega, contrata um indiano que é o mesmo preço.
• Nenhum funcionario deve fazer algo sem saber, o porque daquilo, como funciona e como fazer.
• Microgerenciamento NÃO EXISTE

Como Aprender?

1. Sem aula
2. Sem material
3. Sem professor
   Assim se aprende de verdade, batendo a porta na caram se ferrando e aprendendo

• Devemos aprender a formular a pergunta certa, e não ter a resposta certa
• Passamos a vida seguindo passo a passo, e nunca aprendendo algo real
• Tudo tem que ser dificil, para poder assim aprender.
• Você não é sua linguagem de programação
• Aprender = se virar nos 30
• Quem se destaque é aquele que aprende de verdade e se esforça

Como realmente estudar na faculdade?

• Defina bem o que estudar (ter clareza)
• Anotar termos para estudar depois, e tudo o que aprender, tentar ensinar para alguém.
• Tire a faculdade da frente
• Crie um site de exercios para praticar
• Defgina como praticar o que aprendeu
• Transforme TUDO em estudos
• Arranjar tempo para estudar, no onibus, no trabalho, no banho, se vira meu!
• Tenha SEMPRE um projeto pessoal
• Ajude os outros

AGORA O MAIS IMPORTANTE:

• Defina quem você quer ser;
• Como chegar lá;
• O que preciso para chegar lá;

Eu não sou responsavel por esses ensinamentos, todos eles vem do Akita, apenas sintetizei algumas coisas para compartilhar por aqui. Fique a vontade para compartilhar por aqui a sua opinião e coisas a acrescentar!