Dos notas que nadie vio jamás

Greenhouse tiene dos lugares donde se puede escribir una nota propia. Al capturar una idea, se puede anotar un boceto rápido de qué es. Al registrar un touch en un proyecto, se puede dejar una nota de traspaso, una especie de “carta al yo futuro” sobre dónde se quedó el trabajo. Ambas se guardan. Ninguna de las dos aparecía jamás en ningún lado de la app.

El problema de la nota de captura era estructural: el campo existía en cada item, pero el tipo de wire que envía los datos del item al frontend, lo que renderiza cada card del dashboard, simplemente no lo incluía. La UI no tenía ningún bug escondiendo la nota, no había dónde en los datos para que la nota siquiera llegara. Eso significaba que cada decisión de Vault-o-Work, seguir trabajando en esto o guardarlo, se tomaba solo con el nombre de un proyecto, a veces uno generado automáticamente si no se le había puesto nombre.

La nota de traspaso era un tipo de omisión distinto. Esos datos fluyen bien, están ahí en el historial de touches, y ya existe un comando que los devuelve. El diálogo donde en realidad convendría leerla, el que aparece justo cuando se está por registrar un nuevo touch y retomar donde se había quedado, simplemente nunca la pedía. Construí el mecanismo de entrega y después nunca conecté de vuelta el lado de lectura.

Arreglar ambas fue sobre todo cerrar esa brecha en vez de inventar plomería nueva. Dos campos agregados al tipo de item compartido, poblados con datos que ya estaban ahí. Un fetch agregado al diálogo de touch al abrirse, best-effort, si falla simplemente no aparece el banner, eso no bloquea el registro del touch. Un botón de mostrar en Finder y una duración de “inactivo desde hace” agregados a la única card a la que le faltaba lo que ya tenía cada otra card.

Una decisión de diseño que tomé en el camino: si “inactivo desde hace” debía calcular la hora actual dentro del componente, o recibirla como un valor pasado desde afuera. Opté por pasarlo desde afuera, usando el reloj real por defecto cuando nadie provee uno. Es la misma regla que el backend de este proyecto ya sigue para cualquier cosa basada en tiempo: nunca llamar al reloj del sistema desde dentro de una función que se quiera probar de forma determinista. Una prueba puede pasarle un número fijo y verificar contra un string exacto en vez de escribir un regex que solo espera que el límite del día no caiga mal.