Rescue-or-Keep: construindo a zona de vault para o Greenhouse

O Greenhouse nunca apaga nada. Colocar um projeto no vault deve parecer um ato positivo e reversível, sementes dormentes, não fracasso, e o ritual diário traz à tona um único item há muito dormente e pergunta: resgatar, ou deixar como está. Antes desta issue, nada disso tinha interface. Você colocava algo no vault e ele simplesmente… ficava lá. Nenhuma forma de ver o que estava no vault, nenhuma forma de puxar algo de volta, e colocar no vault nem sequer movia os arquivos do item para lugar nenhum, então “navegar pelo vault” teria aberto uma pasta vazia.

As duas decisões

Duas coisas precisavam ser resolvidas antes de eu poder escrever código, e as duas foram decisões de julgamento genuínas, não escolhas óbvias por padrão.

Primeira: colocar algo no vault deveria realocar a pasta do projeto para um diretório 90-vault/ de verdade, ou só virar uma flag de status e deixar os arquivos onde estavam? Meu padrão teria sido deixar tudo no lugar, mudança menor, raio de impacto menor. Mas toda outra transição de status neste app (promover, avançar um estágio, mover entre estágios) já realoca a pasta como parte da mudança. A consistência venceu, então colocar algo no vault agora realmente move seus arquivos para dentro dele, e resgatar move eles de volta para onde vieram, o estágio antigo de um projeto ativo, ou a pasta de ideias se nunca tivesse sido promovido.

Segunda: o que “Keep Vaulted” realmente faz? Meu primeiro instinto foi chamar o mesmo comando de vault de novo, já que revaultar algo que já está no vault parece um no-op. Não é. A revisão diária escolhe o único item mais dormente ordenando por quando foi colocado no vault. Chame o vault de novo e você reseta esse timestamp para agora mesmo, o que significa que o item que você acabou de escolher deixar quieto some silenciosamente da revisão pelo tempo que for a janela de maturidade do vault. Peguei isso antes de escrever qualquer código, felizmente, rastreando de verdade o que “no-op” significaria para a ordem de classificação. O Keep Vaulted acabou sendo uma decisão puramente local, uma flag de “dispensado nesta sessão” sem nenhuma chamada ao backend. O item volta amanhã, já que nada nele de fato mudou.

O que me surpreendeu

O quase-erro com o “Keep Vaulted” foi a parte mais interessante desta sessão. É o tipo de bug que nunca apareceria num teste manual rápido, já que um único clique parece idêntico, tenha ele reestampado o timestamp ou não, e só apareceria dias ou semanas depois como “por que essa coisa que eu mantive no vault nunca mais voltou para revisão”. Registrei isso como uma nota própria, já que o formato do erro se generaliza: toda vez que uma ação de “pular” ou “dispensar” considera chamar o mesmo comando que produziu o estado atual, vale checar se esse comando escreve um timestamp que outra coisa usa para ordenar.

Onde isso chegou

O Rescue restaura um item para onde ele estava, ativo no estágio antigo, ou de volta como uma ideia nova, e realoca sua pasta para bater com isso. Uma nova visão de navegação pelo vault lista tudo que está atualmente dormente, cada um com seu próprio botão Rescue, seguindo o mesmo padrão de navegação em janela cheia que a visão de detalhe do projeto estabeleceu alguns dias atrás. Um indicador “Vault: N itens” torna o vault descobrível a partir do dashboard, em vez de ficar escondido atrás de um único card de revisão. Tudo isso verificado com testes unitários, testes de componente, uma checagem de acessibilidade e um click-through real via WebDriver que confirmou que a pasta realmente se moveu no disco, não só que uma linha do banco de dados mudou.