CHANGELOG 5.12 : entrées raccourcies

Chaque entrée dit en une ou deux phrases ce qui change pour l'administrateur
ou les membres ; le détail des bugs reste dans les messages de commit.

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

CHANGELOG.md

@@ -10,47 +10,47 @@ Les versions les plus récentes sont en haut. Chaque entrée commence par un ré
 
 ### Changements
 
-- **Journal réglable.** `LOG_LEVEL` choisit le détail du journal (`DEBUG` pour enquêter, `INFO` par défaut). `LOG_FILE=off` n'écrit que sur la console, utile en conteneur où elle est déjà collectée. Le démarrage affiche aussi `MAX_TOKENS`, `API_TIMEOUT` et les chemins complets du journal, de l'historique et de la personnalité.
+- **Journal réglable.** `LOG_LEVEL` choisit le détail du journal (`DEBUG` pour enquêter, `INFO` par défaut), et `LOG_FILE=off` n'écrit que sur la console, pratique en conteneur. Le démarrage rappelle aussi les principaux réglages et les chemins des fichiers.
 
-- **Plusieurs images dans un même message.** On peut envoyer jusqu'à 4 images à la fois : Rika les voit toutes, dans l'ordre, et peut les comparer ou parler de « la deuxième ». Les images d'un message cité ou transféré sont lues elles aussi, jusqu'à 4. Si une image pose problème, le message d'erreur dit laquelle (la première dans l'ordre du message si plusieurs échouent). Dans la mémoire, les images d'un message tiennent en un seul repère (« 4 images jointes »). Un PDF reste seul, sans image.
+- **Plusieurs images dans un même message.** Rika lit jusqu'à 4 images à la fois, dans l'ordre, y compris dans un message cité ou transféré, et peut les comparer ou parler de « la deuxième ». Si une image pose problème, le message d'erreur dit laquelle. Un PDF reste seul, sans image.
 
-- **Un message de démarrage plus soigné.** Le bloc « Bot en ligne » affiche maintenant l'avatar du bot, sa version, le modèle Claude utilisé (« Sonnet 5.5 ») et l'heure du démarrage, sur le vert du statut « en ligne » de Discord.
+- **Un message de démarrage plus soigné.** Le bloc « Bot en ligne » affiche l'avatar du bot, sa version, le modèle Claude utilisé (« Sonnet 5.5 ») et l'heure du démarrage.
 
 ### Corrections
 
-- **L'image Docker n'est plus publiée si les tests échouent.** Chaque push sur `main` construisait et poussait l'image sur Docker Hub (`latest`, celle de la production, et le sha du commit) sans lancer les tests : une régression partait directement en production. Le workflow GitHub installe maintenant Python 3.15 (la version du Dockerfile) et les dépendances, puis lance `python -m unittest` ; si un test échoue, l'image n'est ni construite ni poussée.
+- **L'image Docker n'est plus publiée si les tests échouent.** Chaque push sur `main` lance maintenant les tests avant de construire l'image : une régression ne part plus en production.
 
-- **Deux bots ne tournent plus en boucle.** Rika répond aux autres bots quand ils la mentionnent ou répondent à l'un de ses messages, sans aucune limite : face à un bot qui répond à tout avec « Répondre » (et donc la pinge), chaque réponse déclenchait la suivante, avec un appel à Claude toutes les quelques secondes jusqu'à ce que quelqu'un coupe un des bots. Elle ne répond plus à plus de 5 messages de bots d'affilée dans un salon ; le compte repart de zéro au premier message d'un membre dans ce salon, ou après 10 minutes sans message de bot. Le journal le signale une fois par série.
+- **Deux bots ne tournent plus en boucle.** Face à un bot qui lui répond à chaque fois, Rika pouvait enchaîner les réponses, et les appels à Claude, sans fin. Elle s'arrête maintenant après 5 messages de bots d'affilée dans un salon, jusqu'au prochain message d'un membre ou après 10 minutes de calme.
 
