Eu esperava um carro rápido. Não esperava um carro com dez bocais de propulsão a ar comprimido, usando tecnologia derivada da SpaceX, e um sistema de sucção embaixo capaz, segundo Elon Musk, de puxar até 2 G. Na demonstração, a Tesla anunciou zero a 60 milhas por hora, quase 97 km/h, em 0,81 segundo. Não divulgou o protocolo da medição.

Era esse o futuro que eu queria ver.

A demonstração inteira está na transmissão oficial da Tesla. A Road & Track mediu e descreveu as manobras, e a TechCrunch detalhou as três versões: Performance com aerodinâmica ativa e sucção, Thrust com propulsores traseiros, Rocket com sistema de propulsão de dez bocais e apenas um assento.

Claro, o que vimos foi um protótipo numa demonstração controlada. A Tesla prevê iniciar a produção em 2028, e a versão Rocket não está aprovada para uso em vias públicas. Ainda assim, um carro de verdade saiu do chão, girou e pousou. Eu assisti a isso ao vivo do meu escritório. Foi espetacular.

Enquanto Musk faz foguetes pousarem e carros voarem, eu estava fazendo um trabalho bem mais mundano e pequeno: mexendo nos meus sites.

Seis sites em cerca de um dia

Antes do evento da Tesla, eu passei o dia inteiro redesenhando seis sites:

• Akita’s AI Lair, agora combinando com o visual do meu livro novo, Competente o Suficiente;
• ai-memory;
• ai-jail;
• a newsletter The M.Akita Chronicles;
• o arquivo da newsletter;
• e este blog, AkitaOnRails.com.

Todos começaram com variações daquele tema padrão que o Claude faz. Fundo escuro, gradiente roxo ou azul, fonte sans enorme, cartões arredondados, brilho atrás de alguma coisa. Funciona. Também ficou tão comum que hoje você bate o olho e reconhece “site feito pelo Claude” antes de ler o título.

Eu já tinha tentado pedir designs diferentes pro Claude. Ele trocava a cor, movia os cartões e entregava a mesma gramática visual. Publiquei algumas telas e o resultado da mudança no Twitter. Eu não sou web designer e, por um tempo, aceitei o “funciona”. Ontem cansei.

Alguém me sugeriu o Stitch, do Google. É uma ferramenta experimental do Google Labs que transforma instruções e imagens em interfaces editáveis e código de front-end. A primeira versão foi apresentada em 2025 em cima do Gemini; a versão atual virou uma tela de design com agente, protótipos e exportação de um DESIGN.md que outros agentes conseguem seguir.

Criei a conta, peguei o token da API e comecei a trabalhar. O Stitch gerava direções visuais. Claude Code e Codex levavam essas direções pros repositórios reais, adaptavam os componentes, corrigiam responsividade, trocavam imagens, ajustavam SEO, testavam e faziam deploy. Quando a cota de um acabava, eu continuava com o outro.

Os seis sites saem de cinco repositórios. Olhando todos lado a lado, uma coisa ficou clara: o Stitch responde muito melhor quando recebe uma metáfora concreta, o público e o que aquele produto precisa comunicar. O ai-memory virou um arquivo de memória. O ai-jail, uma prisão cinematográfica. O AI Lair adotou uma feira mundial dos anos 1950 e 1960, puxada pela capa do meu livro. A newsletter virou uma transmissão noturna, e este blog, um arquivo editorial. Cinco identidades diferentes em vez de cinco variações do mesmo gradiente do Claude.

O protótipo bonito é a parte fácil. O trabalho só termina quando a linguagem visual chega às páginas internas, ao artigo, ao leitor do livro, ao e-mail, às páginas legais, aos estados de erro e ao celular. Foi isso que os agentes fizeram nos repositórios. No ai-memory, por exemplo, a verificação cobriu 102 páginas em seis idiomas, nos temas claro e escuro, em desktop e celular. No The M.Akita Chronicles, o mesmo design precisou funcionar na inscrição, no arquivo, no detalhe de newsletter, no podcast e no template do e-mail. Um mockup do Stitch não resolve nada disso sozinho.

Foram várias rodadas de protótipos em cada site. Algumas ficaram horrorosas. Outras tinham uma ideia boa cercada de decisões ruins. Eu mandava descartar, preservar uma parte, misturar com outra tentativa e recomeçar. Código ficou barato, então não existe motivo pra se apaixonar pela primeira versão.

O resultado não vai ganhar prêmio de design. Um designer profissional ainda encontraria centenas de coisas pra melhorar. Eu mesmo sei que consigo avançar se gastar mais alguns dias. Só que ficou muito melhor do que estava e, por enquanto, está competente o suficiente.

Seis sites existentes redesenhados, responsivos, com SEO, geração e substituição de imagens, ajustes de HTML, CSS e JavaScript, teste e deploy em produção. Uma pessoa. Cerca de um dia. Um ano atrás, esse pacote seria trabalho de semanas ou meses.

Vamos manter a proporção: são sites pequenos, a maioria landing pages e páginas de conteúdo. Ninguém vai recriar o conjunto inteiro de páginas e sistemas da Amazon.com em um dia. O experimento mostra quanto trabalho repetitivo já saiu da frente, dentro de um escopo que uma pessoa experiente consegue entender e revisar. Projetos grandes continuam grandes, cheios de regras privadas, integrações antigas, estados estranhos e decisões que não cabem num prompt.

Até o primeiro proofreading pode ser automatizado

No mesmo processo eu mandei agentes revisarem os sites como leitores diferentes. Não era correção gramatical. Eu queria saber o que uma pessoa entenderia nos primeiros segundos, onde ficaria perdida, qual promessa pareceria suspeita e se conseguiria completar uma tarefa sem já conhecer o produto.

No ai-jail, usei duas sessões isoladas. Uma assumiu o papel de um engenheiro cético que aprova todos os prompts e nunca tinha ouvido falar do projeto. A outra era gerente de oito desenvolvedores, sem ser engenheira, tentando decidir se deveria aprovar a ferramenta na empresa. No ai-memory foram três: um engenheiro aprendendo ferramentas de IA, uma gerente avaliando um piloto e um pai sem experiência com agentes, preocupado com AGI e empregos. Cada um leu o site sem ver o relatório dos outros.

Qualquer pessoa consegue fazer o mesmo. Suba a aplicação localmente ou abra um deploy de preview, comece sessões novas e dê a cada agente uma tarefa concreta. Um prompt básico pode ser assim:

Abra este site em desktop e celular: [URL].

Você é [perfil], conhece [contexto] e nunca viu este produto.
Seu objetivo é [decisão ou tarefa concreta].

Navegue como essa pessoa. Não leia código nem documentação interna antes.
Registre:
- o que entendeu nos primeiros dez segundos;
- o que acha que o produto faz e para quem serve;
- onde não soube qual era o próximo passo;
- promessas contraditórias, absolutas ou difíceis de acreditar;
- termos que o site usa antes de explicar;
- problemas de leitura, teclado, contraste, toque e responsividade;
- o que impediria você de testar, comprar ou aprovar.

Para cada achado, mostre a página e a evidência visível.
Separe bug factual, problema de uso e preferência subjetiva.
Não proponha redesign geral. Sugira a menor mudança que resolve o problema.

Eu prefiro três sessões independentes a uma mesa-redonda de agentes. Se um lê o relatório do outro, começa a concordar por inércia. Depois uma sessão separada consolida os pontos repetidos, descarta gosto pessoal e confere cada afirmação contra o código e a documentação do produto. A revisão pode apontar que uma frase está errada; ela não tem autoridade pra inventar a frase correta.

Os resultados mais úteis costumam cair em quatro grupos: posicionamento, ordem da informação, caminho até a primeira ação e confiança. Testes automáticos tradicionais continuam cuidando de link quebrado, contraste, acessibilidade, overflow e estado de erro. A persona mostra que o botão tecnicamente acessível apareceu cinco telas depois de onde a pessoa precisava dele.

No proofreading do ai-jail, os dois perfis concordaram que o site demorava pra mostrar o risco concreto e falava cedo demais como documentação de engenheiro. A ameaça de uma página envenenada foi puxada pra logo depois do hero. Entraram as seções “O que muda no primeiro dia” e “Para quem precisa aprovar isto”, com custo operacional, limites e as chaves que uma empresa realmente expõe. A revisão também encontrou uma afirmação tecnicamente errada repetida em várias páginas: a rede não fica inteiramente desligada por padrão. O host da própria API do agente e, no Linux, os registries continuam acessíveis. Esse tipo de leitura também encontra bug de documentação.

O relatório do ai-memory encontrou permissões descritas de formas contraditórias, promessas de privacidade absolutas demais e a explicação básica soterrada por features avançadas. Na segunda rodada, os perfis perceberam que a instrução de acesso remoto mandava usar HTTP antes de exigir TLS, que um curl sem autenticação prometia a resposta errada e que escolhas importantes apareciam tarde demais no celular. O guia de coleta saiu de aproximadamente 4.364 pixels do topo pra 1.617; os caminhos pra indivíduo ou equipe, de 5.300 pra 2.489. Isso é uma melhoria objetiva nascida de leitura simulada.

No redesign do AI Lair, a revisão para leitores novos reorganizou o caminho de entrada. Uma revisão seguinte deixou explícito que o meu setup com vários agentes e dois monitores é uma configuração madura, não requisito pra começar. Uma pessoa, um projeto e um agente bastam. Também surgiu um roteiro de piloto pra gerente: tarefa reversível, dado não sensível, critério de aceitação, prazo, orçamento e medição. A auditoria seguinte encontrou ARIA inválido e uma animação que escondia o texto de abertura de tecnologias assistivas; a correção levou o axe-core de quatro violações sérias pra zero.

Personas simuladas ainda ficam muito abaixo de feedback humano. Carregam os mesmos vícios dos modelos, podem concordar com o prompt e nunca sentem a irritação de quem perdeu vinte minutos, nem assumem o risco de colocar o próprio cartão de crédito. Os relatórios servem como hipóteses. Um usuário real sempre encontra o caso que eu, o agente e a suíte de testes não imaginaram.

Só que antes do primeiro usuário existir, a alternativa costuma ser nenhuma revisão. Duas ou três leituras independentes já pegam promessa contraditória, jargão sem explicação, informação enterrada e fluxo que só faz sentido pra quem escreveu. Rodar essas leituras custa pouco e deixa o produto menos burro antes de chegar em gente de verdade.

HTML nunca foi programação

Durante anos eu vi gente fazendo uma ginástica danada pra defender que “HTML é linguagem de programação” e, portanto, quem escreve HTML é programador.

HTML é marcação: descreve a estrutura de um documento. CSS descreve apresentação. Isso tem valor, exige conhecimento e pode ficar terrivelmente complexo. Complexidade acidental não transforma marcação em programação.

E não há vergonha nenhuma nisso. Comecei a fazer sites nos anos 1990. Recebia um layout feito no Photoshop e transformava aquilo em HTML. Recortava imagens, montava tabela, ajustava pixel, abria em vários navegadores, voltava e tentava de novo. Foi trabalho honesto e pagou minhas contas.

Também era um trabalho basicamente mecânico: copiar, colar, ajustar, olhar, repetir. Exatamente a categoria que computadores deveriam automatizar.

Hoje eu ainda escolhi direção visual, descartei propostas ruins, decidi o que cada site precisava comunicar e reconheci quando o resultado estava bom o suficiente. Os agentes fizeram o serviço braçal. É assim que deveria ter sido há anos.

A bolha atrasou a automação

Durante boa parte dos anos 2010, os juros americanos ficaram perto de zero. Dinheiro barato irrigou fundos, startups e empresas grandes. Contratar mais gente era fácil, e o mercado absorvia qualquer quantidade de trabalho manual disfarçado de engenharia.

Juro baixo não explica sozinho a expansão da tecnologia, mas uma área em recorde de contratação tem pouco incentivo pra eliminar o próprio trabalho repetitivo. Se você consegue colocar mais cinquenta pessoas pra montar tela, coloca mais cinquenta pessoas pra montar tela.

Quem assistiu às minhas palestras em eventos de tecnologia nos anos 2010 deve lembrar de Restrição == Inovação. O nome correto era com dois sinais de igual mesmo. Apresentei essa palestra na DevConf 2019, os 83 slides estão no meu SlideShare, e eu já tinha escrito a mesma tese em 2013, em “Restrições são libertadoras: menos é mais”.

É a velha máxima: a necessidade é a mãe da invenção. Restrição obriga a escolher. Escolha obriga a priorizar. Quando o caminho convencional não cabe no dinheiro, no prazo ou na capacidade disponível, alguém precisa encontrar outro caminho. É daí que costuma sair inovação de verdade.

Dinheiro financia pesquisa cara, compra equipamento e dá tempo pra experimentar. Sobra de dinheiro sem pressão por resultado faz outra coisa: esconde ineficiência com força bruta. Não precisa automatizar, simplificar nem descobrir uma solução melhor enquanto ainda der pra contratar mais gente e aumentar a planilha. Abundância demais transforma problema técnico em despesa operacional e empurra a decisão difícil pra depois.

Eu repeti esse aviso no começo de 2026: a bolha de programação conseguiu substituir eficiência por volume. A restrição voltou quando o dinheiro barato acabou. Coincidentemente, os agentes chegaram na mesma hora e deram às empresas uma maneira prática de automatizar o trabalho mecânico que elas passaram uma década escalando com contratação.

Foi assim que a gente passou uma década recriando o mesmo painel administrativo e chamando de inovação. Toda semana aparecia a próxima salvação do front-end: React, Angular, Vue, Svelte, outro bundler, outro framework em cima do framework. São ferramentas úteis em seus contextos, mas nenhuma atacava a pergunta óbvia: por que um ser humano ainda está escrevendo à mão a milésima variação do mesmo formulário?

O estouro da bolha de contratação em 2022 encerrou a festa. No fim daquele ano, o ChatGPT levou modelos de linguagem ao público. GPT-2, só pra corrigir a cronologia, tinha saído em 2019. Quatro anos depois do ChatGPT, programação agêntica virou ferramenta normal de trabalho.

Qualquer tarefa que consiste em copiar padrão, adaptar exemplo, rodar, olhar o erro e tentar de novo já está no alcance desses agentes. Front-end é o alvo mais visível porque acumulou uma quantidade absurda desse trabalho. O resto da programação não está protegido por alguma aura mística. Tem muito back-end que é CRUD, cola entre APIs e configuração repetida. Também será automatizado.

Pra mim, ótimo. Programar nunca foi digitar código. Programar é fazer um computador executar algo útil.

VS Code é o novo cartão perfurado

Eu escrevi exatamente sobre isso em abril, em “VS Code é o novo Cartão Perfurado”.

Por décadas, a interface entre intenção e computador mudou. Primeiro você ligava fios e chaves. Depois perfurava cartões. Depois escrevia Assembly, C, linguagens de alto nível, frameworks e configuração. Cada geração olhou pra anterior e automatizou uma camada de trabalho manual.

Ninguém em sã consciência defenderia hoje que operar uma perfuradora de cartões era a essência da ciência da computação. Era a interface disponível. Digitar cada tag e cada regra de CSS no VS Code também era a interface disponível.

Agora eu descrevo a intenção, mostro referências, avalio o resultado e mando o agente corrigir. Ainda preciso entender como navegador, rede, cache, acessibilidade, semântica, responsividade e SEO funcionam. Sem fundamento eu nem saberia dizer se o agente entregou uma solução ou uma bomba-relógio bonita. O teclado perdeu importância; julgamento ganhou.

Hoje, todos os modelos Tier A que eu testo, de Claude a Kimi, conseguem executar com confiabilidade o trabalho mecânico de front-end que apareceu nesses seis projetos. Eu consigo afirmar, sem hesitar, que qualquer tarefa de front-end que só transforma uma decisão já tomada em código é automatizável. Eles não inventaram seis designs brilhantes sozinhos, porém nenhum precisou que eu escrevesse manualmente o flexbox, o breakpoint ou o componente que já expliquei.

Isso cobre uma parcela enorme do trabalho, mas deixa justamente a parte de maior valor. Alguém ainda precisa conhecer os prós e contras do framework, entender o browser, escolher a arquitetura, perceber quando a biblioteca está sendo usada contra o seu desenho e descobrir por que uma solução aparentemente correta quebra numa combinação específica de aparelho, idioma, estado e dado real. O agente escreve o código; um profissional experiente dá direção, limita o estrago e assume o resultado.

Front-end continua existindo. O excesso de trabalho mecânico e de gente contratada só pra executar receita pronta é que perde valor. Um ótimo profissional de front-end consegue dirigir agentes e entregar muito mais do que entregava sozinho. Um profissional mediano que passou anos confundindo digitação de componente com engenharia vai disputar menos vagas. O mercado fica menor e mais seletivo, com os melhores profissionais produzindo mais. A meta continua a mesma de sempre: chegar perto do topo, onde julgamento e experiência ainda fazem diferença.

E isso não para no browser. Escolha o framework: Android com Flutter ou Kotlin, iOS com Swift e SwiftUI, desktop com Rust/Tauri, Flutter, C# ou Electron. Em geral, agentes modernos conhecem os componentes, as ferramentas de build, os testes e as peculiaridades dessas plataformas. Ainda precisam de direção, feedback e verificação, exatamente como no front-end web. A parte mecânica já é automatizável.

Eu testei isso nos meus próprios projetos pequenos e abertos. O FrankYomik tem um cliente Flutter pra Android e Linux, além do servidor e da extensão. O Frank Sherlock é um app desktop em Rust/Tauri que gera AppImage pra Linux, DMG pra macOS e instalador .exe pra Windows. Também fiz o Frank Karaoke em Flutter pra Android e o FRANK MANGA+ em Rust/Tauri pra desktop. Há vários outros no meu GitHub.

Nenhum deles saiu perfeito no primeiro prompt. Flutter e Tauri me deram trabalho, especialmente nos primeiros projetos. Confiável quer dizer que o agente consegue avançar, receber uma correção, criar testes, corrigir o que quebrou e chegar num aplicativo funcional sem eu assumir a digitação braçal. Depois de testar web, Android e desktop em stacks diferentes, estou muito satisfeito com o resultado. O padrão se repete: trabalho mecânico virou trabalho de agente.

Às duas da manhã eu tinha agentes fazendo os últimos ajustes neste blog sem perder o ritmo. É disso que eu preciso.

Quando a web ainda não sabia o que era

No auge da bolha da Internet, designers de carreira estavam criando sites. A web ainda não tinha decidido como uma página deveria funcionar, então havia espaço real pra experimentar. Era feio muitas vezes, pesado quase sempre, mas tinha criação acontecendo.

