Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id : ADR-010 titre : Séparer l’historique des conversations, la mémoire curée et l’autorité d’enrichissement date : 2026-07-19 statut : proposé relates-to :

  • ADR-005
  • docs/book/src/foundations/fnd-002-documentation-standards.md
  • docs/book/src/architecture/memory-payload-lifecycle.md
  • https://github.com/zeroclaw-labs/zeroclaw/issues/9048
  • https://github.com/zeroclaw-labs/zeroclaw/issues/9103
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6850
  • https://github.com/zeroclaw-labs/zeroclaw/pull/9072
  • crates/zeroclaw-api/src/memory_traits.rs
  • crates/zeroclaw-memory
  • crates/zeroclaw-infra/src/session_backend.rs
  • crates/zeroclaw-infra/src/session_store.rs
  • crates/zeroclaw-infra/src/acp_session_store.rs

ADR-010 : Séparer l’historique des conversations, la mémoire organisée et l’autorité d’enrichissement

Contexte

ADR-005 définit un contrat de mémoire durable indépendant du backend, avec SQLite par défaut. Il ne détermine pas quelles données mémorisées relèvent de la mémoire durable ni si une intégration de mémoire externe constitue un autre magasin de référence.

Les chemins actuels du runtime, de la passerelle et des canaux peuvent conserver les tours de conversation à la fois dans les magasins de session et sous forme d’entrées MemoryCategory::Conversation. Cela attribue à une même transcription deux propriétaires possibles, avec des comportements différents en matière de rétention, de rappel, d’export, de suppression et de portée. Une ancienne ligne de conversation peut aussi réintégrer une invite ultérieure comme s’il s’agissait de connaissances inter-sessions organisées.

Les intégrations externes créent un risque de double autorité. Un connecteur peut améliorer la recherche ou fournir du contexte dérivé, mais traiter son index comme un autre stockage durable permet à l’état du connecteur, aux pannes ou à une portée plus faible de concurrencer les données canoniques de ZeroClaw.

RFC acceptées #9048 et #9103 résolvent ces questions ensemble. Cet enregistrement étend ADR-005 sans le réécrire : le contrat Memory neutre vis-à-vis du backend et la valeur par défaut SQLite restent valides, tandis que cet ADR attribue séparément l’autorité à l’historique de session, à la mémoire curée et à l’enrichissement.

Décision

L’historique des conversations garantit la continuité

Le magasin de sessions de chat, de canal, de passerelle ou ACP applicable fait autorité pour la continuité des conversations. La persistance automatique des transcriptions appartient à ce magasin de sessions et préserve la structure des messages nécessaire à une reprise sécurisée, y compris l’appariement des appels d’outils et des résultats d’outils lorsque cela est pris en charge.

L’historique de session préserve chaque limite de session, d’agent, de locataire et de principal applicable. Il ne constitue pas automatiquement une connaissance inter-sessions. La réduction de l’historique modifie le contexte visible par la session et par le fournisseur ; la suppression de la mémoire organisée ne supprime pas l’historique de session.

Lorsque la saisie actuelle ou l’historique de session entre en conflit avec la mémoire organisée, la saisie actuelle et l’historique de session régissent le tour en cours. La mémoire organisée ne doit pas réécrire, remplacer ou supplanter cet enregistrement de continuité.

La mémoire organisée conserve les connaissances sélectionnées entre les sessions.

La mémoire à long terme organisée par l’agent contient des faits, des préférences, des décisions, des conventions et des procédures apprises qui sont intentionnellement conservés d’une session à l’autre. Les écritures doivent être délibérées ou produites par une politique de consolidation bornée explicite, préserver une provenance utile et conserver chaque limite applicable d’agent, de session, de locataire et de principal.

La mémoire organisée utilise le contrat Memory, indépendant du backend, défini par ADR-005. Un backend configuré constitue le magasin durable faisant autorité pour cette mémoire. L’assemblage des prompts, la consolidation, la gouvernance et les retours restent des préoccupations de politique de cycle de vie au-dessus de l’implémentation du stockage ; le ticket #6850 suit cette limite.

Cet ADR ne détermine pas si le Markdown par agent constitue la représentation canonique de la mémoire curée visible par l’opérateur ou une projection d’un autre backend configuré. Cela demeure une décision d’implémentation distincte ; aucune seconde autorité durable ne peut être introduite de manière implicite.

Les sessions ACP/Code, y compris le volet ACP de ZeroCode, restent isolées de l’injection automatique de mémoire à long terme. Les bundles de connaissances et la génération augmentée par récupération sont des sources de contexte délibérées distinctes ; ils ne réactivent pas la mémoire organisée pour ces sessions Code.

L’enrichissement est un dérivé reconstructible

