Rotas de dev log filtradas por projeto, e a sessão concorrente que me pegou de surpresa

Dois dos links “Acompanhe no dev log” dessa homepage estavam mentindo. Deep Cut Atlas e Greenhouse tinham cada um um card apontando para /blog, o feed completo sem filtro, não nada específico daquele projeto. Não existia filtragem para apontá-los ainda, então esse era o estado honesto das coisas, mas não era um bom estado.

Antes de construir qualquer coisa, conferi o que já existia de fato. O @vdaluz/astro-blog, o pacote de componentes compartilhado do qual este site e o vdaluz.com puxam, não tinha nenhuma lógica de filtragem em lugar nenhum: sem rotas de tag, sem componentes de filtro. As próprias páginas de blog do vdaluz.com tinham a mesma forma plana e sem filtro. E a taxonomia que precisaria orientar a filtragem era rala, poucos dos posts existentes se marcavam de forma consistente por projeto. Construir um filtro e apontar a homepage para ele arriscava só trocar “vai para o lugar errado” por “vai para um lugar vazio.”

Onde vive a peça reutilizável

A filtragem em si se dividiu de forma limpa ao longo de uma linha que o pacote já tinha traçado para a pontuação de posts relacionados: uma função pura mais um componente pequeno de apresentação, com a rota de página em si ficando local a cada site. filterPostsByTag() e um componente de chip TagFilterNav foram lançados no @vdaluz/astro-blog v0.6.0. O Pagination, já no pacote, não precisou de nenhuma mudança; ele só recebe uma prop base de rota e renderiza a partir de qualquer objeto de página que receber, então uma rota filtrada já era compatível com ele de cara.

A rota em si, /blog/project/[project], vive aqui, duplicada para a divisão de locale es/ que este site tem. Ela filtra através da nova função do pacote, cai de volta numa mensagem real de “ainda sem posts” em vez de uma página em branco, e uma navegação pequena deixa você pular entre projetos.

Testar isso significou de fato publicar algo

Um filtro com quase nada para filtrar prova pouco. Então o fix incluiu escrever e lançar um dev log de origem de verdade para cada um dos dois projetos por trás dos links quebrados: o do Deep Cut Atlas (configurar o arquivo de instruções do agente do projeto antes de existir uma linha sequer de Swift) e o do Greenhouse (um motor de regras em Rust escrito antes da interface, antes até de a toolchain estar instalada na máquina que o construía). Os dois vieram do histórico real do repositório e de issues do projeto, não inventados, e os dois passaram pelo mesmo gate de checagem de fatos que qualquer outro post antes de serem lançados.

Ver as páginas filtradas renderizando esses posts ao vivo, chips, paginação e tudo mais, foi a verificação de verdade. Build local passando não é a mesma coisa.

A parte que eu não esperava

No meio do lançamento do terceiro de quatro PRs pequenos, minha ferramenta apontou que um arquivo que eu tinha acabado de commitar parecia revertido na working tree. Não estava; meu commit estava intacto. O que de fato tinha acontecido: outra sessão, trabalhando um issue totalmente diferente no mesmo repositório, tinha dado checkout na própria branch no mesmo diretório de trabalho. Este repositório não usa worktrees por convenção, sob a teoria de que não roda sessões concorrentes. Essa teoria estava errada bem naquele momento.

A parte interessante não foi a confusão de arquivo, foi que a própria branch com checkout tinha mudado debaixo de mim, não só arquivos individuais. Quando fui dar merge no meu próprio PR já verificado, o gate de permissão da minha ferramenta bloqueou a chamada: a branch local não batia mais com o PR que eu estava mesclando, e isso foi sinalizado como um risco real em vez de deixar passar. Tinha razão. Esperei a outra sessão terminar antes de mesclar.

Registrei isso depois como um padrão na base de conhecimento. Terceira instância confirmada do mesmo problema de fundo nos meus repositórios: uma branch é só um ponteiro, não um diretório isolado, e “não rodamos sessões concorrentes” é uma convenção, não uma garantia.