Nadia — Le secret sous sa peau

Ta meilleure amie goth-punk depuis le lycée vient de te sauver d'un vampire. Le problème ? Elle a dû devenir une louve-garou pour y parvenir.

Fête de la Musique, trop de bière, trop de burgers, musique forte partout—et un prédateur qui a choisi le mauvais humain ivre à mordre. Nadia passe des années à cacher ce qu'elle est vraiment à {{user}}. Ce soir, ce secret n'est plus que cendres sur le bitume.

Ce à quoi s'attendre

• RP de révélation surnaturelle entre amis de longue date.

• Une lycanthrope goth-punk garçon manqué, passionnée de jeux vidéo, de comics, d'informatique, de randonnée et de camping.

• L'amitié avant tout ; la romance est optionnelle et jamais présumée.

• Des intrigues de mystère surnaturel urbain impliquant des vampires, le secret, les menaces et les conséquences de la révélation de Nadia.

• Conçu comme personnage de test de long chat en direct pour Janitor Memory Optimizer v1.0.0.

Comment jouer

Réponds simplement naturellement. Interroge Nadia, rejette-la, accepte-la, enquête sur le vampire, trouve un endroit à l'abri des regards, ou essaie d'empêcher la nuit de devenir encore plus étrange. Il n'y a aucune commande de mémoire ni menu de configuration.

Notes de contenu

Alcool, tabac, attaque de vampire, violence surnaturelle, sang/crocs, langage grossier, humour graveleux, peur du rejet. Les sentiments et les choix de {{user}} ne sont jamais prédéterminés.

Version de test : 2026-08-18

Janitor Memory Optimizer v1.0.0

Moteur de mémoire passive final

Mémoire de roleplay à long terme pour JanitorAI — entièrement passive, prête à l'emploi et invisible pour l'utilisateur.

Janitor Memory Optimizer est un moteur de mémoire ES5 avancé conçu pour JanitorAI Scripts Beta. Son objectif est simple : aider un personnage à préserver des informations importantes, des relations, des événements, des promesses, des lieux, des objets, des quêtes, des conflits et des arcs narratifs au long cours sans dépendre d'un historique de chat brut toujours plus long.

Il n'y a aucune commande à apprendre, aucun bouton à presser, aucun menu de mémoire à gérer et aucune configuration à surveiller. Installe le script, attache-le à ton personnage et discute normalement.

Le moteur lit discrètement la conversation, décide de ce qui compte, l'organise en plusieurs couches de mémoire, et n'écrit que le résultat utile dans la Scenario d'exécution du personnage afin que le LLM puisse le relire lors des tours futurs.

Il n'injecte jamais de faux messages dans la conversation.

Pour tout le monde : que fait-il concrètement ?

Imagine un long roleplay où, des centaines de messages plus tôt :

• Nadia t'a dit qu'elle était ta sœur.

• Tu as découvert une clé en laiton dans une archive abandonnée.

• Samira a trahi Nadia.

• Nadia a cessé de faire confiance à Samira à cause de cette trahison.

• Tu as promis de retrouver quelqu'un plus tard à la Gare Centrale.

• Un mystère s'est lentement développé à travers plusieurs scènes différentes.

Normalement, les vieilles informations finissent par devenir difficiles à garder disponibles pour un modèle de langage à mesure que la conversation s'allonge.

Janitor Memory Optimizer transforme continuellement les parties importantes de la conversation en un système de mémoire compact et structuré.

Plus tard, si la conversation redevient pertinente pour Nadia, le moteur peut rappeler ce qui compte à propos de Nadia sans reverser des centaines de vieux messages dans le contexte.

Si tu poses une question large comme :

Comment ma relation avec Nadia a-t-elle évolué ?

il peut rappeler l'arc relationnel compact à long terme.

Si tu demandes :

Quand exactement Nadia a-t-elle cessé de faire confiance à Samira ?

il peut automatiquement descendre de l'arc narratif à long terme jusqu'à l'épisode concerné et, si besoin, jusqu'à la preuve atomique originale.

Tu ne dis jamais au moteur de mémoire comment faire tout cela. Tu fais simplement du roleplay.

Prêt à & l'emploi

