[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fgWV1rYZfn4yn3WFAK-vWr2hSmIBfilKR1b2DUblHn0Q":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":19},{"chapter":4,"prev":13,"next":18},{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10,"contentHtml":11,"contentHtmlEn":12},"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.","\u003Ch2 id=\"harness-overview\">Vue d'ensemble du harness agentique\u003C\u002Fh2>\n\n\u003Cp>Le harness agentique de Synedre OS repose sur trois couches complémentaires : les \u003Cstrong>skills\u003C\u002Fstrong> (modules de compétence invocables), les \u003Cstrong>agents\u003C\u002Fstrong> (sous-agents délégables avec une identité propre) et les \u003Cstrong>hooks d'événements\u003C\u002Fstrong> (garde-fous et nudges déclenchés automatiquement à chaque étape du cycle de vie d'une session). L'ensemble est piloté par deux fichiers de configuration qui coexistent.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Fichier de configuration\u003C\u002Fth>\n      \u003Cth>Versionné\u003C\u002Fth>\n      \u003Cth>Contenu\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Fichier de réglages versionné\u003C\u002Ftd>\n      \u003Ctd>Oui\u003C\u002Ftd>\n      \u003Ctd>Hooks \u003Ccode>PreToolUse\u003C\u002Fcode> \u002F \u003Ccode>PostToolUse\u003C\u002Fcode> \u002F \u003Ccode>Stop\u003C\u002Fcode> \u002F \u003Ccode>UserPromptSubmit\u003C\u002Fcode>, variables d'environnement, mode de permissions par défaut\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Fichier de réglages local\u003C\u002Ftd>\n      \u003Ctd>Non\u003C\u002Ftd>\n      \u003Ctd>Liste blanche de permissions (plusieurs centaines d'entrées), hooks \u003Ccode>SessionStart\u003C\u002Fcode> \u002F \u003Ccode>UserPromptSubmit\u003C\u002Fcode> \u002F \u003Ccode>PreToolUse\u003C\u002Fcode> \u002F \u003Ccode>PostToolUse\u003C\u002Fcode>, mode automatique\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Les deux jeux de hooks sont \u003Cstrong>cumulatifs\u003C\u002Fstrong> : pour un même événement (par exemple \u003Ccode>PreToolUse\u003C\u002Fcode> sur l'outil Bash), les commandes des deux fichiers s'exécutent. C'est pourquoi les garde-fous Python vivent dans le fichier local tandis que les nudges shell figurent dans le fichier versionné.\u003C\u002Fp>\n\n\u003Ch2 id=\"skills-catalogue\">Catalogue des skills\u003C\u002Fh2>\n\n\u003Cp>Chaque skill est un module de compétence autonome, défini par un fichier de description en markdown. Il peut être invoqué manuellement ou déclenché par le moteur. Certains skills internes ne sont pas destinés à l'invocation directe.\u003C\u002Fp>\n\n\u003Ch3>Audit et santé du système\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Audit général\u003C\u002Fstrong> — Audit complet d'un site ou d'une propriété : healthcheck infrastructure, pages publiques, SEO, performances, sécurité, base de données. Produit un score sur 100.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Anti-rot de liste blanche\u003C\u002Fstrong> — Vérifie que chaque chemin et section nommée dans la liste blanche immuable de niveau P0 existe encore. Protège contre la dérive silencieuse des références critiques.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit SEO i18n\u003C\u002Fstrong> — Contrôle la parité des clés de traduction FR↔EN, la cohérence des slugs URL localisés et la carte de routage. À lancer avant tout déploiement touchant les pages, l'internationalisation ou le routage.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit du registre lexical\u003C\u002Fstrong> — Détecte les dérives entre le dictionnaire canonique en base et les schémas de code. Mode lecture seule strict ; retourne un code de sortie sain ou dérivé.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit des personas\u003C\u002Fstrong> — Compare les personas des agents à la stack courante et enregistre un snapshot de dérive dans l'historique dédié.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>État du système\u003C\u002Fstrong> — Vérifie l'état global du système (services, connectivité, ressources).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>État du contexte de session\u003C\u002Fstrong> — Restitue l'état du contexte de la session en cours.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Infrastructure et hôtes\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Audit infra\u003C\u002Fstrong> — Vérifie disponibilité, charge, services, certificats SSL et backups d'un hôte donné.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Audit sécurité\u003C\u002Fstrong> — Audit de sécurité d'un hôte (le VPS du vaisseau-mère ou un VPS client).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vérification des sauvegardes\u003C\u002Fstrong> — Contrôle la fraîcheur et l'intégrité des sauvegardes locales d'un hôte.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Mise à jour système\u003C\u002Fstrong> — Lance une mise à jour APT non-interactive avec gel des paquets Docker.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Analyse des bots\u003C\u002Fstrong> — Analyse le journal des hits de robots collecté par le serveur.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Interrogation GSC\u003C\u002Fstrong> — Interroge l'API Google Search Console pour remonter les opportunités SEO.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Pilotage des chantiers\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Chantier\u003C\u002Fstrong> — Pilote la doctrine « 1 chantier = N travaux » : création de squelette, suivi des travaux, lecture en base des chantiers et de leurs travaux associés.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Run\u003C\u002Fstrong> — Ouvre un run scopé (unité légère symétrique du chantier). Charge le périmètre depuis la base de données (vaisseau-mère, tenant, négociation) et restitue la ligne en cours. \u003Cem>Distinct du lanceur d'application natif.\u003C\u002Fem>\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Négociation\u003C\u002Fstrong> — Charge le contexte complet d'une négociation commerciale : dossier, qualification, équipe, journal, livrables. Symétrique du chantier pour le pipeline prospect → contrat.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Idée\u003C\u002Fstrong> — Crée une note de brainstorm dans la table dédiée.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Revue\u003C\u002Fstrong> — Revue de la Place des Armes : chaque agent se présente et rapporte son état.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Leçon post-chantier\u003C\u002Fstrong> — Génère une leçon pédagogique après un chantier (méthode Montessori) et la dépose dans la boîte de réception du Vault Obsidian.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Email et boîte de réception\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Inbox (façade)\u003C\u002Fstrong> — Lit et recherche les emails via la façade applicative, en base de données.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Inbox directe\u003C\u002Fstrong> — Accès IMAP de secours, lecture seule, sans écriture en base. Utilisé en cas d'indisponibilité de la façade.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Recherche inbox\u003C\u002Fstrong> — Wrapper ergonomique pour la récupération et l'analyse des emails : téléchargement au format \u003Ccode>.eml\u003C\u002Fcode>, liste des pièces jointes sans extraction préalable (approche scan-first).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scan de pièce jointe\u003C\u002Fstrong> — Analyse antivirus d'une pièce jointe avant ouverture, via l'agent Mitnick.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vérification de proposition commerciale\u003C\u002Fstrong> — QA d'une proposition commerciale avant envoi par email, orchestrée sur un pool de quatre agents.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Mémoire et connaissance\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Recall sémantique\u003C\u002Fstrong> — Recherche RAG (retrieval-augmented generation) par similarité vectorielle sur la mémoire documentaire et les cicatrices, doctrines et chantiers en base. Utilise des embeddings cosine haute dimension.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Zettelkasten\u003C\u002Fstrong> — Décompose un document monolithique en notes atomiques pour le Vault Obsidian.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Dictionnaire technique\u003C\u002Fstrong> — Ajoute des termes au dictionnaire technique partagé.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Victoire\u003C\u002Fstrong> — Grave une victoire comme cicatrice de type \u003Ccode>victory\u003C\u002Fcode> dans la base.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Rafraîchissement de persona\u003C\u002Fstrong> — Met à jour la persona d'un agent via un modèle IA, une comparaison trois-voies et une revue, puis persiste la mise à jour en base.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Finance et business\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Banque\u003C\u002Fstrong> — Consulte les comptes et transactions via la façade bancaire.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Import bancaire\u003C\u002Fstrong> — Import manuel de transactions depuis un export CSV N26 vers la table de transactions en base.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Facturation\u003C\u002Fstrong> — Crée, liste, génère des PDF et envoie factures et devis via la façade de facturation. Gère les abonnements récurrents. L'entité émettrice canonique est toujours l'entité juridique du titulaire du système.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Prospects Malt\u003C\u002Fstrong> — Récupère les conversations prospect depuis la plateforme Malt.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Publication et SEO\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Publication d'article\u003C\u002Fstrong> — Publie un article de blog sur la propriété web désignée.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Publication de cicatrices\u003C\u002Fstrong> — Pipeline complet : curation → assainissement → revue contradictoire par Mitnick → publication des cicatrices publiques de Synedre. Publie la cicatrice-trophée (leçon extraite) ; \u003Cstrong>ne publie jamais\u003C\u002Fstrong> la cicatrice-tutoriel (repro exploitable).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Sentinelle SEO\u003C\u002Fstrong> — Détection précoce d'hémorragie de positions sur plusieurs propriétés. Lance l'automate de surveillance et reformule le rapport.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Documentation et QA\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Documentation technique\u003C\u002Fstrong> — Génère ou rafraîchit la documentation technique via une orchestration multi-agents (rédaction → vérification → correction). Supporte un mode rafraîchissement sélectif (pages périmées uniquement) et un mode sans synthèse. Ne committe jamais sans validation explicite.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>QA visuelle\u003C\u002Fstrong> — Capture un screenshot via Playwright et soumet l'image à un sous-agent multimodal pour vérifier que l'intention visuelle est bien rendue — au-delà du simple succès d'exécution du code.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Clone de site\u003C\u002Fstrong> — Génère le protocole d'intake « accès et informations serveur » pour cloner le site existant d'un client sur un VPS, et rédige la demande d'accès par email.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"skills-db-sources\">Sources de vérité en base de données\u003C\u002Fh2>\n\n\u003Cp>Les skills ne stockent pas la donnée métier : ils interrogent la base de données centrale via des tables dédiées. Voici la correspondance entre les principaux skills et les entités persistées :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Skill\u003C\u002Fth>\n      \u003Cth>Entités en base\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Chantier\u003C\u002Ftd>\n      \u003Ctd>Table des chantiers, table des travaux de chantier\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Recall sémantique\u003C\u002Ftd>\n      \u003Ctd>Table des cicatrices, table des doctrines, table des chantiers\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Victoire\u003C\u002Ftd>\n      \u003Ctd>Table des cicatrices (\u003Ccode>kind = 'victory'\u003C\u002Fcode>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Idée\u003C\u002Ftd>\n      \u003Ctd>Table de brainstorm\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Audit des personas\u003C\u002Ftd>\n      \u003Ctd>Table d'historique de dérive des personas\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Rafraîchissement de persona\u003C\u002Ftd>\n      \u003Ctd>Table des agents\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Inbox\u003C\u002Ftd>\n      \u003Ctd>Table des emails de la boîte de réception\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Import bancaire\u003C\u002Ftd>\n      \u003Ctd>Table des transactions bancaires\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note d'architecture :\u003C\u002Fstrong> un hook de pré-invocation consulte la taille déclarée de chaque skill en base pour décider si un chargement différé (lazy-load à trois niveaux) doit être suggéré, afin de préserver le contexte de session sur les skills volumineux.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"sous-agents-fichiers\">Sous-agents : fichiers de personnalité délégables\u003C\u002Fh2>\n\n\u003Cp>Le système embarque une trentaine de \u003Cstrong>fichiers de personnalité d'agent\u003C\u002Fstrong>, chacun délégable via le mécanisme de délégation interne. Chaque fichier décrit un agent nommé : son rôle, ses critères de délégation, ses outils autorisés et le modèle de langage cible.\u003C\u002Fp>\n\n\u003Cp>Une partie de chaque fichier est \u003Cstrong>générée automatiquement\u003C\u002Fstrong> depuis la base de données (données de persona : nom canonique, description, capacités) et encadrée par des marqueurs de zone managée. La zone éditoriale — doctrine, mode opératoire, consignes métier — est rédigée à la main et \u003Cstrong>préservée entre chaque regénération\u003C\u002Fstrong>. Il ne faut jamais modifier manuellement la zone managée : toute modification serait écrasée à la prochaine synchronisation.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Source de vérité :\u003C\u002Fstrong> la table physique des agents (accessible en lecture via une vue dédiée) est l'unique référence. Le script de regénération lit la vue ; l'outil de rafraîchissement de persona écrit dans la table de base. Les deux opèrent sur la même source : aucun risque de divergence entre vue et table.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>Chaque fichier de personnalité expose trois métadonnées de frontmatter : un nom public, une description servant de critère de délégation automatique, et la liste des outils autorisés.\u003C\u002Fp>\n\n\u003Ch3>Agents exécutants\u003C\u002Fh3>\n\n\u003Cp>Ces agents disposent d'un accès en lecture \u003Cem>et\u003C\u002Fem> en écriture, ainsi que de la capacité à exécuter des commandes système. Ils interviennent directement sur les artefacts du dépôt et l'infrastructure.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Codename public\u003C\u002Fth>\n      \u003Cth>Domaine\u003C\u002Fth>\n      \u003Cth>Capacités\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Brunel\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Infrastructure & DevOps — orchestration des conteneurs, reverse proxy, certificats SSL, DNS, gestion du VPS du vaisseau-mère\u003C\u002Ftd>\n      \u003Ctd>Lecture, écriture, exécution, recherche\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Turing\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Backend & fiabilité serveur — couche applicative Nuxt, modules métier, scripts Python, intégrité base de données\u003C\u002Ftd>\n      \u003Ctd>Lecture, écriture, exécution, recherche\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Eames\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Frontend — interface Nuxt 4 \u002F Vue 3 \u002F Tailwind, design system, pages du hub\u003C\u002Ftd>\n      \u003Ctd>Lecture, écriture, exécution, recherche\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Otlet\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>SEO technique — balisage structuré, sitemap, Core Web Vitals, redirections, indexabilité IA\u003C\u002Ftd>\n      \u003Ctd>Lecture, écriture, exécution, recherche\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Lovelace\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Assurance qualité — dernier rempart avant mise en production, tests d'acceptance, détection de régressions\u003C\u002Ftd>\n      \u003Ctd>Lecture et recherche uniquement (\u003Cstrong>pas d'écriture\u003C\u002Fstrong>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Mitnick\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Sécurité offensive & défensive — analyse de pièces jointes, détection de secrets exposés, audit OWASP\u003C\u002Ftd>\n      \u003Ctd>Lecture et recherche uniquement (\u003Cstrong>pas d'écriture\u003C\u002Fstrong>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Lovelace\u003C\u002Fstrong> et \u003Cstrong>Mitnick\u003C\u002Fstrong> n'ont délibérément aucun droit d'écriture ni d'exécution : leur rôle est le contrôle, non la mutation. Mitnick en analyse de pièce jointe est un outil d'outillage (étape préalable à tout chantier), non un membre d'équipe recruté.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Agents conseil et connaissance\u003C\u002Fh3>\n\n\u003Cp>Ces agents n'ont accès qu'à la lecture du dépôt et des sources documentaires. Ils produisent des analyses, des recommandations, des drafts et des rapports — jamais d'exécution directe ni de modification de fichiers.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Codename public\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Atlas\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Architecte & chef de projet — partitionne le travail en chantiers, dispatche aux agents spécialisés, orchestre la doctrine de délégation\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Audiard\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Auteur audio — réécriture pour l'oreille (rythme, oralité, souffle)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Bernays\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Croissance commerciale — pipeline de leads, tunnels de conversion\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Bernhardt\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Contrôle qualité audio — notation (seuil 9,5\u002F10 bloquant), diction, fidélité au texte source\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Braille\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Accessibilité — conformité WCAG 2.2 AA (navigation clavier, contrastes, ARIA)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Clausewitz\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Stratégie — cohérence des décisions produit vis-à-vis du positionnement\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Coco\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Gardien de la marque — épuration tonale, cohérence visuelle cross-canal\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Colbert\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Direction générale — priorisation des chantiers, allocation de ressources, pilotage\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Dumas\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Narrateur — storytelling sérialisé, arcs émotionnels, épisodes, personnages\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Gauss\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Analyse de données — métriques (trafic, conversion, coûts), restitution d'insights\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Hill\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Vision long terme — cap stratégique, North Star\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Hokusai\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Illustration — character design & illustration manga\u002Fmanhwa par IA générative\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Itten\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Direction artistique — palette chromatique, typographie, design tokens\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Marco Polo\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Veille — technologique, concurrentielle et marché\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Méliès\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Production visuelle IA — portraits, scènes, couvertures, ingénierie de prompts\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Montesquieu\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Conseil juridique (droit UE) — RGPD, CGV, droit numérique\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Montessori\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Pédagogie — modules d'apprentissage, dictionnaire, parcours apprenants\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Nightingale\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Succès client — rédaction de communications client, \u003Cstrong>jamais d'envoi direct\u003C\u002Fstrong>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Ogilvy\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Copywriting — ton persuasif, clarté du message, CTA, cohérence cross-canal\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Pacioli\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>FinOps — suivi des coûts IA, infrastructure, services, réconciliation financière\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Pulitzer\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Content & blog SEO — articles, couvertures, maillage interne\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Renoir\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Supervision du scheduling — orchestration des automates, horaires, silences entre tâches\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Socrate\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Dialogue & communauté — questionnement maïeutique, FAQ, clarification des présupposés\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Winnicott\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Équilibre opérationnel — détection de surcharge, ajustements de rythme\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Invariants de conception\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Nightingale\u003C\u002Fstrong> ne dispose d'aucune capacité d'exécution système : il est strictement en lecture, ce qui garantit que le système ne communique jamais directement avec un client sans validation humaine.\u003C\u002Fli>\n  \u003Cli>Tous les agents conseil (section précédente) opèrent en lecture seule : zéro exécution, zéro écriture.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Atlas\u003C\u002Fstrong> applique la doctrine de chantier : pour tout périmètre significatif, au moins deux agents distincts sont mobilisés, et la délégation passe par le mécanisme de délégation interne — jamais par appel direct.\u003C\u002Fli>\n  \u003Cli>Un drift résiduel peut apparaître entre la zone managée d'un fichier d'agent et les données réelles en base si une synchronisation manuelle a eu lieu. La source de vérité reste toujours la table physique des agents ; les outils \u003Ccode>refresh-persona\u003C\u002Fcode> et \u003Ccode>audit-personas\u003C\u002Fcode> permettent de corriger tout écart.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"hooks-carte-evenements\">4. Hooks\u003C\u002Fh2>\n\n\u003Ch3>4.1 Carte des événements\u003C\u002Fh3>\n\n\u003Cp>Le harnais intercepte le cycle de vie de l'agent à six points clés. Chaque interception peut être \u003Cstrong>bloquante\u003C\u002Fstrong> (l'agent ne continue pas) ou \u003Cstrong>non-bloquante\u003C\u002Fstrong> (avertissement seul). Le tableau suivant résume la carte complète :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Point d'interception\u003C\u002Fth>\n      \u003Cth>Outil ciblé\u003C\u002Fth>\n      \u003Cth>Mécanismes déclenchés\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Démarrage de session\u003C\u002Ftd>\n      \u003Ctd>(local)\u003C\u002Ftd>\n      \u003Ctd>Remise à zéro du contexte, génération du brief, injection des cicatrices\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Soumission d'un prompt utilisateur\u003C\u002Ftd>\n      \u003Ctd>versionné + local\u003C\u002Ftd>\n      \u003Ctd>Synchronisation du schéma DB, synchronisation de la boîte mail (agent Nightingale)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Lecture\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Contrôle antivirus des pièces jointes (fail-closed)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Commande shell\u003C\u002Ftd>\n      \u003Ctd>versionné + local\u003C\u002Ftd>\n      \u003Ctd>8 nudges et gardes shell, 3 garde-fous Python\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Agent\u003C\u002Ftd>\n      \u003Ctd>versionné + local\u003C\u002Ftd>\n      \u003Ctd>Réacteur d'agent, injection de cicatrices\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Skill\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Suggestion de vue allégée si la fiche de compétence est volumineuse\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Édition\u002FÉcriture\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Moteur de réflexes décentralisés (décision deny\u002Fwarn\u002Fallow, trace d'audit)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Avant utilisation — Édition\u002FÉcriture\u003C\u002Ftd>\n      \u003Ctd>local\u003C\u002Ftd>\n      \u003Ctd>Injection de cicatrices\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Après utilisation — Commande shell\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Journal de réaction, déploiement preprod post-commit\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Après utilisation — Agent\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Réacteur, journal de réaction, télémétrie\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Après utilisation — Éditions multiples\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Suivi des fichiers édités dans la session\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Après utilisation — Tous outils\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Événement cockpit CLI (best-effort, non-bloquant)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Après utilisation — Tous outils\u003C\u002Ftd>\n      \u003Ctd>local\u003C\u002Ftd>\n      \u003Ctd>Comptage de tokens \u002F contexte\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Fin de session (Stop)\u003C\u002Ftd>\n      \u003Ctd>versionné\u003C\u002Ftd>\n      \u003Ctd>Signal cockpit de fin de tour → libération du verrou chantier → rappel cicatrices → vérification commits → synchronisation chantier\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>4.2 Démarrage de session\u003C\u002Fh3>\n\n\u003Cp>Trois opérations s'exécutent à l'ouverture de chaque session, chacune avec un délai d'expiration de 5 secondes :\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Remise à zéro du compteur de contexte\u003C\u002Fstrong> — le module de suivi de contexte repart à zéro pour la session courante.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Génération du brief\u003C\u002Fstrong> — le générateur de rapport lit un rapport pré-calculé (produit chaque nuit vers 5 h UTC par une tâche planifiée de type \u003Cem>audit quotidien\u003C\u002Fem>) et l'enrichit en temps réel : état git, crontab, emails clients en attente, backlog, cicatrices. Le résultat est injecté dans le contexte de démarrage. Aucune dépendance npm n'est requise ; la lecture de la base se fait via le moteur de base de données conteneurisé du vaisseau-mère.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Injection des cicatrices\u003C\u002Fstrong> — les cicatrices pertinentes pour la session sont injectées dans le contexte initial.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note de configuration :\u003C\u002Fstrong> le hook de démarrage de session n'est \u003Cem>pas\u003C\u002Fem> présent dans le fichier de configuration versionné partagé — il vit uniquement dans le fichier de configuration local (non versionné). Cette séparation est intentionnelle : les opérations de démarrage accèdent à des ressources locales (base de données, inbox) qui ne sont disponibles que sur le vaisseau-mère.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.3 Soumission d'un prompt utilisateur\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Fichier versionné\u003C\u002Fstrong> : synchronisation du dump de schéma de base de données à chaque prompt — l'agent dispose toujours d'une vue fraîche de la structure des tables.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Fichier local\u003C\u002Fstrong> : synchronisation de la boîte mail (agent Nightingale, délai d'expiration 15 s) — à chaque prompt, les nouveaux emails entrants sont rapatriés dans la table de suivi de l'inbox. Ce mécanisme est implémenté comme un \u003Cstrong>skill dédié\u003C\u002Fstrong> exposé via la façade applicative ; le script de synchronisation réelle est distinct du script de lecture directe.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Historique correctif :\u003C\u002Fstrong> jusqu'à mi-2026, ce hook pointait vers un script fantôme jamais migré, ce qui le faisait échouer silencieusement. La correction a également mis à jour la liste blanche du garde-fou email, qui référençait le même script obsolète.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.4 Avant utilisation (PreToolUse)\u003C\u002Fh3>\n\n\u003Ch3>Garde antivirus — outil Lecture (bloquant, versionné)\u003C\u002Fh3>\n\n\u003Cp>Toute tentative de lecture d'une pièce jointe dans la zone de quarantaine temporaire est \u003Cstrong>bloquée\u003C\u002Fstrong> si un marqueur de verdict antivirus propre n'est pas présent pour ce fichier. Ce réflexe est \u003Cem>fail-closed\u003C\u002Fem> : en l'absence du marqueur, l'accès est refusé. Il n'a aucune dépendance envers la base de données — il s'évalue sur la seule présence ou absence du fichier de verdict.\u003C\u002Fp>\n\n\u003Ch3>Gardes shell — outil Commande (versionné)\u003C\u002Fh3>\n\n\u003Cp>Huit scripts s'enchaînent avant toute exécution de commande shell :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Garde\u003C\u002Fth>\n      \u003Cth>Comportement\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Contrôle antivirus pièces jointes\u003C\u002Ftd>\n      \u003Ctd>Même logique fail-closed que pour l'outil Lecture : bloque les commandes shell qui ouvriraient une pièce jointe non scannée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Blocage de la commande de mise en production (\u003Ccode>.\u002Fship\u003C\u002Fcode>)\u003C\u002Ftd>\n      \u003Ctd>\u003Cstrong>Bloquant\u003C\u002Fstrong> — l'agent ne peut jamais déclencher lui-même la mise en production publique. Réflexe de tronc, zéro dépendance runtime.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Contrôle de mutation base de données\u003C\u002Ftd>\n      \u003Ctd>Bloque toute mutation destructive sur les tables internes du système si aucun commit de code aligné n'a eu lieu dans les cinq dernières minutes. Incarne la doctrine « le code avant la base ».\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Auto-commit avant déploiement\u003C\u002Ftd>\n      \u003Ctd>Effectue automatiquement un commit avant l'exécution d'un \u003Ccode>.\u002Fdeploy\u003C\u002Fcode>.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Nudge squelette de chantier\u003C\u002Ftd>\n      \u003Ctd>Avertit si une insertion SQL brute sur un chantier est tentée au lieu d'utiliser la commande de création avec squelette dédiée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Scan anti-fuite pré-commit\u003C\u002Ftd>\n      \u003Ctd>Analyse les fichiers à committer pour détecter d'éventuelles fuites (secrets, données sensibles) avant qu'ils n'entrent dans l'historique git. Délai d'expiration : 10 s.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Rappel de chantiers existants\u003C\u002Ftd>\n      \u003Ctd>Non-bloquant (délai 30 s) — lors de la création d'un nouveau chantier, effectue un rappel hybride (recherche lexicale + sémantique) et injecte les quatre chantiers ou doctrines les plus proches. Évite de réinventer l'existant.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Nudge de liaison documentation\u003C\u002Ftd>\n      \u003Ctd>Avertissement seul (jamais bloquant) — au moment d'un commit git, croise les fichiers modifiés avec les contrats de liaison des chapitres de documentation. Si un fichier lié à un chapitre est touché, rappelle de vérifier que le chapitre est encore exact.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note repreneur :\u003C\u002Fstrong> un script de contrôle d'authentification back-office existe dans le dépôt mais n'est référencé dans aucun fichier de configuration actif — il est dormant et sans effet.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Garde-fous Python — outil Commande (local)\u003C\u002Fh3>\n\n\u003Cp>Trois garde-fous supplémentaires, bloquants, s'exécutent depuis la configuration locale :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Garde-fou\u003C\u002Fth>\n      \u003Cth>Comportement\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Protection des environnements de production client\u003C\u002Ftd>\n      \u003Ctd>Bloque toute commande shell ciblant un environnement de production client avec un pattern d'écriture destructive (TRUNCATE, DROP, DELETE, ALTER, UPDATE, import direct via pipe). Trois couches d'anti-faux-positifs : (1) les commandes visant le vaisseau-mère lui-même sont court-circuitées avant le test client ; (2) les commandes visant la preprod client passent sans contrôle ; (3) les requêtes non destructives (SELECT, SHOW, INSERT simple) ne sont pas ciblées — seules neuf familles d'opérations dangereuses sont effectivement bloquées. Les commandes d'écriture autorisées doivent transiter par le script de sécurisation dédié.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Protection de la façade email\u003C\u002Ftd>\n      \u003Ctd>Bloque tout contournement de la façade d'envoi email officielle. Interdit l'utilisation directe des bibliothèques SMTP\u002FIMAP bas niveau ou d'alias d'envoi non officiels. Seuls les scripts d'envoi, de synchronisation inbox, de lecture directe et de mailbox spécialisée figurant dans la liste blanche sont autorisés — chacun accepté avec ou sans chemin relatif. Le script fantôme jamais migré a été retiré de la liste blanche lors de la correction de mi-2026.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Injection de cicatrices contextuelles\u003C\u002Ftd>\n      \u003Ctd>Injecte les cicatrices liées à la commande en cours d'évaluation. Délai d'expiration : 3 s.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Évolution de la façade email (mi-2026) :\u003C\u002Fstrong> la façade auto-envoie une copie de validation à l'opérateur humain à chaque brouillon créé (mécanisme \u003Cem>show-before-send\u003C\u002Fem> appliqué en pratique, pas seulement déclaratif). L'envoi réel appose automatiquement la signature HTML canonique. Un mode de conversion Markdown vers HTML email-safe est disponible. Au moment du brouillon, le ton de rédaction adapté au destinataire est affiché (best-effort, non-bloquant). Un mode de renvoi de copie de validation sur brouillon existant est également disponible, sans recréer le brouillon.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Moteur de réflexes — outil Édition\u002FÉcriture (versionné)\u003C\u002Fh3>\n\n\u003Cp>Avant toute édition de fichier, le \u003Cstrong>moteur de réflexes décentralisés\u003C\u002Fstrong> entre en jeu. Il lit l'événement hook entrant, charge les règles actives depuis la table de réflexes du système, évalue une décision (\u003Cem>deny\u003C\u002Fem>, \u003Cem>warn\u003C\u002Fem> ou \u003Cem>allow\u003C\u002Fem>) et trace l'événement dans la table d'audit des réflexes. Gestion fail-closed ciblée :\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>Si la base de données primaire est injoignable : blocage uniquement pour les zones de code sensibles (le cœur du produit principal) ; hors zone sensible, la main est laissée à l'agent.\u003C\u002Fli>\n  \u003Cli>Si une erreur Python survient dans le moteur lui-même : passage en \u003Cem>allow\u003C\u002Fem> avec trace sur l'erreur standard — un bug du garde-fou ne bloque jamais le travail.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>En parallèle, le script d'injection de cicatrices (configuration locale) s'exécute cumulativement pour le même événement d'édition.\u003C\u002Fp>\n\n\u003Ch3>Agent et Skills\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Outil Agent :\u003C\u002Fstrong> le réacteur d'agent (versionné) et le script d'injection de cicatrices agent (local) s'exécutent avant tout sous-appel d'agent.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Outil Skill :\u003C\u002Fstrong> un hook non-bloquant (délai 5 s, exit 0 garanti) suggère d'utiliser la vue allégée d'une fiche de compétence lorsque celle-ci dépasse un seuil de taille configuré.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.5 Après utilisation (PostToolUse)\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\n    \u003Cstrong>Commande shell :\u003C\u002Fstrong> deux hooks s'enchaînent.\n    \u003Col>\n      \u003Cli>Le journal de réaction enregistre le résultat de la commande.\u003C\u002Fli>\n      \u003Cli>Le déploiement preprod automatique post-commit analyse les chemins touchés et détermine le site impacté. \u003Cstrong>Nuance importante :\u003C\u002Fstrong> pour les sites client, il s'agit d'un déploiement en preprod ; pour le vaisseau-mère lui-même, il n'existe pas de preprod — \u003Ccode>.\u002Fdeploy\u003C\u002Fcode> déclenche un rebuild en direct. Le hook saute le déploiement si le message de commit contient une directive d'exclusion (\u003Ccode>[skip-deploy]\u003C\u002Fcode> \u002F \u003Ccode>[no-deploy]\u003C\u002Fcode> \u002F préfixe \u003Ccode>wip:\u003C\u002Fcode>), si le commit ne touche que de la documentation sans fichier runtime, ou si le répertoire de travail est sale après le commit.\u003C\u002Fli>\n    \u003C\u002Fol>\n  \u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Agent :\u003C\u002Fstrong> réacteur, journal de réaction, télémétrie (délai 5 s).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Éditions multiples :\u003C\u002Fstrong> le traqueur de fichiers édités par session (délai 3 s) maintient la liste des fichiers modifiés, utilisée ensuite par le hook de fin de session.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tous outils :\u003C\u002Fstrong> le miroir d'activité cockpit CLI (délai 10 s) émet un événement vers le cadran de suivi du chantier actif. Il s'active uniquement si un chantier actif est enregistré ; si la variable d'environnement de désactivation est positionnée ou si aucun chantier n'est lié, il sort immédiatement sans coût. Non-bloquant : un événement raté ne bloque jamais l'appel d'outil.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tous outils (local) :\u003C\u002Fstrong> le compteur de tokens de contexte (délai 5 s) met à jour les métriques de consommation de la session.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.6 Fin de session (Stop)\u003C\u002Fh3>\n\n\u003Cp>Cinq opérations s'exécutent séquentiellement à la clôture de chaque session :\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Signal de fin de tour au cockpit\u003C\u002Fstrong> (délai 9 s) — émet un fragment de fin de tour dans la chronologie du cadran de suivi du chantier, uniquement si la fonctionnalité est activée et qu'un chantier est lié.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Libération du verrou chantier\u003C\u002Fstrong> (délai 3 s) — libère le verrou de session sur le chantier en cours.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Rappel de cicatrices\u003C\u002Fstrong> — déclenché uniquement si le dernier message utilisateur contient un mot-clé de clôture (« clôture », « fin de session », « on ferme »…). Lorsqu'il se déclenche, liste les commits correctifs depuis la dernière mise en preprod via le canal d'erreur standard, et retourne un code bloquant.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vérification des commits\u003C\u002Fstrong> (délai 5 s, \u003Cstrong>bloquant\u003C\u002Fstrong>) — refuse la clôture si des fichiers modifiés \u003Cem>dans cette session\u003C\u002Fem> ne sont pas commités. Force le commit en flux continu. Mécaniques clés :\n    \u003Cul>\n      \u003Cli>\u003Cstrong>Session-aware :\u003C\u002Fstrong> seuls les fichiers de la session courante sont vérifiés — plusieurs sessions Claude parallèles ne se bloquent pas mutuellement.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Anti-boucle :\u003C\u002Fstrong> si le hook détecte qu'il est déjà en deuxième passe, il bascule en avertissement non-bloquant au lieu d'un blocage dur.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Court-circuit worker :\u003C\u002Fstrong> si la session est un sous-agent spawné par le moteur de tâches automatisées, le hook sort silencieusement — le worker gère son propre cycle de commit.\u003C\u002Fli>\n      \u003Cli>Le fichier de configuration de session lui-même est exclu de la vérification.\u003C\u002Fli>\n    \u003C\u002Ful>\n  \u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Synchronisation du chantier\u003C\u002Fstrong> (délai 8 s) — rappel de synchronisation entre l'état local du chantier et la base du hub.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>4.7 Convention de contexte worker\u003C\u002Fh3>\n\n\u003Cp>Un module utilitaire partagé, sourcé par les quatre hooks de fin de session, implémente une sortie anticipée systématique lorsque la session est un sous-agent spawné par le moteur de tâches automatisées. Cette convention garantit qu'un sous-agent :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>ne déclenche pas les rappels de cicatrices de clôture,\u003C\u002Fli>\n  \u003Cli>ne libère pas des verrous qui appartiennent à la session parente,\u003C\u002Fli>\n  \u003Cli>n'est pas bloqué par la vérification de commits (il gère son propre cycle),\u003C\u002Fli>\n  \u003Cli>ne pollue pas la synchronisation de chantier de la session utilisateur principale.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>La variable d'environnement de contexte worker est injectée par le module de spawn du moteur de tâches au moment de la création du sous-agent. Cette séparation est une règle générale : ce qui appartient à la session utilisateur ne s'applique pas aux agents automatisés, et vice-versa.\u003C\u002Fp>\n\u003Ch2 id=\"permissions-env\">Permissions et environnement d'exécution\u003C\u002Fh2>\n\n\u003Ch3>Configuration principale\u003C\u002Fh3>\n\n\u003Cp>Le fichier de configuration principal de l'agent définit deux paramètres clés :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Un bloc \u003Ccode>env\u003C\u002Fcode> activant les variables d'expérimentation du moteur (équipes d'agents, rendu sans scintillement).\u003C\u002Fli>\n  \u003Cli>Un bloc \u003Ccode>permissions\u003C\u002Fcode> avec \u003Ccode>defaultMode: auto\u003C\u002Fcode> — l'agent s'exécute sans demander de confirmation à chaque étape, ce qui est cohérent avec la doctrine d'autonomie portée par la commande \u003Ccode>.\u002Fdeploy\u003C\u002Fcode>.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Configuration locale et politique d'accès aux données\u003C\u002Fh3>\n\n\u003Cp>Un second fichier de configuration, propre à la machine hôte et exclu du dépôt versionné, affine la politique d'autorisation :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>La liste d'autorisation recense plusieurs centaines d'outils et de commandes pré-approuvés ; aucune liste de refus explicite n'est définie à ce niveau.\u003C\u002Fli>\n  \u003Cli>Les variables d'environnement locales sont délibérément vides : aucun secret n'est injecté par ce canal.\u003C\u002Fli>\n  \u003Cli>Un bloc de politique en langage naturel précise les règles d'accès aux bases de données selon l'environnement :\n    \u003Cul>\n      \u003Cli>\u003Cstrong>Lecture seule\u003C\u002Fstrong> autorisée sur l'environnement de \u003Cem>staging\u003C\u002Fem> d'un client donné.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Écriture en production\u003C\u002Fstrong> soumise à confirmation explicite à chaque opération — la règle ne peut pas être contournée par accumulation de contexte.\u003C\u002Fli>\n      \u003Cli>Un rappel explicite distingue les deux VPS concernés (production et staging) afin d'éviter toute confusion lors des interventions.\u003C\u002Fli>\n    \u003C\u002Ful>\n  \u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Cette politique déclarative est doublée par un garde-fou exécutable (décrit en section 4) : la règle est donc appliquée à deux niveaux indépendants — la configuration et le hook de vérification — ce qui constitue une défense en profondeur.\u003C\u002Fp>\n\n\u003Ch3>Prévention des fuites de secrets\u003C\u002Fh3>\n\n\u003Cp>Aucun secret n'apparaît en clair dans les hooks, compétences ou définitions d'agents. Les identifiants de messagerie (réception et envoi), les mots de passe de base de données et les clés API sont référencés uniquement par leur \u003Cstrong>nom de variable\u003C\u002Fstrong> dans un fichier d'environnement local exclu du versionnement. Leur valeur n'est jamais inscrite dans un fichier suivi par le dépôt.\u003C\u002Fp>\n\n\u003Cp>Deux mécanismes de surveillance complémentaires assurent la détection des fuites :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Un hook de pré-validation scanne les transcriptions avant tout commit pour détecter toute valeur sensible qui aurait pu être capturée dans l'historique de session.\u003C\u002Fli>\n  \u003Cli>Une compétence dédiée à l'analyse des pièces jointes détecte les contenus malveillants potentiels avant leur traitement.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"modele-donnees\">Modèle de données — vue d'ensemble des flux\u003C\u002Fh2>\n\n\u003Cp>Le tableau suivant récapitule les principaux domaines fonctionnels du modèle de données, en indiquant pour chacun quel composant produit les données et quel composant les consomme.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Domaine fonctionnel\u003C\u002Fth>\n      \u003Cth>Producteur\u003C\u002Fth>\n      \u003Cth>Consommateur\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Référentiel des agents (table de base + vue de lecture)\u003C\u002Ftd>\n      \u003Ctd>Édition manuelle ou compétence de rafraîchissement des personas\u003C\u002Ftd>\n      \u003Ctd>Script de régénération des fichiers de définition d'agents (lit la vue de lecture)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Chantiers et travaux associés\u003C\u002Ftd>\n      \u003Ctd>Compétence chantier, entité métier chantier\u003C\u002Ftd>\n      \u003Ctd>Hooks de synchronisation et de verrouillage des chantiers\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Cicatrices (événements mémorisés)\u003C\u002Ftd>\n      \u003Ctd>Compétence de victoire, hook d'arrêt\u003C\u002Ftd>\n      \u003Ctd>Compétence de rappel, injection au démarrage de session et avant chaque outil\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Rapports d'audit quotidiens\u003C\u002Ftd>\n      \u003Ctd>Tâche d'audit planifiée\u003C\u002Ftd>\n      \u003Ctd>Script de briefing de session (injecté au démarrage)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Index des compétences (taille en octets)\u003C\u002Ftd>\n      \u003Ctd>Indexation automatique des compétences\u003C\u002Ftd>\n      \u003Ctd>Hook de pré-invocation des compétences\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Historique de dérive des personas\u003C\u002Ftd>\n      \u003Ctd>Audit des personas\u003C\u002Ftd>\n      \u003Ctd>Revue manuelle de dérive\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Idées \u002F brainstorm\u003C\u002Ftd>\n      \u003Ctd>Compétence de soumission d'idées\u003C\u002Ftd>\n      \u003Ctd>Cadran de brainstorm du hub\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Boîte de réception e-mail\u003C\u002Ftd>\n      \u003Ctd>Façade de messagerie entrante\u003C\u002Ftd>\n      \u003Ctd>Compétence de lecture de la boîte\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Transactions bancaires\u003C\u002Ftd>\n      \u003Ctd>Import automatisé depuis la banque\u003C\u002Ftd>\n      \u003Ctd>Compétence de consultation bancaire\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note architecturale :\u003C\u002Fstrong> le référentiel des agents repose sur une \u003Cstrong>table de base unique\u003C\u002Fstrong> exposée via une \u003Cstrong>vue de lecture\u003C\u002Fstrong>. Le script de régénération lit la vue ; la compétence de rafraîchissement des personas écrit directement dans la table de base. Il n'existe pas deux tables divergentes : la cohérence est garantie et aucune migration n'est nécessaire.\u003C\u002Fp>\n\u003C\u002Fblockquote>","\u003Ch2 id=\"harness-overview\">Agentic Harness Overview\u003C\u002Fh2>\n\n\u003Cp>The Synedre OS agentic harness rests on three complementary layers: \u003Cstrong>skills\u003C\u002Fstrong> (invocable capability modules), \u003Cstrong>agents\u003C\u002Fstrong> (delegatable sub-agents with their own identity) and \u003Cstrong>event hooks\u003C\u002Fstrong> (guardrails and nudges triggered automatically at each step of a session lifecycle). The whole system is driven by two configuration files that coexist.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Configuration file\u003C\u002Fth>\n      \u003Cth>Versioned\u003C\u002Fth>\n      \u003Cth>Contents\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Versioned settings file\u003C\u002Ftd>\n      \u003Ctd>Yes\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>PreToolUse\u003C\u002Fcode> \u002F \u003Ccode>PostToolUse\u003C\u002Fcode> \u002F \u003Ccode>Stop\u003C\u002Fcode> \u002F \u003Ccode>UserPromptSubmit\u003C\u002Fcode> hooks, environment variables, default permission mode\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Local settings file\u003C\u002Ftd>\n      \u003Ctd>No\u003C\u002Ftd>\n      \u003Ctd>Permission allowlist (several hundred entries), \u003Ccode>SessionStart\u003C\u002Fcode> \u002F \u003Ccode>UserPromptSubmit\u003C\u002Fcode> \u002F \u003Ccode>PreToolUse\u003C\u002Fcode> \u002F \u003Ccode>PostToolUse\u003C\u002Fcode> hooks, automatic mode\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Both sets of hooks are \u003Cstrong>cumulative\u003C\u002Fstrong>: for the same event (for example \u003Ccode>PreToolUse\u003C\u002Fcode> on the Bash tool), the commands from both files are executed. This is why Python guardrails live in the local file while shell nudges appear in the versioned file.\u003C\u002Fp>\n\n\u003Ch2 id=\"skills-catalogue\">Skills Catalogue\u003C\u002Fh2>\n\n\u003Cp>Each skill is an autonomous capability module, defined by a markdown description file. It can be invoked manually or triggered by the engine. Some internal skills are not intended for direct invocation.\u003C\u002Fp>\n\n\u003Ch3>Audit and System Health\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>General audit\u003C\u002Fstrong> — Full audit of a site or property: infrastructure healthcheck, public pages, SEO, performance, security, database. Produces a score out of 100.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Allowlist anti-rot\u003C\u002Fstrong> — Verifies that every path and named section in the immutable P0-level allowlist still exists. Guards against silent drift of critical references.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>SEO i18n audit\u003C\u002Fstrong> — Checks translation key parity FR↔EN, consistency of localised URL slugs, and the routing map. Must be run before any deployment touching pages, internationalisation, or routing.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Lexical registry audit\u003C\u002Fstrong> — Detects drift between the canonical dictionary in the database and code schemas. Strict read-only mode; returns a healthy or drifted exit code.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Personas audit\u003C\u002Fstrong> — Compares agent personas against the current stack and records a drift snapshot in the dedicated history.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>System status\u003C\u002Fstrong> — Checks the overall system status (services, connectivity, resources).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Session context status\u003C\u002Fstrong> — Returns the state of the current session context.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Infrastructure and Hosts\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Infra audit\u003C\u002Fstrong> — Checks availability, load, services, SSL certificates and backups for a given host.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Security audit\u003C\u002Fstrong> — Security audit of a host (the mothership VPS or a client VPS).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Backup verification\u003C\u002Fstrong> — Checks the freshness and integrity of local backups on a host.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>System update\u003C\u002Fstrong> — Runs a non-interactive APT update with Docker package pinning.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Bot analysis\u003C\u002Fstrong> — Analyses the robot hit log collected by the server.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>GSC query\u003C\u002Fstrong> — Queries the Google Search Console API to surface SEO opportunities.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Project Steering\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Project\u003C\u002Fstrong> — Drives the \"1 project = N tasks\" doctrine: skeleton creation, task tracking, database read of projects and their associated tasks.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Run\u003C\u002Fstrong> — Opens a scoped run (lightweight unit symmetric to the project). Loads the scope from the database (mothership, tenant, deal) and returns the current line. \u003Cem>Distinct from the native application launcher.\u003C\u002Fem>\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Deal\u003C\u002Fstrong> — Loads the full context of a commercial deal: file, qualification, team, log, deliverables. Symmetric to the project for the prospect → contract pipeline.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Idea\u003C\u002Fstrong> — Creates a brainstorm note in the dedicated table.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Review\u003C\u002Fstrong> — Place des Armes review: each agent introduces itself and reports its status.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Post-project lesson\u003C\u002Fstrong> — Generates a pedagogical lesson after a project (Montessori method) and deposits it in the Obsidian Vault inbox.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Email and Inbox\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Inbox (façade)\u003C\u002Fstrong> — Reads and searches emails via the application façade, in the database.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Direct inbox\u003C\u002Fstrong> — Fallback IMAP access, read-only, no database writes. Used when the façade is unavailable.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Inbox search\u003C\u002Fstrong> — Ergonomic wrapper for email retrieval and analysis: download in \u003Ccode>.eml\u003C\u002Fcode> format, attachment listing without prior extraction (scan-first approach).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Attachment scan\u003C\u002Fstrong> — Antivirus analysis of an attachment before opening, via the Mitnick agent.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Commercial proposal check\u003C\u002Fstrong> — QA of a commercial proposal before email dispatch, orchestrated across a pool of four agents.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Memory and Knowledge\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Semantic recall\u003C\u002Fstrong> — RAG (retrieval-augmented generation) search by vector similarity over the documentary memory and the scars, doctrines, and projects in the database. Uses high-dimensional cosine embeddings.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Zettelkasten\u003C\u002Fstrong> — Decomposes a monolithic document into atomic notes for the Obsidian Vault.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Technical dictionary\u003C\u002Fstrong> — Adds terms to the shared technical dictionary.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Victory\u003C\u002Fstrong> — Records a victory as a \u003Ccode>victory\u003C\u002Fcode>-type scar in the database.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Persona refresh\u003C\u002Fstrong> — Updates an agent persona via an AI model, a three-way comparison and a review, then persists the update to the database.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Finance and Business\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Bank\u003C\u002Fstrong> — Queries accounts and transactions via the banking façade.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Bank import\u003C\u002Fstrong> — Manual import of transactions from an N26 CSV export into the database transactions table.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Invoicing\u003C\u002Fstrong> — Creates, lists, generates PDFs and sends invoices and quotes via the invoicing façade. Manages recurring subscriptions. The canonical issuing entity is always the system owner's legal entity.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Malt prospects\u003C\u002Fstrong> — Retrieves prospect conversations from the Malt platform.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Publishing and SEO\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Article publishing\u003C\u002Fstrong> — Publishes a blog article to the designated web property.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scar publishing\u003C\u002Fstrong> — Full pipeline: curation → sanitisation → adversarial review by Mitnick → publication of Synedre's public scars. Publishes the trophy scar (extracted lesson); \u003Cstrong>never publishes\u003C\u002Fstrong> the tutorial scar (exploitable reproduction).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>SEO sentinel\u003C\u002Fstrong> — Early detection of ranking haemorrhage across multiple properties. Launches the monitoring automation and reformulates the report.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Documentation and QA\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Technical documentation\u003C\u002Fstrong> — Generates or refreshes technical documentation via multi-agent orchestration (authoring → verification → correction). Supports a selective refresh mode (stale pages only) and a no-synthesis mode. Never commits without explicit validation.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Visual QA\u003C\u002Fstrong> — Captures a screenshot via Playwright and submits the image to a multimodal sub-agent to verify that the visual intent is correctly rendered — beyond mere code execution success.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Site clone\u003C\u002Fstrong> — Generates the \"server access and information\" intake protocol for cloning a client's existing site onto a VPS, and drafts the access request email.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"skills-db-sources\">Database Sources of Truth\u003C\u002Fh2>\n\n\u003Cp>Skills do not store business data: they query the central database via dedicated tables. The following maps the main skills to their persisted entities:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Skill\u003C\u002Fth>\n      \u003Cth>Database entities\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Project\u003C\u002Ftd>\n      \u003Ctd>Projects table, project tasks table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Semantic recall\u003C\u002Ftd>\n      \u003Ctd>Scars table, doctrines table, projects table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Victory\u003C\u002Ftd>\n      \u003Ctd>Scars table (\u003Ccode>kind = 'victory'\u003C\u002Fcode>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Idea\u003C\u002Ftd>\n      \u003Ctd>Brainstorm table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Personas audit\u003C\u002Ftd>\n      \u003Ctd>Persona drift history table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Persona refresh\u003C\u002Ftd>\n      \u003Ctd>Agents table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Inbox\u003C\u002Ftd>\n      \u003Ctd>Inbox emails table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Bank import\u003C\u002Ftd>\n      \u003Ctd>Bank transactions table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architecture note:\u003C\u002Fstrong> a pre-invocation hook queries the declared size of each skill in the database to decide whether a deferred load (three-level lazy-load) should be suggested, in order to preserve session context for large skills.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"sous-agents-fichiers\">Sub-agents: delegable personality files\u003C\u002Fh2>\n\n\u003Cp>The system includes around thirty \u003Cstrong>agent personality files\u003C\u002Fstrong>, each delegable via the internal delegation mechanism. Each file describes a named agent: its role, delegation criteria, authorized tools, and target language model.\u003C\u002Fp>\n\n\u003Cp>Part of each file is \u003Cstrong>automatically generated\u003C\u002Fstrong> from the database (persona data: canonical name, description, capabilities) and enclosed within managed-zone markers. The editorial zone — doctrine, operating mode, business instructions — is written by hand and \u003Cstrong>preserved across each regeneration\u003C\u002Fstrong>. The managed zone must never be edited manually: any modification would be overwritten at the next synchronization.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Source of truth:\u003C\u002Fstrong> the physical agents table (accessible in read mode via a dedicated view) is the sole reference. The regeneration script reads the view; the persona refresh tool writes to the base table. Both operate on the same source: no risk of divergence between view and table.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>Each personality file exposes three frontmatter metadata fields: a public name, a description serving as the automatic delegation criterion, and the list of authorized tools.\u003C\u002Fp>\n\n\u003Ch3>Execution agents\u003C\u002Fh3>\n\n\u003Cp>These agents have both read \u003Cem>and\u003C\u002Fem> write access, as well as the ability to execute system commands. They act directly on repository artifacts and infrastructure.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Public codename\u003C\u002Fth>\n      \u003Cth>Domain\u003C\u002Fth>\n      \u003Cth>Capabilities\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Brunel\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Infrastructure & DevOps — container orchestration, reverse proxy, SSL certificates, DNS, mothership VPS management\u003C\u002Ftd>\n      \u003Ctd>Read, write, execute, search\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Turing\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Backend & server reliability — Nuxt application layer, business modules, Python scripts, database integrity\u003C\u002Ftd>\n      \u003Ctd>Read, write, execute, search\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Eames\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Frontend — Nuxt 4 \u002F Vue 3 \u002F Tailwind interface, design system, hub pages\u003C\u002Ftd>\n      \u003Ctd>Read, write, execute, search\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Otlet\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Technical SEO — structured markup, sitemap, Core Web Vitals, redirects, AI indexability\u003C\u002Ftd>\n      \u003Ctd>Read, write, execute, search\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Lovelace\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Quality assurance — last gate before production, acceptance testing, regression detection\u003C\u002Ftd>\n      \u003Ctd>Read and search only (\u003Cstrong>no write access\u003C\u002Fstrong>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Mitnick\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Offensive & defensive security — attachment analysis, exposed secret detection, OWASP audit\u003C\u002Ftd>\n      \u003Ctd>Read and search only (\u003Cstrong>no write access\u003C\u002Fstrong>)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Lovelace\u003C\u002Fstrong> and \u003Cstrong>Mitnick\u003C\u002Fstrong> deliberately hold no write or execution rights: their role is control, not mutation. Mitnick in attachment-analysis mode is a tooling instrument (a prerequisite step before any workstream), not a recruited team member.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Advisory and knowledge agents\u003C\u002Fh3>\n\n\u003Cp>These agents have read-only access to the repository and documentary sources. They produce analyses, recommendations, drafts, and reports — never direct execution or file modification.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Public codename\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Atlas\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Architect & project lead — partitions work into workstreams, dispatches to specialized agents, orchestrates delegation doctrine\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Audiard\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Audio author — rewriting for the ear (rhythm, orality, breath)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Bernays\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Business growth — lead pipeline, conversion funnels\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Bernhardt\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Audio quality control — scoring (9.5\u002F10 blocking threshold), diction, fidelity to source text\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Braille\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Accessibility — WCAG 2.2 AA compliance (keyboard navigation, contrast ratios, ARIA)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Clausewitz\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Strategy — consistency of product decisions against positioning\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Coco\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Brand guardian — tonal refinement, cross-channel visual consistency\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Colbert\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>General management — workstream prioritization, resource allocation, steering\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Dumas\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Narrator — serialized storytelling, emotional arcs, episodes, characters\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Gauss\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Data analysis — metrics (traffic, conversion, costs), insight reporting\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Hill\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Long-term vision — strategic direction, North Star\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Hokusai\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Illustration — character design & manga\u002Fmanhwa illustration via generative AI\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Itten\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Art direction — color palette, typography, design tokens\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Marco Polo\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Intelligence — technology, competitive, and market monitoring\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Méliès\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>AI visual production — portraits, scenes, covers, prompt engineering\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Montesquieu\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Legal counsel (EU law) — GDPR, terms of service, digital law\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Montessori\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Pedagogy — learning modules, glossary, learner pathways\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Nightingale\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Customer success — drafting client communications, \u003Cstrong>no direct sending\u003C\u002Fstrong>\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Ogilvy\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Copywriting — persuasive tone, message clarity, CTAs, cross-channel consistency\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Pacioli\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>FinOps — AI cost tracking, infrastructure, services, financial reconciliation\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Pulitzer\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Content & SEO blog — articles, covers, internal linking\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Renoir\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Scheduling supervision — automation orchestration, timetables, inter-task quiet periods\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Socrate\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Dialogue & community — maieutic questioning, FAQ, clarification of assumptions\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Winnicott\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Operational balance — overload detection, pace adjustments\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Design invariants\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Nightingale\u003C\u002Fstrong> holds no system execution capability: it operates in strict read-only mode, ensuring the system never communicates directly with a client without human validation.\u003C\u002Fli>\n  \u003Cli>All advisory agents (previous section) operate in read-only mode: zero execution, zero write access.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Atlas\u003C\u002Fstrong> enforces the workstream doctrine: for any significant scope, at least two distinct agents are engaged, and delegation passes through the internal delegation mechanism — never via direct call.\u003C\u002Fli>\n  \u003Cli>Residual drift may occur between the managed zone of an agent file and the actual data in the database if a manual synchronization has taken place. The source of truth remains the physical agents table at all times; the \u003Ccode>refresh-persona\u003C\u002Fcode> and \u003Ccode>audit-personas\u003C\u002Fcode> tools allow any discrepancy to be corrected.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"hooks-carte-evenements\">4. Hooks\u003C\u002Fh2>\n\n\u003Ch3>4.1 Event Map\u003C\u002Fh3>\n\n\u003Cp>The harness intercepts the agent lifecycle at six key points. Each interception can be \u003Cstrong>blocking\u003C\u002Fstrong> (the agent does not proceed) or \u003Cstrong>non-blocking\u003C\u002Fstrong> (warning only). The following table summarises the complete map:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Interception point\u003C\u002Fth>\n      \u003Cth>Targeted tool\u003C\u002Fth>\n      \u003Cth>Triggered mechanisms\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Session start\u003C\u002Ftd>\n      \u003Ctd>(local)\u003C\u002Ftd>\n      \u003Ctd>Context reset, brief generation, scar injection\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>User prompt submission\u003C\u002Ftd>\n      \u003Ctd>versioned + local\u003C\u002Ftd>\n      \u003Ctd>DB schema synchronisation, mailbox synchronisation (Nightingale agent)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Read\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Antivirus check on attachments (fail-closed)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Shell command\u003C\u002Ftd>\n      \u003Ctd>versioned + local\u003C\u002Ftd>\n      \u003Ctd>8 shell nudges and guards, 3 Python guardrails\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Agent\u003C\u002Ftd>\n      \u003Ctd>versioned + local\u003C\u002Ftd>\n      \u003Ctd>Agent reactor, scar injection\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Skill\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Lightweight view suggestion when a skill card is large\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Edit\u002FWrite\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Decentralised reflex engine (deny\u002Fwarn\u002Fallow decision, audit trail)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-use — Edit\u002FWrite\u003C\u002Ftd>\n      \u003Ctd>local\u003C\u002Ftd>\n      \u003Ctd>Scar injection\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Post-use — Shell command\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Reaction log, post-commit preprod deployment\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Post-use — Agent\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Reactor, reaction log, telemetry\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Post-use — Multiple edits\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Tracking of files edited during the session\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Post-use — All tools\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>CLI cockpit event (best-effort, non-blocking)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Post-use — All tools\u003C\u002Ftd>\n      \u003Ctd>local\u003C\u002Ftd>\n      \u003Ctd>Token \u002F context counting\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Session end (Stop)\u003C\u002Ftd>\n      \u003Ctd>versioned\u003C\u002Ftd>\n      \u003Ctd>Cockpit end-of-turn signal → worksite lock release → scar reminder → commit check → worksite synchronisation\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>4.2 Session Start\u003C\u002Fh3>\n\n\u003Cp>Three operations run at the opening of each session, each with a 5-second timeout:\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>Context counter reset\u003C\u002Fstrong> — the context tracking module resets to zero for the current session.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Brief generation\u003C\u002Fstrong> — the report generator reads a pre-computed report (produced each night around 05:00 UTC by a scheduled task of the \u003Cem>daily audit\u003C\u002Fem> type) and enriches it in real time: git status, crontab, pending client emails, backlog, scars. The result is injected into the startup context. No npm dependency is required; database reads are performed via the mother-ship's containerised database engine.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scar injection\u003C\u002Fstrong> — scars relevant to the session are injected into the initial context.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Configuration note:\u003C\u002Fstrong> the session-start hook is \u003Cem>not\u003C\u002Fem> present in the shared versioned configuration file — it lives solely in the local (unversioned) configuration file. This separation is intentional: the startup operations access local resources (database, inbox) that are only available on the mother-ship.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.3 User Prompt Submission\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Versioned file\u003C\u002Fstrong>: database schema dump synchronisation on every prompt — the agent always has a fresh view of the table structure.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Local file\u003C\u002Fstrong>: mailbox synchronisation (Nightingale agent, 15 s timeout) — on every prompt, newly received emails are pulled into the inbox tracking table. This mechanism is implemented as a \u003Cstrong>dedicated skill\u003C\u002Fstrong> exposed via the application facade; the actual synchronisation script is distinct from the direct-read script.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Corrective history:\u003C\u002Fstrong> until mid-2026, this hook pointed to a ghost script that had never been migrated, causing it to fail silently. The fix also updated the email guardrail whitelist, which was referencing the same obsolete script.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>4.4 Pre-use (PreToolUse)\u003C\u002Fh3>\n\n\u003Ch3>Antivirus guard — Read tool (blocking, versioned)\u003C\u002Fh3>\n\n\u003Cp>Any attempt to read an attachment from the temporary quarantine area is \u003Cstrong>blocked\u003C\u002Fstrong> if a clean antivirus verdict marker is not present for that file. This reflex is \u003Cem>fail-closed\u003C\u002Fem>: in the absence of the marker, access is denied. It has no dependency on the database — it evaluates solely on the presence or absence of the verdict file.\u003C\u002Fp>\n\n\u003Ch3>Shell guards — Command tool (versioned)\u003C\u002Fh3>\n\n\u003Cp>Eight scripts run in sequence before any shell command is executed:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Guard\u003C\u002Fth>\n      \u003Cth>Behaviour\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Attachment antivirus check\u003C\u002Ftd>\n      \u003Ctd>Same fail-closed logic as for the Read tool: blocks shell commands that would open an unscanned attachment.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Production deployment command block (\u003Ccode>.\u002Fship\u003C\u002Fcode>)\u003C\u002Ftd>\n      \u003Ctd>\u003Cstrong>Blocking\u003C\u002Fstrong> — the agent can never trigger a public production deployment on its own. Trunk reflex, zero runtime dependency.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Database mutation check\u003C\u002Ftd>\n      \u003Ctd>Blocks any destructive mutation on internal system tables if no aligned code commit has occurred within the last five minutes. Embodies the \"code before database\" doctrine.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-deployment auto-commit\u003C\u002Ftd>\n      \u003Ctd>Automatically performs a commit before a \u003Ccode>.\u002Fdeploy\u003C\u002Fcode> execution.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Worksite skeleton nudge\u003C\u002Ftd>\n      \u003Ctd>Warns if a raw SQL insert on a worksite is attempted instead of using the dedicated skeleton-based creation command.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Pre-commit leak scan\u003C\u002Ftd>\n      \u003Ctd>Scans files about to be committed to detect potential leaks (secrets, sensitive data) before they enter the git history. Timeout: 10 s.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Existing worksites reminder\u003C\u002Ftd>\n      \u003Ctd>Non-blocking (30 s timeout) — when a new worksite is created, performs a hybrid recall (lexical + semantic search) and injects the four closest worksites or doctrines. Prevents reinventing existing work.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Documentation binding nudge\u003C\u002Ftd>\n      \u003Ctd>Warning only (never blocking) — at git commit time, cross-references modified files with the binding contracts of documentation chapters. If a file bound to a chapter is touched, reminds to verify that the chapter is still accurate.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Maintainer note:\u003C\u002Fstrong> a back-office authentication control script exists in the repository but is not referenced in any active configuration file — it is dormant and has no effect.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Python guardrails — Command tool (local)\u003C\u002Fh3>\n\n\u003Cp>Three additional blocking guardrails run from the local configuration:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Guardrail\u003C\u002Fth>\n      \u003Cth>Behaviour\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Client production environment protection\u003C\u002Ftd>\n      \u003Ctd>Blocks any shell command targeting a client production environment with a destructive write pattern (TRUNCATE, DROP, DELETE, ALTER, UPDATE, direct pipe import). Three layers of false-positive mitigation: (1) commands targeting the mother-ship itself are short-circuited before the client test; (2) commands targeting client preprod pass without check; (3) non-destructive queries (SELECT, SHOW, simple INSERT) are not targeted — only nine families of dangerous operations are actually blocked. Authorised write commands must go through the dedicated secured script.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Email facade protection\u003C\u002Ftd>\n      \u003Ctd>Blocks any bypass of the official email sending facade. Direct use of low-level SMTP\u002FIMAP libraries or unofficial sending aliases is forbidden. Only the send, inbox sync, direct read, and specialised mailbox scripts listed in the whitelist are permitted — each accepted with or without a relative path. The ghost script that was never migrated was removed from the whitelist during the mid-2026 fix.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Contextual scar injection\u003C\u002Ftd>\n      \u003Ctd>Injects scars related to the command currently being evaluated. Timeout: 3 s.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Email facade evolution (mid-2026):\u003C\u002Fstrong> the facade automatically sends a validation copy to the human operator for each draft created (\u003Cem>show-before-send\u003C\u002Fem> mechanism applied in practice, not merely declarative). The actual send automatically appends the canonical HTML signature. A Markdown-to-email-safe HTML conversion mode is available. At draft time, the writing tone appropriate for the recipient is displayed (best-effort, non-blocking). A mode to resend a validation copy on an existing draft is also available, without recreating the draft.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Reflex engine — Edit\u002FWrite tool (versioned)\u003C\u002Fh3>\n\n\u003Cp>Before any file edit, the \u003Cstrong>decentralised reflex engine\u003C\u002Fstrong> comes into play. It reads the incoming hook event, loads the active rules from the system reflex table, evaluates a decision (\u003Cem>deny\u003C\u002Fem>, \u003Cem>warn\u003C\u002Fem>, or \u003Cem>allow\u003C\u002Fem>), and traces the event to the reflex audit table. Targeted fail-closed handling:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>If the primary database is unreachable: blocking applies only to sensitive code areas (the core of the main product); outside the sensitive area, control is left to the agent.\u003C\u002Fli>\n  \u003Cli>If a Python error occurs within the engine itself: switches to \u003Cem>allow\u003C\u002Fem> with a trace to standard error — a bug in the guard never blocks work.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>In parallel, the scar injection script (local configuration) runs cumulatively for the same edit event.\u003C\u002Fp>\n\n\u003Ch3>Agent and Skills\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Agent tool:\u003C\u002Fstrong> the agent reactor (versioned) and the agent scar injection script (local) run before any agent sub-call.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Skill tool:\u003C\u002Fstrong> a non-blocking hook (5 s timeout, guaranteed exit 0) suggests using the lightweight view of a skill card when it exceeds a configured size threshold.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.5 Post-use (PostToolUse)\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\n    \u003Cstrong>Shell command:\u003C\u002Fstrong> two hooks run in sequence.\n    \u003Col>\n      \u003Cli>The reaction log records the command result.\u003C\u002Fli>\n      \u003Cli>The automatic post-commit preprod deployment analyses the paths touched and determines the impacted site. \u003Cstrong>Important nuance:\u003C\u002Fstrong> for client sites, this is a preprod deployment; for the mother-ship itself, no preprod exists — \u003Ccode>.\u002Fdeploy\u003C\u002Fcode> triggers a live rebuild. The hook skips deployment if the commit message contains an exclusion directive (\u003Ccode>[skip-deploy]\u003C\u002Fcode> \u002F \u003Ccode>[no-deploy]\u003C\u002Fcode> \u002F \u003Ccode>wip:\u003C\u002Fcode> prefix), if the commit touches only documentation with no runtime file, or if the working directory is dirty after the commit.\u003C\u002Fli>\n    \u003C\u002Fol>\n  \u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Agent:\u003C\u002Fstrong> reactor, reaction log, telemetry (5 s timeout).\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Multiple edits:\u003C\u002Fstrong> the session-edited file tracker (3 s timeout) maintains the list of modified files, subsequently used by the session-end hook.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>All tools:\u003C\u002Fstrong> the CLI cockpit activity mirror (10 s timeout) emits an event to the active worksite tracking dial. It activates only if an active worksite is registered; if the disable environment variable is set or no worksite is linked, it exits immediately at no cost. Non-blocking: a missed event never blocks the tool call.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>All tools (local):\u003C\u002Fstrong> the context token counter (5 s timeout) updates the session consumption metrics.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>4.6 Session End (Stop)\u003C\u002Fh3>\n\n\u003Cp>Five operations run sequentially at the close of each session:\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\u003Cstrong>End-of-turn cockpit signal\u003C\u002Fstrong> (9 s timeout) — emits an end-of-turn fragment into the worksite tracking dial timeline, only if the feature is enabled and a worksite is linked.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Worksite lock release\u003C\u002Fstrong> (3 s timeout) — releases the session lock on the current worksite.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scar reminder\u003C\u002Fstrong> — triggered only if the last user message contains a closing keyword (\"closing\", \"end of session\", \"wrapping up\"…). When triggered, lists corrective commits since the last preprod push via standard error, and returns a blocking exit code.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Commit check\u003C\u002Fstrong> (5 s timeout, \u003Cstrong>blocking\u003C\u002Fstrong>) — refuses closure if files modified \u003Cem>during this session\u003C\u002Fem> are uncommitted. Forces a streaming commit. Key mechanics:\n    \u003Cul>\n      \u003Cli>\u003Cstrong>Session-aware:\u003C\u002Fstrong> only files from the current session are checked — multiple parallel Claude sessions do not block each other.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Anti-loop:\u003C\u002Fstrong> if the hook detects it is already on a second pass, it switches to a non-blocking warning instead of a hard block.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Worker short-circuit:\u003C\u002Fstrong> if the session is a sub-agent spawned by the automated task engine, the hook exits silently — the worker manages its own commit cycle.\u003C\u002Fli>\n      \u003Cli>The session configuration file itself is excluded from the check.\u003C\u002Fli>\n    \u003C\u002Ful>\n  \u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Worksite synchronisation\u003C\u002Fstrong> (8 s timeout) — synchronisation reminder between the local worksite state and the hub database.\u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>4.7 Worker Context Convention\u003C\u002Fh3>\n\n\u003Cp>A shared utility module, sourced by the four session-end hooks, implements a systematic early exit when the session is a sub-agent spawned by the automated task engine. This convention guarantees that a sub-agent:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>does not trigger closing scar reminders,\u003C\u002Fli>\n  \u003Cli>does not release locks that belong to the parent session,\u003C\u002Fli>\n  \u003Cli>is not blocked by the commit check (it manages its own cycle),\u003C\u002Fli>\n  \u003Cli>does not pollute the main user session's worksite synchronisation.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The worker context environment variable is injected by the task engine's spawn module at sub-agent creation time. This separation is a general rule: what belongs to the user session does not apply to automated agents, and vice versa.\u003C\u002Fp>\n\u003Ch2 id=\"permissions-env\">Permissions and Execution Environment\u003C\u002Fh2>\n\n\u003Ch3>Main Configuration\u003C\u002Fh3>\n\n\u003Cp>The agent's main configuration file defines two key parameters:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>An \u003Ccode>env\u003C\u002Fcode> block enabling experimental engine variables (agent teams, flicker-free rendering).\u003C\u002Fli>\n  \u003Cli>A \u003Ccode>permissions\u003C\u002Fcode> block with \u003Ccode>defaultMode: auto\u003C\u002Fcode> — the agent runs without requesting confirmation at each step, which is consistent with the autonomy policy enforced by the \u003Ccode>.\u002Fdeploy\u003C\u002Fcode> command.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Local Configuration and Data Access Policy\u003C\u002Fh3>\n\n\u003Cp>A second configuration file, specific to the host machine and excluded from the versioned repository, refines the authorization policy:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>The allowlist includes several hundred pre-approved tools and commands; no explicit denylist is defined at this level.\u003C\u002Fli>\n  \u003Cli>Local environment variables are deliberately empty: no secrets are injected through this channel.\u003C\u002Fli>\n  \u003Cli>A natural-language policy block specifies database access rules per environment:\n    \u003Cul>\n      \u003Cli>\u003Cstrong>Read-only\u003C\u002Fstrong> access authorized on a given client's \u003Cem>staging\u003C\u002Fem> environment.\u003C\u002Fli>\n      \u003Cli>\u003Cstrong>Production writes\u003C\u002Fstrong> subject to explicit confirmation for each operation — the rule cannot be bypassed through context accumulation.\u003C\u002Fli>\n      \u003Cli>An explicit reminder distinguishes the two VPS instances involved (production and staging) to prevent any confusion during operations.\u003C\u002Fli>\n    \u003C\u002Ful>\n  \u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>This declarative policy is backed by an executable safeguard (described in section 4): the rule is therefore enforced at two independent levels — the configuration and the verification hook — constituting a defense-in-depth approach.\u003C\u002Fp>\n\n\u003Ch3>Secret Leak Prevention\u003C\u002Fh3>\n\n\u003Cp>No secret appears in plaintext in hooks, skills, or agent definitions. Messaging credentials (inbound and outbound), database passwords, and API keys are referenced solely by their \u003Cstrong>variable name\u003C\u002Fstrong> in a local environment file excluded from version control. Their values are never written to any file tracked by the repository.\u003C\u002Fp>\n\n\u003Cp>Two complementary monitoring mechanisms ensure leak detection:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>A pre-commit hook scans transcripts before any commit to detect any sensitive value that may have been captured in the session history.\u003C\u002Fli>\n  \u003Cli>A dedicated attachment analysis skill detects potentially malicious content before processing.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"modele-donnees\">Data Model — Flow Overview\u003C\u002Fh2>\n\n\u003Cp>The following table summarizes the main functional domains of the data model, indicating for each which component produces the data and which component consumes it.\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Functional Domain\u003C\u002Fth>\n      \u003Cth>Producer\u003C\u002Fth>\n      \u003Cth>Consumer\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Agent registry (base table + read view)\u003C\u002Ftd>\n      \u003Ctd>Manual editing or persona refresh skill\u003C\u002Ftd>\n      \u003Ctd>Agent definition file regeneration script (reads the read view)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Worksites and associated tasks\u003C\u002Ftd>\n      \u003Ctd>Worksite skill, worksite business entity\u003C\u002Ftd>\n      \u003Ctd>Worksite synchronization and locking hooks\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Scars (memorized events)\u003C\u002Ftd>\n      \u003Ctd>Victory skill, stop hook\u003C\u002Ftd>\n      \u003Ctd>Recall skill, injection at session startup and before each tool\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Daily audit reports\u003C\u002Ftd>\n      \u003Ctd>Scheduled audit task\u003C\u002Ftd>\n      \u003Ctd>Session briefing script (injected at startup)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Skill index (size in bytes)\u003C\u002Ftd>\n      \u003Ctd>Automatic skill indexing\u003C\u002Ftd>\n      \u003Ctd>Skill pre-invocation hook\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Persona drift history\u003C\u002Ftd>\n      \u003Ctd>Persona audit\u003C\u002Ftd>\n      \u003Ctd>Manual drift review\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Ideas \u002F brainstorm\u003C\u002Ftd>\n      \u003Ctd>Idea submission skill\u003C\u002Ftd>\n      \u003Ctd>Hub brainstorm dashboard\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Email inbox\u003C\u002Ftd>\n      \u003Ctd>Inbound mail facade\u003C\u002Ftd>\n      \u003Ctd>Inbox read skill\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Bank transactions\u003C\u002Ftd>\n      \u003Ctd>Automated bank import\u003C\u002Ftd>\n      \u003Ctd>Banking consultation skill\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architectural note:\u003C\u002Fstrong> the agent registry relies on a \u003Cstrong>single base table\u003C\u002Fstrong> exposed through a \u003Cstrong>read view\u003C\u002Fstrong>. The regeneration script reads the view; the persona refresh skill writes directly to the base table. There are no two diverging tables: consistency is guaranteed and no migration is required.\u003C\u002Fp>\n\u003C\u002Fblockquote>",{"slug":14,"chapterNum":15,"title":16,"titleEn":17},"facades","10","catalogue des façades et points d'entrée du harness","harness facade and entry-point catalogue",null,{"chapters":20},[21,28,35,42,49,56,63,70,77,84,87],{"slug":22,"chapterNum":23,"title":24,"titleEn":25,"summary":26,"summaryEn":27},"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":29,"chapterNum":30,"title":31,"titleEn":32,"summary":33,"summaryEn":34},"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":36,"chapterNum":37,"title":38,"titleEn":39,"summary":40,"summaryEn":41},"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":43,"chapterNum":44,"title":45,"titleEn":46,"summary":47,"summaryEn":48},"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":50,"chapterNum":51,"title":52,"titleEn":53,"summary":54,"summaryEn":55},"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":57,"chapterNum":58,"title":59,"titleEn":60,"summary":61,"summaryEn":62},"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":64,"chapterNum":65,"title":66,"titleEn":67,"summary":68,"summaryEn":69},"email","07","Inbox hub & Atlas Inbox — deux pipelines email","Inbox hub & Atlas Inbox — two email pipelines","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":71,"chapterNum":72,"title":73,"titleEn":74,"summary":75,"summaryEn":76},"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.",{"slug":78,"chapterNum":79,"title":80,"titleEn":81,"summary":82,"summaryEn":83},"deploy","09","Déploiement & infrastructure","Deployment & infrastructure","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":14,"chapterNum":15,"title":16,"titleEn":17,"summary":85,"summaryEn":86},"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":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10}]