Removendo um lock de cooldown que nunca foi fiel à fonte

O Greenhouse (meu gerenciador de projetos criativos) lançou a v1 com uma regra que copiei direto do design doc: depois que você mexe num projeto ativo, ele trava por 7 dias. A ideia foi emprestada do material sobre processo criativo de Mike Monday, onde a incubação importa. Ideias precisam descansar antes de você julgá-las. Essa parte é verdadeira e continua verdadeira.

O problema é que eu apliquei o mesmo período de descanso também a projetos ativos, e essa parte nunca foi fiel a como o material de origem realmente funciona, ou a como eu realmente trabalho.

A lacuna

Um spike voltou para checar essa afirmação contra duas coisas: minha própria prática de dois anos, e os textos reais do Mike Monday. Nenhuma das duas batia com o que eu tinha construído. Na prática, 5 ou 6 projetos ativos são tocados num único dia, e o mesmo projeto é tocado de novo no dia seguinte. Os próprios posts do Monday descrevem o retorno diário ao mesmo projeto como o ponto central, uma corrida contra o tédio, não uma folga obrigatória de uma semana.

Então o lock de 7 dias em projetos ativos não era incubação. Era lógica de incubação de ideias colada no estágio errado do pipeline.

A correção

A issue de follow-up removeu o lock por completo. A ordenação por rotação (o item tocado há mais tempo sobe ao topo da lista de trabalho) já existia e já fazia a parte útil do trabalho, sem nunca precisar de um lock rígido por trás, a mesma conclusão que o desvio entre cooldown e rotação já apontava quando a questão surgiu pela primeira vez. A maturidade de ideia (7 dias antes de você poder julgar uma ideia nova) e a maturidade de vault (14 dias antes de um item arquivado voltar para revisão em Rescue-or-Keep) permaneceram intocadas. Esses são gates de incubação de verdade sobre decisões de verdade, não trabalho burocrático em cima da rotação.

Do lado do Rust isso foi principalmente exclusão: os campos is_cooling / cooldown_until / cooldown_remaining_secs no estado derivado do item, a divisão worklist/cooling no montador de estado diário, os parâmetros de config cooldown_days e cooldown_on_promote. O last_touched permaneceu exatamente como estava, já que ainda é o que direciona a ordem de rotação e o histórico de toques. Nada no schema do banco de dados mudou. A coisa toda acabou sendo uma camada de interpretação em tempo de leitura, colocada em cima de dados que já estavam corretos.

A única decisão de design que eu não tinha pré-decidido: cooldown_on_promote era comportamento vivo (um toggle para saber se promover uma ideia também a afunda na rotação), não código morto, então removê-lo foi uma decisão real, não faxina. Optei pela remoção completa. Promover uma ideia nunca registra um toque, então um projeto recém-promovido cai no topo da lista de trabalho como o item mais negligenciado, o que combina com a forma como a promoção é enquadrada em todo o resto do app: uma decisão de trabalhar, não o trabalho em si.

Lição

O bug não estava no código, estava em traduzir uma ideia bem fundamentada (a incubação importa) para o escopo errado (todo estágio do pipeline) em vez do certo (julgamento de ideia especificamente). Barato de escrever, caro de perceber, porque os testes que eu tinha escrito eram internamente consistentes. Eles só codificavam a regra errada corretamente. Checar uma premissa de design contra uma carga de trabalho real revelou em um dia o que só a revisão de código não teria revelado.