L'ensemble du système a été spécifiquement conçu pour nécessiter le moins d'interaction utilisateur possible.

1. Ouvre Scripts Beta sur JanitorAI.

2. Crée un script Avancé.

3. Colle le script complet Janitor Memory Optimizer v1.0.0.

4. Enregistre-le.

5. Attache-le à ton personnage.

6. C'est tout.

Il n'y a pas d'assistant de configuration. Il n'y a pas de commandes requises. Il n'y a pas d'interface de débogage pour le joueur. Il n'y a pas de budgets de tokens manuels à maintenir.

L'expérience voulue est : installe une fois, puis oublie que le moteur de mémoire existe.

Mémoire en langage naturel 100 % passive

L'optimiseur observe la conversation ordinaire et évalue les informations automatiquement.

Des demandes explicites en langage naturel peuvent aussi renforcer ou supprimer des souvenirs :

Souviens-toi que Nadia est ma sœur.
N'oublie pas que la clé de l'archive appartient à Samira.
Oublie tout ce qui concerne Nadia.
Oublie ce que j'ai dit à propos de la clé en laiton.

Ce sont des phrases normales, pas des commandes.

Le script ne répond pas par des messages comme « Mémoire enregistrée » ou « Mémoire supprimée ». Le personnage continue simplement le roleplay.

Les changements narratifs ordinaires sont traités différemment de l'oubli. Par exemple :

Je ne fais plus confiance à Nadia.

n'efface pas le passé. L'optimiseur peut conserver l'état relationnel précédent comme historique et suivre le nouvel état comme un changement.

Aucune injection dans le chat

C'est l'une des règles de conception les plus importantes de tout le projet.

La conversation elle-même est en lecture seule.

Le script peut lire les surfaces de conversation disponibles telles que :

• context.chat.last_message

• context.chat.last_messages

• context.chat.message_count

Il n'ajoute pas de messages utilisateur, de messages assistant ou de messages système synthétiques.

Il n'utilise pas :

• script_output pour la mémoire ;

• example_dialogs pour la mémoire ;

• de fausses entrées de conversation ;

• des pseudo-commandes de chat cachées.

La seule surface de mémoire active visible par le LLM est :

context.character.scenario

Le coffre d'exécution privé sous context.chat.jai_memory_optimizer_v10 est un état technique, pas un message de conversation.

Comment fonctionne le moteur de mémoire

En interne, Janitor Memory Optimizer utilise plusieurs couches progressivement plus abstraites :

Lecture seule du chat → Faits atomiques → Fragments hachés → Dossiers sémantiques → Graphe temporel → Intelligence d'entités → Mémoire épisodique → Fils narratifs → Rappel hiérarchique → Scenario

1. Faits atomiques

Les informations importantes sont d'abord conservées sous forme de faits atomiques traçables. Un fait peut porter des informations telles que son type, sa source, son importance, son tour, ses occurrences de pertinence, les entités associées et l'ID de preuve.

Ces mémoires atomiques restent ce qui s'approche le plus d'une source de vérité au sein du moteur. Les résumés de niveau supérieur ne les remplacent pas silencieusement.

2. Coffre haché adressé par contenu

Les faits sont organisés en fragments thématiques stockés dans un état d'exécution privé.

Les fragments utilisent des hachages de contenu afin que la mémoire inchangée puisse être réutilisée au lieu d'être constamment réécrite.

Les hachages sont des adresses et des contrôles d'intégrité, pas du chiffrement.

3. Dossiers sémantiques

Les souvenirs liés sont regroupés en profils sémantiques dérivés.

Un dossier peut distinguer :

• les informations stables ;

• les informations actuelles ;

• les informations historiques.

Cela permet au modèle de recevoir un aperçu utile d'une personne ou d'un sujet sans recevoir chaque souvenir individuel à la fois.

4. Graphe de mémoire temporel

L'optimiseur peut établir des relations entre personnes, lieux, objets, quêtes et événements.

Les arêtes temporelles distinguent délibérément :

• causes — uniquement lorsque la source soutient explicitement la causalité ;

• précède — ordre chronologique sans affirmer la causalité ;

• remplace — un état plus récent remplaçant ou contredisant un plus ancien.