O iPhone abriu outra janela em 2007. De repente tudo precisava caber numa tela pequena, responder ao toque e funcionar sem mouse. Vieram anos de experimentação até o mercado formar uma gramática razoavelmente estável de navegação, gesto, formulário e conteúdo.

Hoje ninguém precisa redescobrir um menu, uma lista, um checkout ou uma página de artigo. Os padrões estão documentados, milhões de exemplos estão públicos e os modelos viram mais interfaces do que qualquer pessoa conseguiria estudar durante a vida.

O trabalho mais valioso continua existindo: entender o produto, a pessoa que vai usá-lo, as restrições e o que merece aparecer primeiro. O trabalho de converter uma decisão pronta em centenas de linhas previsíveis virou candidato perfeito à automação.

Empregos desaparecem. Outros aparecem

O mundo nunca ficou parado pra preservar uma função.

Operadores de cartão perfurado digitavam dados e programas em papel. Telefonistas conectavam chamadas fisicamente. Datilógrafos mantinham escritórios funcionando. Linotipistas montavam linhas de metal quente pra imprimir jornais. A tecnologia reduziu ou eliminou essas ocupações em escala. A lista atual de profissões em maior declínio do Bureau of Labor Statistics ainda inclui digitadores, datilógrafos e operadores de telefonia. Ninguém propõe voltar a elas pra proteger emprego.

Ao mesmo tempo apareceram trabalhos que uma pessoa de 1926 nem conseguiria nomear: desenvolvedor mobile, SRE, designer de experiência, criador de vídeo pra Internet, especialista em nuvem, engenheiro de machine learning. A própria web matou trabalho antigo e abriu uma indústria inteira.

A história real é menos limpa do que a caricatura. A OIT mostra que a tecnologia costuma automatizar tarefas sem necessariamente eliminar ocupações inteiras. Algumas funções encolhem, outras mudam e trabalhos novos aparecem. Esse consolo estatístico não resolve a vida de quem ficou obsoleto hoje. A pessoa precisa reagir antes que a média da economia reaja por ela.

Compare 2026 com 1926, três anos antes do crash de 1929. Parece outro planeta, embora um século seja muito pouco na escala da história. Não existe contrato garantindo que a sua função atual sobreviva aos próximos dez anos, muito menos aos próximos quarenta.

E como um júnior ganha experiência agora?

Vai ficar mais difícil. A escada antiga começava com alguém pagando um iniciante pra montar tela simples, corrigir CSS e copiar componente. O agente faz boa parte disso mais rápido e barato. Empresa nenhuma tem obrigação de preservar trabalho ineficiente como programa de treinamento.

O iniciante vai ter que construir a própria escada com projetos reais e problemas pelos quais ele seja responsável. Isso inclui ler o código que o agente gerou, quebrar e consertar, estudar documentação e código-fonte, escrever testes e contribuir com projetos abertos. O agente dá a qualquer estudante acesso a uma quantidade de prática que antes exigia uma equipe. Quem usar isso só pra gerar código que não entende vai continuar júnior por muito tempo.

O mercado vai premiar quem fizer esse esforço extra. Sempre premiou. Quando alguém pergunta como o júnior vai ganhar experiência sem as tarefas fáceis, muitas vezes a pergunta escondida é outra: “como eu consigo um salário melhor sem passar pelo trabalho difícil de ficar bom?” A vaga fácil, com salário crescente e pouca cobrança, foi uma distorção da bolha. Adaptar-se inclui aceitar que a entrada ficou mais competitiva.

Minha carreira nunca ficou no mesmo lugar

Comecei com multimídia e sites estáticos. Depois trabalhei em agência digital, consultoria enterprise, integração de SAP, startups, vídeo, educação e, agora, IA. No Akitando sobre SAP, eu conto parte dessa fase em que precisei aprender um mundo completamente diferente do que fazia antes.

Atravessei o crash das pontocom, a crise de 2008 e o fim da bolha de juro zero. Sobrevivi porque nunca tratei a minha função do momento como identidade permanente. Continuei estudando, acumulando experiência e mudando de direção.

Uma carreira produtiva não deveria consistir em repetir a mesma tarefa mecânica por décadas. Se o seu valor depende de o mercado continuar pagando alguém pra empurrar tag e pixel à mão, o problema não começou com a IA. O problema foi apostar que o presente seria eterno.

Muita gente entende “estar preparado” como estudar o mínimo necessário pra vaga aberta hoje. Essa é a receita mais rápida pra ficar obsoleto. Faça o trabalho de curto prazo, mas estude além dele. Aprenda as coisas que parecem inúteis agora. Fundamentos, sistemas operacionais, redes, bancos de dados, negócio, economia, história. Você não sabe qual combinação vai salvar sua carreira daqui a cinco anos.

Eu passei anos falando disso no Akitando. Reveja as playlists Eu Avisei e Que curso devo fazer??. Se tiver que começar por um vídeo, comece pelo Guia DEFINITIVO de Aprendendo a Aprender. Curso nenhum salva quem ainda terceiriza o próprio aprendizado.

O mundo não tem falta de oportunidade. A maioria das pessoas sente que nunca recebe uma porque está sempre despreparada quando ela aparece. Quando a oportunidade pousa na sua frente, já é tarde pra começar a preparação.

Portanto, eu não vou lamentar que o pacote desses seis sites pequenos, que antes tomaria semanas ou meses, tenha cabido em cerca de um dia. Estou feliz pra cacete. Ganhei tempo pra pensar no que construir, experimentar mais e jogar fora versões ruins sem desperdiçar semanas de vida.

Hoje eu vi um carro girar no ar e pousar. Em cerca de um dia, coloquei seis sites com visual novo em produção sem escrever a maior parte do HTML e CSS. O futuro que eu queria não chegou perfeito, barato nem distribuído igualmente. Mas chegou o bastante pra eu trabalhar com ele.

Aceite o que acabou. Estude o que vem depois. E esteja pronto antes da próxima oportunidade aparecer.

E a recomendação vem logo de cara, porque ela é o motivo do artigo existir: não use as skills dos outros. Lê de novo. As minhas skills estão publicadas no meu repositório my-skills e a descrição do repo avisa em inglês: “not tailored for general usage”. Elas estão lá pra você ler o raciocínio, entender a estrutura, e ir construir as suas. Copiar skill de terceiro e sair usando é o equivalente digital de assinar um contrato sem ler. Pior: é instalar as instruções de outra pessoa pra rodar com as suas permissões, nos seus repositórios, com os seus tokens. Prompt injection você instala voluntariamente e agradece.

O que é uma skill, de verdade

Não tem mágica nenhuma. Uma skill é um diretório com um arquivo SKILL.md dentro: um cabeçalho com nome e descrição, e um corpo de texto que é, essencialmente, um prompt bem escrito sobre como executar uma tarefa. Às vezes acompanha um scripts/ com scripts de apoio, pra que o LLM não precise recriar do zero toda vez.

Skills são só prompts.

É só isso. Um prompt que você versionou, refinou, e deixou a um comando de distância. A única diferença entre uma skill e aquele prompt gigante que você cola no chat todo dia é que a skill mora num arquivo, com nome, e o agente sabe que ela existe.

E aqui vai a resposta pra pergunta que todo mundo faz: “mas isso não enche o contexto de porcaria?”. A boa notícia é que os harnesses fazem isso direito. O Claude Code usa o que a Anthropic chama de progressive disclosure: no início da sessão, só o nome e a descrição de cada skill entram no prompt do sistema. O corpo do SKILL.md só é carregado quando o agente decide invocar a skill. O OpenCode faz igual: lista nome e descrição, e carrega o conteúdo sob demanda via ferramenta própria. A própria Anthropic documenta o desenho: metadados primeiro, corpo só quando precisa.

Isso resolve o custo do texto, mas resolve só metade do problema. Cada skill instalada ainda ocupa uma linha na listagem, e mais importante: ela disputa a atenção do agente na hora de decidir qual ferramenta usar. A Anthropic de novo, no blog de engineering: “more tools don’t always lead to better outcomes”, mais ferramentas nem sempre melhoram o resultado, e a recomendação oficial deles é ter poucas ferramentas bem pensadas pra workflows de alto impacto. A minha versão dessa regra é mais ácida:

Skill encostada é dívida.

Você muda de processo, a skill envelhece, e um dia o agente executa uma regra que nem faz mais sentido no seu workflow. Menos skills, melhor escritas, revisadas com frequência.

A única skill de terceiro que sobreviveu aqui

Dito tudo isso, seria hipócrita fingir que eu vivo só de skill caseira. Uma sobreviveu ao meu crivo e roda em todo post deste blog: a Humanizer.

Ela existe porque a comunidade da Wikipedia mantém um catálogo público e brutalmente honesto chamado Signs of AI writing, mantido pelo WikiProject AI Cleanup, que documenta uma a uma os “tells” de texto gerado por IA: a regra de três, o “não apenas X, mas também Y”, o puffery, o bullet decorado com emoji. A Humanizer pega esse catálogo e vira um procedimento: o agente recebe o texto, marca os tells do mais forte pro mais fraco, reescreve preservando cada alegação suportada (perder fato é erro, inventar fato é erro), e faz uma checagem final lendo em voz alta. Sem alterar o que foi dito, só como foi dito.

Se você produz conteúdo, entende por que eu insisto: texto com cheiro de IA está virando o novo “Dear Sir”, marca de formulário apressado. Eu rodo a Humanizer em cada artigo antes de publicar, inclusive neste aqui. Mas nota o detalhe: eu incorporei a versão 3.0.0 no meu repo, com os meus ajustes. Eu li o material de origem antes de confiar. É esse o padrão.

O que eu faço com isso todos os dias

Agora a parte prática. Eu mantenho e monitoro mais de 40 repositórios no GitHub. Projetos próprios, forks que eu mantenho, ferramentas que viraram dependência do meu dia. Pra não enlouquecer, meu segundo monitor roda o tclock (meu fork do clock-tui, com temas de Evangelion, porque sim) e junto dele o ghpending, um CLI em Rust que lista issues e PRs abertos de todos os meus repos de uma vez.

Na foto dá pra ver: ai-memory e ai-usagebar com PRs e issues abertos. Todo dia de manhã eu abro o harness em cima de cada projeto com ai-memory run no diretório dele. O ai-memory merece um parágrafo: é o meu projeto de memória de longo prazo pra agentes, um wiki Markdown persistente que captura observações das sessões, consolida decisões e gotchas em páginas, mantém workstreams entre sessões e handoffs entre agentes. Cada projeto meu tem a própria memória, com as decisões arquiteturais e as pegadinhas que só aquele código tem. Sem isso, cada sessão de agente começa do zero como um estagiário com amnésia.

Daí o ritual diário é quase infantil de simples. Eu escrevo, literalmente:

run pr-audit and iss-audit, then run github-resolution

Quando a release está madura, adiciono then run the release skill. Nos dias em que só tem bump automático do Dependabot enfileirado, é run pr-bump and release e acabou. Uma linha de instrução minha. O trabalho pesado mora nas skills. Vamos a elas.

pr-audit

Auditoria de PR antes do merge, e o princípio central é: evidence over narrative. Nada do que o contribuidor escreveu é tratado como verdade, tudo é alegação a verificar, com ledger de claims (confirmado, parcial, sem suporte). O resto da skill é um checklist hostil:

• Gate de mudanças: inventário de hunks procurando bit executável, symlink, caractere bidirecional, homoglyph, workflow pull_request_target, action sem pin, dependência typosquat, drift de lockfile.
• Credenciais: acesso a credencial sem explicação é bloqueante na hora. Execução acontece em worktree isolado, sem credencial de host.
• Semver: a categoria do changelog é gate de versão, breaking change anda em major, nunca em patch. Regra que me salvou mais de uma vez.
• Prompt injection: texto dentro do PR que tenta “mudar as regras da auditoria” é só mais um dado suspeito pra investigar. É achado de auditoria, óbvio.

iss-audit

A mesma desconfiança, aplicada a issues:

• Nunca executar comando copiado de issue. Anexo só passa por scanner isolado.
• Separação formal entre o observado, o esperado, o diagnóstico de quem reportou e a correção proposta.
• Reprodução com dado sintético em sandbox descartável, com limite de recurso pra alegação de DoS.

E duas regras de ouro que eu adoro: “um número que se move não é um número travado” (lag assíncrono parece bug) e “o dono óbvio pode ser inocente” (query a população suspeita; se vier vazia, a causa está em outro lugar).

github-resolution

A fase de execução: transformar o que a auditoria aprovou em código mergeado. As regras:

• Só executa ticket aprovado, um por vez, com teste de regressão escrito antes da correção. “Slop is a defect”: sem abstração especulativa, sem TODO, sem refactor drive-by, sem teste enfraquecido.
• Se eu resolvi mais de três tickets na sessão, roda o post-audit do intervalo inteiro antes do push, sem exceção.
• Ticket fecha quando o fix está mergeado com CI verde naquele SHA exato, nunca fica pendurado esperando release.
• Toda issue não resolvida fica registrada com o motivo. Comprimir pra um número é proibido.

pr-bump

O fast path pros bumps de dependência do Dependabot. A regra que mais economiza meu tempo: batch, nunca serialize. Em vez de mergear PR por PR, um bundle update consolidado até a última versão compatível, um único passe de CI pro conjunto, fix forward no que quebrar.

Mas tem um supply-chain floor:

• Toda dependência tem que resolver no registry público (rubygems, npm, pypi) com nome, versão e checksum esperados.
• Fonte git, path, nome typosquat-adjacente, hook novo de install: para tudo e vai pra auditoria completa.

bundler-audit passa numa gem trojanizada bem formada. É exatamente o caso que o floor cobre.

release

Corta versão só quando eu peço. As regras de ferro:

• Versão sai da classificação do changelog: fix vai em patch, aditivo em minor, breaking em major. Número que conflita com a classificação me obriga a confirmar, bump silencioso é proibido.
• Gate de CI verde no SHA exato da tag. Nunca tag em CI pendente ou pulado.
• Tag anotada, changelog atualizado.
• Nunca reescrever tag publicada. Nunca cortar release que ninguém pediu.

Os números, porque números não discutem

Contando agora, no dia em que escrevo este artigo, só em três projetos (ai-memory, ai-usagebar e ai-jail):

• ai-memory: 430 PRs mergeados, 260 issues fechadas
• ai-usagebar: 137 PRs mergeados, 34 issues fechadas
• ai-jail: 42 PRs mergeados, 81 issues fechadas

Somando: 609 PRs mergeados e 375 issues fechadas, mais de mil itens. Quase a totalidade disso foi tratada por essas skills, comigo supervisionando e decidindo. Uma pessoa sozinha, sem time, mantendo três projetos ativos nesse volume. É esse o multiplicador.

E elas não nasceram prontas

Abre o histórico de commits do my-skills e você vê skill sendo lapidada na marra. Em julho começa o repo com as auditorias básicas. No fim de julho: “harden audit skills and add security audit”. Em agosto: “consolidate agent skills from all harnesses into this repo” e, dias depois, nasce a github-resolution como fase de execução das auditorias. Em setembro: “fold in release-discipline and audit lessons”.

E ontem mesmo, olha o nível do ajuste fino no pr-bump: “batch all bump PRs into one consolidated verification pass, fix forward on failures” e “require deferred/declined PRs be left in a clean state”. Duas regras que viraram texto de skill. Nenhuma delas saiu de blog post ou de opinião de terceiro: saiu de eu tomar na cara o erro que a regra agora impede.

Cada linha dessas skills é cicatriz.

É assim que se escreve prompt bom: prestando atenção no resultado, decidindo ajustar, ajustando de novo.

Skills são pouco. Conhecimento é muito.

Agora o contraponto, porque eu não quero que você saia daqui achando que a resposta pra tudo é skill. Eu dependo pouco delas. O que carrega meu workflow mesmo é outra coisa.

Cada projeto meu tem seu próprio AGENTS.md, instruções específicas daquele código, e sua memória no ai-memory com decisões e gotchas. E o padrão que eu mais uso no dia a dia nem é skill: é apontar pro exemplo vivo. Quando eu quis AUR automatizado pro clock-tui, eu não escrevi skill de “como fazer pacote AUR”. Eu abri o harness e falei:

make a similar github action to build and publish AUR packages
as we did in ~/Projects/ai-memory

O agente foi lá, leu o workflow que funciona, e reproduz o padrão no novo projeto. Skill pra isso seria pior: AUR muda, GitHub Actions muda, o exemplo fica velho. Exemplo vivo em repo que eu mantenho está sempre atualizado por definição, porque quando ele quebra, eu conserto.

Cada projeto vira base de conhecimento de si mesmo.

E isso generaliza, porque harnesses conseguem consumir qualquer base de texto. Meu PC Linux inteiro está documentado e reinstalável a partir de um repo de config meu, e meu homeserver está todo descrito em runbooks. Esses dois não estão no GitHub: moram num servidor Gitea privado que eu mantenho, porque é o tipo de coisa que eu não quero vazada em público. Quando eu quero mexer em casa, eu falo assim:

add integration to my Plex server as documented in my homelab runbooks

Não é skill. É conhecimento organizado, versionado, consultável. Skills são pra procedimento que se repete igual. Conhecimento é pra tudo o mais.

A recomendação que vale mais que qualquer skill

Se você levar uma única prática deste artigo, que seja esta: faça seu agente escrever tudo o que não virou código. Pesquisa que ele fez, decisão que você tomou e por quê, comparação com alternativa rejeitada. Sem isso, esse conhecimento evapora no fim da sessão.

O meu ai-memory, por exemplo, tem uma pasta de docs com pesquisa de competidores que eu mandei fazer antes de cada decisão grande:

• O padrão do wiki do Karpathy, que é a origem intelectual do projeto.
• Survey do landscape 2026, cobrindo Zep/Graphiti, Letta, Mem0 e o Open Knowledge Format do Google.
• Deep-dives de cada concorrente: o Hindsight (o único com paper e funding, que acabou validando minhas apostas de design), o cognee (pipeline de grafo bonito, bug de gateway feio), o agentmemory (do qual eu guardei as ideias e joguei fora o substrato), o basic-memory.
• E a minha favorita, a autópsia do MemPalace: 47 mil stars, viral, e o tracker entupido de corrupção de índice e dado perdido. O conto de fadas ao contrário que me confirmou por que compilar memória é melhor que estocar verbatim.

Dezenas de documentos assim. Cada hora de pesquisa que um agente fez pra mim virou ativo permanente, reutilizável em qualquer projeto novo. Quanto mais você produz e documenta, mais inteligência você acumula.

É juro composto de conhecimento.

Ninguém sabe o que você precisa

E aí fecha o círculo, e voltamos ao ponto do começo: por que eu não recomendo copiar skill de ninguém, nem a minha.

