صفحهٔ اصلی گشت‌و‌گذار راهنما
ورود
penta
/
chatbot-maisonnette
mirrorاز https://github.com/Penta/chatbot-maisonnette
1
0
انشعاب 0
پرونده‌ها مشکلات 0 ویکی
درخت: daf2668c28
شاخه‌ها تگ‌ها
chatbot-maisonn...
/
CHANGELOG.md

CHANGELOG.md 35 KB
تاريخچه خام

Changelog — Chatbot Discord

Les versions les plus récentes sont en haut. Chaque entrée commence par un résumé en gras, suivi du détail.

Versions : 5.11 · 5.10 · 5.9 · 5.8 · 5.7 · 5.6 · 5.5 · 5.4.0 · 5.3.0 · 5.2.0 · 5.1.0 · 5.0.0

Version 5.11

En bref : la mémoire des membres devient un choix de chacun (/memoire), elle est beaucoup mieux protégée contre les abus, et elle respecte davantage la vie privée.

Changements

  • La mémoire des membres s'active soi-même. Elle est désactivée par défaut, et chaque membre qui le souhaite l'active avec /memoire, après avoir lu ce qu'elle retient et qui peut voir sa fiche. Le message de bienvenue, envoyé en message privé au premier message de chacun, disparaît. Rien n'est noté sur un membre qui ne l'a pas activée, même quand les autres parlent de lui.

Au premier démarrage, la mémoire reste activée pour les membres qui avaient déjà une fiche et ne l'avaient pas désactivée ; elle est désactivée pour les autres.

Corrections — ce que Rika retient

  • Une info sur un membre ne va que dans sa fiche. En désactivant la mémoire, un membre efface aussi les lignes du fichier général qui le citent.

  • Une fiche effacée reste effacée. Une fiche effacée par « Désactiver la mémoire » ne peut plus être recréée par une note en cours ni par une fenêtre /memoire restée ouverte.

  • Ce qu'on retire de sa fiche n'y revient plus. Avant, Rika le retrouvait dans la conversation et le notait de nouveau au message suivant. Désormais, une fiche ou le fichier général modifié (ou effacé) avec /memoire est montré à Rika avec la date de la modification : elle ne note plus ce qui a été dit avant et n'y figure pas. Ce qu'on lui redit ensuite se note normalement. Même chose après « Désactiver la mémoire », si le membre la réactive. Les dates sont gardées dans memories/modifications.json.

  • Les surnoms sont mieux reconnus. La ligne « Surnoms : … » est trouvée même si elle n'est pas la première de la fiche (ajoutée à la fin, ou fiche modifiée à la main), avec ou sans puce ; plusieurs lignes « Surnoms » sont regroupées. Avant, elles étaient ignorées sans rien dire. « Surnom : … » au singulier et « Surnoms : … » en gras sont aussi reconnus.

  • Chemins plus souples. L'outil accepte memories/membres/… (sans « / » au début), comme /memories/membres/….

  • MAX_TOKENS passe à 4000 par défaut (1500 avant), assez pour que Rika réécrive le fichier général quand il est plein. Avant, la réécriture était coupée et la note perdue, à chaque nouvel essai. Le bot prévient au démarrage si MAX_TOKENS est trop petit pour MEMORY_SERVER_LIMIT, et le log signale un appel d'outil coupé.

Corrections — vie privée

  • Les données personnelles sont protégées. Rika ne note plus les confidences ni ses jugements sur quelqu'un. Une information sensible (santé, sexualité, religion, opinions, origine, adresse, argent) ne se note que si le membre la donne lui-même, et elle ne l'évoque ensuite qu'avec lui. Elle se sert de ce qu'elle sait dans la conversation, mais ne récite plus la fiche d'un membre à quelqu'un d'autre. Les fiches déjà écrites ne sont pas modifiées.

  • Les membres savent qui peut lire leur fiche. Ils sont prévenus que les administrateurs du serveur peuvent la voir et la corriger (avant d'activer la mémoire, et sous leur fiche dans /memoire). Chaque ouverture de la fiche d'un autre membre avec /memoire est notée dans le log, sans son contenu.

  • Les sources nommées sont annoncées. Avant d'activer la mémoire, chacun est prévenu que les sources sont notées avec leur nom (« d'après Toto ») et visibles par la personne concernée : ce qu'on raconte sur un autre membre peut lui être montré dans sa fiche.

  • Pas de fiche écrite sans accord. Un administrateur ne peut plus écrire la fiche d'un membre qui n'a pas activé la mémoire (« Modifier » grisé, avec une explication) ; il peut toujours l'effacer.

