1. Capture verbatim
Un message, document, ticket ou artefact est d'abord archivé tel qu'il existe, avec source, temps, surface et provenance. La capture doit réussir avant toute synthèse.
Cycle mémoire
La mémoire d'Elora n'est pas un simple historique de chat. Elle sépare capture brute, mémoire canonique, mémoire opérationnelle, mémoire relationnelle, retrieval et propositions d'apprentissage.
Ordre dur d'ingestion
2. Archive ou spool
Si PostgreSQL est disponible, l'objet va dans l'archive locale. S'il est indisponible, Elora écrit dans un spool local append-only pour rejouer plus tard.
3. Découpage et indexation
Les contenus longs sont chunkés. Les embeddings locaux via Ollama améliorent le rappel sémantique, mais le texte original reste conservé.
4. Candidats mémoire
Elora peut proposer des entries canoniques: fait, préférence, décision, contrainte, événement, hypothèse, pattern ou expression. Une proposition n'est pas encore vérité durable.
5. Canonicalisation
Les entrées maintenues reçoivent canonical_text, embedding_text, truth_mode, scope, confiance, temporalité, sources et liens de provenance.
6. Contradictions
Une nouvelle information ne détruit pas l'ancienne. Elle peut la confirmer, la contredire, la remplacer, la déprécier ou la limiter dans le temps.
7. Export miroir
À la demande, Elora génère un snapshot Markdown privé: README canonique, index, manifest JSON et fichiers par entrée. Ce miroir sert à lire, auditer, exporter ou alimenter des outils.
Quand la mémoire intervient dans une réponse
- La surface reçoit une demande: terminal, cockpit, Telegram ou futur avatar.
- Elora classe la demande et décide si le contexte mémoire est nécessaire.
- Le retrieval récupère d'abord les `memory.entries` maintenues, puis les archive.chunks comme preuves secondaires.
- Le contexte est assemblé en evidence pack limité: faits utiles, sources, dates, confiance, contradictions et limites.
- Le provider local ou le worker reçoit ce pack, pas toute la base mémoire, puis fait une inférence bornée par ce contexte.
- La réponse doit respecter les preuves injectées ou marquer explicitement l'incertitude.
- Après exécution, les logs, scores, feedbacks et propositions d'apprentissage restent inspectables avant promotion.
- Quand une revue humaine ou un outil externe en a besoin, `elora-memory export-markdown` crée un snapshot lisible sans modifier PostgreSQL.
Les quatre couches de rappel
Ces couches sont maintenant exposées dans le contrat JSON d'elora-context. Elles ne sont pas un simple concept rédactionnel: elles permettent de voir ce qu'Elora sait localement, ce qu'elle infère du routage, ce qui manque, et quand une clarification ou une recherche profonde est nécessaire.
L0 identity wake-up
État minuscule toujours disponible: identité opérateur, mission, persona active, priorités, préférences stables.
L1 operational essentials
Faits et contraintes durables, projets en cours, définitions stables, open loops et préférences importantes.
L2 focused topic recall
Rappel ciblé pour un projet, une personne, un incident, un repo, une mission ou un sujet précis.
L3 deep search
Recherche plus coûteuse: sémantique large, lexical, graphe, temps, contradictions et preuves faibles.
Fallback mémoire
Le premier système historique était plus file-backed. Memory V2 garde la leçon de simplicité, mais ne garde pas un deuxième canon caché: la vérité durable vit dans PostgreSQL. Le fallback sert à ne pas perdre une capture ou une entrée quand la base n'est pas joignable.
- Le spool est local, append-only, inspectable et rejouable.
- Une écriture spoulée n'est pas considérée comme durable tant qu'elle n'est pas rejouée dans PostgreSQL.
- Si les embeddings tombent, Elora peut dégrader vers lexical, temps et provenance.
- Le fallback doit être visible dans les diagnostics; il ne doit pas masquer une panne de mémoire canonique.
Miroir Markdown
Le miroir Markdown répond à un besoin différent du fallback. Le fallback protège une capture quand PostgreSQL est indisponible. Le miroir Markdown expose une photographie lisible de ce qui est déjà dans PostgreSQL.
- Il est généré sous forme de snapshot privé, hors site public et hors dépôt par défaut.
- Il contient un README, un index, un manifest JSON et des fichiers par entrée classés par scope, type et statut.
- Chaque fichier sépare canonical_text, embedding_text, classification, provenance, evidence et métadonnées.
- Il peut alimenter une relecture humaine, un modèle local, un outil de curation ou une sauvegarde orientée audit.
- Une correction dans Markdown doit devenir une proposition explicite avant de modifier PostgreSQL.