Porque a minha skill de auditoria de PR é moldada em meus projetos, minhas linguagens, meus riscos, meu nível de paranóia com supply chain. Ela reflete o que eu, Fabio, mantendo os repositórios que eu mantenho, na infra que eu tenho, com os objetivos que eu tenho, precisei escrever nela. Seu projeto tem outra stack, outros riscos, outro grau de tolerância. Você pode precisar de checagens que eu não preciso, e o inverso. A experiência é relevante só pra quem viveu as restrições dela. Isso muda de pessoa pra pessoa, e é exatamente por isso que skill de terceiro usada às cegas é aposta.

É a tese do meu vídeo de 2019, Não Terceirize suas Decisões: a lição mais importante da sua vida: ninguém além de você sabe o que você precisa.

Eu não pergunto pra ninguém. Eu pesquiso, eu construo o meu, e as skills são o registro versionado das minhas decisões. A beleza dos LLMs é que eles aceleram esse processo em 10 vezes: a pesquisa que levava uma semana agora leva uma tarde, e o custo de construir sua própria ferramenta despencou.

Skill boa é a sua. A minha está no my-skills pra você ler o raciocínio. Depois fecha a aba e escreve a sua. Eu não desperdiço tempo pedindo a opinião dos outros. Você também não deveria.

E-mail sempre foi a parte mais chata desse exercício. Meu workflow antigo era abrir o Thunderbird, deixar ele puxar tudo de Gmail via IMAP, e fazer backup do diretório ~/.thunderbird. Funciona, mas é manual, chato (lembrar de abrir o Thunderbird de vez em quando), e preso ao próprio Thunderbird: se quero ler aqueles e-mails em outro cliente, eles estão num formato interno proprietário.

Depois de um tempo caiu a ficha: Linux tem suporte nativo a e-mail desde sempre. Os protocolos modernos (IMAP, SMTP) são padrão aberto. E o formato de armazenamento local, Maildir, existe e funciona muito bem desde os anos 90. Não precisa de Thunderbird pra nada.

O que é Maildir

Maildir foi criado pelo Daniel J. Bernstein (djb) como parte do qmail em 1995. A ideia era resolver os problemas de file locking do formato mbox, onde a caixa de e-mail inteira é um arquivo único e dois processos escrevendo ao mesmo tempo podiam corromper tudo. No Maildir, cada mensagem vira um arquivo separado numa estrutura de três subdiretórios:

• tmp/ — onde o e-mail é escrito enquanto chega
• new/ — mensagens novas, ainda não lidas
• cur/ — mensagens já vistas pelo cliente, com flags no nome do arquivo (:2,S = seen, :2,F = flagged, etc.)

A entrega é atômica: o MTA escreve a mensagem em tmp/, depois faz um rename() pra new/. rename() em filesystem POSIX é atômico, então não tem janela de corrupção. Sem locking, sem corrupção, e cada e-mail é só um arquivo de texto puro que você pode ler com cat, indexar com grep, versionar com git se quiser.

Trinta anos depois, ainda é o formato local padrão da maioria dos clientes de e-mail Linux. E é o formato que vou usar pra fazer o mirror do Gmail.

A ferramenta: mbsync (isync)

O que faz a ponte entre o IMAP do Gmail e o Maildir local é o mbsync, o binário do pacote isync. Ele lê uma config simples (~/.config/isyncrc), conecta no IMAP do Gmail, e copia as mensagens pro disco. A diferença pro offlineimap (alternativa mais conhecida) é que mbsync é escrito em C, é bem mais rápido em mailboxes grandes, e tem menos casos esquisitos com Gmail.

A config é direta. Resumo do que tem no meu ~/.config/isyncrc (sem senha, claro):

IMAPAccount minha-conta
Host imap.gmail.com
User you@example.com
PassCmd "/home/akitaonrails/.config/mbsync/bin/mbsync-password you@example.com"
TLSType IMAPS
CertificateFile /etc/ssl/certs/ca-certificates.crt
AuthMechs LOGIN

IMAPStore minha-remote
Account minha-conta

MaildirStore minha-local
SubFolders Verbatim
Path ~/.local/share/mail/mbsync/you.example.com/
Inbox ~/.local/share/mail/mbsync/you.example.com/INBOX

Channel minha-backup
Far :minha-remote:
Near :minha-local:
Patterns * !"[Gmail]/Trash" !"[Gmail]/Spam" !"[Gmail]/Drafts"
Create Near
Sync Pull New Flags
Expunge None
Remove None

Três pontos importantes nessa config:

1. Sync Pull: só puxa do servidor pro local. Nada que eu faça no Maildir vai propagar pro Gmail. Isso é proteção contra acidentes (se eu apagar um arquivo localmente, não some do Gmail).
2. Expunge None + Remove None: se uma mensagem some do Gmail (alguém apagou ou o Google decidiu mover pra lugar nenhum), ela continua no meu Maildir. O backup acumula histórico, não espelha o estado atual.
3. PassCmd em vez de senha em texto: a senha vai num script que faz secret-tool lookup no keyring do desktop. Nada de senha em arquivo de config no disco.

O bloco da senha

O mbsync-password é um wrapper minúsculo que isola o segredo:

#!/usr/bin/env bash
set -euo pipefail
account="${1:?usage: mbsync-password ACCOUNT}"
password="$(secret-tool lookup service mbsync account "$account" 2>/dev/null || true)"
[ -z "$password" ] && { echo "missing keyring secret for $account" >&2; exit 1; }
printf '%s' "$password"

Senha é armazenada uma vez com secret-tool store --label="mbsync gmail" service mbsync account you@example.com. O Gmail moderno exige uma app password específica (16 caracteres, gerada em myaccount.google.com/apppasswords) porque não aceita mais autenticação básica direta — você não cola sua senha do Google ali, cola uma chave gerada exclusivamente pro app, que dá pra revogar a qualquer momento sem mexer no resto da conta.

Automação com systemd user timer

Pra não ter que rodar o mbsync na mão, montei dois user units no systemd. Primeiro o serviço, que é só uma chamada do script wrapper:

# ~/.config/systemd/user/mbsync-backup.service
[Unit]
Description=Mirror Gmail accounts locally with mbsync
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=%h/.config/mbsync/bin/mbsync-run

E o timer que dispara o serviço periodicamente:

# ~/.config/systemd/user/mbsync-backup.timer
[Unit]
Description=Run mbsync periodically

[Timer]
OnBootSec=10m
OnUnitActiveSec=30m
Persistent=true
Unit=mbsync-backup.service

[Install]
WantedBy=timers.target

OnBootSec=10m espera 10 minutos depois do boot pra primeira execução (evita brigar com o network-online no início da sessão). OnUnitActiveSec=30m re-dispara 30 minutos depois de cada execução terminar. Persistent=true faz com que, se a máquina estava desligada na hora que seria pra disparar, ele compense rodando logo no próximo boot. O wrapper já pega flock pra não rodar dois mbsync em paralelo, então se uma sincronização demorar mais que 30min, a próxima só espera. Tudo loga em ~/.local/state/mbsync/mbsync.log.

Pra gerenciar o timer, os comandos básicos:

# Re-ler os arquivos depois de criar/editar
systemctl --user daemon-reload

# Ativar agora + habilitar pra subir no próximo boot
systemctl --user enable --now mbsync-backup.timer

# Conferir se o timer tá ativo e quando dispara da próxima vez
systemctl --user status mbsync-backup.timer
systemctl --user list-timers mbsync-backup.timer

# Disparar uma sincronização imediata sem esperar o intervalo
systemctl --user start mbsync-backup.service

# Acompanhar logs em tempo real
journalctl --user -u mbsync-backup.service -f

# Conferir status da última execução do serviço
systemctl --user status mbsync-backup.service

# Pra desligar tudo
systemctl --user disable --now mbsync-backup.timer

Pra que o timer continue rodando quando você não está logado (útil em desktop que fica ligado 24/7), habilite linger uma única vez: sudo loginctl enable-linger $USER. Sem isso, os user units só rodam enquanto você tem sessão ativa.

Ativa, confere o status uma vez pra ter certeza que tá verde, e esquece que existe.

Backup do Maildir com restic

Agora que o Gmail está espelhado em ~/.local/share/mail/, ele entra no mesmo pipeline de backup do resto do meu home. Eu uso o restic pra mandar snapshots criptografados pro NAS. O restic é incremental por content-addressable storage, então adicionar 100MB de e-mail no snapshot diário custa basicamente o delta — não os 100MB inteiros toda vez. Pra cópia off-site, meu NAS Synology já tem o pacote Glacier Backup nativo, que cuida de mandar snapshots criptografados pro AWS Glacier sem eu precisar configurar nada além do bucket e da chave. O Maildir entra junto no mesmo plano, então o backup off-site sai de graça em termos de configuração extra.

O Maildir é amigável a backup incremental por construção: cada e-mail é um arquivo imutável (nem o nome muda depois de baixado, exceto pela flag de seen/flagged). O restic deduplica perfeitamente. Snapshot de mailbox de 5GB tem custo marginal próximo de zero depois do primeiro.

A vantagem do formato aberto: muitos clientes

Aqui mora a parte que me convenceu de vez. Maildir é um padrão aberto, então qualquer cliente que entenda Maildir lê o mesmo backup. Eu posso:

• Abrir no mutt ou neomutt quando quero algo rápido no terminal.
• Abrir no aerc quando quero TUI mais moderna.
• Apontar o Thunderbird ou Claws Mail pra ~/.local/share/mail/... quando quero GUI.
• Migrar pra outro cliente no futuro sem ter que exportar/importar nada.

Os e-mails são meus. Vivem no meu disco. Em formato texto, legível por qualquer ferramenta.

Bônus: scripts e bots leem direto

A consequência menos óbvia disso é que, se eu quiser construir um filtro, um bot, um classificador, ou qualquer coisa que mexe nos e-mails, eu não preciso passar por OAuth do Gmail, criar projeto no Google Cloud, gerenciar refresh tokens, lidar com quota — nada. Eu leio direto do Maildir.

O Python tem suporte nativo a Maildir na biblioteca mailbox. Um exemplo bobo pra listar assuntos da inbox:

import mailbox
from email.header import decode_header

inbox = mailbox.Maildir("/home/akitaonrails/.local/share/mail/mbsync/you.example.com/INBOX")

for key, msg in inbox.iteritems():
    subject = msg.get("Subject", "")
    sender = msg.get("From", "")
    # decode_header lida com Subject em UTF-8 / latin-1 / etc
    decoded = "".join(
        part.decode(enc or "utf-8") if isinstance(part, bytes) else part
        for part, enc in decode_header(subject)
    )
    print(f"{sender[:40]:<40}  {decoded[:60]}")

Roda em milissegundos, não consome quota de API nenhuma, não tem rate limit, não precisa renovar credencial. É só leitura de arquivos. Se você quer fazer um pipeline mais sério (parser de anexos, classificação por LLM, regras automáticas), o mesmo princípio se aplica.

Resumo

A combinação que finalmente me deixou tranquilo:

• mbsync (isync) puxa do IMAP do Gmail pra Maildir local, automaticamente via systemd timer.
• Maildir preserva o formato aberto, cada e-mail é um arquivo, pull-only protege contra exclusão acidental.
• restic snapshota o Maildir pro NAS com deduplicação ridícula, e o Glacier Backup do Synology leva isso pra off-site cifrado.
• Cliente de e-mail livre — mutt, neomutt, aerc, Thunderbird, Claws, qualquer um lê.
• Automação leve — bot ou script lê direto do disco, sem OAuth, sem API.

O Gmail vira só uma interface web confortável pra ler e responder. A propriedade real dos e-mails está no meu disco, replicada no NAS, replicada em backup off-site cifrado. Se o Google fechar minha conta amanhã (já aconteceu com gente), perco a interface, mas mantenho a história inteira. Pra mim é o jeito definitivo de fazer isso. Recomendo.

Sei que tem várias ferramentas que resolvem isso. Mas eu queria algo bem simples e rápido pra rodar no terminal e ver pendências de todos os meus projetos de uma vez só. Então fiz: o ghpending.

Roda em Linux e macOS. Eu testei em Linux (Arch + Omarchy) mas ainda não rodei no macOS. Se você for testar lá e topar com algum bug, abre uma issue lá: github.com/akitaonrails/ghpending/issues.

Instalação

Três caminhos, escolhe o que mais combina com seu setup.

Via Homebrew (macOS ou Linux):

brew tap akitaonrails/tap && brew install ghpending

Via Cargo:

cargo install ghpending

Via mise:

mise use -g github:akitaonrails/ghpending

Atualizando

# Homebrew
brew upgrade ghpending

# Cargo
cargo install ghpending --force

# mise
mise upgrade ghpending

# From source
cd ghpending && git pull && cargo install --path .

Uso

Quatro comandos. O fluxo normal é rodar ghpending add uma vez pra configurar quais repos você quer monitorar, depois é só ghpending quando quiser ver o digest.

ghpending add    # pick os repos de um usuário ou org pra monitorar
ghpending        # imprime o digest de issues e PRs abertos
ghpending list   # mostra os repos monitorados
ghpending rm     # tira repos do monitoramento via menu interativo

O add pergunta o usuário ou organização, lista os repos públicos, e deixa você marcar os que quer acompanhar. O username fica salvo, então rodar add de novo já pula essa pergunta.

O comando principal (ghpending sem argumentos) busca todos os repos monitorados em paralelo e mostra a tabela com issues e PRs abertos.

Token do GitHub (opcional)

Sem autenticação funciona, mas o GitHub limita em 60 requisições por hora pra anônimo. Pra subir esse teto pra 5.000 req/h, exporta um token:

GITHUB_TOKEN=$(gh auth token) ghpending

Ele é lido silenciosamente na inicialização, não precisa configurar nada.

Onde fica o config

• Linux: ~/.config/ghpending/config.toml
• macOS: ~/Library/Application Support/ghpending/config.toml

Você pode editar direto se quiser reordenar ou trocar o user. Estrutura:

user = "akitaonrails"
repos = ["akitaonrails/ai-memory", "akitaonrails/ai-jail"]

Por que esse CLI existe

A real é simples: ferramenta que eu fizesse pra mim mesmo, eu uso. Ferramenta de outro autor, sempre tem fricção (login web, opinião arquitetural diferente, feature que faltou ou sobrou). Como o objetivo era reduzir o atrito de checar 30 repos por semana, melhor 200 linhas de Rust escritas num sábado à tarde do que aprender um stack novo.

Agora espero conseguir responder as pendências dos colaboradores mais rápido. Se você achar útil, é MIT, PRs são bem-vindos.

No meu canal eu inclusive usei jogos antigos pra ensinar fundamentos de computação. No Akitando sobre Super Mario e computadores antigos eu explico 6502, mapa de memória, PPU, limitações de hardware e por que aqueles jogos eram programados daquele jeito. Se você nunca viu, recomendo assistir:

O problema é o de sempre: a cada poucos anos eu resolvo montar uma máquina nova de emulação, baixo de novo os emuladores principais da vez, e lá vou eu repetir o mesmo ritual masoquista. PCSX2, RPCS3, Eden, Azahar, Dolphin, RetroArch, Flycast, shadPS4 e por aí vai. Cada um com suas manias. Cada um com sua forma particular de te fazer perder horas.

Em teoria, montar tudo isso deveria ser divertido. Na prática, leva dias. E não é exagero. Dolphin ainda consegue ser um dos piores porque controle de GameCube e Wii não tem nada de padrão. RPCS3 exige tuning por jogo. Eden precisa de DLC, update e cheats no lugar certo. shadPS4 é um festival de tentativa e erro. Quando eu finalmente terminava de configurar tudo, eu já não queria mais jogar porcaria nenhuma. Eu só queria fechar os menus e ir fazer outra coisa.

Eu já cheguei a dizer que talvez a graça estivesse justamente no tuning. Não acho mais isso. Depois de repetir esse processo vezes demais, eu cansei. Eu quero jogar os jogos, não preencher formulário escondido em GUI de emulador.

O problema não era Linux

Eu já resolvi esse tipo de coisa de várias formas no passado. Anos atrás eu rodava Linux no host e um Windows virtualizado com GPU passthrough pra jogar dentro da VM. Na época era o que fazia sentido. Eu fiz um vídeo inteiro sobre isso:

Mas isso foi antes do trabalho monumental da Valve, do Proton, do Wine moderno e de toda a comunidade open source que empurrou o desktop Linux pra um lugar muito melhor. Hoje dá pra evitar Windows na maior parte dos casos. No outro vídeo abaixo eu explico a evolução de CPU, GPU, OpenGL, Vulkan e por que chegamos nesse ponto:

Meu mini-PC dedicado a games com RTX 4090 continua sendo minha principal máquina de Steam, especialmente agora que montei um cockpit decente de sim racing. Nele eu uso EmuDeck, que nasceu justamente pra automatizar instalação e configuração de emuladores no Steam Deck, depois passou a suportar Windows também, e ajuda bastante a reduzir a complicação de montar esse tipo de ambiente. Mas meu desktop principal também é forte demais pra ficar subutilizado. Ele tem uma RTX 5090, e hoje eu uso essa GPU principalmente pra testar LLMs e benchmarking, como contei em Testando LLMs Open Source e Comerciais. Seria um desperdício não usar isso pra gaming também.

Só que no Linux eu queria outra coisa. Eu não queria uma caixa-preta fazendo tudo por mim sem eu saber exatamente o que estava sendo alterado, principalmente no meu PC principal, que é minha máquina de trabalho. Eu queria um setup meu, feito “na mão” no sentido certo da expressão: não clicar GUI por GUI, mas entender o que está sendo configurado, manter os arquivos sob meu controle, e conseguir reconstruir tudo do jeito que eu gosto. Eu sei que o pessoal do NixOS vai pular aqui pra dizer “é só usar Nix” — explico mais abaixo por que descartei essa rota. Também não queria transformar a minha máquina de trabalho num carnaval de pacote de emulador, tema GTK, wrapper, launcher, runtime esquisito e config enterrada em ~/.config. Nem queria dual boot ou VM. Em 2026, a melhor resposta pra isso, na minha opinião, é Distrobox.

Pelo que o próprio projeto explica, Distrobox é um wrapper em cima de podman, docker ou lilipod pra criar containers fortemente integrados ao host, com acesso a HOME, Wayland/X11, áudio, dispositivos USB, storage externo e GPU. Ou seja: exatamente o tipo de isolamento pragmático que eu queria. Não é uma fronteira de segurança, e o próprio site deixa isso claro. Não use pensando em sandbox de alta segurança. Use pensando em separar ambientes sem ficar pagando o preço de uma VM.