Corrections — sécurité

  • Le bot ne sert plus que son propre serveur (celui de CHANNEL_ID). Invité sur un autre serveur, il ignore les messages et refuse les commandes : un administrateur de ce serveur pouvait lire et réécrire la mémoire du vrai serveur avec /memoire et /memoire-serveur, et les réponses étaient payées par le propriétaire du bot. Les messages privés sont aussi ignorés. Le log signale au démarrage les autres serveurs où se trouve le bot, et le README explique comment décocher Public Bot et User Install dans le portail Discord.

  • Plus d'usurpation par le pseudo. Rika voit chaque auteur avec son nom d'utilisateur Discord, unique (« Johnounet (johnk) »), quand il diffère de son pseudo, y compris pour l'auteur d'un message cité. Deux membres qui portent le même pseudo ne se confondent plus, et personne ne peut faire noter une info dans la fiche d'un autre en prenant son pseudo. Les fiches jointes indiquent celles des auteurs du message, et une fiche ne peut plus imiter l'en-tête d'une autre. Les messages déjà enregistrés gardent l'ancien format.

  • On ne peut plus prendre le nom d'un autre comme surnom. Un surnom qui reprend le nom Discord d'un autre membre (pseudo, nom d'utilisateur ou ancien pseudo) est ignoré dans la liste des membres : Rika ne note plus dans sa fiche ce qu'on raconte sur l'autre.

  • Les notes restent des notes. Le fichier général et la liste des membres sont présentés à Rika comme des notes, pas des consignes, et une note ne peut plus sortir de ce cadre, même avec une balise non fermée ou des chevrons pleine largeur. Rika ne note plus de règle qui s'appliquerait à tout le monde (façon d'écrire, sujet à éviter), même présentée comme votée ou venant d'un administrateur ; une préférence personnelle (« veut qu'on l'appelle Majesté ») se note toujours dans la fiche. Au plus 5 surnoms de 32 caractères par membre. Le texte écrit dans le fichier général apparaît dans le log, pour que l'administrateur puisse vérifier.

  • Un membre ne peut plus vider le fichier général en désactivant sa mémoire. Seuls ses noms Discord servent à retrouver les lignes qui le citent, plus les surnoms de sa fiche, qu'il écrit lui-même. Si plus de 3 lignes le citent (pseudo qui est un mot courant, comme « Soleil »), aucune n'est retirée et le log demande à l'administrateur de vérifier avec /memoire-serveur.

Corrections — /memoire et les commandes

  • /memoire ne promet plus d'effacer plus qu'il ne le fait. Le bouton « Tout effacer » d'une fiche devient « Effacer la fiche », et la confirmation précise que ce qui a été dit récemment reste dans la conversation. « Désactiver la mémoire » ne dit plus que « plus rien ne sera retenu », et remplace maintenant le nom du membre par « un membre » là où il est cité comme source dans les fiches des autres (« d'après Bob », « selon Bob »).

  • « Modifier » n'écrase plus les changements récents. La fenêtre n'enregistre plus rien si le fichier a changé depuis son ouverture (note de Rika, désactivation d'un membre qui retire des lignes du fichier général). Avant, elle réécrivait le fichier tel qu'il était à l'ouverture : la note était perdue, ou la ligne retirée revenait. Quand un texte n'est pas enregistré (fichier changé, trop long…), il est renvoyé en fichier joint pour ne pas être perdu.

  • « Modifier » respecte la limite du fichier général : 5000 caractères (MEMORY_SERVER_LIMIT). Sa deuxième zone de texte laissait en écrire 8000, refusés ensuite à l'enregistrement.

  • Un fichier trop long s'ouvre de nouveau. Un fichier plus long que sa limite (MEMORY_*_LIMIT baissée, fichier modifié sur le disque) s'ouvre en entier dans « Modifier », avec la limite rappelée pour le raccourcir. Avant, la fenêtre ne s'ouvrait pas (« Échec de l'interaction »). Au-delà de 20 000 caractères, trop pour une fenêtre Discord, son contenu est envoyé en fichier joint.

  • Des erreurs compréhensibles. Une erreur dans une commande ou un bouton affiche « Une erreur est survenue » au lieu du seul « Échec de l'interaction » de Discord. Les boutons de /memoire se grisent au bout de 10 minutes, avec un message qui invite à relancer la commande, au lieu de rester affichés sans répondre. La fenêtre « Modifier » peut être validée pendant une heure, au lieu de 10 minutes.

  • La fiche d'un membre parti reste accessible avec /memoire membre: (par son identifiant). Avant, la commande échouait, et lui-même ne pouvait plus la lancer : sa fiche restait pour toujours. Un administrateur peut aussi désactiver sa mémoire à sa place, ce qui efface tout comme s'il l'avait fait.