-- **Une rafale de mentions ne lance plus un appel par message.** Hors du salon dédié, chaque mention lançait son propre appel à Claude, en parallèle : 10 « @Rika ? » envoyés en 5 secondes dans #général donnaient 10 appels, chacun avec ses 20 messages de contexte, puis 10 réponses à la suite. Les mentions fonctionnent maintenant comme le salon dédié : une seule réponse à la fois par salon, et les mentions arrivées pendant qu'elle écrit partent ensemble dans l'appel suivant, avec leurs pièces jointes (deux appels au lieu de dix). La réponse groupée relit aussi celle que Rika vient de poster : elle ne se répète pas et ne se contredit pas. Si une pièce jointe est refusée, seule cette mention est retirée. Les mentions reçues pendant une absence reçoivent aussi une seule réponse au lieu d'une par message.
+- **Une rafale de mentions ne lance plus un appel par message.** Comme dans son salon, les mentions envoyées pendant que Rika écrit, ou pendant une absence, reçoivent une seule réponse groupée, qui tient compte de celle qu'elle vient de poster : 10 « @Rika ? » d'affilée coûtaient 10 appels à Claude, ils en coûtent maintenant deux.
 
-- **Erreurs de démarrage : toutes d'un coup, et dans `bot.log`.** Le bot s'arrêtait à la première variable fausse du `.env` : avec trois erreurs, il fallait trois redémarrages. Il les liste maintenant toutes. Le message n'était écrit que sur la console : il va aussi dans `bot.log` quand `LOG_FILE` est utilisable, pour qu'un redémarrage raté y laisse une trace. Enfin, un PC hors ligne ou une panne de Discord au démarrage donnaient une longue trace technique ; le bot dit maintenant « Impossible de joindre Discord : vérifie la connexion Internet » ou « Discord semble en panne ».
+- **Erreurs de démarrage plus claires.** Toutes les erreurs du `.env` sont listées d'un coup, au lieu d'une par redémarrage, et elles sont aussi écrites dans `bot.log`. Sans Internet, ou si Discord est en panne, un message clair remplace la trace technique.
 
-- **Un `.env` entre guillemets marche aussi sous Docker.** `docker run --env-file` garde les guillemets que le bot retire en local : `DISCORD_TOKEN="abc"` donnait « Token Discord invalide » sous Docker. Le bot retire maintenant lui-même une paire de guillemets autour d'une valeur. Le README précise que `--env-file` ne retire pas les commentaires en fin de ligne, et que le `.env` est prioritaire sur une variable passée en ligne de commande.
+- **Un `.env` entre guillemets marche aussi sous Docker.** `DISCORD_TOKEN="abc"` donnait « Token Discord invalide » avec `docker run --env-file` : le bot retire maintenant lui-même les guillemets. Le README explique les autres différences de `--env-file`.
 
-- **« Réflexion : off » n'est plus affiché à tort.** Sur un modèle dont la réflexion ne peut pas être coupée (Opus 5.5), `THINKING=off` laissait la réflexion active alors que le journal de démarrage affichait « off ». Il indique maintenant « impossible à couper sur ce modèle (règle EFFORT) ».
+- **« Réflexion : off » n'est plus affiché à tort.** Sur Opus 5.5, dont la réflexion ne peut pas être coupée, le journal de démarrage indiquait « off » avec `THINKING=off` ; il dit maintenant que c'est impossible sur ce modèle.
 
-- **Documentation des réglages alignée.** `.env.exemple` et le README précisent qu'un `THINKING` vide ou absent vaut `off` (l'exemple propose `on`) ; le README indique que `xhigh` et `max` nécessitent `THINKING=on` ; la phrase sur `MAX_TOKENS` parle du plus grand des deux plafonds de mémoire, comme la vérification ; le tableau du README reprend les valeurs proposées de `.env.exemple` pour `MAX_TOKENS` (6000) et `API_TIMEOUT` (90).
+- **Documentation des réglages alignée.** `.env.exemple` et le README décrivent maintenant exactement ce que fait le bot pour `THINKING`, `EFFORT` et `MAX_TOKENS`, avec les mêmes valeurs proposées.
 
-- **« Modifier » ne signale plus de faux conflit.** Quand l'écriture sur le disque prenait plus de 3 secondes, Discord considérait l'envoi comme échoué alors que le texte était enregistré : la fenêtre restait ouverte, et un second clic répondait que le fichier avait changé entre-temps. Le bot répond maintenant tout de suite à Discord, avant d'enregistrer, et un même texte envoyé deux fois est accepté.
+- **« Modifier » ne signale plus de faux conflit.** Quand l'enregistrement était lent, la fenêtre de `/memoire` restait ouverte alors que le texte était sauvé, et un second clic disait à tort que le fichier avait changé entre-temps. La fenêtre se ferme maintenant dès l'envoi.
 
