Reuniones que por fin puedes volver a encontrar: el lanzamiento del timeline

Para enero de 2026, los usuarios de GeekBye tenían un problema de historial. La app grababa y analizaba sus reuniones sin problema — y luego las archivaba en un dropdown. Un dropdown está bien para tres elementos. Para la reunión quince, «aquella entrevista del martes pasado» era una expedición arqueológica entre filas de aspecto idéntico. v1.7.3 — 64 commits entre mediados de diciembre y el 16 de enero — es la release en la que las reuniones se volvieron algo que por fin podías volver a encontrar.

(Una nota contable, porque el historial de git es honesto incluso cuando los números de versión no lo son: no existe tag de release v1.7.2. La versión se subió, pero el siguiente tag en salir fue v1.7.3, así que los arreglos de Windows de la era v1.7.2 viajaron en esta release.)

Del dropdown al timeline

El cambio estrella es un solo pull request: 12 archivos, +640 líneas, la mayoría un nuevo componente MeetingsTimeline de 381 líneas. El dropdown se convirtió en un timeline desplazable de tarjetas de reunión, agrupadas en cuatro buckets — Today, Yesterday, This Week, Older (hoy, ayer, esta semana, anteriores) — con fechas escritas como las diría un humano: Today, 2:30 PM, Yesterday, 2:30 PM, Mon, 2:30 PM para esta semana y Jan 5, 2:30 PM más allá. Cmd/Ctrl+K enfoca un cuadro de búsqueda que filtra por título. La vista de detalle de la reunión se convirtió en una página de navegación de verdad, así que los botones de atrás y adelante del navbar por fin significan algo, y el breadcrumb dejó de leer "Meetings / Meeting" y empezó a leer "Meetings / Interview with John" (truncado con puntos suspensivos, porque siempre habrá alguien que titule una reunión como una novela).

Con ello llegaron dos pequeñas mejoras de calidad de vida: un botón de borrar dentro de la vista de reunión (que te devuelve al timeline tras borrar, en vez de dejarte tirado en una página muerta), y la navegación automática — cuando una sesión de escucha termina con contenido real de transcripción, el dashboard se abre directamente en la página de detalle de esa reunión. Terminas la llamada, ves la reunión. Las sesiones que terminan vacías se borran en silencio en vez de ensuciar el timeline.

La carrera que creas al mejorar la navegación

Aquí viene la parte que el changelog no te cuenta. La lista de reuniones antigua tenía una costumbre: en cada carga, auto-seleccionaba la sesión más reciente. Inofensivo cuando la lista era un dropdown que apenas tocabas. Fatal en el momento en que las reuniones se volvieron una página por la que navegas: haces clic en la reunión n.º 5, un refetch en segundo plano termina, y la lista, servicial, selecciona la reunión más reciente — sobrescribiendo la elección que hiciste hace dos segundos. El arreglo no fue una guarda más lista; fue borrar la auto-selección por completo. Cualquier lista que seleccione cosas en nombre del usuario acabará peleándose con el usuario.

Quitarla destapó la segunda carrera. La navegación automática salta a una reunión en el instante en que su sesión termina — que puede ser antes de que esa sesión haya terminado de escribir en la base de datos SQLite local. Navega demasiado rápido y llegas a una reunión que todavía no existe. El arreglo que salió es un retraso de 500 milisegundos antes de cargar sesiones al llegar a la vista de detalle, y el manejador de navegación lleva sus propias coberturas — esperar al did-finish-load de la ventana más 100ms si el dashboard acababa de crearse, 50ms si ya estaba abierto. Nuestra lectura: la navegación al final de sesión cruza tres dominios de tiempo — la escritura en base de datos, la carga de la ventana y el montaje de React — y cada uno recibió su pequeño retraso. Funciona, y diremos sin rodeos que una pila de números mágicos es deuda honesta, no una victoria.

La captura de pantalla anterior a su propia reunión

