genome pousse : celui qui pousse avance son propre clone, et sa console l'ignore

Le correctif de serveur_ops a eu sa preuve en conditions reelles : clone passe de 6367d85
a f9a20b0 chez les deux locataires, tache en changed, consoles reparties a 15h33m33 et
15h38m02 contre 15h16, sondes a 0. En la donnant, il a montre le cas qu'il ne couvre pas.

genome_pousser.yml fait avancer le clone du runner du SITE sans qu'aucun role ne passe :
c'est lui qui pousse, donc il recoit d'abord. Quand serveur_ops passera, le clone sera
deja a jour et la tache s'abstiendra a juste titre — l'hebergeur gardait le defaut corrige
chez ses locataires. Le playbook nomme deja la transition dans son verdict ; il en tire
maintenant la consequence et redemarre la console du site quand c'est le MOTEUR qui a
bouge. Un plan pousse ne coupe pas les pages ouvertes, et l'unite systemd est verifiee
avant de toucher au service.

Valide : --syntax-check contre l'inventaire du site et celui d'un locataire, ansible-lint
sur le playbook (profil production, 0 echec, 0 avertissement), condition de declenchement
eprouvee sur quatre cas dont le mode check.

Limite : le redemarrage de la console du site demande une poussee posterieure a ce commit,
il n'est donc pas encore observe. Son disque porte f9a20b0, sa console sert le code
charge a 15h16.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -1,5 +1,52 @@
 # CHANGELOG — Set-OPS
 
+## 2026-09-20 (5) — Celui qui pousse avance son propre clone
+
+**82 preuves dans le rapport du 17 septembre, non rejouées ici.** Le correctif de
+l'entrée `(4)` attendait sa preuve : il l'a eue en conditions réelles, et en la donnant
+il a montré le cas qu'il ne couvrait pas.
+
+### Le déclenchement, mesuré deux fois
+
+Le commit `f9a20b0` poussé sur la forge du site, rejouer `serveur_ops` chez les deux
+locataires a fait avancer leur clone de `6367d85` à `f9a20b0`. La tâche
+« Redémarrer la console quand le moteur a avancé » est passée en `changed` sur les deux :
+console de TechnoLibre repartie à 15h33m33 contre 15h16m49, celle de Chezlepro à 15h38m02
+contre 15h16m47. Les deux sondes rendent 0. **Le mécanisme a été vu fonctionner, pas
+simulé** — et la tâche s'était abstenue plus tôt le même jour, quand les clones étaient
+déjà au niveau de la forge.
+
+### Le site ne peut pas se voir avancer
+
+`genome_pousser.yml` fait avancer le clone du runner du site **sans qu'aucun rôle ne
+passe** : c'est lui qui pousse, donc il doit d'abord recevoir. Mesure du même jour — son
+clone est passé à `f9a20b0` pendant la poussée, sa console est restée démarrée à 15h16.
+Le correctif de `serveur_ops` ne peut rien pour lui : quand le rôle passera, le clone sera
+déjà à jour, et la tâche s'abstiendra à juste titre. L'hébergeur gardait donc précisément
+le défaut corrigé chez ses locataires.
+
+Le remède tient là où vit la cause. Le playbook nomme déjà la transition dans son verdict
+(`6367d85 → f9a20b0`) : il en tire maintenant la conséquence et redémarre la console du
+site quand c'est **le moteur** qui a bougé. Un plan poussé ne coupe pas les pages
+ouvertes, et un runner sans console n'est pas touché — l'unité systemd est vérifiée avant.
+
+**Personne d'autre que ce playbook ne sait que ce clone a avancé.** Une information qui
+n'existe qu'à un endroit doit y être utilisée, sinon elle se perd et le défaut se
+reconstitue au passage suivant.
+
+### Ce qui a été vérifié, et ce qui ne l'a pas été
+
+`--syntax-check` sur `playbooks/maintenance/genome_pousser.yml`, contre l'inventaire du
+site et contre celui d'un locataire ; `ansible-lint` sur le playbook (profil `production`,
+0 échec, 0 avertissement). La condition de déclenchement est éprouvée sur quatre cas :
+moteur avancé, moteur immobile, `DEPOT=` visant un plan seulement, et la boucle sans
+résultat du mode `--check`.
+
+**Le redémarrage de la console du site n'a pas encore été observé** : il demande une
+poussée du génome postérieure à ce commit. La console du site sert donc encore, à
+l'heure où ces lignes sont écrites, le code chargé à 15h16 — le disque, lui, porte
+`f9a20b0`. Aucune preuve du harnais rejouée, aucune voûte ouverte, aucune VM touchée.
+
 ## 2026-09-20 (4) — Le code sur le disque n'est pas le code servi
 
 **82 preuves dans le rapport du 17 septembre, non rejouées ici.** Les trois runners
