01Choisir le noyau de démarrage par défaut depuis le menu Update
dhh a rédigé et intégré omacom/omarchy#15966 à la branche de développement de Quattro. Lorsque plusieurs noyaux sont installés, Update propose désormais un menu Kernel qui, après authentification, modifie le choix par défaut de Limine, reconstruit le noyau sélectionné et affiche une notification proposant de redémarrer. La commande refuse tout changement sous Direct Boot et tente de restaurer la configuration de démarrage précédente en cas d'échec.
La discussion a entériné une limite délibérée : lorsque l’ordre de démarrage a été modifié à la main et commence par un caractère générique, la coche indiquant le noyau actuel peut rester absente. dhh a expliqué que les paramètres fournis et la commande de sélection utilisent les noms exacts des noyaux ; 
greptile-apps[bot] a accepté ce compromis et retiré son signalement dans omacom/omarchy#15966:discussion_r4339204956.
02La réactivation des écrans et les espaces de travail flottants préservent les dispositions personnalisées
dhh a intégré deux correctifs de 
zihaomu à la branche de développement de Quattro. Avec omacom/omarchy#16147, la réactivation d’un écran préserve le mode, la position et l’échelle définis par sa règle existante, qui le désigne par son nom. Avec omacom/omarchy#16143, les règles personnelles de fenêtres flottantes enregistrées après les modes d’espace de travail sauvegardés prennent effet avant l’ouverture de la première fenêtre correspondante, évitant un redimensionnement indésirable puis un passage en mosaïque.
omarchybot a indiqué avoir reproduit les deux problèmes et vérifié les correctifs sur des instances de travail Omarchy jetables. Sa revue de la gestion des écrans en a également précisé la limite : les règles personnalisées utilisant un caractère générique ou une description peuvent encore perdre leur disposition. La modification des espaces de travail flottants corrige l’attribution de la gestion et les exclusions ; elle ne constitue pas un correctif général de la négociation initiale de la taille des fenêtres.
03Les paquets Surface Pro 11 arrivent, mais la configuration de la carte attend une décision
La proposition de 
turbineBMW pour la carte de la Surface Pro 11 reste ouverte sous la référence omacom/omarchy#14390. Les commits nécessaires à sa prise en charge ont rejoint la branche master du dépôt de paquets. Ils couvrent le Wi-Fi, l’audio, le routage des caméras, l’appairage du Flex Keyboard, le comportement à la sortie de veille, la saisie au stylet et la détection de la lumière ambiante. Les commits des paquets font état d'une publication sur edge ; celle-ci est distincte de l’acceptation de la configuration de la carte.
La revue de 
birkskyum exigeait d'exclure les paquets réservés à ARM des miroirs hors ligne x86_64 et de mener à bien une installation à partir des paquets publiés. Cette exclusion a été enregistrée sur la branche Quattro du dépôt ISO dans omacom/omarchy-iso@886f2899f1bb, et turbineBMW a signalé la réussite d’une installation neuve sur Surface dans omacom/omarchy#14390:issuecomment-6323783042.
omarchybot a ensuite indiqué que les prérequis à remplir par l’auteur étaient satisfaits, mais que la classification et le choix entre les approches concurrentes de prise en charge nécessitaient encore une décision des responsables du projet. La configuration proposée vise le modèle OLED ; les variantes LCD et X Plus restent hors du périmètre testé.
05La proposition de Podman comme moteur natif précise les limites de migration et de récupération
acrogenesis a ouvert omacom/omarchy#16173 pour faire de Podman le moteur de conteneurs natif, avec une compatibilité Docker facultative. La proposition place les bases de données de développement sous le contrôle de services utilisateur sans privilèges root, préserve les données lors des migrations Docker admissibles et fait passer le lanceur Windows à Podman avec privilèges root et authentification, tout en conservant son disque et ses identifiants. Elle reste ouverte.
greptile-apps[bot] a mis en doute la capacité des requêtes de paquets à détecter les fournisseurs alternatifs de Docker. acrogenesis a indiqué avoir testé le véritable binaire pacman avec des bases de paquets isolées et constaté que ces fournisseurs étaient bien résolus, qualifiant le signalement de faux positif dans omacom/omarchy#16173:discussion_r4337709418. L’auteur distingue également les résultats actuels de la suite de tests ciblée des observations antérieures en conditions d’exécution : une installation complète et une migration du moteur n’ont pas été refaites pour cette version remaniée de la proposition.
06La proposition sur les portails captifs suspend les nœuds de sortie Tailscale pendant la connexion
dhh a ouvert omacom/omarchy#16186 pour transférer la détection de connectivité vers un point de terminaison propre à Omarchy et améliorer la connexion aux portails captifs. La commande de portail proposée suspend temporairement un nœud de sortie Tailscale actif, surveille la connectivité et le rétablit après la connexion. Le panneau réseau éviterait également d'afficher des mesures trompeuses de perte de paquets lorsque l’accès à Internet est indisponible.
greptile-apps[bot] a signalé un contrôle de fin dépendant des paramètres linguistiques, susceptible de laisser le nœud de sortie en pause, ainsi que des chaînes de notification qui contournent les catalogues de traduction. La proposition reste ouverte. La description de dhh mentionne aussi les règles HSTS mises en cache par le navigateur comme un obstacle connu et précise que la suspension effective d'un nœud de sortie et un parcours réel de connexion à un portail captif n’ont pas encore été testés.
07Une protection de l’installateur empêcherait les tables de partitions illisibles de mettre en danger les données existantes
emirb a ouvert omacom/omarchy-iso#307 après avoir repéré un cas d’installation dans l’espace libre susceptible de confondre une partition existante avec une partition nouvellement créée en cas d’échec de la lecture initiale de la table de partitions. Une partition EFI Omarchy existante pouvait alors être formatée ou supprimée lors du retour en arrière.
La proposition ouverte exige que la lecture de la table réussisse avant et après la création, avec exactement une partition supplémentaire. Si le résultat ne peut pas être identifié avec certitude, l’installation s’arrête plutôt que de procéder au jugé. 
github-actions[bot] a indiqué que les tests d’installation avaient réussi sur x86_64 comme sur aarch64 dans omacom/omarchy-iso#307:issuecomment-6322688377.
08L’ISO live démarrerait avec le noyau qui sera effectivement installé sur le PC
La proposition ouverte omacom/omarchy-iso#310 de emirb prévoit de démarrer linux-omarchy dans l’environnement live sur les PC ordinaires, tout en conservant linux-t2 pour les machines qui déclarent Apple comme fabricant. L’objectif est de mettre à l’épreuve le noyau destiné à être installé avant l’installation, plutôt que de le découvrir pour la première fois après le chargeur d'amorçage et l’invite de déverrouillage du disque.
La proposition ajoute les deux noyaux à l’image x86_64 et estime l’augmentation de sa taille à environ trois pour cent. github-actions[bot] a indiqué que les tests d’installation x86_64 et aarch64 avaient réussi dans omacom/omarchy-iso#310:issuecomment-6328144501 ; la proposition n’a pas été intégrée.
11Le suivi des paquets gagne des récupérations authentifiées et des tentatives limitées
Des commits de maintenance des paquets associés à emirb ont rejoint master pour fiabiliser le suivi des sources amont. omacom/omarchy-pkgs@4f04db9a0506 ajoute des requêtes authentifiées à l’API GitHub et impose HTTP/1.1 pour les récupérations concernées. L’explication du commit attribue nombre d’échecs récents aux quotas partagés de l’API pour les accès anonymes, et d'autres à des erreurs HTTP/2.
omacom/omarchy-pkgs@b4c15a6898b2 ajoute un nombre limité de nouvelles tentatives en cas d’échec transitoire et stocke temporairement les téléchargements avant d’en transmettre le contenu, évitant ainsi la concaténation de réponses partielles après plusieurs tentatives. Un commit complémentaire supprime de Basecamp les messages génériques d’échec du suivi horaire des branches, tout en conservant les exécutions Actions en échec et les journaux propres à chaque paquet.
