Meus produtos novos não começam do zero. Começam de um clone.

Em 7 de novembro, decidi ter uma base própria para os meus produtos, num repositório só, privado e marcado como template no GitHub, sempre na última versão do main. Começar um produto apontando para o repositório e o commit de outro pode arrastar decisões que só fazem sentido naquele produto. Começar do zero pode repetir erros de conta, publicação e operação.

A base traz o que todo produto precisa e nenhum produto

A base entrega um site e um app em inglês e português, entrada na conta, a conta com cópia dos dados e exclusão, a área do operador atrás do Cloudflare Access, e-mail, pagamentos e IA atrás de adaptadores com fakes que funcionam. Ela traz também erros e analytics depois do consentimento, retenção, alertas e runbooks, com a publicação rodando da minha máquina. Nenhum produto mora dentro dela, e cada clone apaga o que não usa.

O Garfim e dois produtos que ainda não apresentei aqui nasceram antes da base e não são clones dela. Um produto já criado também não recebe a base de novo de forma automática.

A regra de volta mantém a base viva sem misturar os produtos. Uma melhoria genérica feita num produto, como uma correção de segurança, um portão ou um padrão de operação, volta para a base num commit e numa linha do changelog. O que pertence ao domínio de um produto fica só naquele produto e nunca entra na base.

O rename troca slug, nome e domínio em todo o repositório

Quem começa um produto clona a última versão do main da base para o repositório próprio, com histórico novo. Depois roda bun install e bun rename <slug> "<Display Name>" <domain>, informando o slug, o nome de exibição e o domínio do produto novo. O comando troca o slug em cada nome de recurso, como workers, filas, buckets e o banco local, troca o nome de exibição onde o produto é nomeado e troca example.com em todo o repositório.

O rename também renova a chave do IndexNow e formata o que ele mudou. Depois dele, confiro o git diff e preencho o que o comando não tem como saber, como os dados de infraestrutura e a entidade legal do produto novo. A partir daí, escrevo o SRS na pasta de especificação e moldo a base ao produto, removendo telas, procedimentos, tabelas e e-mails que ele não precisa.

A prova da troca vem com bun rename:check, incluído no gate da base. O comando renomeia uma cópia real do repositório e roda a checagem de tipos e a suíte inteira dela, e o gate da base executa essa prova. Num repositório já renomeado, o comando reconhece o estado, pula a prova e avisa, porque a base já provou a troca na cópia dela.

Seis rodadas de revisão fecharam a base no mesmo dia

O changelog da base registra seis rodadas de revisão em 7 de novembro, além da versão inicial cortada de um produto que ainda não apresentei aqui. Duas dessas rodadas aparecem nos exemplos abaixo, no Postgres do gate e na lista de exceções do gitleaks. Registrar cada rodada no changelog deixa visível o que um produto futuro pode querer trazer da base.

Um exemplo está no Postgres que o gate sobe para os testes. Cada execução marca o container com um rótulo aleatório próprio e remove só os containers que carregam aquele rótulo. Com dois gates rodando ao mesmo tempo, uma execução que falha por colisão de nome encerra sem tocar no banco da outra.

A exceção do gitleaks libera um achado por vez

O outro exemplo está na lista de exceções do gitleaks, a ferramenta que procura segredo no código. A lista passou a liberar um achado por regra e pelo valor exato dele, e parou de liberar por linha. Na versão 8.30, uma exceção por linha deixava passar todos os achados de um arquivo inteiro quando qualquer linha dele casava com a exceção, e o teste da base roda o scanner de verdade para provar o comportamento.

Clonar a base encurta o começo e mantém cada produto dono do próprio domínio. O próximo passo dessa organização está em publicar da minha máquina, onde conto como a publicação roda daqui.