Jah 4.0.30 : le Tableau des quêtes se range en trois tiroirs

TL;DR

Ouvrir le Tableau des quêtes ne donne plus une seule longue liste. Il s'ouvre sur trois tiroirs : En cours (tes quêtes), Village (celles qu'on peut rejoindre), Souvenirs (celles déjà faites). Chaque carte affiche son avancement (anneau 0/2, 1/2…), le bouton qui compte est mis en avant, et pour retirer une quête il faut confirmer. « Épingler un coup de main » reste en bas, toujours sous la main. Le tout est parti en production à la main : 4.0.30 en ligne, /readyz confirmé, repli armé.

Ce que tu vois, toi

Tu ouvres le Tableau. Au lieu de tout mélanger, il est rangé en trois onglets :

• En cours — les quêtes que tu suis : tu vois d'abord ce qui te regarde.
• Village — les quêtes ouvertes que tu peux encore rejoindre.
• Souvenirs — celles déjà faites, rangées sans encombrer.

Sur chaque carte, un anneau montre où on en est (0/2, 1/2…), à côté d'un petit glyphe qui dit le type de quête. Le bouton important est mis en avant — « J'en suis » pour rejoindre, « C'est fait » pour valider. Et si tu veux retirer une quête, il te demande une seconde fois (« Vraiment ? ») : plus de fausse manip. En bas du Tableau, « Épingler un coup de main » reste accessible, collé au bas de la fenêtre.

Rien ne change dans le jeu lui-même : c'est la même mécanique de quêtes, lue plus clairement.

Pourquoi ça part maintenant

Le Tableau vivait dans le code depuis un moment, mais pas encore en ligne : la version en production était 4.0.29. Les runners GitHub sont toujours éteints (quota d'Actions), donc la chaîne habituelle tag → CI → image → deploy ne pouvait pas tourner. On l'a donc faite à la main, jusqu'à jah.vfg.lol — pour la sixième version d'affilée.

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

1. Version 4.0.30 : package.json, sw.js, les deux changelogs. La porte courte (check:pr, 1096 tests dont 1094 verts, 0 échec, audit propre) passe avant d'écrire quoi que ce soit. Le diff 4.0.29 → 4.0.30 est de l'interface seulement : le dialogue des quêtes, des styles, le service worker — aucun fichier serveur, aucune migration.
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 (a024280a…), puis on bâtit ghcr.io/fgdidou/jahmessenger:4.0.30 là-bas.
4. Sonder à l'écart, avant de toucher la prod : un conteneur jetable sur un port à part → /readyz = 4.0.30, /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. Pousser l'image dans le registre (4.0.30 et sha-8fae10044968, même digest que l'image sondée) grâce au login de FG (write:packages).
6. Déployer : bash deploy.sh jah 4.0.30 --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.29 (l'image est déjà sur le serveur).

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

/readyz répond 4.0.30. Le hub est running/healthy, RestartCount=0 (pas de boucle), la rotation des logs est bien json-file / 10 Mo / 3 fichiers, et jah.deployed porte 4.0.30. Le Tableau en trois tiroirs est donc bien celui que tu as sous les doigts.

Ce que ça dit de la méthode

• Préparé n'est pas servi. Fusionner n'est pas servir : la distance entre main et la prod se mesure, et il faut tout le chemin pour qu'un changement d'interface 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.29 sans rien reconstruire.

Live : 4.0.30. Les quêtes, rangées comme un journal.