Estante de cosecha: darle a los elementos publicados de Greenhouse un lugar donde caer

Greenhouse es mi gestor de proyectos creativos con opinión propia. Las ideas se capturan, maduran, se trabajan a través de un pipeline de etapas, y con el tiempo terminan guardadas en la bóveda (archivadas, reversible) o publicadas (release, terminado). El lado de la bóveda se construyó hace un tiempo: un contador en el pie, una vista de exploración, un botón de rescate. El lado de publicación nunca recibió el mismo tratamiento.

Una revisión completa de la app reciente lo detectó: publicar un proyecto era de solo escritura. La base de datos marcaba un elemento como released y estampaba un timestamp, pero ningún comando volvía a listar los elementos publicados. La insignia “Released” de ItemCard tenía toda una rama de switch-case para eso que nunca podía renderizar en la práctica, porque nada le entregaba jamás un elemento publicado. El diálogo de confirmación de Publish le decía a la persona desde dónde salía su proyecto, pero no adónde iba. Funcionalmente: a ningún lado. Toda la recompensa del pipeline, lo que la metáfora de la planta llama Fruiting, Harvest, era invisible.

Por qué esta forma

La vista de la bóveda ya era la plantilla correcta. Misma forma de problema: un estado que filtra elementos fuera de la lista de trabajo principal, un contador que necesita un indicador en el pie, una vista de exploración a pantalla completa que refleja el propio shell del dashboard en vez de abrir un modal. No quería inventar un segundo patrón cuando ya existía uno que funcionaba. Así que el plan fue mecánico: copiar el cableado de la bóveda, cambiar el estado y la dirección de orden.

Una decisión de diseño real: el orden de clasificación. La vista de bóveda ordena primero lo más antiguo en estado inactivo, porque el objetivo es sacar a la luz lo que lleva más tiempo esperando una decisión de Rescatar o Conservar. Cosecha no tiene ninguna decisión que tomar, es un estante de trofeos, no una cola, así que tuvo más sentido ordenar primero por publicación más reciente. Lo que interesa es ver arriba lo que se acaba de lanzar.

Implementación

Del lado de Rust: una consulta nueva, list_released_by_recency, que ordena por released_at DESC en vez del vaulted_at ASC de la bóveda. Un campo released_count en el struct de estado diario, calculado de la misma forma que el vaulted_count existente. Dos comandos nuevos de Tauri, get_released_items y open_harvest_folder, ambos copias casi idénticas de sus equivalentes de la bóveda.

El único lugar donde tuve que pensar de verdad en vez de copiar: publicar un proyecto es solo una transición de estado, nunca mueve la carpeta del elemento en disco. Un elemento publicado simplemente se queda donde lo dejó la etapa terminal del pipeline (su carpeta de etapa, por ejemplo 60-released/). Entonces “abrir toda la carpeta de cosecha” no puede reutilizar la ruta fija 90-vault/ de la bóveda, tiene que resolver la carpeta a la que apunta la última etapa configurada del pipeline, ya que eso depende de la configuración y no es una constante hardcodeada.

Del lado del frontend: un HarvestView.svelte nuevo, casi una copia directa de VaultView.svelte, menos el botón de Rescatar, no existe la opción de “despublicar” un proyecto, así que la única acción por elemento es Mostrar en Finder. Se agregó un campo released_at junto al vaulted_at existente para que ItemCard pudiera mostrar una duración tipo “Released 3d ago” junto a la insignia, de la misma forma en que ya muestra “Dormant 12d” para los elementos en bóveda.

Trampas

Agregar un campo a un struct compartido que se serializa directo al frontend (DerivedItemState) significa que cada fixture de prueba que lo construye a mano también necesita el campo nuevo, o la verificación estricta de object literals de TypeScript lo marca. Quince archivos tocados, y la lógica real de la función vivía en apenas seis de ellos. No es una queja, solo un recordatorio de que “agregar un campo” rara vez es un cambio de una línea cuando la cobertura de pruebas es real.

También manejé la app compilada de punta a punta con el arnés de WebDriver del proyecto en vez de confiar solo en la suite de pruebas. Sembré un elemento publicado directo en el archivo SQLite de una bóveda descartable, relancé la app real, e hice clic paso a paso: el pie decía “Harvest: 1 release”, la vista se abría, el elemento aparecía con su duración de publicación, y estaban los dos botones de Mostrar en Finder. Un IPC simulado en una suite de pruebas prueba que el cableado es internamente consistente, no prueba que un clic real a través de un webview real de verdad renderiza la cosa. Valió los diez minutos extra.

Resultado

Publicar un proyecto ahora lleva a algún lado. La rama muerta de la insignia ahora hace algo. Y hay un pequeño contador, deliberadamente simple, del tipo “esto es lo que se publicó”, justo al lado del indicador de la bóveda, que, para una herramienta cuya premisa de diseño completa es combatir el instinto de abandonar proyectos, se sintió como el tipo correcto de recompensa para hacer visible.