-- **Une réponse trop lente n'est plus relancée trois fois.** Quand Claude dépassait `API_TIMEOUT`, la requête était recommencée jusqu'à 3 fois, recherches web comprises (et refacturées) : un membre pouvait attendre 4 minutes avant « Je mets trop de temps à répondre ». `API_TIMEOUT` borne maintenant l'attente totale ; une erreur passagère (API surchargée) est toujours réessayée dans cette limite. Le bot prévient au démarrage si `API_TIMEOUT` est trop court pour `MAX_TOKENS` (environ 80 tokens par seconde), et 40 secondes de plus avec `WEB_SEARCH=on`.
+- **Une réponse trop lente n'est plus relancée trois fois.** Un membre pouvait attendre 4 minutes, recherches web refacturées à chaque essai, avant « Je mets trop de temps à répondre ». `API_TIMEOUT` borne maintenant l'attente totale, et le bot prévient au démarrage s'il est trop court pour `MAX_TOKENS`.
 
-- **`MAX_TOKENS` vérifié en tenant compte de la réflexion.** Avec `MEMORY=on`, la réécriture d'un fichier de mémoire plein doit tenir dans `MAX_TOKENS` après la réflexion. La marge prévue était de 2000 tokens quels que soient `THINKING` et `EFFORT` : avec `EFFORT=high`, une note pouvait être perdue sans avertissement. La marge dépend maintenant de l'effort (2000 tokens pour low et medium, 4000 pour high ou par défaut, 8000 pour xhigh et max ; aucune sans réflexion). Sous le strict minimum, le bot refuse de démarrer avec un message clair. Sous la valeur conseillée, il le signale aussi dans le message « En ligne », pas seulement dans le journal. `.env.exemple` passe à `MAX_TOKENS=6000` et `API_TIMEOUT=90`.
+- **`MAX_TOKENS` vérifié en tenant compte de la réflexion.** Avec `MEMORY=on` et un effort élevé, une note de mémoire pouvait être perdue sans avertissement, faute de place. Le bot refuse maintenant de démarrer sous le minimum et prévient dans le message « En ligne » sous la valeur conseillée ; `.env.exemple` propose `MAX_TOKENS=6000` et `API_TIMEOUT=90`.
 
