# Dream / Réflexion Comprenez la prévisualisation des candidats Dream, la consolidation guidée par révision, les modes de console et la limite séparant les propositions de prévisualisation de l'outil de maintenance reflect. - Canonical: https://docs.xmemo.dev/fr/docs/concepts/dream-reflection - Locale: fr-FR - Content-Locale: fr-FR - Canonical-Content-Digest: 3e7b3df8ea8c94fd1d518674032b79705bd4d88c083d3d3add5929f5eda0610c - Edition-Digest: 971a8cfd1999ebd0fd3add5a07825dad2a806c5bea85e9f2974a9e508a4260ad - Source-Revision: sha256:6f8e110913bcc6793a7a5e098bcaed56d211e60f7e0895041fff8316967b9d49 ## Architecture de prévisualisation Dream et flux de travail de révision explicite Dream est une fonctionnalité de Preview distincte et révisée par l'utilisateur, accessible dans la Memory Console sur https://xmemo.dev/me#dream. Elle est distincte de l'outil de maintenance reflect (qui exécute des passes de consolidation programmatiques à la demande via MCP/API ; voir /docs/tools/reflect). Plutôt que d'exécuter des mutations silencieuses en arrière-plan, Dream met en avant ce que l'utilisateur examine et choisit de sauvegarder, en organisant le contexte conversationnel dispersé en candidats ancrés dans les sources. - Espace de travail de la console : Dans la Memory Console sur https://xmemo.dev/me#dream, Dream fournit un espace de prévisualisation interactif sous le sous-titre : "Review recurring patterns before they become long-term memory." - Révision pilotée par l'utilisateur : Dream ne modifie jamais la mémoire persistante en arrière-plan ; tous les éléments candidats nécessitent une inspection et une confirmation humaines explicites avant toute écriture de destination. - Distinction par rapport à reflect : Dream est une fonctionnalité de prévisualisation distincte où les candidats sont générés pour examen par l'utilisateur, et rien n'est enregistré sans confirmation humaine explicite. En revanche, la passe de maintenance reflect (/docs/tools/reflect) est un outil interne dont l'action summarize lit les mémoires épisodiques actives et écrit des résumés ancrés dans les sources sous reflections/episodic. Pour les faits récurrents, reflect fournit une action promote d'épisodique à sémantique exigeant une importance moyenne d'au moins 0.35 et une confiance moyenne d'au moins 0.6. Ses actions de cycle de vie exécutent expire, decay et archive, avec dry_run offrant une planification sûre sans écriture de destination. - Frontière architecturale : La génération de candidats Dream est strictement un mécanisme de prévisualisation et n'implémente pas d'architecture spéculative multi-passes Light, REM ou Deep ni de mutations autonomes en arrière-plan. - Posture de défaillance sécurisée : Si une exécution s'arrête ou rencontre un problème, la mémoire existante reste inchangée ("Dream stopped safely. Existing memory was not changed."). ## Disponibilité du compte, statut dans le catalogue de forfaits et limites de prévisualisation Dream fonctionne strictement si Dream est activé pour votre compte. Tous les contrôles d'exécution sont désactivés par défaut dans les environnements de production. La documentation publique évite d'exposer des indicateurs de configuration interne. - Disponibilité du compte : Dream fonctionne strictement si Dream est activé pour votre compte. Si la fonctionnalité n'est pas active pour un espace de travail, la console affiche : "Dream is not enabled for this workspace yet. Your memory remains unchanged." - Statut du catalogue : Dans le catalogue des offres de produits, Dream n'est pas inclus dans le forfait Free, tandis que le forfait Plus liste les capacités de Dream. Cependant, la documentation ne prétend nullement que Plus débloque Dream dans la pratique aujourd'hui, car le fournisseur personnel de secours refuse l'accès lorsque l'application commerciale est inactive. - Limite de défaut : Dream est actuellement en version préliminaire et peut ne pas encore générer de candidats pour votre compte. La synthèse basée sur des modèles ne peut pas s'exécuter directement dans l'environnement de worker fourni, et la confirmation des candidats dépend de la configuration de capacité du serveur. - Confirmation humaine stricte : Le système impose une frontière stricte de confirmation humaine. La documentation réfute toute allégation de sauvegarde automatique ou d'ajout en arrière-plan ; chaque élément proposé requiert le consentement manuel de l'utilisateur. ## Cycle de vie d'exécution, éligibilité des preuves et codes de motif de filtrage Une exécution Dream examine les preuves de mémoire éligibles sur une fenêtre d'observation configurable (définie par défaut à 30 jours) pour identifier des schémas récurrents sans modifier les enregistrements sources : - Collecte de preuves : Une exécution de prévisualisation examine les mémoires épisodiques actives et rappelables créées au cours de la fenêtre d'observation (personnalisable via --window-days jusqu'à 365 jours). - Candidats ancrés : Les preuves éligibles sont regroupées en thèmes récurrents, générant des éléments candidats affichés avec leur lignage source et un score de confiance ("Confidence Score"). - Pourquoi les preuves ont été filtrées : Dans la console, le récapitulatif d'exécution signale "Why evidence was filtered" à l'aide de puces de motif standardisées : score below threshold, insufficient occurrences, insufficient evidence days, insufficient query contexts, duplicate candidate, source not episodic, source inactive et contradiction detected. - Résumé d'exécution sans contenu : Les exécutions terminées affichent un récapitulatif de révision : "Dream reviewed {{considered}} signals, generated {{generated}} grounded candidates, and saved {{promoted}} confirmed memories.", assorti de la garantie de sécurité : "This report is review-only and never becomes Dream evidence." ## Modes de fonctionnement de la console et préréglages de planification Les paramètres Dream offrent un contrôle granulaire sur les modes d'exécution et les calendriers d'évaluation dans le volet des paramètres de la console : - Modes de fonctionnement : Les utilisateurs choisissent entre deux modes de comportement : "Preview only" (évalue les preuves et génère des candidats révisables sans droits d'écriture) et "Allow explicit confirmation" (active l'interface de confirmation afin que les utilisateurs puissent examiner et valider sélectivement les candidats individuels). - Préréglages de planification : La fréquence d'exécution est configurée via trois préréglages : "Manual only" (s'exécute uniquement à la demande en sélectionnant "Run Preview" dans la console ou en émettant une commande de prévisualisation en CLI), "Daily around 03:00" (exécution quotidienne planifiée évaluée vers 03:00 dans le fuseau horaire local de l'utilisateur) et "Weekly on Monday around 03:00" (exécution hebdomadaire planifiée évaluée le lundi vers 03:00 dans le fuseau horaire local de l'utilisateur). - Restriction des exécutions planifiées : Les exécutions planifiées opèrent en mode preview only ; les évaluations planifiées en arrière-plan ne valident jamais d'écritures en mémoire et ne contournent pas l'examen humain. - Ancrage au fuseau horaire : Les exécutions planifiées utilisent le fuseau horaire local du navigateur de l'utilisateur. ## Flux de travail de confirmation, résultats typés et cycle de vie de destination La validation des candidats se fait en mode append-only et nécessite une action explicite de l'utilisateur. La console prend en charge la confirmation élément par élément et des résultats typés optionnels : - Confirmation de base : En mode de prévisualisation standard, cliquer sur le bouton "Confirm and save" sur une carte de candidat crée un NOUVEL enregistrement de mémoire sous le chemin dream/confirmed/... avec la clé sémantique dream:confirmed:... . Les mémoires sources ne sont jamais modifiées ni écrasées. - Configuration des résultats typés : Lorsque les résultats typés sont disponibles, le volet des paramètres pose la question "What should Dream prepare?" avec l'indication "Choose what to generate. Turning a type off keeps existing drafts and saved content." - Six choix de génération : (1) Preferences : "Clarify your preferences" ; (2) Knowledge : "Distill knowledge worth keeping" ; (3) Skills : "Turn experience into reusable skills" ; (4) Projects : "Organize project memory" ; (5) Patterns : "Discover lasting patterns" ; (6) Durable Memory : "Build reusable long-term memory". - Interrupteur de génération vs consentement de destination : L'activation d'un interrupteur de génération ne confère pas de consentement à une destination ; tous les résultats préparés apparaissent sous "Prepared for your review" et exigent un examen manuel. - Actions de révision des candidats : Les réviseurs peuvent sélectionner "Save edits" pour modifier les titres et contenus proposés, "Review later" pour différer, "Reject" pour écarter, ou accepter vers la destination ciblée. - Acceptation par destination : Knowledge s'accepte via "Add draft to knowledge base" dans une base de connaissances choisie en tant que DRAFT (avec états d'indexation de recherche : "Saved. Preparing for search.", "Search index is ready. Publication is a separate choice.", "Saved, but indexing needs another attempt.") ; Skill s'accepte via "Add draft to Cloud Skills" en tant que DRAFT ; Project s'accepte via "Confirm project organization" (le résultat d'association de projet est le seul chemin qui réassigne des mémoires existantes à un espace de travail de projet) ; Memory s'accepte via "Save as memory". - Suppression : Les résultats confirmés deviennent des mémoires standard, des brouillons de connaissances ou des brouillons de compétences dans leurs magasins respectifs. Ils sont supprimés à l'aide des actions standard de suppression de la console ou de l'API ; il n'existe aucun mécanisme d'annulation ou de rollback spécifique à Dream. ## Isolation des espaces de travail, limites d'équipe et opérations CLI Les autorisations d'espace de travail et les outils CLI imposent des frontières multi-tenant strictes et des capacités de rôle : - Délimitation de l'espace de travail : L'en-tête de la console identifie l'espace de travail actif comme "Personal space" ou "Team space". - Autorisations d'équipe : Dans les espaces Team, seuls les propriétaires et administrateurs d'équipe peuvent modifier les paramètres Dream, annuler les exécutions actives ou confirmer les mémoires candidates ("Only Team owners and admins can change Dream settings."). - Limitation des résultats typés en équipe : Les résultats typés ne sont pas disponibles dans les espaces Team. Les espaces de travail Team fonctionnent en mode preview-only ou de confirmation de mémoire v1. - Commandes CLI vérifiées : La CLI xmemo (commit fixé d412c7866b7a4c8eedb3a0cf40748c6aef8707ec, src/commands/dream.js) prend en charge trois commandes vérifiées : xmemo dream preview [--window-days ] [--wait] [--json] (déclenche la prévisualisation ; échoue en fermeture sécurisée si la prévisualisation est désactivée avec "Dream preview is disabled; CLI will not change Dream settings."), xmemo dream show [--wait] [--json] (affiche les éléments candidats ; prend en charge --receipt-out pour les accusés de lecture) et xmemo dream apply --item --from --yes [--json] (confirme un candidat à l'aide du point de terminaison de confirmation v1). - Frontières opérationnelles de la CLI : La CLI ne peut pas modifier les paramètres de configuration de Dream (les paramètres doivent être gérés dans la console), et dream apply fonctionne exclusivement avec la confirmation de mémoire v1 (n'effectue aucune mutation de résultat typé). ```bash # Trigger a candidate preview across a 30-day window xmemo dream preview --window-days 30 --wait --json # Inspect candidate proposals and record a read receipt xmemo dream show --receipt-out receipt.json # Confirm a candidate proposal into memory via v1 confirmation xmemo dream apply --item --from view.json --yes ``` ## Utilisateur de ChatGPT Donnez à ChatGPT un accès durable à vos préférences XMemo, faits de projet, décisions et TODOs sans coller de jetons bearer dans un chat. Connectez le serveur MCP XMemo hébergé via le flux OAuth de l'application ChatGPT/OpenAI, puis approuvez les autorisations memory:read et memory:write pour votre compte XMemo. Enregistrez une préférence synthétique ou une note de projet, démarrez un nouveau chat, puis demandez à ChatGPT de la rappeler via XMemo avant de poursuivre le travail. Si OAuth échoue ou si les outils n'apparaissent pas, déconnectez-vous du serveur MCP dans l'application hôte, reconnectez l'URL du serveur XMemo et réessayez avant de créer des jetons directs. ## Développeur Copilot / Codex Transmettez les décisions du dépôt, les conventions de codage, les notes de correctifs et l'historique des tâches entre les agents IDE et CLI. Utilisez OAuth pour VS Code / GitHub Copilot et Gemini CLI lorsqu'il est disponible. Pour Copilot CLI, Codex, Cursor ou d'autres clients MCP directs, conservez XMEMO_KEY dans l'environnement local ou le gestionnaire de secrets et définissez un identifiant XMEMO_AGENT_INSTANCE_ID stable. Enregistrez une décision relative au code ou un correctif, puis demandez au prochain agent de l'IDE ou de la CLI de rappeler le contexte XMemo pertinent avant toute modification. Si les rappels sont vides, vérifiez le chemin de configuration MCP sélectionné, la variable d'environnement XMEMO_KEY pour les clients directs et tout identifiant OAuth obsolète dans l'application hôte. ## Responsable de projet pilote d'équipe / entreprise Évaluez la mémoire partagée avec les contrôles de compte, l'attribution des sources, les flux d'exportation/suppression et des preuves de configuration sécurisées pour les évaluateurs. Créez ou rejoignez l'espace de travail sécurisé XMemo, invitez les utilisateurs approuvés, puis connectez chaque client via OAuth ou un identifiant direct délimité selon les badges de disponibilité. Demandez à un membre du projet pilote d'enregistrer une mémoire d'équipe synthétique, confirmez l'attribution de la source dans XMemo, puis examinez les chemins de suppression/exportation et de support. Si un membre ne parvient pas à se connecter, vérifiez les permissions de rôle, l'approbation OAuth, l'état de disponibilité du client et les conseils du support avant d'émettre un nouveau jeton. ## Opérateur d'agents autonomes Permettez aux agents autonomes ou planifiés d'enregistrer leur progression, de récupérer les décisions antérieures et de conserver une identité d'instance stable et non secrète. Récupérez /api/v1/mcp/config/autonomous-agent. Privilégiez auth_modes.oauth lorsque l'exécuteur prend en charge OAuth + en-têtes personnalisés ; utilisez auth_modes.xmemo_key avec XMEMO_KEY issu d'un gestionnaire de secrets uniquement pour les exécuteurs entièrement autonomes. Exécutez une tâche synthétique qui consigne la progression dans XMemo, redémarrez l'exécuteur et confirmez qu'il rappelle cette progression à l'aide du même XMEMO_AGENT_INSTANCE_ID. Si l'attribution change ou si les rappels se scindent entre instances, conservez XMEMO_AGENT_INSTANCE_ID hors de git et vérifiez que l'exécuteur ne le régénère pas à chaque démarrage.