Corrections — fiabilité et performances

  • La mémoire coûte moins cher sur un grand serveur. Le prompt ne liste plus que les membres qui ont une fiche, au lieu de tous ceux que le bot a vus ou qu'on a mentionnés. Au plus 5 fiches sont jointes à un message (les auteurs d'abord, puis l'auteur du message cité, puis les membres mentionnés) ; les autres sont seulement nommées, et Rika peut les lire si besoin.

  • Le bot ne relit plus toutes les fiches à chaque message. Elles sont lues une fois au démarrage, puis suivies à chaque note. Avec 500 membres, chaque message bloquait le bot près d'une seconde (mesuré sous Windows). Une fiche modifiée directement sur le disque n'est prise en compte dans la liste qu'au redémarrage.

  • Une fiche illisible ne bloque plus le bot. Une fiche ou un fichier général illisible (enregistré à la main dans un autre encodage, problème de droits) est signalé une fois dans le log, affiché avec « � » à la place des caractères invalides, et n'est plus modifié tant qu'il n'est pas corrigé. Une fiche enregistrée avec BOM (Bloc-notes) garde sa ligne « Surnoms ».

  • Un registre abîmé coupe la mémoire au lieu de la réinitialiser. Si memories/registre.json est abîmé ou mal modifié à la main, la mémoire des membres est coupée jusqu'à sa réparation, au lieu de repartir d'un registre vide qui réactivait la mémoire de ceux qui l'avaient désactivée. Le fichier n'est plus mis de côté ni réécrit ; le log et /memoire signalent la panne. Un registre corrigé à la main et enregistré avec BOM (Bloc-notes) reste lisible.

  • Un registre impossible à enregistrer est signalé. Si le registre ne peut pas être enregistré (disque plein, droits), « Désactiver la mémoire » et « Réactiver la mémoire » le disent, au lieu d'annoncer un réglage qui serait perdu au redémarrage du bot. Le réglage s'applique quand même, et la prochaine sauvegarde réussie du registre l'enregistre.

Corrections — démarrage et réponses

  • Un modèle inconnu est signalé dès le démarrage (CLAUDE_MODEL mal écrit, par exemple), et plus seulement au premier message. Les messages d'erreur citent CLAUDE_MODEL (et non MODEL, une variable qui n'existe pas).

  • TIMEZONE mal formée (« Europe/Paris/ », « ../Paris ») ou trop longue : message d'erreur clair au démarrage, au lieu d'une trace Python.

  • Plus de « […] » envoyé seul. Une réponse coupée avant son premier mot n'envoie plus « […] » seul sur Discord (ni dans l'historique), mais un message d'explication.

Divers

  • Secrets masqués. Le token Discord et les clés Anthropic et Steam n'apparaissent plus quand la configuration est affichée (précaution : aucun log ne l'affiche aujourd'hui).

  • Premiers tests automatisés (mémoire des membres) : lancer python -m unittest à la racine du projet.

  • Écritures plus sûres. Les fiches et le registre des membres sont envoyés jusqu'au disque avant d'être remplacés : une coupure de courant ne laisse plus de fichier vide. Une écriture ratée ne laisse plus de fichier .tmp derrière elle.

Version 5.10

En bref : Rika se souvient des membres et du serveur d'une conversation à l'autre.

