Eliminar un bloqueo de enfriamiento que nunca fue fiel a la fuente

Greenhouse (mi gestor de proyectos creativos) salió en v1 con una regla que tomé directo del documento de diseño: después de tocar un proyecto activo, se bloquea durante 7 días. La idea venía del material sobre proceso creativo de Mike Monday, donde la incubación importa. Las ideas necesitan reposar antes de juzgarlas. Esa parte es cierta y sigue siendo cierta.

El problema es que apliqué el mismo período de reposo también a los proyectos activos, y esa parte nunca fue fiel a cómo funciona en realidad el material original, ni a cómo trabajo yo en realidad.

La brecha

Un spike volvió a chequear la afirmación contra dos cosas: mis propios dos años de práctica, y los escritos reales de Mike Monday. Ninguno coincidía con lo que había construido. En la práctica, se tocan entre 5 y 6 proyectos activos en un solo día, y el mismo proyecto se vuelve a tocar al día siguiente. Los propios posts de Monday describen el regreso diario al mismo proyecto como el punto central, una carrera contra el aburrimiento, no una semana libre obligatoria.

Así que el bloqueo de 7 días en proyectos activos no era incubación. Era lógica de incubación de ideas pegada en la etapa equivocada del pipeline.

El arreglo

El issue de seguimiento sacó el bloqueo por completo. El orden de rotación (lo que se tocó hace más tiempo sube a la cima de la lista de trabajo) ya existía y ya hacía la parte útil del trabajo, sin necesitar nunca un bloqueo duro detrás, la misma conclusión a la que apuntaba el desvío entre enfriamiento y rotación cuando surgió la pregunta por primera vez. La madurez de idea (7 días antes de poder juzgar una idea nueva) y la madurez de vault (14 días antes de que un elemento archivado entre en consideración para Rescue-or-Keep) quedan intactas. Esas son compuertas de incubación reales sobre decisiones reales, no trabajo de relleno encima de la rotación.

Del lado de Rust esto fue sobre todo eliminación: los campos is_cooling / cooldown_until / cooldown_remaining_secs en el estado derivado del ítem, la separación worklist/cooling en el ensamblador de estado diario, y las opciones de configuración cooldown_days y cooldown_on_promote. last_touched queda exactamente igual, ya que sigue siendo lo que maneja el orden de rotación y el historial de toques. Nada del esquema de la base de datos cambió. Todo esto resultó ser una interpretación en tiempo de lectura montada sobre datos que ya eran correctos.

La única decisión de diseño que no tenía tomada de antemano: cooldown_on_promote era comportamiento activo (un interruptor para si promover una idea también la hunde en la rotación), no código muerto, así que quitarlo fue una decisión real, no una limpieza. Opté por quitarlo por completo. Promover una idea nunca registra un toque, así que un proyecto recién promovido aterriza en la cima de la lista de trabajo como el ítem más descuidado, lo cual coincide con cómo se enmarca la promoción en el resto de la app: una decisión de trabajar, no el trabajo en sí.

Lección

El error no estaba en el código, estaba en traducir una idea bien fundamentada (la incubación importa) al alcance equivocado (cada etapa del pipeline) en vez del correcto (juzgar ideas específicamente). Barato de escribir, caro de notar, porque las pruebas que había escrito eran internamente consistentes. Solo codificaban correctamente la regla equivocada. Comparar un supuesto de diseño contra una carga de trabajo real sacó a la luz en un día lo que la revisión de código sola no habría logrado.