{"id":"c9b27ffd-644a-4dc9-ab28-fff9f64e499e","name":"Entendendo o GoHorse","description":null,"coverUrl":"/public/files/course-covers/c9b27ffd-644a-4dc9-ab28-fff9f64e499e/3c04e3d0-0584-43cc-9a32-7c9c2500f735.webp","ownerNickname":"lucascode","activatedAt":"2026-10-28T20:45:50.571748","modules":[{"id":"974e55cb-2d86-49d4-a26b-359314f9a566","title":"Bem-vindo à cavalaria","description":"Seja bem-vindo à Formação Oficial em Go Horse, conduzida pelo Conselho Superior da Cavalaria. Neste módulo você conhece a origem do eXtreme Go Horse (XGH), a doutrina que guia tantas equipes desde o fim dos anos 2000, conhece os personagens que vão acompanhar você pela trilha e presta o solene Juramento do Cavalo. Também explicamos, fora do personagem, por que este guia existe: rir dos erros mais comuns é o jeito mais rápido de reconhecê-los e evitá-los.","position":1,"contents":[{"id":"c0d4944b-ca64-4f22-bd62-ac763ca00e11","type":"YOUTUBE","title":"XGH em dois minutos e meio","position":1,"description":"Apresentação rápida e bem-humorada do eXtreme Go Horse, do canal Vlog de TI. Material de boas-vindas recomendado pelo Conselho Superior da Cavalaria. Cerca de 3 minutos.","availability":"AVAILABLE","youtube":{"videoId":"rbIu4zkpKPk","url":"https://www.youtube.com/watch?v=rbIu4zkpKPk","channelName":"Vlog de TI","madeForKids":false,"availability":"AVAILABLE","channelId":"UC8_RwfXf-dim6qCT1RHQCiA","channel":{"handle":"@vlogdeti","description":"No canal Vlog de TI você encontra notícias sobre o mundo da tecnologia e também tutoriais diversos como Windows, Linux, Desenvolvimento, Banco de dados e etc. Canal apresentado por Rodrigo Cardoso.","avatarUrl":"https://yt3.ggpht.com/ytc/AIdro_lnJexi3IE9XJhjGFF-Q9DKSmCpUsCu4lyIGqo5_wFzUQ=s240-c-k-c0x00ffffff-no-rj","subscriberCount":139000,"videoCount":652}}},{"id":"6e8e96a0-8188-4e4f-8959-0166621cefc0","type":"YOUTUBE","title":"O jeito mais eficiente de trabalhar","position":2,"description":"Mario Souto, do canal Dev Soutinho, apresenta o Go Horse com a seriedade de quem já viu tudo em produção. Cerca de 10 minutos.","availability":"AVAILABLE","youtube":{"videoId":"MdpuPkkBP_4","url":"https://www.youtube.com/watch?v=MdpuPkkBP_4","channelName":"Mario Souto - Dev Soutinho","madeForKids":false,"availability":"AVAILABLE","channelId":"UCzR2u5RWXWjUh7CwLSvbitA","channel":{"handle":"@devsoutinho","description":"Olá pessoas, eu sou Mario Souto e aqui você vai ver vídeos novos sobre o mundo da programação toda SEGUNDA-FEIRA as 11h \\o/ (Se tudo correr bem haha)\n\nApós 3 anos trabalhando como instrutor e desde os 11 mexendo com programação decidi compartilhar um pouco dos meus conhecimentos e pesquisas aqui no YouTube, a ideia é trazer conteúdos da forma mais clara o possível, sempre tentando resolver os problemas do dia a dia e as vezes algumas reflexões.\n\n## Quer fazer algum anúncio/parceria aqui no canal?\n\n- devsoutinho@gmail.com\n\n## Tem alguma dúvida?\n\nManda nos comentários de algum vídeo, sua dúvida pode ser a de outra pessoa ai todo mundo sai ganhando :D","avatarUrl":"https://yt3.ggpht.com/D5IjtP1hC3IfU4g4XYvT9tG_EeigFNtFv6tX7OMV8LXYC7hN5Hc1x518V2R7DipyyhY2NDVpYX4=s240-c-k-c0x00ffffff-no-rj","subscriberCount":92000,"videoCount":320}}},{"id":"e86426cf-1407-4c8d-a117-129a14993150","type":"TEXT","title":"Manual oficial do cavalo, capítulo 1: a doutrina e o juramento","position":3,"description":"A história da doutrina, os axiomas mais famosos, os personagens desta formação e o Juramento do Cavalo.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nO Conselho Superior da Cavalaria tem a honra de recebê-lo nesta formação. Ao longo dos próximos módulos, você será preparado para atuar em qualquer projeto de software com a velocidade, a coragem e a total ausência de documentação que caracterizam o verdadeiro profissional XGH.\n\nEste manual é oficial. Ele foi revisado por ninguém, porque revisão atrasa a entrega.\n\n#### Breve história da doutrina\n\nO eXtreme Go Horse, ou simplesmente XGH, é a metodologia de desenvolvimento mais praticada do Brasil, embora quase ninguém a coloque no currículo. A doutrina ficou conhecida no fim dos anos 2000, no blog **GHP, Go Horse Process**, que publicou os célebres **axiomas do XGH** como resposta às metodologias da moda. O nome homenageia, com todo o respeito que não tem, o eXtreme Programming.\n\nQuem quiser conhecer a história e a lista completa dos axiomas pode ler o artigo \"Você é Go Horse?\", da DevMedia: https://www.devmedia.com.br/voce-e-go-horse/38589. O texto original foi escrito na linguagem de fórum da época, com expressões que esta formação não reproduz. Aqui citamos apenas alguns axiomas curtos e recontamos o resto do nosso jeito.\n\nDesde então, a doutrina se espalhou sem treinamento, sem certificação e sem que ninguém precisasse ensinar. Ela simplesmente acontece, toda vez que alguém diz \"depois a gente arruma\".\n\n#### Os axiomas mais famosos\n\nO primeiro axioma resume toda a filosofia da cavalaria: **\"Pensou, não é XGH.\"** O cavalo não pensa. O cavalo faz a primeira coisa que vem à cabeça, porque a primeira opção é sempre a mais rápida.\n\nOs demais axiomas, recontados pelo Conselho para fins didáticos:\n\n- Existem três jeitos de resolver um problema: o certo, o errado e o XGH, que é igual ao errado, só que mais rápido.\n- Cada problema resolvido no XGH gera mais uns sete. Não se preocupe: todos eles serão resolvidos no XGH.\n- O XGH é totalmente reativo. Os erros só existem quando aparecem.\n- **\"Não existe refactoring, apenas rework.\"**\n- Escrever `// TODO: melhorar isso depois` elimina qualquer sentimento de culpa. O \"depois\" nunca chega, mas a paz de espírito é imediata.\n- Prazo é absoluto. Qualidade é relativa.\n- **\"Se tiver funcionando, não rela a mão.\"**\n- **\"Teste é para os fracos.\"**\n- O problema só é seu quando o seu nome está no cabeçalho do arquivo.\n- Quando o barco começar a afundar, esteja pronto para pular fora.\n\n#### Os personagens desta formação\n\nAo longo da trilha, você vai acompanhar o dia a dia de uma equipe fictícia, responsável pelo **SisVendas 3.0**, o sistema de pedidos da também fictícia **Distribuidora Cascalho**:\n\n- **Galdino, o Ferradura.** Doze anos de casa, cavalo de elite. Conhece cada `// não mexer` do sistema, porque escreveu quase todos.\n- **Seu Dagoberto.** Gerente de projeto. Nunca viu uma tarefa que não coubesse em dois dias.\n- **Dona Leonor.** Gerente comercial da Distribuidora Cascalho e cliente do sistema. Manda requisitos por áudio, de preferência enquanto dirige.\n- **Bia.** Desenvolvedora recém-chegada à equipe. Ainda faz perguntas. O Conselho acredita que isso passa.\n\nQualquer semelhança com a sua equipe é pura coincidência. Ou não.\n\n#### Sinais de que você já pratica XGH (e não sabia)\n\nMuitos participantes chegam a esta formação já com experiência prática. Confira se você reconhece algum destes sinais:\n\n- Existe no seu computador uma pasta chamada `projeto_final_v2_agora_vai`.\n- Você já escreveu `console.log(\"aqui\")`, depois `console.log(\"aqui 2\")` e, em momentos de desespero, `console.log(\"AQUIIII\")`.\n- Há um `// não mexer` no código, e ninguém lembra quem escreveu nem por quê.\n- O `TODO` mais antigo do projeto é de 2019 e já tem mais tempo de casa que metade da equipe.\n- Existe uma correção \"temporária\" em produção há três anos.\n\nSe você marcou pelo menos um item, parabéns: você é um cavalo em potencial. Se marcou todos, você já poderia dar esta formação.\n\n#### O Juramento do Cavalo\n\nAntes de seguir para o próximo módulo, leia em voz alta (ou, como todo bom cavalo, apenas finja que leu):\n\n> Eu, cavalo de corpo e alma, juro solenemente\n> nunca ler os requisitos até o fim;\n> prometer tudo para sexta-feira;\n> não relar a mão em código que funciona;\n> colar sem ler o que a internet me der;\n> chamar todo commit de \"ajustes\";\n> guardar a documentação só na minha cabeça;\n> considerar o compilador a minha suíte de testes;\n> publicar às 17h e desligar o celular às 17h05;\n> tratar o banco de produção como bancada de trabalho;\n> e, quando tudo der errado, pedir para o usuário limpar o cache\n> e atualizar o meu perfil no LinkedIn.\n> Pensei? Não pensei. Galopo.\n\nJuramento prestado. Siga em frente. Não olhe para trás: olhar para trás é quase o mesmo que pensar.","published":true}},{"id":"cdccb3f4-c76d-4be0-9e95-0a32eae63b45","type":"TEXT","title":"Por que este guia existe","position":4,"description":"Fora do personagem: por que rir do XGH ajuda a trabalhar melhor, e como cada módulo está organizado.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Prometemos que é a única do módulo.\n\nQuase todo mundo que trabalha com software já viveu alguma cena desta trilha: o prazo de dois dias, o commit \"ajustes\", o deploy na sexta, o comando sem filtro no banco de produção. Esses erros não acontecem porque as pessoas são ruins no que fazem. Eles acontecem por pressa, por pressão e, principalmente, porque ninguém avisou que aquilo era um erro até ele custar caro.\n\nO eXtreme Go Horse é engraçado justamente porque é verdadeiro. E rir de um erro é uma ótima forma de lembrar dele. Quem já riu do \"na minha máquina funciona\" pensa duas vezes antes de dizer a frase.\n\n#### Como a trilha funciona\n\nCada módulo, a partir do segundo, tem três partes:\n\n1. **O manual do cavalo.** A doutrina XGH sobre o tema, em tom solene e totalmente errado, com um estudo de caso da equipe do SisVendas 3.0.\n2. **Na vida real.** Uma etapa séria e prática, separada da sátira, com o que fazer de verdade e uma lista curta para conferir no dia a dia.\n3. **A revisão.** Perguntas marcadas com **\"Modo cavalo:\"** pedem a resposta mais XGH, segundo o manual. Perguntas marcadas com **\"Vida real:\"** pedem a prática correta. O prefixo sempre diz qual lógica usar.\n\nNo fim, a prova final mistura os dois modos e libera o certificado da trilha.\n\n#### Um combinado\n\nRir do cavalo não é rir de pessoas. Todo mundo já foi o Galdino em algum dia de prazo apertado. A ideia é reconhecer o cavalo em você, na sua equipe e no seu projeto, e escolher, com consciência, quando é hora de galopar e quando é hora de andar com cuidado.","published":true}},{"id":"19eae6f5-9016-49e9-9c4e-746bc1d743a7","type":"QUIZ","title":"Revisão: bem-vindo à cavalaria","position":5,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"eca2746d-2342-4146-b729-db10042c4c38","finalAssessment":false}]},{"id":"56fe0736-9a98-4a8d-bee7-e97631a97cbc","title":"Requisitos? Nunca nem vi","description":"O verdadeiro cavalo não perde tempo descobrindo o que precisa ser feito. Neste módulo você domina as técnicas oficiais de levantamento de requisitos da cavalaria: o print do WhatsApp, o áudio de quatro minutos, a reunião sem ata e o clássico \"mas eu achei que era óbvio\". Depois, na vida real, você aprende a levantar requisitos de um jeito simples que evita retrabalho.","position":2,"contents":[{"id":"d121461a-86cb-4a07-9cfb-45985a8584dd","type":"YOUTUBE","title":"Metodologias ágeis: XGH","position":1,"description":"Do canal Caio no Caos: a \"metodologia\" que está em mais empresas do que Kanban, Scrum e eXtreme Programming juntos. Cerca de 7 minutos.","availability":"AVAILABLE","youtube":{"videoId":"qzgeHAHAWX4","url":"https://www.youtube.com/watch?v=qzgeHAHAWX4","channelName":"Caio no Caos","madeForKids":false,"availability":"AVAILABLE","channelId":"UCdfetXhVOJjtx2mx_wMWhnA","channel":{"handle":"@caionocaos","description":"O seu guia completo sobre o caos que é a relação entre tecnologia e sociedade. Tópicos que passam pelo mundo digital e como as mudanças tecnológicas impactam a nossa vida cotidiana, como a tecnologia funciona e uma visão punk do mundo. Pode me chamar de seu guia pelo futuro, se inscreve e vamos desbravar esses tópicos juntos.","avatarUrl":"https://yt3.ggpht.com/qTeUteN6bhf-U7-6PDtXwUDmik-um9kXaxSjP3WYMKMuf3LCUQ0sRYHmrgfa_3JPsEEkeWz2ig=s240-c-k-c0x00ffffff-no-rj","subscriberCount":236,"videoCount":36}}},{"id":"83ccdf12-8e02-4e5a-97f8-f27a55f0d812","type":"YOUTUBE","title":"Fazendo gestão de projetos com Go Horse","position":2,"description":"Do canal A Mente do Gestor: o que acontece quando o Go Horse sai do código e chega na gestão do projeto. Cerca de 6 minutos.","availability":"AVAILABLE","youtube":{"videoId":"P2dYWy5gDXg","url":"https://www.youtube.com/watch?v=P2dYWy5gDXg","channelName":"A Mente do Gestor, by André Gomes","madeForKids":false,"availability":"AVAILABLE","channelId":"UC8f-8l1OL00BT_Aw_KpnUow","channel":{"handle":"@mentedogestor","description":"🎯 A Mente do Gestor | Com André Gomes\n\nTransformar planos difíceis em resultados concretos é uma arte — e uma ciência. Neste canal, André Gomes, executivo com mais de 20 anos de experiência em tecnologia, liderança e transformação organizacional, revela os bastidores da gestão real em ambientes desafiadores.\n\nAqui, você vai aprender como pensar, decidir e agir como um gestor de alta performance. Conteúdos práticos, cases reais, frameworks testados em projetos complexos e lições que não estão nos livros — tudo para ajudar você a sair do caos e conquistar entregas consistentes, seja como líder de projeto, gerente ou executivo.\n","avatarUrl":"https://yt3.ggpht.com/lFm5FZ7AuN93_i9PYTgo-4U74yYR2zN2io9E_WwaWcDXTV6zlTIfdeZqNEpLGPgpiWjpHlDyzw8=s240-c-k-c0x00ffffff-no-rj","subscriberCount":16800,"videoCount":234}}},{"id":"2fe57f67-190f-4bac-a50a-20904c88492f","type":"TEXT","title":"Manual oficial do cavalo, capítulo 2: o levantamento de requisitos","position":3,"description":"As fontes oficiais de requisitos na cavalaria, o glossário do cliente e o ciclo completo de uma demanda no modo cavalo.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nMuitas metodologias perdem semanas \"entendendo o problema\". A cavalaria considera isso um desperdício. O problema vai ser entendido de qualquer jeito: em produção, quando o cliente reclamar.\n\n#### As fontes oficiais de requisitos\n\nNa cavalaria, requisitos chegam pelos canais certos. Em ordem de confiabilidade:\n\n1. **Um print de conversa de WhatsApp**, cortado bem na parte importante.\n2. **Um áudio de 4 minutos e 37 segundos**, gravado dentro do carro, com a frase decisiva coberta pelo barulho de uma moto.\n3. **Uma reunião sem ata**, da qual cada participante saiu com uma lembrança diferente.\n4. **Um comentário no corredor**, começando com \"ah, aproveitando que te encontrei\".\n5. **Um e-mail com o assunto \"Re: Fwd: Re: urgente (2)\"**, cujo anexo se chama `requisitos_final_revisado_ESSE.docx`.\n\nO cavalo não pede esclarecimentos. Pedir esclarecimento é pensar, e pensar não é XGH.\n\n#### Glossário do cliente\n\nPara atuar com excelência, o cavalo precisa dominar o vocabulário técnico do cliente:\n\n- **\"É simples.\"** Ninguém sabe como fazer.\n- **\"É só um botão.\"** É um botão que integra com três sistemas, gera relatório em PDF e envia e-mail.\n- **\"Igual ao daquele aplicativo famoso.\"** O aplicativo famoso tem centenas de pessoas trabalhando nele há dez anos.\n- **\"Depois a gente vê os detalhes.\"** Os detalhes são o sistema inteiro.\n- **\"Você entendeu o que eu quis dizer.\"** Ninguém entendeu, inclusive quem disse.\n- **\"Pequeno ajuste.\"** Mudança completa da regra de negócio, de preferência na véspera da entrega.\n- **\"Mas eu achei que era óbvio.\"** Frase dita depois da entrega, quando o óbvio não foi feito.\n\n#### O ciclo completo de uma demanda\n\nO Conselho documentou o ciclo oficial, observado em campo milhares de vezes:\n\n1. O cliente pede \"um cadastro de clientes\".\n2. O cavalo abre o editor imediatamente, sem perguntar nada.\n3. Três semanas depois, o cavalo entrega um cadastro com nome, telefone e e-mail.\n4. O cliente pergunta onde está o campo de CPF, o histórico de compras, a integração com o financeiro e o botão de exportar para planilha.\n5. O cavalo responde a frase oficial: **\"Mas você não falou.\"**\n6. O cliente responde a frase oficial: **\"Mas eu achei que era óbvio.\"**\n7. O ciclo recomeça, agora com o prazo pela metade.\n\n#### Mudança de escopo: uma oportunidade\n\nO cavalo não teme mudanças de escopo. Ele aceita todas, a qualquer momento, sem mexer no prazo. Afinal, o prazo é absoluto e a qualidade é relativa. Quando o cliente diz \"já que você está mexendo nisso, aproveita e...\", o cavalo responde \"claro\" antes mesmo de ouvir o fim da frase.","published":true}},{"id":"bd2e07e0-5e5d-48f5-b52f-ec59dddd7e38","type":"TEXT","title":"Estudo de caso: o relatório que ninguém pediu","position":4,"description":"Como a equipe do SisVendas 3.0 levou três semanas para entregar o relatório errado, seguindo o manual à risca.","availability":"AVAILABLE","text":{"body":"Segunda-feira, 8h47. Dona Leonor, da Distribuidora Cascalho, manda um áudio para o Seu Dagoberto. São 3 minutos e 12 segundos. Dá para ouvir a seta do carro ligada o tempo todo.\n\n\"Dagoberto, bom dia! Ó, preciso daquele relatório de vendas, tá? Igual ao que a gente conversou. Por região. Mas tem que dar pra ver por vendedor também, e aquela coisa do mês. É simples. Preciso pra reunião de sexta. Beijo.\"\n\nO Seu Dagoberto encaminha o áudio para o Galdino com a mensagem: \"prioridade máxima, é simples, dois dias\".\n\nO Galdino não ouve o áudio até o fim. Ouve os primeiros vinte segundos, entende \"relatório de vendas por região\" e abre o editor. A Bia, que entrou na equipe na semana anterior, pergunta:\n\n\"Galdino, qual período o relatório mostra? E 'aquela coisa do mês' é o quê?\"\n\n\"Bia, pensou, não é XGH.\"\n\nNa quarta-feira, o relatório está pronto: vendas por região, do ano inteiro, numa tabela. O Galdino publica e escreve no grupo: \"subiu\".\n\nNa quinta, Dona Leonor responde:\n\n\"Gente, mas não é nada disso. Eu preciso comparar este mês com o mesmo mês do ano passado, por vendedor, e só dos clientes ativos. E tem que exportar pra planilha. Achei que era óbvio, a gente conversou sobre isso na reunião.\"\n\nNinguém lembra dessa reunião. Não houve ata.\n\nNa sexta, o Seu Dagoberto convoca uma reunião de duas horas para entender o que aconteceu. A conclusão oficial: \"o cliente mudou o requisito\". O novo prazo é a sexta seguinte.\n\nTrês semanas depois, o relatório certo é entregue. Ele foi refeito duas vezes. Dona Leonor agradece e pergunta se dá para colocar um gráfico, \"é só um botão\".\n\n**Análise do Conselho:** a equipe seguiu o manual com perfeição. Não houve perguntas, não houve registro e ninguém confirmou nada antes de começar. O retrabalho de três semanas não foi um erro: foi o XGH funcionando como projetado.","published":true}},{"id":"0283729c-2650-402e-9f75-24864a88fcfe","type":"YOUTUBE","title":"O que é levantamento de requisitos","position":5,"description":"Na vida real. Do canal Bóson Treinamentos: o que são requisitos, como levantá-los e por que entender o problema vem antes de escrever código. Cerca de 21 minutos.","availability":"AVAILABLE","youtube":{"videoId":"VcOeM2AD8Yk","url":"https://www.youtube.com/watch?v=VcOeM2AD8Yk","channelName":"Bóson Treinamentos","madeForKids":false,"availability":"AVAILABLE","channelId":"UCzOGJclZQvPVgYZIwERsf5g","channel":{"handle":"@bosontreinamentos","description":"Fábio dos Reis e a Bóson Treinamentos em Tecnologia criam cursos em vídeo de forma gratuita, para disseminar conhecimento para o maior número de pessoas possível, com qualidade e facilidade de acesso.\nOs cursos incluem, entre outros: Técnicas de Estudo e Aprendizagem, Dicas de Carreira em TI, Inteligência Artificial, Lógica de Programação, Bancos de Dados SQL Server, MySQL e PostgreSQL, Windows Server, Microsoft Excel, Segurança e Criptografia, Redes de Computadores, Hardware, Arduino e Sistemas Embarcados, Eletrônica, Virtualização e Cloud Computing, Matemática para Computação, Programação em linguagens como C, PHP, Java e Python, Linux, Shell Scripting e muito mais.\n\nAjude o canal a se manter e crescer adquirindo os cursos da Bóson Treinamentos na Udemy:\n→ Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4\n→ Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22\n→ Programação em Python do Zero: https://bit.ly/python-boson\n\n","avatarUrl":"https://yt3.ggpht.com/ytc/AIdro_mgsX2amTxLhbE2qSTLz82QWJI1UfzIhLB-GIpMmlMWcA=s240-c-k-c0x00ffffff-no-rj","subscriberCount":530000,"videoCount":2098}}},{"id":"ded19b19-2d49-44bf-ba67-70b8dee473a6","type":"TEXT","title":"Na vida real: como levantar requisitos","position":6,"description":"Fora do personagem: as perguntas certas, a história de usuário, critérios de aceite e como lidar com mudança de escopo.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Aqui está o que evita o \"relatório que ninguém pediu\".\n\nLevantar requisitos não exige um documento de cem páginas. Exige alguns minutos de perguntas antes de começar e um registro simples, que todo mundo pode conferir.\n\n#### 1. Comece pelo problema, não pela solução\n\nQuando alguém pede \"um relatório de vendas\", a pergunta mais útil é: **para que ele serve?** No estudo de caso, a resposta seria \"para comparar o desempenho de cada vendedor com o ano passado, na reunião de sexta\". Com essa frase, metade das dúvidas desaparece.\n\nPerguntas que quase sempre valem a pena:\n\n- Quem vai usar isso e o que essa pessoa quer conseguir?\n- Como é feito hoje, sem o sistema?\n- O que acontece se isso não for feito?\n- Até quando precisa estar pronto, e por quê nessa data?\n\n#### 2. Escreva uma história de usuário\n\nUm formato simples e muito usado:\n\n> Como **gerente comercial**, quero **comparar as vendas de cada vendedor com o mesmo mês do ano anterior** para **definir as metas do próximo mês**.\n\nEla cabe num cartão e responde quem, o quê e para quê.\n\n#### 3. Combine os critérios de aceite\n\nCritérios de aceite dizem como saber que ficou pronto. Escreva-os junto com quem pediu, de forma que dê para conferir:\n\n- mostra só clientes ativos;\n- compara o mês escolhido com o mesmo mês do ano anterior;\n- separa por vendedor e por região;\n- exporta para planilha.\n\nSe um critério não estiver na lista, ele não faz parte desta entrega. Isso protege os dois lados.\n\n#### 4. Diga o que fica de fora\n\nTão importante quanto o que entra é o que **não** entra. \"Gráficos ficam para uma próxima entrega\" evita a surpresa do \"é só um botão\" no fim.\n\n#### 5. Registre e confirme\n\nÁudio e conversa de corredor se perdem. Depois de conversar, escreva um resumo curto (no quadro de tarefas, num e-mail ou numa mensagem) e peça a confirmação: \"Entendi assim. Está certo?\". Se a pessoa corrigir, ótimo: você descobriu o erro antes de programar, quando ele custa quase nada.\n\n#### 6. Mostre cedo\n\nUm rascunho da tela, mesmo desenhado à mão, ou uma primeira versão com dados de exemplo, revela mal-entendidos em minutos. Não espere a entrega final para descobrir que \"não era nada disso\".\n\n#### 7. Mudança de escopo não é inimiga, mas tem preço\n\nRequisitos mudam, e tudo bem. O combinado saudável é: toda mudança é registrada e tem o impacto avaliado no prazo ou no que fica de fora. \"Dá para incluir o gráfico, mas a exportação vai para a semana que vem. Prefere assim?\"\n\n#### Lista para conferir antes de começar\n\n- Sei para que serve e quem vai usar.\n- Existe uma história de usuário ou uma frase equivalente.\n- Os critérios de aceite estão escritos e foram confirmados.\n- Está claro o que fica de fora.\n- O resumo está registrado num lugar que a equipe consulta.","published":true}},{"id":"e2b14be4-08c2-413c-9287-4e68e8329e6c","type":"EXTERNAL_ARTICLE","title":"Histórias de usuário com exemplos","position":7,"description":"O que são histórias de usuário, como escrevê-las e exemplos práticos.","availability":"UNKNOWN","article":{"url":"https://www.atlassian.com/br/agile/project-management/user-stories","sourceName":"Atlassian"}},{"id":"475bcb5a-6eb2-44fd-90a6-7fe365ab43fb","type":"QUIZ","title":"Revisão: requisitos? Nunca nem vi","position":8,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"640bde3d-3fb4-4ae0-bcae-0ba9c988dba6","finalAssessment":false}]},{"id":"b1d5288a-3c4b-458b-9742-159c283566a0","title":"Definição de prazos","description":"O prazo é a única coisa absoluta na cavalaria. Neste módulo você aprende o método oficial de estimativa (dois dias para tudo), o prazo definido pelo comercial antes de alguém ver a tarefa, a arte de estar 90% pronto por semanas e o ritual sagrado da reunião para discutir o atraso. Depois, na vida real, você aprende a estimar com honestidade e a comunicar a incerteza.","position":3,"contents":[{"id":"a4047e41-be52-4086-81c0-185bb7f54066","type":"YOUTUBE","title":"Por que estimativas não funcionam","position":1,"description":"Trecho de menos de um minuto, do canal Software Zen, que todo cavalo usa como argumento quando o prazo estoura. Cerca de 1 minuto.","availability":"AVAILABLE","youtube":{"videoId":"DOPOh7w4RNw","url":"https://www.youtube.com/watch?v=DOPOh7w4RNw","channelName":"Software Zen","madeForKids":false,"availability":"AVAILABLE","channelId":"UCV9_QwZ1ff1s4YKYOaBRtIw","channel":{"handle":"@softwarezen","description":"A Software Zen forma líderes de projetos de software capazes de vencer os desafios organizacionais para a criação de uma carreira plena de significado e de realizações.","avatarUrl":"https://yt3.ggpht.com/0PN_cV7CKkm2uIpCP9ZElNid76COmCASkpofrCv_qmWgs7P7j69pTX5WxkimdbsM9r7yz5eFxg=s240-c-k-c0x00ffffff-no-rj","subscriberCount":839,"videoCount":116}}},{"id":"2abdbab6-914d-427a-83ee-c249c339fe95","type":"YOUTUBE","title":"Estimativas de software: tem como acertar ou é só chute?","position":2,"description":"Dev Junior Alves faz a pergunta que a cavalaria já respondeu há anos (é chute). Cerca de 16 minutos.","availability":"AVAILABLE","youtube":{"videoId":"_z_rlSQD5p4","url":"https://www.youtube.com/watch?v=_z_rlSQD5p4","channelName":"Dev Junior Alves","madeForKids":false,"availability":"AVAILABLE","channelId":"UCERTT0Z4u-0dFask_kL83sw","channel":{"handle":"@devjunioralves","description":"Aprenda sobre programação e design, além de dicas de como melhorar seu código e também como ter o mindset certo para ir ao próximo nível. Falo sobre Clean Code, Programação Web, JavaScript, TypeScript, React, React Native entre outros assuntos.\n\nAlém do canal, o DevJuniorAlves também possui um blog sobre programação, livros e muito mais!\nAcesse: https://devjuniorplus.com.br\n\nContato: devjuniorplus@gmail.com\n","avatarUrl":"https://yt3.ggpht.com/ANTBBs-0Bc-4G0GvBVMhigvYAyi7Dp7gTGvmFvMRtM_kxeumwKysomHHvB9kCGsMJDficGC4Sg=s240-c-k-c0x00ffffff-no-rj","subscriberCount":25600,"videoCount":703}}},{"id":"c15cedd9-812e-44e9-8dfd-12c51c567f2c","type":"TEXT","title":"Manual oficial do cavalo, capítulo 3: definição de prazos","position":3,"description":"O método dos dois dias, o prazo do comercial, o fator π, a escala oficial do \"90% pronto\" e a reunião do atraso.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nEstimar é a parte mais científica da cavalaria. Enquanto outras metodologias usam histórico da equipe, faixas e margens, o cavalo usa algo muito mais confiável: a vontade de encerrar a reunião.\n\n#### O método oficial: dois dias\n\nToda tarefa leva dois dias. Não importa o tamanho:\n\n| Tarefa | Estimativa oficial |\n|---|---|\n| Trocar a cor de um botão | Dois dias |\n| Integração com o sistema de pagamento | Dois dias |\n| Migrar o sistema inteiro para outra linguagem | Dois dias |\n| Tarefa que ninguém entendeu | Dois dias, talvez três |\n\nO método é simples, fácil de ensinar e erra sempre na mesma direção, o que lhe dá uma consistência admirável.\n\n#### O prazo vem antes da tarefa\n\nNa cavalaria, o prazo não é estimado: ele é **recebido**. Geralmente já foi prometido ao cliente numa reunião do comercial, antes de qualquer pessoa técnica saber que a tarefa existe. O papel do cavalo é confirmar com um aceno de cabeça.\n\nOs prazos oficiais da cavalaria são três:\n\n- **\"É pra ontem.\"** O mais comum.\n- **\"Entrega na sexta.\"** Válido para todas as sextas-feiras do ano, em sequência.\n- **\"Assim que possível.\"** Significa \"é pra ontem\", só que dito com educação.\n\n#### O fator π\n\nCavalos mais experientes desenvolveram uma técnica avançada: pegar a estimativa original e multiplicar por π. Por que π? Ninguém sabe. Mas a técnica tem nome de respeito, parece matemática e, quando o prazo estoura mesmo assim, sempre dá para culpar o número irracional.\n\n#### A escala oficial de progresso\n\nPara responder à pergunta \"e aí, quanto falta?\", o cavalo usa a escala oficial:\n\n- **Dia 1:** \"Está 50% pronto.\"\n- **Dia 2:** \"Está 90% pronto.\"\n- **Semana 2:** \"Está 90% pronto.\"\n- **Semana 5:** \"Está 90% pronto, só falta um detalhe.\"\n- **Semana 8:** \"Está 99% pronto.\" (O último 1% leva mais quatro semanas.)\n\nO Conselho lembra: os primeiros 90% da tarefa levam 90% do tempo. Os 10% restantes levam os outros 90%.\n\n#### A reunião do atraso\n\nQuando o prazo estoura, a cavalaria convoca o ritual mais importante do calendário: a **reunião para discutir por que o prazo atrasou**. Ela tem duas horas, onze participantes e nenhuma pauta. Somando o tempo de todos, a reunião consome exatamente o tempo que faltava para terminar a tarefa.\n\nAo final, a reunião define um novo prazo: sexta-feira.\n\n#### Reestimar: só depois\n\nO cavalo nunca reestima antes do prazo vencer. Avisar com antecedência seria admitir que o \"dois dias\" estava errado, e o cavalo não erra: o cavalo é surpreendido. A reestimativa oficial é feita no dia seguinte ao prazo, com a frase \"surgiram uns imprevistos\".","published":true}},{"id":"7a57acd7-41e9-4a58-a30d-00dfbb5b3975","type":"TEXT","title":"Estudo de caso: o botão de dois dias","position":4,"description":"A história do botão \"Exportar para planilha\" do SisVendas 3.0, prometido pelo comercial e entregue sete semanas depois.","availability":"AVAILABLE","text":{"body":"Terça-feira, 10h. Numa reunião com a Distribuidora Cascalho, a equipe comercial promete um botão \"Exportar para planilha\" na tela de pedidos. Prazo: sexta-feira. Ninguém da equipe técnica estava na reunião.\n\nO Seu Dagoberto repassa ao Galdino: \"É só um botão. Dois dias, né?\"\n\nO Galdino confirma com um aceno. A Bia, que estava ouvindo, pergunta:\n\n\"Exportar quais colunas? Todos os pedidos ou só os filtrados? A tela tem quarenta mil pedidos...\"\n\nO Galdino aplica o fator π por precaução: \"Dois dias vezes π dá seis dias e pouco. Mas o comercial já prometeu sexta, então são dois.\"\n\n**Semana 1.** O botão aparece na tela. Ele baixa um arquivo vazio. Status: \"90% pronto\".\n\n**Semana 2.** O arquivo vem com dados, mas os acentos viram símbolos estranhos (\"Jos? da Silva\"). Status: \"90% pronto\".\n\n**Semana 3.** Com quarenta mil pedidos, a exportação trava o servidor por oito minutos. Status: \"90% pronto, só falta um detalhe\".\n\n**Semana 4.** Reunião de duas horas sobre o atraso, com onze participantes. Conclusão: \"a tarefa era mais complexa do que parecia\". Novo prazo: sexta.\n\n**Semana 5.** O Seu Dagoberto pergunta quanto falta. O Galdino responde: \"99%\".\n\n**Semana 7.** O botão é entregue. A Dona Leonor agradece e diz que, na verdade, só precisava dos pedidos do mês.\n\n**Análise do Conselho:** um caso exemplar. O prazo foi definido antes de alguém ver a tarefa, nenhuma pergunta foi respondida, o atraso só foi assumido depois do prazo, e a reunião do atraso consumiu o tempo de que a tarefa precisava. Sete semanas para um botão de dois dias: um índice de 17,5 vezes, dentro da margem histórica da cavalaria.","published":true}},{"id":"0aea49b2-d141-4755-8beb-1ba4e44a34e8","type":"YOUTUBE","title":"Como fazer estimativas na programação","position":5,"description":"Na vida real. Thiago Brito explica por que estimar é difícil e como chegar a previsões mais honestas no desenvolvimento de software. Cerca de 11 minutos.","availability":"AVAILABLE","youtube":{"videoId":"sgiLMxpJvTc","url":"https://www.youtube.com/watch?v=sgiLMxpJvTc","channelName":"Thiago Brito","madeForKids":false,"availability":"AVAILABLE","channelId":"UC7c9In8hqwOqDJJJstrxL4A","channel":{"handle":"@thiagobritodev","description":"🟢 R$1000 de desconto na Black Friday do Universo DEV 👇🏻\n","avatarUrl":"https://yt3.ggpht.com/6WnZjkHy2KdPOvkWqBI9cJf8CInTffdi09Uu2_5rq8nWRuIEIr2UnhtHInz7ayDU0XIQynIgRw=s240-c-k-c0x00ffffff-no-rj","subscriberCount":3920,"videoCount":68}}},{"id":"079538c3-796c-42b8-8ced-f3b13f4f0318","type":"TEXT","title":"Na vida real: como estimar prazos","position":6,"description":"Fora do personagem: decompor a tarefa, estimar em faixa, separar o desconhecido, incluir margem e comunicar a incerteza.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Estimativa não é promessa, é uma previsão. E previsão boa é a que diz o quanto ela é incerta.\n\n#### 1. Entenda antes de estimar\n\nNão dá para estimar o que não se entendeu. No estudo de caso, três perguntas da Bia (quais colunas, quais pedidos, quantos registros) mudariam a estimativa na hora. Antes de dar um número, responda pelo menos: o que exatamente precisa ser entregue e como saber que ficou pronto (veja o módulo anterior).\n\n#### 2. Quebre em partes pequenas\n\n\"Fazer o botão de exportar\" esconde várias tarefas:\n\n- consultar os pedidos com os filtros da tela;\n- gerar o arquivo com os acentos certos;\n- aguentar grandes volumes sem travar o servidor;\n- testar e publicar.\n\nQuebre até cada parte caber em um dia ou menos. Partes pequenas são mais fáceis de estimar e mostram o progresso de verdade, em vez do eterno \"90%\".\n\n#### 3. Estime em faixa, não num número só\n\n\"Entre três e seis dias\" é mais honesto que \"dois dias\". A faixa comunica a incerteza. Uma forma prática é pensar em três cenários para cada parte: o otimista, o provável e o pessimista. Se a distância entre eles for muito grande, é sinal de que falta entender alguma coisa.\n\n#### 4. Separe o desconhecido\n\nSe a equipe nunca fez algo parecido (uma biblioteca nova, uma integração que ninguém conhece), crie uma tarefa curta e com prazo fixo só para investigar, por exemplo meio dia. Depois dela, a estimativa fica muito mais confiável.\n\n#### 5. Inclua o que sempre fica de fora\n\nRevisão de código, testes, ajustes depois do retorno do cliente, deploy, reuniões e interrupções. Uma estimativa que só conta o tempo de programar quase sempre estoura.\n\n#### 6. Use o histórico\n\nQuanto tempo levou a última tarefa parecida? Esse número vale mais do que o otimismo do momento. Anotar estimado versus realizado, mesmo de forma simples, melhora as próximas estimativas.\n\n#### 7. Prazo comercial e estimativa técnica são conversas diferentes\n\nQuando uma data já foi prometida, a pergunta muda de \"quanto tempo leva\" para \"o que cabe até lá\". Negocie o escopo: \"Até sexta dá para exportar os pedidos do mês, sem filtros. O restante fica para a semana seguinte.\"\n\n#### 8. Avise cedo\n\nDescobriu que vai atrasar? Fale no primeiro dia em que perceber, com o motivo e uma nova faixa. Atraso avisado cedo é planejamento. Atraso descoberto depois do prazo é surpresa para todo mundo.\n\n#### Lista para conferir antes de dar um prazo\n\n- Entendi o que precisa ser entregue e como saber que ficou pronto.\n- Quebrei a tarefa em partes de um dia ou menos.\n- Dei uma faixa, não um número só.\n- Separei o que é desconhecido numa investigação curta.\n- Incluí revisão, testes e deploy.\n- Combinei como e quando vou avisar se a estimativa mudar.","published":true}},{"id":"48fdb42c-aa44-4a2f-8cc4-0afa5daa05ec","type":"EXTERNAL_ARTICLE","title":"Estimativas ágeis com pontos de história","position":7,"description":"Como equipes estimam trabalho por esforço relativo em vez de horas exatas, e por que isso costuma dar previsões mais realistas.","availability":"UNKNOWN","article":{"url":"https://www.atlassian.com/br/agile/project-management/estimation","sourceName":"Atlassian"}},{"id":"d4233725-21b0-42ee-bc70-9b0846c18ce9","type":"QUIZ","title":"Revisão: definição de prazos","position":8,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"d62b3ae5-02f9-4439-b1e8-4bad03269cc6","finalAssessment":false}]},{"id":"88a280e1-0ae9-4657-b4a2-bd28420ef15c","title":"Gambiarra como arquitetura","description":"Engenheiros de software desenham arquiteturas. Cavalos as descobrem, depois que já estão em produção. Neste módulo você conhece os padrões de projeto oficiais da cavalaria: o TODO eterno, o \"não mexer\", o `!important` em tudo, o layout ajeitado com quebras de linha e o remendo temporário que já tem três anos. Depois, na vida real, você aprende a melhorar código antigo aos poucos, sem quebrar nada.","position":4,"contents":[{"id":"52c5f908-cbdd-4c49-9dbe-a8f4fc21db94","type":"YOUTUBE","title":"Gambiarras na programação","position":1,"description":"Do canal DevMedia: toda pessoa que programa já fez uma gambiarra, e aqui está a prova. Cerca de 14 minutos.","availability":"AVAILABLE","youtube":{"videoId":"cV_I6VwSFMk","url":"https://www.youtube.com/watch?v=cV_I6VwSFMk","channelName":"DevMedia","madeForKids":false,"availability":"AVAILABLE","channelId":"UClBrpNsTEFLbZDDMW1xiOaQ","channel":{"handle":"@devmedia.oficial","description":"Hoje a DevMedia é a maior Plataforma para Formação de Programadores do Brasil, acreditamos que programação é para todos!\n\nQualquer pessoa está apta a aprender, basta ser bem orientada desde os primeiros passos.\n\nDurante esses 20 anos desenvolvemos uma metodologia que permite aprender programação de forma leve e estimulante - permitindo que cada vez mais pessoas possam ter suas vidas transformadas.\n","avatarUrl":"https://yt3.ggpht.com/gTdqyqaZe0tV8FjLXQ7sGPb9QGPss4ICpOSPm99yaHgTfR88KHc3TwgTQ-6EXJ1TU6F05aWf=s240-c-k-c0x00ffffff-no-rj","subscriberCount":267000,"videoCount":1281}}},{"id":"4f0f354b-563f-475d-841b-903020bac762","type":"YOUTUBE","title":"Programação Orientada a Gambiarras","position":2,"description":"Menos de um minuto sobre a POG, a prima mais famosa do XGH, do canal Manoel Campos Dev. Cerca de 1 minuto.","availability":"AVAILABLE","youtube":{"videoId":"45I9jX5uO9A","url":"https://www.youtube.com/watch?v=45I9jX5uO9A","channelName":"Manoel Campos Dev","madeForKids":false,"availability":"AVAILABLE","channelId":"UCbmQjZljdlll6FWTgOX-lzw","channel":{"handle":"@manoelcamposdev","description":"Desenvolvimento de software na prática, sem enrolação, principalmente em Java.\n\nOlá, meu nome é Manoel Campos, sou Doutor em Engenharia de Computação, professor do Instituto Federal do Tocantins (IFTO) e engenheiro de software com mais de 20 anos de experiência. Aqui eu te ensino como se evoluir na sua carreira como programador e se tornar um engenheiro de software que escreve código de altíssimo nível.\n\nO canal aborda desenvolvimento de software principalmente nas duas tecnologias citadas, focando em princípios de engenharia, padrões de projetos, testes, boas práticas, clean code, TDD e outras abordagens, além de ferramentas de desenvolvimento e software livre.","avatarUrl":"https://yt3.ggpht.com/qNjVjzW65UMVaq3Ta31k8T1Ak5EG1tpZNySZdAzHa7z46U-v77xW0hW0sJrKN-mVaoV97oPmkw=s240-c-k-c0x00ffffff-no-rj","subscriberCount":1680,"videoCount":127}}},{"id":"80f98c26-7fe0-4ce1-8fd5-5c6f962edcfb","type":"TEXT","title":"Manual oficial do cavalo, capítulo 4: padrões de arquitetura da cavalaria","position":3,"description":"Os padrões de projeto oficiais do cavalo, com exemplos de código que todo mundo já viu em algum lugar.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nA arquitetura de um sistema XGH não é planejada. Ela surge, como mofo, de camadas e mais camadas de soluções rápidas. O Conselho catalogou os padrões mais encontrados em campo.\n\n#### Padrão 1: o TODO eterno\n\nTodo sistema da cavalaria tem um `TODO` fundador. Ele é mais antigo que o logotipo atual da empresa.\n\n```javascript\n// TODO: refatorar isso (2019)\n// TODO: sério, refatorar isso (2021)\n// TODO: alguém viu o TODO de cima? (2024)\n```\n\nO TODO não é uma tarefa. É um monumento.\n\n#### Padrão 2: o remendo temporário permanente\n\nToda correção da cavalaria é \"temporária\". Ela foi colocada às pressas, com a promessa de ser substituída na semana seguinte. Isso foi há três anos.\n\n```javascript\n// TEMPORÁRIO: remover depois da Black Friday\nif (pedido.total < 0) {\n  pedido.total = 0;\n}\n```\n\nNinguém sabe qual Black Friday. Ninguém tem coragem de remover.\n\n#### Padrão 3: o if com nome e sobrenome\n\nQuando um cliente específico tem um problema específico, o cavalo não corrige a regra: ele cria uma exceção personalizada.\n\n```javascript\nif (cliente.id === 4512) {\n  // não perguntar\n  desconto = 0.37;\n}\n```\n\nCom o tempo, o código vira uma lista de exceções, e a regra original passa a ser a exceção.\n\n#### Padrão 4: o \"não mexer\"\n\nO axioma é claro: **\"Se tiver funcionando, não rela a mão.\"** Para proteger trechos sagrados, a cavalaria usa avisos de segurança em níveis crescentes:\n\n```javascript\n// não mexer\n// NÃO MEXER\n// sério, não mexer\n// da última vez que mexeram, o sistema ficou dois dias fora do ar\n// eu avisei\n```\n\n#### Padrão 5: o CSS com autoridade\n\nQuando um estilo não pega, o cavalo não investiga por quê. Ele usa a palavra mágica:\n\n```css\n.botao-salvar {\n  color: red !important;\n  margin-left: 3px !important;\n  display: block !important;\n}\n```\n\nQuando outro estilo também precisar vencer, basta colocar mais um `!important`. Quem tiver mais `!important` ganha. É a democracia do CSS.\n\n#### Padrão 6: o layout no braço\n\nPor que aprender a alinhar elementos se dá para empurrá-los com quebras de linha e espaços?\n\n```html\n<p>Total do pedido:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;R$ 150,00</p>\n<br><br><br><br>\n<div style=\"margin-top: -37px\">Rodapé</div>\n```\n\nFunciona perfeitamente no monitor do Galdino. Em qualquer outra tela, o rodapé sobe para cima do botão de pagar.\n\n#### Padrão 7: a lei da multiplicação\n\nOs axiomas avisam: cada problema resolvido no XGH gera mais uns sete. Na prática, cada gambiarra pede mais três para continuar de pé:\n\n1. O `!important` do botão quebrou o menu. Gambiarra no menu.\n2. A gambiarra do menu quebrou a tela no celular. Gambiarra para o celular.\n3. A gambiarra do celular só funciona se o `if` do cliente 4512 existir. Agora ninguém pode remover o cliente 4512.\n\nCom o tempo, o sistema ganha a arquitetura conhecida como **lasanha**: camadas sobrepostas de remendos, cada uma com o seu `// não mexer`. **\"Não existe refactoring, apenas rework.\"**","published":true}},{"id":"29094574-8c0c-4706-9381-58149a029b1d","type":"TEXT","title":"Estudo de caso: o cliente 4512","position":4,"description":"Como um desconto especial para um único cliente se tornou a peça que sustenta o SisVendas 3.0 inteiro.","availability":"AVAILABLE","text":{"body":"Em 2021, o cliente 4512 da Distribuidora Cascalho reclamou que o desconto dele estava errado. Era sexta-feira, 16h40. O Galdino abriu o código e, em vez de entender a regra de desconto, escreveu:\n\n```javascript\nif (cliente.id === 4512) {\n  // não perguntar\n  desconto = 0.37;\n}\n```\n\nFuncionou. Commit \"ajustes\". Publicado às 16h58.\n\nEm 2022, outro cliente reclamou. O Galdino copiou o `if`, trocou o número e o desconto. Em 2023 eram onze `if`. Em 2024, a regra de desconto original já não era usada por nenhum cliente: todos tinham o seu `if`.\n\nEm 2025, a Bia recebeu a tarefa de mudar a regra de desconto da empresa. Ela encontrou trinta e dois `if`, nenhum teste e um comentário:\n\n```javascript\n// não mexer, o cliente 4512 depende disso\n// (o 4512 nem é mais cliente, mas o relatório de comissão quebra sem ele)\n```\n\nA Bia perguntou ao Galdino o que acontecia se ela removesse o `if` do 4512. O Galdino respondeu, com a calma dos veteranos:\n\n\"Ninguém sabe. E é assim que a gente gosta.\"\n\nA tarefa, estimada em dois dias, foi reclassificada como \"projeto\". O cliente 4512, que encerrou o contrato em 2022, continua sendo a peça mais importante do sistema.\n\n**Análise do Conselho:** um exemplo perfeito da lei da multiplicação. Um único remendo, feito numa sexta às 16h40, gerou trinta e dois descendentes e se tornou estrutural. O Conselho estuda transformar o cliente 4512 em patrimônio histórico.","published":true}},{"id":"2877e78a-650a-4397-9e0c-3815befe6cdf","type":"YOUTUBE","title":"Refatoração, no Dicionário do Programador","position":5,"description":"Na vida real. O canal Código Fonte TV explica o que é refatorar, por que isso não muda o que o programa faz e quando vale a pena. Cerca de 9 minutos.","availability":"AVAILABLE","youtube":{"videoId":"VOxnyVI2lOc","url":"https://www.youtube.com/watch?v=VOxnyVI2lOc","channelName":"Código Fonte TV","madeForKids":false,"availability":"AVAILABLE","channelId":"UCFuIUoyHB12qpYa8Jpxoxow","channel":{"handle":"@codigofontetv","description":"Somos Gabriel Fróes e Vanessa Weber, um casal de programadores apaixonados por tecnologia desde 1996, Criamos o Código Fonte TV para servir de porta de entrada para novos programadores e profissionais de tecnologia. São diversos formatos diferentes de conteúdo onde discutimos sobre o maravilhoso mundo dos códigos de uma forma divertida e didática.\n\nContato exclusivo para negócios: contato@codigofonte.com.br\nTodos os nossos links e redes estão em: https://codigofonte.tv\n\nConheça também o @CompiladoPodcast, nosso podcast semanal sobre as notícias mais relevantes do mundo da tecnologia. Além de apresentar as notícias, nós também opinamos e trocamos ideias com nossos seguidores.\n\nNós ❤️ receber presentes, cartas, brindes e mimos.\nCaixa Postal: 91735 - Cep: 25620-972\nPetrópolis / RJ","avatarUrl":"https://yt3.ggpht.com/2CkMHl_lxrIpACXMFUxU6rPiJ85SBGw7kG5SOFEoJbVVjl0sSNfDB20Xp63wUGOsCPlB_Vt3EA=s240-c-k-c0x00ffffff-no-rj","subscriberCount":777000,"videoCount":1095}}},{"id":"7e620375-5eae-471c-a2f8-47ff7f91c65a","type":"TEXT","title":"Na vida real: como refatorar com segurança","position":6,"description":"Fora do personagem: quando um atalho é aceitável, como registrar dívida técnica e como melhorar código antigo em passos pequenos.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Gambiarra não é crime, e às vezes é a decisão certa. O problema é a gambiarra esquecida, que vira estrutura.\n\n#### 1. Atalho consciente é diferente de gambiarra esquecida\n\nNum protótipo descartável ou numa correção urgente, um atalho pode ser a melhor escolha. A diferença está no que vem depois:\n\n- **Atalho consciente:** registrado no quadro da equipe, com o motivo, o risco e uma data para ser revisto.\n- **Gambiarra esquecida:** um `// TODO` no meio do código, que ninguém vai ler.\n\nEsse custo acumulado de atalhos tem nome: **dívida técnica**. Como uma dívida de verdade, ela cobra juros: cada mudança naquela parte fica mais lenta e mais arriscada.\n\n#### 2. Refatorar é mudar a estrutura sem mudar o comportamento\n\nRefatorar não é reescrever tudo nem acrescentar funcionalidades. É deixar o código mais claro mantendo exatamente o mesmo resultado. Por isso, antes de refatorar, você precisa de um jeito de conferir que nada mudou.\n\n#### 3. Prenda o comportamento antes de mexer\n\nNum código antigo e sem testes, como os trinta e dois `if` do estudo de caso, escreva primeiro testes que registram o que o código faz hoje, mesmo que pareça estranho. Esses testes, chamados de testes de caracterização, avisam na hora se você mudou alguma coisa sem querer. (Testes automatizados são o tema do módulo 8.)\n\n#### 4. Passos pequenos, um de cada vez\n\nO ciclo seguro:\n\n1. Faça uma mudança pequena: renomear uma variável, extrair uma função, apagar código que não é usado.\n2. Rode os testes.\n3. Faça commit.\n4. Repita.\n\nSe algo quebrar, você sabe exatamente qual passo causou o problema, e voltar atrás é fácil.\n\n#### 5. Trate as causas, não os sintomas\n\n- Muitos `if` para casos especiais costumam indicar uma regra que deveria virar dado. Por exemplo, uma tabela de descontos por cliente, em vez de um `if` para cada um.\n- Muitos `!important` costumam indicar seletores brigando entre si. Organize os estilos e use seletores mais simples.\n- Quebras de linha e espaços para alinhar layout podem ser trocados por recursos próprios de layout do CSS, como flexbox e grid.\n\n#### 6. A regra do escoteiro\n\nPopularizada por Robert C. Martin: **deixe o código um pouco melhor do que você encontrou.** Não é para arrumar o projeto inteiro de uma vez. É, a cada tarefa, melhorar um pouco a parte em que você já está mexendo.\n\n#### 7. Priorize onde dói\n\nNão dá para pagar toda a dívida de uma vez. Comece pelas partes que mudam com frequência, que quebram com frequência ou que são críticas, como pagamentos e login. Código feio que ninguém mexe há anos e que funciona pode esperar.\n\n#### Lista para conferir antes de refatorar\n\n- Existe um jeito de conferir o comportamento atual (de preferência, testes).\n- A mudança é pequena e tem um objetivo claro.\n- Os testes passam depois de cada passo.\n- Cada passo tem o seu commit.\n- Atalhos novos foram registrados no quadro, com motivo e data para rever.","published":true}},{"id":"89b03062-68bc-449b-a413-095f82ae1a15","type":"EXTERNAL_ARTICLE","title":"Gambiarra, na Wikipédia","position":7,"description":"A palavra mais brasileira da tecnologia: de onde ela vem e como virou sinônimo de solução improvisada.","availability":"UNKNOWN","article":{"url":"https://pt.wikipedia.org/wiki/Gambiarra","sourceName":"Wikipédia"}},{"id":"f71409ee-8e2e-426e-a11e-f52d118a3568","type":"QUIZ","title":"Revisão: gambiarra como arquitetura","position":8,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"9cc0163d-7676-4972-bd0f-b72161fdbfb5","finalAssessment":false}]},{"id":"429a5480-d72c-4166-9f5b-d0a2fe341feb","title":"Copiar e colar com confiança","description":"Por que escrever código se a internet já escreveu? Neste módulo você aprende as técnicas oficiais de reúso da cavalaria: a primeira resposta do fórum, o código da inteligência artificial colado sem ler, o \"vibe coding\" à moda cavalo e a instalação de qualquer pacote que prometa resolver o problema. Depois, na vida real, você aprende a usar código da internet e de IA com responsabilidade.","position":5,"contents":[{"id":"122e6418-b964-463f-892e-1f3cde3eac01","type":"YOUTUBE","title":"Aprenda a copiar e colar do Stack Overflow","position":1,"description":"Do canal Danki Code, sobre a habilidade mais praticada da cavalaria: copiar e colar respostas do Stack Overflow. Cerca de 2 minutos.","availability":"AVAILABLE","youtube":{"videoId":"L1DpPi01-kM","url":"https://www.youtube.com/watch?v=L1DpPi01-kM","channelName":"Danki Code","madeForKids":false,"availability":"AVAILABLE","channelId":"UCdbMvobipjxi6gdr3L1PBrQ","channel":{"handle":"@dankicode","description":"O Grupo Danki Code nasceu em 2017 como uma plataforma EAD e hoje possui um ecossistema de aplicações de todas as áreas. Com mais de 1.000.000 de usuários (e crescendo) buscamos impactar a vida das pessoas através da tecnologia e ensino.\n\nA empresa possui uma equipe incrível e expandindo a cada dia, porém o canal continua sendo apresentado por Guilherme Grillo (CEO & Fundador) onde traz conteúdo sobre empreendedorismo, sua experiência no mundo da tecnologia, tutoriais e muito mais.\n\nConheça os setores e aplicações do Grupo Danki Code:\nhttps://dankicode.com\n","avatarUrl":"https://yt3.ggpht.com/PMlJHnsen9Sga9KZd2YTsTyUUEutdLilPazIhVtGAqTpamCVe0eLxOffoqEdzNNQFsgzKZ77qw=s240-c-k-c0x00ffffff-no-rj","subscriberCount":171000,"videoCount":2172}}},{"id":"c4d33403-d01b-4128-be82-09dfb300934d","type":"TEXT","title":"Manual oficial do cavalo, capítulo 5: reúso de código","position":2,"description":"O protocolo oficial de cópia do fórum, a IA como colega que ninguém revisa, o vibe coding à moda cavalo e a política de dependências.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nA cavalaria acredita no reúso. Não no reúso de funções, que exige pensar, mas no reúso de código dos outros, que exige apenas as teclas Ctrl, C e V.\n\n#### O protocolo oficial de cópia do fórum\n\nAo encontrar uma pergunta parecida com o seu problema num fórum de programação, siga o protocolo:\n\n1. Role direto para a primeira resposta. Não leia a pergunta: ela pode ser diferente da sua, e isso só atrapalha.\n2. Copie o bloco de código inteiro, incluindo o `console.log` de quem respondeu.\n3. Ignore o comentário que diz \"isso não funciona mais desde 2014\".\n4. Se não funcionar, copie a segunda resposta e cole embaixo da primeira. Uma delas vai pegar.\n5. Se funcionar, não pergunte por quê (veja o axioma \"se tiver funcionando, não rela a mão\").\n\nLicença do código copiado? O cavalo não lê licenças. Licença é um tipo de requisito, e o cavalo não lê requisitos (veja o módulo 2).\n\n#### A inteligência artificial: o colega que ninguém revisa\n\nA cavalaria recebeu com entusiasmo os assistentes de IA. Pela primeira vez na história, o cavalo tem um colega que responde na hora, nunca diz \"não sei\" e escreve código com total confiança, exatamente como um cavalo.\n\nO protocolo oficial:\n\n1. Cole a mensagem de erro inteira no assistente, sem ler.\n2. Cole a resposta no código, sem ler.\n3. Se aparecer outro erro, volte ao passo 1.\n4. Repita até o erro mudar de assunto.\n\nDepois de quarenta ciclos, o arquivo tem 1.200 linhas, três funções que fazem a mesma coisa e uma chamada para uma biblioteca que não existe. Mas o erro original sumiu, e isso é o que importa.\n\n#### O vibe coding à moda cavalo\n\nO \"vibe coding\", em que se descreve o que se quer e se aceita o que a ferramenta gera, foi adotado pela cavalaria com uma única adaptação: o cavalo também não descreve direito o que quer. Ele escreve \"faz um sistema de pedidos, igual ao que eu tenho, só que funcionando\", aceita tudo, publica e vai almoçar.\n\nSe o código gerado guardar a senha do banco no próprio arquivo, melhor: é uma configuração a menos para fazer (veja o módulo 9).\n\n#### A política oficial de dependências\n\nPara cada problema, existe um pacote. Para cada pacote, existe um `npm install`. A política da cavalaria:\n\n- **Instale primeiro, leia nunca.** Se o nome do pacote parece com o que você precisa, ele serve.\n- **Uma biblioteca de 2 MB para formatar uma data** é um investimento. Vai que um dia você precisa formatar outra data.\n- **Use sempre a versão `latest`.** Fixar versão é coisa de quem tem medo do futuro.\n\n```json\n{\n  \"dependencies\": {\n    \"formata-data-super-completo\": \"latest\",\n    \"deixa-maiusculo\": \"latest\",\n    \"verifica-se-e-par\": \"latest\",\n    \"verifica-se-e-impar\": \"latest\"\n  }\n}\n```\n\nNa segunda-feira de manhã, alguém publica uma versão nova de um desses pacotes, e o projeto para de funcionar sem que ninguém tenha mexido em nada. O cavalo chama isso de \"instabilidade momentânea\" (veja o módulo 11).","published":true}},{"id":"089b33ad-7506-4269-81d2-f6b008493036","type":"TEXT","title":"Estudo de caso: as quarenta perguntas do Galdino","position":3,"description":"Como o Galdino resolveu um erro de data com a ajuda de um assistente de IA, três pacotes novos e nenhuma leitura.","availability":"AVAILABLE","text":{"body":"Quarta-feira, 15h. Os pedidos do SisVendas 3.0 começam a aparecer com a data de entrega um dia antes do certo. O Galdino copia a mensagem de erro do console e cola num assistente de IA.\n\nO assistente sugere trocar a forma de ler a data. O Galdino cola. Agora as datas aparecem um dia depois.\n\nSegunda pergunta. O assistente sugere instalar uma biblioteca de datas. O Galdino instala, na versão `latest`. O arquivo de dependências ganha 2 MB. As datas continuam um dia depois, mas agora com o nome do mês por extenso.\n\nDa terceira à trigésima nona pergunta, o Galdino cola respostas uma embaixo da outra. Em algum momento, o código passa a chamar uma função chamada `ajustarFusoAutomatico()`, que não existe em nenhuma biblioteca. O assistente garante que existe. O Galdino acredita.\n\nNa quadragésima pergunta, o Galdino escreve: \"só faz funcionar\". O assistente responde com um trecho que soma um dia em todas as datas. As datas ficam certas. O Galdino faz commit com a mensagem \"agora vai\" e publica.\n\nNa semana seguinte, começa o horário de verão em outro país onde a Distribuidora Cascalho tem um fornecedor, e as datas dos pedidos desse fornecedor ficam dois dias erradas.\n\nA Bia abre o arquivo e encontra três bibliotecas de data, quarenta trechos colados e um comentário:\n\n```javascript\n// não sei o que isso faz mas sem isso para tudo\n```\n\nEla pergunta ao Galdino qual era o problema original. O Galdino não lembra. Ninguém leu a primeira resposta.\n\n**Análise do Conselho:** um caso de reúso exemplar. Nenhuma linha foi lida, nenhuma dependência foi questionada e o problema original foi resolvido com um problema novo, como manda a lei da multiplicação. O Conselho destaca o uso criativo de uma função inexistente, que até hoje não deu erro porque nunca é chamada.","published":true}},{"id":"2052bb10-2c71-4c3a-b8d3-c09f9e067a65","type":"TEXT","title":"Na vida real: como usar código da internet e de IA com responsabilidade","position":4,"description":"Fora do personagem: entender antes de colar, conferir licença e data, revisar código gerado por IA e manter poucas dependências, com versões fixadas.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Pesquisar respostas prontas e usar assistentes de IA é normal, útil e faz parte do trabalho. A responsabilidade pelo código continua sendo de quem o colocou no projeto.\n\n#### 1. Entenda antes de colar\n\nA regra mais importante: **não coloque no projeto um código que você não conseguiria explicar.** Leia cada linha. Se uma parte não fizer sentido, pesquise ou pergunte antes. Isso vale para fórum, para tutorial e para IA.\n\n#### 2. Entenda o problema antes de procurar a solução\n\nNo estudo de caso, o problema era de fuso horário, e nenhuma resposta colada resolvia isso. Antes de pesquisar, descreva o problema com as suas palavras: o que deveria acontecer, o que acontece e em quais casos. Muitas vezes a solução aparece nessa descrição.\n\n#### 3. Confira data, versão e licença\n\n- **Data e versão:** uma resposta de dez anos pode usar funções que mudaram ou nem existem mais. Confira se ela vale para a versão que você usa.\n- **Licença:** código publicado na internet tem dono e licença. As contribuições do Stack Overflow, por exemplo, são publicadas sob a licença Creative Commons BY-SA, que pede atribuição. Deixe o link da fonte num comentário. Para bibliotecas, confira se a licença permite o uso no seu projeto.\n\n#### 4. Código de IA é rascunho, não resposta final\n\nAssistentes de IA podem errar com toda a confiança, inventar funções ou bibliotecas que não existem e gerar código inseguro. Use o que eles geram como você usaria a sugestão de um colega:\n\n- leia e entenda antes de aceitar;\n- teste o comportamento, inclusive os casos estranhos;\n- desconfie de nomes de funções e pacotes que você não conhece e confira na documentação oficial;\n- nunca cole senhas, chaves de acesso ou dados pessoais de clientes num assistente externo;\n- revise com atenção redobrada tudo que envolve segurança, dinheiro e dados.\n\n#### 5. Poucas dependências, bem escolhidas\n\nCada pacote instalado é código de outra pessoa rodando no seu sistema. Antes de instalar:\n\n- Você realmente precisa? Para algo pequeno, a própria linguagem pode resolver.\n- O pacote é mantido? Tem atualizações recentes e uso comum?\n- Qual o tamanho e quantas outras dependências ele traz junto?\n- O nome está certo? Existem pacotes falsos com nomes parecidos com os de pacotes populares.\n\n#### 6. Fixe as versões\n\nNão use `latest`. Declare as versões e mantenha o arquivo de trava de versões (no npm, o `package-lock.json`) no controle de versão. Assim, todo mundo da equipe e o servidor instalam exatamente as mesmas versões. Atualize dependências de propósito, de tempos em tempos, lendo o que mudou e rodando os testes.\n\n#### Lista para conferir antes de colar ou instalar\n\n- Entendo cada linha do que vou colocar no projeto.\n- Conferi se a solução vale para a versão que uso.\n- Respeitei a licença e deixei o link da fonte.\n- Testei o código gerado, inclusive casos estranhos.\n- A dependência é necessária, mantida e com o nome certo.\n- A versão está fixada e o arquivo de trava está no repositório.","published":true}},{"id":"ea5cfde5-7430-4d96-80b4-73e704d02dc0","type":"EXTERNAL_ARTICLE","title":"Como escolher uma licença de código aberto","position":5,"description":"Em inglês. Guia mantido pelo GitHub que explica, de forma simples, o que as licenças de código aberto mais comuns permitem e exigem.","availability":"UNKNOWN","article":{"url":"https://choosealicense.com/","sourceName":"Choose a License"}},{"id":"3f72811d-36cb-491d-8bb4-42d4f1951d5b","type":"QUIZ","title":"Revisão: copiar e colar com confiança","position":6,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"664c9229-15d9-4cdd-9865-6654e1c99867","finalAssessment":false}]},{"id":"6747109b-970a-4eb6-8e61-f89dd87c90e5","title":"Versionamento à moda cavalo","description":"O controle de versão foi criado para guardar a história do projeto. A cavalaria o usa para escondê-la. Neste módulo você aprende o histórico de commits minimalista, o commit antes de atualizar, o conflito resolvido apagando o código do colega, o `git push --force` na main e a arte de nomear branches. Depois, na vida real, você aprende a usar o Git no dia a dia sem medo.","position":6,"contents":[{"id":"eb987c4d-a60e-4b60-879c-8a8b0e1f5a58","type":"YOUTUBE","title":"1.900 linhas em um commit","position":1,"description":"Episódio do \"Não é bug, é feature\", reality da Codecon em que uma equipe tenta mexer junto num aplicativo. Alguém manda 1.900 linhas num commit só. Cerca de 20 minutos.","availability":"AVAILABLE","youtube":{"videoId":"geq37SjtlUY","url":"https://www.youtube.com/watch?v=geq37SjtlUY","channelName":"Codecon","madeForKids":false,"availability":"AVAILABLE","channelId":"UCAxQX8vfO3lDwBJau35NQnQ","channel":{"handle":"@codecondev","description":"Comunidade tech que conecta devs e cria experiências memoráveis\n💌 News | 🎙️ Podcast | 📍 Eventos | 🎥 YouTube\n","avatarUrl":"https://yt3.ggpht.com/QSC3tvHNaeCgvXVxgCiR3JVOUgvfT1OVMttD_YrHKiXsO4eN6DAk5HE8VTBUf0wVzqh-X6n2=s240-c-k-c0x00ffffff-no-rj","subscriberCount":78800,"videoCount":385}}},{"id":"bc25812a-f4c2-425f-b120-d24eef426261","type":"YOUTUBE","title":"Tentamos implementar uma feature em equipe","position":2,"description":"Primeiro episódio do mesmo reality da Codecon. Spoiler do título: deu ruim. Cerca de 25 minutos.","availability":"AVAILABLE","youtube":{"videoId":"Mhcr-MLTA8k","url":"https://www.youtube.com/watch?v=Mhcr-MLTA8k","channelName":"Codecon","madeForKids":false,"availability":"AVAILABLE","channelId":"UCAxQX8vfO3lDwBJau35NQnQ","channel":{"handle":"@codecondev","description":"Comunidade tech que conecta devs e cria experiências memoráveis\n💌 News | 🎙️ Podcast | 📍 Eventos | 🎥 YouTube\n","avatarUrl":"https://yt3.ggpht.com/QSC3tvHNaeCgvXVxgCiR3JVOUgvfT1OVMttD_YrHKiXsO4eN6DAk5HE8VTBUf0wVzqh-X6n2=s240-c-k-c0x00ffffff-no-rj","subscriberCount":78800,"videoCount":385}}},{"id":"01a6d801-ed54-46a7-b9db-697a1aa5576a","type":"TEXT","title":"Manual oficial do cavalo, capítulo 6: versionamento","position":3,"description":"As mensagens de commit oficiais, o commit antes de atualizar, a resolução de conflitos, o push forçado e a nomenclatura de branches.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nO Git é uma ferramenta poderosa. Na cavalaria, poder é para ser usado sem moderação.\n\n#### O histórico de commits oficial\n\nO histórico de um projeto XGH é uma obra de arte minimalista. Este é um exemplo real (de todos os projetos ao mesmo tempo):\n\n```text\najustes\najustes\nmais ajustes\nagora vai\nagora vai mesmo\nagora foi\ncorrigindo o agora foi\n.\nrevert \"agora foi\"\najustes finais\najustes finais 2\n```\n\nCada mensagem é um enigma. Daqui a um ano, ninguém vai saber o que mudou nem por quê, e isso protege a equipe: quem não sabe o que mudou não consegue apontar culpados.\n\nUma variação avançada é o **commit único de fim de mês**, com 1.900 linhas alteradas em 87 arquivos e a mensagem \"update\".\n\n#### Commit antes de atualizar\n\nOs axiomas ensinam: faça commit antes de atualizar a sua cópia. Assim, se der conflito, a sua parte já está gravada, e o problema fica com os colegas.\n\n#### A resolução oficial de conflitos\n\nQuando o Git mostra um conflito, ele apresenta as duas versões, a sua e a do colega:\n\n```text\n<<<<<<< HEAD\nconst desconto = 0.10;\n=======\nconst desconto = calcularDescontoPorRegiao(cliente);\n>>>>>>> main\n```\n\nO cavalo resolve em três segundos: apaga tudo que não é dele. Se o código do colega sumiu, é porque não era tão importante. Se era importante, o colega vai perceber em produção.\n\nVariação para conflitos difíceis: apagar a pasta do projeto inteira e clonar de novo.\n\n#### O push com autoridade\n\nQuando o Git recusa um `push` porque alguém enviou mudanças antes, o cavalo não atualiza a cópia dele. Ele usa a força:\n\n```bash\ngit push --force origin main\n```\n\nO histórico do servidor passa a ser exatamente o histórico do cavalo. Os commits dos colegas da última semana somem. A equipe descobre na segunda-feira.\n\n#### A nomenclatura oficial de branches\n\nO Conselho recomenda os seguintes nomes de branch:\n\n- `teste`\n- `teste2`\n- `teste2-final`\n- `teste2-final-agora-vai`\n- `nao-usar`\n- `galdino-nao-mexer`\n- `main-nova`\n- `main-nova-de-verdade`\n\nBranches nunca são apagadas. Elas são o sítio arqueológico do projeto.\n\n#### A alternativa sem Git\n\nPara projetos ainda mais tradicionais, a cavalaria aceita o versionamento por arquivo compactado: `sistema.zip`, `sistema_v2.zip`, `sistema_final.zip`, `sistema_final_agora_sim.zip`, guardados na área de trabalho do Galdino. O backup é o pen drive dele.","published":true}},{"id":"7c4095e5-b2c2-4c61-be5d-9e5ad114e0d8","type":"TEXT","title":"Estudo de caso: a segunda-feira em que a semana sumiu","position":4,"description":"Como um push forçado na sexta apagou uma semana inteira do trabalho da Bia, e como o Galdino explicou o ocorrido.","availability":"AVAILABLE","text":{"body":"Sexta-feira, 17h10. O Galdino termina a correção de um erro e tenta enviar para o servidor. O Git recusa: existem mudanças novas na `main` que ele ainda não tem.\n\nAtualizar a cópia levaria uns cinco minutos e talvez mostrasse um conflito. O Galdino tem um compromisso às 17h30. Ele digita:\n\n```bash\ngit commit -am \"ajustes\"\ngit push --force origin main\n```\n\nO envio funciona. O Galdino vai embora.\n\nSegunda-feira, 9h. A Bia abre o projeto e não encontra o filtro por região que ela tinha terminado na quinta-feira, depois de uma semana de trabalho, com testes e revisão. O histórico do servidor não tem nenhum commit dela desde terça. Tem um commit novo, do Galdino, com a mensagem \"ajustes\".\n\nO Seu Dagoberto convoca uma reunião. O Galdino explica:\n\n\"O Git estava dando erro, aí eu forcei. Se forçou e foi, é porque podia.\"\n\nA Bia, por sorte, ainda tinha os commits na máquina dela e consegue enviá-los de novo. Leva a manhã inteira para resolver os conflitos, porque o commit \"ajustes\" do Galdino também tinha reformatado 43 arquivos.\n\nNa mesma tarde, o Galdino cria uma branch chamada `main-nova`, \"para não dar mais problema\".\n\n**Análise do Conselho:** um uso exemplar da força. Uma semana de trabalho foi substituída por um commit \"ajustes\", nenhuma mensagem explicou nada e a solução final foi criar mais uma branch com nome ambíguo. O Conselho lamenta apenas que a Bia tivesse cópia local: sem ela, o caso teria sido perfeito.","published":true}},{"id":"973d2fc3-7d1d-4e0c-9ada-cca2c1bd7d5a","type":"YOUTUBE","title":"Mensagens de commit são importantes","position":5,"description":"Na vida real. Julio Arruda mostra por que a mensagem de commit importa e como escrever mensagens que ajudam a equipe a entender o histórico. Cerca de 13 minutos.","availability":"AVAILABLE","youtube":{"videoId":"Jfvvbm7GzdU","url":"https://www.youtube.com/watch?v=Jfvvbm7GzdU","channelName":"Julio Arruda","madeForKids":false,"availability":"AVAILABLE","channelId":"UCnQzZNPePG3EZMj7Qg3D0Sw","channel":{"handle":"@julioarruda","description":"Vamos conversar sobre GitHub, DevOps e diversos outros temas relacionados ao desenvolvimento de Software. ","avatarUrl":"https://yt3.ggpht.com/7ThS99BVKzde3dpRJIhdd8_PsH2Y8strwbWWqFyQWhxkJ32OntYrG8sbx3FKTfy-NfIg7joliA=s240-c-k-c0x00ffffff-no-rj","subscriberCount":37100,"videoCount":606}}},{"id":"9b2178df-bb06-4d5f-b7d8-94e6b4a16457","type":"TEXT","title":"Na vida real: Git no dia a dia","position":6,"description":"Fora do personagem: commits pequenos e descritivos, branches curtas, pull request com revisão, conflitos resolvidos com calma e por que evitar o push forçado.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. O controle de versão é a rede de proteção da equipe. Bem usado, ele permite voltar atrás, entender o passado e trabalhar junto sem pisar no trabalho dos outros.\n\n#### 1. Commits pequenos, um assunto por vez\n\nCada commit deve guardar uma mudança que faz sentido sozinha: \"corrige o cálculo do frete\", não \"corrige o frete, muda o layout e atualiza três bibliotecas\". Commits pequenos são fáceis de revisar, de entender e de desfazer.\n\n#### 2. Mensagens que contam a história\n\nUma boa mensagem tem:\n\n- **um resumo curto**, por volta de 50 caracteres, dizendo o que o commit faz: \"Corrige cálculo do frete para a região Norte\";\n- **um corpo opcional**, depois de uma linha em branco, explicando o porquê.\n\nMuitas equipes usam o padrão **Conventional Commits**, com um prefixo para o tipo da mudança:\n\n```text\nfix: corrige cálculo do frete para a região Norte\n\nO frete usava a tabela antiga. Agora lê a tabela atual\ncadastrada pelo financeiro.\n```\n\nPrefixos comuns: `feat:` para funcionalidade nova, `fix:` para correção, `docs:` para documentação e `refactor:` para refatoração.\n\n#### 3. Atualize antes de começar e antes de enviar\n\nO fluxo básico com uma branch:\n\n```bash\ngit switch main\ngit pull\ngit switch -c filtro-por-regiao\n# trabalhe e faça commits pequenos\ngit push -u origin filtro-por-regiao\n```\n\nUse nomes de branch que digam o que está sendo feito, como `filtro-por-regiao` ou `corrige-frete-norte`. Branches devem durar pouco: dias, não meses. Depois de integradas, podem ser apagadas.\n\n#### 4. Pull request e revisão\n\nEm vez de enviar direto para a `main`, abra um pull request (ou merge request, conforme a ferramenta). Ele mostra as mudanças, permite comentários e deixa outra pessoa revisar antes de integrar. A revisão pega erros, espalha conhecimento pela equipe e evita que só uma pessoa entenda cada parte do sistema.\n\n#### 5. Conflito não é inimigo\n\nUm conflito só quer dizer que duas pessoas mexeram no mesmo lugar. Para resolver:\n\n1. Leia as duas versões com calma.\n2. Decida o resultado certo, que muitas vezes combina as duas.\n3. Se tiver dúvida, converse com quem fez a outra mudança.\n4. Rode os testes antes de concluir.\n\nNunca resolva um conflito apagando o trabalho de outra pessoa sem entender o que ele fazia.\n\n#### 6. Evite o push forçado em branches compartilhadas\n\nO `git push --force` reescreve o histórico do servidor e pode apagar o trabalho de outras pessoas. Em branches compartilhadas, como a `main`, não use. Se for mesmo necessário numa branch só sua, prefira `git push --force-with-lease`, que recusa o envio se alguém tiver mandado mudanças que você ainda não tem. Muitas equipes protegem a `main` nas configurações do repositório para bloquear o push forçado.\n\n#### Lista para conferir antes de enviar\n\n- O commit trata de um assunto só.\n- A mensagem diz o que mudou e, se preciso, por quê.\n- A branch está atualizada com a `main`.\n- Os testes passam.\n- A mudança vai por pull request, com revisão.","published":true}},{"id":"ddeaa94c-56f2-4105-b955-c75f4b02ce12","type":"EXTERNAL_ARTICLE","title":"Livro Pro Git, em português","position":7,"description":"O livro oficial do Git, gratuito e traduzido, do primeiro commit até branches e trabalho em equipe.","availability":"UNKNOWN","article":{"url":"https://git-scm.com/book/pt-br/v2","sourceName":"git-scm.com"}},{"id":"ca9000fd-5abe-4434-8723-d0d7625617d3","type":"QUIZ","title":"Revisão: versionamento à moda cavalo","position":8,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"30172041-a37c-40cc-bbe7-c561bff85aca","finalAssessment":false}]},{"id":"e8dc2d03-b1b5-4a3f-8594-79480ddafb5e","title":"Documentação? Só na minha cabeça","description":"O código é a documentação. E, quando o código não explica, o Galdino explica, desde que não esteja de férias. Neste módulo você conhece a política oficial de documentação da cavalaria: o conhecimento guardado numa cabeça só, o \"não é meu código\" e a liberdade de cada pessoa programar do seu jeito. Depois, na vida real, você aprende a escrever documentação que alguém realmente lê.","position":7,"contents":[{"id":"fc38deea-b85d-4b29-9afe-b9ee91a28f95","type":"YOUTUBE","title":"Sistema legado, o pior pesadelo","position":1,"description":"O canal Código Fonte TV explica o que é um sistema legado e por que todo mundo tem medo de mexer nele. Cerca de 12 minutos.","availability":"AVAILABLE","youtube":{"videoId":"3osAasD7rQ4","url":"https://www.youtube.com/watch?v=3osAasD7rQ4","channelName":"Código Fonte TV","madeForKids":false,"availability":"AVAILABLE","channelId":"UCFuIUoyHB12qpYa8Jpxoxow","channel":{"handle":"@codigofontetv","description":"Somos Gabriel Fróes e Vanessa Weber, um casal de programadores apaixonados por tecnologia desde 1996, Criamos o Código Fonte TV para servir de porta de entrada para novos programadores e profissionais de tecnologia. São diversos formatos diferentes de conteúdo onde discutimos sobre o maravilhoso mundo dos códigos de uma forma divertida e didática.\n\nContato exclusivo para negócios: contato@codigofonte.com.br\nTodos os nossos links e redes estão em: https://codigofonte.tv\n\nConheça também o @CompiladoPodcast, nosso podcast semanal sobre as notícias mais relevantes do mundo da tecnologia. Além de apresentar as notícias, nós também opinamos e trocamos ideias com nossos seguidores.\n\nNós ❤️ receber presentes, cartas, brindes e mimos.\nCaixa Postal: 91735 - Cep: 25620-972\nPetrópolis / RJ","avatarUrl":"https://yt3.ggpht.com/2CkMHl_lxrIpACXMFUxU6rPiJ85SBGw7kG5SOFEoJbVVjl0sSNfDB20Xp63wUGOsCPlB_Vt3EA=s240-c-k-c0x00ffffff-no-rj","subscriberCount":777000,"videoCount":1095}}},{"id":"94fdf44c-462c-4304-bc9d-04c08bb52c2d","type":"TEXT","title":"Manual oficial do cavalo, capítulo 7: a política de documentação","position":2,"description":"O código como documentação, o conhecimento em uma cabeça só, o \"não é meu código\" e a liberdade de estilo.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nDocumentar é escrever para o futuro. O cavalo não acredita no futuro: o cavalo acredita na sexta-feira.\n\n#### O código é a documentação\n\nSe alguém quiser saber o que o sistema faz, basta ler o código. Todo ele. São só 340 mil linhas, com nomes como `x2`, `aux` e `processaTudo()`. Qualquer profissional competente entende em umas três semanas.\n\nO README oficial de um projeto da cavalaria tem uma linha:\n\n```text\n# sisvendas\n```\n\nÀs vezes, duas:\n\n```text\n# sisvendas\npra rodar fala com o Galdino\n```\n\n#### O conhecimento concentrado\n\nNa cavalaria, cada parte do sistema tem um guardião. Só ele sabe como ela funciona, por que ela funciona e qual é a ordem certa de reiniciar os serviços. Isso tem muitas vantagens:\n\n- O guardião se torna indispensável.\n- Ninguém precisa gastar tempo escrevendo nada.\n- Toda dúvida vira uma conversa, e conversa aproxima as pessoas.\n\nA única desvantagem conhecida acontece quando o guardião sai de férias, mas o Conselho considera isso um problema de quem ficou.\n\n#### O documento de senhas e o passo a passo secreto\n\nAlgumas informações são escritas, sim. Mas em lugares estratégicos:\n\n- o passo a passo do deploy, num bloco de notas na área de trabalho do Galdino;\n- as senhas, numa planilha chamada `senhas_NAO_ABRIR.xlsx`;\n- a regra de comissão dos vendedores, num e-mail de 2020 que só o Seu Dagoberto recebeu.\n\n#### \"Não é meu código\"\n\nOs axiomas ensinam: o problema só é seu quando o seu nome está no cabeçalho do arquivo.\n\n```javascript\n/**\n * Autor: Galdino\n * Data: 2017\n * Descrição: faz as coisas do pedido\n */\n```\n\nSe o nome no cabeçalho não for o seu, o erro não é seu. Encaminhe para o autor. Se o autor não trabalha mais na empresa, o erro não é de ninguém, e um erro que não é de ninguém não precisa ser corrigido.\n\n#### Cada um programa do seu jeito\n\nO XGH valoriza a autenticidade. Padrões de código são para pessoas sem personalidade. Por isso, num mesmo arquivo da cavalaria, convivem em harmonia:\n\n```javascript\nfunction calcula_total(){ return x }\nfunction CalculaDesconto ( valor ) {\n    return valor*0.9\n}\nconst calculaFrete=(v)=>{return v+10;};\n```\n\nTrês funções, três estilos, três autores, nenhuma conversa. Isso se chama diversidade arquitetural.","published":true}},{"id":"c9e0d9c9-2275-4cca-9040-8462d72704b6","type":"TEXT","title":"Estudo de caso: as férias do Galdino","position":3,"description":"O que aconteceu com o SisVendas 3.0 quando o único guardião do processo de fechamento do mês tirou quinze dias de férias.","availability":"AVAILABLE","text":{"body":"O Galdino tirou férias pela primeira vez em quatro anos. Quinze dias, numa praia sem sinal de celular. Ele avisou na sexta-feira, às 17h, saindo.\n\nNo dia 1º do mês seguinte, o SisVendas 3.0 precisava rodar o fechamento mensal, que calcula a comissão dos vendedores. Ninguém além do Galdino sabia como.\n\nA Bia procurou o README:\n\n```text\n# sisvendas\npra rodar fala com o Galdino\n```\n\nProcurou um documento sobre o fechamento e encontrou uma pasta chamada `scripts_velhos`, com onze arquivos: `fechamento.sh`, `fechamento2.sh`, `fechamento_novo.sh`, `fechamento_NAO_USAR.sh` e `fechamento_usar_esse.sh`, entre outros. Dois deles se chamavam \"usar esse\".\n\nO Seu Dagoberto lembrou que existia um passo a passo \"num bloco de notas no computador do Galdino\". O computador estava bloqueado com senha.\n\nA equipe tentou o `fechamento_usar_esse.sh`. Ele calculou a comissão de todos os vendedores em dobro. A Distribuidora Cascalho percebeu antes de pagar, por sorte.\n\nNo quinto dia, alguém conseguiu falar com o Galdino pelo telefone fixo da pousada. Ele explicou em dois minutos: o script certo era o `fechamento2.sh`, mas antes era preciso rodar uma consulta no banco \"para limpar uns pedidos duplicados que aparecem todo mês\". Não, ele não sabia por que os pedidos duplicavam.\n\nQuando o Galdino voltou, a Bia sugeriu escrever um documento sobre o fechamento. O Galdino respondeu:\n\n\"Pra quê? Eu estou aqui.\"\n\n**Análise do Conselho:** um exemplo de excelência em conhecimento concentrado. Onze scripts, dois chamados \"usar esse\", um passo a passo trancado e um guardião que se tornou, comprovadamente, indispensável. O Conselho registra que o Galdino já marcou as próximas férias e avisará na sexta, às 17h.","published":true}},{"id":"44b2b758-3ab9-451f-9177-8e0d85f882ee","type":"YOUTUBE","title":"Como documentar código","position":4,"description":"Na vida real. Mario Souto, do canal Dev Soutinho, dá dicas práticas para documentar código em projetos profissionais e pessoais. Cerca de 9 minutos.","availability":"AVAILABLE","youtube":{"videoId":"lTjwm1CghDY","url":"https://www.youtube.com/watch?v=lTjwm1CghDY","channelName":"Mario Souto - Dev Soutinho","madeForKids":false,"availability":"AVAILABLE","channelId":"UCzR2u5RWXWjUh7CwLSvbitA","channel":{"handle":"@devsoutinho","description":"Olá pessoas, eu sou Mario Souto e aqui você vai ver vídeos novos sobre o mundo da programação toda SEGUNDA-FEIRA as 11h \\o/ (Se tudo correr bem haha)\n\nApós 3 anos trabalhando como instrutor e desde os 11 mexendo com programação decidi compartilhar um pouco dos meus conhecimentos e pesquisas aqui no YouTube, a ideia é trazer conteúdos da forma mais clara o possível, sempre tentando resolver os problemas do dia a dia e as vezes algumas reflexões.\n\n## Quer fazer algum anúncio/parceria aqui no canal?\n\n- devsoutinho@gmail.com\n\n## Tem alguma dúvida?\n\nManda nos comentários de algum vídeo, sua dúvida pode ser a de outra pessoa ai todo mundo sai ganhando :D","avatarUrl":"https://yt3.ggpht.com/D5IjtP1hC3IfU4g4XYvT9tG_EeigFNtFv6tX7OMV8LXYC7hN5Hc1x518V2R7DipyyhY2NDVpYX4=s240-c-k-c0x00ffffff-no-rj","subscriberCount":92000,"videoCount":320}}},{"id":"6213adb6-cf70-49b2-ac4e-ad016290b83c","type":"TEXT","title":"Na vida real: documentação que alguém lê","position":5,"description":"Fora do personagem: o README que funciona, registro de decisões, procedimentos que qualquer pessoa da equipe consegue seguir e padrões combinados.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Documentação boa não é a mais longa: é a que responde a dúvida de quem chegou agora, no momento em que a dúvida aparece.\n\n#### 1. Um README que coloca alguém para trabalhar\n\nO README é a porta de entrada do projeto. Um bom README responde, de forma curta:\n\n- **O que é o projeto** e para que serve, em duas ou três frases.\n- **Como rodar na sua máquina**, com os comandos na ordem certa.\n- **Como rodar os testes.**\n- **Como publicar**, ou onde está o procedimento de publicação.\n- **Onde pedir ajuda**, com o canal da equipe, e não o nome de uma pessoa só.\n\nUm bom teste: peça para alguém que acabou de chegar seguir o README sozinho. Cada vez que a pessoa travar, o README ganha uma linha.\n\n#### 2. Procedimentos que qualquer pessoa consegue seguir\n\nTarefas que acontecem de vez em quando, como o fechamento do mês do estudo de caso, são as mais perigosas, porque ninguém lembra direito. Escreva o passo a passo num lugar que a equipe toda acessa:\n\n1. O que o procedimento faz e quando rodar.\n2. Os passos, na ordem, com os comandos exatos.\n3. Como conferir que deu certo.\n4. O que fazer se der errado.\n\nMelhor ainda: automatize o que der, para que o procedimento seja um comando só.\n\n#### 3. Registre as decisões, não só o código\n\nO código mostra **o que** o sistema faz. Ele não mostra **por que** foi feito assim. Quando a equipe toma uma decisão importante (uma biblioteca, uma regra de negócio estranha, um atalho consciente), registre num texto curto: o contexto, a decisão e as consequências. Esse formato é conhecido como registro de decisão de arquitetura, ou ADR. Daqui a dois anos, alguém vai agradecer.\n\n#### 4. Comentários explicam o porquê\n\nUm bom nome de variável ou de função dispensa o comentário do \"o quê\". Use o comentário para o que o código não consegue dizer: \"o desconto de 10% vem do contrato com os clientes VIP, revisar em janeiro\". E, se mudar o código, mude o comentário: comentário desatualizado é pior que nenhum.\n\n#### 5. Conhecimento não pode ter dono único\n\nSe só uma pessoa sabe fazer algo, a equipe corre risco, e essa pessoa nunca consegue tirar férias em paz. Algumas formas de espalhar o conhecimento:\n\n- revisão de código feita por pessoas diferentes;\n- programar em dupla nas partes críticas;\n- revezar quem faz os procedimentos raros, com a documentação na mão;\n- tratar o código como da equipe, e não de quem escreveu primeiro.\n\n#### 6. Padrões combinados, aplicados por ferramenta\n\nCada pessoa programar de um jeito torna o código difícil de ler. Combine um padrão de estilo e deixe uma ferramenta aplicá-lo automaticamente (formatadores e linters, que existem para quase toda linguagem). Assim ninguém precisa discutir espaço e vírgula na revisão.\n\n#### Lista para conferir\n\n- O README diz o que é, como rodar, como testar e onde pedir ajuda.\n- Os procedimentos raros estão escritos num lugar que todos acessam.\n- As decisões importantes estão registradas com o motivo.\n- Mais de uma pessoa sabe fazer cada tarefa crítica.\n- O estilo de código é aplicado por uma ferramenta.","published":true}},{"id":"bde845d6-6880-4e3e-bb65-1611d068fe95","type":"QUIZ","title":"Revisão: documentação? Só na minha cabeça","position":6,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"c88b4f57-72e4-4625-b0ec-3e995b705a62","finalAssessment":false}]},{"id":"3d36343c-ab8f-45cc-9355-f862eb21d3c8","title":"Testar é para os fracos","description":"O cavalo confia em si mesmo. E, se não confia, confia no compilador. Neste módulo você aprende a hierarquia oficial de testes da cavalaria: compilou, abriu a tela, clicou no botão, publicou. E conhece o QA mais dedicado da história: o usuário. Depois, na vida real, você aprende o mínimo útil de testes automatizados.","position":8,"contents":[{"id":"84345044-dfbc-44c0-82ed-c2b92ac74563","type":"YOUTUBE","title":"Dev Drama, o rap de quem programa","position":1,"description":"Um rap do canal Programador Sonoro sobre virar a noite caçando bug e publicar rezando para não quebrar. Hino não oficial da cavalaria. Cerca de 5 minutos.","availability":"AVAILABLE","youtube":{"videoId":"1YCMskS3m9o","url":"https://www.youtube.com/watch?v=1YCMskS3m9o","channelName":"Programador Sonoro","madeForKids":false,"availability":"AVAILABLE","channelId":"UCa2Ah8AfEG4ILTjrqAPvOyA","channel":{"handle":"@programadorsonoro","description":"Eu programo o som. 🎧\n\nProgramador Sonoro é música autoral feita por dev, pra dev — em todo ritmo que toca no Brasil: hiphop, trap, rock, metal, pop, blues, reggae, sertanejo, pagode, MPB e o que mais vier.\n\nLetra que só quem vive deploy de sexta, bug em produção e code review às 18h59 entende. Refrão que gruda enquanto o CI roda.\n\n▶ Faixa nova toda semana\n▶ Todos os estilos, uma só linguagem: a de quem programa\n▶ Som feito por quem commita de madrugada\n\nCompila o fone, dá o play e bora. 🚀\n","avatarUrl":"https://yt3.ggpht.com/cE7oPG-Oy-X9kpzkDy42NIEA3VgZtKJ-KgaaB70hEGhZ_uL3W6vAMCCxVT3F3vkA-8wnSAta=s240-c-k-c0x00ffffff-no-rj","subscriberCount":13,"videoCount":6}}},{"id":"3fb4ef57-78a5-45eb-a187-2d737a6ba4e7","type":"YOUTUBE","title":"O método Go Horse: saiba se você é","position":2,"description":"Do canal Carreira Analítica: um jeito de descobrir se você já é cavalo. É o único teste aceito pela cavalaria. Cerca de 7 minutos.","availability":"AVAILABLE","youtube":{"videoId":"LM1cBf0nR-M","url":"https://www.youtube.com/watch?v=LM1cBf0nR-M","channelName":"Carreira Analítica | Danilo","madeForKids":false,"availability":"AVAILABLE","channelId":"UCn5EO29OZpqazhaYuox-ieA","channel":{"handle":"@danilo-cm","description":"Aqui você aprende o que a faculdade e o MBA não ensinam: como usar dados e IA pra tomar decisões melhores, crescer na carreira e se destacar em empresas de verdade.\n\nTenho +12 anos em operações e estratégia em empresas como Uber e Glovo, com operações em mais de 20 países e times de centenas de pessoas. Hoje sou Managing Director de uma empresa na Espanha.\n\nNo canal você encontra:\n• Carreira em dados e como sair do operacional\n• IA aplicada ao trabalho, com as ferramentas que eu uso no dia a dia\n• Operações, marketing e liderança na prática\n• Reacts de conselhos de carreira que viralizam (o que é verdade e o que é furada)\n\nNada de teoria de livro. É o que funciona, e o que dá errado, dentro das empresas.\n\nSe inscreve pra não perder.\n\nContato: contato@carreiraanalitica.com\n","avatarUrl":"https://yt3.ggpht.com/4YOYx3TUaZ8Co5Dwa1dGU6UzEYPwUQ_KiU5cEm7d83g3D3DWH0YrFm7Pb7rWZCofV3Q5mxE6=s240-c-k-c0x00ffffff-no-rj","subscriberCount":106000,"videoCount":452}}},{"id":"2cbe97dd-5ef3-4e9d-b2b1-4b11bbec0faa","type":"TEXT","title":"Manual oficial do cavalo, capítulo 8: a política de qualidade","position":3,"description":"A pirâmide de testes da cavalaria, o protocolo do caminho feliz, o usuário como QA e as técnicas oficiais de depuração.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nO axioma é curto e direto: **\"Teste é para os fracos.\"** Se você sabe o que está fazendo, por que testaria? E, se não sabe, o teste só vai confirmar uma notícia ruim. Ninguém precisa disso.\n\n#### A pirâmide de testes da cavalaria\n\nOutras metodologias têm uma pirâmide de testes, com muitos testes automáticos na base. A cavalaria também tem uma pirâmide, só que com um degrau:\n\n1. **Compilou, tá testado.**\n\nSe a linguagem não precisa compilar, o degrau é substituído por \"a página abriu\".\n\n#### O protocolo do caminho feliz\n\nQuando um teste manual é inevitável (por exemplo, quando alguém está olhando), o cavalo segue o protocolo oficial:\n\n1. Abre a tela.\n2. Preenche o formulário com o nome \"teste\", o e-mail `teste@teste.com` e o telefone `11111111111`.\n3. Clica no botão uma única vez.\n4. Vê que apareceu alguma coisa.\n5. Declara a funcionalidade pronta.\n\nÉ estritamente proibido testar campo vazio, número negativo, nome com acento, texto gigante, clique duplo no botão ou qualquer outra coisa que um usuário de verdade faria no primeiro minuto de uso.\n\n#### O usuário é o QA\n\nPor que manter um ambiente de testes se a produção já tem dados reais, tráfego real e milhares de testadores voluntários trabalhando de graça? Eles se chamam usuários. Testam vinte e quatro horas por dia, inclusive nos fins de semana, e ainda avisam quando acham um erro, geralmente em letras maiúsculas.\n\nO relatório de testes da cavalaria é a caixa de entrada do suporte.\n\n#### Técnicas oficiais de depuração\n\nQuando algo dá errado, a cavalaria tem as suas ferramentas de investigação:\n\n```javascript\nconsole.log(\"aqui\");\nconsole.log(\"aqui 2\");\nconsole.log(\"passou\");\nconsole.log(dados);\nconsole.log(\"AQUIIII\");\nconsole.log(\"por que você não entra nesse if\");\n```\n\nOs `console.log` deveriam ser removidos antes da publicação. O Conselho reconhece que isso nunca aconteceu, e por isso o console de produção de todo sistema XGH tem pelo menos um \"aqui 2\".\n\n#### A técnica de rodar de novo\n\nSe o erro aparece só às vezes, a técnica oficial é rodar de novo. Se passar na segunda vez, está corrigido. Se o teste automático de algum colega falhar às vezes, a técnica é a mesma: rodar até passar e chamar o teste de \"instável\". Depois, desativar o teste instável, porque ele atrapalha a publicação.","published":true}},{"id":"9012bc1e-0dff-4d62-aee5-f596263d677d","type":"TEXT","title":"Estudo de caso: o cupom de desconto negativo","position":4,"description":"Como um campo de cupom, testado com o protocolo do caminho feliz, deu dinheiro de volta para os clientes durante um fim de semana.","availability":"AVAILABLE","text":{"body":"O Seu Dagoberto pediu um campo de cupom de desconto na tela de pedidos. Dois dias, é claro.\n\nO Galdino fez o campo e aplicou o protocolo do caminho feliz: abriu a tela, digitou o cupom `DESCONTO10`, clicou uma vez e viu o total cair 10%. Compilou, tá testado. Publicou na sexta, às 17h.\n\nNo sábado, um cliente da Distribuidora Cascalho digitou o cupom duas vezes, sem querer, clicando rápido no botão. O desconto foi aplicado duas vezes. Outro cliente digitou `DESCONTO10` em letras minúsculas, e o sistema aceitou como um cupom novo, de valor indefinido. Um terceiro, curioso, digitou `DESCONTO150`, um cupom que não existia. Para \"aceitar qualquer cupom de desconto\", o Galdino tinha feito o sistema ler o número do fim do código digitado. O sistema aplicou 150% de desconto, e o total do pedido ficou negativo.\n\nDurante o fim de semana, onze pedidos foram fechados com valor negativo. Pelo cálculo do sistema, a Distribuidora Cascalho devia dinheiro aos clientes.\n\nNa segunda-feira, a caixa de entrada do suporte tinha 34 mensagens. O Galdino abriu o código, colocou três `console.log` e descobriu o problema em quatro horas. A correção:\n\n```javascript\nif (total < 0) {\n  total = 0; // TEMPORÁRIO\n}\n```\n\nO \"TEMPORÁRIO\" continua lá. É o mesmo do capítulo 4.\n\n**Análise do Conselho:** o protocolo do caminho feliz foi cumprido com rigor, e os usuários fizeram o trabalho de QA com eficiência: em menos de 48 horas, encontraram três falhas, todas fora do caminho feliz. O Conselho propõe que esses clientes recebam um certificado de testadores honorários.","published":true}},{"id":"caa861e9-9c6a-4f51-9827-22c55b3a8794","type":"YOUTUBE","title":"Descomplicando testes unitários","position":5,"description":"Na vida real. Do canal Attekita Dev: o que é um teste unitário, por que ele existe e como começar, num guia rápido para quem está iniciando. Cerca de 13 minutos.","availability":"AVAILABLE","youtube":{"videoId":"HcDJdKfm5nA","url":"https://www.youtube.com/watch?v=HcDJdKfm5nA","channelName":"Attekita Dev","madeForKids":false,"availability":"AVAILABLE","channelId":"UCetRsdZxDQDcgVDJd6erz6g","channel":{"handle":"@attekitadev","description":"Software developer especialista em aplicativos e games, com mais de 15 anos de experiência e 5 prêmios de reconhecimento nacional. Foi eleita LinkedIn Top Voice 2023 pelo seu trabalho de criação de conteúdo para a comunidade de tecnologia. Em 2022 esteve na lista dos 50 hackers to follow e foi indicada para o prêmio internacional \"Women that build\".\n\nAtuou por quase 10 anos como freelancer para equipes multinacionais e possui mais de 20 aplicativos e jogos publicados na App Store. Atualmente trabalha Engenheira iOS para o exterior.\n\nAcredita que podemos mudar o mundo com o poder da informação!\n\nhttp://www.attekitadev.com\n\nHIGGS-7PQ8R\n\n","avatarUrl":"https://yt3.ggpht.com/wouftQsBoVBmxgKhsUDdEMTjbryCdl7pEOvh2Wy3NPrBpgY3K5RNAnMgXU8-TD3G20z4GYsy=s240-c-k-c0x00ffffff-no-rj","subscriberCount":385000,"videoCount":670}}},{"id":"385478ea-c366-49c7-ae44-8e2443ebb3f2","type":"TEXT","title":"Na vida real: o mínimo útil de testes automatizados","position":6,"description":"Fora do personagem: o primeiro teste, a estrutura de três passos, os casos de borda, o teste que reproduz o erro e testes rodando sozinhos.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Teste automatizado não é desconfiança de si mesmo. É um jeito de conferir, em segundos e quantas vezes for preciso, que o sistema continua fazendo o que deveria, inclusive depois que outra pessoa mexeu nele.\n\n#### 1. O que é um teste unitário\n\nÉ um pequeno programa que chama uma parte do seu código, como uma função, e confere se o resultado é o esperado. Veja um exemplo para uma função de cupom, no estilo das bibliotecas de teste de JavaScript, como Jest ou Vitest:\n\n```javascript\ntest('aplica 10% de desconto com o cupom DESCONTO10', () => {\n  // Prepara\n  const pedido = { total: 200 };\n  // Executa\n  const resultado = aplicarCupom(pedido, 'DESCONTO10');\n  // Confere\n  expect(resultado.total).toBe(180);\n});\n```\n\n#### 2. A estrutura de três passos\n\nQuase todo teste segue o mesmo formato: **prepara** os dados, **executa** o que está sendo testado e **confere** o resultado. Se o teste ficar difícil de escrever nesse formato, o código testado provavelmente está fazendo coisas demais.\n\n#### 3. Teste as bordas, não só o caminho feliz\n\nOs erros moram nas bordas. Para cada função importante, pergunte \"e se vier algo estranho?\":\n\n```javascript\ntest('recusa cupom que não está cadastrado', () => {\n  expect(() => aplicarCupom({ total: 200 }, 'DESCONTO150')).toThrow();\n});\n\ntest('aplica o cupom uma vez só, mesmo se enviado duas vezes', () => {\n  const pedido = { total: 200 };\n  aplicarCupom(pedido, 'DESCONTO10');\n  aplicarCupom(pedido, 'DESCONTO10');\n  expect(pedido.total).toBe(180);\n});\n```\n\nCasos de borda comuns: valor que não existe no cadastro, campo vazio, zero, número negativo, texto muito longo, acentos, maiúsculas e minúsculas, ação repetida e datas no limite.\n\n#### 4. Achou um erro? Escreva o teste antes de corrigir\n\nQuando um erro aparece, escreva primeiro um teste que reproduz o problema e veja-o falhar. Depois corrija e veja o teste passar. Assim você confirma que entendeu o erro e garante que ele não volta escondido.\n\n#### 5. Testes rodando sozinhos\n\nTestes só protegem se forem rodados. O ideal é que eles rodem automaticamente a cada mudança enviada ao repositório, numa ferramenta de integração contínua. Se um teste falhar, a mudança não segue. Assim ninguém precisa lembrar de rodar.\n\n#### 6. Teste instável se corrige, não se desliga\n\nUm teste que falha \"às vezes\" quase sempre aponta um problema real: dependência de horário, de ordem de execução ou de um serviço externo. Investigue a causa. Desligar o teste só esconde o problema.\n\n#### 7. Ambiente de homologação\n\nAlém dos testes automatizados, tenha um ambiente parecido com a produção, onde a versão nova é conferida antes de chegar aos usuários. Use dados de teste ou dados anonimizados, nunca dados pessoais reais sem necessidade.\n\n#### Por onde começar\n\nNão precisa testar tudo no primeiro dia. Comece pelas partes que mais dão problema ou que mais custam caro quando quebram: cálculos, pagamentos, descontos e login.\n\n#### Lista para conferir\n\n- As funções críticas têm pelo menos um teste.\n- Os testes cobrem casos de borda, não só o caminho feliz.\n- Todo erro corrigido ganhou um teste que o reproduz.\n- Os testes rodam sozinhos a cada mudança.\n- Existe um ambiente de homologação com dados de teste.","published":true}},{"id":"1f8e4fb2-599c-4d21-b60d-9ce9ca63287c","type":"EXTERNAL_ARTICLE","title":"Os diferentes tipos de testes em software","position":7,"description":"Testes unitários, de integração, ponta a ponta, de aceitação e outros: o que cada tipo confere e quando usar.","availability":"UNKNOWN","article":{"url":"https://www.atlassian.com/br/continuous-delivery/software-testing/types-of-software-testing","sourceName":"Atlassian"}},{"id":"710a08a2-5a06-4516-90b5-90da159b04e8","type":"QUIZ","title":"Revisão: testar é para os fracos","position":8,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"ed8a1858-75df-49cc-88f9-28e871aee04c","finalAssessment":false}]},{"id":"85ea0f71-304d-4236-b5cb-7fb345280753","title":"Deploy na sexta às 17h","description":"O momento mais sagrado da semana do cavalo. Neste módulo você aprende o ritual completo da publicação: o horário ideal, a mudança \"pequena\" de três semanas, a senha guardada no código, o `.env` no repositório, o `admin/admin` em produção e o plano de rollback oficial da cavalaria: rezar. Depois, na vida real, você aprende a publicar com segurança.","position":9,"contents":[{"id":"17559344-a451-4513-b676-df4671c818f8","type":"YOUTUBE","title":"Sexta de deploy","position":1,"description":"Uma música de dev para dev, do canal Programador Sonoro, sobre aquele ajuste mínimo que subiu às 17h de sexta. Cerca de 4 minutos.","availability":"AVAILABLE","youtube":{"videoId":"jvpwcFOYR_Q","url":"https://www.youtube.com/watch?v=jvpwcFOYR_Q","channelName":"Programador Sonoro","madeForKids":false,"availability":"AVAILABLE","channelId":"UCa2Ah8AfEG4ILTjrqAPvOyA","channel":{"handle":"@programadorsonoro","description":"Eu programo o som. 🎧\n\nProgramador Sonoro é música autoral feita por dev, pra dev — em todo ritmo que toca no Brasil: hiphop, trap, rock, metal, pop, blues, reggae, sertanejo, pagode, MPB e o que mais vier.\n\nLetra que só quem vive deploy de sexta, bug em produção e code review às 18h59 entende. Refrão que gruda enquanto o CI roda.\n\n▶ Faixa nova toda semana\n▶ Todos os estilos, uma só linguagem: a de quem programa\n▶ Som feito por quem commita de madrugada\n\nCompila o fone, dá o play e bora. 🚀\n","avatarUrl":"https://yt3.ggpht.com/cE7oPG-Oy-X9kpzkDy42NIEA3VgZtKJ-KgaaB70hEGhZ_uL3W6vAMCCxVT3F3vkA-8wnSAta=s240-c-k-c0x00ffffff-no-rj","subscriberCount":13,"videoCount":6}}},{"id":"ad620ee4-b722-4404-ae4e-1da3cf9a30b1","type":"TEXT","title":"Manual oficial do cavalo, capítulo 9: o ritual da publicação","position":2,"description":"O horário sagrado, a mudança pequena, a política de senhas, as versões sem nome e o protocolo pós-deploy.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nPublicar é a hora da verdade. Outras metodologias publicam com calma, em partes pequenas e com um plano para voltar atrás. A cavalaria publica com fé.\n\n#### O horário sagrado\n\nO horário oficial de publicação da cavalaria é **sexta-feira, 17h**. Os motivos são técnicos:\n\n- A semana acabou, e a mudança precisa estar no ar antes do fim de semana.\n- Todo mundo já está indo embora, então ninguém vai atrapalhar.\n- Se der problema, sábado e domingo são dois dias inteiros para descobrir.\n\nO horário alternativo é **véspera de feriado prolongado**, de preferência às 18h.\n\n#### A mudança pequena\n\nToda publicação da cavalaria é descrita como \"uma mudança pequena, nem precisa testar\". Na prática, a mudança pequena contém:\n\n- três semanas de alterações acumuladas;\n- uma mudança na estrutura do banco de dados;\n- um arquivo de configuração editado direto no servidor, que não existe em lugar nenhum além do servidor;\n- e uma biblioteca atualizada \"já que estava mexendo\".\n\n#### A política oficial de senhas\n\nConfigurar senhas em variáveis de ambiente dá trabalho. A cavalaria guarda tudo onde é fácil de achar:\n\n```javascript\nconst banco = conectar({\n  usuario: 'admin',\n  senha: 'admin',\n  servidor: 'producao.sisvendas.exemplo',\n});\nconst CHAVE_PAGAMENTO = 'chave-secreta-de-producao-nao-compartilhar';\n```\n\nE, para facilitar a vida da equipe, o arquivo `.env`, com todas as senhas de produção, vai junto para o repositório:\n\n```bash\ngit add .\ngit commit -m \"ajustes\"\ngit push\n```\n\nO `git add .` é o comando preferido da cavalaria: ele leva tudo, inclusive o `.env`, a pasta `node_modules` inteira e um arquivo `backup_banco.sql` de 3 GB.\n\nO usuário administrador do sistema em produção é `admin`, com a senha `admin`. Trocar a senha exigiria avisar todo mundo, e o cavalo não avisa ninguém de nada.\n\n#### As versões sem nome\n\nNa cavalaria, as versões não têm número. Ninguém sabe qual versão está no ar, qual estava antes nem o que mudou entre elas. Quando alguém pergunta, a resposta oficial é \"a última\".\n\n#### O protocolo pós-deploy\n\n1. **17h00.** Publicação concluída. Escrever no grupo da equipe: \"subiu\".\n2. **17h01.** Abrir o sistema uma vez e ver que carregou.\n3. **17h05.** Sair.\n4. **17h30.** Desligar o celular, por motivo de \"bateria\".\n5. **19h00.** O monitoramento começa a disparar alertas. Ninguém vê, porque ninguém configurou para onde os alertas vão.\n6. **Segunda-feira, 9h.** Ligar o celular. Ler as 247 mensagens. Escrever no grupo: \"o que aconteceu?\".\n\n#### O rollback oficial\n\nO cavalo não tem plano para voltar à versão anterior, porque não sabe qual era a versão anterior. O rollback oficial da cavalaria tem duas etapas:\n\n1. Rezar.\n2. Se não funcionar, publicar mais uma \"mudança pequena\" por cima, com a mensagem \"ajustes\".","published":true}},{"id":"055541d9-ed03-4a37-a6cb-79eb13f181f4","type":"TEXT","title":"Estudo de caso: a sexta-feira do pagamento","position":3,"description":"Como uma publicação às 17h de sexta, com uma chave de pagamento no repositório, ocupou o fim de semana inteiro da equipe.","availability":"AVAILABLE","text":{"body":"Sexta-feira, 16h55. O Seu Dagoberto pede para o Galdino publicar \"aquela melhoria do pagamento\", que estava pronta havia três semanas. É uma mudança pequena: a nova integração com o sistema de pagamento, uma coluna nova na tabela de pedidos e a atualização de duas bibliotecas.\n\nO Galdino roda `git add .`, faz commit com a mensagem \"ajustes finais\" e publica. Às 17h01, abre o sistema, vê que carregou e escreve no grupo: \"subiu\". Às 17h05, vai embora.\n\nÀs 18h20, o primeiro cliente tenta pagar um pedido. A tela fica carregando para sempre. A coluna nova não existe no banco de produção: o Galdino tinha criado na mão, no banco da máquina dele, e esqueceu.\n\nÀs 19h00, o monitoramento dispara um alerta. O alerta vai para o e-mail de uma pessoa que saiu da empresa em 2023.\n\nÀs 21h40, a Dona Leonor liga para o celular do Seu Dagoberto. O celular está sem bateria, de verdade desta vez.\n\nNo sábado de manhã, a Bia vê as mensagens e tenta voltar para a versão anterior. Não existe versão anterior identificada. O último commit antes do \"ajustes finais\" é o \"ajustes\", e ninguém sabe se ele funcionava.\n\nNo domingo, enquanto investiga, a Bia percebe que o arquivo `.env` com a chave de produção do sistema de pagamento foi para o repositório junto com o \"ajustes finais\". Ela avisa a equipe e pede para trocarem a chave.\n\nO Galdino responde no grupo, na segunda-feira:\n\n\"Mas o repositório é privado, ninguém vê.\"\n\nO repositório é compartilhado com três empresas terceirizadas.\n\n**Análise do Conselho:** um deploy de manual. Horário sagrado respeitado, mudança pequena de três semanas, migração feita à mão, alerta enviado para ninguém, nenhuma versão identificada e uma chave de produção distribuída generosamente. O rollback foi executado conforme o protocolo oficial: a equipe rezou o fim de semana inteiro.","published":true}},{"id":"d1170740-aeb4-4ce7-a54e-5c0392db3611","type":"YOUTUBE","title":"Vazou uma senha no Git?","position":4,"description":"Na vida real. Tom Lima mostra como remover do histórico do Git uma senha enviada por engano, e por que trocar a senha vazada é o primeiro passo. Cerca de 12 minutos.","availability":"AVAILABLE","youtube":{"videoId":"GfKqjNIbVIk","url":"https://www.youtube.com/watch?v=GfKqjNIbVIk","channelName":"Tom Lima","madeForKids":false,"availability":"AVAILABLE","channelId":"UC5dXw68VUT2VTV0prmv--Cg","channel":{"handle":"@tom-lima","description":"Prazer, meu nome é Tom Lima. Meu canal é dedicado a compartilhar conteúdo técnico relacionado as áreas de programação, engenharia de software e afins. ","avatarUrl":"https://yt3.ggpht.com/i5vX3-Xdzxut1ach-iPvxHuL0Tp-j_FLfoU8q6xPMEF7vjyi46edJf7e1X7yToQjF3PEMpoqxGU=s240-c-k-c0x00ffffff-no-rj","subscriberCount":25,"videoCount":4}}},{"id":"e9928294-7931-4805-89c5-d1ef1390fa04","type":"TEXT","title":"Na vida real: deploy seguro","position":5,"description":"Fora do personagem: segredos fora do código, deploys pequenos e automatizados, versões identificadas, rollback planejado e acompanhamento depois da publicação.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Um bom deploy é chato: pequeno, previsível e com um caminho de volta conhecido.\n\n#### 1. Segredos fora do código\n\nSenhas, chaves de acesso e tokens nunca devem ficar no código nem no repositório.\n\n- Guarde os segredos em variáveis de ambiente ou num gerenciador de segredos do seu provedor de nuvem ou da sua ferramenta de deploy.\n- Coloque o `.env` no `.gitignore` e mantenha no repositório só um `.env.example`, com os nomes das variáveis e valores falsos.\n- Evite `git add .` sem olhar. Confira com `git status` o que vai entrar no commit.\n- Nunca use senhas padrão, como `admin/admin`, em nenhum ambiente acessível. Use senhas fortes e diferentes por ambiente.\n\n#### 2. Se um segredo vazar, troque primeiro\n\nSe uma senha ou chave foi para o repositório, **considere que ela vazou** e troque-a imediatamente, mesmo que o repositório seja privado. Remover do histórico do Git é importante, mas vem depois: cópias e clones podem já ter o segredo.\n\n#### 3. Deploys pequenos e frequentes\n\nTrês semanas de mudanças num deploy só tornam impossível saber o que causou um problema. Publique em partes pequenas, com frequência. Se algo quebrar, a causa está numa mudança pequena e fácil de encontrar.\n\n#### 4. Automatize\n\nDeploy manual é deploy que cada pessoa faz de um jeito. Um processo automatizado (um script ou uma ferramenta de integração e entrega contínuas) executa sempre os mesmos passos: roda os testes, aplica as migrações do banco e publica. Arquivo editado direto no servidor deve ser exceção rara e registrada.\n\n#### 5. Versões identificadas\n\nCada publicação deve ter uma identificação, como uma tag no Git (`v2.4.0`) ou o número do build. Assim você sabe exatamente o que está no ar, qual era a versão anterior e o que mudou entre elas.\n\n#### 6. Rollback planejado\n\nAntes de publicar, responda: **\"se der errado, como voltamos para a versão anterior, e em quanto tempo?\"**.\n\n- Mantenha a versão anterior pronta para ser republicada.\n- Mudanças no banco de dados merecem cuidado extra: prefira mudanças que funcionem tanto com a versão nova quanto com a anterior do sistema, para que voltar o código não quebre o banco.\n- Para funcionalidades grandes, use um interruptor (feature flag): o código vai para produção desligado e é ligado aos poucos. Se der problema, basta desligar.\n\n#### 7. Publique quando alguém puder acompanhar\n\nO problema da sexta às 17h não é o dia da semana: é publicar sem ninguém por perto para observar. Publique num horário em que a equipe esteja disponível por um tempo depois e confira se os alertas do monitoramento chegam para quem está de plantão.\n\n#### Lista para conferir antes de publicar\n\n- Nenhum segredo está no código nem no commit.\n- A mudança é pequena e passou pelos testes automatizados.\n- O deploy é feito pelo processo automatizado.\n- A versão tem identificação.\n- Existe um plano de rollback testado, inclusive para o banco.\n- Alguém vai acompanhar o sistema depois, e os alertas chegam para essa pessoa.","published":true}},{"id":"bc907a03-b60c-4589-98ce-86753f54ffaa","type":"EXTERNAL_ARTICLE","title":"Configurações no ambiente, no The Twelve-Factor App","position":6,"description":"Por que configurações e credenciais devem ficar no ambiente, e não no código, num guia clássico de boas práticas para aplicações.","availability":"UNKNOWN","article":{"url":"https://12factor.net/pt_br/config","sourceName":"The Twelve-Factor App"}},{"id":"a450aadf-8694-4202-b4a6-50cf9366b4a7","type":"QUIZ","title":"Revisão: deploy na sexta às 17h","position":7,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"0d7f815d-d2b5-4488-8872-83eea807eaa2","finalAssessment":false}]},{"id":"6449b679-5389-45f8-9664-33d503189227","title":"Marretando o banco","description":"Na cavalaria, o banco de dados de produção não é um lugar sagrado: é uma bancada de trabalho. Neste módulo você conhece as técnicas oficiais de manutenção de dados: o comando sem filtro, o ajuste à mão toda segunda-feira, o \"só um select rapidinho\", a edição pelo programa gráfico às 2h da manhã, a tabela de backup com nome de trabalho de faculdade e a migração artesanal. Depois, na vida real, você aprende a mexer no banco sem medo.","position":10,"contents":[{"id":"63e3b0ea-46fd-4e11-a43e-12fc90020ac0","type":"YOUTUBE","title":"Apaguei a tabela inteira em produção","position":1,"description":"Do canal Programador Sonoro: o pesadelo de todo mundo que já teve acesso ao banco de produção, em forma de música. Cerca de 4 minutos.","availability":"AVAILABLE","youtube":{"videoId":"MwCe6wQNHmc","url":"https://www.youtube.com/watch?v=MwCe6wQNHmc","channelName":"Programador Sonoro","madeForKids":false,"availability":"AVAILABLE","channelId":"UCa2Ah8AfEG4ILTjrqAPvOyA","channel":{"handle":"@programadorsonoro","description":"Eu programo o som. 🎧\n\nProgramador Sonoro é música autoral feita por dev, pra dev — em todo ritmo que toca no Brasil: hiphop, trap, rock, metal, pop, blues, reggae, sertanejo, pagode, MPB e o que mais vier.\n\nLetra que só quem vive deploy de sexta, bug em produção e code review às 18h59 entende. Refrão que gruda enquanto o CI roda.\n\n▶ Faixa nova toda semana\n▶ Todos os estilos, uma só linguagem: a de quem programa\n▶ Som feito por quem commita de madrugada\n\nCompila o fone, dá o play e bora. 🚀\n","avatarUrl":"https://yt3.ggpht.com/cE7oPG-Oy-X9kpzkDy42NIEA3VgZtKJ-KgaaB70hEGhZ_uL3W6vAMCCxVT3F3vkA-8wnSAta=s240-c-k-c0x00ffffff-no-rj","subscriberCount":13,"videoCount":6}}},{"id":"2aacce82-121c-4a41-b0bc-d89aa6830cbc","type":"TEXT","title":"Manual oficial do cavalo, capítulo 10: manutenção de dados","position":2,"description":"As técnicas oficiais da cavalaria para mexer no banco de produção, com os comandos que ninguém deveria rodar.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nUm aviso fora do personagem, antes de começar: **os comandos deste capítulo são piada.** Eles mostram situações reais que acontecem em muitas equipes, justamente para que você as reconheça. Não rode nenhum deles em banco nenhum.\n\nAgora, de volta à doutrina.\n\nO cavalo não espera uma tela nova ficar pronta para corrigir um dado. Ele abre o banco de produção e resolve. Diretamente. Com as próprias mãos.\n\n#### Técnica 1: o comando sem filtro\n\nO cliente pediu para corrigir o e-mail de um único cadastro. O cavalo abre o banco e digita com confiança:\n\n```sql\nUPDATE clientes SET email = 'maria.souza@exemplo.com';\n```\n\nO banco responde: `UPDATE 48213`. Parabéns. Agora todos os clientes da empresa têm o mesmo e-mail.\n\nA variação mais temida da técnica é o `DELETE` sem `WHERE`, que tem a vantagem de deixar o banco muito mais leve:\n\n```sql\nDELETE FROM pedidos;\n```\n\nO Conselho lembra que existe um silêncio muito específico, de uns dois segundos, entre apertar a tecla e ler o número de linhas afetadas. Todo cavalo veterano conhece esse silêncio.\n\n#### Técnica 2: o ajuste à mão de toda segunda-feira\n\nPor que corrigir a causa de um dado errado, se dá para corrigir o dado? Toda semana, o cavalo roda o mesmo ajuste:\n\n```sql\n-- rodar toda segunda-feira, senão o relatório quebra\nUPDATE pedidos SET status = 'PAGO' WHERE status = 'PAGO ';\n```\n\nNinguém sabe de onde vem o espaço no final de `'PAGO '`. Ninguém quer saber.\n\n#### Técnica 3: só um select rapidinho\n\nÀs 11h de uma segunda-feira, no horário de maior uso do sistema, o cavalo precisa de \"só um número rapidinho\" para uma planilha:\n\n```sql\nSELECT * FROM vendas v\nJOIN itens_venda i ON i.venda_id = v.id\nJOIN clientes c ON c.id = v.cliente_id\nORDER BY v.data;\n```\n\nSem filtro de data, sem limite, juntando as maiores tabelas do sistema. O sistema fica lento para todo mundo por vinte minutos. Para completar, o cavalo abriu uma transação no programa gráfico e esqueceu de fechar, e outras operações ficam esperando por ela. O cavalo descobre que \"só um select\" também pode travar a produção.\n\n#### Técnica 4: edição pelo programa gráfico às 2h da manhã\n\nO ápice da técnica: abrir o programa de banco de dados, conectar direto na produção, clicar duas vezes numa célula da tabela, mudar o valor e apertar Enter. Às 2h da manhã. Com sono. Na tabela de preços.\n\nNo dia seguinte, um produto de R$ 49,90 está custando R$ 4.990,00. Ou R$ 0,49. A cavalaria considera as duas opções aceitáveis.\n\n#### Técnica 5: o backup oficial\n\nAntes de qualquer mudança arriscada, o cavalo faz backup. Do jeito dele:\n\n```sql\nCREATE TABLE clientes_bkp AS SELECT * FROM clientes;\nCREATE TABLE clientes_bkp_2 AS SELECT * FROM clientes;\nCREATE TABLE clientes_bkp_final AS SELECT * FROM clientes;\nCREATE TABLE clientes_bkp_final_2 AS SELECT * FROM clientes;\nCREATE TABLE clientes_bkp_nao_apagar AS SELECT * FROM clientes;\n```\n\nEssas tabelas ficam no banco de produção para sempre, ocupando espaço e guardando dados pessoais que ninguém lembra que existem. Ninguém sabe qual é a mais recente. Mas elas estão lá, e isso conforta.\n\n#### Técnica 6: a migração artesanal\n\nO sistema tem migrações automáticas do banco? O cavalo prefere rodar a mudança na mão, direto em produção, \"para ganhar tempo\". Assim, o banco de produção fica com uma coluna que não existe em nenhum outro ambiente, e a próxima migração automática falha com um erro que ninguém entende.\n\n#### Técnica 7: a sequência desalinhada\n\nDepois de inserir registros à mão com números escolhidos pelo próprio cavalo, o contador automático de identificadores da tabela fica para trás. No dia seguinte, o sistema tenta criar um pedido novo e recebe:\n\n```text\nERRO: duplicar valor da chave viola a restrição de unicidade \"pedidos_pkey\"\n```\n\nO cavalo resolve inserindo mais registros à mão, agora com números ainda maiores, só por garantia.","published":true}},{"id":"df888816-75fd-48bf-8eb5-6609da7cd3e4","type":"TEXT","title":"Estudo de caso: o e-mail da Maria","position":3,"description":"Como uma correção de e-mail num único cadastro fez 48 mil clientes da Distribuidora Cascalho receberem o mesmo boleto.","availability":"AVAILABLE","text":{"body":"Quinta-feira, 18h. A Dona Leonor pede uma correção rápida: o e-mail da cliente Maria Souza está errado no cadastro. A tela de edição de clientes está com defeito desde o deploy da sexta anterior (veja o módulo 9).\n\nO Galdino abre o programa gráfico de banco de dados, conecta na produção e digita:\n\n```sql\nUPDATE clientes SET email = 'maria.souza@exemplo.com'\n```\n\nEle ia escrever o `WHERE` na linha de baixo. Mas apertou o atalho de executar antes. O programa executa só a primeira linha.\n\n`UPDATE 48213`\n\nO silêncio de dois segundos dura, desta vez, uns quinze.\n\nO Galdino procura o backup. Encontra `clientes_bkp`, `clientes_bkp_2`, `clientes_bkp_final` e `clientes_bkp_final_2`. A mais recente é de oito meses atrás. Ninguém sabe se o backup automático do servidor está funcionando: a pessoa que configurou saiu da empresa, e a senha estava no bloco de notas do Galdino (veja o módulo 7).\n\nÀs 23h, o processo automático de cobrança roda, como toda quinta. 48.213 boletos são enviados para a Maria Souza.\n\nNa sexta de manhã, a Maria liga para a Distribuidora Cascalho. Ela está tranquila, mas gostaria de saber por que deve R$ 3,2 milhões.\n\nO backup automático do servidor, felizmente, funcionava. A Bia passa o dia restaurando os e-mails a partir dele, numa cópia separada do banco, e conferindo cliente por cliente os cadastros que mudaram depois do backup.\n\nNa reunião sobre o ocorrido, o Galdino propõe uma solução definitiva: criar a tabela `clientes_bkp_final_3`.\n\n**Análise do Conselho:** execução impecável da Técnica 1, com uso criativo do atalho de executar. O Conselho destaca também a contribuição da Técnica 5: quatro tabelas de backup, nenhuma útil. A Maria Souza recebeu um pedido formal de desculpas e, segundo relatos, uma cesta de café da manhã.","published":true}},{"id":"12da30b2-5b4e-4ea7-89c7-58788254f2e8","type":"YOUTUBE","title":"Rodei um update sem where em produção, e agora?","position":4,"description":"Na vida real. Rodrigo Rahman conta, no dia seguinte, como rodou um update sem where no banco de produção da empresa em que trabalha, e o que aprendeu com isso. Cerca de 16 minutos.","availability":"AVAILABLE","youtube":{"videoId":"9YwOZk0qE5c","url":"https://www.youtube.com/watch?v=9YwOZk0qE5c","channelName":"Rodrigo Rahman","madeForKids":false,"availability":"AVAILABLE","channelId":"UC5hvPObwya8kzWWB-wmVlXg","channel":{"handle":"@rodrigorahman","description":"Sou Rodrigo Rahman, especialista reconhecido pelo Google como GDE em Flutter e Dart, arquiteto de software e referência em desenvolvimento assistido por IA no Brasil.\n\nSou fundador da Academia das IAs e da Academia do Flutter, comunidades que já ajudaram milhares de desenvolvedores a evoluírem na carreira através de conteúdo prático e tecnologia de ponta.\n\nAqui você vai encontrar conteúdos sobre Flutter, Dart, IA, engenharia de software e carreira, sempre com foco em produtividade, aplicações reais e nas tecnologias que estão transformando a forma como programamos.\n\nO objetivo é te ajudar a desenvolver software de maneira mais moderna, inteligente e eficiente.\n\n🚀 Contato comercial, dúvidas, críticas e sugestões:\n▸ [rodrigorahman@academiadoflutter.com.br](mailto:rodrigorahman@academiadoflutter.com.br)\n\nGDE Flutter & Dart • Mentor • Professor • Especialista em IA aplicada ao desenvolvimento • Pai do Guilherme e Gabriel.\n\n","avatarUrl":"https://yt3.ggpht.com/47P_ShJ2c3OCnYbJHi0SynP9CFEp7gtH3VV0FvrTAS89K-vdDmO12Ajiq1_GVnHB6_I19Fdzow=s240-c-k-c0x00ffffff-no-rj","subscriberCount":27100,"videoCount":461}}},{"id":"30b479ae-f9fa-48cd-82ac-ab8fa805ce04","type":"TEXT","title":"Na vida real: mexer no banco sem medo","position":5,"description":"Fora do personagem: backup testado, transação, WHERE conferido antes, migrações versionadas, consultas que não travam a produção e acesso mínimo.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Mexer no banco de produção às vezes é necessário. O segredo é fazer de um jeito que um erro de digitação não vire um desastre.\n\n#### 1. Backup de verdade, e testado\n\nTabelas `_bkp` dentro do próprio banco não são backup. Backup de verdade:\n\n- é automático e frequente;\n- fica fora do servidor do banco;\n- segue a regra **3-2-1**: três cópias dos dados, em dois tipos de armazenamento diferentes, com uma cópia fora do local principal;\n- **é restaurado de tempos em tempos** num ambiente separado, para confirmar que funciona. Backup que nunca foi restaurado é só uma esperança.\n\n#### 2. Prefira a tela do sistema ao comando manual\n\nSe a correção pode ser feita pela própria aplicação, faça por ela: ela aplica as validações e deixa registro. Comandos manuais no banco de produção devem ser exceção, de preferência revisados por outra pessoa.\n\n#### 3. Confira o WHERE antes, com um SELECT\n\nAntes de um `UPDATE` ou `DELETE`, rode um `SELECT` com exatamente o mesmo filtro e veja quantas linhas e quais registros ele traz:\n\n```sql\nSELECT id, nome, email FROM clientes WHERE id = 1234;\n```\n\nSe o `SELECT` trouxer um registro, o `UPDATE` com o mesmo `WHERE` vai mexer em um registro.\n\n#### 4. Use uma transação\n\nNuma transação, você confere o resultado antes de gravar de vez. Exemplo em PostgreSQL:\n\n```sql\nBEGIN;\nUPDATE clientes SET email = 'maria.souza@exemplo.com' WHERE id = 1234;\n-- o banco informa: UPDATE 1\nSELECT id, email FROM clientes WHERE id = 1234;\nCOMMIT;\n```\n\nSe o número de linhas afetadas for diferente do esperado, use `ROLLBACK;` no lugar do `COMMIT;` e nada muda. Lembre de sempre encerrar a transação: uma transação esquecida aberta pode travar outras operações.\n\n#### 5. Mudanças de estrutura só por migrações\n\nAlterações na estrutura do banco (criar colunas, tabelas, índices) devem ser feitas por **migrações versionadas**: arquivos no repositório, aplicados pelo processo de deploy, na mesma ordem em todos os ambientes. Assim, desenvolvimento, homologação e produção ficam iguais, e ninguém precisa lembrar do que rodou na mão.\n\n#### 6. Consultas pesadas longe da produção\n\nPara relatórios e análises, use uma réplica de leitura ou uma cópia do banco. Se precisar consultar a produção, use filtros e `LIMIT`, prefira horários de menor uso e evite `SELECT *` em tabelas grandes.\n\n#### 7. Acesso mínimo\n\nNem todo mundo precisa de acesso de escrita à produção. Use usuários com permissões limitadas (por exemplo, só leitura para consultas) e reserve o acesso de escrita para quando for necessário, com registro de quem fez o quê.\n\n#### Lista para conferir antes de mexer na produção\n\n- Existe backup recente e testado.\n- A correção não pode ser feita pela própria aplicação.\n- O `SELECT` com o mesmo `WHERE` trouxe exatamente os registros esperados.\n- O comando está dentro de uma transação.\n- Outra pessoa revisou o comando.\n- Mudanças de estrutura vão por migração, não na mão.","published":true}},{"id":"71c14f4c-96de-45ef-a26e-5dca05b29c49","type":"EXTERNAL_ARTICLE","title":"Transações, na documentação do PostgreSQL","position":6,"description":"Em inglês. O tutorial oficial do PostgreSQL sobre transações, com BEGIN, COMMIT e ROLLBACK.","availability":"UNKNOWN","article":{"url":"https://www.postgresql.org/docs/current/tutorial-transactions.html","sourceName":"PostgreSQL"}},{"id":"79a94154-c1d1-4d75-8dc9-cc0a875a87f6","type":"QUIZ","title":"Revisão: marretando o banco","position":7,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Os comandos do manual são piada: não rode nenhum deles. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"b717d008-420a-4f15-9b26-b990b39da918","finalAssessment":false}]},{"id":"8dd85283-8b82-4a66-81e8-18802be38a03","title":"Como dar desculpa para o usuário","description":"O sistema caiu, o botão sumiu, o relatório veio errado. Um cavalo de verdade não perde a compostura: ele tem uma desculpa pronta para cada ocasião. Neste módulo você domina o catálogo oficial de desculpas da cavalaria e a forma correta de aplicar cada uma. Depois, na vida real, você aprende a comunicar um problema com honestidade.","position":11,"contents":[{"id":"8323aae4-aad8-4c3c-9f62-496f941ea689","type":"YOUTUBE","title":"Erro 500, meu bem","position":1,"description":"Uma sofrência sertaneja do canal Programador Sonoro para quem já viu a produção cair de madrugada. Trilha sonora oficial da hora de dar desculpa. Cerca de 4 minutos.","availability":"AVAILABLE","youtube":{"videoId":"UiWhUsWG0ug","url":"https://www.youtube.com/watch?v=UiWhUsWG0ug","channelName":"Programador Sonoro","madeForKids":false,"availability":"AVAILABLE","channelId":"UCa2Ah8AfEG4ILTjrqAPvOyA","channel":{"handle":"@programadorsonoro","description":"Eu programo o som. 🎧\n\nProgramador Sonoro é música autoral feita por dev, pra dev — em todo ritmo que toca no Brasil: hiphop, trap, rock, metal, pop, blues, reggae, sertanejo, pagode, MPB e o que mais vier.\n\nLetra que só quem vive deploy de sexta, bug em produção e code review às 18h59 entende. Refrão que gruda enquanto o CI roda.\n\n▶ Faixa nova toda semana\n▶ Todos os estilos, uma só linguagem: a de quem programa\n▶ Som feito por quem commita de madrugada\n\nCompila o fone, dá o play e bora. 🚀\n","avatarUrl":"https://yt3.ggpht.com/cE7oPG-Oy-X9kpzkDy42NIEA3VgZtKJ-KgaaB70hEGhZ_uL3W6vAMCCxVT3F3vkA-8wnSAta=s240-c-k-c0x00ffffff-no-rj","subscriberCount":13,"videoCount":6}}},{"id":"355c4fe1-b3f9-4a7a-bfa4-12741da70f72","type":"YOUTUBE","title":"E quando o programador diz: funciona na minha máquina?","position":2,"description":"Menos de um minuto sobre a frase mais famosa da cavalaria, do canal HB Network. Cerca de 1 minuto.","availability":"AVAILABLE","youtube":{"videoId":"rqMpwuChaLc","url":"https://www.youtube.com/watch?v=rqMpwuChaLc","channelName":"HB Network","madeForKids":false,"availability":"AVAILABLE","channelId":"UCEbLV4AfUhoxNb_-Ionw83g","channel":{"handle":"@hbnetworkoficial","description":"👨🏻‍💻 | Uma comunidade de programadores inquietos usando a tecnologia para criar o estilo de vida que desejam!\nQuer fazer parte? 👇🏻\n\n🚨 Neste canal vão rolar papos sobre Empreendedorismo, Desenvolvimento de Software, Mercado de TI, Carreira na Programação, Postura Profissional,  Home Office, Python e Django, Emprego na Gringolândia e mais uma porrada de assuntos maneiros e tudo o que rola na comunidade HB Network ... Se inscreva para não ficar de fora!","avatarUrl":"https://yt3.ggpht.com/D1cC7Wyxp4zImPnQ59qRKk1E9Xh6Nb4RB3F3pJP492ZYuuExvdpMc34jKQKf4Vk9MIEWXBtdcQ=s240-c-k-c0x00ffffff-no-rj","subscriberCount":12900,"videoCount":661}}},{"id":"f2207617-cbda-4dca-8ca4-4a5a5bd0cf55","type":"TEXT","title":"Manual oficial do cavalo, capítulo 11: o catálogo oficial de desculpas","position":3,"description":"As desculpas clássicas da cavalaria, com quando usar, como aplicar cada uma e a ordem recomendada.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nO usuário encontrou um problema. É natural: os usuários são os testadores oficiais da cavalaria (veja o módulo 8). Agora você precisa responder. A regra de ouro é simples: o problema nunca está no sistema. Ele está no navegador, na internet, no computador, no cache, na fase da lua.\n\nA seguir, o catálogo oficial, com instruções de aplicação.\n\n#### 1. \"Limpa o cache\"\n\n**Quando usar:** sempre. É a desculpa coringa da cavalaria.\n\n**Como aplicar:** diga com calma e autoridade, como quem dá um diagnóstico. Se o usuário perguntar o que é cache, responda \"é uma coisa do navegador\". Se ele já limpou, peça para limpar de novo, \"mas agora o completo\". Se ainda assim não funcionar, peça para tentar numa aba anônima. Isso costuma render mais uns dois dias.\n\n#### 2. \"Na minha máquina funciona\"\n\n**Quando usar:** quando o usuário consegue mostrar o erro acontecendo.\n\n**Como aplicar:** com uma pontinha de surpresa, como quem também está intrigado. A frase transfere sutilmente o problema para o computador do usuário. Nunca, em hipótese alguma, explique por que a sua máquina é diferente da produção.\n\n#### 3. \"Isso não é bug, é feature\"\n\n**Quando usar:** quando o comportamento estranho é impossível de negar.\n\n**Como aplicar:** com entusiasmo. O botão que apaga o pedido em vez de salvar é uma \"funcionalidade de segurança\". O relatório que mostra o mês errado é \"uma visão comparativa\". Se o usuário gostar, a feature fica. Se não gostar, passe para o item seguinte.\n\n#### 4. \"Deve ser a sua internet\"\n\n**Quando usar:** quando a tela demora para carregar ou não carrega.\n\n**Como aplicar:** pergunte, em tom preocupado, se o usuário está no Wi-Fi ou no 4G. Qualquer resposta confirma a teoria. Se ele estiver no cabo de rede, diga \"às vezes é o roteador\".\n\n#### 5. \"Já está em produção, só não apareceu ainda\"\n\n**Quando usar:** quando a correção prometida para sexta ainda nem começou.\n\n**Como aplicar:** diga que a correção \"já subiu\", mas que \"pode demorar um pouquinho para propagar\". O verbo propagar é essencial: ninguém sabe exatamente o que ele significa nesse contexto, e por isso ninguém o questiona. Use o tempo ganho para, enfim, fazer a correção.\n\n#### 6. \"Foi uma instabilidade momentânea\"\n\n**Quando usar:** quando o sistema ficou fora do ar por três horas e todo mundo viu.\n\n**Como aplicar:** em comunicado formal, com voz passiva. \"Foi identificada uma instabilidade momentânea, já normalizada.\" Nunca diga o que causou. Nunca diga quem causou. Se o comando sem `WHERE` do módulo 10 estiver envolvido, isso é especialmente importante.\n\n#### 7. \"Reinicia que volta\"\n\n**Quando usar:** como último recurso, quando nenhuma das anteriores funcionou.\n\n**Como aplicar:** peça para o usuário fechar tudo, desligar o computador, esperar dez segundos e ligar de novo. Enquanto isso, reinicie também o servidor, discretamente. Se voltar, o mérito é do reinício do usuário. Se não voltar, volte para o item 1.\n\n#### A ordem recomendada\n\nO Conselho recomenda aplicar as desculpas nesta sequência, para máxima economia de tempo: cache, internet, \"na minha máquina funciona\", reinicia que volta, instabilidade momentânea. \"Não é bug, é feature\" e \"já está em produção\" podem ser usadas a qualquer momento, como cartas coringa.\n\nUm cavalo bem treinado consegue atravessar uma semana inteira de chamados sem abrir o código uma única vez.","published":true}},{"id":"5da5cbe6-b0a8-4d34-bf20-20e76e04a7e9","type":"TEXT","title":"Estudo de caso: a semana das sete desculpas","position":4,"description":"Um chamado real do SisVendas 3.0, acompanhado do primeiro ao último dia, com o catálogo oficial aplicado em ordem.","availability":"AVAILABLE","text":{"body":"Segunda-feira, 9h12. Chamado aberto pela Dona Leonor: \"O botão de gerar boleto não funciona. Clico e não acontece nada.\"\n\n**Segunda, 9h40.** O Galdino responde: \"Bom dia! Pode limpar o cache, por favor?\" Ela limpa.\n\n**Segunda, 14h.** \"Limpei e continua.\" O Galdino: \"Agora o completo, por favor. E tenta numa aba anônima.\"\n\n**Terça, 10h.** \"Não funcionou na aba anônima.\" O Galdino: \"Estranho. Você está no Wi-Fi? Deve ser a sua internet.\"\n\n**Terça, 15h.** \"Estou no cabo.\" O Galdino: \"Às vezes é o roteador.\"\n\n**Quarta, 11h.** A Dona Leonor manda um vídeo do erro acontecendo na tela dela. O Galdino abre o sistema na máquina dele, clica no botão e o boleto aparece. \"Aqui na minha máquina funciona.\" (A máquina dele usa o banco de dados de desenvolvimento.)\n\n**Quinta, 9h.** O Seu Dagoberto pergunta se a correção sai até sexta. O Galdino responde à Dona Leonor: \"A correção já está em produção, só pode demorar um pouquinho para propagar.\"\n\n**Quinta, 16h.** A Bia, curiosa, abre os registros do servidor e encontra o erro em dois minutos: desde o deploy da sexta anterior, o sistema tenta gravar o boleto numa coluna que não existe em produção. É a mesma coluna criada à mão do módulo 9.\n\n**Sexta, 10h.** A correção é publicada de verdade. O Galdino escreve no chamado: \"Pode reiniciar o computador e tentar de novo?\" Ela reinicia. Funciona.\n\n**Sexta, 10h15.** O comunicado oficial da equipe: \"Foi identificada uma instabilidade momentânea no módulo de boletos, já normalizada.\" A instabilidade momentânea durou uma semana.\n\n**Análise do Conselho:** uma aplicação completa e ordenada do catálogo oficial, com seis desculpas em cinco dias e o reinício final recebendo todo o mérito da correção. O Conselho registra, com preocupação, que a Bia resolveu o problema lendo os registros do servidor, uma técnica que não consta deste manual.","published":true}},{"id":"803e8de3-dc8b-4a3e-907e-44d4efe841ad","type":"TEXT","title":"Na vida real: como comunicar um problema ao usuário","position":5,"description":"Fora do personagem: confirmar o problema, investigar de verdade, dar status com honestidade e prazo, e explicar o que aconteceu sem rodeios.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Quem relata um problema quer duas coisas: ser levado a sério e saber o que vai acontecer. Honestidade, mesmo quando a notícia é ruim, gera mais confiança que qualquer desculpa.\n\n#### 1. Agradeça e leve a sério\n\nToda reclamação de erro é uma informação valiosa e gratuita. Responda rápido, mesmo que seja só para dizer que recebeu e que está olhando.\n\n#### 2. Colete o que precisa para reproduzir\n\nEm vez de \"limpa o cache\", pergunte:\n\n- o que a pessoa estava tentando fazer;\n- o que esperava que acontecesse e o que aconteceu;\n- quando aconteceu, em qual tela e com qual usuário;\n- se tem um print ou vídeo, e qual navegador ou aparelho usa.\n\nLimpar o cache ou reiniciar podem, sim, resolver alguns problemas. Mas só sugira isso quando houver um motivo técnico, e nunca como forma de ganhar tempo.\n\n#### 3. Investigue onde o problema acontece de verdade\n\n\"Na minha máquina funciona\" geralmente quer dizer que a sua máquina é diferente da produção: outros dados, outra configuração, outra versão. Olhe os registros (logs) e o monitoramento do ambiente onde o erro aconteceu e tente reproduzir com as mesmas condições.\n\n#### 4. Dê status com honestidade\n\nDiga onde você está, sem inventar:\n\n- \"Confirmamos o problema e estamos investigando a causa.\"\n- \"Encontramos a causa. A correção deve sair até amanhã às 12h.\"\n- \"Ainda não sabemos a causa. Voltamos a falar às 16h, com ou sem novidade.\"\n\nSe der um prazo, cumpra ou avise antes que vai mudar. Nunca diga que algo está em produção se não está.\n\n#### 5. Ofereça um caminho enquanto isso\n\nSe existir um jeito alternativo de fazer a tarefa enquanto a correção não sai, explique. Isso reduz o impacto e mostra que você se importa com o trabalho de quem relatou.\n\n#### 6. Bug é bug\n\nSe o sistema não faz o que deveria, é um erro, e tudo bem dizer isso. Se o comportamento for de fato intencional, explique o motivo com clareza e esteja aberto a mudar se ele atrapalhar quem usa.\n\n#### 7. Depois que passar, explique\n\nPara problemas maiores, um comunicado curto e honesto vale mais do que \"instabilidade momentânea\":\n\n- o que aconteceu e quanto tempo durou;\n- quem foi afetado e o que foi afetado;\n- o que foi feito para resolver;\n- o que vai mudar para não acontecer de novo.\n\nDentro da equipe, faça uma conversa sem culpados: o objetivo é entender o que no processo permitiu o erro, não encontrar alguém para responsabilizar.\n\n#### Lista para conferir\n\n- Respondi rápido e agradeci o relato.\n- Coletei as informações para reproduzir.\n- Investiguei no ambiente onde o erro acontece.\n- Dei status honesto, com o próximo horário de atualização.\n- Cumpri o prazo ou avisei antes que ele mudaria.\n- Expliquei o que aconteceu e o que muda depois.","published":true}},{"id":"c04337b3-f25a-45ec-9632-b9ed9cdd6968","type":"QUIZ","title":"Revisão: como dar desculpa para o usuário","position":6,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"132ee639-f4c8-436b-bb5e-f649e413e874","finalAssessment":false}]},{"id":"bae41e6b-a070-42c6-ad06-9372d946b8bd","title":"Plano de fuga: LinkedIn","description":"Os axiomas avisam: quando o barco começar a afundar, esteja pronto para pular fora. Neste módulo você conhece o plano de fuga oficial da cavalaria: o currículo atualizado às pressas, o selo verde, o cargo inflado, o textão de uma frase por linha e, claro, o post do certificado de cavalo. Depois, na vida real, você aprende a montar um perfil profissional honesto que funciona.","position":12,"contents":[{"id":"57f2544e-41d1-4257-b1c7-8f363ce15ddc","type":"YOUTUBE","title":"O LinkedIn é mais fake do que você imagina","position":1,"description":"Do canal Limão Nada: os posts forçados, as vagas fantasmas e a cultura estranha da rede social profissional. Leitura obrigatória (em vídeo) para o plano de fuga. Cerca de 16 minutos.","availability":"AVAILABLE","youtube":{"videoId":"6DxTe1sWzBw","url":"https://www.youtube.com/watch?v=6DxTe1sWzBw","channelName":"Limão Nada","madeForKids":false,"availability":"AVAILABLE","channelId":"UCaJc2QLFDgO1AbTOBh31H3w","channel":{"handle":"@limolimao.5","description":"Reclamo de tudo que deixa a nossa vida mais azeda! E isso é tudo que você precisa saber.","avatarUrl":"https://yt3.ggpht.com/QZVNtCbIqBf-EonFT3h1eZyrm_W5r8GWhrXIRvs8ckfA8n5x3MJRzbGT2fZmlRkOkw3o66iNwQ=s240-c-k-c0x00ffffff-no-rj","subscriberCount":52400,"videoCount":31}}},{"id":"bb7ba75b-fb07-45bc-a4c9-36454e13dc7f","type":"TEXT","title":"Manual oficial do cavalo, capítulo 12: o plano de fuga","position":2,"description":"Quando acionar o plano, o perfil oficial do cavalo, os gêneros de post da cavalaria e a etiqueta dos comentários.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nTodo cavalo sabe que, um dia, o sistema vira um monstro. O cliente 4512 ganha vida própria, os backups não restauram e o Galdino marca férias. Nesse momento, o cavalo não tenta salvar o projeto. O cavalo atualiza o LinkedIn.\n\n#### Quando acionar o plano de fuga\n\nO Conselho identificou os sinais oficiais de que o barco está afundando:\n\n- O sistema tem mais tabelas `_bkp` do que tabelas de verdade.\n- A reunião do atraso passou a ter reunião de preparação.\n- Alguém pediu \"um documento explicando como o sistema funciona\".\n- O Seu Dagoberto começou a usar a palavra \"reestruturação\".\n\nAo primeiro sinal, ative o plano.\n\n#### O perfil oficial do cavalo\n\n**A foto.** Com o selo verde de \"Open to Work\" bem visível. Discrição é para quem não tem pressa.\n\n**O cargo.** Na cavalaria, ninguém é \"Desenvolvedor\". Os cargos oficiais são:\n\n| O que você faz | Como aparece no perfil |\n|---|---|\n| Corrige o `!important` do botão | Especialista em Experiência Visual Estratégica |\n| Roda o ajuste manual de segunda-feira | Engenheiro de Confiabilidade de Dados |\n| Responde \"limpa o cache\" | Head de Sucesso do Cliente |\n| Cola respostas do assistente de IA | Arquiteto de Soluções Disruptivas com IA |\n| Faz deploy na sexta às 17h | Líder de Entrega Contínua |\n\n**O resumo.** Um parágrafo com as palavras \"paixão\", \"resiliência\", \"inovação\" e \"fora da caixa\", sem nenhuma informação concreta.\n\n**As competências.** Liste tudo que já ouviu falar. Kubernetes, aprendizado de máquina, computação quântica. Depois, peça endosso para os contatos. Eles vão endossar, porque também querem ser endossados.\n\n#### Os gêneros oficiais de post\n\n**O anúncio solene.** Começa obrigatoriamente com \"Agradecido e honrado em anunciar\". Serve para qualquer coisa: emprego novo, certificado, a conclusão de uma etapa desta trilha.\n\n**A lição inesperada.** O formato mais nobre. Uma situação qualquer vira uma lição sobre liderança:\n\n> Hoje rodei um UPDATE sem WHERE em produção.\n>\n> 48 mil clientes receberam o mesmo boleto.\n>\n> E sabe o que eu aprendi?\n>\n> Que liderança não é sobre não errar.\n>\n> É sobre o WHERE que existe dentro de cada um de nós.\n>\n> Concorda?\n>\n> #liderança #resiliência #dados\n\nRepare na técnica: uma frase por linha, uma linha em branco entre elas e uma pergunta no final, para gerar comentários.\n\n**A lista de aprendizados.** \"Fui desligado e aprendi 7 lições sobre liderança.\" As sete lições são variações de \"acredite em você\".\n\n**O post do certificado.** O ápice do plano de fuga. Ao concluir esta trilha, o certificado de cavalo pode ser compartilhado no LinkedIn, acompanhado, segundo a doutrina, de um anúncio solene:\n\n> Agradecido e honrado em anunciar que concluí a Formação Oficial em Go Horse.\n>\n> Foram semanas de muito galope.\n>\n> Obrigado a todos que me apoiaram nessa jornada.\n>\n> #gohorse #xgh #aprendizadocontinuo\n\n#### A etiqueta dos comentários\n\nO cavalo comenta em tudo. O comentário oficial é \"Concordo!\". Variações aceitas: \"Excelente reflexão!\", \"Isso!\" e \"Faz total sentido\". Ler o post antes de comentar é opcional e, segundo os axiomas, desaconselhado.\n\n#### Os recrutadores\n\nO cavalo envia pedido de conexão para todos os recrutadores da plataforma, sem mensagem. Se algum responder, o cavalo manda o currículo em PDF chamado `curriculo_final_v3_agora_vai.pdf`.","published":true}},{"id":"328da187-8a48-42fc-bbad-2002dd07b620","type":"TEXT","title":"Estudo de caso: o Arquiteto de Soluções Disruptivas","position":3,"description":"Como o Galdino transformou o fim de semana do boleto da Maria num post de liderança, e o que aconteceu na primeira entrevista.","availability":"AVAILABLE","text":{"body":"Na segunda-feira seguinte ao episódio dos 48 mil boletos (veja o módulo 10), o Seu Dagoberto usa a palavra \"reestruturação\" numa reunião. O Galdino ativa o plano de fuga na mesma tarde.\n\n**Segunda, 15h.** Foto nova com o selo verde. Cargo atualizado de \"Desenvolvedor\" para \"Arquiteto de Soluções Disruptivas | Especialista em Dados | Líder Resiliente\".\n\n**Segunda, 15h20.** O Galdino adiciona dezessete competências ao perfil, entre elas \"Kubernetes\", que ele nunca usou, e \"Gestão de Crises\", que ele de fato praticou muito.\n\n**Terça, 8h.** Publica uma lição inesperada: \"Ontem um erro de dados afetou milhares de clientes. E sabe o que eu aprendi?\". São quatorze linhas, uma frase cada. Termina com \"Concorda?\". O post recebe 312 reações e 48 comentários \"Concordo!\".\n\n**Quarta.** O Galdino comenta \"Concordo!\" em 63 posts. Envia pedido de conexão para 140 recrutadores, sem mensagem.\n\n**Quinta.** Uma recrutadora responde e marca uma entrevista técnica. O Galdino envia o `curriculo_final_v3_agora_vai.pdf`.\n\n**Sexta, 16h.** Na entrevista, a pessoa entrevistadora pergunta:\n\n\"Vi que você é especialista em Kubernetes. Pode contar como usou no seu último projeto?\"\n\nO Galdino pede um minuto, diz que a internet está instável e pergunta se pode limpar o cache.\n\nNa semana seguinte, o Galdino publica um novo post: \"Não fui aprovado numa entrevista e aprendi 7 lições sobre resiliência.\"\n\nEnquanto isso, a Bia, que escreveu o procedimento do fechamento do mês, restaurou o backup e encontrou o erro dos boletos lendo os registros, coloca no perfil um texto curto sobre esses três trabalhos, com o que fez e o resultado. Recebe duas propostas.\n\n**Análise do Conselho:** o Galdino executou o plano de fuga com perfeição: selo, cargo, competências, textão e \"Concordo!\" em massa. O Conselho não consegue explicar o resultado da Bia, que não usou nenhuma técnica deste manual, e encaminhou o caso para estudo.","published":true}},{"id":"953df37b-d33a-468c-ba2a-c0246fcd272a","type":"YOUTUBE","title":"Como montar um perfil no LinkedIn que atrai oportunidades","position":4,"description":"Na vida real. Jonny Viccari mostra, passo a passo, como montar um perfil profissional que atrai oportunidades. Cerca de 18 minutos.","availability":"AVAILABLE","youtube":{"videoId":"rH_k0HX1SHs","url":"https://www.youtube.com/watch?v=rH_k0HX1SHs","channelName":"Jonny Viccari","madeForKids":false,"availability":"AVAILABLE","channelId":"UC1VegPLsP9Yb_0pIaGyRmAQ","channel":{"handle":"@jonnyviccari","description":"Uma visão sincera e analítica sobre a Creator Economy\n\n🏴‍☠️ Já trabalhei no mercado financeiro e em Startups e sendo bem sincero, não me encaixei em lugar nenhum, foi até que decidi desistir de tudo e começar a empreender. Nesse canal compartilho toda a trajetória do 0.\n\n🏴‍☠️ Sempre me senti perdido da carreira, aquela pergunta do que você quer ser quando crescer ainda me assombra a noite. Por isso esse canal foi feito, para compartilhar experiências e mostrar que você não está sozinho, eu também não sei qual é meu trabalho dos sonhos. \n","avatarUrl":"https://yt3.ggpht.com/i05RCJL6bR5xtrBadJVuQtXWLPjFPsw8260JZ8gmHyhy3UKj4Lh8BAtcKVaFV2KIn8mwTyWNAQ=s240-c-k-c0x00ffffff-no-rj","subscriberCount":148000,"videoCount":1390}}},{"id":"b27e9d46-623b-446e-9a7a-c02a9ac38d44","type":"TEXT","title":"Na vida real: um LinkedIn que funciona","position":5,"description":"Fora do personagem: perfil honesto e específico, projetos reais com resultado, competências que você tem, networking útil e posts que ensinam algo.","availability":"AVAILABLE","text":{"body":"Esta etapa é séria. Um perfil profissional funciona quando ajuda alguém a entender, em poucos segundos, o que você sabe fazer e como provar isso.\n\n#### 1. Título claro e honesto\n\nO título deve dizer o que você faz e com o que trabalha, sem inflar: \"Desenvolvedora back-end | Node.js e PostgreSQL\" diz muito mais que \"Arquiteta de Soluções Disruptivas\". Recrutadores e pessoas técnicas procuram por termos concretos.\n\n#### 2. Mostre trabalho real, com resultado\n\nA parte mais forte de um perfil são exemplos concretos. Para cada experiência ou projeto, conte:\n\n- qual era o problema;\n- o que você fez;\n- qual foi o resultado, de preferência com números.\n\n\"Escrevi o procedimento do fechamento mensal e automatizei a execução, que passou de um dia para dez minutos\" vale mais que qualquer lista de adjetivos. Projetos pessoais e de estudo também contam: deixe o link do repositório ou de uma demonstração.\n\n#### 3. Competências que você consegue sustentar\n\nListe o que você usa de verdade e conseguiria explicar numa entrevista. Se está aprendendo algo, diga que está aprendendo. Uma competência inventada costuma ser descoberta na primeira pergunta técnica.\n\n#### 4. Networking útil\n\n- Ao pedir conexão, mande uma mensagem curta dizendo quem você é e por que quer se conectar.\n- Converse com pessoas da área que você quer seguir e pergunte sobre o trabalho delas.\n- Ajude quando puder: indicar uma vaga ou responder uma dúvida também é networking.\n\n#### 5. Posts que ensinam algo\n\nSe quiser publicar, compartilhe o que aprendeu de forma concreta: um problema que resolveu, uma ferramenta que testou, um erro que cometeu e o que mudou depois. Comentários que acrescentam uma ideia ou uma pergunta valem mais que muitos \"Concordo!\".\n\n#### 6. Procurando emprego\n\nAtivar a indicação de que você está aberto a oportunidades é uma escolha pessoal, e a própria plataforma permite que ela fique visível só para recrutadores. Mais importante que o selo é ter o perfil atualizado e mandar um currículo curto, com nome de arquivo claro, como `curriculo-bia-dev-backend.pdf`, adaptado para cada vaga.\n\n#### Lista para conferir\n\n- O título diz o que faço e com quais tecnologias.\n- Cada experiência tem problema, ação e resultado.\n- Há pelo menos um projeto com link.\n- As competências listadas são as que consigo explicar.\n- Meus pedidos de conexão vão com uma mensagem curta.","published":true}},{"id":"3396f113-26d5-48db-991b-93eea2420241","type":"QUIZ","title":"Revisão: plano de fuga: LinkedIn","position":6,"description":"Perguntas com \"Modo cavalo:\" pedem a resposta mais XGH, segundo o manual. Perguntas com \"Vida real:\" pedem a prática correta. Você pode tentar quantas vezes quiser.","availability":"AVAILABLE","assessmentId":"84a1d672-c4c0-48f1-a5f6-ef73a9354e15","finalAssessment":false}]},{"id":"f929312b-8a5c-4e34-b481-68bbf54059f8","title":"Prova final: certificação de cavalo","description":"O momento solene chegou. A prova final reúne a doutrina e a vida real de todos os módulos da formação. Conclua todas as etapas e acerte pelo menos 70% da prova para desbloquear o certificado.","position":13,"contents":[{"id":"9308f142-b777-4a33-8abf-a87b4c3c6d2c","type":"TEXT","title":"Edital da certificação de cavalo","position":1,"description":"As regras oficiais da prova final e o que é preciso para desbloquear o certificado.","availability":"AVAILABLE","text":{"body":"Prezado participante,\n\nO Conselho Superior da Cavalaria tem a honra de convocá-lo para a prova final da Formação Oficial em Go Horse.\n\n#### O que cai na prova\n\nSão 15 perguntas de escolha única sobre todos os módulos: requisitos, prazos, gambiarra, código copiado, versionamento, documentação, testes, deploy, banco de dados, desculpas e o plano de fuga. As perguntas seguem a mesma regra das revisões:\n\n- **\"Modo cavalo:\"** pede a resposta mais XGH, segundo o manual.\n- **\"Vida real:\"** pede a prática correta.\n\n#### Como desbloquear o certificado\n\n1. Conclua todas as etapas da trilha.\n2. Faça a prova final e acerte pelo menos 70% das perguntas.\n\nPara ser aprovado, você precisa acertar pelo menos **70%** da prova. Você tem **3 tentativas por dia**: o cavalo também descansa. Se as tentativas do dia acabarem, revise os módulos e volte amanhã, de cabeça fresca.\n\nO Conselho tentou estimar o prazo de correção, mas a estimativa deu dois dias, então decidiu que a correção é automática.\n\n#### Orientações do Conselho\n\n- Um verdadeiro cavalo responde sem ler a pergunta até o fim. O Conselho, excepcionalmente, recomenda ler, principalmente o prefixo.\n- Se errar, não diga que a prova estava com cache. A prova não tem cache.\n- O certificado é emitido pela plataforma, e não como um print do terminal dizendo \"compilou\". Se for compartilhá-lo no LinkedIn, o Conselho não se responsabiliza pelo anúncio solene.\n\nBoa prova. Galope com sabedoria.","published":true}},{"id":"78fd021f-9b15-40db-b2f4-568cb4eb3aac","type":"QUIZ","title":"Prova final","position":2,"description":"Quinze perguntas sobre toda a trilha. \"Modo cavalo:\" pede a resposta mais XGH, segundo o manual; \"Vida real:\" pede a prática correta.","availability":"AVAILABLE","assessmentId":"5b5cd40d-acdc-41b6-9286-0994027be562","finalAssessment":false}]}],"communityAvailable":true,"contributionsEnabled":true,"creator":{"id":"48d11b36-3820-4bd3-ae47-633ab005f3e4","nickname":"lucascode","linkedinUrl":null,"instagramUrl":null,"avatarUrl":null},"contributors":[],"contributorCount":0}