Nuevos reportes del choque entre Qt 6.12 y el singleton de color vuelven a dejar la interfaz de Omarchy en negro pese a un parche ya confirmado y sin fusionar, la cuenta omarchybot llega a 226 pull requests con 39 fusionados, dos parches rivales compiten por arreglar el bloqueo forzado de 1Password, Greptile revisa un parche nuevo a pesar de su pausa anunciada hasta el 21 de octubre, un pull request comparte las sesiones de Claude Code entre cuentas mientras el asiento de agente sigue sin decisión, el kernel Linux 7.3 cumple tres días sin una octava candidata y Fedora 45 llega a cinco días de su plazo sin tareas cerradas.
El issue #15525 y otros dos reportes del 15 de octubre repiten el mismo apagón de paneles que el pull request #15265 ya corrige desde hace tres días, sin que ningún mantenedor lo haya fusionado todavía.
El usuario garrett-fox abrió este 15 de octubre el issue #15525 en el repositorio de Omarchy: tras actualizar a Qt 6.12.0 en una MacBook Air con chip M1 de Apple, bajo Asahi Linux y Omarchy 4.0.3rc4-1, todos los paneles de la interfaz -el lanzador que abre con SUPER+ESPACIO, el atajo de teclas con SUPER+K, la barra superior y la pantalla de bloqueo- se quedan en negro, con el error "Property 'loadColors' ... is not a function" en el registro del sistema. El mismo día, los issues #15545 y #15521 describen el mismo síntoma en otros equipos, según sus propios títulos y fechas de apertura en el repositorio; el #15521 fue cerrado horas después como duplicado. La causa es la misma que esta sección documentó el 12 de octubre: el tipo Color que QtQuick 6.12 agrega de forma nativa choca con el singleton Color propio de la interfaz de Omarchy, y deja sin resolver cualquier referencia de color del tema. El pull request #15265, abierto el 13 de octubre para empacar la corrección en la versión 4.0.4, ya tiene una confirmación de que funciona: el usuario tozes escribió el 14 de octubre en la página del parche "please merge and ship it in a 4.0.4 point release / new bundle" -por favor fusionen esto y envíenlo en una versión 4.0.4 o un nuevo paquete-, después de probarlo en una Mac con Apple Silicon. David Heinemeier Hansson dejó una reacción de aprobación en la descripción del parche, pero eso no equivale a una fusión ni a una revisión formal, y el pull request sigue sin ningún comentario de revisión según la propia página. Al cierre de esta edición, siete días después de que el parche original llegara a la rama principal y uno después de la confirmación de que funciona, ningún mantenedor con permiso de fusión ha movido el pull request #15265. Costa Rica no reporta despliegues institucionales de Omarchy, pero la comunidad tica de software libre que sigue el canal estable del proyecto -personaje de la semana en esta sección- sigue expuesta al mismo apagón de paneles mientras ese backport no se publique.
El filtro author:omarchybot sobre los pull requests del repositorio de Omarchy, consultado hoy para esta edición, muestra 226 resultados en total: 175 todavía abiertos y 51 cerrados, de los cuales 39 fueron fusionados. El 14 de octubre esta misma sección reportó 222 parches totales y 38 fusionados, es decir que en 24 horas la cuenta abrió cuatro parches más y logró una sola fusión adicional -una tasa de aprobación que se mantiene cerca del 17%, prácticamente la misma que el día anterior. La cifra crece el mismo día en que la propia cuenta abre nuevos pull requests, como el #15522 -que deja que el medio de instalación de Omarchy precargue el idioma, el teclado y la zona horaria del sistema- y el #15519, ambos todavía sin revisión de un mantenedor humano al cierre de esta edición, según el listado público de pull requests. La automatización sigue produciendo volumen sin que la tasa de fusión se mueva de forma sustancial. Ningún mantenedor de Omarchy se ha pronunciado sobre si el cuello de botella de revisión se agravará mientras Greptile mantenga pausadas sus revisiones automatizadas, el tema que ocupa más adelante esta misma edición. Sin impacto local conocido al cierre de esta edición.
El usuario axelfontaine, autor original del issue #15180 sobre el bloqueo forzado de 1Password, abrió el 12 de octubre el pull request #15183, titulado "Respect 1Password's lock on device lock setting", que modifica el script omarchy-system-lock para que revise la llave security.autolock.onDeviceLock en el archivo de configuración de 1Password antes de ejecutar 1password --lock; si el archivo o la llave no existen, el comportamiento actual se mantiene sin cambios. La revisión automatizada de greptile-apps lo calificó con confianza de 5 sobre 5 sin señalamientos pendientes. El pull request no es la única propuesta sobre la mesa: el colaborador jandrusk señaló en los comentarios que el pull request #12784, abierto antes por otro colaborador, resuelve el mismo problema por una vía distinta -elimina el bloqueo forzado y usa un puente D-Bus para que 1Password reaccione a su propia señal-, de modo que los mantenedores de Omarchy deberán elegir entre dos parches que tocan el mismo archivo con enfoques distintos. Jandrusk sugirió además que el nuevo parche lea la ruta de configuración desde la variable XDG_CONFIG_HOME en vez de asumir siempre ~/.config, una corrección menor que axelfontaine no había incorporado al cierre de esta edición. Tres días después de que nekomario28 documentara la causa raíz -que el bloqueo de Omarchy nunca emite la señal estándar de logind que 1Password necesita para reaccionar a su propio ajuste-, el proyecto tiene ya una posible solución, pero ningún mantenedor con permiso de fusión ha elegido entre las dos rutas. 1Password es uno de los gestores de contraseñas más usados entre equipos de desarrollo en Costa Rica, por lo que cualquiera de los dos parches, una vez fusionado, sí tocaría flujos de trabajo locales en caso de que Omarchy gane adopción en el país.
La página de etiquetas del repositorio torvalds/linux en GitHub, revisada hoy para esta edición, no muestra ninguna candidata nueva ni la versión final desde que Linus Torvalds publicó v7.3-rc7 el 12 de octubre: tres días sin movimiento en el ciclo, el mismo punto donde esta sección lo dejó el 14 de octubre. La ventana de fin de semana en que Torvalds suele etiquetar cada candidata ya pasó sin una octava. Si el ciclo se cierra sin ella, la versión final debería salir el domingo 18 de octubre, según la expectativa que Phoronix reportó al publicar la rc7; si en cambio aparece una rc8, la fecha se correría al 25 de octubre. Se trata de información preliminar sobre una fecha todavía no confirmada por un lanzamiento real ni por una segunda fuente independiente al cierre de esta edición. El kernel Linux corre en la mayoría de los centros de datos en la nube y en Android, así que cualquier infraestructura usada por empresas costarricenses hereda este calendario de forma indirecta, a través de las distribuciones que empaquetan el kernel, sin que medie una decisión local.
El colaborador hermitokatt abrió este 15 de octubre el pull request #15543, "Share Claude's session task lists across accounts", que agrega el directorio tasks a la lista de carpetas compartidas (shared_dirs) que Omarchy vincula entre cuentas de usuario de Claude Code. El cambio corrige el issue #15437: aunque Omarchy ya comparte el directorio projects entre cuentas añadidas, el directorio tasks -donde Claude Code guarda la lista de tareas de cada sesión- no se compartía, de modo que retomar una conversación con claude --continue desde otra cuenta perdía las tareas asociadas. Según el propio autor, la prueba del cambio falla sin el parche y pasa con él; la revisión automatizada de greptile-apps lo calificó con confianza de 5 sobre 5 e impacto medio. El parche llega mientras otra pieza de la misma conversación sobre agentes de IA sigue sin avanzar: el pull request #15087, que propone un "asiento de agente" con escritorio, puntero y teclado propios para que un agente opere aplicaciones sin tomar el control del usuario, cumple ya varios días sin una decisión de los mantenedores desde que el colaborador jandrusk pidiera, el 13 de octubre, una revisión de seguridad dedicada al listado de permisos del intermediario Wayland. El propio autor, KewkLW, respondió que la decisión de enviarlo dentro del repositorio principal o mantenerlo experimental es, en palabras de jandrusk, "the maintainers' call" -la decisión de los mantenedores-, sin que ninguno con permiso de fusión se haya pronunciado todavía. La combinación de ambos expedientes muestra que Omarchy profundiza su integración con herramientas agénticas -compartir el estado de sesiones de Claude Code entre cuentas- al mismo tiempo que posterga la pregunta de seguridad sobre cuánto control delegarle a un agente dentro del propio escritorio. Costa Rica no reporta uso institucional de Omarchy ni de agentes de escritorio, pero cualquier desarrollador tico que use Claude Code sobre varias cuentas en su propio Linux encuentra en el pull request #15543 una solución directa a un problema que probablemente ya conoce.
— Un nuevo parche comparte el estado de sesiones de Claude Code entre varias cuentas, mientras la propuesta de darle a los agentes de IA un escritorio propio sigue sin decisión de los mantenedores.
El aviso que fija la pausa de revisiones automatizadas hasta el 21 de octubre sigue vigente, pero la misma cuenta automatizada completó hoy una revisión de 5 sobre 5 en otro parche del repositorio.
El issue #15333, que fija desde el 13 de octubre el aviso de que Greptile pausó sus revisiones automatizadas en el repositorio de Omarchy hasta el 21 de octubre, sigue abierto y sin cambios al cierre de esta edición. Pero la cuenta automatizada greptile-apps sí dejó, este mismo 15 de octubre, una revisión completa con confianza de 5 sobre 5 e impacto medio en el pull request #15543 -el que comparte las tareas de Claude Code entre cuentas, reportado en esta misma edición. La contradicción no tiene explicación pública: el aviso fijado en el issue #15333 dice que las revisiones solo se reanudan antes del 21 de octubre si un administrador de la organización activa el uso facturado del servicio, pero ningún mantenedor de Omarchy ha confirmado ese pago, y el propio issue no tiene comentarios nuevos desde el 13 de octubre. Es posible que la organización haya activado el uso facturado sin anunciarlo, que el aviso de pausa no cubra todos los repositorios o ramas de la organización, o que Greptile mantenga cupo residual para pull requests puntuales; esta sección no encontró, al cierre de esta edición, una explicación oficial para ninguna de las tres hipótesis. El episodio matiza la lectura de que la automatización de Omarchy depende por completo de un proveedor externo sin capacidad propia, como reportó esta sección el 14 de octubre: la operación real parece más desordenada que el aviso formal que la propia Greptile publicó. Sin impacto local conocido al cierre de esta edición: no hay registro de empresas costarricenses que dependan de Greptile para su propio flujo de revisión de código.
El hito "Fedora 45 release" en el repositorio de GitLab de la documentación de notas de lanzamiento de Fedora muestra, al cierre de esta edición, 17 tareas abiertas y 0 cerradas, con el hito en 0% completado, a cinco días de su fecha límite fijada para el 20 de octubre de 2026 -el mismo balance que esta sección reportó el 14 de octubre, sin movimiento visible en ese tablero específico durante ya varios días consecutivos de seguimiento. LinuxCompatible y Warp2Search habían reportado a comienzos de octubre que el congelamiento final ("final freeze") de Fedora 45 entró en vigor el 6 de octubre con solo dos bloqueadores aceptados -una imagen de Server para aarch64 de tamaño excesivo y una falla de autenticación WiFi vinculada al servicio de secretos oo7-, una señal de que el tablero de tareas de documentación, que es el que esta sección sigue, no necesariamente refleja el riesgo real para la fecha de lanzamiento. Fedora mantiene dos fechas de respaldo, el 27 de octubre y el 3 de noviembre, si el calendario se atrasa. El indicador real seguirá siendo si el proyecto confirma el lanzamiento el 20 de octubre como estaba previsto. Fedora es una de las bases de desarrollo más usadas en universidades y empresas de software en Costa Rica por su ciclo de soporte corto y predecible, así que un atraso en esta fecha retrasaría en cadena las actualizaciones de quienes la usan como entorno de trabajo local.
El jueves 15 de octubre repitió el patrón de la semana con un giro adicional: el choque entre Qt 6.12 y el singleton de color de Omarchy volvió a dejar paneles en negro en al menos tres reportes nuevos, pese a que el parche que lo corrige ya tiene confirmación de que funciona y sigue sin fusionarse. La cuenta automatizada omarchybot llegó a 226 pull requests propios con 39 fusionados, dos parches rivales compiten por arreglar el bloqueo forzado de 1Password, y un nuevo pull request que comparte las sesiones de Claude Code entre cuentas convivió con la noticia de que Greptile revisó ese mismo parche pese a su pausa anunciada hasta el 21 de octubre -una contradicción sin explicación oficial. Fuera de Omarchy, el kernel Linux sostiene su séptima candidata del ciclo 7.3 sin fecha confirmada de lanzamiento final, y el tablero de hitos de Fedora 45 llega a cinco días de su plazo sin una sola tarea cerrada. Ninguno de los dos casos es, por ahora, una alarma: son los relojes normales de un ecosistema que depende de voluntarios, fundaciones y proveedores externos de IA en partes desiguales, y que esta semana mostró más de una vez que lo que un aviso formal anuncia no siempre coincide con lo que ocurre en la práctica.