Nouveautés

  • Mémoire des membres (MEMORY=on). Rika tient une fiche sur chaque membre et un fichier général du serveur (blagues récurrentes, événements, habitudes). Elle décide seule de ce qui mérite d'être retenu, quelle que soit la personne qui le lui apprend, et note la source quand l'info vient d'un autre membre (« d'après Toto »). Elle écrit en style télégraphique, une ligne par fait, sans doublon, et met à jour une ligne plutôt que d'en ajouter une. Elle ne signale pas ce qu'elle note : on le découvre plus tard, quand elle s'en souvient.

  • Ce que Rika voit. Le bot joint lui-même à chaque message les fiches des membres concernés (auteurs, membres mentionnés, auteur du message cité), sans appel supplémentaire. Son prompt contient aussi le fichier général et la liste des membres, avec tous leurs noms (pseudo, nom d'utilisateur, surnoms notés en tête de fiche, anciens pseudos) et le chemin de leur fiche : elle peut ainsi noter une info sur quelqu'un cité par son seul nom ou surnom, et lire sa fiche si besoin. Les fiches jointes ne sont pas enregistrées dans l'historique, et le cache s'arrête juste avant elles : l'historique reste relu en cache.

  • Comment elle écrit. Avec un outil « memoire » exécuté par le bot (lire, ajouter, remplacer, réécrire), limité à ces seuls fichiers. Une fiche fait au plus 3000 caractères (MEMORY_MEMBER_LIMIT) et le fichier général 5000 (MEMORY_SERVER_LIMIT) : une note de trop est refusée, et Rika réécrit alors le fichier en plus court, en fusionnant et en retirant le moins important. Au plus 5 lectures ou écritures par réponse (MEMORY_MAX_OPERATIONS). Outil maison plutôt que celui d'Anthropic, qui lui ferait relire tout le dossier avant chaque réponse, soit un appel de plus à chaque message.

  • /memoire. Chaque membre voit sa fiche, visible par lui seul, et peut la modifier dans une fenêtre déjà remplie, tout effacer ou désactiver la mémoire (avec confirmation : sa fiche est effacée, plus rien n'est retenu sur lui ni joint à ses messages). Il peut la réactiver au même endroit. Les administrateurs (permission Administrateur) voient, modifient et effacent la fiche de n'importe qui avec /memoire membre:@… ; seul le membre lui-même peut désactiver sa mémoire. /memoire-serveur, réservé aux administrateurs, fait de même pour le fichier général.

  • Présentation. Au premier message d'un membre, le bot lui envoie une seule fois un message privé qui explique ce qu'il peut retenir et comment le voir, le modifier ou le désactiver avec /memoire. Si ses messages privés sont fermés, le message est posté dans le salon, avec son nom en mention mais sans notification, et s'efface au bout d'une minute. Les membres déjà actifs sont prévenus à leur premier message après le passage à la 5.10 ; un membre qui a déjà utilisé /memoire ne l'est pas.

  • Registre des membres. Le bot garde, pour chaque membre vu, son nom d'utilisateur, son nom d'affichage, son pseudo sur le serveur et ses 5 derniers anciens pseudos, mis à jour à chaque message, ainsi que ses réglages de la mémoire. Tout est dans le dossier memories/, à côté de l'historique (MEMORY_DIR pour un autre dossier) : registre.json, serveur.md et membres/<id>.md. Avec Docker, il est donc sur le même volume que l'historique.

  • Mise en service. MEMORY=on dans le .env (ou la ConfigMap), sans nouvelle permission Discord. Avec MEMORY=off (par défaut), rien ne change, et /memoire et /memoire-serveur indiquent que la mémoire est coupée. MEMORY_MEMBER_LIMIT et MEMORY_SERVER_LIMIT ne peuvent pas dépasser 20 000 (taille maximale de la fenêtre de modification).

Divers

  • /reset et /skip réservés aux administrateurs (permission Administrateur). Avant, les modérateurs avec « Gérer les messages » y avaient aussi accès. Les commandes sont renvoyées à Discord au premier démarrage de la 5.10.

Version 5.9

En bref : tous les emojis du serveur, un statut Discord qui survit aux redémarrages, et la commande /skip.

Nouveautés

  • Emojis du serveur. Rika reçoit automatiquement la liste des emojis du serveur et peut tous les utiliser, sans qu'il faille les recopier dans la personnalité ; un emoji ajouté ou retiré est pris en compte tout de suite. Elle les écrit par leur nom (:hap:), et le bot les remplace par l'emoji avant l'envoi : plus d'identifiant inventé, et environ 3 fois moins de tokens par emoji. Les emojis animés sont compris (un bot n'a pas besoin de Nitro) ; seuls ceux réservés à des rôles qu'elle n'a pas sont exclus, y compris quand elle répond à un emoji seul. Dans sa mémoire et dans les messages qu'elle lit, les emojis apparaissent aussi par leur nom.

La personnalité dit seulement quand en mettre, par exemple : « Tu termines chaque message par un seul emoji du serveur, directement après le dernier mot. » Une ancienne liste de codes (<:hap:123…>) fonctionne encore, mais n'est plus utile.

  • Statut Discord gardé entre deux redémarrages. Rika reprend son statut là où elle en serait si elle ne s'était pas arrêtée, comme s'il avait continué pendant l'arrêt. Après un redémarrage rapide, elle regarde toujours le même épisode ou joue au même jeu ; après un arrêt plus long, l'anime a avancé d'autant d'épisodes et la playlist d'autant de morceaux. Absente ou en « Ne pas déranger », elle le reste : les messages en attente gardent leur réponse différée. Un statut terminé pendant l'arrêt, coupé par la nuit ou désactivé depuis dans PRESENCE_WEIGHTS laisse place à un nouveau, et ses derniers statuts personnalisés ne sont pas répétés. Le statut est gardé dans presence_state.json, à côté de l'historique.

  • /skip abandonne le statut Discord en cours (l'anime ou la playlist entière) et en tire un nouveau tout de suite, selon les mêmes règles. Réservé aux modérateurs et administrateurs, comme /reset ; seul celui qui lance la commande voit le nouveau statut et sa durée. Si Rika était absente et passe en ligne, elle répond aussitôt aux messages en attente ; si elle s'éloigne en pleine conversation, elle prévient son salon. Sans effet la nuit, et absente avec PRESENCE=off. La commande est envoyée à Discord au premier démarrage de la 5.9.

  • Statuts plus variés. Un nouveau statut ne peut plus être du même type que les deux derniers (avant, seul le dernier était exclu), et le type d'avant revient deux fois moins souvent. Les suites comme anime / musique / anime deviennent impossibles : un type vu dans les 3 derniers statuts revient dans 15 % des tirages au lieu de 37 %, et les chances de PRESENCE_WEIGHTS restent presque respectées. Si trop de statuts sont désactivés pour respecter la règle, elle s'assouplit. Les derniers types tirés sont gardés dans presence_state.json.

Divers

  • Image Docker : Python 3.15 au lieu de 3.13. Toutes les dépendances ont leurs paquets précompilés pour cette version.

Version 5.8

En bref : Rika tient compte des messages modifiés ou supprimés.

Nouveautés

  • Messages modifiés ou supprimés. Dans son salon, Rika oublie le contenu d'un message supprimé (texte, pièces jointes) et sa citation dans les réponses qui le citaient. Elle se souvient seulement que quelqu'un a écrit un message à ce moment-là, supprimé depuis, et garde sa propre réponse : la conversation ne perd pas son fil. Un message modifié prend son nouveau texte, avec une mention indiquant qu'il a été modifié après sa réponse.

Un message supprimé avant qu'elle y réponde (pendant une absence par exemple) ne reçoit plus de réponse, y compris une mention hors de son salon ; modifié, elle répond au nouveau texte.

  • Nouveau format de l'historique (version 3), plus lisible : chaque message Discord y garde son identifiant, et la date, l'auteur, la citation, le texte et les pièces jointes sont séparés. L'ancien fichier est converti automatiquement au premier lancement, sans réécrire le cache de prompt, et une copie en est gardée à côté (conversation_history.json.v2-<date>).

⚠️ Revenir à la 5.7 demande de remettre cette copie à la place du fichier : la 5.7 ne sait pas lire le nouveau format et repartirait d'une mémoire vide.

Corrections

  • Réflexion affichée. Quand le modèle commence sa réponse par sa réflexion (<think>…</think>, <reasoning>…, faux appel d'outil), elle est retirée avant l'envoi, et le log le signale. Seul un bloc complet tout au début est retiré : une balise plus loin dans le texte ou dans du code reste affichée. Celle déjà présente dans la mémoire est nettoyée au démarrage : en la relisant, le modèle l'imitait, et une fuite en entraînait d'autres.

Version 5.7

En bref : lecture des PDF, historique 2 à 3 fois moins cher, et de nombreuses corrections.

Nouveautés

  • Rika prévient quand elle s'en va. Quand elle passe absente ou en « Ne pas déranger » (ou part dormir) en pleine conversation, elle prévient son salon dans un court message, en accord avec son statut. Elle ne le fait que si quelqu'un y a écrit dans les 3 dernières minutes, et après avoir fini sa réponse en cours ; elle s'en souvient ensuite.

  • PDF. Rika lit un PDF joint au message (texte, tableaux, schémas, pages scannées), dans son salon et quand on la mentionne. Un PDF par message, sans image ; 20 pages au plus (PDF_MAX_PAGES dans le .env, 0 pour refuser les PDF) et 20 Mo. Les PDF protégés par un mot de passe sont refusés. Comme pour les images, seul le nom du fichier reste en mémoire. Nouvelle dépendance : pypdf (pip install -r requirements.txt).

  • Mémoire moins chère. Quand elle est pleine, elle n'oublie plus un échange à chaque message, mais plusieurs d'un coup. Elle grandit jusqu'à MAX_HISTORY_LENGTH + la moitié (20 → 30 messages), puis revient à MAX_HISTORY_LENGTH. Entre deux coupes, le début de la conversation reste dans le cache de prompt au lieu d'être réécrit à chaque message : dans une conversation animée, l'historique coûte environ 2 à 3 fois moins cher.

  • Plus de fichiers texte. En plus des .txt, Rika lit les .md, .csv, .json, .log, sous-titres (.srt, .vtt), fichiers de configuration, pages HTML et le code (.py, .js, .java, .cpp, .cs…).

Corrections

  • Captures d'écran nettes. Les captures trop grandes restent en PNG au lieu d'être converties en JPEG, qui brouillait le texte (le JPEG ne sert plus que si le PNG dépasse la limite de l'API). Les images en palette (PNG optimisés, GIF) sont réduites proprement, et non plus au plus proche voisin.

  • Erreurs de l'API mieux expliquées. Une requête refusée n'est plus toujours présentée comme un problème de formulation (ou d'image dès qu'une image est jointe). Rika parle de l'image seulement si c'est elle qui pose problème, propose /reset si la conversation est trop longue, et demande de prévenir l'administrateur pour un réglage du .env refusé, un crédit épuisé, un modèle introuvable ou un accès refusé ; les logs en donnent la cause.

  • Fichiers « Unicode » du Bloc-notes. Les .txt enregistrés en UTF-16 sont lus, au lieu d'être refusés comme « pas du texte lisible ».

  • Stickers. Un sticker accompagné de texte ou d'une pièce jointe n'efface plus le message (même pendant une absence) : Claude reçoit le texte et le nom du sticker. « Aucun sticker utilisable » et « Aucun emoji personnalisé » ne sont plus envoyés à chaque fois : si le serveur n'a rien d'utilisable, Rika répond avec des mots.

  • Indicateur « en train d'écrire ». Si Discord le refuse (permission manquante, panne passagère), la réponse est quand même envoyée, au lieu d'être perdue.

  • Commandes slash. Elles ne sont plus renvoyées à Discord à chaque démarrage (Discord limite ces envois), seulement quand elles ont changé. Leur empreinte est gardée dans slash_commands.sha256, à côté de l'historique (le supprimer force un nouvel envoi). Un échec de l'envoi n'empêche plus le bot de démarrer : il réessaie au démarrage suivant.

  • Historique abîmé. Un fichier conversation_history.json d'une forme inattendue (liste, « channels » qui n'est pas un dictionnaire, mauvais encodage) n'empêche plus le bot de démarrer : il est mis de côté et Rika repart d'une mémoire vide. Les copies de secours sont datées (.corrompu-AAAA-MM-JJ_HH-MM-SS) et ne s'écrasent plus entre elles.

  • Réglages du .env vérifiés. API_TIMEOUT doit valoir au moins 1 seconde, et les prix (PRICE_*) ne peuvent plus être négatifs. « nan » et « inf » sont refusés pour tous les réglages décimaux, PRESENCE_SPEED compris. Une valeur invalide arrête le bot au démarrage avec un message clair.

Version 5.6

En bref : Rika a une vie sous son pseudo Discord — elle regarde des animes, écoute de la musique, joue, et n'est pas toujours disponible.

Nouveautés

  • Statut Discord. Sous son pseudo, Rika regarde un anime, écoute de la musique, joue à un jeu, affiche une pensée du moment, ou passe en « Ne pas déranger » ou absente.

    • Chances de chaque statut : anime 20 %, musique 20 %, pensée 10 %, jeu 20 %, en ligne sans activité 20 %, Ne pas déranger 5 %, absente 5 % (PRESENCE_WEIGHTS dans le .env). Chaque statut a sa propre durée, tirée au sort ; à la fin, un nouveau statut est tiré, jamais le même que le précédent.
    • Animes : un titre (romaji) au hasard dans le top 500 d'AniList. Rika regarde 1 à 5 épisodes à la suite, à partir d'un épisode précis, à la durée réelle d'un épisode (un film compte pour un épisode).
    • Musiques : 6 à 20 titres au hasard dans le Top Worldwide, le Top France et le Top Japan de Deezer, chacun à sa durée réelle.
    • Jeux : un jeu au hasard dans toute la boutique Steam (clé STEAM_API_KEY ; sans elle, pas de statut « joue à »), pendant 45 min à 2 h. Les jeux pour adultes sont écartés, et Rika connaît la présentation du jeu sur la boutique.
    • En ligne sans activité : 15 à 45 min.
    • Pensée du moment (30 à 90 min), raison d'une absence (10 à 60 min) ou d'un Ne pas déranger (30 à 90 min) : écrites par Claude avec la personnalité du bot, selon l'heure et la durée, sans reprendre les dernières.
    • La nuit, de 2 h à 6 h, Rika est automatiquement absente (PRESENCE_NIGHT), quoi qu'elle soit en train de faire.
    • Quand on lui parle, Rika sait ce qu'elle est en train de faire, et pour combien de temps encore.
    • PRESENCE_SPEED=10 rend tous les statuts 10 fois plus courts, pour tester.
    • Les listes sont téléchargées au démarrage puis une fois par jour, et gardées dans presence_sources.json (à côté de l'historique) au cas où un site ne répondrait plus.

  • Réponses différées. Absente (et la nuit), Rika ne répond plus avant son retour ; en « Ne pas déranger », elle répond au bout de 5 à 15 minutes, ou dès qu'elle change de statut.

    • Dans son salon, tous les messages arrivés entre-temps reçoivent une seule réponse groupée. Ailleurs, elle répond à chaque mention avec « Répondre », pour qu'on sache à quel message elle répond.
    • Elle sait qu'elle répond en retard, et pourquoi (absente, Ne pas déranger, la nuit, avec la raison affichée).
    • Elle ne réagit pas aux stickers ni aux emojis seuls pendant ce temps.
    • Les messages en attente sont gardés dans waiting_messages.json (à côté de l'historique) : après un redémarrage, Rika y répond quand même.

Version 5.5

En bref : moins de réflexion qui fuit dans les réponses, et des logs plus propres.

Corrections

  • Avertissements vocaux masqués. Les avertissements de discord.py sur le vocal (PyNaCl et davey non installés) n'apparaissent plus à chaque démarrage : le bot n'utilise pas le vocal.

  • Réflexion affichée. Avec Sonnet 5.5 et EFFORT=high, le modèle écrivait parfois sa réflexion dans sa réponse (faux appel d'outil <invoke name="think">…, raisonnement entre balises <reasoning>…), quand il choisissait de ne pas réfléchir. Ça n'arrive plus avec EFFORT=medium : c'est le réglage conseillé.

    • Les consignes ajoutées automatiquement à la personnalité suivent les recommandations d'Anthropic contre ces fuites : plus d'interdiction de commenter les recherches web (ce commentaire n'est de toute façon jamais affiché), et une consigne générale contre les balises internes.
    • Au démarrage, le log indique le modèle, la réflexion, l'effort et la recherche web réellement utilisés.

  • Logs moins bavards. Chaque requête HTTP vers l'API d'Anthropic n'est plus journalisée (le SDK 2.x passe par httpx2, qui n'était pas rendu silencieux).

Version 5.4.0

En bref : choix du modèle Claude, lecture des messages transférés, et réponses groupées.

Nouveautés

  • Changement de modèle facile. Il suffit de modifier CLAUDE_MODEL dans le .env (claude-sonnet-5-5, claude-haiku-5-5 ou claude-opus-5-5) et de redémarrer le bot.

    • THINKING=off coupe la réflexion de la façon propre à chaque modèle (auparavant, tout autre modèle que Sonnet 5.5 était refusé par l'API).
    • Sur Opus 5.5, la réflexion ne peut pas être coupée : régler EFFORT=low.
    • Les tarifs utilisés pour le coût estimé dans les logs suivent le modèle choisi ; PRICE_INPUT_PER_MTOK et PRICE_OUTPUT_PER_MTOK ne sont plus à renseigner que pour un autre modèle (à vider dans le .env existant).

  • Messages transférés. Dans le salon dédié, le bot lit le message transféré (son texte et son image).

  • Discussion entre bots. Le bot répond aux autres bots quand ils le mentionnent ou répondent à l'un de ses messages ; le reste de ce qu'ils postent est toujours ignoré.

  • Messages regroupés. Dans le salon dédié, les messages envoyés pendant que le bot répond ne reçoivent plus chacun leur réponse ; ils lui sont transmis ensemble (avec leurs images) et il y répond en une seule fois.

Corrections

  • Messages système ignorés. Les messages système (arrivée d'un membre, message épinglé, boost, fil créé…) et les messages sans rien à lire (sondages…) ne déclenchent plus de réponse payante de Claude.

  • /reset pendant une réponse. La mémoire était mal vidée : l'échange en cours y était réécrit juste après. Le reset attend désormais la fin de la réponse avant de tout effacer.

  • Mentions moins chères. Le contexte lu pour répondre à une mention n'est plus écrit dans le cache de prompt (surcoût de 25 %), puisqu'il change à chaque mention et n'y était jamais relu.

  • Image d'une mention. L'image jointe à la mention elle-même est maintenant lue (seule celle du message cité l'était). Si les deux en ont une, c'est celle de la mention qui est envoyée à Claude.

Version 5.3.0

En bref : accès à Internet en option, et un cache qui divise le coût des messages.

Nouveautés

  • Accès à Internet (désactivé par défaut). Avec WEB_SEARCH=on dans le .env, le bot peut faire des recherches web et lire les liens partagés dans la conversation (outils web_search et web_fetch d'Anthropic).
    • Il ne cherche que si la question porte sur l'actualité ou une info qu'il ne connaît pas, et nomme sa source dans sa réponse (sans lien).
    • WEB_MAX_USES limite le nombre de recherches (et de pages lues) par message.
    • Seule la réponse finale est envoyée sur Discord, sans les commentaires écrits pendant les recherches.
    • Dans la mémoire, une mention indique au bot qu'il a réellement cherché, pour qu'il ne croie pas avoir inventé sa réponse au message suivant.
    • Avec la recherche activée, prévoir API_TIMEOUT=90.

Améliorations

  • Cache de prompt. La personnalité, les outils et l'historique sont relus depuis le cache à 10 % du prix (pendant 5 minutes, prolongées à chaque message). Avec la recherche web activée, un message simple passe d'environ 0,015 $ à 0,002 $.

  • Coût estimé plus juste. Le coût dans les logs tient compte du cache (tokens lus et écrits) et des recherches web (PRICE_WEB_SEARCH_PER_1000).

Version 5.2.0

En bref : lecture des fichiers texte, et des réponses plus naturelles.

Nouveautés

  • Fichiers texte. Le bot lit un fichier .txt joint au message et en tient compte dans sa réponse.

    • Un fichier .txt par message (en plus d'une éventuelle image), 100 Ko maximum.
    • Fonctionne dans le salon dédié et en mode mention.
    • Encodage UTF-8 ou Windows (Bloc-notes) reconnu automatiquement.
    • Dans la mémoire, seul le nom du fichier est conservé, pas son contenu (comme pour les images), pour ne pas faire grimper le coût des messages suivants.

  • Personnalité perso. Les fichiers *.local.txt sont exclus de GitHub (.gitignore). On peut y mettre une personnalité contenant des infos privées (ex. PERSONALITY_FILE=personality_prompt.local.txt dans le .env) ; personality_prompt.txt reste la personnalité par défaut publiée sur GitHub.

Améliorations

  • Réponses plus naturelles. Le bot n'utilise plus la fonction « Répondre » de Discord pour ses réponses : il écrit simplement à la suite dans le salon, comme un humain.
    • Les messages d'erreur (fichier non pris en charge, image en trop, etc.) restent en « Répondre », pour qu'on sache à qui ils s'adressent.

Version 5.1.0

En bref : le bot comprend les réponses à un message, même ancien.

Nouveautés

  • Réponses aux messages. Quand on utilise « Répondre » sur un message, même ancien, le bot lit le message cité et en tient compte dans sa réponse.

    • Si le message cité vient du bot, il sait qu'il s'agit de sa propre réponse.
    • Le texte cité est limité à 500 caractères.
    • Si le message cité contient une image, elle est aussi envoyée à Claude, sauf si la réponse contient déjà sa propre image (celle-ci est prioritaire).
    • Fonctionne dans le salon dédié et en mode mention.

  • Images en mode mention. Le bot peut maintenant voir une image, celle du message cité.

Améliorations

  • Images. Le téléchargement et la préparation des images passent par une seule fonction, partagée entre le salon dédié et les messages cités. Une image citée illisible ou trop lourde est simplement ignorée (avertissement dans bot.log) au lieu de bloquer la réponse.

  • /reset réservé aux modérateurs (permission « Gérer les messages ») et aux administrateurs du serveur.

    • Elle est masquée pour les autres membres et n'est plus disponible en messages privés.
    • Si un administrateur l'ouvre à tous dans les paramètres du serveur, le bot refuse quand même la commande (réponse visible uniquement par l'auteur) et note la tentative dans bot.log.

Divers

  • discord.py 2.5 minimum est désormais requis (requirements.txt).
  • README : ajout de la fonctionnalité « Réponses », et précision sur les droits nécessaires pour /reset.

Version 5.0.0

En bref : le bot passe de Mistral à Claude.

Nouveautés

  • Passage de Mistral à Claude (Anthropic) pour générer les réponses.
  • Réécriture complète du bot.

Migration depuis la version 4 (Mistral)

  • L'ancien conversation_history.json est converti automatiquement au premier lancement (les images sont remplacées par un marqueur texte).
  • Dans le .env : MISTRAL_API_KEY devient ANTHROPIC_API_KEY, et MISTRAL_MODEL devient CLAUDE_MODEL.
  • L'intent Discord « Presence » n'est plus nécessaire.