Una suposición más murió en esta release: «las capturas pertenecen a una sesión si y solo si se tomaron durante ella». Perfectamente lógica. Falsa. Los usuarios reales pulsan Cmd+H sobre la oferta de trabajo, la agenda, el código que están a punto de discutir — antes de pulsar Start. La pestaña Report emparejaba capturas con el rango temporal de la sesión de forma estricta, así que esas capturas de preparación desaparecían del informe para el que se habían tomado. El arreglo amplió la ventana de emparejamiento 60 segundos antes del inicio de sesión. (La maquinaria de rangos temporales en sí es más antigua — salió discretamente en v1.6.15; la aportación de v1.7.3 es enseñarle que las reuniones empiezan un poco antes de empezar.)

Cinco arreglos en veintiocho minutos

La batallita de esta release no está en el timeline — está en el overlay de onboarding de Windows, y es una cadena de manual de «arreglar el arreglo»: cinco commits entre las 10:50 y las 11:18 de la misma mañana.

La ventana principal de GeekBye usa passthrough de ratón — un hook que conmuta el setIgnoreMouseEvents de Electron en cada movimiento del ratón para que los clics atraviesen las zonas transparentes. Durante el onboarding en Windows, ese hook se peleaba con el overlay del tutorial, y en el paso en que aparece la ventana del dashboard, la app se congelaba. Arreglo uno: hacer que el hook no haga nada mientras el onboarding está activo. La paz por el desarme.

Salvo que ahora los botones del onboarding no respondían, porque el reenvío de eventos mandaba los clics a la ventana del dashboard debajo del overlay. Los arreglos dos y tres trastearon con forward: false asistente por asistente. Luego llegó el commit que encontró la causa raíz de verdad: cuando la ventana del dashboard se abre, su manejador de arrastre reinicia la ventana principal a modo click-through — y el primer arreglo había vuelto pasivo el hook de passthrough, lo que significaba que no quedaba nada para corregir la interferencia. El arreglo real invirtió la estrategia: el hook ahora reafirma activamente setIgnoreMouseEvents(false) en cada movimiento del ratón durante el onboarding, precisamente porque código externo puede reiniciarlo en cualquier momento. También borró 75 líneas de los parches anteriores por asistente.

Y aun así hubo un quinto commit, porque ganar la guerra del input no es ganar la guerra del z-order: el overlay y el dashboard estaban en el mismo nivel always-on-top, y Windows eleva la ventana que recibe el foco. El overlay se movió a un nivel de ventana superior y vuelve a elevarse con un retraso después de que aparezca el dashboard. El arco merece recordarse: un arreglo pasivo que desarma a tu único defensor es peor que la pelea original.

Tres cosas que nos enseñó esta release

1. Las mejoras de navegación destapan bugs de estado. La carrera de auto-selección existía antes de v1.7.3; un dropdown simplemente nunca te dejaba sentirla. En el momento en que las reuniones se volvieron una página por la que navegas deliberadamente, cada pieza de código que seleccionaba cosas por ti se convirtió en un bug.
2. Los límites temporales alrededor de la intención del usuario necesitan holgura. Sesiones, grabaciones, informes — los usuarios actúan un poco antes y un poco después de la ventana oficial de la máquina. El buffer de 60 segundos para capturas es una línea que refleja cómo se comporta la gente de verdad.
3. Nunca vuelvas pasivo tu código correctivo. La congelación de Windows llevó cinco arreglos porque el arreglo uno apagó el único mecanismo que podía contrarrestar la interferencia externa. Si otro código puede romper tu invariante en cualquier momento, tu trabajo es reafirmarlo continuamente, no retirarte.

Para el capítulo anterior de la historia v1 — construir dos apps con marca desde esta única base de código — mira una base de código, dos apps: cómo hacer white-label sin bifurcar (v1.7.1); y para todo el arco, la anatomía de publicar software hasta la perfección.