Jah 4.0.29 : le tiroir du bas s’ouvre enfin sur tes salons

TL;DR

Le tiroir du bas de l’écran — celui qui glisse par-dessus le village — s’ouvre maintenant sur Salons, l’onglet le plus utile en jeu, au lieu de la liste de contacts. Contacts et Menu sont passés sur des onglets juste à côté. Le tiroir est plus court (48 % de la hauteur au lieu de 62 %) pour que tu voies mieux ce qui se passe derrière, et ton profil se replie d’un chevron. Le tout est parti en production à la main : 4.0.29 en ligne, /readyz confirmé, repli armé.

Ce que tu vois, toi

Tu es sur téléphone, dans le village. Tu tires la poignée en bas : le tiroir monte — mais cette fois il s’arrête sur Salons. Les endroits où l’on parle sont là tout de suite, sans avoir à chercher dans une liste de contacts qui ne sert qu’à ouvrir une conversation privée.

• Salons · Contacts · Menu : trois onglets en haut du tiroir, tu passes de l’un à l’autre d’un doigt.
• Le tiroir est plus bas qu’avant, pour ne pas manger le village.
• Ton profil se replie derrière un petit chevron : il ne prend plus la moitié de la place.

Rien d’autre ne bouge : sur ordinateur, la veilleuse et les fenêtres sont exactement comme avant.

Pourquoi ça part maintenant

C’était prêt dans le code, pas encore en ligne. Fusionner n’est pas servir : la version en production était 4.0.28, et le tiroir mobile attendait dans main. Les runners GitHub sont toujours éteints (quota d’Actions) : la chaîne habituelle tag → CI → image → deploy ne pouvait pas tourner. On l’a donc faite à la main, jusqu’à jah.vfg.lol.

Comment on l’a livrée (sans CI)

1. Bump 4.0.29 : package.json, sw.js, les deux changelogs. La porte courte (check:pr, 571 tests dont 569 verts, 0 échec, audit propre) passe avant d’écrire quoi que ce soit.
2. Aligner ops/* sur le serveur et vérifier par empreinte : les cinq sha256sum (compose, deploy, env, jah, probe) sont identiques local ↔ serveur. Cinq sur cinq, rien à recopier — mais on l’a mesuré, pas supposé.
3. Construire l’image sur le serveur. Le poste n’a pas Docker : on envoie une archive du source (git archive), on vérifie que son empreinte côté serveur est la même qu’en local (f633025c…), puis on bâtit ghcr.io/fgdidou/jahmessenger:4.0.29 là-bas.
4. Sonder à l’écart, avant de toucher la prod : un conteneur jetable sur un port à part → /readyz = 4.0.29, /ws sans cookie = 401, CSP conforme, non-root (uid 1000), backup OK, arrêt propre (exit=0). Tant que ces cases ne sont pas vertes, on ne déploie pas.
5. Déployer : bash deploy.sh jah 4.0.29 --backup. Backup vérifié, voile de maintenance posé avant l’arrêt du hub en place, recréation, sonde /readyz + /ws, levée du voile. En cas d’échec, retour tout seul à 4.0.28 (l’image est déjà sur le serveur).

Le résultat, vérifié de l’extérieur

/readyz répond 4.0.29. Le hub est running/healthy, RestartCount=0 (pas de boucle), la rotation des logs est bien json-file / 10 Mo / 3 fichiers, et le démarrage n’a appliqué aucune migration. Le tiroir neuf est donc bien celui que tu as sous les doigts.

Ce que ça dit de la méthode

• Préparé n’est pas servi. La distance entre main et la prod se mesure : on a livré un seul petit correctif d’interface, mais il fallait tout le chemin pour qu’il arrive jusqu’à ton écran.
• Hors CI, on reproduit les gardes à la main. Backup avant prod, sonde avant et après, repli armé, empreintes des fichiers d’ops. Un « ça devrait marcher » n’est pas une preuve.
• Un déploiement qu’on peut défaire d’une ligne est un déploiement tranquille : retour possible vers 4.0.28 sans rien reconstruire.

Live : 4.0.29. Le tiroir s’ouvre là où l’on parle.