Un MemoryEnricher est un dérivé optionnel, au mieux, du magasin de mémoire curée faisant autorité, et non une autre source de vérité. Le magasin faisant autorité valide en premier. Une défaillance du connecteur, un dépassement de délai, une sortie mal formée ou un état obsolète ne peuvent pas invalider une écriture réussie faisant autorité ni rendre indisponible la récupération depuis le magasin faisant autorité.

La limite d’enrichissement partagée est responsable de la politique indépendante du connecteur : capacités déclarées, portée de l’appelant et de l’agent, comportement de défaillance borné, ordre de fusion déterministe et toute réhydratation de ligne canonique nécessaire pour rejeter les résultats obsolètes, remplacés ou provenant d’un mauvais agent. Le contexte dérivé du connecteur est isolé comme non fiable avant de devenir visible pour le modèle.

Les nouvelles écritures automatiques de transcriptions ne doivent pas être transmises à un connecteur d’enrichissement. La politique de migration doit définir explicitement tout traitement, côté connecteur, des anciennes lignes MemoryCategory::Conversation, empêcher que leurs dérivés soient récupérés en tant que mémoire sélectionnée et fournir des consignes de nettoyage ou de reconstruction. Un futur index de l’historique des sessions nécessite sa propre décision explicite concernant l’autorité, la confidentialité, la conservation et le périmètre ; il ne peut pas être introduit implicitement via le point d’intégration de la mémoire sélectionnée.

La première implémentation peut rester spécifique à SQLite. La généralisation de l’enrichissement sur d’autres stockages durables attend l’apparition d’un second consommateur concret plutôt que de contraindre chaque backend à adopter les hypothèses d’un seul connecteur.

Les lignes de conversation héritées nécessitent une transition explicite

Les données existantes de MemoryCategory::Conversation constituent un état de compatibilité, et non la future source de vérité pour les transcriptions. La migration doit permettre un retour en arrière et éviter toute suppression silencieuse. Les implémentations peuvent conserver les lectures de compatibilité, migrer les tours récupérables vers le magasin de sessions approprié, promouvoir délibérément certains faits durables sélectionnés vers la mémoire organisée, ou laisser expirer les lignes conformément à des règles de rétention documentées.

Aucune implémentation ne peut traiter la promotion en masse des transcriptions vers la mémoire organisée comme comportement par défaut. La promotion est une décision bornée et consciente de la provenance, et non une conversion de format de stockage.

Critères d’acceptation

Cet ADR reste proposé jusqu’à ce que toutes ces conditions soient remplies :

  • les nouvelles écritures automatiques de transcription utilisent des magasins de sessions canoniques sur les chemins d’exécution, de passerelle, de canal et ACP couverts ;
  • la mémoire organisée ne peut pas remplacer une entrée actuelle ou un historique de session en conflit, et l’isolation de la mémoire automatique ACP/Code reste appliquée ;
  • la jonction authoritative-store/enricher est active avec des écritures authoritative-first, un rappel à portée et contrôlé par capacités, un cloisonnement des contextes non fiables et un repli en cas d’échec ;
  • les nouvelles écritures de transcription automatique sont exclues des connecteurs d’enrichissement ; et
  • La compatibilité et le comportement de migration pour les lignes de conversation héritées, notamment le rappel de connecteur sûr par catégorie ainsi que le comportement de nettoyage ou de reconstruction, sont documentés et couverts par des tests compatibles avec la restauration.

Conséquences

Conséquences positives :

  • La reprise de conversation, la rétention des transcriptions et la suppression des transcriptions ont un seul propriétaire canonique.
  • La mémoire organisée peut évoluer sans devenir un second système d’historique de session.
  • L’enrichissement externe peut améliorer le rappel sans retirer l’autorité durable du backend de mémoire configuré.
  • Les pannes de connecteur et les protocoles de connecteur moins robustes basculent en repli vers les données faisant autorité à portée limitée.
  • Les sessions ACP/Code conservent leur protection existante contre la dérive de mémoire, y compris le volet ACP de ZeroCode.

Conséquences négatives :

  • Les chemins d’enregistrement automatique des transcriptions existantes et les lignes de conversation héritées nécessitent un travail de compatibilité et de migration progressif.
  • Les magasins de session doivent fournir suffisamment de fidélité et de couverture avant que les écritures de transcription puissent quitter la mémoire générale.
  • Les adaptateurs d’enrichissement ne peuvent pas recevoir chaque écriture Memory de manière indiscriminée ; le wrapper partagé doit appliquer les limites de catégorie et de portée.
  • Les opérateurs peuvent temporairement voir à la fois les anciennes lignes de conversation et l’historique de session canonique tant que la migration est active.

Références