[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fKpLIs51CCqYkEV4x-M5EYTMhlTGpwzoG0L8VXChgAZA":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":23},{"chapter":4,"prev":13,"next":18},{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10,"contentHtml":11,"contentHtmlEn":12},"memory","08","Mémoire & apprentissage — architecture à trois niveaux","Memory & Learning — Three-Level Architecture","Ce chapitre décrit les trois niveaux de mémoire du harness Synedre OS (réflexe, Zettelkasten, vectoriel pgvector), les automates d'indexation associés et la boucle de capitalisation des erreurs en règles réutilisables.","This chapter describes the three memory levels of the Synedre OS harness (reflex, Zettelkasten, vector pgvector), the associated indexing automata, and the loop for capitalizing errors into reusable rules.","\u003Ch2 id=\"memoire-apprentissage\">Mémoire & apprentissage du harness agentique\u003C\u002Fh2>\n\n\u003Cp>Cette page décrit comment le harness agentique \u003Cstrong>se souvient\u003C\u002Fstrong> (mémoire à trois niveaux), \u003Cstrong>retrouve l'information pertinente\u003C\u002Fstrong> (rappel sémantique par similarité vectorielle) et \u003Cstrong>capitalise ses erreurs et succès\u003C\u002Fstrong> en règles réutilisables (boucle cicatrices → apprentissage → leçons).\u003C\u002Fp>\n\n\u003Ch2 id=\"memoire-trois-niveaux\">1. Mémoire à trois niveaux\u003C\u002Fh2>\n\n\u003Cp>Le système distingue trois mémoires de granularité et de discipline d'écriture croissantes.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>┌─────────────────────────────────────────────────────────────────┐\n│ NIVEAU 1 — Mémoire réflexe                                      │\n│   Chargée dans CHAQUE session. Règles dures, feedbacks,         │\n│   références. Stricte, une entrée par ligne dans l'index.       │\n├─────────────────────────────────────────────────────────────────┤\n│ NIVEAU 2 — Base de connaissance (Zettelkasten)                  │\n│   Le « pourquoi » : décisions, doctrine, concepts. Exploratoire.│\n│   Zone brouillon = dépôt libre ; zone consolidée = validation   │\n│   humaine obligatoire.                                          │\n├─────────────────────────────────────────────────────────────────┤\n│ NIVEAU 3 — Index sémantique vectoriel                           │\n│   Index vectoriel HNSW (similarité cosinus, 1024 dimensions)    │\n│   couvrant l'ensemble des deux niveaux précédents + tables DB.  │\n│   Permet le rappel RAG (Retrieval-Augmented Generation).        │\n└─────────────────────────────────────────────────────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3>Niveau 1 — Mémoire réflexe\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Un \u003Cstrong>fichier index\u003C\u002Fstrong> liste toutes les entrées actives (une ligne par entrée, ≤ 200 caractères chacune).\u003C\u002Fli>\n  \u003Cli>Les détails vivent dans des fichiers thématiques : retours d'expérience, préférences utilisateur, références de projet.\u003C\u002Fli>\n  \u003Cli>Ces fichiers sont \u003Cstrong>injectés automatiquement dans le contexte de chaque session\u003C\u002Fstrong> : aucun rappel explicite n'est nécessaire. Seules les vraies doctrines à fort impact y figurent — la discipline de saisie est stricte.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Niveau 2 — Base de connaissance Zettelkasten\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Organisée en sous-espaces distincts : notes permanentes (consolidées), boîte de réception (brouillons), tables des matières, journaux quotidiens, notes éphémères.\u003C\u002Fli>\n  \u003Cli>Les notes s'inter-référencent par des liens wiki ; un frontmatter YAML indique le type et le statut de chaque note.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Règle de promotion :\u003C\u002Fstrong> la boîte de réception est la seule zone où l'agent écrit librement. La zone permanente n'est jamais modifiée sans ordre explicite d'un opérateur humain. Aucune fusion automatique entre les deux zones n'est autorisée — c'est un garde-fou architectural.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Niveau 3 — Index sémantique vectoriel\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Les vecteurs sont de dimension \u003Cstrong>1024\u003C\u002Fstrong>, produits par un modèle d'embedding dédié.\u003C\u002Fli>\n  \u003Cli>L'index utilise la structure \u003Cstrong>HNSW\u003C\u002Fstrong> (Hierarchical Navigable Small World) avec la similarité cosinus, ce qui garantit des recherches approximatives très rapides même sur des corpus volumineux.\u003C\u002Fli>\n  \u003Cli>Une contrainte d'unicité par paire \u003Cem>(type de source, identifiant de source)\u003C\u002Fem> évite les doublons lors des mises à jour.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"indexation\">2. Indexation\u003C\u002Fh2>\n\n\u003Cp>Deux automates distincts alimentent les niveaux 2 et 3. Il est important de ne pas les confondre : le premier alimente un \u003Cstrong>index structurel\u003C\u002Fstrong> de la base de connaissance (utilisé par les interfaces et la recherche par critères) ; le second alimente l'\u003Cstrong>index vectoriel sémantique\u003C\u002Fstrong> (utilisé pour le rappel RAG).\u003C\u002Fp>\n\n\u003Ch3>2.1 Automate d'indexation structurelle de la base de connaissance\u003C\u002Fh3>\n\n\u003Cp>Cet automate parcourt l'ensemble des sous-espaces de la base de connaissance et maintient une représentation structurée de chaque note dans la base de données relationnelle.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Périmètre :\u003C\u002Fstrong> notes permanentes, boîte de réception, tables des matières, journaux quotidiens, notes éphémères.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Traitement :\u003C\u002Fstrong> extraction du frontmatter YAML et des liens inter-notes de chaque fichier.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Synchronisation incrémentale :\u003C\u002Fstrong> comparaison de la date de modification du fichier avec la valeur en base ; seules les notes modifiées sont recalculées. Les notes supprimées sont retirées de l'index.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Données conservées par note :\u003C\u002Fstrong> chemin relatif, type, titre, tags, frontmatter complet, corps, liens sortants, taille, horodatages.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Options :\u003C\u002Fstrong> mode \u003Cem>force\u003C\u002Fem> (réindexation complète) et mode \u003Cem>stats\u003C\u002Fem> (comptage sans écriture).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Cadence :\u003C\u002Fstrong> toutes les 15 minutes. L'opération est idempotente.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>2.2 Automate d'embedding et de synchronisation vectorielle\u003C\u002Fh3>\n\n\u003Cp>Cet automate produit les vecteurs sémantiques de l'ensemble des sources et les insère dans l'index vectoriel. Il utilise un modèle d'embedding externe (1024 dimensions).\u003C\u002Fp>\n\n\u003Cp>Les \u003Cstrong>sources indexées\u003C\u002Fstrong> et leur volume indicatif sont :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Type de source\u003C\u002Fth>\n      \u003Cth>Origine\u003C\u002Fth>\n      \u003Cth>Volume indicatif\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Cicatrices\u003C\u002Ftd>\n      \u003Ctd>Erreurs enregistrées par le moteur de réflexes (toutes entrées avec description)\u003C\u002Ftd>\n      \u003Ctd>~740\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Victoires\u003C\u002Ftd>\n      \u003Ctd>Succès enregistrés par le moteur de réflexes\u003C\u002Ftd>\n      \u003Ctd>~4\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Mémoire réflexe\u003C\u002Ftd>\n      \u003Ctd>Fichiers de la mémoire de niveau 1 (hors index principal)\u003C\u002Ftd>\n      \u003Ctd>~226\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Base de connaissance\u003C\u002Ftd>\n      \u003Ctd>Notes des différents sous-espaces Zettelkasten\u003C\u002Ftd>\n      \u003Ctd>~14\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Doctrines\u003C\u002Ftd>\n      \u003Ctd>Règles doctrinales actives\u003C\u002Ftd>\n      \u003Ctd>~25\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Chantiers\u003C\u002Ftd>\n      \u003Ctd>Projets en cours\u003C\u002Ftd>\n      \u003Ctd>~10\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Agents\u003C\u002Ftd>\n      \u003Ctd>Descripteurs d'agents\u003C\u002Ftd>\n      \u003Ctd>~30\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Exercices (drills)\u003C\u002Ftd>\n      \u003Ctd>Scénarios d'entraînement\u003C\u002Ftd>\n      \u003Ctd>~31\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Conduites\u003C\u002Ftd>\n      \u003Ctd>Procédures opérationnelles actives\u003C\u002Ftd>\n      \u003Ctd>~17\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Itérations ReAct\u003C\u002Ftd>\n      \u003Ctd>Triplets raisonnement \u002F action \u002F observation des boucles agentiques\u003C\u002Ftd>\n      \u003Ctd>~16\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>\u003Cstrong>Mécanismes clés de l'automate :\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Déduplication par empreinte :\u003C\u002Fstrong> chaque chunk reçoit une empreinte SHA-256 de son contenu. Si la paire \u003Cem>(type, identifiant)\u003C\u002Fem> existe déjà avec la même empreinte, le chunk est ignoré — aucun appel au service d'embedding n'est effectué.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Chunking :\u003C\u002Fstrong> dans la version actuelle, chaque document constitue un chunk unique, tronqué au-delà d'un seuil de caractères. Un découpage plus fin est prévu en phase ultérieure.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Traitement par lots :\u003C\u002Fstrong> les appels au service d'embedding regroupent 50 inputs par requête afin de limiter la latence réseau.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Insertion :\u003C\u002Fstrong> chaque vecteur est inséré ou mis à jour atomiquement selon la contrainte d'unicité \u003Cem>(type, identifiant)\u003C\u002Fem>.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Options :\u003C\u002Fstrong> mode \u003Cem>rebuild\u003C\u002Fem> (purge complète puis réembedding total), filtre par type de source, mode \u003Cem>dry-run\u003C\u002Fem> (simulation sans écriture).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>2.3 Réindexation immédiate d'une cicatrice\u003C\u002Fh3>\n\n\u003Cp>Lorsqu'une cicatrice est gravée \u003Cem>pendant\u003C\u002Fem> une boucle agentique active (cycle ReAct), une procédure de réindexation unitaire est déclenchée \u003Cstrong>immédiatement\u003C\u002Fstrong> : la cicatrice devient searchable dans le RAG sans attendre la synchronisation nocturne suivante. Ce mécanisme garantit que l'agent peut bénéficier d'une leçon apprise quelques secondes après l'avoir enregistrée, y compris au sein du même run.\u003C\u002Fp>\n\n\u003Ch3>2.4 Cadences de maintenance\u003C\u002Fh3>\n\n\u003Cp>Les différents automates de mémoire s'exécutent selon les plannings suivants :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Indexation structurelle de la base de connaissance :\u003C\u002Fstrong> toutes les 15 minutes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Synchronisation vectorielle complète (incrémentale) :\u003C\u002Fstrong> quotidienne, tôt le matin. La réindexation unitaire des cicatrices (§ 2.3) reste active en parallèle pour l'immédiateté.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Boucle de consolidation nocturne :\u003C\u002Fstrong> nuit, peu après minuit — propose des synthèses de la boîte de réception vers la zone permanente (validation humaine requise).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Détecteur de patterns :\u003C\u002Fstrong> hebdomadaire (dimanche).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Détecteur de propositions de compétences :\u003C\u002Fstrong> hebdomadaire (dimanche) et surveillance horaire.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Métriques mémoire :\u003C\u002Fstrong> quotidien, matin.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Consolidation mensuelle :\u003C\u002Fstrong> 1\u003Csup>er\u003C\u002Fsup> du mois.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Cadran de maintenance :\u003C\u002Fstrong> quotidien, tôt le matin.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note architecturale :\u003C\u002Fstrong> aucun de ces automates ne modifie la zone permanente de la base de connaissance sans validation humaine explicite. L'ensemble du pipeline est conçu pour être idempotent : une exécution supplémentaire ne produit pas d'effet de bord indésirable.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"recall-rag\">Recall RAG\u003C\u002Fh2>\n\n\u003Cp>Le moteur de rappel sémantique permet d'interroger la mémoire indexée du système via une requête en langage naturel. Il opère selon trois modes de recherche complémentaires, fusionnés par défaut en un mode hybride.\u003C\u002Fp>\n\n\u003Ch3>Flux de traitement\u003C\u002Fh3>\n\n\u003Cp>La requête entrante est traitée selon le mode sélectionné :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Mode sémantique\u003C\u002Fstrong> : la requête est vectorisée par le modèle d'embedding (vecteurs 1024 dimensions), puis comparée à l'index par distance cosine. Les résultats sont triés par similarité décroissante.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Mode lexical\u003C\u002Fstrong> : les mots de trois caractères ou plus sont extraits et combinés en une requête OR. La correspondance est calculée par score de rang textuel sur le contenu indexé en français. Ce mode ne fait appel à aucune API externe — aucune clé n'est requise. Il rattrape efficacement les slugs et noms propres que l'embedding tend à flouter.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Mode hybride (défaut)\u003C\u002Fstrong> : les deux classements précédents sont fusionnés par \u003Cem>Reciprocal Rank Fusion\u003C\u002Fem> (RRF, paramètre k=60). Le score combiné est \u003Ccode>score = Σ 1\u002F(60 + rang_i)\u003C\u002Fcode>. Un document absent d'un des deux modes reçoit un score nul pour ce mode, sans pénaliser l'autre.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Un filtre de périmètre (\u003Cem>scope\u003C\u002Fem>) commun aux trois modes permet de restreindre la recherche à certaines catégories de sources : historique d'itérations, cicatrices, victoires, mémoire de référence, doctrine, chantiers en cours, profils d'agents, protocoles, ou la totalité des sources.\u003C\u002Fp>\n\n\u003Ch3>Re-classement par importance et récence\u003C\u002Fh3>\n\n\u003Cp>Après la première sélection, un sur-fetch (par défaut trois fois le nombre de résultats demandés) permet un re-classement enrichi, appliqué aux cicatrices uniquement. La formule est :\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>score_final = similarité × (1 + importance\u002F10) × exp(−âge_jours \u002F 365)\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>Effet concret : une cicatrice récente de haute importance est boostée d'un facteur ~2×, tandis qu'une cicatrice ancienne de faible importance voit son score réduit à ~0,4×. Ce mécanisme garantit que les apprentissages frais et critiques remontent en tête.\u003C\u002Fp>\n\n\u003Ch3>Anti-oubli : incrémentation du compteur de rappel\u003C\u002Fh3>\n\n\u003Cp>Chaque cicatrice effectivement servie voit son compteur de rappel incrémenté de 1 et sa date de dernier rappel mise à jour. Cette opération est non bloquante : une erreur éventuelle est silencieuse et ne perturbe pas la réponse. Le système de cron d'archivage ne purge que les cicatrices dont le compteur de rappel est resté à zéro — celles qui ont été rappelées au moins une fois sont préservées.\u003C\u002Fp>\n\n\u003Ch3>Interprétation des scores\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>En mode \u003Cstrong>sémantique\u003C\u002Fstrong> : score > 0,75 → très pertinent ; 0,65–0,75 → pertinent ; < 0,65 → à valider manuellement.\u003C\u002Fli>\n  \u003Cli>En mode \u003Cstrong>hybride\u003C\u002Fstrong> (défaut) : les scores RRF sont sur une échelle différente (typiquement < 0,1). Se fier au \u003Cem>rang relatif\u003C\u002Fem>, pas aux seuils absolus.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Options de la commande de rappel\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Ccode>--k\u003C\u002Fcode> : nombre de résultats à retourner.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--mode lex|sem|hybrid\u003C\u002Fcode> : mode de recherche (défaut : \u003Ccode>hybrid\u003C\u002Fcode>).\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--scope\u003C\u002Fcode> : périmètre de sources à interroger.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--json\u003C\u002Fcode> : sortie machine au format JSON.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Déclenchement automatique avant création\u003C\u002Fh3>\n\n\u003Cp>Un déclencheur automatique s'active avant toute création de nouveau chantier. Il extrait le titre de la tâche et lance une recherche hybride sur les quatre résultats les plus proches. En cas d'indisponibilité de l'API d'embedding (limite de débit atteinte), le mode lexical prend le relais. Les résultats sont injectés dans le flux de diagnostic \u003Cem>avant\u003C\u002Fem> la création, de façon non bloquante. L'objectif est d'éviter de réinventer une cicatrice, une doctrine ou un chantier déjà connu — la recherche sémantique rattrape les entrées que l'index linéaire de mémoire manquait.\u003C\u002Fp>\n\n\u003Ch2 id=\"harness-evaluation-recall\">Harness d'évaluation du recall\u003C\u002Fh2>\n\n\u003Cp>Le système de non-régression du recall repose sur un harness d'évaluation automatisé. Il charge un \u003Cem>golden dataset\u003C\u002Fem> — un ensemble de requêtes associées aux identifiants de sources attendus, effectivement présents dans l'index vectoriel — et mesure la qualité de la recherche sans jamais muter les compteurs de rappel (mode lecture seule strict).\u003C\u002Fp>\n\n\u003Ch3>Métriques calculées\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Métrique\u003C\u002Fth>\n      \u003Cth>Définition\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>recall@k\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fraction des sources attendues retrouvées dans le top-k, moyennée sur l'ensemble des requêtes.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>mrr@10\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Inverse du rang du premier résultat pertinent dans le top-10 (0 si absent), moyenné sur les requêtes.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>top1_accuracy\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fraction des requêtes pour lesquelles le premier résultat correspond à une source attendue.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>La correspondance entre un résultat retourné et une source attendue est évaluée par inclusion de sous-chaîne (insensible à la casse), ce qui la rend robuste aux variations de préfixes de chemin et de formats d'identifiants.\u003C\u002Fp>\n\n\u003Ch3>Gestion du débit API\u003C\u002Fh3>\n\n\u003Cp>Pour les modes faisant appel à l'API d'embedding, un délai de temporisation de 1,3 secondes est introduit entre chaque appel. En cas de réponse de limitation de débit (HTTP 429), un backoff exponentiel est appliqué jusqu'à cinq tentatives. Le mode lexical seul ne sollicite aucune API et ne requiert aucun délai.\u003C\u002Fp>\n\n\u003Ch3>Commandes et codes de sortie\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Mode \u002F option\u003C\u002Fth>\n      \u003Cth>Effet\u003C\u002Fth>\n      \u003Cth>Code de sortie\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(aucune option)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Mode gate : compare les métriques courantes au baseline figé. Échoue si la régression dépasse la tolérance.\u003C\u002Ftd>\n      \u003Ctd>0 (succès) \u002F 1 (régression)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--baseline\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fige un nouveau baseline en lançant l'évaluation en mode hybride.\u003C\u002Ftd>\n      \u003Ctd>0\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--mode-sweep\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Compare les trois modes (lexical, sémantique, hybride) à titre informatif, sans gate.\u003C\u002Ftd>\n      \u003Ctd>0\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--tol <valeur>\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Tolérance de régression acceptable (défaut : 0,05).\u003C\u002Ftd>\n      \u003Ctd>—\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--json\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Sortie au format machine.\u003C\u002Ftd>\n      \u003Ctd>—\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(baseline absent)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Avertissement : aucun baseline de référence trouvé.\u003C\u002Ftd>\n      \u003Ctd>2\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note opérationnelle\u003C\u002Fstrong> : le harness d'évaluation ne modifie jamais l'état de la base de données. Il est conçu pour s'exécuter en intégration continue sans effet de bord sur les compteurs anti-oubli ni sur les métadonnées des cicatrices indexées.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"boucle-apprentissage\">Boucle d'apprentissage : erreurs, vérifications, suggestions et leçons\u003C\u002Fh2>\n\n\u003Cp>C'est le cœur de la capitalisation. Une erreur (ou un succès) devient une donnée, puis une suggestion concrète, puis — après validation humaine — une règle chargée dans toutes les sessions futures.\u003C\u002Fp>\n\n\u003Cp>Le flux général se déroule en quatre temps :\u003C\u002Fp>\n\u003Col>\n  \u003Cli>Une tâche résolue (ou un pattern reproductible) est enregistrée dans le \u003Cstrong>registre des leçons\u003C\u002Fstrong>.\u003C\u002Fli>\n  \u003Cli>Un moteur de suggestion lit les entrées marquées comme apprises et produit une proposition structurée.\u003C\u002Fli>\n  \u003Cli>Un opérateur humain valide, refuse ou modifie chaque proposition depuis le tableau de bord.\u003C\u002Fli>\n  \u003Cli>La règle validée est appliquée dans la destination appropriée et devient active dès la session suivante.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>4.1 Le registre des leçons\u003C\u002Fh3>\n\n\u003Cp>Le registre des leçons est la \u003Cstrong>source unique de vérité\u003C\u002Fstrong> pour toute la capitalisation. Chaque entrée documente soit un échec résolu, soit un succès reproductible. Les champs clés sont :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Le type d'entrée\u003C\u002Fstrong> (\u003Ccode>kind\u003C\u002Fcode>) : distingue les échecs, les succès et quelques catégories historiques (convention, pattern, bug). La grande majorité des entrées sont des échecs résolus.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>La leçon\u003C\u002Fstrong> (\u003Ccode>check_added\u003C\u002Fcode>) : pour un échec, ce qu'on a ajouté pour ne pas recommencer ; pour un succès, le pattern à reproduire.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Le score d'importance\u003C\u002Fstrong> : calculé automatiquement par un modèle de langage au moment de l'enregistrement, via le moteur de routage IA. Non bloquant — si le modèle est indisponible, le score est renseigné lors de la prochaine maintenance nocturne. L'importance pondère la fréquence de rappel (un bonus est accordé aux entrées les plus critiques).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>L'indicateur d'apprentissage\u003C\u002Fstrong> (\u003Ccode>learnable\u003C\u002Fcode>) : porte d'entrée du moteur de suggestion. Seules les entrées marquées \u003Ccode>true\u003C\u002Fcode> sont traitées.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Bonne pratique — graver un succès :\u003C\u002Fstrong> passer par la skill dédiée (\u003Ccode>\u002Fvictoire\u003C\u002Fcode>) plutôt que par du SQL direct. Le champ \u003Ccode>tags\u003C\u002Fcode> doit être fourni au format tableau PostgreSQL littéral (\u003Ccode>\"{a,b,c}\"\u003C\u002Fcode>), pas une liste Python — une leçon apprise en production.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.2 Le moteur de suggestion : de la leçon à la proposition\u003C\u002Fh3>\n\n\u003Cp>Le moteur de suggestion lit le registre des leçons, filtre les entrées marquées comme apprenables et non encore traitées, puis appelle un modèle de langage pour produire une proposition structurée. Le pipeline en détail :\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Sélection\u003C\u002Fstrong> : les entrées apprenables absentes du journal de propositions, triées par importance décroissante puis par date, dans la limite de 50 par exécution.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Purge des données personnelles\u003C\u002Fstrong> avant envoi au modèle. L'output du modèle est également filtré avant insertion — défense en profondeur.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Appel LLM\u003C\u002Fstrong> : le modèle retourne un objet JSON contenant la destination cible, le texte de la suggestion, et les différences avant\u002Faprès (\u003Cem>diff_before\u003C\u002Fem> \u002F \u003Cem>diff_after\u003C\u002Fem>).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Insertion\u003C\u002Fstrong> dans le journal de propositions avec le statut \u003Ccode>pending\u003C\u002Fcode>. L'opération est idempotente ; un délai court entre chaque appel évite de saturer l'API.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>Les \u003Cstrong>six destinations possibles\u003C\u002Fstrong> pour une proposition :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Destination\u003C\u002Fth>\n      \u003Cth>Sens\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Directive orchestrateur\u003C\u002Ftd>\n      \u003Ctd>Règle à ajouter ou modifier dans le fichier de directives principal de l'agent\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Configuration hooks\u003C\u002Ftd>\n      \u003Ctd>Paramètre de permissions, hooks ou variables d'environnement\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Note persistante (niveau 1)\u003C\u002Ftd>\n      \u003Ctd>Réflexe immédiat injecté dans chaque briefing via la mémoire courante\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Boîte de réception conceptuelle\u003C\u002Ftd>\n      \u003Ctd>Nouvelle note Zettelkasten (concept ou doctrine à maturation)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Skill\u003C\u002Ftd>\n      \u003Ctd>Création ou amélioration d'une skill invocable\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Chantier ou outil\u003C\u002Ftd>\n      \u003Ctd>Nouveau chantier automatisé ou script utilitaire\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>4.3 Validation humaine et journal d'audit\u003C\u002Fh3>\n\n\u003Cp>Aucune proposition n'est appliquée automatiquement. Le tableau de bord expose trois opérations :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Consulter le flux\u003C\u002Fstrong> (lecture) : liste des propositions en attente.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Appliquer\u003C\u002Fstrong> (écriture) : la proposition passe au statut \u003Ccode>applied\u003C\u002Fcode> et une entrée est créée dans le journal d'audit avec l'identifiant de l'opérateur et un instantané du diff.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Refuser ou modifier\u003C\u002Fstrong> (écriture) : la proposition passe au statut \u003Ccode>refused\u003C\u002Fcode> ou \u003Ccode>modified\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Le journal d'audit conserve pour chaque action : la référence à la proposition, l'auteur de la décision, l'horodatage et l'instantané du diff appliqué.\u003C\u002Fp>\n\n\u003Ch3>4.4 Leçons post-chantier (bilan structuré)\u003C\u002Fh3>\n\n\u003Cp>En complément de la boucle cicatrices → suggestions, un outil de bilan post-chantier permet d'extraire des leçons après la clôture d'un chantier. Il est invocable par un agent dédié via la skill correspondante.\u003C\u002Fp>\n\n\u003Cp>Le mécanisme charge un bundle d'audit complet : métadonnées du chantier, travaux, tâches, itérations récentes, cicatrices liées et journaux d'exécution tronqués. Le volume d'entrée est plafonné pour rester sous les limites du modèle.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Garde-fou ROI\u003C\u002Fstrong> : un chantier comptant moins de trois travaux est refusé par défaut (contournable via un flag explicite).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Modèle par défaut\u003C\u002Fstrong> : l'appel LLM passe par le binaire Claude via un wrapper en lecture seule (outils \u003Ccode>Read\u003C\u002Fcode>, \u003Ccode>Grep\u003C\u002Fcode>, \u003Ccode>Glob\u003C\u002Fcode> uniquement), avec deux tentatives et une pause entre les deux.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Fallback\u003C\u002Fstrong> : si le binaire est absent ou si un mode alternatif est explicitement demandé, un second fournisseur est utilisé, avec jusqu'à trois tentatives et un backoff exponentiel.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Prompt figé en cinq sections\u003C\u002Fstrong> : écart tokens estimés\u002Fréels, top 3 erreurs récurrentes, top 3 patterns à standardiser, une doctrine candidate, un outil à créer.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Sortie\u003C\u002Fstrong> : une note de leçon au format Zettelkasten, avec statut \u003Ccode>draft\u003C\u002Fcode>, déposée dans la boîte de réception du Vault.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Promotion\u003C\u002Fstrong> : jamais automatique. L'opérateur déplace manuellement la note vers la mémoire permanente (RAG) ou la mémoire courante (réflexe) après relecture.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.5 Détection de patterns et propositions de skills\u003C\u002Fh3>\n\n\u003Cp>Un second pipeline, distinct de la boucle cicatrices, transforme les patterns récurrents observés dans les boucles de travail en propositions de skills invocables. C'est le mécanisme d'auto-amélioration des capacités de l'écosystème.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>Journal des itérations de tâches (actions\u002Fobservations terminées)\n      │ scan hebdomadaire (dimanche 04h UTC)\n      ▼\nDétecteur de patterns (LLM-first via sous-processus, timeout 3 min)\n      │ repère les patterns présents dans ≥ 3 tâches\n      │ vérifie l'absence de doublons (skill existante ou proposition déjà pendante)\n      │ INSERT proposition (status='pending', itérations sources, évidence LLM)\n      ▼\nTableau de bord des propositions de skills ── validation HUMAINE (fondateur)\n      │ liste \u002F valider \u002F rejeter\n      ▼\nPromotion vers le registre des skills natives (invocable par \u002F<slug>)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Détecteur opérationnel\u003C\u002Fstrong> (cron hebdomadaire, dimanche 04h UTC) : charge les itérations récentes au statut \u003Ccode>done\u003C\u002Fcode> ou \u003Ccode>pass\u003C\u002Fcode>, passe le batch au modèle de langage qui identifie les patterns méritant une skill, puis insère les propositions dans le journal après déduplication. Flags \u003Ccode>--dry-run\u003C\u002Fcode> et \u003Ccode>--limit\u003C\u002Fcode> disponibles.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Moniteur de propositions\u003C\u002Fstrong> (cron horaire) : alerte le fondateur si le nombre de propositions en attente dépasse un seuil configurable. Cool-down d'une heure pour éviter les doublons d'alerte. Les statistiques incluent les totaux par statut, le temps moyen de validation et les ajouts dans la dernière heure. L'alerte transite par la façade email centrale — jamais par une connexion SMTP directe.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Validation humaine\u003C\u002Fstrong> : une page dédiée du tableau de bord liste les propositions et permet de valider ou rejeter chacune. Une proposition validée est promue vers le registre des skills natives.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>À ne pas confondre :\u003C\u002Fstrong> le détecteur opérationnel décrit ci-dessus est le seul à alimenter réellement le journal de propositions. Il existe un second module-squelette (cron dominical 03h UTC) dont la docstring précise explicitement qu'il scanne et journalise sans encore créer de propositions — la logique de détection y est à venir. Ce n'est pas lui qui produit les propositions actives.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.6 Automates connexes de la boucle d'apprentissage\u003C\u002Fh3>\n\n\u003Ch4>Consolidation nocturne (boucle de maintenance)\u003C\u002Fh4>\n\n\u003Cp>Un automate de maintenance nocturne (exécution quotidienne à 04h UTC) consolide les apprentissages en dix fonctionnalités distinctes. Chaque fonctionnalité résout son modèle de langage depuis le routeur IA central. La règle transversale absolue : \u003Cstrong>aucun déplacement automatique\u003C\u002Fstrong> de la boîte de réception vers la mémoire permanente ou courante — toute promotion reste humaine. Le mode sans écriture (\u003Ccode>--dry-run\u003C\u002Fcode>) est le défaut.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Détection de cicatrices répétées\u003C\u002Fstrong> : compare les nouvelles entrées du jour aux entrées passées via similarité vectorielle. Si au moins deux occurrences similaires sont trouvées, un brouillon de promotion est généré dans la boîte de réception.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Compaction de sessions\u003C\u002Fstrong> : analyse les journaux de session du jour (maximum 30, en sautant ceux contenant des secrets détectés par regex), extrait de 3 à 5 faits durables (décision, livraison, cicatrice, constat) et les consigne dans le journal quotidien. En mode dry-run, aucun appel LLM n'est effectué.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Récapitulatif matinal\u003C\u002Fstrong> : email de synthèse envoyé via la façade email centrale, uniquement si des brouillons ou des journaux ont été produits dans la nuit.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit de divergence documentaire\u003C\u002Fstrong> : vérifie les paliers tarifaires canoniques, scanne les patterns obsolètes définis dans un fichier de configuration, et signale les tableaux à forte densité numérique qui gagneraient à être stockés en base de données. Les écarts sont déposés en brouillon dans la boîte de réception.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Réflexion nocturne\u003C\u002Fstrong> : pour chaque agent actif, les 20 cicatrices résolues les plus saillantes alimentent un LLM qui produit 3 questions introspectives et 3 abstractions, déposées en brouillon. En mode dry-run, seul le comptage des agents éligibles est effectué.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Courbe d'oubli\u003C\u002Fstrong> : archive (sans effacement) les cicatrices très anciennes sans aucun rappel enregistré, dans la limite de 200 par exécution. L'archivage les rend invisibles au moteur de rappel sémantique mais reste réversible.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Pro-activité chantier\u003C\u002Fstrong> : scrute les chantiers avec contacts externes actifs, relie automatiquement les emails entrants et sortants correspondants, et soumet le fil reconstitué à un LLM qui classe la situation : à archiver, action requise, en attente de réponse externe, ou aucune action nécessaire.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit d'obsolescence interne\u003C\u002Fstrong> : évalue les chantiers inactifs depuis un seuil de jours configurable, calcule leurs signaux d'obsolescence, et produit un verdict (toujours pertinent \u002F peut-être obsolète \u002F archivage recommandé) persisté dans le journal d'obsolescence. Les verdicts non-« toujours pertinent » remontent dans l'email matinal pour décision de l'opérateur.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit de dérive de persona\u003C\u002Fstrong> : exécuté uniquement le 1er du mois. Compare le profil actuel de chaque agent à sa configuration de référence, calcule un score de dérive, le persiste en historique, et remonte le top 3 des agents les plus dérivés dans l'email matinal.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Ticket de coût quotidien\u003C\u002Fstrong> : agrège les coûts IA de la veille par agent, compare à la moyenne sur 7 jours, et envoie une alerte email si le delta dépasse 20 % pour un agent donné.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch4>Classificateur de cicatrices\u003C\u002Fh4>\n\n\u003Cp>Un automate de qualification classe les cicatrices non encore catégorisées. Le modèle de langage retourne un objet structuré contenant :\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>Une catégorie proposée pour le type d'erreur.\u003C\u002Fli>\n  \u003Cli>Une sévérité réestimée (mise à jour si différente de l'actuelle).\u003C\u002Fli>\n  \u003Cli>Un indice de confiance et un raisonnement.\u003C\u002Fli>\n  \u003Cli>Des tags proposés.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note :\u003C\u002Fstrong> l'indicateur d'apprentissage (\u003Ccode>learnable\u003C\u002Fcode>) n'est pas écrit directement dans la colonne correspondante par cet automate. Il est sérialisé en préfixe du champ de raisonnement sous la forme \u003Ccode>learnable:true|false\u003C\u002Fcode> — comportement documenté et intentionnel.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch4>Hygiène de la mémoire courante\u003C\u002Fh4>\n\n\u003Cp>Un pipeline de consolidation mensuel (premier du mois, 00h00 UTC, avec verrou anti-overlap) nettoie la mémoire courante en quatre étapes séquentielles :\u003C\u002Fp>\n\u003Col>\n  \u003Cli>\u003Cstrong>Validation d'environnement\u003C\u002Fstrong> : vérifie que les variables d'environnement requises et les chemins sont accessibles. En cas d'échec, le pipeline s'arrête sans exécuter les étapes suivantes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Détection de liens morts\u003C\u002Fstrong> : scanne le fichier d'index de la mémoire et produit un rapport des références brisées. Cette étape s'exécute \u003Cstrong>même en mode dry-run\u003C\u002Fstrong> et peut écrire des rapports sur le disque.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Archivage des fichiers obsolètes\u003C\u002Fstrong> : déplace les fichiers marqués comme démantelés ou obsolètes vers une zone d'archive hors-dépôt, supprime les références correspondantes dans l'index.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Déduplication par empreinte\u003C\u002Fstrong> : identifie et supprime les fichiers strictement identiques (empreinte SHA-256).\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>Un rapport JSON est généré à chaque exécution, indiquant pour chaque étape le statut, la durée et les éventuelles erreurs. Les codes de sortie sont :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Code\u003C\u002Fth>\n      \u003Cth>Sens\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>0\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Pipeline complet réussi (ou validation seule réussie)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>1\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Validation d'environnement échouée — aucune étape exécutée\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>2\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Erreur fatale dans une étape — pipeline interrompu\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>3\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Mode dry-run terminé — aucune modification réelle\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Flags disponibles : \u003Ccode>--dry-run\u003C\u002Fcode> (étapes 3 et 4 court-circuitées ou simulées, étape 2 toujours active), \u003Ccode>--validate-only\u003C\u002Fcode> (arrêt après l'étape 1).\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Important :\u003C\u002Fstrong> le module de formation documentant ce pipeline (\u003Cem>support de formation consolidation\u003C\u002Fem>) est lu en dur par le quiz de non-régression. Le supprimer sans adapter le quiz au préalable ferait échouer au moins quatre vérifications et bloquerait le pipeline de validation.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch4>Observabilité de la mémoire courante\u003C\u002Fh4>\n\n\u003Cp>Un automate quotidien (06h00 UTC) enregistre une série temporelle sur 90 jours : nombre de fichiers, taille totale, nombre de lignes dans l'index, liens morts et références orphelines. Des alertes sont émises dans le système de supervision si les seuils configurés sont dépassés. Flags : \u003Ccode>--json\u003C\u002Fcode>, \u003Ccode>--dry-run\u003C\u002Fcode>.\u003C\u002Fp>\n\n\u003Ch3>4.7 Rappel du modèle utilisateur (canal structuré)\u003C\u002Fh3>\n\n\u003Cp>Le rappel sémantique vectoriel n'est pas l'unique canal de mémoire. Un module dédié charge le \u003Cstrong>modèle utilisateur\u003C\u002Fstrong> depuis la base de données — un profil structuré en dimensions JSONB — et l'injecte dans les briefings agents. Ce rappel est \u003Cstrong>ciblé et structuré\u003C\u002Fstrong>, pas vectoriel.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Dimensions disponibles\u003C\u002Fstrong> : style de communication, horaires, profil, compétences, historique, préférences, données strictement privées réservées à l'opérateur principal.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tranche composite \u003Ccode>core\u003C\u002Fcode>\u003C\u002Fstrong> : agrège le style de communication, les préférences cognitives et les créneaux de rendez-vous, calibrée pour l'injection briefing (moins de 1 000 tokens). N'inclut jamais les données privées réservées.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>API\u003C\u002Fstrong> : \u003Ccode>get_profile(slice=…)\u003C\u002Fcode> retourne un dictionnaire ; \u003Ccode>format_for_briefing(…)\u003C\u002Fcode> retourne un texte prêt à l'injection. Une interface en ligne de commande permet d'interroger ces tranches directement, avec options \u003Ccode>--json\u003C\u002Fcode> et \u003Ccode>--format-briefing\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"boucle-maintenance-nocturne\">Boucle de maintenance nocturne\u003C\u002Fh2>\n\n\u003Cp>La boucle de maintenance nocturne constitue la méta-couche au-dessus des cycles d'apprentissage : un orchestrateur qui s'exécute chaque nuit, inspecte la fidélité de la documentation par rapport au code, mesure la santé globale du système, répare mécaniquement les références mortes, déclenche la régénération autonome des chapitres dérivés, puis pousse un instantané assaini vers synedre.com.\u003C\u002Fp>\n\n\u003Cp>La séquence d'étapes s'enchaîne dans l'ordre suivant :\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Perception initiale\u003C\u002Fstrong> — le détecteur de dérive mesure l'écart entre documentation et code.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Couverture\u003C\u002Fstrong> — le détecteur d'angles morts identifie les zones non documentées.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Réparation\u003C\u002Fstrong> — le correcteur de références mortes traite mécaniquement les liens brisés.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Régénération profonde\u003C\u002Fstrong> — la réécriture approfondie, soumise à des gardes-fous, reconstruit les chapitres dérivés.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Proposition\u003C\u002Fstrong> — un cycle de mise en attente produit des brouillons en zone de staging.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Publication documentation\u003C\u002Fstrong> — les chapitres passent des portes anti-fuite, anti-dérive et de style avant activation.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Re-perception\u003C\u002Fstrong> — le détecteur de dérive effectue une \u003Cem>seconde\u003C\u002Fem> mesure après régénération, afin que le bilan de santé reflète l'état réel post-régénération et non l'état de début de nuit.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Bilan de santé\u003C\u002Fstrong> — les cinq dimensions vitales sont agrégées et un commentaire de soin est rédigé.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Publication snapshot\u003C\u002Fstrong> — un instantané assaini est poussé vers synedre.com (mode best-effort).\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>Le déclenchement automatique a lieu chaque jour à 05 h 00 UTC via le planificateur de tâches du système. Les journaux d'exécution sont conservés dans le répertoire de logs dédié à cette boucle.\u003C\u002Fp>\n\n\u003Ch3>Orchestrateur de la boucle\u003C\u002Fh3>\n\n\u003Cp>L'orchestrateur constitue l'unique point d'entrée de la boucle nocturne. Il embarque plusieurs gardes-fous globaux :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Coupe-circuit en base\u003C\u002Fstrong> : si l'entrée correspondant à cette boucle dans la table de configuration des automates indique \u003Ccode>active = 0\u003C\u002Fcode>, l'exécution s'interrompt silencieusement.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Verrou anti-chevauchement\u003C\u002Fstrong> : un fichier de verrou temporaire portant le PID courant est créé au démarrage. Si un processus identifié par ce PID est déjà actif, la boucle s'arrête immédiatement. Le verrou est systématiquement supprimé en fin d'exécution, même en cas d'exception dans une sous-étape.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Codes de retour sémantiques\u003C\u002Fstrong> : les codes 1 et 2 signalent respectivement « dérive présente » et « santé critique » — ce sont des statuts informatifs, non des échecs fatals. Le seul cas de sortie non-zéro bloquante est le crash réel d'une sous-étape.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Rapport quotidien\u003C\u002Fstrong> : en fin de boucle, un enregistrement idempotent est inséré dans la table de rapport du matin, résumant le code de retour de chaque étape.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Les options de pilotage disponibles sont les suivantes :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Option\u003C\u002Fth>\n      \u003Cth>Effet\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(aucune)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Exécution complète en mode live\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--dry-run\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Toutes les sous-étapes opèrent en simulation ; le coupe-circuit DB est contourné\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--no-deep\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Saute l'étape de régénération profonde\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--deep-max N\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Plafond dur du nombre de chapitres traités en profondeur (défaut : 4) ; la convergence réelle reste bornée par le budget-temps\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--deep-budget-sec N\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Budget-temps maximal en secondes pour la régénération profonde (défaut : 4 500 s \u002F 75 min) ; aucun nouveau chapitre n'est lancé au-delà de ce seuil\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Bilan de santé multi-dimensionnel\u003C\u002Fh3>\n\n\u003Cp>Le composant de bilan de santé agrège cinq dimensions vitales en un instantané idempotent par date d'exécution, visible dans le tableau de bord du matin.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Dimension\u003C\u002Fth>\n      \u003Cth>Ce qui est mesuré\u003C\u002Fth>\n      \u003Cth>Seuil critique\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Proprioception\u003C\u002Ftd>\n      \u003Ctd>Table de dérive documentaire\u003C\u002Ftd>\n      \u003Ctd>≥ 1 chapitre avec référence morte\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Couverture\u003C\u002Ftd>\n      \u003Ctd>Table de couverture documentaire\u003C\u002Ftd>\n      \u003Ctd>≥ 1 unité non couverte\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Dette\u003C\u002Ftd>\n      \u003Ctd>Backlog de tâches priorisées\u003C\u002Ftd>\n      \u003Ctd>≥ 1 tâche de priorité maximale en attente\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Apprentissage\u003C\u002Ftd>\n      \u003Ctd>Vue matérialisée des indicateurs de cicatrices\u003C\u002Ftd>\n      \u003Ctd>Rafraîchissement absent depuis plus de 3 jours\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Automates\u003C\u002Ftd>\n      \u003Ctd>Journal d'erreurs cron + registre des automates\u003C\u002Ftd>\n      \u003Ctd>≥ 1 script du périmètre vaisseau-mère désactivé involontairement\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>\u003Cstrong>Périmètre des automates surveillés\u003C\u002Fstrong> : seuls les automates appartenant au périmètre vaisseau-mère et marqués actifs sont pris en compte. Les automates appartenant à un tenant client ou désactivés volontairement ne dégradent pas la métrique de santé globale.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Note de soin\u003C\u002Fstrong> : l'agent Nightingale (Gardien de la Santé) lit les signes vitaux agrégés et rédige une note de soin en trois phrases maximum, en anglais. Cette note est stockée dans le champ JSON de l'enregistrement global du bilan de santé. Si l'agent est indisponible, le champ reste vide sans bloquer le reste de la boucle.\u003C\u002Fp>\n\n\u003Cp>Options disponibles : \u003Ccode>--dry-run\u003C\u002Fcode> (affiche le bilan sans écriture), \u003Ccode>--no-voice\u003C\u002Fcode> (métriques seules, sans note de soin). Codes de sortie : 0 = nominal, 1 = avertissement, 2 = critique.\u003C\u002Fp>\n\n\u003Ch3>Publication du snapshot assaini vers synedre.com\u003C\u002Fh3>\n\n\u003Cp>Ce composant lit en lecture seule les derniers instantanés de santé et de dérive sur le VPS du vaisseau-mère, applique une passe d'assainissement automatique (suppression des adresses IP, chemins internes et identifiants clients), puis pousse un instantané JSON vers la base de données du VPS synedre.com.\u003C\u002Fp>\n\n\u003Cp>Gardes-fous :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Aucune écriture n'est effectuée sur la base du vaisseau-mère : la connexion est strictement en lecture.\u003C\u002Fli>\n  \u003Cli>La table de destination est créée idempotement au premier lancement si elle n'existe pas.\u003C\u002Fli>\n  \u003Cli>Un seul snapshot est conservé par date (UPSERT sur la clé date).\u003C\u002Fli>\n  \u003Cli>Une erreur lors de la poussée vers le VPS synedre.com génère un log d'erreur et un code de retour 2, mais \u003Cstrong>n'interrompt pas\u003C\u002Fstrong> la boucle nocturne (mode best-effort).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Le snapshot expose la santé globale et par dimension (scores, statuts, résumés assainis), la liste des chapitres en dérive (avec leur score), et la note de soin de l'agent Nightingale. Ces données alimentent le cadran de maintenance accessible depuis la section documentation de synedre.com.\u003C\u002Fp>\n\n\u003Cp>Options : \u003Ccode>--dry-run\u003C\u002Fcode> (affiche le JSON sans écriture). Codes de sortie : 0 = nominal, 1 = erreur lecture vaisseau-mère, 2 = erreur poussée vers synedre.com.\u003C\u002Fp>\n\n\u003Ch2 id=\"facade-ia\">Façade IA centralisée\u003C\u002Fh2>\n\n\u003Cp>L'ensemble des appels à des services d'intelligence artificielle au sein du système passe par une façade unique. Cette doctrine garantit que toute modification de fournisseur, de modèle ou de clé se fait en un seul endroit, sans toucher aux automates métier.\u003C\u002Fp>\n\n\u003Cp>Deux fonctions canoniques sont exposées :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Vectorisation\u003C\u002Fstrong> (\u003Ccode>embed\u003C\u002Fcode>) : transforme un texte en vecteur flottant, utilisé pour la recherche sémantique et le rappel de mémoire.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Complétion\u003C\u002Fstrong> (\u003Ccode>complete\u003C\u002Fcode>) : envoie une mission et un contexte à un modèle de langage et retourne la réponse textuelle ou JSON.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Routage par base de données\u003C\u002Fh3>\n\n\u003Cp>Lorsque le paramètre fournisseur est réglé sur \u003Ccode>auto\u003C\u002Fcode>, la façade lit la table de routage IA en base pour déterminer quel fournisseur et quel modèle utiliser selon la fonctionnalité demandée. Cette table expose une ligne de repli global ainsi qu'une ligne par fonctionnalité nommée, fusionnée avec le repli.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Avantage clé\u003C\u002Fstrong> : changer de fournisseur revient à modifier une seule ligne en base — aucun redéploiement n'est nécessaire. La boucle nocturne relit la configuration à chaque exécution. Si la base est inaccessible ou vide, des valeurs par défaut canoniques prennent le relais (mode fail-soft).\u003C\u002Fp>\n\n\u003Cp>Fournisseurs et modèles par défaut :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Usage\u003C\u002Fth>\n      \u003Cth>Fournisseurs supportés\u003C\u002Fth>\n      \u003Cth>Modèle par défaut\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Vectorisation\u003C\u002Ftd>\n      \u003Ctd>Mistral, Voyage, OpenAI\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>mistral-embed\u003C\u002Fcode> \u002F \u003Ccode>voyage-3\u003C\u002Fcode> \u002F \u003Ccode>text-embedding-3-small\u003C\u002Fcode>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Complétion\u003C\u002Ftd>\n      \u003Ctd>Anthropic (Claude), Mistral, OpenAI\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>claude-haiku-4-5\u003C\u002Fcode> \u002F \u003Ccode>mistral-large-latest\u003C\u002Fcode> \u002F \u003Ccode>gpt-4o-mini\u003C\u002Fcode>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Le fournisseur de vectorisation canonique est Mistral, retenu pour des raisons de souveraineté européenne des données.\u003C\u002Fp>\n\n\u003Ch3>Complétion Anthropic : deux chemins de facturation\u003C\u002Fh3>\n\n\u003Cp>Le fournisseur Anthropic dispose de deux chemins d'appel distincts, sélectionnés automatiquement à l'exécution :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Appel API directe\u003C\u002Fstrong> : si la clé API du fournisseur Anthropic est présente dans l'environnement ou passée en paramètre, la façade appelle directement l'API REST. Ce chemin est utilisé pour les clients disposant d'un compte Console propre (facturation séparée). Il inclut une logique de réessai sur les erreurs temporaires (code 429 ou 5xx), un suivi de consommation en base (tokens, coût estimé, étiquette de facturation par tenant), et la résolution d'alias courts (\u003Ccode>haiku\u003C\u002Fcode>, \u003Ccode>sonnet\u003C\u002Fcode>, \u003Ccode>opus\u003C\u002Fcode>) vers les identifiants complets de modèle.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Appel via l'agent interne\u003C\u002Fstrong> : en l'absence de clé API dans l'environnement, la façade délègue à l'agent Gauss (persona neutre), qui utilise le forfait interne. Ce chemin est réservé à l'usage interne du vaisseau-mère.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Complétion Mistral\u003C\u002Fh3>\n\n\u003Cp>Les appels Mistral passent par l'API REST avec une température nulle (sorties déterministes) et un mode JSON si demandé. La façade effectue jusqu'à trois tentatives en cas d'erreur temporaire (code 429 ou 5xx) avec une attente croissante entre chaque essai. Les erreurs 4xx non temporaires (paramètre invalide, quota dépassé définitivement, etc.) sont considérées comme permanentes et ne déclenchent pas de réessai. Tout retour \u003Ccode>None\u003C\u002Fcode> est journalisé sur la sortie d'erreur.\u003C\u002Fp>\n\n\u003Ch3>Suivi de consommation\u003C\u002Fh3>\n\n\u003Cp>Chaque complétion effectuée via l'API directe Anthropic est tracée en base : fournisseur, modèle, étiquette fonctionnelle, nombre de tokens en entrée et en sortie, coût estimé en USD. Ce mécanisme permet la refacturation par tenant. L'écriture en base est encapsulée dans un bloc de protection : une erreur de traçage ne bloque jamais la complétion elle-même.\u003C\u002Fp>\n\n\u003Ch3>Clés API et sécurité\u003C\u002Fh3>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Règle absolue\u003C\u002Fstrong> : aucune valeur de clé ou de secret n'apparaît dans cette documentation ni dans le dépôt versionné. Toutes les clés sont lues depuis des fichiers d'environnement exclus du contrôle de version.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>La façade lit les variables d'environnement suivantes au démarrage :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Fournisseur\u003C\u002Fth>\n      \u003Cth>Variable d'environnement\u003C\u002Fth>\n      \u003Cth>Usage\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Mistral\u003C\u002Ftd>\n      \u003Ctd>Clé API Mistral\u003C\u002Ftd>\n      \u003Ctd>Vectorisation et complétion Mistral\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Voyage\u003C\u002Ftd>\n      \u003Ctd>Clé API Voyage\u003C\u002Ftd>\n      \u003Ctd>Vectorisation Voyage\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>OpenAI\u003C\u002Ftd>\n      \u003Ctd>Clé API OpenAI\u003C\u002Ftd>\n      \u003Ctd>Vectorisation et complétion OpenAI\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Anthropic\u003C\u002Ftd>\n      \u003Ctd>Clé API Anthropic\u003C\u002Ftd>\n      \u003Ctd>Complétion API directe (chemin clients)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Base de données\u003C\u002Ftd>\n      \u003Ctd>Mot de passe de la base principale\u003C\u002Ftd>\n      \u003Ctd>Connexion au moteur de persistance du vaisseau-mère\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Le chargement s'effectue au démarrage depuis les fichiers d'environnement situés à la racine du dépôt, via \u003Ccode>os.environ.setdefault\u003C\u002Fcode> (les valeurs déjà présentes dans l'environnement système ne sont pas écrasées).\u003C\u002Fp>\n\n\u003Ch2 id=\"connexion-base-de-donnees\">Connexion à la base de données\u003C\u002Fh2>\n\n\u003Cp>Le moteur de persistance du vaisseau-mère est un service PostgreSQL conteneurisé. Les automates Python s'y connectent en spécifiant le bon nom de base et le schéma dédié au vaisseau-mère via l'option \u003Ccode>search_path\u003C\u002Fcode>. Le port d'exposition sur la machine hôte est distinct du port interne du conteneur afin d'éviter toute collision.\u003C\u002Fp>\n\n\u003Cp>Tous les accès en lecture (rappel sémantique, synchronisation de vecteurs) comme en écriture (journaux, bilans de santé, rapports quotidiens) utilisent la même chaîne de connexion, garantissant un point de configuration unique pour l'ensemble des automates.\u003C\u002Fp>\n\u003Ch2 id=\"artefacts-recap\">Tableau récapitulatif des composants\u003C\u002Fh2>\n\n\u003Cp>Ce tableau liste l'ensemble des composants qui constituent la boucle d'apprentissage et de mémoire de Synedre OS, classés par rôle fonctionnel.\u003C\u002Fp>\n\n\u003Ch3>Composants d'indexation et de mémoire\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Indexeur de notes\u003C\u002Ftd>\n      \u003Ctd>Tâche périodique (toutes les 15 min)\u003C\u002Ftd>\n      \u003Ctd>Transforme les notes du cerveau documentaire en entrées relationnelles consultables.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Synchroniseur de vecteurs\u003C\u002Ftd>\n      \u003Ctd>Tâche nocturne + déclenchement en ligne\u003C\u002Ftd>\n      \u003Ctd>Calcule et stocke les représentations vectorielles (1024 dimensions) de toutes les sources ; mode incrémental la nuit, recalcul unitaire à la demande lors d'un cycle de raisonnement.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des vecteurs\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stocke les vecteurs sémantiques avec index HNSW cosine pour la recherche approximative de plus proches voisins.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des notes indexées\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Représentation relationnelle du Zettelkasten documentaire, alimentée par l'indexeur de notes.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Dataset doré de rappel\u003C\u002Ftd>\n      \u003Ctd>Fichier de référence\u003C\u002Ftd>\n      \u003Ctd>Jeu de questions-réponses de référence utilisé par le harnais d'évaluation du rappel.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Baseline de rappel\u003C\u002Ftd>\n      \u003Ctd>Fichier de référence figé\u003C\u002Ftd>\n      \u003Ctd>Scores de référence figés (rappel@k, MRR, top-1) servant de seuil de non-régression.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Composants de rappel et d'évaluation\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Moteur de rappel\u003C\u002Ftd>\n      \u003Ctd>RAG\u003C\u002Ftd>\n      \u003Ctd>Combine recherche lexicale, sémantique et hybride (fusion par rang réciproque, k=60) ; sélectionne les top-K résultats, les re-classe et remonte leur score d'usage.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Harnais d'évaluation du rappel\u003C\u002Ftd>\n      \u003Ctd>Assurance qualité\u003C\u002Ftd>\n      \u003Ctd>Mesure recall@k, MRR@10 et précision top-1 sur le dataset doré ; bloque toute régression par rapport à la baseline figée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Rappel pré-chantier\u003C\u002Ftd>\n      \u003Ctd>Crochet d'événement (déclenchement avant création)\u003C\u002Ftd>\n      \u003Ctd>Exécute un rappel hybride top-4 avant toute création de structure de chantier ; non bloquant, enrichit le contexte de l'agent sans interrompre le flux.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Rappel utilisateur\u003C\u002Ftd>\n      \u003Ctd>Personnalisation\u003C\u002Ftd>\n      \u003Ctd>Exploite le modèle utilisateur multidimensionnel pour produire des briefings contextualisés à destination des agents.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table du modèle utilisateur\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stocke les dimensions JSONB du profil de chaque utilisateur, utilisées pour personnaliser les briefings de rappel.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Composants de maintenance nocturne\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Orchestrateur de maintenance nocturne\u003C\u002Ftd>\n      \u003Ctd>Tâche nocturne (vers 5 h)\u003C\u002Ftd>\n      \u003Ctd>Coordonne la boucle complète de régénération : perception → couverture → réparation → régénération → proposition → publication de documentation → re-perception → soin → publication.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Bilan de santé\u003C\u002Ftd>\n      \u003Ctd>Diagnostic\u003C\u002Ftd>\n      \u003Ctd>Évalue cinq dimensions de santé du système et enregistre le résultat dans les tables de suivi ; alimente également le journal quotidien de l'équipe.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Synchroniseur public de santé\u003C\u002Ftd>\n      \u003Ctd>Export assaini\u003C\u002Ftd>\n      \u003Ctd>Produit un instantané sanitisé (sans données sensibles) des indicateurs de santé et de dérive, synchronisé vers le VPS public.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des snapshots de santé\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Historique des évaluations de santé par date et par dimension (cinq dimensions + score global).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des snapshots publics\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Instantanés assainis jour par jour, répliqués vers le VPS public pour exposition sur synedre.com.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Moteur de consolidation nocturne\u003C\u002Ftd>\n      \u003Ctd>Tâche toutes les 4 h\u003C\u002Ftd>\n      \u003Ctd>Consolide dix fonctionnalités de mémoire à long terme ; s'exécute en mode simulation par défaut (aucune écriture sans validation explicite).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Hygiène mensuelle de la mémoire\u003C\u002Ftd>\n      \u003Ctd>Tâche mensuelle\u003C\u002Ftd>\n      \u003Ctd>Nettoie le corpus mémoriel : suppression des liens morts, archivage des entrées obsolètes, déduplication par empreinte de contenu ; produit un rapport de consolidation daté.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Métriques mémoire\u003C\u002Ftd>\n      \u003Ctd>Tâche toutes les 6 h\u003C\u002Ftd>\n      \u003Ctd>Calcule les indicateurs de volumétrie et de qualité de la mémoire ; conserve une série temporelle sur 90 jours et émet des alertes si des seuils sont franchis.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des métriques mémoire\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Série temporelle des indicateurs mémoire sur 90 jours de rétention.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Composants d'apprentissage et de qualification\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Réflexe post-chantier\u003C\u002Ftd>\n      \u003Ctd>Rétrospective\u003C\u002Ftd>\n      \u003Ctd>Produit une leçon structurée à l'issue de chaque chantier et l'injecte dans la boîte de réception du cerveau documentaire ; utilise un modèle de langage avancé par défaut, avec repli automatique vers un modèle alternatif.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Moteur de suggestions d'apprentissage\u003C\u002Ftd>\n      \u003Ctd>Moteur LLM\u003C\u002Ftd>\n      \u003Ctd>Analyse les leçons marquées comme apprenables et génère des suggestions d'amélioration en attente de validation humaine.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Qualificateur de leçons\u003C\u002Ftd>\n      \u003Ctd>Classification LLM\u003C\u002Ftd>\n      \u003Ctd>Attribue à chaque leçon un type d'erreur, un niveau de sévérité, un score de confiance et un raisonnement ; préfixe les leçons apprenables pour les distinguer dans la file d'attente.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des leçons\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stocke les leçons (échecs et victoires), leur importance et leur statut apprenable.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des suggestions d'apprentissage\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>File d'attente des suggestions LLM en attente de validation par l'équipe.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Journal d'audit des apprentissages\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Trace immuable de chaque suggestion validée et appliquée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Composants de détection de patterns et de compétences\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Détecteur de compétences émergentes\u003C\u002Ftd>\n      \u003Ctd>Tâche hebdomadaire (dimanche 4 h)\u003C\u002Ftd>\n      \u003Ctd>Analyse les patterns d'itérations récurrentes et soumet des propositions de nouvelles compétences pour validation humaine. Composant \u003Cstrong>fonctionnel\u003C\u002Fstrong> : les propositions sont réellement insérées en base.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Moniteur de propositions\u003C\u002Ftd>\n      \u003Ctd>Tâche horaire\u003C\u002Ftd>\n      \u003Ctd>Émet une alerte à destination de l'équipe fondatrice si le nombre de propositions de compétences en attente dépasse un seuil configurable.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Squelette de détection de patterns\u003C\u002Ftd>\n      \u003Ctd>Tâche hebdomadaire (dimanche 3 h) — MVP inactif\u003C\u002Ftd>\n      \u003Ctd>Parcourt et journalise les patterns sans créer de propositions. Composant en cours de développement, distinct du détecteur de compétences émergentes.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des propositions de compétences\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>File d'attente des propositions de nouvelles compétences en attente de validation humaine.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table des compétences natives\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Référentiel des compétences actives du système ; cible de promotion des propositions validées.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Interface de validation des compétences\u003C\u002Ftd>\n      \u003Ctd>Interface utilisateur (cadran hub)\u003C\u002Ftd>\n      \u003Ctd>Permet à l'équipe de valider ou rejeter les propositions de compétences directement depuis le hub de pilotage.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Composants transverses\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Façade IA\u003C\u002Ftd>\n      \u003Ctd>Abstraction\u003C\u002Ftd>\n      \u003Ctd>Point d'entrée unique pour toutes les opérations d'inférence (embedding et complétion) ; route chaque appel vers le fournisseur et le modèle appropriés selon une table de routage centrale ; supporte deux chemins d'accès au modèle principal (API directe et interface CLI) ; enregistre chaque appel pour le suivi de consommation et la refacturation.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table de routage IA\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Source de vérité unique définissant, pour chaque fonctionnalité, le fournisseur d'embedding, le fournisseur de complétion, le modèle cible et des paramètres étendus au format structuré.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Table de consommation IA\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Enregistre chaque appel API avec le fournisseur, le modèle, l'étiquette de mesure, le nombre de tokens en entrée et en sortie, et le coût estimé en dollars ; utilisé pour la facturation par tenant.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Interface de rappel utilisateur\u003C\u002Ftd>\n      \u003Ctd>Compétence (interface utilisateur)\u003C\u002Ftd>\n      \u003Ctd>Permet à un utilisateur d'interroger explicitement la mémoire du système via une interface dédiée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Interface de rétrospective\u003C\u002Ftd>\n      \u003Ctd>Compétence (interface utilisateur)\u003C\u002Ftd>\n      \u003Ctd>Déclenche manuellement la production d'une leçon post-chantier.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Interface de victoire\u003C\u002Ftd>\n      \u003Ctd>Compétence (interface utilisateur)\u003C\u002Ftd>\n      \u003Ctd>Enregistre et valorise les succès notables dans le corpus mémoriel.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note d'architecture :\u003C\u002Fstrong> l'ensemble de ces composants forme un système fermé d'auto-amélioration. Les leçons alimentent les suggestions, les suggestions alimentent les compétences, les compétences améliorent les futurs chantiers, et les chantiers produisent de nouvelles leçons. La façade IA et la table de routage centrale garantissent que chaque évolution de modèle ou de fournisseur se répercute uniformément sur l'intégralité de la boucle sans modification des composants individuels.\u003C\u002Fp>\n\u003C\u002Fblockquote>","\u003Ch2 id=\"memoire-apprentissage\">Memory & learning of the agentic harness\u003C\u002Fh2>\n\n\u003Cp>This page describes how the agentic harness \u003Cstrong>remembers\u003C\u002Fstrong> (three-level memory), \u003Cstrong>retrieves relevant information\u003C\u002Fstrong> (semantic recall via vector similarity) and \u003Cstrong>capitalises on its errors and successes\u003C\u002Fstrong> as reusable rules (scars → learning → lessons loop).\u003C\u002Fp>\n\n\u003Ch2 id=\"memoire-trois-niveaux\">1. Three-level memory\u003C\u002Fh2>\n\n\u003Cp>The system distinguishes three memory stores of increasing granularity and write discipline.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>┌─────────────────────────────────────────────────────────────────┐\n│ LEVEL 1 — Reflex memory                                         │\n│   Loaded in EVERY session. Hard rules, feedback,                │\n│   references. Strict, one entry per line in the index.          │\n├─────────────────────────────────────────────────────────────────┤\n│ LEVEL 2 — Knowledge base (Zettelkasten)                         │\n│   The \"why\": decisions, doctrine, concepts. Exploratory.        │\n│   Draft zone = free deposit; consolidated zone = mandatory      │\n│   human validation.                                             │\n├─────────────────────────────────────────────────────────────────┤\n│ LEVEL 3 — Vector semantic index                                 │\n│   HNSW vector index (cosine similarity, 1024 dimensions)        │\n│   covering both preceding levels + DB tables.                   │\n│   Enables RAG recall (Retrieval-Augmented Generation).          │\n└─────────────────────────────────────────────────────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch3>Level 1 — Reflex memory\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>An \u003Cstrong>index file\u003C\u002Fstrong> lists all active entries (one line per entry, ≤ 200 characters each).\u003C\u002Fli>\n  \u003Cli>Details live in thematic files: experience feedback, user preferences, project references.\u003C\u002Fli>\n  \u003Cli>These files are \u003Cstrong>automatically injected into the context of every session\u003C\u002Fstrong>: no explicit recall is required. Only genuine high-impact doctrines appear here — write discipline is strict.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Level 2 — Zettelkasten knowledge base\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Organised into distinct sub-spaces: permanent notes (consolidated), inbox (drafts), tables of contents, daily logs, ephemeral notes.\u003C\u002Fli>\n  \u003Cli>Notes cross-reference each other via wiki links; a YAML frontmatter indicates the type and status of each note.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Promotion rule:\u003C\u002Fstrong> the inbox is the only zone where the agent writes freely. The permanent zone is never modified without an explicit order from a human operator. No automatic merge between the two zones is permitted — this is an architectural safeguard.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Level 3 — Vector semantic index\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Vectors are \u003Cstrong>1024\u003C\u002Fstrong>-dimensional, produced by a dedicated embedding model.\u003C\u002Fli>\n  \u003Cli>The index uses the \u003Cstrong>HNSW\u003C\u002Fstrong> (Hierarchical Navigable Small World) structure with cosine similarity, guaranteeing very fast approximate searches even on large corpora.\u003C\u002Fli>\n  \u003Cli>A uniqueness constraint per \u003Cem>(source type, source identifier)\u003C\u002Fem> pair prevents duplicates during updates.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"indexation\">2. Indexing\u003C\u002Fh2>\n\n\u003Cp>Two distinct automations feed levels 2 and 3. It is important not to confuse them: the first feeds a \u003Cstrong>structural index\u003C\u002Fstrong> of the knowledge base (used by interfaces and criteria-based search); the second feeds the \u003Cstrong>semantic vector index\u003C\u002Fstrong> (used for RAG recall).\u003C\u002Fp>\n\n\u003Ch3>2.1 Knowledge-base structural indexing automation\u003C\u002Fh3>\n\n\u003Cp>This automation traverses all sub-spaces of the knowledge base and maintains a structured representation of each note in the relational database.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Scope:\u003C\u002Fstrong> permanent notes, inbox, tables of contents, daily logs, ephemeral notes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Processing:\u003C\u002Fstrong> extraction of the YAML frontmatter and inter-note links from each file.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Incremental synchronisation:\u003C\u002Fstrong> the file modification date is compared against the value stored in the database; only modified notes are reprocessed. Deleted notes are removed from the index.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Data retained per note:\u003C\u002Fstrong> relative path, type, title, tags, full frontmatter, body, outgoing links, size, timestamps.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Options:\u003C\u002Fstrong> \u003Cem>force\u003C\u002Fem> mode (full re-indexing) and \u003Cem>stats\u003C\u002Fem> mode (count without writing).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Cadence:\u003C\u002Fstrong> every 15 minutes. The operation is idempotent.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>2.2 Embedding and vector synchronisation automation\u003C\u002Fh3>\n\n\u003Cp>This automation produces semantic vectors for all sources and inserts them into the vector index. It uses an external embedding model (1024 dimensions).\u003C\u002Fp>\n\n\u003Cp>The \u003Cstrong>indexed sources\u003C\u002Fstrong> and their indicative volumes are:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Source type\u003C\u002Fth>\n      \u003Cth>Origin\u003C\u002Fth>\n      \u003Cth>Indicative volume\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Scars\u003C\u002Ftd>\n      \u003Ctd>Errors recorded by the reflex engine (all entries with a description)\u003C\u002Ftd>\n      \u003Ctd>~740\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Victories\u003C\u002Ftd>\n      \u003Ctd>Successes recorded by the reflex engine\u003C\u002Ftd>\n      \u003Ctd>~4\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Reflex memory\u003C\u002Ftd>\n      \u003Ctd>Level-1 memory files (excluding the main index)\u003C\u002Ftd>\n      \u003Ctd>~226\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Knowledge base\u003C\u002Ftd>\n      \u003Ctd>Notes from the various Zettelkasten sub-spaces\u003C\u002Ftd>\n      \u003Ctd>~14\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Doctrines\u003C\u002Ftd>\n      \u003Ctd>Active doctrine rules\u003C\u002Ftd>\n      \u003Ctd>~25\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Projects\u003C\u002Ftd>\n      \u003Ctd>Ongoing projects\u003C\u002Ftd>\n      \u003Ctd>~10\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Agents\u003C\u002Ftd>\n      \u003Ctd>Agent descriptors\u003C\u002Ftd>\n      \u003Ctd>~30\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Drills\u003C\u002Ftd>\n      \u003Ctd>Training scenarios\u003C\u002Ftd>\n      \u003Ctd>~31\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Procedures\u003C\u002Ftd>\n      \u003Ctd>Active operational procedures\u003C\u002Ftd>\n      \u003Ctd>~17\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>ReAct iterations\u003C\u002Ftd>\n      \u003Ctd>Reasoning \u002F action \u002F observation triplets from agentic loops\u003C\u002Ftd>\n      \u003Ctd>~16\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>\u003Cstrong>Key mechanisms of the automation:\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Fingerprint-based deduplication:\u003C\u002Fstrong> each chunk receives a SHA-256 fingerprint of its content. If the \u003Cem>(type, identifier)\u003C\u002Fem> pair already exists with the same fingerprint, the chunk is skipped — no call to the embedding service is made.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Chunking:\u003C\u002Fstrong> in the current version, each document constitutes a single chunk, truncated beyond a character threshold. Finer-grained splitting is planned for a later phase.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Batch processing:\u003C\u002Fstrong> calls to the embedding service group 50 inputs per request to limit network latency.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Insertion:\u003C\u002Fstrong> each vector is atomically inserted or updated according to the \u003Cem>(type, identifier)\u003C\u002Fem> uniqueness constraint.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Options:\u003C\u002Fstrong> \u003Cem>rebuild\u003C\u002Fem> mode (full purge followed by complete re-embedding), source-type filter, \u003Cem>dry-run\u003C\u002Fem> mode (simulation without writing).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>2.3 Immediate re-indexing of a scar\u003C\u002Fh3>\n\n\u003Cp>When a scar is recorded \u003Cem>during\u003C\u002Fem> an active agentic loop (ReAct cycle), a unit re-indexing procedure is triggered \u003Cstrong>immediately\u003C\u002Fstrong>: the scar becomes searchable in the RAG without waiting for the next nightly synchronisation. This mechanism ensures that the agent can benefit from a lesson learned a few seconds after recording it, including within the same run.\u003C\u002Fp>\n\n\u003Ch3>2.4 Maintenance cadences\u003C\u002Fh3>\n\n\u003Cp>The various memory automations run according to the following schedules:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Knowledge-base structural indexing:\u003C\u002Fstrong> every 15 minutes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Full vector synchronisation (incremental):\u003C\u002Fstrong> daily, early morning. Unit re-indexing of scars (§ 2.3) remains active in parallel for immediacy.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Nightly consolidation loop:\u003C\u002Fstrong> at night, shortly after midnight — proposes syntheses from the inbox to the permanent zone (human validation required).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Pattern detector:\u003C\u002Fstrong> weekly (Sunday).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Skill-proposal detector:\u003C\u002Fstrong> weekly (Sunday) and hourly monitoring.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Memory metrics:\u003C\u002Fstrong> daily, morning.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Monthly consolidation:\u003C\u002Fstrong> 1\u003Csup>st\u003C\u002Fsup> of the month.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Maintenance dashboard:\u003C\u002Fstrong> daily, early morning.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architectural note:\u003C\u002Fstrong> none of these automations modifies the permanent zone of the knowledge base without explicit human validation. The entire pipeline is designed to be idempotent: an additional execution produces no undesirable side effects.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"recall-rag\">Recall RAG\u003C\u002Fh2>\n\n\u003Cp>The semantic recall engine allows querying the system's indexed memory via a natural-language query. It operates across three complementary search modes, merged by default into a hybrid mode.\u003C\u002Fp>\n\n\u003Ch3>Processing pipeline\u003C\u002Fh3>\n\n\u003Cp>The incoming query is processed according to the selected mode:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Semantic mode\u003C\u002Fstrong>: the query is vectorized by the embedding model (1024-dimensional vectors), then compared against the index using cosine distance. Results are sorted by descending similarity.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Lexical mode\u003C\u002Fstrong>: words of three characters or more are extracted and combined into an OR query. Matching is computed via text-rank scoring against content indexed in French. This mode calls no external API — no key is required. It reliably catches slugs and proper nouns that the embedding tends to blur.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Hybrid mode (default)\u003C\u002Fstrong>: the two preceding rankings are merged via \u003Cem>Reciprocal Rank Fusion\u003C\u002Fem> (RRF, parameter k=60). The combined score is \u003Ccode>score = Σ 1\u002F(60 + rank_i)\u003C\u002Fcode>. A document absent from one of the two modes receives a null score for that mode, without penalizing the other.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>A scope filter common to all three modes allows restricting the search to specific source categories: iteration history, scars, victories, reference memory, doctrine, ongoing work items, agent profiles, protocols, or all sources.\u003C\u002Fp>\n\n\u003Ch3>Re-ranking by importance and recency\u003C\u002Fh3>\n\n\u003Cp>After the initial selection, an over-fetch (by default three times the number of requested results) enables enriched re-ranking, applied to scars only. The formula is:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>final_score = similarity × (1 + importance\u002F10) × exp(−age_days \u002F 365)\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>Concrete effect: a recent high-importance scar is boosted by a factor of ~2×, while an old low-importance scar sees its score reduced to ~0.4×. This mechanism ensures that fresh, critical learnings surface to the top.\u003C\u002Fp>\n\n\u003Ch3>Anti-forgetting: recall counter increment\u003C\u002Fh3>\n\n\u003Cp>Each scar actually served has its recall counter incremented by 1 and its last-recalled timestamp updated. This operation is non-blocking: any error it raises is silent and does not disrupt the response. The archiving cron system only purges scars whose recall counter has remained at zero — those recalled at least once are preserved.\u003C\u002Fp>\n\n\u003Ch3>Score interpretation\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>In \u003Cstrong>semantic\u003C\u002Fstrong> mode: score > 0.75 → highly relevant; 0.65–0.75 → relevant; < 0.65 → requires manual review.\u003C\u002Fli>\n  \u003Cli>In \u003Cstrong>hybrid\u003C\u002Fstrong> mode (default): RRF scores operate on a different scale (typically < 0.1). Rely on \u003Cem>relative rank\u003C\u002Fem>, not absolute thresholds.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Recall command options\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Ccode>--k\u003C\u002Fcode>: number of results to return.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--mode lex|sem|hybrid\u003C\u002Fcode>: search mode (default: \u003Ccode>hybrid\u003C\u002Fcode>).\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--scope\u003C\u002Fcode>: source scope to query.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>--json\u003C\u002Fcode>: machine-readable JSON output.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Automatic trigger before creation\u003C\u002Fh3>\n\n\u003Cp>An automatic trigger fires before any new work item is created. It extracts the task title and runs a hybrid search for the four closest results. If the embedding API is unavailable (rate limit reached), lexical mode takes over. Results are injected into the diagnostic stream \u003Cem>before\u003C\u002Fem> creation, in a non-blocking manner. The objective is to avoid reinventing a scar, a doctrine, or a work item already on record — semantic search catches entries that the linear memory index was missing.\u003C\u002Fp>\n\n\u003Ch2 id=\"harness-evaluation-recall\">Recall evaluation harness\u003C\u002Fh2>\n\n\u003Cp>The recall non-regression system is built on an automated evaluation harness. It loads a \u003Cem>golden dataset\u003C\u002Fem> — a set of queries associated with the expected source identifiers, actually present in the vector index — and measures search quality without ever mutating recall counters (strict read-only mode).\u003C\u002Fp>\n\n\u003Ch3>Computed metrics\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Metric\u003C\u002Fth>\n      \u003Cth>Definition\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>recall@k\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fraction of expected sources found in the top-k, averaged across all queries.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>mrr@10\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Reciprocal rank of the first relevant result in the top-10 (0 if absent), averaged across queries.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>top1_accuracy\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fraction of queries for which the first result matches an expected source.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>The match between a returned result and an expected source is evaluated by substring inclusion (case-insensitive), making it robust to path prefix variations and identifier format differences.\u003C\u002Fp>\n\n\u003Ch3>API rate management\u003C\u002Fh3>\n\n\u003Cp>For modes that call the embedding API, a throttle delay of 1.3 seconds is introduced between each call. In the event of a rate-limit response (HTTP 429), exponential backoff is applied for up to five attempts. Lexical mode alone calls no API and requires no delay.\u003C\u002Fp>\n\n\u003Ch3>Commands and exit codes\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Mode \u002F option\u003C\u002Fth>\n      \u003Cth>Effect\u003C\u002Fth>\n      \u003Cth>Exit code\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(no option)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Gate mode: compares current metrics against the frozen baseline. Fails if regression exceeds tolerance.\u003C\u002Ftd>\n      \u003Ctd>0 (success) \u002F 1 (regression)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--baseline\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Freezes a new baseline by running evaluation in hybrid mode.\u003C\u002Ftd>\n      \u003Ctd>0\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--mode-sweep\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Compares all three modes (lexical, semantic, hybrid) for informational purposes, without gating.\u003C\u002Ftd>\n      \u003Ctd>0\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--tol <value>\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Acceptable regression tolerance (default: 0.05).\u003C\u002Ftd>\n      \u003Ctd>—\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--json\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Machine-readable output.\u003C\u002Ftd>\n      \u003Ctd>—\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(baseline absent)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Warning: no reference baseline found.\u003C\u002Ftd>\n      \u003Ctd>2\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Operational note\u003C\u002Fstrong>: the evaluation harness never modifies database state. It is designed to run in continuous integration with no side effects on anti-forgetting counters or on the metadata of indexed scars.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"boucle-apprentissage\">Learning Loop: Errors, Verifications, Suggestions and Lessons\u003C\u002Fh2>\n\n\u003Cp>This is the core of knowledge capitalization. An error (or a success) becomes a data point, then a concrete suggestion, then — after human validation — a rule loaded into all future sessions.\u003C\u002Fp>\n\n\u003Cp>The general flow unfolds in four stages:\u003C\u002Fp>\n\u003Col>\n  \u003Cli>A completed task (or a reproducible pattern) is recorded in the \u003Cstrong>lessons registry\u003C\u002Fstrong>.\u003C\u002Fli>\n  \u003Cli>A suggestion engine reads entries marked as learned and produces a structured proposal.\u003C\u002Fli>\n  \u003Cli>A human operator validates, rejects, or modifies each proposal from the dashboard.\u003C\u002Fli>\n  \u003Cli>The validated rule is applied to the appropriate destination and becomes active from the next session onward.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>4.1 The Lessons Registry\u003C\u002Fh3>\n\n\u003Cp>The lessons registry is the \u003Cstrong>single source of truth\u003C\u002Fstrong> for all knowledge capitalization. Each entry documents either a resolved failure or a reproducible success. The key fields are:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Entry type\u003C\u002Fstrong> (\u003Ccode>kind\u003C\u002Fcode>): distinguishes failures, successes, and a few legacy categories (convention, pattern, bug). The vast majority of entries are resolved failures.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>The lesson\u003C\u002Fstrong> (\u003Ccode>check_added\u003C\u002Fcode>): for a failure, what was added to prevent recurrence; for a success, the pattern to reproduce.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Importance score\u003C\u002Fstrong>: automatically computed by a language model at recording time, via the AI routing engine. Non-blocking — if the model is unavailable, the score is populated during the next nightly maintenance run. Importance weights recall frequency (a bonus is granted to the most critical entries).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Learnability flag\u003C\u002Fstrong> (\u003Ccode>learnable\u003C\u002Fcode>): gateway for the suggestion engine. Only entries marked \u003Ccode>true\u003C\u002Fcode> are processed.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Best practice — recording a success:\u003C\u002Fstrong> use the dedicated skill (\u003Ccode>\u002Fvictoire\u003C\u002Fcode>) rather than direct SQL. The \u003Ccode>tags\u003C\u002Fcode> field must be supplied as a PostgreSQL literal array (\u003Ccode>\"{a,b,c}\"\u003C\u002Fcode>), not a Python list — a lesson learned in production.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.2 The Suggestion Engine: From Lesson to Proposal\u003C\u002Fh3>\n\n\u003Cp>The suggestion engine reads the lessons registry, filters entries marked as learnable and not yet processed, then calls a language model to produce a structured proposal. The pipeline in detail:\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Selection\u003C\u002Fstrong>: learnable entries absent from the proposal log, sorted by descending importance then by date, capped at 50 per run.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>PII scrubbing\u003C\u002Fstrong> before sending to the model. The model output is also filtered before insertion — defense in depth.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>LLM call\u003C\u002Fstrong>: the model returns a JSON object containing the target destination, the suggestion text, and before\u002Fafter diffs (\u003Cem>diff_before\u003C\u002Fem> \u002F \u003Cem>diff_after\u003C\u002Fem>).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Insertion\u003C\u002Fstrong> into the proposal log with status \u003Ccode>pending\u003C\u002Fcode>. The operation is idempotent; a short delay between calls prevents API rate saturation.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>The \u003Cstrong>six possible destinations\u003C\u002Fstrong> for a proposal:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Destination\u003C\u002Fth>\n      \u003Cth>Meaning\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Orchestrator directive\u003C\u002Ftd>\n      \u003Ctd>Rule to add or modify in the agent's main directive file\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Hooks configuration\u003C\u002Ftd>\n      \u003Ctd>Permission parameter, hooks, or environment variables\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Persistent note (level 1)\u003C\u002Ftd>\n      \u003Ctd>Immediate reflex injected into each briefing via current memory\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Conceptual inbox\u003C\u002Ftd>\n      \u003Ctd>New Zettelkasten note (concept or doctrine under maturation)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Skill\u003C\u002Ftd>\n      \u003Ctd>Creation or improvement of an invocable skill\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Project or tool\u003C\u002Ftd>\n      \u003Ctd>New automated project or utility script\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>4.3 Human Validation and Audit Log\u003C\u002Fh3>\n\n\u003Cp>No proposal is applied automatically. The dashboard exposes three operations:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Browse the feed\u003C\u002Fstrong> (read): list of pending proposals.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Apply\u003C\u002Fstrong> (write): the proposal moves to status \u003Ccode>applied\u003C\u002Fcode> and an entry is created in the audit log with the operator identifier and a snapshot of the diff.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Reject or modify\u003C\u002Fstrong> (write): the proposal moves to status \u003Ccode>refused\u003C\u002Fcode> or \u003Ccode>modified\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The audit log retains for each action: the reference to the proposal, the decision author, the timestamp, and the snapshot of the applied diff.\u003C\u002Fp>\n\n\u003Ch3>4.4 Post-Project Lessons (Structured Debrief)\u003C\u002Fh3>\n\n\u003Cp>In addition to the scar → suggestion loop, a post-project debrief tool allows lessons to be extracted after a project is closed. It is invocable by a dedicated agent via the corresponding skill.\u003C\u002Fp>\n\n\u003Cp>The mechanism loads a full audit bundle: project metadata, work items, tasks, recent iterations, linked scars, and truncated execution logs. Input volume is capped to stay within model limits.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>ROI guardrail\u003C\u002Fstrong>: a project with fewer than three work items is rejected by default (overridable via an explicit flag).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Default model\u003C\u002Fstrong>: the LLM call goes through the Claude binary via a read-only wrapper (tools \u003Ccode>Read\u003C\u002Fcode>, \u003Ccode>Grep\u003C\u002Fcode>, \u003Ccode>Glob\u003C\u002Fcode> only), with two attempts and a pause between them.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Fallback\u003C\u002Fstrong>: if the binary is absent or an alternative mode is explicitly requested, a second provider is used, with up to three attempts and exponential backoff.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Prompt fixed in five sections\u003C\u002Fstrong>: estimated vs. actual token delta, top 3 recurring errors, top 3 patterns to standardize, one candidate doctrine, one tool to create.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Output\u003C\u002Fstrong>: a lesson note in Zettelkasten format, with status \u003Ccode>draft\u003C\u002Fcode>, deposited in the Vault inbox.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Promotion\u003C\u002Fstrong>: never automatic. The operator manually moves the note to permanent memory (RAG) or current memory (reflex) after review.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.5 Pattern Detection and Skill Proposals\u003C\u002Fh3>\n\n\u003Cp>A second pipeline, distinct from the scar loop, transforms recurring patterns observed in work iterations into proposals for invocable skills. This is the capability self-improvement mechanism of the ecosystem.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>Task iteration log (completed actions\u002Fobservations)\n      │ weekly scan (Sunday 04:00 UTC)\n      ▼\nPattern detector (LLM-first via subprocess, 3 min timeout)\n      │ identifies patterns present in ≥ 3 tasks\n      │ checks for duplicates (existing skill or already-pending proposal)\n      │ INSERT proposal (status='pending', source iterations, LLM evidence)\n      ▼\nSkill proposal dashboard ── HUMAN validation (founder)\n      │ list \u002F validate \u002F reject\n      ▼\nPromotion to the native skills registry (invocable via \u002F<slug>)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Operational detector\u003C\u002Fstrong> (weekly cron, Sunday 04:00 UTC): loads recent iterations with status \u003Ccode>done\u003C\u002Fcode> or \u003Ccode>pass\u003C\u002Fcode>, passes the batch to the language model which identifies patterns warranting a skill, then inserts proposals into the log after deduplication. Flags \u003Ccode>--dry-run\u003C\u002Fcode> and \u003Ccode>--limit\u003C\u002Fcode> available.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Proposal monitor\u003C\u002Fstrong> (hourly cron): alerts the founder if the number of pending proposals exceeds a configurable threshold. One-hour cool-down to prevent duplicate alerts. Statistics include totals by status, average validation time, and additions in the last hour. The alert is routed through the central email facade — never via a direct SMTP connection.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Human validation\u003C\u002Fstrong>: a dedicated dashboard page lists proposals and allows each to be validated or rejected. A validated proposal is promoted to the native skills registry.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Not to be confused:\u003C\u002Fstrong> the operational detector described above is the only one that actually feeds the proposal log. A second skeleton module exists (Sunday cron 03:00 UTC) whose docstring explicitly states that it scans and logs without yet creating proposals — the detection logic is forthcoming. It is not this module that produces active proposals.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.6 Related Automations in the Learning Loop\u003C\u002Fh3>\n\n\u003Ch4>Nightly Consolidation (Maintenance Loop)\u003C\u002Fh4>\n\n\u003Cp>A nightly maintenance automation (daily execution at 04:00 UTC) consolidates learning across ten distinct features. Each feature resolves its language model from the central AI router. The absolute cross-cutting rule: \u003Cstrong>no automatic promotion\u003C\u002Fstrong> from the inbox to permanent or current memory — all promotion remains human-gated. No-write mode (\u003Ccode>--dry-run\u003C\u002Fcode>) is the default.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Repeated scar detection\u003C\u002Fstrong>: compares new entries from the day against past entries via vector similarity. If at least two similar occurrences are found, a promotion draft is generated in the inbox.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Session compaction\u003C\u002Fstrong>: analyzes the day's session logs (maximum 30, skipping those containing secrets detected by regex), extracts 3 to 5 durable facts (decision, delivery, scar, finding) and records them in the daily journal. In dry-run mode, no LLM call is made.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Morning summary\u003C\u002Fstrong>: a digest email sent via the central email facade, only if drafts or journals were produced overnight.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Documentary divergence audit\u003C\u002Fstrong>: checks canonical pricing tiers, scans obsolete patterns defined in a configuration file, and flags numerically dense tables that would benefit from database storage. Discrepancies are deposited as drafts in the inbox.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Nightly reflection\u003C\u002Fstrong>: for each active agent, the 20 most salient resolved scars feed an LLM that produces 3 introspective questions and 3 abstractions, deposited as drafts. In dry-run mode, only the count of eligible agents is performed.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Forgetting curve\u003C\u002Fstrong>: archives (without deletion) very old scars with no recorded recall, capped at 200 per run. Archiving renders them invisible to the semantic recall engine but remains reversible.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Project proactivity\u003C\u002Fstrong>: monitors projects with active external contacts, automatically links corresponding inbound and outbound emails, and submits the reconstructed thread to an LLM that classifies the situation: to archive, action required, awaiting external response, or no action needed.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Internal obsolescence audit\u003C\u002Fstrong>: evaluates projects inactive beyond a configurable day threshold, computes their obsolescence signals, and produces a verdict (still relevant \u002F possibly obsolete \u002F archiving recommended) persisted in the obsolescence log. Non-\"still relevant\" verdicts surface in the morning email for operator decision.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Persona drift audit\u003C\u002Fstrong>: runs only on the 1st of each month. Compares each agent's current profile against its reference configuration, computes a drift score, persists it in history, and surfaces the top 3 most-drifted agents in the morning email.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Daily cost ticket\u003C\u002Fstrong>: aggregates the previous day's AI costs by agent, compares against the 7-day average, and sends an email alert if the delta exceeds 20% for a given agent.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch4>Scar Classifier\u003C\u002Fh4>\n\n\u003Cp>A qualification automation classifies scars that have not yet been categorized. The language model returns a structured object containing:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>A proposed category for the error type.\u003C\u002Fli>\n  \u003Cli>A re-estimated severity (updated if different from the current value).\u003C\u002Fli>\n  \u003Cli>A confidence index and a rationale.\u003C\u002Fli>\n  \u003Cli>Proposed tags.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong> the learnability flag (\u003Ccode>learnable\u003C\u002Fcode>) is not written directly to the corresponding column by this automation. It is serialized as a prefix in the rationale field in the form \u003Ccode>learnable:true|false\u003C\u002Fcode> — documented and intentional behavior.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch4>Current Memory Hygiene\u003C\u002Fh4>\n\n\u003Cp>A monthly consolidation pipeline (first of the month, 00:00 UTC, with anti-overlap lock) cleans current memory in four sequential steps:\u003C\u002Fp>\n\u003Col>\n  \u003Cli>\u003Cstrong>Environment validation\u003C\u002Fstrong>: checks that required environment variables and paths are accessible. On failure, the pipeline halts without executing subsequent steps.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Dead link detection\u003C\u002Fstrong>: scans the memory index file and produces a report of broken references. This step runs \u003Cstrong>even in dry-run mode\u003C\u002Fstrong> and may write reports to disk.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Obsolete file archiving\u003C\u002Fstrong>: moves files marked as decommissioned or obsolete to an off-repository archive area and removes the corresponding references from the index.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Fingerprint deduplication\u003C\u002Fstrong>: identifies and removes strictly identical files (SHA-256 fingerprint).\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>A JSON report is generated on each run, indicating for each step the status, duration, and any errors. Exit codes are:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Code\u003C\u002Fth>\n      \u003Cth>Meaning\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>0\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Pipeline completed successfully (or validation-only succeeded)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>1\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Environment validation failed — no steps executed\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>2\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Fatal error in a step — pipeline interrupted\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>3\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Dry-run mode completed — no actual changes made\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Available flags: \u003Ccode>--dry-run\u003C\u002Fcode> (steps 3 and 4 bypassed or simulated, step 2 always active), \u003Ccode>--validate-only\u003C\u002Fcode> (halt after step 1).\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Important:\u003C\u002Fstrong> the training module documenting this pipeline (\u003Cem>consolidation training material\u003C\u002Fem>) is hard-read by the non-regression quiz. Deleting it without first updating the quiz would cause at least four checks to fail and would block the validation pipeline.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch4>Current Memory Observability\u003C\u002Fh4>\n\n\u003Cp>A daily automation (06:00 UTC) records a 90-day time series: file count, total size, number of lines in the index, dead links, and orphaned references. Alerts are emitted to the monitoring system if configured thresholds are exceeded. Flags: \u003Ccode>--json\u003C\u002Fcode>, \u003Ccode>--dry-run\u003C\u002Fcode>.\u003C\u002Fp>\n\n\u003Ch3>4.7 User Model Recall (Structured Channel)\u003C\u002Fh3>\n\n\u003Cp>Semantic vector recall is not the only memory channel. A dedicated module loads the \u003Cstrong>user model\u003C\u002Fstrong> from the database — a structured profile in JSONB dimensions — and injects it into agent briefings. This recall is \u003Cstrong>targeted and structured\u003C\u002Fstrong>, not vectorial.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Available dimensions\u003C\u002Fstrong>: communication style, schedules, profile, skills, history, preferences, strictly private data reserved for the primary operator.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Composite slice \u003Ccode>core\u003C\u002Fcode>\u003C\u002Fstrong>: aggregates communication style, cognitive preferences, and appointment slots, calibrated for briefing injection (under 1,000 tokens). Never includes reserved private data.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>API\u003C\u002Fstrong>: \u003Ccode>get_profile(slice=…)\u003C\u002Fcode> returns a dictionary; \u003Ccode>format_for_briefing(…)\u003C\u002Fcode> returns text ready for injection. A command-line interface allows these slices to be queried directly, with \u003Ccode>--json\u003C\u002Fcode> and \u003Ccode>--format-briefing\u003C\u002Fcode> options.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"boucle-maintenance-nocturne\">Nightly Maintenance Loop\u003C\u002Fh2>\n\n\u003Cp>The nightly maintenance loop forms the meta-layer above the learning cycles: an orchestrator that runs every night, inspects documentation fidelity against the codebase, measures overall system health, mechanically repairs dead references, triggers autonomous regeneration of derived chapters, and then pushes a sanitized snapshot to synedre.com.\u003C\u002Fp>\n\n\u003Cp>The step sequence executes in the following order:\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Initial inspection\u003C\u002Fstrong> — the drift detector measures the gap between documentation and code.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Coverage\u003C\u002Fstrong> — the blind-spot detector identifies undocumented areas.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Repair\u003C\u002Fstrong> — the dead-reference fixer mechanically processes broken links.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Deep regeneration\u003C\u002Fstrong> — the gated deep-rewrite step rebuilds derived chapters.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Proposal\u003C\u002Fstrong> — a staging cycle produces drafts in the staging area.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Documentation publishing\u003C\u002Fstrong> — chapters pass anti-leak, anti-drift, and style gates before activation.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Re-inspection\u003C\u002Fstrong> — the drift detector performs a \u003Cem>second\u003C\u002Fem> measurement after regeneration, so that the health report reflects the actual post-regeneration state rather than the state at the start of the night.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Health report\u003C\u002Fstrong> — the five vital dimensions are aggregated and a care note is written.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Snapshot publishing\u003C\u002Fstrong> — a sanitized snapshot is pushed to synedre.com (best-effort mode).\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cp>Automatic triggering occurs every day at 05:00 UTC via the system task scheduler. Execution logs are retained in the log directory dedicated to this loop.\u003C\u002Fp>\n\n\u003Ch3>Loop Orchestrator\u003C\u002Fh3>\n\n\u003Cp>The orchestrator is the single entry point of the nightly loop. It embeds several global safeguards:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Database circuit breaker\u003C\u002Fstrong>: if the entry corresponding to this loop in the automation configuration table indicates \u003Ccode>active = 0\u003C\u002Fcode>, execution halts silently.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Overlap prevention lock\u003C\u002Fstrong>: a temporary lock file bearing the current PID is created at startup. If a process identified by that PID is already active, the loop stops immediately. The lock is always removed at the end of execution, even if an exception occurs in a sub-step.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Semantic return codes\u003C\u002Fstrong>: codes 1 and 2 signal \"drift present\" and \"critical health\" respectively — these are informational statuses, not fatal failures. The only blocking non-zero exit case is an actual crash of a sub-step.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Daily report\u003C\u002Fstrong>: at the end of the loop, an idempotent record is inserted into the morning report table, summarizing the return code of each step.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The available control options are as follows:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Option\u003C\u002Fth>\n      \u003Cth>Effect\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cem>(none)\u003C\u002Fem>\u003C\u002Ftd>\n      \u003Ctd>Full execution in live mode\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--dry-run\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>All sub-steps operate in simulation; the DB circuit breaker is bypassed\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--no-deep\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Skips the deep regeneration step\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--deep-max N\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Hard cap on the number of chapters processed in depth (default: 4); actual convergence remains bounded by the time budget\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Ccode>--deep-budget-sec N\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Maximum time budget in seconds for deep regeneration (default: 4,500 s \u002F 75 min); no new chapter is started beyond this threshold\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Multi-dimensional Health Report\u003C\u002Fh3>\n\n\u003Cp>The health report component aggregates five vital dimensions into an idempotent snapshot per execution date, visible in the morning dashboard.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Dimension\u003C\u002Fth>\n      \u003Cth>What is measured\u003C\u002Fth>\n      \u003Cth>Critical threshold\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Proprioception\u003C\u002Ftd>\n      \u003Ctd>Documentation drift table\u003C\u002Ftd>\n      \u003Ctd>≥ 1 chapter with a dead reference\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Coverage\u003C\u002Ftd>\n      \u003Ctd>Documentation coverage table\u003C\u002Ftd>\n      \u003Ctd>≥ 1 uncovered unit\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Debt\u003C\u002Ftd>\n      \u003Ctd>Prioritized task backlog\u003C\u002Ftd>\n      \u003Ctd>≥ 1 maximum-priority task pending\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Learning\u003C\u002Ftd>\n      \u003Ctd>Materialized view of scar indicators\u003C\u002Ftd>\n      \u003Ctd>Refresh absent for more than 3 days\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Automations\u003C\u002Ftd>\n      \u003Ctd>Cron error log + automation registry\u003C\u002Ftd>\n      \u003Ctd>≥ 1 script in the mothership scope unintentionally disabled\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>\u003Cstrong>Monitored automation scope\u003C\u002Fstrong>: only automations belonging to the mothership scope and marked active are taken into account. Automations belonging to a client tenant or intentionally disabled do not degrade the overall health metric.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Care note\u003C\u002Fstrong>: the Nightingale agent (Health Guardian) reads the aggregated vital signs and writes a care note of at most three sentences, in English. This note is stored in the JSON field of the global health report record. If the agent is unavailable, the field remains empty without blocking the rest of the loop.\u003C\u002Fp>\n\n\u003Cp>Available options: \u003Ccode>--dry-run\u003C\u002Fcode> (displays the report without writing), \u003Ccode>--no-voice\u003C\u002Fcode> (metrics only, without care note). Exit codes: 0 = nominal, 1 = warning, 2 = critical.\u003C\u002Fp>\n\n\u003Ch3>Sanitized Snapshot Publishing to synedre.com\u003C\u002Fh3>\n\n\u003Cp>This component reads in read-only mode the latest health and drift snapshots from the mothership VPS, applies an automatic sanitization pass (removal of IP addresses, internal paths, and client identifiers), then pushes a JSON snapshot to the synedre.com VPS database.\u003C\u002Fp>\n\n\u003Cp>Safeguards:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>No writes are performed on the mothership database: the connection is strictly read-only.\u003C\u002Fli>\n  \u003Cli>The destination table is created idempotently on first run if it does not exist.\u003C\u002Fli>\n  \u003Cli>Only one snapshot is retained per date (UPSERT on the date key).\u003C\u002Fli>\n  \u003Cli>An error during the push to the synedre.com VPS generates an error log and a return code of 2, but \u003Cstrong>does not interrupt\u003C\u002Fstrong> the nightly loop (best-effort mode).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The snapshot exposes overall and per-dimension health (scores, statuses, sanitized summaries), the list of drifting chapters (with their scores), and the Nightingale agent's care note. These data feed the maintenance dashboard accessible from the documentation section of synedre.com.\u003C\u002Fp>\n\n\u003Cp>Options: \u003Ccode>--dry-run\u003C\u002Fcode> (displays the JSON without writing). Exit codes: 0 = nominal, 1 = mothership read error, 2 = push error to synedre.com.\u003C\u002Fp>\n\n\u003Ch2 id=\"facade-ia\">Centralized AI Facade\u003C\u002Fh2>\n\n\u003Cp>All calls to artificial intelligence services within the system pass through a single facade. This policy ensures that any change of provider, model, or key is made in one place, without touching the business automations.\u003C\u002Fp>\n\n\u003Cp>Two canonical functions are exposed:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Vectorization\u003C\u002Fstrong> (\u003Ccode>embed\u003C\u002Fcode>): transforms a text into a floating-point vector, used for semantic search and memory recall.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Completion\u003C\u002Fstrong> (\u003Ccode>complete\u003C\u002Fcode>): sends a mission and a context to a language model and returns the textual or JSON response.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Database-driven Routing\u003C\u002Fh3>\n\n\u003Cp>When the provider parameter is set to \u003Ccode>auto\u003C\u002Fcode>, the facade reads the AI routing table in the database to determine which provider and model to use according to the requested functionality. This table exposes a global fallback row as well as one row per named functionality, merged with the fallback.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Key advantage\u003C\u002Fstrong>: switching provider amounts to modifying a single row in the database — no redeployment is required. The nightly loop re-reads the configuration at each execution. If the database is unreachable or empty, canonical default values take over (fail-soft mode).\u003C\u002Fp>\n\n\u003Cp>Default providers and models:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Usage\u003C\u002Fth>\n      \u003Cth>Supported providers\u003C\u002Fth>\n      \u003Cth>Default model\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Vectorization\u003C\u002Ftd>\n      \u003Ctd>Mistral, Voyage, OpenAI\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>mistral-embed\u003C\u002Fcode> \u002F \u003Ccode>voyage-3\u003C\u002Fcode> \u002F \u003Ccode>text-embedding-3-small\u003C\u002Fcode>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Completion\u003C\u002Ftd>\n      \u003Ctd>Anthropic (Claude), Mistral, OpenAI\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>claude-haiku-4-5\u003C\u002Fcode> \u002F \u003Ccode>mistral-large-latest\u003C\u002Fcode> \u002F \u003Ccode>gpt-4o-mini\u003C\u002Fcode>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>The canonical vectorization provider is Mistral, chosen for European data sovereignty reasons.\u003C\u002Fp>\n\n\u003Ch3>Anthropic Completion: Two Billing Paths\u003C\u002Fh3>\n\n\u003Cp>The Anthropic provider has two distinct call paths, selected automatically at runtime:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Direct API call\u003C\u002Fstrong>: if the Anthropic provider API key is present in the environment or passed as a parameter, the facade calls the REST API directly. This path is used for clients with their own Console account (separate billing). It includes retry logic on transient errors (code 429 or 5xx), consumption tracking in the database (tokens, estimated cost, per-tenant billing label), and resolution of short aliases (\u003Ccode>haiku\u003C\u002Fcode>, \u003Ccode>sonnet\u003C\u002Fcode>, \u003Ccode>opus\u003C\u002Fcode>) to full model identifiers.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Call via the internal agent\u003C\u002Fstrong>: in the absence of an API key in the environment, the facade delegates to the Gauss agent (neutral persona), which uses the internal plan. This path is reserved for internal mothership use.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Mistral Completion\u003C\u002Fh3>\n\n\u003Cp>Mistral calls go through the REST API with zero temperature (deterministic outputs) and JSON mode if requested. The facade makes up to three attempts in case of a transient error (code 429 or 5xx) with increasing wait time between each attempt. Non-transient 4xx errors (invalid parameter, permanently exceeded quota, etc.) are considered permanent and do not trigger a retry. Any \u003Ccode>None\u003C\u002Fcode> return is logged to the error output.\u003C\u002Fp>\n\n\u003Ch3>Consumption Tracking\u003C\u002Fh3>\n\n\u003Cp>Each completion performed via the Anthropic direct API is traced in the database: provider, model, functional label, number of input and output tokens, estimated cost in USD. This mechanism enables per-tenant chargebacks. The database write is wrapped in a protection block: a tracking error never blocks the completion itself.\u003C\u002Fp>\n\n\u003Ch3>API Keys and Security\u003C\u002Fh3>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Absolute rule\u003C\u002Fstrong>: no key or secret value appears in this documentation or in the versioned repository. All keys are read from environment files excluded from version control.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>The facade reads the following environment variables at startup:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Provider\u003C\u002Fth>\n      \u003Cth>Environment variable\u003C\u002Fth>\n      \u003Cth>Usage\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Mistral\u003C\u002Ftd>\n      \u003Ctd>Mistral API key\u003C\u002Ftd>\n      \u003Ctd>Mistral vectorization and completion\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Voyage\u003C\u002Ftd>\n      \u003Ctd>Voyage API key\u003C\u002Ftd>\n      \u003Ctd>Voyage vectorization\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>OpenAI\u003C\u002Ftd>\n      \u003Ctd>OpenAI API key\u003C\u002Ftd>\n      \u003Ctd>OpenAI vectorization and completion\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Anthropic\u003C\u002Ftd>\n      \u003Ctd>Anthropic API key\u003C\u002Ftd>\n      \u003Ctd>Direct API completion (client path)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Database\u003C\u002Ftd>\n      \u003Ctd>Main database password\u003C\u002Ftd>\n      \u003Ctd>Connection to the mothership persistence engine\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Loading is performed at startup from the environment files located at the root of the repository, via \u003Ccode>os.environ.setdefault\u003C\u002Fcode> (values already present in the system environment are not overwritten).\u003C\u002Fp>\n\n\u003Ch2 id=\"connexion-base-de-donnees\">Database Connection\u003C\u002Fh2>\n\n\u003Cp>The mothership persistence engine is a containerized PostgreSQL service. Python automations connect to it by specifying the correct database name and the schema dedicated to the mothership via the \u003Ccode>search_path\u003C\u002Fcode> option. The port exposed on the host machine differs from the container's internal port to avoid any collision.\u003C\u002Fp>\n\n\u003Cp>All read accesses (semantic recall, vector synchronization) as well as write accesses (logs, health reports, daily reports) use the same connection string, guaranteeing a single configuration point for all automations.\u003C\u002Fp>\n\u003Ch2 id=\"artefacts-recap\">Component Summary Table\u003C\u002Fh2>\n\n\u003Cp>This table lists all components that make up the learning and memory loop of Synedre OS, organized by functional role.\u003C\u002Fp>\n\n\u003Ch3>Indexing and Memory Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Note Indexer\u003C\u002Ftd>\n      \u003Ctd>Periodic task (every 15 min)\u003C\u002Ftd>\n      \u003Ctd>Transforms notes from the documentary brain into queryable relational entries.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Vector Synchronizer\u003C\u002Ftd>\n      \u003Ctd>Nightly task + online trigger\u003C\u002Ftd>\n      \u003Ctd>Computes and stores vector representations (1024 dimensions) for all sources; incremental mode at night, on-demand single recompute during a reasoning cycle.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Vector Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stores semantic vectors with a cosine HNSW index for approximate nearest-neighbor search.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Indexed Notes Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Relational representation of the documentary Zettelkasten, populated by the note indexer.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Golden Recall Dataset\u003C\u002Ftd>\n      \u003Ctd>Reference file\u003C\u002Ftd>\n      \u003Ctd>Reference question-answer set used by the recall evaluation harness.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Recall Baseline\u003C\u002Ftd>\n      \u003Ctd>Frozen reference file\u003C\u002Ftd>\n      \u003Ctd>Frozen reference scores (recall@k, MRR, top-1) serving as a non-regression threshold.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Recall and Evaluation Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Recall Engine\u003C\u002Ftd>\n      \u003Ctd>RAG\u003C\u002Ftd>\n      \u003Ctd>Combines lexical, semantic, and hybrid search (reciprocal rank fusion, k=60); selects top-K results, re-ranks them, and increments their usage score.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Recall Evaluation Harness\u003C\u002Ftd>\n      \u003Ctd>Quality assurance\u003C\u002Ftd>\n      \u003Ctd>Measures recall@k, MRR@10, and top-1 precision against the golden dataset; blocks any regression relative to the frozen baseline.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-Project Recall\u003C\u002Ftd>\n      \u003Ctd>Event hook (triggered before creation)\u003C\u002Ftd>\n      \u003Ctd>Executes a hybrid top-4 recall before any project structure is created; non-blocking, enriches the agent's context without interrupting the flow.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>User Recall\u003C\u002Ftd>\n      \u003Ctd>Personalization\u003C\u002Ftd>\n      \u003Ctd>Leverages the multidimensional user model to produce contextualized briefings for agents.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>User Model Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stores the JSONB dimensions of each user's profile, used to personalize recall briefings.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Nightly Maintenance Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Nightly Maintenance Orchestrator\u003C\u002Ftd>\n      \u003Ctd>Nightly task (around 5 a.m.)\u003C\u002Ftd>\n      \u003Ctd>Coordinates the full regeneration loop: perception → coverage → repair → regeneration → proposal → documentation publishing → re-perception → care → publishing.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Health Check\u003C\u002Ftd>\n      \u003Ctd>Diagnostic\u003C\u002Ftd>\n      \u003Ctd>Assesses five system health dimensions and records the result in the tracking tables; also feeds the team's daily log.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Public Health Synchronizer\u003C\u002Ftd>\n      \u003Ctd>Sanitized export\u003C\u002Ftd>\n      \u003Ctd>Produces a sanitized snapshot (free of sensitive data) of health and drift indicators, synchronized to the public VPS.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Health Snapshot Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Historical record of health assessments by date and dimension (five dimensions plus overall score).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Public Snapshot Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Day-by-day sanitized snapshots, replicated to the public VPS for exposure on synedre.com.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Nightly Consolidation Engine\u003C\u002Ftd>\n      \u003Ctd>Task every 4 h\u003C\u002Ftd>\n      \u003Ctd>Consolidates ten long-term memory features; runs in simulation mode by default (no writes without explicit validation).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Monthly Memory Hygiene\u003C\u002Ftd>\n      \u003Ctd>Monthly task\u003C\u002Ftd>\n      \u003Ctd>Cleans the memory corpus: removes dead links, archives obsolete entries, deduplicates by content fingerprint; produces a dated consolidation report.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Memory Metrics\u003C\u002Ftd>\n      \u003Ctd>Task every 6 h\u003C\u002Ftd>\n      \u003Ctd>Computes memory volume and quality indicators; maintains a 90-day time series and emits alerts when thresholds are crossed.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Memory Metrics Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Time series of memory indicators with a 90-day retention window.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Learning and Qualification Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Post-Project Reflex\u003C\u002Ftd>\n      \u003Ctd>Retrospective\u003C\u002Ftd>\n      \u003Ctd>Produces a structured lesson at the end of each project and injects it into the documentary brain's inbox; uses an advanced language model by default, with automatic fallback to an alternative model.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Learning Suggestion Engine\u003C\u002Ftd>\n      \u003Ctd>LLM engine\u003C\u002Ftd>\n      \u003Ctd>Analyzes lessons flagged as learnable and generates improvement suggestions pending human validation.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Lesson Qualifier\u003C\u002Ftd>\n      \u003Ctd>LLM classification\u003C\u002Ftd>\n      \u003Ctd>Assigns each lesson an error type, severity level, confidence score, and rationale; prefixes learnable lessons to distinguish them in the queue.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Lessons Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Stores lessons (failures and wins), their importance, and their learnable status.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Learning Suggestions Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Queue of LLM-generated suggestions pending team validation.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Learning Audit Log\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Immutable trace of every suggestion that has been validated and applied.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Pattern Detection and Skill Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Emerging Skill Detector\u003C\u002Ftd>\n      \u003Ctd>Weekly task (Sunday 4 a.m.)\u003C\u002Ftd>\n      \u003Ctd>Analyzes recurrent iteration patterns and submits new skill proposals for human validation. \u003Cstrong>Functional\u003C\u002Fstrong> component: proposals are actually inserted into the database.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Proposal Monitor\u003C\u002Ftd>\n      \u003Ctd>Hourly task\u003C\u002Ftd>\n      \u003Ctd>Emits an alert to the founding team when the number of pending skill proposals exceeds a configurable threshold.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pattern Detection Skeleton\u003C\u002Ftd>\n      \u003Ctd>Weekly task (Sunday 3 a.m.) — inactive MVP\u003C\u002Ftd>\n      \u003Ctd>Traverses and logs patterns without creating proposals. Component under development, distinct from the emerging skill detector.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Skill Proposals Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Queue of new skill proposals pending human validation.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Native Skills Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Registry of the system's active skills; target for promotion of validated proposals.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Skill Validation Interface\u003C\u002Ftd>\n      \u003Ctd>User interface (hub dial)\u003C\u002Ftd>\n      \u003Ctd>Allows the team to validate or reject skill proposals directly from the control hub.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Cross-Cutting Components\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Type\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>AI Facade\u003C\u002Ftd>\n      \u003Ctd>Abstraction\u003C\u002Ftd>\n      \u003Ctd>Single entry point for all inference operations (embedding and completion); routes each call to the appropriate provider and model via a central routing table; supports two access paths to the primary model (direct API and CLI interface); logs every call for consumption tracking and chargeback.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>AI Routing Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Single source of truth defining, for each feature, the embedding provider, completion provider, target model, and extended parameters in structured format.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>AI Consumption Table\u003C\u002Ftd>\n      \u003Ctd>Table\u003C\u002Ftd>\n      \u003Ctd>Records each API call with the provider, model, metering label, input and output token counts, and estimated cost in dollars; used for per-tenant billing.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>User Recall Interface\u003C\u002Ftd>\n      \u003Ctd>Skill (user interface)\u003C\u002Ftd>\n      \u003Ctd>Allows a user to explicitly query the system's memory through a dedicated interface.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Retrospective Interface\u003C\u002Ftd>\n      \u003Ctd>Skill (user interface)\u003C\u002Ftd>\n      \u003Ctd>Manually triggers the production of a post-project lesson.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Win Interface\u003C\u002Ftd>\n      \u003Ctd>Skill (user interface)\u003C\u002Ftd>\n      \u003Ctd>Records and highlights notable successes in the memory corpus.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architecture note:\u003C\u002Fstrong> all of these components form a closed self-improvement loop. Lessons feed suggestions, suggestions feed skills, skills improve future projects, and projects produce new lessons. The AI facade and the central routing table ensure that any change in model or provider propagates uniformly across the entire loop without modifying individual components.\u003C\u002Fp>\n\u003C\u002Fblockquote>",{"slug":14,"chapterNum":15,"title":16,"titleEn":17},"email","07","Inbox hub & Atlas Inbox — deux pipelines email","Inbox hub & Atlas Inbox — two email pipelines",{"slug":19,"chapterNum":20,"title":21,"titleEn":22},"deploy","09","Déploiement & infrastructure","Deployment & infrastructure",{"chapters":24},[25,32,39,46,53,60,67,70,71,74,81],{"slug":26,"chapterNum":27,"title":28,"titleEn":29,"summary":30,"summaryEn":31},"overview","01","Vue d'ensemble du harness agentique","Agentic harness overview","Le harness transforme une demande (courriel, console, cron) en action déployée en enchaînant classification, spawn LLM via pseudo-TTY, validation qualité à deux niveaux et boucle d'apprentissage, le tout sans état métier hors base de données.","The harness transforms a request (email, console, cron) into a deployed action by chaining intent classification, pseudo-TTY LLM spawn, two-level quality validation, and a learning loop — with no business state stored outside the database.",{"slug":33,"chapterNum":34,"title":35,"titleEn":36,"summary":37,"summaryEn":38},"data-layer","02","La couche données","The Data Layer","Décrit l'architecture données de Synedre OS : une base PostgreSQL unique (un composant interne\u002Fun composant interne), les trois chemins d'accès (Nuxt\u002FNitro, Python agentique, Drizzle ORM DDL), les familles de tables par préfixe et les conventions de nommage associées.","Describes the Synedre OS data architecture: a single PostgreSQL database (un composant interne\u002Fun composant interne), the three access paths (Nuxt\u002FNitro, agentic Python, Drizzle ORM DDL), the table families by prefix, and the associated naming conventions.",{"slug":40,"chapterNum":41,"title":42,"titleEn":43,"summary":44,"summaryEn":45},"agentic-core","03","Le cœur agentique : Atlas et les agents","The Agentic Core: Atlas and the Agents","Décrit l'architecture du moteur agentique : classification LLM des emails entrants, spawn headless de Claude Code via pseudo-TTY, injection des personas agents et orchestration post-spawn (deploy, QA, récap).","Describes the architecture of the agentic engine: LLM classification of incoming emails, headless spawning of Claude Code via pseudo-TTY, injection of agent personas, and post-spawn orchestration (deploy, QA, recap).",{"slug":47,"chapterNum":48,"title":49,"titleEn":50,"summary":51,"summaryEn":52},"chantiers","04","Chantiers, travaux & tâches — modèle de données et API","Worksites, Jobs & Tasks — Data Model and API","Décrit la hiérarchie chantier\u002Ftravail\u002Ftâche de Synedre OS, le modèle de données DB, les statuts\u002Fscopes canoniques et l'API Python associée.","Describes the worksite\u002Fjob\u002Ftask hierarchy in Synedre OS, the DB data model, canonical statuses\u002Fscopes, and the associated Python API.",{"slug":54,"chapterNum":55,"title":56,"titleEn":57,"summary":58,"summaryEn":59},"automates","05","Automates, crons & runs","Automations, crons & runs","Décrit la couche d'exécution non-conversationnelle de Synedre OS : les 209 façades Python, leur enrobage cron, le registre un composant interne et la frontière entre doctrine run et unité agent.","Describes the non-conversational execution layer of Synedre OS: the 209 Python facades, their cron wrapper, the un composant interne registry, and the boundary between run doctrine and agent unit.",{"slug":61,"chapterNum":62,"title":63,"titleEn":64,"summary":65,"summaryEn":66},"hub","06","Le Hub (\u002Fhub\u002F*)","The Hub (\u002Fhub\u002F*)","Présentation de l'interface d'administration privée Synedre OS (mothership-app), son architecture en couches Nuxt, la carte de ses modules et pages, ainsi que le système d'authentification et de session.","Presentation of the Synedre OS private administration interface (mothership-app), its Nuxt layered architecture, the map of its modules and pages, as well as the authentication and session management system.",{"slug":14,"chapterNum":15,"title":16,"titleEn":17,"summary":68,"summaryEn":69},"Décrit les deux pipelines IMAP→DB du harness (contact@ trié pour le hub, atlas@ déclencheur d'actions agentiques), la façade d'envoi sortant et les doctrines bloquantes associées (scan AV, zéro contact client direct).","Describes the two IMAP→DB pipelines of the harness (contact@ sorted for the hub, atlas@ triggering agentic actions), the outbound sending facade, and the associated blocking doctrines (AV scan, zero direct client contact).",{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10},{"slug":19,"chapterNum":20,"title":21,"titleEn":22,"summary":72,"summaryEn":73},"Décrit le pipeline de mise en ligne Synedre OS : asymétrie entre .\u002Fdeploy (IA, preprod) et .\u002Fship (Alex, production), le dispatcher YAML, le pattern build-host sans build VPS, et les règles associées (secrets, commit-avant-deploy, drift, smoke).","Describes the Synedre OS release pipeline: asymmetry between .\u002Fdeploy (AI, preprod) and .\u002Fship (Alex, production), the YAML dispatcher, the build-host pattern without build VPS, and the associated rules (secrets, commit-before-deploy, drift, smoke).",{"slug":75,"chapterNum":76,"title":77,"titleEn":78,"summary":79,"summaryEn":80},"facades","10","catalogue des façades et points d'entrée du harness","harness facade and entry-point catalogue","comment le harness synedre organise ses centaines d'automates en familles fonctionnelles, avec les garde-fous en temps réel qui encadrent chaque action.","how the synedre harness organizes its hundreds of automations into functional families, with the real-time guard-rails that frame every action.",{"slug":82,"chapterNum":83,"title":84,"titleEn":85,"summary":86,"summaryEn":87},"skills-hooks","11","Skills, agents & hooks — harness agentique Synedre OS","Skills, agents & hooks — Synedre OS agentic harness","Décrit le câblage complet du harness Claude Code de synedre-os : skills disponibles, sous-agents délégables et hooks d'événements qui imposent la doctrine commit-en-flux, garde-fous prod\u002Femail et injection mémoire.","Describes the complete wiring of the synedre-os Claude Code harness: available skills, delegatable sub-agents, and event hooks that enforce the commit-in-flow doctrine, prod\u002Femail guardrails, and memory injection."]