Autrement dit, le moteur ne présume pas que, parce que l'événement B s'est produit après l'événement A, l'événement A a causé l'événement B.

5. Intelligence d'entités

Le moteur effectue une résolution d'entités prudente pour :

• les alias explicites ;

• les surnoms ;

• certaines relations nom complet / nom de famille ;

• les pronoms non ambigus sur une courte fenêtre ;

• certaines références relationnelles non ambiguës comme « ma sœur ».

Lorsqu'une référence est ambiguë, l'optimiseur préfère ne pas fusionner les identités plutôt que d'inventer avec assurance la mauvaise connexion.

6. Température de mémoire adaptative

Les souvenirs sont dynamiquement traités comme chauds, tièdes ou froids.

La température est influencée par plus que l'ancienneté. Le moteur prend en compte l'utilité observée, l'importance, la récence, la stabilité et la pertinence répétée.

Un vieux souvenir qui redevient régulièrement utile peut rester important. Un souvenir froid n'est pas automatiquement considéré comme faux et n'est pas effacé simplement parce qu'il est froid ; il est avant tout dépriorisé.

7. Consolidation épisodique

Les anciens groupes d'événements liés peuvent devenir des souvenirs épisodiques compacts.

Au lieu de porter en permanence dix événements détaillés dans le rappel actif, l'optimiseur peut conserver un épisode extractif contenant les moments clés de ce qui s'est passé.

La preuve atomique sous-jacente peut rester attachée à cet épisode, permettant un examen plus poussé ultérieur lorsque des détails exacts sont nécessaires.

8. Fils narratifs

Plusieurs épisodes peuvent eux-mêmes devenir des arcs narratifs au long cours.

Les familles de fils prises en charge incluent :

• entity:*

• relationship:*

• quest:*

• location:*

• mystery:*

• conflict:*

• topic:*

Un seul épisode peut participer à plusieurs fils narratifs sans dupliquer sa preuve d'origine.

Cela signifie qu'une scène impliquant Nadia, un mystère d'archive et la quête du Fil d'Argent peut contribuer aux trois arcs narratifs tout en restant un seul et même élément d'historique sous-jacent.

9. Rappel hiérarchique

L'optimiseur s'efforce de répondre aux besoins de mémoire en utilisant la couche utile la moins coûteuse.

Une question large peut ne nécessiter qu'un fil narratif.

Une question plus précise peut automatiquement descendre à travers :

Fil → Épisode → Preuve atomique

Cela aide à préserver les détails sans forcer chaque détail dans chaque prompt.

Récupération réversible : dépôt fiduciaire JMO10

Le Scenario porte également un point de contrôle de récupération limité.

La couche de récupération utilise :

sérialisation compacte → LZW12 → Base64 → somme de contrôle

Si l'état d'exécution privé disparaît alors que le point de contrôle précédent du Scenario reste disponible, l'optimiseur peut reconstruire la mémoire à partir de ce point de contrôle.

Conceptuellement :

Scenario → Dépôt JMO10 → Faits atomiques / Épisodes archivés → Dossiers sémantiques → Graphe temporel → Fils narratifs

Les données de dépôt corrompues sont rejetées plutôt que converties en mémoire fabriquée.

JMO10 peut aussi lire les anciens formats de dépôt JMO3–JMO9 pour la migration et la récupération.

Gestion automatique du contexte

L'objectif n'est pas de déverser tout le coffre de mémoire dans chaque génération.

Le stockage et le rappel sont délibérément séparés.

Le moteur ajuste automatiquement les budgets de rappel et de récupération en fonction de l'espace disponible et du type d'information actuellement requis.

Une simple continuation nécessite moins de mémoire qu'une question détaillée sur la causalité, la chronologie ou une relation s'étendant sur des centaines de messages.

Si nécessaire, l'optimiseur réduit les détails avant de déborder de son enveloppe de travail interne.

Garde-fous internes

Ce sont des heuristiques de projet, et non des limites officielles revendiquées de JanitorAI.

• Plafond souple estimé combiné Personnalité + Scenario : 4 000 tokens

• Fragments thématiques maximum : 512

• Graphe temporel : 384 nœuds / 768 arêtes

• Archives épisodiques : 160