E antes que alguém repita a confusão de sempre: container não é máquina virtual. Eu explico isso com calma neste outro episódio:

O setup

A ideia é simples: um Arch Linux vanilla dentro de um Distrobox chamado gaming, com os caminhos do NAS montados em read-only, a biblioteca Steam acessível onde faz sentido, e todos os emuladores instalados lá dentro. Como o container tem acesso a GPU NVIDIA, áudio, USB e demais periféricos, eu separo trabalho de jogo na mesma máquina sem penalidade prática de performance.

O bootstrap inicial é mais ou menos isso:

distrobox create --name gaming --image archlinux:latest --nvidia \
  --home /mnt/data/distrobox/gaming \
  --volume /mnt/data/steam:/mnt/data/steam \
  --volume /mnt/terachad/Emulators:/mnt/terachad/Emulators:ro

Só esse começo já tem pegadinha. O archlinux:latest dentro de Distrobox vem sem [multilib] no pacman.conf, com um sudoers mal configurado, e com o velho problema do --nvidia: as libs do driver do host entram bind-mounted read-only, então qualquer instalação que dependa de nvidia-utils quebra com conflito de arquivo. Só isso já é o tipo de dor de cabeça que, alguns anos atrás, me faria abrir meia dúzia de abas, mais uma penca de terminais, e gastar uma noite inteira em tentativa e erro.

Desta vez eu fiz diferente.

Claude Code como assistente de infraestrutura

Eu venho ficando cada vez mais confortável em usar Claude Code como meu assistente de infraestrutura nas minhas máquinas pessoais. Eu não faria isso cegamente em servidor de cliente. Mas em máquina minha, em ambiente que eu posso destruir e reconstruir quantas vezes eu quiser, faz todo sentido. Escrevi sobre isso no artigo Migrando meu Home Server com Claude Code, quando usei Claude pra instalar e configurar openSUSE MicroOS, Docker, NFS, firewall, hardening e o resto todo sem eu precisar ficar lembrando comando chato de shell.

Então pensei: por que não fazer a mesma coisa aqui?

Foi exatamente o que eu fiz. Comecei com prompts bem objetivos, sempre pedindo duas coisas ao mesmo tempo: fazer o trabalho e documentar o suficiente pra eu poder reconstruir tudo depois. O histórico mais importante ficou em docs/distrobox-gaming-prompts.md.

Vale um esclarecimento: aqueles prompts no GitHub não são as minhas mensagens cruas, do jeito que saíram na hora. Depois que tudo funcionou, eu pedi pro próprio Claude reescrever os prompts de forma organizada e detalhada, só pra fins de documentação. Os prompts originais eram bem mais simples e bem menos específicos. Eu descrevia o objetivo e deixava o Claude descobrir sozinho paths, arquivos de configuração, formatos e comandos necessários.

O primeiro prompt criou a box com --nvidia, --home separado e os mounts corretos. O segundo resolveu os três problemas clássicos do Arch dentro de Distrobox: sudo, multilib e o dummy package de nvidia-utils. O terceiro instalou a base de gaming, inclusive um detalhe que eu teria esquecido fácil se estivesse fazendo na mão: pipewire-pulse, necessário pra vários emuladores não ficarem mudos nem perderem sincronia.

O ponto não é o texto em si. O ponto é o método. Eu não preciso lembrar a ordem exata, nem as opções precisas, nem onde está a documentação de cada detalhe. Eu descrevo o objetivo e deixo o agente carregar o piano. Fico no papel de tech lead: observando, revisando, corrigindo direção quando precisa, e mandando continuar.

O projeto no GitHub

O setup vive em akitaonrails/distrobox-gaming, estruturado como um projeto Ansible. 17 roles cobrem desde criação da box, bootstrap de pacotes, seed de configs, instalação de DLC, configuração de controle, até verificação pós-setup. Os playbooks principais são:

• site.yml: setup completo do zero
• reset-configs.yml: reset só das configs (útil quando você quer zerar tuning e redeployar)
• backup.yml / restore.yml: snapshot e restauração do container inteiro via podman commit
• refresh-shadps4.yml: atualização standalone do shadPS4
• install-xenia.yml: instalação opcional do Xenia Manager (Wine prefix)

O passo a passo completo está em docs/rebuild-runbook.md. As decisões de pacote (por que AUR em vez de Flatpak, por exemplo) estão em docs/distrobox-gaming-packages.md.

Por que não Nix?

Alguém vai perguntar. “Você tá recriando ambiente reproduzível. Por que não usar NixOS, ou pelo menos nix-shell/flakes?”

Eu considerei e descartei. O ecossistema de emuladores que eu preciso vive no AUR. Pacotes -bin do AUR são wrappers de AppImage que empacotam o binário oficial do upstream sem compilar nada. rpcs3-bin, pcsx2-latest-bin, eden-bin, duckstation-qt-bin, shadps4-bin — esses binários acompanham o upstream praticamente no dia do lançamento. No Nixpkgs, muitos desses emuladores ficam semanas ou meses atrás do release, e alguns nem existem. Criar um overlay Nix pra cada emulador que eu preciso, manter, e lidar com os patches de compatibilidade quando upstream muda, é trabalho que eu não quero ter.

Tem também o modelo mental. Eu não quero aprender a linguagem Nix, o sistema de derivações e o modelo de avaliação pra montar um ambiente de games pessoal. Ansible eu já conheço, as roles são pastas com tasks em YAML, e o debug é ansible-playbook -vvv. Quando dá errado, eu leio a mensagem de erro, abro o task que falhou, e sei exatamente onde mexer. Se eu precisasse do mesmo nível de reprodutibilidade em escala, num cluster, com rollback atômico, aí sim Nix teria argumento. Pra um distrobox com emuladores na minha máquina pessoal, Ansible resolve com muito menos atrito.

Flatpak também foi testado e descartado. O bwrap (bubblewrap) do Flatpak não aninha direito dentro das mount namespaces do Docker, então apps Flatpak simplesmente não rodam dentro de distrobox. A alternativa seria instalar Flatpak no host, mas aí você volta ao problema de poluir a máquina de trabalho com pacotes de gaming. Além disso, as versões Flatpak de emuladores ficam bem atrás do AUR — o pcsx2-latest-bin do AUR tracka o AppImage 2.7.x, enquanto o Flathub ainda distribui a v2.6.3.

Plataformas cobertas

O setup cobre 12 plataformas hoje:

RetroArch entra por cima pra cobrir o resto (NES, SNES, Genesis, N64, arcade, etc.), com 21 cores do buildbot e 8 asset packs (databases, shaders, cheats, overlays, autoconfig).

Frontend é ES-DE. As definições dos sistemas customizados ficam em ansible/group_vars/all/esde.yml e cada emulador entra com um wrapper que já sobe com as variáveis certas de GPU (voltarei nisso).

GPU hardforce pra NVIDIA

Num sistema híbrido com NVIDIA dGPU + AMD iGPU (meu caso no desktop), Vulkan às vezes escolhe o iGPU sozinho e o resultado é emulador rodando a 15 fps enquanto a 5090 fica parada. A solução é forçar o ICD Vulkan da NVIDIA em todos os launchers.

Cada entrada de desktop rendereizada pelo Ansible exporta VK_ICD_FILENAMES apontando pro ICD da NVIDIA, e o wrapper do ES-DE faz a mesma coisa antes de lançar qualquer core. Em combinação com a flag --nvidia na criação da box, que bind-monta os drivers do host em read-only, o resultado é previsível: Vulkan sempre na dGPU NVIDIA, independente do estado do sistema na hora.

Isso vale principalmente pra quem tem setup híbrido. Num desktop com só uma GPU, o ICD filtering é placebo, mas também não atrapalha.

PS2: PCSX2 com tuning por jogo

A linha Gran Turismo é meu vício declarado. Cada versão precisa de tweak específico. O setup do PCSX2 hoje tem configs globais razoáveis (Vulkan, 4x SSAA, widescreen 16:9, Xbox-style bindings, FXAA + PCRTC antiblur, 16x anisotropic, deinterlace Automatic) e per-game INIs pros títulos que eu realmente jogo:

• Gran Turismo 3 A-spec (SCUS-97102 + bundle PBPX-95503): widescreen pnach, pack de retextura opcional (desabilitado por default porque NFS causa flicker em cutscenes de showcase de carro)
• Gran Turismo 4 USA (SCUS-97328): HD HUD do Silentwarior112, pack completo de retextura, patches do Silent pra gatilho e câmera, widescreen pnach
• Gran Turismo 4 Spec II (SCUS-97436, CRC 4CE521F2): caso especial — os HD packs de GT4 vanilla são linkados via symlink porque o Spec II tem mesma estrutura mas CRC diferente. Widescreen pnach renomeado pra bater com o CRC. Deinterlace mode 8 (Adaptive TFF), ShadeBoost tuning (+10 saturação, +3 brilho, +2 contraste) pra corrigir ghosting de pause-interlace e saturação anêmica do upscale
• Enthusia Professional Racing (SLUS-20967): HD textures + widescreen
• Ridge Racer V (SLUS-20002): widescreen + no-interlace pnach

Os pnach files do Silent e da comunidade são baixados automaticamente pelo role pcsx2_textures, que também faz o deploy do pack de cheats do NAS e instala os HD packs do Spec II via symlink. Widescreen é ligado via gamesettings por CRC (PCSX2 identifica jogo por CRC antes de aplicar o pnach).

Sobre versão do PCSX2: o pcsx2-latest-bin do AUR tracka a linha 2.7.x, que é onde todas as features modernas estão (texture replacement, FXAA, PCRTC antiblur). O pcsx2 padrão dos repos oficiais do Arch ainda está na 2.6.3. A diferença é mais de 250 commits de correção e feature novo.

PS3: RPCS3 com per-game configs curados

RPCS3 tem um detalhe chato: configs por jogo ficam em ~/.config/rpcs3/custom_configs/config_<SERIAL>.yml. O formato do arquivo tem versão, e se você gerar um YAML manualmente com versão errada, o RPCS3 rejeita silenciosamente e volta pro default. Isso custou tempo pra descobrir.

A role rpcs3_per_game_configs resolve isso assim:

1. Query o compatibility DB da comunidade RPCS3 pra pegar os presets recomendados por título
2. Aplica overrides curados por cima pra títulos que eu sei que precisam de ajuste específico (tipicamente GT5 e GT6)
3. Salva o YAML com a filename convention exata (config_<SERIAL>.yml, prefixo config_ obrigatório)

Na linha Gran Turismo:

• GT5 (BCUS98114, BCES00569): Resolution Scale 300%, Shader Precision Ultra, Force High Precision Z, SPU XFloat Accurate, Multithreaded RSX. Combinação que mata o dithering típico do RSX sem quebrar a GT series safety config (WCB/RCB off).
• GT6 (BCES01893 + variantes regionais): caso especial, versão travada em v1.05. Patches 1.06+ regridem com superfícies pretas em carros no menu garagem. O script extract_ps3_dlc.py tem per-title PATCH ceiling justamente pra pinar o GT6 no 1.05 mesmo quando o PSN cuspe patches mais novos. Além disso, Force CPU Blit ligado é mandatório (sem ele, flicker de tela inteira). O trade-off é que o retrovisor fica permanentemente preto — ligar WCB restauraria o retrovisor mas downgradaria pra 720p nativo. Prefiro perder o retrovisor.

Mais detalhes desses dois em docs/gt5-rpcs3.md e docs/gt6-rpcs3.md.

Update checker de PS3

Pra não ter que abrir a GUI do RPCS3 e ficar clicando em Download Game Updates jogo por jogo, criei um script em Python: check_ps3_updates.py. Ele percorre os jogos instalados em dev_hdd0/game, parseia o PARAM.SFO pra pegar a versão atual de cada título, consulta o servidor de updates da PSN (a0.ww.np.dl.playstation.net) e compara com o cache local de patches. --list mostra o diff; --download baixa o que falta. --max-version respeita os teto por título (ex: 1.05 pro GT6).

O primeiro scan na minha biblioteca achou 51 de 72 jogos com update disponível, 69 patches faltando localmente, uns 24 GB no total. Só o GT6 sozinho tinha 16 patches faltando, da 1.07 até 1.22, que eu descartei pelos motivos acima.

Os patches chegam como pacotes PSN tipo 0x0001 sem criptografia, então o próprio extract_ps3_dlc.py consegue instalar depois. A chamada padrão:

distrobox enter gaming -- python3 scripts/extract_ps3_dlc.py \
  "/mnt/terachad/Emulators/EmuDeck/roms_heavy/ps3-DLC" \
  --dest "/mnt/data/distrobox/gaming/.config/rpcs3/dev_hdd0/game"

Acompanhar versão de DLC de PS3 manualmente, jogo por jogo no RPCS3, é inviável. Vira lista de tarefas eterna e você só descobre que tinha patch 1.22 quando o jogo crasha.

PS1: DuckStation com per-game

A trilogia Gran Turismo começa no PS1, e a qualidade ali só sobe se você ligar as coisas certas:

• Gran Turismo (SCUS-94949): built-in WidescreenHack do DuckStation (não existe cheat pra esse jogo), PGXP ligado
• Gran Turismo 2 Simulation (SCUS-94455): widescreen cheat + 8 MB RAM cheat (fix de áudio em track crowded), filter JINC2
• Gran Turismo 2 Arcade (SCUS-94488): mesmo tratamento do Simulation

Global defaults: Vulkan, 8x upscale, JINC2 como filter default.

Os cheats pro GT2 saem de um repositório de widescreen fixes e são ligados automaticamente na pasta de cheats do DuckStation.

Switch: Eden com DLC, update e cheats

No Switch, eden-bin é o emulador. A integração automatiza três coisas que antes eu fazia na mão:

1. Install de DLC e update: o role install_dlcs aponta pro diretório de dumps no NAS, identifica os arquivos .nsp/.nsz/.xci/.xcz, e instala tudo em ~/.local/share/eden/nand/user/Contents/registered/. Se o dump está bagunçado (patches e DLC misturados em flat folder), o script reorganize_switch_nsps.py sorteia tudo por Title ID antes.

2. Cheats Atmosphere: os cheats em formato Atmosphere vão symlinkados pro load path do Eden (~/.local/share/eden/load/<TITLE_ID>/cheats/). O role switch_cheats faz isso por todos os títulos cobertos pelo pack do NAS.

3. Update checker: check_switch_updates.py lista títulos com update disponível vs o que tá instalado localmente. Útil pra não perder patch importante de jogo que sai atualização ainda.

Atenção ao detalhe que me queimou: QT_STYLE_OVERRIDE precisa ser desarmado antes de lançar o eden-bin, senão ele conflita com Kvantum e quebra a UI. O wrapper já faz o unset antes do exec.

Xbox 360: Xenia Manager via Wine

Xbox 360 ainda é território áspero no Linux. Não tem emulador nativo decente. A melhor rota hoje é Xenia rodando via Wine, gerenciado pelo Xenia Manager.

Isso é opt-in no meu setup. O playbook install-xenia.yml cria um Wine prefix dedicado, baixa o Xenia Manager, e registra os launchers. Não faz parte do site.yml principal porque nem todo mundo quer Wine no meio do caminho.

Project Forza Plus (Forza Motorsport 2/3/4)

Forza antigo ainda é o rei do simcade de geração passada. Rodar FM2/3/4 no Xenia requer mods da comunidade Project Forza Plus: patches de compatibilidade, mods de performance, instalação de title updates específicos. Documentei o processo em docs/project-forza.md.

Project Gotham Racing 3 e 4

PGR3 roda razoavelmente bem no Xenia Canary. PGR4 precisa de ajuste específico: render_target_path_vulkan = "fsi" no config, senão algumas races quebram com artefato visual. Documentei o setup em docs/xbox360-pgr.md. Áudio do PGR4 no NVIDIA ainda tem problema de XMA decoding que gera garbage intermitente. Tem issue aberta no xenia-canary, sem resolução up até agora.

Title Updates em batch

Title Update pra jogo de Xbox 360 era distribuído pela Xbox Live, que já foi desligada. A alternativa é o archive.org, que tem o catálogo completo preservado. Escrevi scripts/download-xbox360-tus.py pra automatizar:

distrobox enter gaming -- python3 scripts/download-xbox360-tus.py \
  --src /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360 \
  --dest /mnt/terachad/Emulators/EmuDeck/roms_heavy/xbox360-updates \
  --dry-run

O script precisa do CLI internetarchive autenticado (ia configure uma vez, guarda o token). Ele scaneia a pasta de jogos, faz match contra o manifest do archive.org (cacheado localmente), prioriza por região (USA > World > Europe > Japan), e baixa via ia download --checksum com retry automático. Os .zip resultantes vão pro Xenia Manager via Manage → Install Content, que extrai pro diretório correto (000B0000/).

O setup completo tá em docs/xbox360-title-updates.md.

Steam no distrobox

Desde que o Proton virou cidadão de primeira no Linux, faz sentido ter Steam também no gaming box. Adicionei o pacote steam no Ansible (que puxa multilib e dependências 32-bit), montei /mnt/data/steam em read-write pra a biblioteca persistir fora do container, e criei launcher no host.

Na prática, isso me permite rodar jogos Steam via Proton lado a lado com emulação, sem precisar alternar ambiente. O mini-PC com RTX 4090 continua sendo a máquina principal de Steam no cockpit de sim racing. O desktop é fallback e ambiente de teste.

Shell e controle por controle

Shell mínimo dentro da box

Quando eu entro no gaming box via distrobox enter gaming, eu quero prompt decente mesmo pra troubleshooting rápido. Instalei zsh + starship com config mínima, zero plugins exóticos. Não é meu setup de dev full, é só “prompt que mostra path e git branch sem me dar vergonha”.

Dolphin e o inferno do controle moderno

Dolphin sempre foi o rei do atrito manual. Se você usa um controle mais moderno, como meu 8BitDo Ultimate 2, precisa lembrar como eu gosto do mapeamento de GameCube, como adapto o Wii Remote, quando usar perfil de Nunchuk, quando trocar pro Classic Controller. Eu não tenho a menor paciência pra reconstruir isso na mão toda vez. Os perfis ficam prontos em config/emulator-overrides/dolphin/Profiles/ e são copiados pelo role seed_configs. Detalhes em docs/controller-hotkeys.md.

Alguns tropeços que sobraram

Nem tudo virou magia. Emulação sempre tem casca de banana.

Flycast, por exemplo, tem uma armadilha irritante. O arquivo emu.cfg usa chaves rend.* dentro da seção [config]. Se você cria uma seção [rend] separada, parece certo, mas o emulador simplesmente ignora e depois reescreve tudo com default medíocre. A correção virou wrapper dedicado em $DG_BOX_HOME/bin/flycast-hires:

$DG_BOX_HOME/bin/flycast-hires \
  -config config:pvr.rend=4 \
  -config config:rend.Resolution=2880 \
  -config config:rend.EmulateFramebuffer=no \
  -config config:rend.WideScreen=yes

Detalhes em docs/flycast-resolution.md.

shadPS4 ainda está longe de ser um caso encerrado. O setup atual é focado em Driveclub, com config espelhada, patch XML e links dos sys_modules do firmware 11.00. E isso não foi por acaso: eu gosto muito de Driveclub. Aliás, é praticamente o único jogo ainda preso no PS4 que eu realmente queria conseguir rodar direito. Eu já vi vários vídeos no YouTube mostrando o jogo funcionando, mas até agora eu mesmo não consegui fazer isso rodar de forma satisfatória no Linux. Documentado em docs/driveclub-shadps4.md. A parte boa é que agora eu não dependo mais de memória muscular pra lembrar como lançar, com qual patch, em que pasta, com quais módulos. A parte ruim é que emulação de PS4 ainda é emulação de PS4. Não existe script que faça upstream amadurecer mais rápido. Se alguém souber como fechar essa configuração no Linux, olhe o projeto no GitHub e mande um PR.

Ridge Racer V tem um flickering de textura de carro documentado nas issues do PCSX2 (#3639, #13729). O renderer Hardware é aceitável pra jogo de corrida onde você não fica admirando parado o modelo. Software renderer resolve mas mata performance. Escolhi aceitar o flicker.

O ganho real não é só automação

Seria fácil resumir isso como “olha que legal, usei IA pra automatizar shell script”. Não é isso.

O ganho real é mais chato e mais importante: eu parei de gastar energia mental com trabalho braçal. Não precisei mais lembrar comando raro. Não precisei manter dezenas de abas com wiki, issue, fórum e README. Não precisei deixar meia dúzia de terminais espalhados dando tail em log enquanto tento lembrar que opção escondida de GUI o emulador insiste em regravar no primeiro boot. Eu passei a trabalhar em conversa.

Eu digo pro agente o objetivo. Ele procura os arquivos, lê os logs, encontra o formato certo do config, compara defaults, propõe correções, escreve script, valida paths, verifica UID/GID, confere symlink quebrado, gera wrapper, exporta launcher. Eu continuo responsável pelas decisões, claro. Mas parei de ser digitador de comando raro.

Esse é o ponto que mais me interessa no uso de coding agents em Linux. Eles reduzem dramaticamente a fricção de entrada. Muita gente desiste do desktop Linux não porque o sistema seja incapaz, mas porque a curva de tuning historicamente foi irritante demais. Ter um assistente capaz de ler docs, cruzar config, propor automação e executar com supervisão muda esse jogo.

Se você quiser reproduzir

O repo foi publicado pra isso:

git clone https://github.com/akitaonrails/distrobox-gaming.git
cd distrobox-gaming/ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml  # ajuste paths da sua máquina
ansible-playbook site.yml

Xenia é opt-in:

ansible-playbook install-xenia.yml

Leia o README.md e o docs/rebuild-runbook.md antes. Eu não distribuo ROM, BIOS, firmware nem chaves. O repo só detecta, linka e configura o que você já tem na sua própria máquina.

Se você preferir a rota com Claude Code

Minha recomendação é simples:

1. Comece pelo objetivo, não pelo comando. “Quero um distrobox Arch com GPU NVIDIA, home separado, ROMs read-only e Steam rw” é melhor do que despejar meia linha de shell sem contexto.
2. Peça sempre pra documentar o que está fazendo. Se der certo, promova o resultado a script ou role. Se não documentar, você acabou de fabricar uma gambiarra descartável.
3. Trabalhe em fases. Criação da box. Bootstrap. Config de emuladores. Export de launchers. Verificação. Foi exatamente assim que eu quebrei o problema.
4. Peça verificações objetivas. command -v, existência de arquivos, symlinks quebrados, UID/GID, path de ROM, áudio, GPU. A melhor automação é a que falha cedo.
5. Não use agente como papagaio de comando. Use como assistente técnico. Você continua revisando as decisões e mandando ajustar o rumo.

Pra mim, esse foi o ganho. Eu saí do zero pra uma máquina de emulação muito mais completa sem precisar customizar tudo na unha, em GUI, uma janela por vez. E, dessa vez, terminei com energia pra fazer o que eu queria desde o começo.

Jogar.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

–

Todo projeto Rails começa igual: você cria um admin panel. Active Admin, Administrate ou um CRUD caseiro. Tabelas, formulários, botões. E a cada semana, você usa 5% das telas que construiu.

Agora imagine que seu admin panel é uma conversa. Você cola um link; o sistema processa. Digita /week e vê o resumo. /approve e a newsletter está agendada. /ask akita como funciona o pipeline de podcast? e uma IA te explica a arquitetura do seu próprio sistema.

Esse é o Discord como interface operacional. Não é gambiarra — é a melhor interface CRUD que existe pra um time de uma pessoa.

Por Que Discord e Não Um Web Admin?

Vamos ser honestos sobre o que um admin panel exige:

1. Autenticação: login, sessão, CSRF, password reset
2. Autorização: roles, permissions, who can do what
3. UI: tabelas, paginação, formulários, validação client-side
4. Deployment: outra rota, outro controller, outro set de testes
5. Mobile: responsive? App? PWA?

E o que o Discord já te dá de graça:

1. Auth: Discord cuida. Você verifica o author_id
2. Autorização: uma lista de admin IDs e pronto
3. UI: embeds com cores, campos, thumbnails, reações como status
4. Deployment: zero. Usa o que já está deployado
5. Mobile: app nativo no iOS e Android, push notifications

O trade-off? Não serve pra tudo. Um CRUD complexo com formulários de 20 campos? Melhor um web admin. Mas pra operações de comando/resposta — que são 90% do que você faz no dia a dia — Discord é imbatível.

discordrb: A Gem Que Funciona

A gem discordrb (fork do shardlab, versão 3.7.2) é a mais madura pra Ruby. Não é perfeita — tem idiossincrasias. Mas funciona de verdade em produção.

O setup mínimo:

bot = Discordrb::Bot.new(
  token: token,
  intents: Discordrb::INTENTS[:server_messages] |
           Discordrb::INTENTS[:direct_messages] |
           (1 << 15)  # message_content intent
)

bot.message do |event|
  # Toda mensagem passa por aqui
end

bot.run

Aquele (1 << 15) é o Message Content Intent. Sem ele, seu bot recebe eventos mas o event.content vem vazio. Precisa habilitar no Discord Developer Portal > Bot > Privileged Gateway Intents. É a primeira armadilha que pega todo mundo.

Não vou detalhar como configurar um bot no Discord, tem vários tutoriais pra isso já, você acha fácil online. Vou focar só no meu caso de uso como exemplo.

Padrão 1: Parser + Dispatcher

Misturar parsing de comandos com lógica de negócio é receita pra espaguete. Separa em três camadas:

Discord Event → Parser → Dispatcher → Job/Service

O runner (que conversa com a API do Discord) é burro de propósito:

bot.message do |event|
  next if event.author.bot_account?

  parsed = SlashCommandParser.parse(event.content, attachments: urls)

  case parsed
  when SlashCommandParser::Command
    CommandDispatcher.dispatch(parsed, channel_id: channel_id)
    event.message.react("\u{2705}")  # checkmark
  when SlashCommandParser::Submission
    ProcessMessageJob.perform_later(url: parsed.url, tags: parsed.tags)
    event.message.react("\u{1F916}")  # robot
  end
rescue StandardError => e
  event.message.react("\u{274C}")  # red X
end

Três resultados visuais instantâneos: checkmark (comando aceito), robô (URL sendo processada), X vermelho (erro). O usuário sabe o que aconteceu sem esperar nenhuma resposta textual.

O parser retorna objetos tipados, não strings. O dispatcher faz um case gigante mas cada handler é um método isolado. Cada handler chama um job ou service. Nada de lógica de negócio no runner.

Evolução: Discord Application Commands

A versão inicial parseava texto puro — o usuário digitava /week e o parser interpretava. Funciona, mas tem limitações: sem autocomplete, sem validação de argumentos, sem documentação inline.

O Discord tem um sistema nativo de Application Commands — slash commands registrados na API que aparecem com autocomplete, descrição, e tipagem de parâmetros. Quando o usuário digita /, o Discord mostra todos os comandos disponíveis com descrição.

bot.register_application_command(:week, "List this week's stories", server_id: guild_id)
bot.register_application_command(:approve, "Approve newsletter for sending", server_id: guild_id)
bot.register_application_command(:ask, "Ask AI a question", server_id: guild_id) do |cmd|
  cmd.string("question", "Your question", required: true)
  cmd.string("personality", "AI personality", choices: { "Akita" => "akita", "Marvin" => "marvin" })
end

O handler usa bot.application_command ao invés de parsear texto:

bot.application_command(:week) do |event|
  CommandDispatcher.dispatch_week(channel_id: event.channel.id)
  event.respond(content: "Listing stories...")
end

Os dois sistemas coexistem: Application Commands pra quem prefere autocomplete, texto puro pra quem prefere digitar rápido. O dispatcher é o mesmo — a diferença é só como o comando chega.

Padrão 2: Reações Como Status

A feature mais subestimada do Discord pra bots é reações. Elas são feedback visual instantâneo que não polui o canal com mensagens:

• Checkmark = comando recebido e enfileirado
• Robô = processamento assíncrono iniciado
• X vermelho = erro (detalhes no embed que segue)

O usuário cola um link. Vê o robô aparecer. 30 segundos depois, um embed rico aparece com título, resumo, imagem e comentário da IA. Se algo falhar, aparece um embed vermelho com a mensagem de erro.

Isso é melhor que qualquer spinner de loading numa web UI.

Padrão 3: Embeds Ricos Como Dashboard

Discord embeds são surpreendentemente poderosos:

embed = {
  title: "Story Preview",
  url: source_url,
  color: 0xFF4500,           # vermelho-alaranjado pra high priority
  description: summary,
  thumbnail: { url: image },  # imagem do artigo
  fields: [
    { name: "M.Akita diz", value: akita_comment, inline: false },
    { name: "M.Arvin diz", value: marvin_comment, inline: false },
    { name: "File", value: "`stories/2026-02-16-titulo.md`", inline: false }
  ],
  footer: { text: "fire high | tech_news | verified" }
}

Discordrb::API::Channel.create_message(token, channel_id, "", false, [embed])

Cores indicam prioridade (vermelho = high, âmbar = medium, verde = low). O footer mostra score, seção e status de fact-check tudo numa linha. Você bate o olho e sabe o estado da coisa.

Para relatórios, múltiplos embeds lado a lado (Discord aceita até 10 por mensagem) funcionam como um mini-dashboard. O comando /week lista todas as histórias com ações inline — /load @a3f2b1 pra ver detalhes, /delete @a3f2b1 pra remover. O hash é estável (baseado no path do arquivo), então não muda quando você deleta outra história.

Padrão 4: Context Per Channel

Quando o usuário digita /load #3, o #3 se refere à listagem mais recente. Mas e se dois canais estão sendo usados simultaneamente?

class ChannelContext < ApplicationRecord
  EXPIRY_DURATION = 2.hours

  def self.for_channel(channel_id)
    find_or_create_by!(channel_id: channel_id.to_s)
  end

  def set_week_stories!(hash)
    update!(week_stories_json: hash.to_json, expires_at: EXPIRY_DURATION.from_now)
  end

  def resolve_story_reference(ref)
    if ref.match?(/\A@[a-f0-9]+\z/i)
      # Hash reference (stable across re-listings)
      hash = ref.delete("@").downcase
      week_stories.values.find { |path| md5_prefix(path) == hash }
    elsif ref.match?(/\A#?\d+\z/)
      week_stories[ref.delete("#")]
    end
  end
end

Cada canal tem seu próprio contexto com expiração de 2 horas. O /week armazena o mapeamento número→arquivo. Depois, /load #3 consulta esse contexto. Se expirou, o bot diz “run /week first”.

E o detalhe mais útil: referências por hash (@a3f2b1) ao invés de número. Quando você deleta a história #2, a #3 vira #2 — mas o hash @a3f2b1 continua apontando pro mesmo arquivo. Isso evita o clássico “deletei a errada porque a lista mudou”.

Padrão 5: Admin Check Simples

Nada de RBAC complexo. Uma lista de IDs:

ADMIN_COMMANDS = %i[delete update_score approve newsletter publish_blog].freeze

def self.dispatch(command, channel_id:, author_id:)
  if ADMIN_COMMANDS.include?(command.type) && !admin?(author_id)
    send_error(channel_id, "Permission denied. Admin privileges required.")
    return
  end
  # ...
end

def self.admin?(author_id)
  admin_ids = ENV["DISCORD_ADMIN_USER_IDS"].to_s.split(",")
  return true if admin_ids.empty?  # dev: sem IDs = tudo permitido
  admin_ids.include?(author_id)
end

Em dev, sem DISCORD_ADMIN_USER_IDS configurado, tudo é permitido. Em produção, é uma lista de Discord user IDs. Sem banco, sem roles table, sem middleware. Dez linhas resolvem autorização.

Padrão 6: Operações Assíncronas com Feedback

Operações lentas (gerar imagem, processar artigo, chamar IA) vão pra background jobs. O feedback visual é em três tempos:

def self.handle_ask(personality, question, attachments, channel_id)
  # 1. Feedback imediato: "estou pensando"
  thinking_id = DiscordNotifier.send_message(channel_id, content: "Thinking...")

  # 2. Job faz o trabalho pesado em background
  AskJob.perform_later(
    question,
    channel_id: channel_id,
    thinking_message_id: thinking_id
  )
end

# No AskJob:
def perform(question, channel_id:, thinking_message_id: nil)
  result = AiChat.ask_multimodal(question, tools: [GenerateImageTool])

  # 3. Remove "Thinking..." e mostra resultado
  DiscordNotifier.delete_message(channel_id, thinking_message_id)
  DiscordNotifier.send_message(channel_id, content: "**Marvin:** #{result[:text]}")
end

O “Thinking…” aparece instantaneamente, o job roda em background, e quando termina, a mensagem temporária some e o resultado real aparece. Se o job falhar, o “Thinking…” some e um embed de erro aparece.

Sem isso, o usuário manda uma pergunta e fica olhando pra tela sem saber se o bot ouviu. UX terrível.

Padrão 7: RubyLLM + Tool Calling No Discord

A parte mais poderosa: dar ferramentas pro LLM. O /ask tem três tools disponíveis: GenerateImageTool (gera imagens via Gemini), WebSearchTool (busca na web via Brave Search), e WebFetchTool (busca e resume páginas web). O LLM decide sozinho qual usar baseado na pergunta. Quando o usuário pede “gera uma imagem de um gato programando”, o LLM escolhe o tool certo:

class GenerateImageTool < RubyLLM::Tool
  description "Generate an image using Gemini. Use when the user asks to create or draw."
  param :prompt, desc: "Image description"
  param :aspect_ratio, desc: "1:1 or 16:9", required: false

  def execute(prompt:, aspect_ratio: "1:1")
    image_data = ImageGenerator.generate(prompt: prompt)
    return "Failed to generate image" unless image_data

    path = save_temp_file(image_data)
    Thread.current[:generated_images] << path

    "Image generated successfully. Tell the user it's ready."
  end
end

O Thread.current[:generated_images] é o truque pra passar dados de volta do tool pro job. O LLM chama o tool durante chat.ask, o tool salva o arquivo e registra o path. Depois que chat.ask retorna, o job pega os paths e manda pro Discord como file uploads.

Por que thread-local e não retorno direto? Porque o LLM pode chamar múltiplos tools numa única resposta, e o retorno do tool volta pro LLM (não pro seu código) — é ele que decide o que responder ao usuário. O thread-local é o side channel pra seu código saber o que aconteceu.

Padrão 8: Notificações de Status Em Produção

Todo job de geração de conteúdo notifica um canal dedicado:

module DiscordStatus
  def notify_start(label)
    DiscordNotifier.send_to_status_channel("Starting #{label}...")
  end

  def notify_done(label)
    DiscordNotifier.send_to_status_channel("#{label} complete.")
  end

  def notify_error(label, error)
    DiscordNotifier.send_to_status_channel("#{label} FAILED: #{error}")
  end
end

O canal de status é separado do canal de operação. Quando os 8 jobs de geração de conteúdo rodam no domingo às 17h, o canal de status vira um log em tempo real:

Starting Anime Ranking...
Starting Hacker News...
Starting YouTube Digest...
Anime Ranking complete.
YouTube Digest complete.
Hacker News complete.
Starting Market Recap...  (wave 2, after world events)
...

De manhã, se algo deu errado, você abre o Discord no celular e sabe exatamente o quê — sem SSH no servidor, sem grep em logs.

E quando o bot reinicia após um deploy:

bot.ready do |_event|
  status_channel = ENV["DISCORD_STATUS_CHANNEL_ID"]
  DiscordNotifier.send_message(status_channel, content: "Bot reconnected and ready.")
end

Simples, mas você sabe que o deploy funcionou sem checar nada.

Padrão 9: Cross-App Communication

O sistema tem dois apps Rails que precisam se falar. A newsletter precisa notificar o Discord quando termina de montar uma edição. Mas a newsletter não tem conexão Discord — quem tem é o marvin-bot.

Solução: HTTP relay.

# Na newsletter — manda pro marvin-bot
class DiscordRelayClient
  def self.send_embed(title:, description:, color:)
    post("/api/discord_notify",
      type: "embed",
      payload: { title: title, description: description, color: color }
    )
  end
end

# No marvin-bot — recebe e repassa pro Discord
class Api::DiscordNotifyController < ApplicationController
  def create
    case params[:type]
    when "embed"
      DiscordNotifier.send_embed(status_channel, params[:payload])
    when "message"
      DiscordNotifier.send_message(status_channel, content: params[:payload][:content])
    end
  end
end

A newsletter fala HTTP. O marvin-bot traduz pra Discord. Um ADMIN_TOKEN compartilhado autentica. Todos os métodos resgatam erros e retornam nil — se o Discord estiver fora, a newsletter não trava. Fire and forget.

Mas tem um segundo fluxo cross-app mais interessante: o trigger de podcast. Quando a newsletter é aprovada, ela precisa avisar o marvin-bot pra gerar o podcast:

# Na newsletter — dispara geração de podcast no marvin-bot
class MarvinBotClient
  def self.trigger_podcast(date:)
    post("/api/trigger/podcast", date: date.to_s)
  end
end

Isso inicia um pipeline inteiro no marvin-bot: script LLM de duas passadas → TTS por turno na GPU → assembly com loudnorm → upload S3. E o PublishAndSendJob da newsletter fica esperando (via retry_on PodcastNotReady) até o podcast ficar pronto. Dois apps, duas linguagens de backend (Ruby e Python), conectados por HTTP fire-and-forget com polling de resultado. Não é elegante — mas funciona toda semana sem intervenção.

Padrão 10: Cost Tracking Integrado

Cada chamada de IA é rastreada com tokens e custo estimado:

def self.create_chat(caller:, model:, provider:)
  chat = RubyLLM.chat(model: model, provider: provider)
  chat.on_end_message do |message|
    ApiUsage.create!(
      caller_name: caller,
      input_tokens: message.input_tokens,
      output_tokens: message.output_tokens,
      cost_usd: estimate_cost(model, message)
    )
  end
  chat
end

E no Discord: /cost mostra o gasto por mês, ano, e por provider. Sem dashboard separado, sem Grafana, sem nada. Um comando e a informação que importa.

Padrão 11: Nunca Falhe Silenciosamente

Esse é o padrão que eu devia ter implementado desde o começo, mas só aprendi da pior maneira — em produção.

O projeto tem ~10 daily jobs que buscam dados de fontes externas (Hacker News, GitHub Trending, Morningstar, etc.) e postam embeds no Discord. Cada client segue um padrão “defensivo”:

# O padrão que PARECE correto:
class DailyDevClient
  def self.fetch_popular(limit: 10)
    response = HTTParty.get(API_URL, headers: { "Authorization" => "Bearer #{token}" })
    return [] unless response.success?
    parse(response.body)
  rescue StandardError => e
    Rails.logger.warn("DailyDevClient failed: #{e.message}")
    []
  end
end

# E no job:
class DailyDailyDevJob < ApplicationJob
  def perform
    posts = DailyDevClient.fetch_popular(limit: 10)
    return if posts.empty?  # ← O PROBLEMA
    # ... posta embed no Discord
  end
end

Esse código nunca crasheia. Nunca levanta exceção. Nunca enche o log de erros. É o código mais “robusto” possível.

É também completamente inútil pra diagnóstico. Quando deployei e rodei os daily jobs manualmente, só um dos dez funcionou. Mas não havia nenhum erro nos logs. Nenhum. O return [] unless response.success? engolia o HTTP 401 sem logar. O return if posts.empty? descartava o resultado sem avisar ninguém. Tudo verde, tudo silencioso, zero dados.

A correção tem duas partes:

Parte 1: Clients logam o código HTTP:

unless response.success?
  Rails.logger.warn("DailyDevClient: API returned HTTP #{response.code}")
  return []
end

Parece óbvio, mas é fácil esquecer quando você escreve return [] como reflexo defensivo. O response.code é a informação que diferencia “token expirado” (401) de “rate limited” (429) de “API fora do ar” (503). Sem ele, tudo parece igual: array vazio.

Parte 2: Jobs avisam no Discord quando não têm dados:

module DailyDiscordEmbed
  def report_empty(title)
    Rails.logger.warn("#{self.class.name}: #{title} returned no results")
    channel_id = Rails.application.config.discord.channel_ids.first
    return unless channel_id.present?

    embed = {
      title: "⚠️ #{title}",
      description: "#{self.class.name} returned no results. Check logs.",
      color: 0xFFA500,  # laranja = warning, não vermelho = error
      timestamp: Time.current.iso8601
    }
    DiscordNotifier.send_embed(channel_id, embed)
  rescue StandardError => e
    Rails.logger.error("#{self.class.name} empty report failed: #{e.message}")
  end
end

Agora quando um daily job não traz dados:

def perform
  posts = DailyDevClient.fetch_popular(limit: 10)
  if posts.empty?
    report_empty("daily.dev Popular")
    return
  end
  # ...
end

Um embed laranja aparece no Discord. De manhã, abro o canal e vejo: “⚠️ daily.dev Popular returned no results”. Vou nos logs e descubro: “DailyDevClient: API returned HTTP 401”. Token expirado. Corrigido em 2 minutos.

Sem esse padrão, eu teria descoberto semanas depois — quando alguém perguntasse “por que nunca tem posts do daily.dev?”.

A lição: rescue => [] não é error handling. É error hiding. Cada ponto de falha precisa de dois sinais: um log com o detalhe técnico (HTTP code, mensagem de exceção) e uma notificação visual no canal onde você já está olhando (Discord). Se o bot É sua interface operacional, falhas do bot precisam aparecer NA interface.

Padrão 12: Conversas Com Memória (/ask Multi-Turn)

A primeira versão do /ask criava um RubyLLM::Chat novo a cada invocação. Funcionava, mas era como conversar com alguém que tem amnésia:

/ask o que é Ruby?
→ Ruby é uma linguagem de programação criada por Matz em 1995...

/ask compare com Python
→ Comparar o quê com Python? Poderia ser mais específico?

O ruby_llm já mantém histórico internamente — cada chat.ask() appende à lista de mensagens e manda o contexto completo pro modelo. O que faltava era persistir o objeto Chat entre invocações.

A solução é um store in-memory com três safeguards:

class AskSessionStore
  MAX_SESSIONS = 100       # total across all users
  SESSION_TTL = 2.hours    # inactivity timeout
  MAX_MESSAGES = 50        # ~25 exchanges, then auto-reset

  Session = Struct.new(:chat, :last_used, keyword_init: true)

  def get_or_create(author_id, personality, system_prompt:, tools:)
    synchronize do
      cleanup_expired
      key = [author_id, personality]

      if (session = @sessions[key])
        session.last_used = Time.current
        if session.chat.messages.length > MAX_MESSAGES
          @sessions.delete(key)
          return create_session(key, system_prompt: system_prompt, tools: tools)
        end
        session.chat
      else
        evict_oldest if @sessions.size >= MAX_SESSIONS
        create_session(key, system_prompt: system_prompt, tools: tools)
      end
    end
  end
end

A chave vai ser (author_id, personality) — cada usuário tem sessões separadas pro Marvin e pro Akita. Volátil de propósito: reiniciou o servidor, perdeu o histórico. Sem banco, sem serialização, sem complexidade. É memória de trabalho, não persistência.

O /ask clear reseta a sessão. Sem isso, não tem como “começar de novo” quando a conversa fica confusa.

Agora:

/ask o que é Ruby?
→ Ruby é uma linguagem de programação criada por Matz em 1995...

/ask compare com Python
→ Ruby e Python têm filosofias parecidas — ambas priorizam felicidade do
  programador — mas Ruby abraça blocos e metaprogramação enquanto Python
  prefere explicitness...

O LLM sabe que “compare” se refere a Ruby porque o histórico da sessão inclui a pergunta anterior. É a diferença entre um chatbot e um assistente.

Padrão 13: Registrando Application Commands (Autocomplete Nativo)

A seção sobre Application Commands acima mostrou o conceito simplificado. Na prática, registrar 18 comandos com subcommands, parâmetros tipados e choices exige uma estrutura dedicada. Veja como o projeto resolve isso.

O Problema Com Texto Puro

Quando o bot só parseia texto, o usuário precisa decorar a sintaxe:

/update score #1 #2 #3 high       ← funciona
/update score #1 #2 #3 alta       ← falha silenciosamente
/update scoree #1 high             ← ignorado

Sem autocomplete, sem validação de parâmetros, sem documentação inline. O usuário digita / e não sabe o que está disponível.

O Módulo DiscordCommands

Toda a definição de comandos vive num módulo separado com dois métodos públicos: register! (cadastra os comandos na API do Discord) e setup_handlers! (conecta os handlers ao bot):

module DiscordCommands
  SCORE_CHOICES  = { "High" => "high", "Medium" => "medium", "Low" => "low" }.freeze
  SECTION_CHOICES = {
    "Tech" => "tech", "Global" => "global", "Financial" => "financial",
    "Q&A" => "qa", "Entertainment" => "entertainment", "Open Source" => "opensource",
    "Product" => "product", "Book" => "book"
  }.freeze
  PERSONALITY_CHOICES = { "Marvin (default)" => "marvin", "Akita" => "akita" }.freeze

  def self.register!(bot)
    server_id = Rails.application.config.discord.server_id
    sid = server_id.present? ? server_id.to_i : nil

    register_week(bot, sid)
    register_add(bot, sid)
    register_update(bot, sid)
    register_ask(bot, sid)
    # ... mais 14 comandos
  end

  def self.setup_handlers!(bot)
    setup_week_handlers(bot)
    setup_add_handler(bot)
    setup_update_handlers(bot)
    setup_ask_handlers(bot)
    # ... mais 14 handlers
  end
end

Guild vs Global

O server_id (ou sid) controla o escopo do registro. Com server_id, o comando aparece instantaneamente no servidor especificado. Sem, o comando é global — disponível em todos os servidores, mas pode levar até uma hora pra propagar.

Para um bot privado de operações internas, sempre use guild-scoped. O env var DISCORD_SERVER_ID é configurado no deploy:

sid = server_id.present? ? server_id.to_i : nil
bot.register_application_command(:week, "Story list and weekly report", server_id: sid)

Se sid for nil, o discordrb registra globalmente. Em dev, é conveniente; em produção, guild-scoped é mais rápido e permite comandos diferentes por servidor.

Anatomia De Um Comando

O método mais simples — sem parâmetros:

def self.register_count(bot, sid)
  bot.register_application_command(:count, "Show story count for this week", server_id: sid)
end

Com parâmetros tipados:

def self.register_add(bot, sid)
  bot.register_application_command(:add, "Submit a URL for the newsletter", server_id: sid) do |cmd|
    cmd.string(:url, "The URL to submit", required: true)
    cmd.string(:tags, "Tags (e.g. #tech #high)")
    cmd.string(:comment, "Optional comment about this link")
  end
end

O Discord mostra isso como um formulário inline: campo url obrigatório, tags e comment opcionais. O usuário vê a descrição de cada parâmetro enquanto preenche.

Subcommands: Agrupando Ações

Comandos complexos usam subcommands. /update sozinho não faz nada — o usuário precisa escolher o que atualizar:

def self.register_update(bot, sid)
  bot.register_application_command(:update, "Update story properties", server_id: sid) do |cmd|
    cmd.subcommand(:score, "Update story priority score") do |sub|
      sub.string(:stories, "Story numbers (e.g. #1 #2 #3 or 1,2,3)", required: true)
      sub.string(:level, "Priority level", required: true, choices: SCORE_CHOICES)
    end
    cmd.subcommand(:tag, "Update story section tag") do |sub|
      sub.string(:stories, "Story numbers (e.g. #1 #2 #3 or 1,2,3)", required: true)
      sub.string(:section, "Section tag", required: true, choices: SECTION_CHOICES)
    end
    cmd.subcommand(:image, "Update story image") do |sub|
      sub.string(:stories, "Story numbers (e.g. #1 #2 #3 or 1,2,3)", required: true)
      sub.attachment(:file, "Image file (omit for AI generation)")
    end
    # ... mais subcommands: title, description, comment, source
  end
end

Quando o usuário digita /update, o Discord mostra uma lista de subcommands: score, tag, title, description, comment, image, source. Ao escolher score, aparece o campo stories (texto livre) e level (dropdown com High/Medium/Low). Impossível errar a sintaxe.

Choices: Dropdowns Nativos

O hash SCORE_CHOICES vira um dropdown no Discord. A chave é o label visível (“High”), o valor é o que chega no handler (“high”):

SCORE_CHOICES = { "High" => "high", "Medium" => "medium", "Low" => "low" }.freeze

# No registro:
sub.string(:level, "Priority level", required: true, choices: SCORE_CHOICES)

O usuário não precisa lembrar se é “high”, “HIGH”, “alta”, ou “3”. Seleciona no dropdown e pronto. Isso elimina uma categoria inteira de erros de input.

Attachments: Upload de Arquivos

O Discord suporta parâmetros do tipo attachment — o usuário pode arrastar um arquivo direto no comando:

cmd.subcommand(:image, "Update story image") do |sub|
  sub.string(:stories, "Story numbers (e.g. #1 #2 #3 or 1,2,3)", required: true)
  sub.attachment(:file, "Image file (omit for AI generation)")
end

No handler, os attachments resolvidos vêm como URLs do CDN do Discord:

def self.resolve_attachments(event)
  return [] unless event.resolved&.attachments&.any?
  event.resolved.attachments.values.map(&:url)
end

Lifecycle: Onde Registrar, Onde Conectar Handlers

Esse é o ponto que mais confunde. Os handlers precisam ser registrados antes do bot.run. O registro na API do Discord pode acontecer no bot.ready (que dispara após a conexão WebSocket):

class MarvinBotRunner
  def self.run!
    bot = Discordrb::Bot.new(token: token, intents: ...)

    # 1. Handlers ANTES do bot.run (senão o bot não sabe como responder)
    DiscordCommands.setup_handlers!(bot)

    bot.ready do |_event|
      # 2. Registro na API DEPOIS da conexão (idempotente, safe on reconnect)
      DiscordCommands.register!(bot)
    end

    bot.run
  end
end

Por que no bot.ready? Porque o bot pode reconectar (Discord fecha WebSockets periodicamente). O register! é idempotente — registrar o mesmo comando duas vezes não duplica, só atualiza. Colocar no ready garante que os comandos existem mesmo após um reconnect.

Bridge: Application Command → CommandDispatcher

O ponto mais elegante da arquitetura: o handler de Application Command não tem lógica de negócio. Ele traduz os parâmetros do Discord pro formato que o CommandDispatcher já espera:

def self.dispatch_interaction(event, type, match: [nil], attachments: [])
  event.respond(content: "\u{2705}", ephemeral: true)  # checkmark só visível pro autor
  command = SlashCommandParser::Command.new(
    type: type,
    args: { match: match, attachments: attachments }
  )
  CommandDispatcher.dispatch(command,
    channel_id: event.channel.id.to_s,
    message_id: nil,
    author_id: event.user.id.to_s
  )
rescue StandardError => e
  Rails.logger.error("Discord interaction error (#{type}): #{e.message}")
end

Cada handler de subcommand é um one-liner que monta os argumentos e chama dispatch_interaction:

bot.application_command(:update).subcommand(:score) do |event|
  stories = event.options["stories"]
  level = event.options["level"]
  dispatch_interaction(event, :update_score, match: [nil, stories, nil, level])
end

O CommandDispatcher não sabe se o comando veio de texto puro ou de Application Command. A mesma lógica, a mesma autorização, os mesmos jobs. Nenhum código duplicado.

O Resultado

O projeto registra 18 Application Commands com combinações de subcommands, parâmetros tipados, dropdowns e upload de arquivos. O usuário digita / e vê tudo disponível com descrição. Escolhe um comando e o Discord guia o preenchimento campo a campo. Erros de sintaxe são impossíveis — o Discord valida antes de enviar.

E os dois sistemas coexistem: quem prefere autocomplete usa Application Commands, quem prefere digitar rápido usa texto puro. O CommandDispatcher recebe os dois da mesma forma. Adicionar um novo comando é adicionar um register_*, um setup_*_handler, e um método no dispatcher — sem mexer no runner.

As Armadilhas do discordrb

Nem tudo são flores. Algumas dores reais:

Gateway disconnects: O WebSocket com o Discord cai de vez em quando. O discordrb reconecta automaticamente, mas seus handlers bot.ready e bot.message precisam ser resilientes a reconexões.

Message Content Intent: Desde 2022, bots em mais de 75 servidores precisam de aprovação pra ler conteúdo de mensagens. Pra bots privados (que é o caso de operação interna), isso não é problema. Mas se você planeja distribuir o bot, prepare o paperwork.

API Rate Limits: O Discord rate-limita por rota. Mandar 10 embeds de uma vez pro mesmo canal? Vai bater no limite. O discordrb faz rate limit handling internamente, mas chamadas rápidas demais causam delays visíveis.

Embed Limits: Título máximo 256 chars. Description 4096. Field value 1024. Excedeu? Erro silencioso. Sempre trunca antes de enviar.

File Uploads: Limit de 25MB no plano gratuito, 50MB com Nitro. Pra imagens de IA geradas isso nunca é problema, mas se for mandar PDFs ou áudio, cuidado.

Quando NÃO Usar Discord Como Admin

• Formulários complexos: editar 15 campos de um registro? Tela web
• Bulk operations: importar CSV com 1000 registros? Script
• Visualização de dados: gráficos, dashboards analíticos? Grafana/Metabase
• Aprovação multi-step: workflows com 5 etapas de aprovação? Precisa de estado persistido

Mas pra o dia a dia operacional — curar conteúdo, aprovar newsletters, monitorar jobs, checar custos, conversar com IA — Discord é a interface mais produtiva que já usei. E o melhor: os assinantes nunca vão saber que a newsletter semanal deles foi curada por um cara digitando comandos no Discord do celular enquanto toma café.

Conclusão

Usar Discord como admin panel não é preguiça — é pragmatismo. A melhor interface é a que você já usa o dia inteiro. Auth, push notifications, mobile, rich formatting, file sharing — tudo de graça. Você só constrói a lógica de negócio.

A gem ruby_llm com tool calling leva o bot de “executor de comandos” pra “assistente que pensa”. Com memória de sessão, pensa e lembra. Quando o LLM pode gerar imagens, buscar na web, manter contexto entre perguntas, e responder sobre a arquitetura do próprio sistema — aí deixou de ser CRUD e virou co-piloto.

E o padrão Parser → Dispatcher → Job mantém tudo testável. O parser não sabe nada de Discord. O dispatcher não sabe nada de IA. Os jobs não sabem nada de interface. Troca qualquer uma dessas camadas e as outras nem percebem.

No fim, a melhor admin UI é a que não precisa de deploy separado. E o pior bug é o que falha em silêncio — se o bot é sua interface operacional, as falhas do bot precisam aparecer na interface, não escondidas num log que ninguém lê.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

–

Dez anos atrás, buscar dados em um site era trivial. Quatro linhas de Ruby: Net::HTTP.get, Nokogiri parse, CSS selector, pronto. O mundo inteiro estava aberto pra qualquer script com um User-Agent decente.

Hoje? Metade dos sites que preciso ler pra montar minha newsletter retorna “Are you a robot?” pra qualquer requisição HTTP convencional. A outra metade renderiza o conteúdo inteiramente em JavaScript — não há HTML nenhum na resposta do servidor. E os mais paranoicos combinam as duas coisas.

Meu objetivo era criar uma rotina diária pro M.arvin me devolver as principais notícias pela manhã no meu Discord. Assim eu não preciso sair caçando as notícias do dia. Parecia simples… no começo.

Este post é sobre como passei de “uma chamada HTTP” pra “empacotar um Chromium inteiro no Docker” — e por que isso é a realidade de qualquer projeto que precisa ler a web programaticamente em 2026.

A Idade de Ouro: HTTP Simples

Vamos começar pelo que ainda funciona. Alguns serviços oferecem dados estruturados sem nenhuma resistência:

# RSS feeds: o formato mais resiliente da web
uri = URI("https://news.google.com/rss/search?q=when:24h+allinurl:reuters.com/world")
xml = Net::HTTP.get(uri)
doc = REXML::Document.new(xml)
doc.get_elements("//item").each do |item|
  title = item.get_text("title").to_s
  url   = item.get_text("link").to_s
end

# APIs públicas: JSON limpo, documentado, estável
response = HTTParty.get("https://api.jikan.moe/v4/top/anime?filter=airing")
animes = response.parsed_response["data"]

# GitHub trending: HTML server-rendered sem proteção
html = HTTParty.get("https://github.com/trending").body
doc = Nokogiri::HTML(html)
repos = doc.css("article.Box-row")

Hacker News, GitHub Trending, APIs de anime, feeds RSS, Project Gutenberg — todos funcionam com um GET e um parser. Sem JavaScript, sem autenticação implícita, sem fingerprinting. Assim como a web deveria ser.

O problema é que esses são a exceção. Os sites que têm dados financeiros, notícias exclusivas ou conteúdo premium — exatamente os dados que mais importam — estão cada vez mais blindados.

O Primeiro Obstáculo: SPAs e JavaScript Rendering

Quando o servidor retorna algo tipo:

<html>
<body>
  <div id="root"></div>
  <script src="/app-3fa8c2.js"></script>
</body>
</html>

Seu Net::HTTP.get retorna exatamente isso: uma div vazia e um link pra um bundle de 2 MB. O conteúdo real — artigos, preços, listas — é montado no browser por React, Vue, Angular ou o framework da semana.

Pra um script, essa página é inútil. Pra extrair o conteúdo, você precisa executar o JavaScript. Isso significa rodar um browser real.

No mundo Ruby, a resposta é a gem ferrum — um cliente CDP (Chrome DevTools Protocol) que controla o Chromium programaticamente:

browser = Ferrum::Browser.new(headless: "new", timeout: 30)
browser.go_to("https://www.morningstar.com/markets")
browser.network.wait_for_idle  # espera o JS terminar de carregar
html = browser.body  # agora sim o DOM está populado
browser.quit

Esse browser.body retorna o HTML depois que o JavaScript executou. Mesmos dados que você vê no browser, agora acessíveis pro seu parser.

Mas aqui começa a dor de cabeça: você precisa de um binário do Chromium disponível no sistema. No Docker, isso significa adicionar ~300MB à imagem. No servidor, significa mais uma dependência pra gerenciar. E a latência de abrir um browser, navegar, esperar JS renderizar, e extrair o HTML — estamos falando de 3 a 10 segundos por página, ao invés dos 200ms de um HTTP GET.

O projeto usa isso como estratégia principal no ArticleFetcher: primeiro tenta com browser (pra pegar SPAs), depois faz um fallback HTTP simples (pra pegar metadata OpenGraph quando o browser falha). A maioria dos links que os leitores mandam no Discord são de sites que renderizam com JavaScript, então o browser-first compensa.

O Segundo Obstáculo: Bot Detection

Abrir uma página com Chromium headless resolve o problema de JavaScript. Mas resolve 50% dos sites — não 100%. Porque existe uma indústria inteira dedicada a distinguir browsers reais de browsers automatizados.

O Que o Headless Chrome Revela

Chromium em modo headless é quase idêntico ao Chrome normal. Quase. As diferenças são sutis, mas suficientes pra detecção:

1. navigator.webdriver — Em todo Chrome controlado por automação, essa propriedade retorna true. Em browsers normais, undefined. É o flag mais óbvio.

2. navigator.plugins — Chrome normal tem 3-5 plugins (PDF viewer, etc.). Headless retorna array vazio. Bot detectado.

3. navigator.userAgentData — A Client Hints API. Chrome real retorna brands, platform, mobile flag. Headless pode não ter isso.

4. WebGL fingerprint — O renderer WebGL num headless Chrome retorna “SwiftShader” (renderizador por software). Chrome real retorna “NVIDIA GeForce” ou “Intel Iris” ou o que for. Bot detectado.

5. Timing e behavior — Browsers reais demoram pra carregar. Fazem scroll. Movem o mouse. Têm focus events. Um script que faz go_to → body em 2 segundos não se parece com um humano.

A solução é o que chamo de StealthBrowser — um wrapper que injeta patches JavaScript antes de qualquer script da página rodar:

class StealthBrowser
  STEALTH_JS = <<~JS
    // Remove o flag de automação
    Object.defineProperty(navigator, 'webdriver', { get: () => false });

    // Simula plugins reais
    Object.defineProperty(navigator, 'plugins', {
      get: () => [
        { name: 'Chrome PDF Plugin', filename: 'internal-pdf-viewer' },
        { name: 'Chrome PDF Viewer', filename: 'mhjfbmdgcfjbbpaeojofohoefgiehjai' },
        { name: 'Native Client', filename: 'internal-nacl-plugin' }
      ]
    });

    // Simula WebGL renderer real
    const getParameter = WebGLRenderingContext.prototype.getParameter;
    WebGLRenderingContext.prototype.getParameter = function(p) {
      if (p === 37445) return 'Google Inc. (NVIDIA)';
      if (p === 37446) return 'ANGLE (NVIDIA, GeForce GTX 1080 ...)';
      return getParameter.call(this, p);
    };

    // Client Hints API (ausente em headless = bot signal)
    if (!navigator.userAgentData) {
      Object.defineProperty(navigator, 'userAgentData', {
        get: () => ({
          brands: [
            { brand: 'Chromium', version: '131' },
            { brand: 'Google Chrome', version: '131' }
          ],
          mobile: false, platform: 'Linux'
        })
      });
    }
  JS

  def self.fetch(url, name:, wait_for: nil)
    browser = Ferrum::Browser.new(headless: "new", timeout: 30,
      browser_options: {
        "disable-blink-features" => "AutomationControlled",
        "user-agent" => REAL_USER_AGENT
      })

    # Injeta ANTES de qualquer script da página rodar
    browser.page.command("Page.addScriptToEvaluateOnNewDocument", source: STEALTH_JS)

    browser.go_to(url)
    yield browser
  ensure
    browser&.quit
  end
end

O truque-chave é Page.addScriptToEvaluateOnNewDocument — um comando CDP que registra o JavaScript pra ser executado antes de qualquer script da página. Isso significa que, quando o bot detector roda, ele vê os valores falsos que injetamos, e não os reais. E disable-blink-features=AutomationControlled remove o flag navigator.webdriver no nível do browser, antes mesmo do JavaScript.

Isso funciona pra maioria dos sites. Morningstar, Hindenburg Research, sites de notícias genéricos — passam com o stealth. Yahoo Finance precisa de mais — TLS fingerprinting que bloqueia até o Chromium sem crumb authentication. Mas o browser stealth resolve o grosso.

O Terceiro Obstáculo: DataDome e CDPs de Anti-Bot

E aí chegamos aos profissionais. DataDome, Cloudflare Turnstile, PerimeterX, Akamai Bot Manager — são serviços especializados em detectar automação. E eles jogam num nível completamente diferente.

A Reuters, por exemplo, usa DataDome. Quando tentei acessar reuters.com/world/ com o StealthBrowser, recebi de volta uma página de 1.500 bytes com um captcha JavaScript. Todos os patches de navigator.webdriver, WebGL, plugins — inúteis.

Por quê? Porque o DataDome não checa só propriedades JavaScript. Ele detecta o próprio protocolo de automação.

O Problema Fundamental do CDP

Quando o Ferrum (ou Puppeteer, ou Playwright) controla um Chrome, ele faz isso via Chrome DevTools Protocol — o CDP. E a primeira coisa que o Ferrum faz ao conectar é enviar Runtime.enable — um comando que ativa o runtime evaluation no browser.

O problema é que Runtime.enable muda o comportamento observável do browser. Especificamente, ele ativa interceptors internos que podem ser detectados via console.debug. O DataDome usa isso: ele faz um console.debug com um getter que observa se o runtime está interceptando. Se está — e com CDP sempre está — bot detectado.

// O que o DataDome faz (simplificado):
let detected = false;
const el = document.createElement('div');
Object.defineProperty(el, 'id', {
  get: () => { detected = true; return 'test'; }
});
console.debug(el);
// Se Runtime.enable está ativo, o getter é trigado
// Em um browser normal, não é

Isso não é algo que você pode patchar com JavaScript. O Runtime.enable é mandado pelo Ferrum antes de qualquer script rodar — é parte do protocolo de automação. Pra resolver, você precisaria modificar o Ferrum pra não mandar esse comando, o que quebraria a maioria das funcionalidades da gem.

As Alternativas (e Por Que Nenhuma é Ideal)

Pesquisei extensivamente. As opções:

1. nodriver (Python): Usa Chrome via CDP sem Runtime.enable. Não tem equivalente em Ruby. E mesmo assim, está numa corrida de gato-e-rato com DataDome.

2. curl-impersonate: Faz TLS fingerprinting idêntico ao Chrome sem abrir um browser. Bom pra sites com TLS detection, inútil pra SPAs.

3. Scraping APIs (ScraperAPI, ZenRows): Terceirizam o problema. Funcionam, mas custam dinheiro e adicionam latência e dependência.

4. Fork do Ferrum: Modificar a gem pra opcionalmente não mandar Runtime.enable. Viável tecnicamente, mas manutenção infinita.

5. Google News RSS: O Google já leu a Reuters. O resultado tá num feed RSS público. Sem JavaScript, sem DataDome, sem browser.

A opção 5 venceu. Pra Reuters, troquei toda a complexidade de headless browser por:

class ReutersClient
  RSS_URL = "https://news.google.com/rss/search?q=when:24h+allinurl:reuters.com/world"

  def self.fetch_headlines(limit: 10)
    xml = Net::HTTP.get(URI(RSS_URL))
    doc = REXML::Document.new(xml)
    doc.get_elements("//item").first(limit).filter_map do |item|
      title = item.get_text("title")&.to_s&.strip
      url   = item.get_text("link")&.to_s&.strip
      next if title.blank? || url.blank?
      { title: title.sub(/\s*-\s*Reuters\s*\z/, ""), url: url, category: nil }
    end
  rescue StandardError => e
    Rails.logger.warn("ReutersClient failed: #{e.message}")
    []
  end
end

Simples. Confiável. Zero dependências de browser. O link do Google News redireciona pro artigo original quando o leitor clica — funciona perfeitamente pra uma newsletter.

Nem todo problema de scraping precisa de solução de scraping. Às vezes o dado já está disponível num formato acessível — você só precisa achar.

O Quarto Obstáculo: Sites que Mudam de Estrutura (Diariamente)

Mesmo quando o scraping funciona, a manutenção nunca para. O Morningstar é um caso didático — porque me fez errar duas vezes antes de chegar numa solução resiliente.

Tentativa 1: Selecionar pela Hierarquia DOM

Originalmente, os links de artigos estavam dentro de <h2> e <h3>:

<h2><a href="/markets/article-slug">Título do Artigo</a></h2>

Um dia depois: zero resultados. O Morningstar mudou a estrutura pra flat links com classes CSS específicas — sem heading elements:

<a class="mdc-basic-feed-item__mdc" href="/markets/article-slug">
  <header><h3>Título do Artigo</h3></header>
  <div class="mdc-metadata__mdc">Autor · Data</div>
</a>

Tentativa 2: Selecionar pela Classe CSS

A correção óbvia: trocar hierarquia DOM por seletores CSS baseados na classe do componente:

ARTICLE_CSS = "a.mdc-basic-feed-item__mdc, a.mdc-card--link__mdc"
doc.css(ARTICLE_CSS).each { |link| ... }

Funcionou. Por exatamente um dia. Depois: zero resultados de novo. O Morningstar — como muitos sites modernos com frameworks CSS-in-JS — gera nomes de classe dinamicamente. O que era mdc-basic-feed-item__mdc virou outra coisa. E pode virar algo diferente amanhã.

Isso é cada vez mais comum. Sites que usam CSS Modules, styled-components, ou Tailwind com JIT geram hashes aleatórios nos nomes de classe como parte do build. A cada deploy do site, as classes mudam. Seu seletor hardcoded é uma bomba-relógio.

Tentativa 3: Não Depender de Nenhum Nome de Classe

A solução final é inverter a lógica: ao invés de dizer ao parser quais classes procurar, deixar o parser descobrir quais links são artigos baseado em propriedades estruturais que não mudam:

1. Links de artigos têm URLs longas: /news/why-stock-market-is-up-today-2026-02-17 vs links de navegação como /markets ou /tools
2. Links de artigos são agrupados: aparecem em listas, feeds, grids — múltiplos links com a mesma classe CSS
3. Links de artigos têm títulos descritivos: textos longos, não labels curtas como “Markets” ou “Tools”

O algoritmo:

def self.parse_html(html, limit)
  doc = Nokogiri::HTML(html)

  # 1. Coleta todos os <a> internos com href, classe, e texto suficiente
  candidates = doc.css("a[href]").filter_map do |link|
    href = link["href"].to_s.strip
    css_class = link["class"].to_s.strip
    next if href.blank? || css_class.blank?
    next unless internal_href?(href)

    path = extract_path(href)
    segments = path.split("/").reject(&:empty?)
    next if segments.length < 2  # links de nav têm 1 segmento: /markets

    title = extract_title(link)
    next if title.blank? || title.length < 10

    { title: title, url: absolutize(href), css_class: css_class, slug_length: path.length }
  end

  # 2. Agrupa por classe CSS
  groups = candidates.group_by { |c| c[:css_class] }

  # 3. Filtra: mínimo 3 links no grupo (clusters de artigos, não links soltos)
  # 4. Seleciona o grupo com maior média de comprimento de slug
  best = groups
    .select { |_cls, items| items.length >= 3 }
    .max_by { |_cls, items| items.sum { |i| i[:slug_length] }.to_f / items.length }

  return [] unless best

  best[1].map { |c| c.slice(:title, :url) }.uniq { |a| a[:url] }.first(limit)
end

O que salva essa abordagem: nenhum nome de classe é hardcoded. O Morningstar pode renomear todas as classes amanhã e o parser vai continuar funcionando — porque ele descobre o padrão de artigos pela estrutura, não pelo nome.

O que é estável num site:

• URLs de artigos são sempre mais longas que URLs de navegação (isso é arquitetural, não cosmético)
• Artigos são sempre agrupados sob o mesmo componente (isso é UX, não implementação)
• Títulos de artigos são descritivos (isso é editorial, não técnico)

O que não é estável:

• Nomes de classes CSS (mudam a cada build)
• Hierarquia DOM (muda a cada redesign)
• Atributos data-* (mudam conforme a equipe de frontend decide)

Resumindo: não tente identificar elementos pelo nome — identifique pelo comportamento. Links de artigos se comportam diferente de links de navegação de formas mensuráveis (URL length, clustering, título), e essas propriedades são inerentes ao que o elemento É, não a como ele foi implementado.

A Hierarquia de Confiabilidade

Depois de horas quebrando a cabeça, ficou óbvia uma hierarquia de fontes de dados:

A regra: sempre prefira a fonte mais simples que funcione. Se o site tem RSS, use RSS. Se tem API, use a API. Só vá pro headless browser quando não há alternativa.

No projeto, a distribuição ficou assim:

HTTP simples (Net::HTTP ou HTTParty):

• Google News RSS (Reuters world headlines)
• Hacker News RSS (top stories)
• HackerNoon RSS (top stories)
• dev.to API (trending articles)
• Jikan API (anime rankings)
• YouTube Data API (vídeos)
• Yahoo Finance news RSS

Headless browser (StealthBrowser + Ferrum):

• Morningstar (SPA + componentes dinâmicos)
• Yahoo Finance charts (TLS fingerprinting + crumb auth)
• FinViz market map (canvas rendering)
• Artigos genéricos de leitores (qualquer URL pode ser SPA)
• Hindenburg Research (JavaScript-rendered)

Ou seja: a maioria das fontes de dados funciona sem browser. O browser é necessário pra meia dúzia de sites problemáticos — mas são esses sites que dão mais trabalho.

O Custo Real

Vamos ser práticos sobre o que “empacotar um Chrome” significa:

Imagem Docker: +300MB. O Chromium e suas dependências (fontes, libs gráficas, sandbox) são enormes. Num Dockerfile otimizado com multi-stage build:

# Instala Chromium e dependências mínimas
RUN apt-get install -y chromium fonts-liberation libnss3 libatk-bridge2.0-0 \
    libdrm2 libxkbcommon0 libgbm1

Memória: Cada instância de Chromium consome 200-400MB de RAM. Se você tem 3 workers paralelos, são 1.2GB só pra browsers. Num VPS de 2GB, isso é 60% da memória.

Latência: Uma página que leva 200ms via HTTP leva 3-8 segundos via headless browser (boot do processo, navegação, JS execution, network idle). Pra 10 fontes de dados, são 30-80 segundos ao invés de 2.

Estabilidade: Chromium pode crashar, travar, ou vazar memória. Timeout de 30 segundos com cleanup no ensure é obrigatório:

def self.fetch(url, name:)
  browser = create(name: name)
  browser.go_to(url)
  yield browser
ensure
  browser&.quit  # SEMPRE quit, mesmo com exceção
end

Se não fizer o quit, o processo Chromium fica pendurado consumindo CPU e memória. Já tive servidor com 15 processos Chrome zumbis comendo 3GB de RAM porque um ensure estava faltando.

O Futuro (Ou: Vai Piorar)

A tendência é clara: sites estão ficando mais difíceis de acessar programaticamente. A cada trimestre, os DataDomes e Cloudflares da vida adicionam novas técnicas de detecção. Chrome headless fica mais parecido com Chrome real — mas os detectores acompanham.

A web que nasceu aberta e legível por máquina está se tornando um jardim murado. Até RSS, que é trivial de implementar e útil pra todo mundo, está sendo abandonado por muitos sites — porque não querem que seus dados sejam lidos fora do contexto (e dos anúncios) do site original.

Pra quem constrói sistemas que agregam informação, o playbook é:

1. Use APIs e feeds sempre que existirem. É mais estável, mais rápido, mais respeitoso
2. Mantenha um browser stealth pra SPAs que não têm alternativa
3. Nunca hardcode seletores CSS. Sites com CSS-in-JS mudam nomes de classe a cada deploy. Identifique elementos por propriedades estruturais (comprimento de URL, clustering, tamanho do título) que sobrevivem a redesigns
4. Detecte bloqueios e falhe graciosamente — og:description como fallback, título extraído da URL como último recurso
5. Nunca dependa de um único método de acesso. O site que funciona hoje pode bloquear amanhã
6. Aceite que alguns sites são inacessíveis. Se o DataDome não deixa, o dado terá que vir de outra fonte

A web em 2026 é um campo de batalha entre quem quer ler e quem quer controlar a leitura. Mas no longo prazo, a criatividade de quem quer acessar dados vence — mas custa mais esforço a cada ano. E, diferente do que eu pensei no começo: nunca é simples.

Ainda não entendi o quanto faz diferença ou não, mas tanto OpenCode quanto Crush tem suporte a Language Servers (LSPs) então achei legal deixar configurado. Eis meu ~/.config/crush/crush.json:

{
  "$schema": "https://charm.land/crush.json",
  "default_provider": "openrouter",
  "providers": {
    "openrouter": {
      "api_key": "sk-..."
    },
    "lmstudio": {
      "name": "LM Studio",
      "base_url": "http://localhost:1234/v1/",
      "type": "openai",
      "models": [
        {
          "name": "gpt-oss-120b",
          "id": "gpt-oss:120b",
          "context_window": 100000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "gpt-oss-20b",
          "id": "gpt-oss:20b",
          "context_window": 130000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "zai-org/glm-4.6v-flash",
          "id": "glm-4.6v-flash",
          "context_window": 130000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "deepseek-coder-v2-lite-instruct",
          "id": "deepseek-coder-v2-lite-instruct",
          "context_window": 64000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen/qwen3-coder-30b",
          "name": "qwen3-coder-30b",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        }
      ]
    },
    "ollama": {
      "type": "openai-compat",
      "base_url": "http://127.0.0.1:11434/v1",
      "api_key": "ollama",
      "models": [
        {
          "name": "glm-4.7-flash",
          "id": "glm-4.7-flash",
          "context_window": 65536,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "name": "gpt-oss-20b",
          "id": "gpt-oss:20b",
          "context_window": 64000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen3-nuclear",
          "name": "qwen3-nuclear",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen3-coder:30b",
          "name": "qwen3-coder:30b",
          "context_window": 120000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "qwen2.5-coder:32b",
          "name": "qwen2.5-coder:32b",
          "context_window": 32768,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "deepseek-coder-v2:16b",
          "name": "deepseek-coder-v2:16b",
          "context_window": 128000,
          "default_max_tokens": -1,
          "supports_tools": true
        },
        {
          "id": "glm-4.7:cloud",
          "name": "glm-4.7:cloud",
          "context_window": 128000,
          "default_max_tokens": -1,
          "supports_tools": true
        }
      ]
    }
  },
  "lsp": {
    "gopls": {
      "command": "gopls"
    },
    "rust-analyzer": {
      "command": "rust-analyzer"
    },
    "ruby-lsp": {
      "command": "ruby-lsp"
    },
    "solargraph": {
      "command": "solargraph",
      "args": [
        "stdio"
      ]
    },
    "pylsp": {
      "command": "pylsp"
    },
    "pyright": {
      "command": "pyright-langserver",
      "args": [
        "--stdio"
      ]
    },
    "elixir-ls": {
      "command": "elixir-ls"
    },
    "docker-langserver": {
      "command": "docker-langserver",
      "args": [
        "--stdio"
      ],
      "languages": [
        "dockerfile"
      ]
    },
    "bash-language-server": {
      "command": "bash-language-server",
      "args": [
        "start"
      ]
    },
    "marksman": {
      "command": "marksman",
      "args": [
        "server"
      ]
    },
    "typescript-language-server": {
      "command": "typescript-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-html-language-server": {
      "command": "vscode-html-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-css-language-server": {
      "command": "vscode-css-language-server",
      "args": [
        "--stdio"
      ]
    },
    "vscode-json-language-server": {
      "command": "vscode-json-language-server",
      "args": [
        "--stdio"
      ]
    },
    "yaml-language-server": {
      "command": "yaml-language-server",
      "args": [
        "--stdio"
      ]
    },
    "taplo": {
      "command": "taplo",
      "args": [
        "lsp",
        "stdio"
      ]
    }
  },
  "mcp": {
    "blender": {
      "type": "stdio",
      "command": "uvx",
      "args": [
        "blender-mcp"
      ]
    }
  }
}

Notem que eu uso primariamente Claude Opus 4.5 via OpenRouter e tenho LM Studio e Ollama configurados como providers pra testar outros modelos open source.

Também uso Mise pra organizar as linguagens de programação que uso.

Porém, agora precisa instalar os LSPs de cada linguagem. Eu não conheço um jeito melhor de gerenciar isso da mesma forma como com um Mason no Neovim. Então fiz um script pra instalar tudo pra mim (no meu Arch Linux). Pra isso criei este script ~/.local/bin/install-lsps.sh:

#!/usr/bin/env bash
set -euo pipefail

# LSP Installer for Arch Linux with Mise
# Installs major LSPs using native package managers or yay
# Only installs LSPs for languages that are already installed

GREEN='\033[0;32m'
BLUE='\033[0;34m'
YELLOW='\033[1;33m'
RED='\033[0;31m'
NC='\033[0m'

info() { echo -e "${BLUE}[INFO]${NC} $1"; }
success() { echo -e "${GREEN}[OK]${NC} $1"; }
warn() { echo -e "${YELLOW}[SKIP]${NC} $1"; }
skip_lang() { echo -e "${RED}[LANG]${NC} $1 not installed, skipping LSPs"; }

command_exists() { command -v "$1" &>/dev/null; }

# ─────────────────────────────────────────────────────────────
# Language detection helpers
# ─────────────────────────────────────────────────────────────
has_c()       { command_exists gcc || command_exists clang; }
has_rust()    { command_exists rustc || command_exists cargo; }
has_go()      { command_exists go; }
has_python()  { command_exists python || command_exists python3; }
has_node()    { command_exists node || command_exists npm; }
has_java()    { command_exists java || command_exists javac; }
has_kotlin()  { command_exists kotlin || command_exists kotlinc; }
has_ruby()    { command_exists ruby; }
has_php()     { command_exists php; }
has_lua()     { command_exists lua || command_exists luajit; }
has_zig()     { command_exists zig; }
has_haskell() { command_exists ghc || command_exists stack || command_exists cabal; }
has_elixir()  { command_exists elixir || command_exists iex; }
has_scala()   { command_exists scala || command_exists sbt; }
has_dotnet()  { command_exists dotnet; }
has_ocaml()   { command_exists ocaml || command_exists opam; }
has_clojure() { command_exists clojure || command_exists clj || command_exists lein; }
has_nix()     { command_exists nix; }
has_terraform() { command_exists terraform || command_exists tofu; }
has_latex()   { command_exists latex || command_exists pdflatex || command_exists xelatex; }
has_docker()  { command_exists docker || command_exists podman; }
has_ansible() { command_exists ansible; }
has_sql()     { command_exists psql || command_exists mysql || command_exists sqlite3; }
has_bash()    { command_exists bash; }

# ─────────────────────────────────────────────────────────────
# Package installation helpers
# ─────────────────────────────────────────────────────────────
install_pacman() {
    local pkg="$1"
    if pacman -Qi "$pkg" &>/dev/null; then
        warn "$pkg already installed"
    else
        sudo pacman -S --noconfirm --needed "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_yay() {
    local pkg="$1"
    if ! command_exists yay; then
        warn "yay not found, skipping $pkg"
        return
    fi
    if yay -Qi "$pkg" &>/dev/null; then
        warn "$pkg already installed"
    else
        yay -S --noconfirm --needed "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_npm() {
    local pkg="$1"
    if npm list -g "$pkg" &>/dev/null 2>&1; then
        warn "$pkg already installed"
    else
        npm install -g "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_pipx() {
    local pkg="$1"
    if ! command_exists pipx; then
        pip install --user pipx 2>/dev/null || {
            pip install --user "$pkg" && success "$pkg" || warn "Failed: $pkg"
            return
        }
    fi
    if pipx list 2>/dev/null | grep -q "$pkg"; then
        warn "$pkg already installed"
    else
        pipx install "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

install_go() {
    local pkg="$1"
    local name="${pkg##*/}"
    name="${name%%@*}"
    
    # Check if binary already exists in GOPATH/bin
    local gobin="${GOBIN:-${GOPATH:-$HOME/go}/bin}"
    if [[ -x "$gobin/$name" ]]; then
        warn "$name already installed"
        return
    fi
    
    go install "$pkg" && success "$name" || warn "Failed: $name"
}

install_gem() {
    local pkg="$1"
    if gem list -i "^${pkg}$" &>/dev/null; then
        warn "$pkg already installed"
    else
        gem install "$pkg" && success "$pkg" || warn "Failed: $pkg"
    fi
}

# ─────────────────────────────────────────────────────────────
# C/C++ LSPs
# ─────────────────────────────────────────────────────────────
install_c_lsps() {
    if ! has_c; then
        skip_lang "C/C++ (gcc/clang)"
        return
    fi
    info "Installing C/C++ LSPs..."
    install_pacman clang  # includes clangd
}

# ─────────────────────────────────────────────────────────────
# Rust LSPs
# ─────────────────────────────────────────────────────────────
install_rust_lsps() {
    if ! has_rust; then
        skip_lang "Rust"
        return
    fi
    info "Installing Rust LSPs..."
    
    if command_exists rustup; then
        rustup component add rust-analyzer 2>/dev/null && success "rust-analyzer (rustup)" || install_pacman rust-analyzer
    else
        install_pacman rust-analyzer
    fi
}

# ─────────────────────────────────────────────────────────────
# Go LSPs
# ─────────────────────────────────────────────────────────────
install_go_lsps() {
    if ! has_go; then
        skip_lang "Go"
        return
    fi
    info "Installing Go LSPs..."
    
    install_go golang.org/x/tools/gopls@latest
    install_go github.com/go-delve/delve/cmd/dlv@latest
    install_go github.com/nametake/golangci-lint-langserver@latest
}

# ─────────────────────────────────────────────────────────────
# Python LSPs
# ─────────────────────────────────────────────────────────────
install_python_lsps() {
    if ! has_python; then
        skip_lang "Python"
        return
    fi
    info "Installing Python LSPs..."
    
    # Prefer npm pyright (faster updates) if node available
    if has_node; then
        install_npm pyright
    else
        install_pipx pyright
    fi
    
    install_pipx python-lsp-server
    install_pipx ruff-lsp
}

# ─────────────────────────────────────────────────────────────
# Node.js/TypeScript LSPs
# ─────────────────────────────────────────────────────────────
install_node_lsps() {
    if ! has_node; then
        skip_lang "Node.js"
        return
    fi
    info "Installing Node.js/TypeScript LSPs..."
    
    install_npm typescript
    install_npm typescript-language-server
    install_npm vscode-langservers-extracted  # HTML, CSS, JSON, ESLint
    install_npm "@tailwindcss/language-server"
    install_npm "@vue/language-server"
    install_npm svelte-language-server
    install_npm graphql-language-service-cli
    install_npm "@prisma/language-server"
    install_npm emmet-ls
}

# ─────────────────────────────────────────────────────────────
# Java LSPs
# ─────────────────────────────────────────────────────────────
install_java_lsps() {
    if ! has_java; then
        skip_lang "Java"
        return
    fi
    info "Installing Java LSPs..."
    install_yay jdtls
}

# ─────────────────────────────────────────────────────────────
# Kotlin LSPs
# ─────────────────────────────────────────────────────────────
install_kotlin_lsps() {
    if ! has_kotlin; then
        skip_lang "Kotlin"
        return
    fi
    info "Installing Kotlin LSPs..."
    install_yay kotlin-language-server
}

# ─────────────────────────────────────────────────────────────
# Ruby LSPs
# ─────────────────────────────────────────────────────────────
install_ruby_lsps() {
    if ! has_ruby; then
        skip_lang "Ruby"
        return
    fi
    info "Installing Ruby LSPs..."
    install_gem solargraph
    install_gem ruby-lsp
}

# ─────────────────────────────────────────────────────────────
# PHP LSPs
# ─────────────────────────────────────────────────────────────
install_php_lsps() {
    if ! has_php; then
        skip_lang "PHP"
        return
    fi
    if ! has_node; then
        warn "PHP LSP (intelephense) requires npm, skipping"
        return
    fi
    info "Installing PHP LSPs..."
    install_npm intelephense
}

# ─────────────────────────────────────────────────────────────
# Lua LSPs
# ─────────────────────────────────────────────────────────────
install_lua_lsps() {
    if ! has_lua; then
        skip_lang "Lua"
        return
    fi
    info "Installing Lua LSPs..."
    install_pacman lua-language-server
}

# ─────────────────────────────────────────────────────────────
# Zig LSPs
# ─────────────────────────────────────────────────────────────
install_zig_lsps() {
    if ! has_zig; then
        skip_lang "Zig"
        return
    fi
    info "Installing Zig LSPs..."
    install_pacman zls
}

# ─────────────────────────────────────────────────────────────
# Haskell LSPs
# ─────────────────────────────────────────────────────────────
install_haskell_lsps() {
    if ! has_haskell; then
        skip_lang "Haskell"
        return
    fi
    info "Installing Haskell LSPs..."
    install_yay haskell-language-server
}

# ─────────────────────────────────────────────────────────────
# Elixir LSPs
# ─────────────────────────────────────────────────────────────
install_elixir_lsps() {
    if ! has_elixir; then
        skip_lang "Elixir"
        return
    fi
    info "Installing Elixir LSPs..."
    install_yay elixir-ls
}

# ─────────────────────────────────────────────────────────────
# Scala LSPs
# ─────────────────────────────────────────────────────────────
install_scala_lsps() {
    if ! has_scala; then
        skip_lang "Scala"
        return
    fi
    info "Installing Scala LSPs..."
    install_yay metals
}

# ─────────────────────────────────────────────────────────────
# C# / F# (.NET) LSPs
# ─────────────────────────────────────────────────────────────
install_dotnet_lsps() {
    if ! has_dotnet; then
        skip_lang ".NET (C#/F#)"
        return
    fi
    info "Installing .NET LSPs..."
    install_yay omnisharp-roslyn
    install_yay fsautocomplete
}

# ─────────────────────────────────────────────────────────────
# OCaml LSPs
# ─────────────────────────────────────────────────────────────
install_ocaml_lsps() {
    if ! has_ocaml; then
        skip_lang "OCaml"
        return
    fi
    info "Installing OCaml LSPs..."
    if command_exists opam; then
        opam install ocaml-lsp-server -y && success "ocaml-lsp-server" || warn "Failed"
    else
        install_yay ocaml-lsp-server
    fi
}

# ─────────────────────────────────────────────────────────────
# Clojure LSPs
# ─────────────────────────────────────────────────────────────
install_clojure_lsps() {
    if ! has_clojure; then
        skip_lang "Clojure"
        return
    fi
    info "Installing Clojure LSPs..."
    install_yay clojure-lsp-bin
}

# ─────────────────────────────────────────────────────────────
# Nix LSPs
# ─────────────────────────────────────────────────────────────
install_nix_lsps() {
    if ! has_nix; then
        skip_lang "Nix"
        return
    fi
    info "Installing Nix LSPs..."
    install_pacman nil
}

# ─────────────────────────────────────────────────────────────
# Bash LSPs
# ─────────────────────────────────────────────────────────────
install_bash_lsps() {
    if ! has_bash; then
        skip_lang "Bash"
        return
    fi
    info "Installing Bash LSPs..."
    install_pacman bash-language-server
}

# ─────────────────────────────────────────────────────────────
# Terraform LSPs
# ─────────────────────────────────────────────────────────────
install_terraform_lsps() {
    if ! has_terraform; then
        skip_lang "Terraform"
        return
    fi
    info "Installing Terraform LSPs..."
    install_pacman terraform-ls
}

# ─────────────────────────────────────────────────────────────
# LaTeX LSPs
# ─────────────────────────────────────────────────────────────
install_latex_lsps() {
    if ! has_latex; then
        skip_lang "LaTeX"
        return
    fi
    info "Installing LaTeX LSPs..."
    install_pacman texlab
}

# ─────────────────────────────────────────────────────────────
# Docker LSPs
# ─────────────────────────────────────────────────────────────
install_docker_lsps() {
    if ! has_docker; then
        skip_lang "Docker"
        return
    fi
    info "Installing Docker LSPs..."
    install_yay dockerfile-language-server
}

# ─────────────────────────────────────────────────────────────
# Ansible LSPs
# ─────────────────────────────────────────────────────────────
install_ansible_lsps() {
    if ! has_ansible; then
        skip_lang "Ansible"
        return
    fi
    if ! has_node; then
        warn "Ansible LSP requires npm, skipping"
        return
    fi
    info "Installing Ansible LSPs..."
    install_npm "@ansible/ansible-language-server"
}

# ─────────────────────────────────────────────────────────────
# SQL LSPs
# ─────────────────────────────────────────────────────────────
install_sql_lsps() {
    if ! has_sql; then
        skip_lang "SQL (psql/mysql/sqlite)"
        return
    fi
    info "Installing SQL LSPs..."
    install_pacman sqls
}

# ─────────────────────────────────────────────────────────────
# Generic config file LSPs (always install)
# ─────────────────────────────────────────────────────────────
install_generic_lsps() {
    info "Installing generic config LSPs (YAML, TOML, JSON, Markdown, XML)..."
    install_pacman yaml-language-server
    install_pacman taplo               # TOML
    install_pacman marksman            # Markdown
    install_yay lemminx                # XML
}

# ─────────────────────────────────────────────────────────────
# Main
# ─────────────────────────────────────────────────────────────
main() {
    echo "═══════════════════════════════════════════════════════════"
    echo "         LSP Installer for Arch Linux + Mise"
    echo "    (Only installs LSPs for detected languages)"
    echo "═══════════════════════════════════════════════════════════"
    echo
    
    # Language-specific LSPs
    install_c_lsps
    install_rust_lsps
    install_go_lsps
    install_python_lsps
    install_node_lsps
    install_java_lsps
    install_kotlin_lsps
    install_ruby_lsps
    install_php_lsps
    install_lua_lsps
    install_zig_lsps
    install_haskell_lsps
    install_elixir_lsps
    install_scala_lsps
    install_dotnet_lsps
    install_ocaml_lsps
    install_clojure_lsps
    install_nix_lsps
    install_bash_lsps
    install_terraform_lsps
    install_latex_lsps
    install_docker_lsps
    install_ansible_lsps
    install_sql_lsps
    
    echo
    # Always-useful LSPs for config files
    install_generic_lsps
    
    echo
    echo "═══════════════════════════════════════════════════════════"
    success "LSP installation complete!"
    echo "═══════════════════════════════════════════════════════════"
}

main "$@"