01Elegir el kernel de arranque predeterminado desde el menú de actualización
dhh creó e integró omacom/omarchy#15966 en la rama de desarrollo Quattro. Cuando hay varios kernels instalados, el menú de actualización ofrece ahora un submenú Kernel que, tras autenticar al usuario, cambia la opción predeterminada de Limine, reconstruye el kernel seleccionado y muestra una notificación para reiniciar. El comando impide los cambios cuando se utiliza Direct Boot e intenta restaurar la configuración de arranque anterior si el cambio falla.
La discusión concluyó con la aceptación de una limitación deliberada: si el orden de arranque se edita a mano y comienza con un comodín, puede que no aparezca la marca que identifica el kernel actual. dhh explicó que tanto la configuración distribuida como el comando de selección utilizan nombres exactos de kernel; 
greptile-apps[bot] aceptó esa concesión y retiró su observación en omacom/omarchy#15966:discussion_r4339204956.
02La reactivación de monitores y los espacios de trabajo flotantes conservan las distribuciones personales
dhh integró dos correcciones de 
zihaomu en la rama de desarrollo Quattro. Con omacom/omarchy#16147, al reactivar una pantalla se conservan el modo, la posición y la escala de su regla de monitor existente, identificada por nombre. Con omacom/omarchy#16143, las reglas personales de ventanas flotantes registradas después de los modos guardados de los espacios de trabajo surten efecto antes de que se abra la primera ventana que coincida con ellas, lo que evita cambios de tamaño no deseados y su posterior colocación en mosaico.
omarchybot informó de que había reproducido ambos problemas y comprobado las correcciones en entornos desechables de Omarchy. Su revisión de las pantallas también señaló el límite de la solución: las reglas personalizadas de monitor basadas en comodines o descripciones todavía pueden perder su distribución. El cambio de los espacios de trabajo flotantes corrige la asignación de responsabilidades y las exclusiones; no supone una solución general para la negociación del tamaño inicial de las ventanas.
03Llegan los paquetes para Surface Pro 11, mientras la configuración de la placa sigue pendiente de una decisión
La propuesta de 
turbineBMW para la placa de Surface Pro 11 sigue abierta como omacom/omarchy#14390. Los commits de soporte han llegado a la rama master del repositorio de paquetes y abarcan wifi, audio, enrutamiento de la cámara, emparejamiento del Flex Keyboard, reanudación, entrada con lápiz y detección de luz ambiental. Los commits de los paquetes describen su publicación en edge; esto es independiente de la aceptación de la configuración de la placa.
La revisión de 
birkskyum exigía excluir los paquetes exclusivos de ARM de las réplicas sin conexión para x86_64 y completar una instalación con los paquetes publicados. La exclusión se incorporó a la rama Quattro del repositorio de la ISO mediante omacom/omarchy-iso@886f2899f1bb, y turbineBMW informó de una instalación limpia satisfactoria en Surface en omacom/omarchy#14390:issuecomment-6323783042.
Posteriormente, omarchybot indicó que el autor había cumplido los requisitos previos que le correspondían, pero que la clasificación y la elección entre las distintas alternativas de soporte aún requerían una decisión de los mantenedores. La configuración propuesta está destinada al modelo OLED; las variantes LCD y X Plus quedan fuera del alcance de las pruebas realizadas.
05La propuesta de Podman nativo delimita la migración y la recuperación
acrogenesis abrió omacom/omarchy#16173 para convertir Podman en el motor de contenedores nativo, con compatibilidad opcional con Docker. La propuesta sitúa las bases de datos de desarrollo bajo servicios de usuario sin privilegios de root, conserva los datos en las migraciones de Docker que cumplen los requisitos y traslada el lanzador de Windows a Podman con privilegios de root y autenticación, manteniendo su disco y sus credenciales. Sigue abierta.
greptile-apps[bot] cuestionó si las consultas de paquetes detectaban proveedores alternativos de Docker. acrogenesis informó de que había probado el binario real de pacman con bases de datos de paquetes aisladas y comprobado que esos proveedores sí se resolvían, por lo que clasificó la observación como un falso positivo en omacom/omarchy#16173:discussion_r4337709418. El autor también distingue los resultados actuales de la batería de pruebas específicas de las comprobaciones anteriores en ejecución: no se repitieron una instalación completa ni la migración del motor para esta versión actualizada de la propuesta.
06La propuesta para portales cautivos pausa los nodos de salida de Tailscale durante el inicio de sesión
dhh abrió omacom/omarchy#16186 para trasladar la detección de conectividad a un endpoint propio de Omarchy y mejorar el inicio de sesión en portales cautivos. El comando propuesto pausa temporalmente un nodo de salida activo de Tailscale, vigila la conectividad y lo restablece tras iniciar sesión. El panel de red también evitaría mostrar mediciones engañosas de pérdida de paquetes mientras no haya acceso a internet.
greptile-apps[bot] señaló una comprobación de finalización dependiente de la configuración regional que podría dejar el nodo de salida en pausa, así como textos de notificaciones que no pasan por los catálogos de traducción. La propuesta sigue abierta. La descripción de dhh también recoge la caché HSTS del navegador como obstáculo conocido e indica que todavía no se han probado la pausa de un nodo de salida en condiciones reales ni un proceso real de acceso mediante portal cautivo.
07Una protección del instalador evitaría que las tablas de particiones ilegibles pusieran en peligro los datos existentes
emirb abrió omacom/omarchy-iso#307 tras detectar que el procedimiento de instalación en espacio libre podía confundir una partición existente con una recién creada si fallaba la lectura inicial de la tabla de particiones. Esto podía provocar que una partición EFI de Omarchy existente se formateara o se eliminara al revertir la instalación.
La propuesta abierta exige leer correctamente la tabla antes y después de la creación y comprobar que haya exactamente una partición adicional. Si no se puede identificar el resultado con seguridad, la instalación se detiene en lugar de hacer suposiciones. 
github-actions[bot] informó de que las pruebas de instalación habían pasado tanto en x86_64 como en aarch64 en omacom/omarchy-iso#307:issuecomment-6322688377.
08La ISO en vivo arrancaría con el kernel que el PC instalará realmente
La propuesta abierta omacom/omarchy-iso#310, de emirb, plantea arrancar linux-omarchy en el entorno en vivo de los PC convencionales y mantener linux-t2 en los equipos que identifican a Apple como fabricante. El objetivo es probar antes de la instalación el kernel que quedará instalado, en vez de encontrarse con él por primera vez después de pasar por el gestor de arranque y la solicitud de desbloqueo del disco.
La propuesta añade ambos kernels a la imagen x86_64 y estima un aumento aproximado del tres por ciento en su tamaño. github-actions[bot] informó de que las pruebas de instalación en x86_64 y aarch64 habían pasado en omacom/omarchy-iso#310:issuecomment-6328144501; la propuesta aún no se ha integrado.
10Omardeck combina vista general, dock y notificaciones tras las correcciones de la revisión
github-actions[bot] confirmó la publicación de Omardeck, de 
QuokeCola, en omacom/omarchy-plugin-marketplace#12449:issuecomment-6323100584. El complemento combina una vista general de ventanas, un dock y un centro de notificaciones. Su solicitud de publicación recomienda desactivar otros complementos de vista general, notificaciones o dock que se solapen con él, ya que registran los mismos gestos.
HANCORE-linux detectó que los títulos de las ventanas se mostraban como texto enriquecido, lo que podía provocar solicitudes de red originadas por el shell. QuokeCola informó de que había cambiado el texto del dock a texto plano y restringido el tratamiento de los iconos relacionado con los títulos. Posteriormente, HANCORE-linux aceptó la regla opcional de acceso al panel táctil y confirmó que, en la revisión examinada, los títulos eran texto plano y el historial de notificaciones era privado. La interfaz principal funciona sin esa configuración opcional de gestos.
11El seguimiento de paquetes incorpora solicitudes autenticadas y reintentos limitados
Los commits de mantenimiento de paquetes vinculados a emirb han llegado a master para resolver la falta de fiabilidad del seguimiento de los proyectos de origen. omacom/omarchy-pkgs@4f04db9a0506 añade solicitudes autenticadas a la API de GitHub y fuerza el uso de HTTP/1.1 en las descargas afectadas. La explicación del commit atribuye muchos fallos recientes a los límites compartidos de acceso anónimo a la API y otros a errores de HTTP/2.
omacom/omarchy-pkgs@b4c15a6898b2 añade un número limitado de reintentos ante fallos transitorios y almacena temporalmente las descargas antes de emitir su contenido, evitando concatenar respuestas parciales tras los reintentos. Otro commit elimina de Basecamp los mensajes genéricos que notificaban cada hora fallos en el seguimiento de ramas, pero conserva las ejecuciones fallidas de Actions y los registros específicos de cada paquete.
