v0.50.1

Sécurité

• Images api-web et api-worker reconstruites pour curl 8.23.0-r0 (CVE-2026-92392, HIGH) : Trivy bloquait la
  publication de v0.50.0 côté API. Aucun changement de code.

v0.50.0

La page des pelles d'un événement passe en onglets, et le blind test gagne une page joueur par morceau.

Modifié

• Pelles de l'événement en onglets (41.57) : « Membres », « Distribuer » et « Blind test » sous l'en-tête et les
  chiffres, l'onglet ouvert dans l'adresse (?onglet=). Destinataires d'une distribution en choix segmenté, la
  sélection se coche dans l'onglet (tout cocher, tout décocher). Le bloc Blind test se range en « Accès » et « Gains »,
  avec des interrupteurs. Aucune migration.

App du blind test (archilan-blind-test, image latest)

• Musique sans sa version SiIvaGunner (41.55) : « Green Hill Zone (Beta Mix) » attend « Green Hill Zone » ; le
  correcteur ignore la version face à une musique. Rafraîchir le catalogue depuis la console après le déploiement.
• Page joueur par morceau (41.56) : bandeau avec les essais, saisie en tête, puis une carte par morceau (trouvé,
  manqué, mes erreurs). Migration de l'app Version20261026090000 (player_track.misses).

v0.49.0

Le blind test s'ouvre à tous les membres présents à l'événement, inscrits ou non.

Modifié

• Blind test sans inscription (41.54) : tout compte connecté entre dans le blind test pendant l'événement et
  gagne les mêmes pelles d'événement, sous le même plafond. Elles suivent la conversion commune de fin d'événement
  (10 % en or). Le code d'erreur not_registered du blind test disparaît.
• Interrupteur « Les non-inscrits gagnent des pelles » dans le bloc Blind test de l'admin des pelles, actif par
  défaut : coupé, les non-inscrits jouent pour le classement seulement (crédits refusés,
  unregistered_without_pelles). Une migration (Version20261025200000,
  blind_test_setting.pelles_for_unregistered).
• Admin des pelles de l'événement : la section « Membres » liste aussi les non-inscrits qui détiennent des pelles
  (mention « non inscrit »), hors distribution.

v0.48.0

La partie site du blind test pour sa console d'animation : l'app y trouve les événements à préparer, et les admins
d'archilan.fr y entrent avec leur compte. Le reste (console en 4 étapes, catalogue des œuvres, musique d'origine,
vues minimales, design du site) est dans l'app archilan-blind-test, publiée à part.

Ajouté

• Console du blind test depuis l'admin (41.46) : le bloc « Blind test » de l'admin des pelles affiche
  l'identifiant de l'événement (copiable) et « Ouvrir la console du blind test » quand l'app est configurée.
• Liste des événements pour la console (41.48) : GET /api/v1/integrations/blind-test/evenements, signé comme
  les autres appels de l'app ; l'animateur choisit l'événement au lieu de taper son identifiant.
• Animation par compte admin (41.53) : page /blind-test/animation et code à usage unique réservé aux admins
  (POST /api/v1/blind-test/animation/codes) ; l'échange revérifie le rôle et renvoie désormais role (player ou
  animator). Une migration (Version20261025160000, blind_test_login_code.event_id facultatif).

Modifié

• envs/blind-test.env.example et la doc de déploiement : REGIE_TOKEN devient un secours facultatif pour les PC
  de la salle ; nouvelle variable facultative YOUTUBE_API_KEY (clé YouTube Data API v3, vues minimales).
• Stories 41.47 à 41.53 du blind test.

v0.47.0

Le blind test de mashups est prêt à être déployé : l'app à part (dépôt archilan-blind-test) tourne à côté du site,
joue la musique depuis YouTube et connaît ses joueurs par leur compte archilan.fr.

Ajouté