• Fils narratifs : 192

• Budgets de rappel et de dépôt : adaptatifs automatiquement

Ceux-ci existent pour maintenir le système de mémoire borné et prévisible plutôt que de permettre une croissance incontrôlée.

Sécurité pour les longs roleplays & Hygiène de la mémoire

Le moteur inclut plusieurs sauvegardes prudentes développées tout au long du projet :

• consolidation des doublons exacts ;

• synthèse des quasi-doublons lorsque approprié ;

• remplacement de l'état actuel sans détruire aveuglément l'historique utile ;

• filtrage des questions afin que les questions ne deviennent pas automatiquement des faits établis ;

• détection prudente de la causalité ;

• résolution d'entités consciente de l'ambiguïté ;

• oubli ciblé en langage naturel ;

• rejet des points de contrôle de récupération corrompus ;

• rappel historique conscient de la pertinence ;

• isolement du remplissage afin qu'un « Okay. » générique n'entraîne pas d'archives non pertinentes dans le contexte ;

• préservation de la preuve atomique derrière les résumés de niveau supérieur ;

• mémoire bornée et élagage du graphe ;

• migration automatique des anciens états d'optimiseur lorsqu'ils sont disponibles.

Conçu pour le roleplay au long cours

Janitor Memory Optimizer est particulièrement utile pour les roleplays impliquant :

• des relations à évolution lente ;

• des distributions de plusieurs personnages ;

• des mystères et des enquêtes ;

• des quêtes et des objectifs ;

• des alliances changeantes ;

• des conflits au long cours ;

• des inventaires persistants ou des objets importants ;

• des lieux récurrents ;

• le développement des personnages ;

• des histoires s'étendant sur des centaines ou des milliers de tours.

Validation & Tests de charge

La v1.0.0 n'a pas été publiée après une simple vérification de syntaxe. Elle a subi des suites dédiées de régression, de durcissement, de récupération et de stress sur un horizon long.

Validation statique / du pack créateur

• Vérification de la syntaxe Node : RÉUSSI

• Validateur ES5 prudent : RÉUSSI

• Erreurs : 0

• Avertissements : 0

• Taille à l'exécution : 191 418 / 400 000 octets

Tests d'invariance de la surface de sortie

• Aucun script_output : RÉUSSI

• Aucune écriture dans l'historique du chat : RÉUSSI

• last_message reste inchangé : RÉUSSI

• message_count reste inchangé : RÉUSSI

• Aucune écriture de mémoire dans example_dialogs : RÉUSSI

• Aucun bloc de mémoire actif ajouté à la Personnalité : RÉUSSI

• Exactement une destination de mémoire visible par le LLM — Scenario : RÉUSSI

• Aucune syntaxe de commande utilisateur requise ni exposée : RÉUSSI

Suite de régression

21 assertions ciblées : RÉUSSI

La couverture comprenait :

• scénario de 109 tours ;

• consolidation épisodique ;

• fils narratifs ;

• rappel large d'un fil ;

• examen approfondi exact/historique ;

• isolement du remplissage ;

• récupération après perte d'état ;

• compatibilité de migration d'anciennes versions.

Suite de durcissement finale

23 assertions supplémentaires : RÉUSSI

Cette suite couvrait spécifiquement :

• architecture Scenario uniquement ;

• migration de l'état actif v0.9 vers v1.0 ;

• récupération de l'ancien dépôt JMO9 ;

• preuve atomique survivant à la récupération héritée ;

• rejet sûr d'un dépôt corrompu ;

• oubli ciblé en langage naturel ;

• préservation des souvenirs sémantiques non liés lors d'un oubli ciblé.

Test de charge de 500 tours

Corpus de test :

500 tours de population + 60 requêtes de mémoire en langage naturel + 3 récupérations complètes après perte d'état privé.

• Faits avant récupération : 42

• Faits après 3 récupérations : 42

• Épisodes avant / après : 10 / 10

• Fils narratifs avant / après : 5 / 5

• Récupérations complètes après perte d'état : 3 / 3 RÉUSSI

Test de charge sur horizon long de 2 000 tours

Un test bien plus vaste a également été exécuté :

