Abrir o código de um projeto pequeno

Antes de abrir o código, separei o Owl do trabalho do dia a dia. Eu já via que ele não seria o único projeto pessoal, então criei um espaço só para os projetos que faço por diversão.

Ele não estava pronto

Eu não achava o Owl pronto, e ainda não acho. Quero olhar para ele com calma e ver como ele pode ajudar mais no dia a dia. Talvez ele saia das sessões do Claude e vire um notificador para outras coisas, mas por enquanto é só ideia.

Também não achava ele ruim a ponto de esconder. Tem outros apps parecidos por aí, e o Owl é pequeno, mas funciona bem o bastante para eu seguir usando ele. Pensei que alguém podia esbarrar nele e gostar. Não fui divulgar em lugar nenhum, só deixei aberto.

Nada para vazar

Abrir o código não me preocupou. O Owl não guarda nada que seria um problema se vazasse. Ele conversa com o próprio computador e com as notificações do sistema.

Antes de publicar, pedi ao Claude para ver se tinha algo que não deveria estar ali, e confiei no que ele disse. Agora, escrevendo este post, pedi uma nova conferência no código e no histórico inteiro. Não apareceu caminho da minha máquina, senha, chave nem nada do trabalho.

As escolhas práticas

Publiquei na minha conta pessoal do GitHub, que era o caminho mais fácil. Pedi ajuda ao Claude com a licença e fiquei com a MIT, a mais comum e simples para software livre.

O README ficou em inglês. Se era para mais gente usar, fazia sentido escrever numa língua que mais gente lê, e isso também ajuda quem quiser contribuir.

Onde eu testei as coisas

Foi no Owl que eu testei o Claude e aprendi sobre apps de Mac. Também foi nele que encontrei limites, dele e meus. E foi ele que me deu vontade de escrever esta série.

No próximo post, conto como pedi para o Claude revisar meu código e a revisão virou 48 issues.