• Déploiement de l'app de blind test (41.43, 41.44) : profil Compose blind-test (services blind-test et
  blind-test-credits, volume blind-test-data), envs/blind-test.env.example, variables BLIND_TEST_VERSION et
  BLIND_TEST_DOMAIN, procédure dans docs/deploiement-production.md (import de la playlist depuis le wiki
  SiIvaGunner, vérification des vidéos YouTube, régie et écran de salle).
• « Se connecter avec archilan.fr » sur l'app de blind test (41.45) : l'app renvoie le joueur sur le site, qui
  émet un code à usage unique (60 s) ; l'app l'échange de serveur à serveur contre l'identité du joueur inscrit.
  Le cookie de session du site ne quitte pas son domaine. Le bouton « Jouer au blind test » affiche aussi un QR
  code pour ouvrir l'app sur téléphone.

Modifié

• Lien du blind test (41.45) : le lien signé de 41.40 laisse place à la connexion par code.
  BLIND_TEST_APP_URL est désormais l'adresse de base de l'app, sans chemin. Une migration
  (Version20261024120000, table blind_test_login_code).
• Le contrôle d'accès au blind test répond « pas d'accès » sans erreur quand le membre ne peut pas jouer, et n'est
  plus appelé pour un visiteur anonyme.

v0.46.0

Le suivi en direct ne dévoile plus le contenu des emplacements, le détail d'une inscription s'ouvre de nouveau, et
le site est prêt pour le blind test de mashups du prochain événement.

Ajouté

• Blind test de mashups, côté site (41.40) : l'admin des pelles d'un événement gagne un bloc « Blind test »
  (interrupteur, pelles par source trouvée, plafond par membre). Un inscrit voit « Jouer au blind test » sur la page
  de l'événement pendant qu'il se joue ; le lien est signé par le site. L'app du blind test (service à part) crédite
  des pelles d'événement par un endpoint signé, idempotent et plafonné. Sans BLIND_TEST_APP_URL ni
  BLIND_TEST_SHARED_SECRET, le blind test reste indisponible.
• Jeux que je suis (38.23) : sur /compte/notifications, la liste des jeux suivis, avec « Ne plus suivre ».

Corrigé

• Fuite du suivi en direct (27.13) : le push Mercure du suivi d'un slot publiait l'objet de chaque emplacement
  (et les sphères même désactivées) sur un topic ouvert à tous les participants de la session, et en anonyme via
  l'overlay de stream. Il publie maintenant une vue brute pour l'admin et la vue joueur, sans contenu, pour les
  autres. En attendant la story 27.14, les toasts « objet reçu » des joueurs s'affichent sans couleur.
• Détail d'inscription admin (5.8) : la page plantait dès qu'une inscription avait des jeux (elle lisait
  encore les anciennes options) ; elle affiche le YAML de chaque slot. Déjà sur main par le hotfix #902.
• « Tout sélectionner » du catalogue d'événement (3.14) : la limite de slots par inscription ne bride plus
  l'ajout en masse de jeux au catalogue.

Sécurité

• L'API ne monte plus le socket Docker (17.34) : api-worker et api-migrations n'y ont plus accès ; seul
  l'orchestrateur pilote Docker.

Mise en prod