2 000 tours de population + 60 requêtes naturelles + 3 récupérations complètes après perte d'état.

• Faits avant / après récupération : 61 / 61

• Épisodes avant / après : 40 / 40

• Fils narratifs avant / après : 5 / 5

• Récupérations complètes après perte d'état : 3 / 3 RÉUSSI

• Constructions de fils : 195

• Réutilisations de signature de fil : 1 927

• Constructions de graphe : 201

• Réutilisations de graphe : 1 860

Cela démontre que les structures dérivées sont largement réutilisées plutôt que reconstruites aveuglément à chaque tour.

Optimisation des performances

Sur le même harnais Node local 500+60 :

• référence v0.9 : environ 6,49 secondes

• v1.0 optimisée : environ 3,87 secondes

• Réduction relative : environ 39 %

Ce benchmark mesure le script dans un harnais de test Node VM local. Il s'agit d'une mesure relative de régression/performance pour le script lui-même, et non d'une affirmation sur la latence des serveurs de JanitorAI.

Compatibilité & Migration

La v1.0.0 écrit le format de récupération actuel JMO10.

Il peut lire les anciens points de contrôle de dépôt JMO3 à JMO9.

La migration depuis les états précédents de Janitor Memory Optimizer est prise en charge lorsque l'ancien état nécessaire est encore disponible.

Pour une installation neuve, utilise simplement la v1.0.0.

Codé à l'instinct avec ChatGPT 5.6

Oui, ce projet a été codé à l'instinct avec ChatGPT 5.6.

Le moteur a été développé de façon itérative par une conception, des tests, du débogage, des tests de charge et des révisions architecturales répétées dirigés par l'humain, avec ChatGPT 5.6 assistant pour le code.

Il a évolué à travers plusieurs prototypes : d'un simple injecteur de mémoire sélective vers un coffre adressé par contenu, un système de récupération réversible, une hiérarchie de mémoire sémantique, un graphe temporel, un résolveur d'entités, une archive épisodique et un moteur de fils narratifs.

La version finale a ensuite été soumise à des suites automatisées de régression et de charge plutôt que d'être publiée simplement parce que le code généré « semblait correct ».

Il s'agit d'un projet communautaire indépendant. Ce n'est pas un produit officiel d'OpenAI ou de JanitorAI, et la mention de ChatGPT 5.6 décrit le processus de développement plutôt qu'une certification ou une approbation officielle.

Pourquoi l'utiliser ?

Parce que la mémoire ne devrait pas devenir une mécanique de jeu supplémentaire que le joueur doit gérer.

Tu ne devrais pas avoir à mettre une scène en pause pour taper :

/save_memory relationship Nadia trust -1

Tu devrais simplement pouvoir écrire :

Après ce que Nadia a fait, je ne pense pas pouvoir lui faire confiance à nouveau.

et continuer l'histoire.

C'est la philosophie de conception derrière Janitor Memory Optimizer.

Le traitement de la mémoire devrait se faire en arrière-plan. Le chat devrait rester un chat. Les définitions de personnage devraient porter la mémoire de travail. Le LLM devrait recevoir la plus petite quantité utile de contexte pour le moment présent.

En bref

• Prêt à & l'emploi.

• Entièrement passif.

• Aucune commande.

• Aucune interface de mémoire.

• Aucun faux message de chat.

• Mémoire visible par le LLM uniquement dans le Scenario.

• Mémoriser / oublier en langage naturel.

• Preuve atomique.

• Coffre de mémoire haché.

• Dossiers sémantiques.

• Graphe temporel et causal.

• Intelligence d'entités prudente.

• Mémoire adaptative chaude / tiède / froide.

• Consolidation épisodique à long terme.

• Fils narratifs persistants.

• Rappel hiérarchique avec examen approfondi des preuves.

• Dépôt de récupération JMO10 réversible.

• Prise en charge de la récupération héritée.

• Budgétisation automatique du contexte.

• Testé sous charge sur plus de 2 000 tours.

• 3/3 récupérations complètes après perte d'état dans les deux suites de stress majeures.

• 0 erreur de validation ES5.

• 0 avertissement de validation ES5.

Colle-le. Attache-le. Fais du roleplay normalement.
Laisse le personnage se souvenir.