@@ -62,9 +109,10 @@ rendu dans ses deux modes, sans reste Jinja, et passe `bash -n` ; son filtre d'
 éprouvé sur cinq formes d'adresses réelles. Le rôle est appliqué aux trois runners et la
 sonde rejouée sur chacun.
 
-**Le redémarrage automatique n'a pas été observé en conditions réelles** : les clones
+**Le redémarrage automatique n'était pas observé au moment d'écrire ces lignes** : les
-étaient déjà au niveau de la forge, la tâche s'est donc correctement abstenue. La preuve
+clones étaient déjà au niveau de la forge, la tâche s'est donc correctement abstenue.
-du déclenchement viendra au prochain génome poussé. Les trois consoles ont été redémarrées
+La preuve est venue le jour même, une fois ce commit poussé sur la forge du site — elle
+est mesurée dans l'entrée `(5)` ci-dessus. Les trois consoles ont été redémarrées
 à la main ce jour-là pour servir le code courant. Aucune preuve du harnais n'a été
 rejouée, aucune voûte ouverte, aucune VM créée ou détruite.
 

playbooks/maintenance/genome_pousser.yml

@@ -255,6 +255,42 @@
         label: "{{ item.depot }}"
         index_var: idx
 
+    # LE RUNNER DU SITE AVANCE SON PROPRE CLONE, ET SA CONSOLE NE LE SAIT PAS (2026-09-20).
+    #
+    # C'est LUI qui pousse, donc il doit d'abord recevoir : ce playbook fait avancer le
+    # moteur du site sans qu'aucun role ne passe. `serveur_ops` redemarre bien la console
+    # quand le clone avance, mais il ne verra jamais cet avancement-ci — le clone sera
+    # deja a jour quand il passera. Le site garderait donc une console servant l'ancien
+    # code, exactement le defaut corrige le meme jour chez les locataires.
+    #
+    # `python3 scripts/inventory_gui.py` lit son code au demarrage, et seulement la. Ce
+    # qui a avance doit etre relu, et personne d'autre que ce playbook ne sait qu'il a
+    # avance : le verdict ci-dessus nomme la transition, il suffit de l'ecouter.
+    - name: Retenir ce que le colis du moteur a fait bouger
+      ansible.builtin.set_fact:
+        genome_moteur_colis: >-
+          {{ (genome_recu.results | default([]))
+             | selectattr('item.dest', 'equalto', genome_moteur)
+             | map(attribute='stdout') | list }}
+
+    - name: Voir si ce runner sert une console
+      ansible.builtin.stat:
+        path: /etc/systemd/system/setops-gui.service
+      register: genome_console_unite
+
+    - name: Redémarrer la console du site quand son moteur a avancé
+      ansible.builtin.systemd:
+        name: setops-gui.service
+        state: restarted
+        daemon_reload: true
+      become: true
+      become_user: root
+      when:
+        - genome_console_unite.stat.exists
+        - genome_moteur_colis | length > 0
+        - (genome_moteur_colis[0] | from_json).avant
+          != (genome_moteur_colis[0] | from_json).apres
+
     # Le genome n'a pas a trainer en double sur la machine : ce qui compte est dans les
     # depots et sur la forge.
     - name: Retirer les colis