--- title: "Jah 4.0.30 : le Tableau des quêtes se range en trois tiroirs" subtitle: "Le Tableau se lit maintenant comme un petit journal : **En cours**, **Village**, **Souvenirs**. Chaque carte montre où on en est, le bouton utile est mis en avant, et retirer une quête demande confirmation. Sixième version livrée à la main, sans workflow : image construite et sondée sur le serveur, `deploy.sh` avec backup et retour arrière." date: 2026-10-07 time: "01:48" author: VFG publishedBy: code status: pub tags: ["vfjah", "jah", "interface", "deploiement", "agents"] --- ## 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.