1. API et frontend 0.46.0. Migration (jouée par api-migrations) : Version20261024110000 (blind_test_setting).
2. Recréer api-worker (fin du montage du socket Docker) ; retirer DOCKER_HOST de envs/api.env (sans effet
   s'il reste).
3. Blind test : poser BLIND_TEST_APP_URL et BLIND_TEST_SHARED_SECRET dans envs/api.env le jour où l'app est
   déployée, puis redémarrer api-web.

v0.45.0

On peut suivre un jeu pour être prévenu de ses nouveaux apworlds, les sphères sont visibles sans spoil, et les
joueurs d'un événement récupèrent enfin leurs fichiers de génération.

Ajouté

• Suivre un jeu (38.22) : un bouton « Suivre ce jeu » sur la page d'un jeu. Chaque fois que le site met en place
  un nouvel apworld pour ce jeu (fichier admin, import GitHub ou mise à jour automatique), ceux qui le suivent
  reçoivent une notification : « Nouvel apworld pour {jeu} », ou « {jeu} est jouable sur le site » pour un premier
  apworld. Réglable dans les préférences (« Jeux suivis ») : cloche par défaut, push possible.
• Sphères visibles sans spoil (27.12) : les joueurs voient l'onglet Sphères de leur slot, emplacements seulement,
  sans ce qu'ils contiennent. Réglable dans la config des parties (privée, hebdo, événement), activé par défaut ; le
  propriétaire d'une partie privée garde toujours ses sphères. Nouvel onglet Sphères sur la page de slot d'une hebdo.
• Logs des conteneurs d'une session (17.33, orchestrateur 0.23.0) : l'onglet « Container » de l'admin d'une
  session devient « Logs » et affiche les logs du serveur AP, du bridge ou de la génération, rafraîchis toutes les
  5 s quand la session tourne. Le bouton « Créer » devient « Forcer le lancement ».

Modifié

• Fanfare de goal coupée par défaut (16.24) : sans choix enregistré, plus de musique à l'atteinte du goal ; le
  sélecteur de fanfare la réactive.
• Fanfare moins forte (16.25) : le volume passe de 0.30 à 0.12, et l'aperçu du sélecteur joue enfin le même
  niveau.

Corrigé

• Fichiers de génération des événements (17.32) : la section « Fichiers de patch » d'une inscription restait
  vide (ancien dossier local, nom de fichier attendu égal au slot). Elle lit l'archive de génération comme en partie
  privée, avec les mêmes règles (ses slots seulement, jamais la multidata ni le spoiler), dès la génération.
• Temps de partie jamais négatifs (32.24) : la durée d'une partie, le temps d'un joueur et le classement de
  vitesse partent du premier lancement du serveur, pas de la dernière relance.
• L'onglet Container ne marchait pas (17.33) : il visait un conteneur qui n'existe plus par un socket Docker que
  api-web n'a pas. Le code est retiré (ContainerController, FetchLogsJob, callback runner logs).
• Pokémon Noir et Blanc sans template (38.21, image archipelago 0.20.1) : worlds.world_sources manquait dans les
  scripts de chargement d'apworld.

Sécurité

• Couches Alpine reconstruites pour brotli-libs (CVE-2026-111497).
• Overrides pnpm : zod 4.6.6 (GHSA-mrhx-c7xc-m3w5), body-parser 2.4.0 (GHSA-27r3-jxmh-p828), undici 7.30.1
  (GHSA-xjj6-f33q-929c).

Mise en prod

Dans l'ordre :

1. Image orchestrateur 0.23.0 (route des logs ; sans elle l'onglet Logs affiche « orchestrateur trop ancien »).
   Image archipelago 0.20.1 si elle n'est pas déjà en place.
2. API et frontend 0.45.0. Migrations (jouées par api-migrations) : Version20261022100000 (premier lancement),
   Version20261024100000 (game_follow).
3. Redémarrer les workers (nouveau handler async de ApworldPromoted).
4. Pokémon Noir et Blanc : « Régénérer » le template, puis --reintrospect et app:games:backfill-locations.

v0.44.2

Sécurité

• Next.js 16.3.8 → 16.4.2 : corrige les failles publiées pour Next.js 16.0 à 16.4.0, dont deux critiques
  (une exécution de code à distance sans authentification dans les fonctions use cache, GHSA-673q-mjm6-r5xr) et
  un déni de service des Server Actions (GHSA-p3m5-59mp-jv5r). pnpm audit bloquait la CI frontend de toutes les PR.

Mise en prod

1. Déployer le frontend 0.44.2. Rien côté API.

v0.44.1

Corrigé

• Plus de manque de mémoire sur les listes de jeux (38.20) : depuis l'ajout des noms d'items (0.44.0), charger
  le catalogue décodait l'introspection complète de chaque jeu (YAML par défaut, options, lieux, items) et dépassait
  128 Mo. /admin/catalogue renvoyait une erreur 500 ; la page « mes slots » d'une partie privée, la sélection des
  jeux d'un événement, la vérification des mises à jour et les backfills étaient exposés au même problème.
  L'introspection vit maintenant dans sa propre table, chargée seulement pour le jeu qui en a besoin. Mesuré sur un
  catalogue de 664 jeux : 16 Mo pour la liste, contre 115 Mo avant.
• app:games:backfill-locations et app:games:backfill-option-types traitent les jeux un par un et ne gardent rien
  en mémoire entre deux jeux.

Mise en prod

1. Déployer l'API 0.44.1 : la migration Version20261022200000 déplace l'introspection vers la table
   game_introspection (service api-migrations, automatique).
2. Redémarrer les workers.
3. Optionnel : retirer le montage php-memory.ini (memory_limit = 1G) ajouté en attendant ce correctif.

v0.44.0

Les parties priv�es ont leur propre monnaie, les pelles de bronze, et les �diteurs de YAML savent importer un
fichier, le tester et compl�ter les noms d'items.

Ajout�

• Pelles de bronze des parties priv�es (41.36 � 41.39) : chaque joueur d'une partie priv�e a un solde de
  bronze propre � cette partie, jamais converti, br�l� � la fin de la partie. Il se gagne au lancement (20 par
  d�faut), � chaque check jou� (1) et au goal (25), montants r�glables par le propri�taire (0 coupe la source).
  Les co-joueurs d'un slot sont cr�dit�s chacun. Release, collect et checks apr�s le goal ne paient pas. En partie
  priv�e, hints et primes se paient uniquement en bronze ; l'or reste pour la boutique. Une prime pos�e en or avant
  la mise en prod est vers�e ou rendue en or.
• Import d'un YAML dans les �diteurs (9.57) : chaque �diteur de YAML (profils, slots, hebdos, events) accepte
  un fichier existant. La structure est v�rifi�e et normalis�e (poids, random, valeurs nomm�es), les options
  inconnues sont signal�es, et une g�n�ration de test confirme que le YAML passe avant de l'enregistrer.
• Autocompl�tion des noms d'items (9.58, image archipelago 0.20.0, orchestrateur 0.22.0) : les options qui
  attendent des items (start_inventory, start_hints, local_items...) proposent les noms et groupes d'items
  du jeu, et un nom inconnu est signal�.
• Pages publiques rafra�chies � la modification (34.10) : modifier un �v�nement ou un article rafra�chit tout
  de suite sa page publique, au lieu d'attendre jusqu'� 5 minutes.
• V�rification des mises � jour d'apworlds en arri�re-plan (38.18) : la v�rification tourne dans le worker et
  ne bloque plus l'admin ; une seule v�rification � la fois.

S�curit�

• Images API sur PHP 8.5.12 (PHP2Shell, CVE-2026-109618 / CVE-2026-109619, d�j� livr� en 0.43.1 et 0.43.2), avec
  le patch PHP �pingl� dans le tag FrankenPHP. La mitigation provisoire session.upload_progress est retir�e.
• Couches Alpine reconstruites pour libx11 (CVE-2026-88806) et libexpat (CVE-2026-77214).

Mise en prod

Dans l'ordre :

1. Images archipelago 0.20.0 puis orchestrateur 0.22.0.
2. envs/api.env : FRONTEND_INTERNAL_URL=http://archilan-frontend:3000 et REVALIDATE_SECRET ;
   envs/frontend.env : le m�me REVALIDATE_SECRET (openssl rand -hex 32). Vide = pages rafra�chies toutes les
   5 minutes comme avant.
3. API et frontend 0.44.0. Migrations (jou�es par api-migrations) : Version20261018100000,
   Version20261018110000, Version20261018120000, Version20261019100000, Version20261019110000.
4. Red�marrer les workers (nouveaux messages async).
5. Remplir le catalogue d'items : app:games:backfill-option-types --reintrospect puis
   app:games:backfill-locations.
6. V�rifier : app:frontend:revalidate events ne doit r�pondre ni Disabled ni Rejected.