-- **Une personnalité illisible ne rend plus Rika muette.** Un fichier de personnalité qui n'est pas en UTF-8 (enregistré en ANSI avec le Bloc-notes, par exemple), illisible, ou un `PERSONALITY_FILE` qui désigne un dossier (ConfigMap montée comme dossier sur OpenShift) faisait échouer chaque message sans réponse. Rika garde maintenant la dernière personnalité valide, ou celle par défaut au démarrage, et le journal indique une seule fois le problème et comment le corriger. Le fichier est relu dès qu'il est modifié.
+- **Une personnalité illisible ne rend plus Rika muette.** Un fichier de personnalité illisible (pas en UTF-8, ou un dossier au lieu d'un fichier) faisait échouer chaque message. Rika garde maintenant la dernière personnalité valide, et le journal explique comment corriger le fichier.
 
-- **`CONTEXT_MESSAGE_LIMIT` plafonné à 100.** Aucune limite n'empêchait d'y mettre 2000 : chaque mention demandait alors une vingtaine d'appels à Discord et envoyait environ 100 000 tokens à Claude (plusieurs dizaines de centimes par mention, ou un refus « prompt is too long »). Au-delà de 100, le bot refuse de démarrer avec un message « Erreur de configuration » clair.
+- **`CONTEXT_MESSAGE_LIMIT` plafonné à 100.** Une valeur comme 2000 pouvait coûter plusieurs dizaines de centimes par mention. Au-delà de 100, le bot refuse maintenant de démarrer, avec un message clair.
 
-- **Les autres réglages ont aussi un plafond.** Une valeur trop grande n'était découverte qu'au premier message, avec un « Je suis mal configuré » sans explication (`MAX_TOKENS=200000`, `PDF_MAX_PAGES=300` alors que l'API refuse les PDF de plus de 100 pages), ou passait sans erreur mais coûtait cher (`WEB_MAX_USES=50`) ou saturait Discord (`PRESENCE_SPEED=100000`). Le bot refuse maintenant de démarrer avec un message « Erreur de configuration » clair au-delà de 64000 pour `MAX_TOKENS`, 10 pour `WEB_MAX_USES`, 20 pour `MEMORY_MAX_OPERATIONS`, 100 pour `PDF_MAX_PAGES` et 100 pour `PRESENCE_SPEED`. Les bornes sont indiquées dans `.env.exemple`.
+- **Les autres réglages ont aussi un plafond.** Une valeur trop grande (`MAX_TOKENS`, `PDF_MAX_PAGES`, `WEB_MAX_USES`…) ne se voyait qu'au premier message, ou coûtait cher sans prévenir. Le bot refuse maintenant de démarrer au-delà du plafond, indiqué dans `.env.exemple`.
 
-- **`PRESENCE_WEIGHTS` mieux vérifié.** Une virgule finale ou doublée ne donne plus « Statut inconnu dans PRESENCE_WEIGHTS : '' » : l'élément vide est ignoré. Un statut écrit deux fois n'est plus accepté en silence (la dernière valeur gagnait) : le bot refuse de démarrer. Enfin, si `jeu` est le seul statut possible sans `STEAM_API_KEY`, le bot ne reste plus « en ligne » sans activité ni avertissement : il refuse de démarrer avec un message « Erreur de configuration » clair.
+- **`PRESENCE_WEIGHTS` mieux vérifié.** Une virgule en trop est ignorée. Un statut écrit deux fois, ou `jeu` comme seul statut possible sans `STEAM_API_KEY`, arrête maintenant le bot avec un message clair.
 
-- **Un dossier absent est signalé au démarrage.** Si le dossier de `LOG_FILE`, de `HISTORY_FILE` ou de `MEMORY_DIR` n'existe pas (volume Docker mal monté, faute de frappe) ou n'est pas accessible en écriture, le bot refuse de démarrer avec un message « Erreur de configuration » clair, au lieu d'une trace Python (`LOG_FILE`) ou de tourner sans jamais rien sauvegarder (`HISTORY_FILE`). L'historique est aussi enregistré comme les autres fichiers : envoyé jusqu'au disque avant de remplacer l'ancien, pour ne pas finir vide après une coupure de courant.
+- **Un dossier absent est signalé au démarrage.** Si le dossier de `LOG_FILE`, `HISTORY_FILE` ou `MEMORY_DIR` n'existe pas ou n'est pas accessible en écriture (volume Docker mal monté, faute de frappe), le bot refuse de démarrer au lieu de tourner sans rien sauvegarder. L'historique résiste aussi mieux à une coupure de courant.
 
-- **Un `CHANNEL_ID` faux arrête le bot.** Si le salon était introuvable (ID du serveur ou d'un autre salon collé par erreur), le bot restait connecté sans répondre nulle part : sur OpenShift, le pod paraissait « Running » alors que Rika était muette. Un ID de catégorie ou de forum faisait planter le message de démarrage, et une permission manquante n'était pas signalée. Le bot vérifie maintenant au démarrage que `CHANNEL_ID` désigne un salon textuel où il peut voir, écrire et lire l'historique, et sinon s'arrête avec un message « Erreur de configuration » qui dit quoi corriger. Si un serveur est seulement indisponible chez Discord (panne), il patiente et s'annonce dès son retour.
+- **Un `CHANNEL_ID` faux arrête le bot.** Avec un mauvais salon ou une permission manquante, le bot restait connecté sans répondre nulle part. Il vérifie maintenant le salon au démarrage et s'arrête en disant quoi corriger ; si Discord est seulement en panne, il patiente.
 
-- **Une clé Anthropic ou un modèle faux arrête le bot.** Une `ANTHROPIC_API_KEY` révoquée ou mal recopiée, ou un `CLAUDE_MODEL` inexistant, ne se voyait qu'au premier message : le bot s'annonçait « En ligne », puis répondait « Je suis mal configuré » à chaque message. Il vérifie maintenant la clé et le modèle au démarrage, sans consommer de tokens, et sinon s'arrête avec un message « Erreur de configuration » qui dit quoi corriger. Si l'API est seulement injoignable, il démarre quand même et le signale dans le journal. Un crédit épuisé ne peut pas être détecté gratuitement : il ne se voit toujours qu'au premier message.
+- **Une clé Anthropic ou un modèle faux arrête le bot.** Une `ANTHROPIC_API_KEY` ou un `CLAUDE_MODEL` invalide ne se voyait qu'au premier message, avec « Je suis mal configuré ». Le bot les vérifie maintenant au démarrage ; seul un crédit épuisé ne se voit toujours qu'au premier message.
 
 ---