[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fnvG29OCi3XGslGm9X_CpTOzpGGftceHwBHPqd1yzSA4":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":19},{"chapter":4,"prev":13,"next":14},{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10,"contentHtml":11,"contentHtmlEn":12},"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.","\u003Ch2 id=\"what-is-harness\">1. Ce qu'est le harness\u003C\u002Fh2>\n\n\u003Cp>Le « harness » est l'ensemble du dispositif qui transforme une \u003Cstrong>demande\u003C\u002Fstrong> (un courriel transmis, un message dans une console de pilotage, un déclencheur planifié) en \u003Cstrong>action exécutée et déployée\u003C\u002Fstrong> (du code commité, une réponse préparée pour validation humaine, un site mis à jour), sans état métier stocké hors base de données.\u003C\u002Fp>\n\n\u003Cp>Trois principes le structurent :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Base de données unique.\u003C\u002Fstrong> La base PostgreSQL est la seule source de vérité métier. Les fichiers de documentation ne portent que des guides opérationnels, des schémas d'architecture et des doctrines. Tout référentiel (serveurs, clients, missions, agents, journaux d'apprentissage, exécutions) vit en table.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Asymétrie déploiement\u002Fpublication.\u003C\u002Fstrong> La mise à jour des environnements de préproduction est déclenchée automatiquement par le système. La mise en production finale est un geste \u003Cstrong>manuel et exclusif d'un opérateur humain\u003C\u002Fstrong>. Le système ne publie jamais en production de lui-même.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Gouvernance par garde-fous.\u003C\u002Fstrong> Vérifications antivirus obligatoires avant ouverture de toute pièce jointe, façade d'envoi de courriels unique soumise à validation, protection anti-fuite des secrets, procédure en sept étapes pour créer une mission structurée. Toute violation déclenche une dette architecturale prioritaire.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Le harness sert un \u003Cstrong>cockpit de pilotage privé\u003C\u002Fstrong> — distinct des produits e-commerce publics et des configurations spécifiques aux clients. Cette page ne couvre que le harness lui-même.\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"topology\">2. Topologie réelle\u003C\u002Fh2>\n\n\u003Cp>Trois couches d'exécution communiquent toutes avec le \u003Cstrong>même schéma PostgreSQL\u003C\u002Fstrong>, mais via des transports différents :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Le cockpit (application Nuxt 4 Nitro, mode standalone)\u003C\u002Fstrong> — l'interface de pilotage. Accès à la base via un pool \u003Cstrong>postgres-js\u003C\u002Fstrong> équipé d'un adaptateur de traduction SQL MySQL→PostgreSQL à la volée : substitution des paramètres positionnels, qualification du schéma sur les tables métier, conversion de \u003Ccode>INSERT IGNORE\u003C\u002Fcode>, \u003Ccode>DATE_SUB\u002FDATE_ADD\u003C\u002Fcode>, \u003Ccode>TIMESTAMPDIFF\u003C\u002Fcode>, \u003Ccode>IFNULL\u003C\u002Fcode> et des alias en camelCase. Certaines constructions MySQL ne sont pas converties automatiquement (\u003Ccode>ON DUPLICATE KEY UPDATE\u003C\u002Fcode>, \u003Ccode>LAST_INSERT_ID()\u003C\u002Fcode>, \u003Ccode>GROUP_CONCAT\u003C\u002Fcode>, \u003Ccode>FIND_IN_SET\u003C\u002Fcode>, \u003Ccode>DATE_FORMAT\u003C\u002Fcode>, \u003Ccode>CURDATE()\u003C\u002Fcode>) et doivent être portées manuellement. L'application se décompose en 27 modules indépendants.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>La couche d'automatisation Python (236 façades)\u003C\u002Fstrong> — orchestration, automates, mémoire, audits, courriels, déploiement. Accès à la base via un conteneur de base de données dédié, en passant les requêtes par sous-processus.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Les scripts et le planificateur\u003C\u002Fstrong> — wrappers de déploiement, spawn du moteur LLM via pseudo-TTY, extraction de pièces jointes, sauvegardes, tests de régression. Le planificateur intégré à l'application Nuxt est hors service depuis mai 2026 ; l'ordonnancement repose exclusivement sur le crontab Linux de la machine hôte (69 entrées actives).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cpre>\u003Ccode>                    DEMANDE\n courriel transmis ──┐       ┌─── console de pilotage\n boîte agentique     │       │    (scopée mothership | tenant)\n                     ▼       ▼\n     ┌─────────────────────────────────────────────────────┐\n     │  COUCHE PYTHON — 236 façades                        │\n     │  Orchestrateur : poll + classification + spawn       │\n     │  Exécution : worker de tâches, cycle ReAct           │\n     │  Mémoire \u002F audits \u002F courriels \u002F déploiement          │\n     │  Invocation LLM headless via pseudo-TTY              │\n     │                    (jamais subprocess direct)         │\n     └──────────────┬──────────────────────┬───────────────┘\n    sous-processus  │                       │ SSH + conteneur\n                    ▼                       ▼\n     ┌────────────────────────┐   ┌──────────────────────────┐\n     │  POSTGRESQL            │   │  COCKPIT (Nuxt 4)        │\n     │  schéma unique         │◄──┤  interface de pilotage   │\n     │  271 tables + 18 vues  │   │  pool postgres-js        │\n     │  tables métier         │   │  adaptateur MySQL→PG     │\n     │  vues-shim legacy      │   │  27 modules              │\n     └────────────────────────┘   └──────────────────────────┘\n                    ▲\n     planificateur  │  crontab Linux (69 entrées)\n     (Nitro hors    │  scripts shell \u002F Node\n      service)      │\n     ┌──────────────┴──────────────────────────────────────┐\n     │  SCRIPTS ET CRON — déploiement, hooks, sauvegardes  │\n     │  Asymétrie : déploiement préproduction = automatique │\n     │              publication production = geste humain   │\n     └─────────────────────────────────────────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>\u003Cstrong>Points d'attention architecturaux clés :\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Le schéma PostgreSQL est distinct de la base par défaut (\u003Ccode>public\u003C\u002Fcode>) ; une qualification explicite du schéma est requise sur toutes les requêtes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Douze tables du registre des agents sont en réalité des vues\u003C\u002Fstrong> qui encapsulent les tables physiques sous-jacentes — héritage d'une migration progressive. En lecture, utiliser les vues ; en écriture, cibler les tables physiques.\u003C\u002Fli>\n  \u003Cli>Une même entité « mission » est répartie entre des tables historiques (données de pilotage) et des tables cockpit (suivi d'exécution).\u003C\u002Fli>\n  \u003Cli>Le cockpit est \u003Cstrong>standalone\u003C\u002Fstrong> : il n'étend pas la base de code e-commerce. La sécurité réelle repose sur l'infrastructure réseau (tunnel et porte de filtrage nginx) ; un middleware injecte automatiquement une session opérateur en interne.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Chr>\n\n\u003Ch2 id=\"lifecycle\">3. Cycle de vie complet d'une demande\u003C\u002Fh2>\n\n\u003Cp>Le chemin canonique « courriel → action déployée ». Deux portes d'entrée alimentent le même moteur d'orchestration : le \u003Cstrong>poll de la boîte agentique\u003C\u002Fstrong> et la \u003Cstrong>console de pilotage\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>(0) INGESTION\n    Un opérateur transmet un courriel vers la boîte agentique\n       │  planificateur *\u002F1 min — poll IMAP (SEARCH UNSEEN)\n       ▼\n    Enregistrement en base (brut) ──► file agentique (status='received')\n       │\n(0b) SCAN ANTIVIRUS (si pièce jointe — doctrine scan-first P0)\n       │  Analyse ClamAV + heuristiques (PDF malveillant, macros Office, exécutables)\n       │  verdict ∈ {clean, suspect, blocked} ; verdict ≠ clean ⇒ classification BLOQUÉE\n       ▼\n(1) CLASSIFICATION  (LLM via façade IA unifiée, énumération stricte, anti-injection)\n    classified_intent ∈ {run, chantier, question, noise, negociation, conseil}\n       │  matérialise au plus 1 ligne dans la table correspondante\n       ▼\n(2) SPAWN + ORCHESTRATION  (planificateur *\u002F5 min, décalé 120 s après classify)\n    Orchestrateur Python\n       │  verrou consultatif PostgreSQL (anti-double-spawn)\n       │  spawn du moteur LLM via pseudo-TTY (node-pty, stream-json) :\n       │    isolation de contexte inter-spawns (zéro fuite entre exécutions)\n       │    modèle configuré, mode permissions contrôlé\n       │    outillage optionnellement restreint (ex. validateur QA en lecture seule)\n       │    timeout configurable (défaut : 15 min, extensible à 40 min par l'appelant)\n       │    ⚠️ ordre des arguments CLI : les arguments varargs doivent précéder les flags\n       │    ⚠️ le flux de log doit se clore APRÈS l'émission de l'événement de sortie\n       │    ⚠️ le pipe stdout doit être drainé avant la sortie du processus\n       │  le moteur LLM dépose un fichier résultat JSON puis se termine\n       ▼\n    Post-traitement de l'orchestrateur\n       ├─ branche sans code (run\u002Fquestion\u002Fnegociation) → récapitulatif courriel → 'actioned'\n       └─ branche avec code (chantier) → déploiement en préproduction automatique\n              └─ Validation qualité à 2 niveaux par route :\n                     Niveau 1 — requête HTTP (statut + détection de patterns d'erreur,\n                                bypass SSH optionnel pour contournement du filtre nginx)\n                     Niveau 2 — navigateur Playwright chromium headless\n                                (erreurs console, erreurs de page, capture d'écran)\n                     Filtres de bruit : erreurs 401 et ERR_HTTP2 ignorées\n                                        sur les environnements preprod protégés\n                    ├─ OK   → récapitulatif courriel vers l'opérateur → status='actioned'\n                    └─ FAIL → re-spawn (max 3 itérations) sinon escalade humaine\n       ▼\n(3) MISSION STRUCTURÉE (si intent=chantier, voir documentation dédiée)\n    procédure 7 étapes : audit des agents → lettre de mission → recrutement ≥2 agents\n       │  création atomique : mission + travaux + tâches en une transaction\n       ▼\n    EXÉCUTION des agents : worker de tâches (*\u002F1 min) ou cycle ReAct\n       │  cascade de statut tâche→travail→mission (max 1 cran) ; équipe QA si recrutée\n       ▼\n    mission → 'test' (validation preprod, revue opérateur) ── manuel ──► publication → 'done'\n       ▼\n(4) APPRENTISSAGE (asynchrone)\n    journal d'apprentissage (échec\u002Fvictoire) → réindexation vectorielle →\n    suggestion validée par l'humain → règle dans la mémoire persistante →\n    réflexe disponible à la session suivante\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>Côté \u003Cstrong>courriels sortants\u003C\u002Fstrong>, rien ne part jamais directement vers un destinataire externe : tout transite par la façade d'envoi de courriels (rédaction → copie de validation pour l'opérateur → envoi après accord explicite). Le système écrit à l'opérateur interne, jamais au demandeur.\u003C\u002Fp>\n\n\u003Cp>L'\u003Cstrong>ordonnancement\u003C\u002Fstrong> repose sur le crontab Linux : poll IMAP et scan en continu (*\u002F1 min), spawn décalé (*\u002F5 min + 120 s), worker de tâches en continu (*\u002F1 min), plus 69 entrées cron actives pour les automates récurrents, les workers et les observateurs.\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"glossary\">4. Glossaire des noms cardinaux\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Nom\u003C\u002Fth>\n      \u003Cth>Définition\u003C\u002Fth>\n      \u003Cth>Support physique\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Orchestrateur (Atlas)\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Le chef d'orchestre du harness. Une \u003Cstrong>persona enregistrée en base\u003C\u002Fstrong> sans runtime propre : « être l'orchestrateur » = lancer un moteur LLM avec le prompt système dédié. Pilote la classification, le spawn, l'orchestration post-spawn.\u003C\u002Ftd>\n      \u003Ctd>Façades Python d'orchestration + module de spawn pseudo-TTY\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Agent\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Une \u003Cstrong>persona\u003C\u002Fstrong> (identité + cadre cognitif + périmètre métier) injectée dans le contexte d'un moteur LLM pour exécuter une tâche. 30 agents actifs, répartis en 4 familles : \u003Ccode>direction\u003C\u002Fcode>, \u003Ccode>cadrage\u003C\u002Fcode>, \u003Ccode>execution\u003C\u002Fcode>, \u003Ccode>validation\u003C\u002Fcode>. Un agent \u003Cstrong>délibère\u003C\u002Fstrong> (cycle ReAct), il n'exécute pas une routine figée.\u003C\u002Ftd>\n      \u003Ctd>Registre des agents en base ; persona chargée par une façade dédiée ; 30 définitions dans le répertoire des agents\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Automate\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Un \u003Cstrong>script déterministe\u003C\u002Fstrong> qui exécute une routine ; peut invoquer un LLM mais son flux de contrôle est codé en dur. Opposé conceptuel de l'agent.\u003C\u002Ftd>\n      \u003Ctd>Registre des automates en base ; journal d'exécution dédié\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Chantier\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Une \u003Cstrong>mission structurée multi-étapes\u003C\u002Fstrong>. Unité de travail de plus haut niveau. Créée atomiquement avec ≥1 travail et ≥1 tâche via une procédure dédiée. Hiérarchie : 1 chantier = N travaux = N tâches.\u003C\u002Ftd>\n      \u003Ctd>Table des missions en base\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Travail\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Un \u003Cstrong>lot granulaire\u003C\u002Fstrong> d'un chantier (phase ou sous-objectif), avec son agent responsable, son périmètre et ses critères de sortie. Porte les cascades de statut et le mécanisme de déblocage (\u003Ccode>travail-bis\u003C\u002Fcode>).\u003C\u002Ftd>\n      \u003Ctd>Table des travaux en base\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Tâche\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>L'\u003Cstrong>unité atomique\u003C\u002Fstrong> assignée à un agent, avec estimation de tokens et modèle recommandé.\u003C\u002Ftd>\n      \u003Ctd>Table des tâches en base\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Run\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Une \u003Cstrong>exécution scopée pilotée par l'orchestrateur\u003C\u002Fstrong> sur un périmètre (cockpit interne ou site client), le périmètre chargeant le contexte (serveur, client, boîte mail). Déclencheur : courriel transmis ou console de pilotage. \u003Cstrong>L'enregistrement d'exécution de tâche n'est PAS un run\u003C\u002Fstrong> : c'est l'unité d'exécution déléguée à un agent.\u003C\u002Ftd>\n      \u003Ctd>Table des runs en base ; console de pilotage dédiée\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Cicatrice\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Une \u003Cstrong>leçon gravée\u003C\u002Fstrong> d'une erreur (\u003Ccode>kind='failure'\u003C\u002Fcode>) ou d'un succès reproductible (\u003Ccode>kind='victory'\u003C\u002Fcode>). Indexée en vecteurs pour le rappel sémantique, scorée en importance, porte d'entrée de la boucle d'apprentissage.\u003C\u002Ftd>\n      \u003Ctd>Table des cicatrices en base + index vectoriel pgvector\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Orbite\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Anneau d'organisation des agents (1\u002F2\u002F3). Notion \u003Cstrong>double\u003C\u002Fstrong> : la colonne numérique de la base (sous-utilisée) ne mappe pas 1:1 sur le rendu visuel du réacteur, qui recalcule l'anneau depuis la famille (\u003Ccode>direction\u003C\u002Fcode>=1, \u003Ccode>cadrage\u003C\u002Fcode>\u002F\u003Ccode>execution\u003C\u002Fcode>=2, \u003Ccode>validation\u003C\u002Fcode>=3). C'est la famille qui fait foi.\u003C\u002Ftd>\n      \u003Ctd>Colonne \u003Ccode>orbite\u003C\u002Fcode> + colonne \u003Ccode>group_name\u003C\u002Fcode> dans le registre des agents\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Façade\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Un \u003Cstrong>point d'entrée unique obligatoire\u003C\u002Fstrong> pour une capacité, qui rend une opération non-contournable (courriels, invocation IA, scan antivirus, accès base de données). Souvent doublée d'un hook qui bloque le contournement.\u003C\u002Ftd>\n      \u003Ctd>Façades Python + hooks de vérification pré-outil\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Autres termes utiles : \u003Cstrong>knock-gate\u003C\u002Fstrong> (filtre nginx cookie+slug en amont du cockpit), \u003Cstrong>pseudo-TTY\u003C\u002Fstrong> (terminal virtuel obligatoire pour spawner le moteur LLM de façon programmatique), \u003Cstrong>scan-first\u003C\u002Fstrong> (doctrine : aucune pièce jointe ouverte avant verdict antivirus \u003Ccode>clean\u003C\u002Fcode>), \u003Cstrong>travail-bis\u003C\u002Fstrong> (travail portant une référence de déblocage pour déverrouiller un travail en attente).\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"hard-boundaries\">5. Les frontières dures (non-négociables)\u003C\u002Fh2>\n\n\u003Cp>Rappel condensé des règles que tout le harness fait respecter :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Base unique\u003C\u002Fstrong> — zéro contenu métier dans des fichiers statiques (JSON, TypeScript, Markdown) ; tout en base de données.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Anti-fuite de secrets P0\u003C\u002Fstrong> — aucun secret en clair dans un fichier versionné ; les secrets vivent dans des fichiers d'environnement hors dépôt, référencés par nom de variable uniquement.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scan antivirus avant ouverture\u003C\u002Fstrong> — toute pièce jointe reste fermée jusqu'au verdict \u003Ccode>clean\u003C\u002Fcode> du moteur antivirus.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Zéro communication client directe par le système\u003C\u002Fstrong> — façade d'envoi de courriels + validation humaine avant envoi + prise de rendez-vous uniquement via le lien Calendly canonique.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Procédure 7 étapes\u003C\u002Fstrong> — aucun chantier sans création atomique via la procédure dédiée, avec ≥2 agents distincts pour un périmètre client.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Commit en flux\u003C\u002Fstrong> — aucun travail terminé sans commit immédiat ; l'IA commit, l'opérateur humain ne tape jamais les commandes git de bas niveau ; un hook bloquant garantit l'invariant à chaque fin de session.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Chr>\n\n\u003Ch2 id=\"pages\">6. Les autres pages de la documentation\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Page\u003C\u002Fth>\n      \u003Cth>Sous-système couvert\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>02 — La couche données\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Base de données unique, préfixes de tables, adaptateur MySQL→PostgreSQL, classes Entity Python, vues-shim legacy, i18n en base\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>03 — Le cœur agentique\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Orchestrateur, modèle d'agents, classification d'intent, spawn pseudo-TTY, orchestration déploiement→QA→courriel, orbites, calibration\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>04 — Chantiers, travaux et tâches\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Hiérarchie mission\u002Ftravail\u002Ftâche, création atomique, procédure 7 étapes, verrou multi-session, cascades de statut, travail-bis\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>05 — Automates, crons et runs\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>236 façades, wrapper cron, registre des automates, distinction run \u002F enregistrement de tâche, double planificateur (Nitro hors service + crontab)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>06 — Le cockpit\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Application Nuxt, modules, pages de pilotage, endpoints internes, authentification knock-gate + auto-session, consoles\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>07 — Boîte de réception, boîte agentique et courriels\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Deux pipelines IMAP (cockpit vs boîte agentique), façade d'envoi de courriels, scan antivirus, zéro communication directe\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>08 — Mémoire et apprentissage\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Mémoire 3 niveaux (fichiers persistants \u002F notes \u002F index vectoriel), rappel RAG, boucle cicatrices→suggestions→leçons, façade IA unifiée\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>09 — Déploiement et infrastructure\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Asymétrie déploiement\u002Fpublication, dispatcher YAML, build + transfert compressé, auto-déploiement du cockpit, inventaire serveurs, secrets, commit avant déploiement\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>10 — Catalogue des façades et points d'entrée\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Recensement des façades Python + scripts par famille, mode d'invocation (cron\u002FCLI\u002Fskill\u002Fhook\u002Flib), hooks recensés\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>11 — Skills, agents et hooks\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Compétences slash-commandes, définitions des sous-agents, hooks de configuration + permissions\u002Fenv\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n","\u003Ch2 id=\"what-is-harness\">1. What the harness is\u003C\u002Fh2>\n\n\u003Cp>The \"harness\" is the set of mechanisms that transforms a \u003Cstrong>request\u003C\u002Fstrong> (a forwarded email, a message in a control console, a scheduled trigger) into a \u003Cstrong>deployed action\u003C\u002Fstrong> (committed code, a response drafted for human review, an updated website), with no business state stored outside the database.\u003C\u002Fp>\n\n\u003Cp>Three principles structure it:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Database-first.\u003C\u002Fstrong> The PostgreSQL database is the single source of truth for all business data. Documentation files carry only operational guides, architecture diagrams, and doctrines. Every registry (servers, clients, missions, agents, learning journals, executions) lives in a table.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Deploy\u002Fpublish asymmetry.\u003C\u002Fstrong> Staging environment updates are triggered automatically by the system. The final production release is a \u003Cstrong>manual, human-exclusive action\u003C\u002Fstrong>. The system never publishes to production on its own.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Governance through guardrails.\u003C\u002Fstrong> Mandatory antivirus checks before opening any attachment, a single email-sending facade subject to human approval, secret anti-leak protections, and a seven-step procedure for creating structured missions. Any violation triggers a priority architectural debt.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The harness serves a \u003Cstrong>private control cockpit\u003C\u002Fstrong> — distinct from the public e-commerce products and client-specific configurations. This page covers only the harness itself.\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"topology\">2. Real topology\u003C\u002Fh2>\n\n\u003Cp>Three execution layers all communicate with the \u003Cstrong>same PostgreSQL schema\u003C\u002Fstrong>, but through different transports:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>The cockpit (standalone Nuxt 4 Nitro application)\u003C\u002Fstrong> — the control interface. Database access via a \u003Cstrong>postgres-js\u003C\u002Fstrong> pool with a MySQL-to-PostgreSQL translation adapter working at query time: positional parameter substitution, schema qualification on business tables, conversion of \u003Ccode>INSERT IGNORE\u003C\u002Fcode>, \u003Ccode>DATE_SUB\u002FDATE_ADD\u003C\u002Fcode>, \u003Ccode>TIMESTAMPDIFF\u003C\u002Fcode>, \u003Ccode>IFNULL\u003C\u002Fcode>, and camelCase aliases. Some MySQL constructs are not automatically converted (\u003Ccode>ON DUPLICATE KEY UPDATE\u003C\u002Fcode>, \u003Ccode>LAST_INSERT_ID()\u003C\u002Fcode>, \u003Ccode>GROUP_CONCAT\u003C\u002Fcode>, \u003Ccode>FIND_IN_SET\u003C\u002Fcode>, \u003Ccode>DATE_FORMAT\u003C\u002Fcode>, \u003Ccode>CURDATE()\u003C\u002Fcode>) and must be ported manually. The application is composed of 27 independent modules.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>The Python automation layer (236 facades)\u003C\u002Fstrong> — orchestration, automation, memory, audits, email, deployment. Database access via a dedicated database container, routing queries through sub-processes.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Scripts and scheduler\u003C\u002Fstrong> — deployment wrappers, LLM engine spawn via pseudo-TTY, attachment extraction, backups, regression tests. The scheduler built into the Nuxt application has been offline since May 2026; scheduling relies exclusively on the host machine's Linux crontab (69 active entries).\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cpre>\u003Ccode>                  REQUEST\n forwarded email ──┐       ┌─── control console\n agentic mailbox   │       │    (scoped to cockpit | tenant)\n                   ▼       ▼\n   ┌─────────────────────────────────────────────────────┐\n   │  PYTHON LAYER — 236 facades                         │\n   │  Orchestrator: poll + classification + spawn         │\n   │  Execution: task worker, ReAct cycle                 │\n   │  Memory \u002F audits \u002F email \u002F deployment                │\n   │  Headless LLM invocation via pseudo-TTY             │\n   │                  (never direct subprocess)           │\n   └──────────────┬──────────────────────┬───────────────┘\n  sub-process DB  │                       │ SSH + container\n                  ▼                       ▼\n   ┌────────────────────────┐   ┌──────────────────────────┐\n   │  POSTGRESQL            │   │  COCKPIT (Nuxt 4)        │\n   │  single schema         │◄──┤  control interface       │\n   │  271 tables + 18 views │   │  postgres-js pool        │\n   │  business tables       │   │  MySQL→PG adapter        │\n   │  legacy shim views     │   │  27 modules              │\n   └────────────────────────┘   └──────────────────────────┘\n                  ▲\n   scheduler      │  Linux crontab (69 entries)\n   (Nitro         │  shell \u002F Node scripts\n    offline)      │\n   ┌──────────────┴──────────────────────────────────────┐\n   │  SCRIPTS AND CRON — deploy, hooks, backups           │\n   │  Asymmetry: staging deploy = automatic               │\n   │             production publish = human action        │\n   └─────────────────────────────────────────────────────┘\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>\u003Cstrong>Key architectural pitfalls to keep in mind:\u003C\u002Fstrong>\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>The PostgreSQL schema is distinct from the default \u003Ccode>public\u003C\u002Fcode> schema; explicit schema qualification is required on all queries.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Twelve tables in the agent registry are actually views\u003C\u002Fstrong> that wrap the underlying physical tables — a legacy of a progressive migration. Read from the views; write to the physical tables.\u003C\u002Fli>\n  \u003Cli>A single \"mission\" entity is split across legacy tables (control data) and cockpit tables (execution tracking).\u003C\u002Fli>\n  \u003Cli>The cockpit is \u003Cstrong>standalone\u003C\u002Fstrong>: it does not extend the e-commerce codebase. Real security relies on network infrastructure (SSH tunnel and nginx filter gate); a middleware auto-injects an operator session internally.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Chr>\n\n\u003Ch2 id=\"lifecycle\">3. Complete request lifecycle\u003C\u002Fh2>\n\n\u003Cp>The canonical path: \"email → deployed action.\" Two entry points feed the same orchestration engine: the \u003Cstrong>agentic mailbox poll\u003C\u002Fstrong> and the \u003Cstrong>control console\u003C\u002Fstrong>.\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>(0) INGESTION\n    An operator forwards an email to the agentic mailbox\n       │  scheduler *\u002F1 min — IMAP poll (SEARCH UNSEEN)\n       ▼\n    Record in database (raw) ──► agentic queue (status='received')\n       │\n(0b) ANTIVIRUS SCAN (if attachment — scan-first P0 doctrine)\n       │  ClamAV analysis + heuristics (malicious PDF, Office macros, executables)\n       │  verdict ∈ {clean, suspect, blocked} ; verdict ≠ clean ⇒ classification BLOCKED\n       ▼\n(1) CLASSIFICATION  (LLM via unified AI facade, strict enum, anti-injection)\n    classified_intent ∈ {run, chantier, question, noise, negociation, conseil}\n       │  materializes at most 1 row in the corresponding table\n       ▼\n(2) SPAWN + ORCHESTRATION  (scheduler *\u002F5 min, offset 120 s after classify)\n    Python orchestrator\n       │  PostgreSQL advisory lock (anti-double-spawn)\n       │  spawn LLM engine via pseudo-TTY (node-pty, stream-json):\n       │    context isolation between spawns (zero cross-run leakage)\n       │    configured model, controlled permissions mode\n       │    optional toolset restriction (e.g. QA validator read-only)\n       │    configurable timeout (default 15 min, extendable to 40 min by caller)\n       │    ⚠️ CLI argument order: varargs arguments must precede flags\n       │    ⚠️ log stream must close AFTER the exit event is emitted\n       │    ⚠️ stdout pipe must be drained before process exit\n       │  the LLM engine writes a JSON result file, then exits\n       ▼\n    Post-spawn handler\n       ├─ no-code branch (run\u002Fquestion\u002Fnegociation) → summary email → 'actioned'\n       └─ code branch (chantier) → automatic staging deployment\n              └─ Two-level quality check per route:\n                     Level 1 — HTTP request (status + error pattern detection,\n                               optional SSH bypass for nginx filter gate)\n                     Level 2 — Playwright chromium headless browser\n                               (console errors, page errors, screenshot)\n                     Noise filters: 401 and ERR_HTTP2 ignored\n                                    on basic-auth-protected staging environments\n                    ├─ OK   → summary email to operator → status='actioned'\n                    └─ FAIL → re-spawn (max 3 iterations) then human escalation\n       ▼\n(3) STRUCTURED MISSION (if intent=chantier, see dedicated documentation)\n    7-step procedure: agent audit → mission brief → recruitment ≥2 agents\n       │  atomic creation: mission + work packages + tasks in one transaction\n       ▼\n    AGENT EXECUTION: task worker (*\u002F1 min) or ReAct cycle\n       │  status cascade task→work→mission (max 1 level); QA team if recruited\n       ▼\n    mission → 'test' (staging review, operator validation) ── manual ──► publish → 'done'\n       ▼\n(4) LEARNING (asynchronous)\n    learning record (failure\u002Fvictory) → vector re-indexing →\n    human-validated suggestion → persisted memory rule →\n    reflex available in next session\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>On the \u003Cstrong>outbound email\u003C\u002Fstrong> side, nothing ever reaches an external recipient directly: everything goes through the email-sending facade (draft → validation copy for the operator → send after explicit approval). The system writes to the internal operator, never to the requester.\u003C\u002Fp>\n\n\u003Cp>\u003Cstrong>Scheduling\u003C\u002Fstrong> relies on the Linux crontab: IMAP poll and scan continuously (*\u002F1 min), spawn with offset (*\u002F5 min + 120 s), task worker continuously (*\u002F1 min), plus 69 active cron entries for recurring automation, workers, and watchers.\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"glossary\">4. Cardinal terms glossary\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Name\u003C\u002Fth>\n      \u003Cth>Definition\u003C\u002Fth>\n      \u003Cth>Physical backing\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Orchestrator (Atlas)\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>The harness conductor. A \u003Cstrong>persona registered in the database\u003C\u002Fstrong> with no dedicated runtime: \"being the orchestrator\" = launching an LLM engine with the dedicated system prompt. Drives classification, spawn, and post-spawn orchestration.\u003C\u002Ftd>\n      \u003Ctd>Orchestration Python facades + pseudo-TTY spawn module\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Agent\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>persona\u003C\u002Fstrong> (identity + cognitive frame + business scope) injected into an LLM engine context to execute a task. 30 active agents across 4 families: \u003Ccode>direction\u003C\u002Fcode>, \u003Ccode>cadrage\u003C\u002Fcode>, \u003Ccode>execution\u003C\u002Fcode>, \u003Ccode>validation\u003C\u002Fcode>. An agent \u003Cstrong>deliberates\u003C\u002Fstrong> (ReAct cycle); it does not execute a hard-coded routine.\u003C\u002Ftd>\n      \u003Ctd>Agent registry in the database; persona loaded by a dedicated facade; 30 definitions in the agent directory\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Automate\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>deterministic script\u003C\u002Fstrong> that executes a routine; may call an LLM but its control flow is hard-coded. The conceptual opposite of an agent.\u003C\u002Ftd>\n      \u003Ctd>Automation registry in the database; dedicated execution log\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Chantier\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>structured multi-step mission\u003C\u002Fstrong>. The highest-level unit of work. Created atomically with ≥1 work package and ≥1 task via a dedicated procedure. Hierarchy: 1 chantier = N work packages = N tasks.\u003C\u002Ftd>\n      \u003Ctd>Mission table in the database\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Travail\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>granular batch\u003C\u002Fstrong> within a chantier (phase or sub-objective), with its responsible agent, scope, and exit criteria. Carries status cascades and the unblocking mechanism (\u003Ccode>travail-bis\u003C\u002Fcode>).\u003C\u002Ftd>\n      \u003Ctd>Work packages table in the database\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Tâche\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>The \u003Cstrong>atomic unit\u003C\u002Fstrong> assigned to an agent, with a token estimate and recommended model.\u003C\u002Ftd>\n      \u003Ctd>Tasks table in the database\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Run\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>scoped execution driven by the orchestrator\u003C\u002Fstrong> on a perimeter (internal cockpit or client site), the perimeter loading its context (server, client, mailbox). Trigger: forwarded email or control console. \u003Cstrong>A task execution record is NOT a run\u003C\u002Fstrong>: it is the execution unit delegated to an agent.\u003C\u002Ftd>\n      \u003Ctd>Runs table in the database; dedicated control console\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Cicatrice\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>recorded lesson\u003C\u002Fstrong> from a failure (\u003Ccode>kind='failure'\u003C\u002Fcode>) or a reproducible success (\u003Ccode>kind='victory'\u003C\u002Fcode>). Indexed as vectors for semantic recall, scored by importance, the entry point of the learning loop.\u003C\u002Ftd>\n      \u003Ctd>Learning records table in the database + pgvector index\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Orbit\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Organizational ring for agents (1\u002F2\u002F3). A \u003Cstrong>dual concept\u003C\u002Fstrong>: the numeric database column (underused) does not map 1:1 to the visual reactor display, which recomputes the ring from the family (\u003Ccode>direction\u003C\u002Fcode>=1, \u003Ccode>cadrage\u003C\u002Fcode>\u002F\u003Ccode>execution\u003C\u002Fcode>=2, \u003Ccode>validation\u003C\u002Fcode>=3). The family field is authoritative.\u003C\u002Ftd>\n      \u003Ctd>\u003Ccode>orbite\u003C\u002Fcode> column + \u003Ccode>group_name\u003C\u002Fcode> column in the agent registry\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Facade\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>A \u003Cstrong>single mandatory entry point\u003C\u002Fstrong> for a capability, making an operation non-bypassable (email, AI invocation, antivirus scan, database access). Often paired with a hook that blocks bypass attempts.\u003C\u002Ftd>\n      \u003Ctd>Python facades + pre-tool verification hooks\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Other useful terms: \u003Cstrong>knock-gate\u003C\u002Fstrong> (nginx cookie+slug filter upstream of the cockpit), \u003Cstrong>pseudo-TTY\u003C\u002Fstrong> (virtual terminal required to spawn the LLM engine programmatically), \u003Cstrong>scan-first\u003C\u002Fstrong> (doctrine: no attachment opened before an antivirus \u003Ccode>clean\u003C\u002Fcode> verdict), \u003Cstrong>travail-bis\u003C\u002Fstrong> (work package carrying an unblocking reference to release a paused work package).\u003C\u002Fp>\n\n\u003Chr>\n\n\u003Ch2 id=\"hard-boundaries\">5. Hard boundaries (non-negotiable)\u003C\u002Fh2>\n\n\u003Cp>A condensed reminder of the rules the entire harness enforces:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Single database\u003C\u002Fstrong> — zero business content in static files (JSON, TypeScript, Markdown); everything in the database.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Secret anti-leak P0\u003C\u002Fstrong> — no secret in cleartext in any versioned file; secrets live in environment files outside the repository, referenced only by variable name.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Antivirus scan before opening\u003C\u002Fstrong> — any attachment remains closed until the antivirus engine returns a \u003Ccode>clean\u003C\u002Fcode> verdict.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Zero direct client communication by the system\u003C\u002Fstrong> — email-sending facade + human validation before send + appointments exclusively via the canonical scheduling link.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>7-step procedure\u003C\u002Fstrong> — no chantier without atomic creation via the dedicated procedure, with ≥2 distinct agents for a client-scoped perimeter.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Commit-in-flow\u003C\u002Fstrong> — no completed work without an immediate commit; the AI commits, the human operator never types low-level git commands; a blocking hook enforces the invariant at every session end.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Chr>\n\n\u003Ch2 id=\"pages\">6. Other documentation pages\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Page\u003C\u002Fth>\n      \u003Cth>Subsystem covered\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>02 — The data layer\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Single database, table prefixes, MySQL→PostgreSQL adapter, Python Entity classes, legacy shim views, i18n in the database\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>03 — The agentic core\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Orchestrator, agent model, intent classification, pseudo-TTY spawn, deploy→QA→email orchestration, orbits, calibration\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>04 — Chantiers, work packages and tasks\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Mission\u002Fwork\u002Ftask hierarchy, atomic creation, 7-step procedure, multi-session lock, status cascades, travail-bis\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>05 — Automations, crons and runs\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>236 facades, cron wrapper, automation registry, run vs. task execution record, dual scheduler (Nitro offline + crontab)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>06 — The cockpit\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Nuxt application, modules, control pages, internal endpoints, knock-gate + auto-session authentication, consoles\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>07 — Inbox, agentic mailbox and email\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Two IMAP pipelines (cockpit vs. agentic mailbox), email-sending facade, antivirus scan, zero direct communication\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>08 — Memory and learning\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>3-level memory (persistent files \u002F notes \u002F vector index), RAG recall, cicatrices→suggestions→lessons loop, unified AI facade\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>09 — Deployment and infrastructure\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Deploy\u002Fpublish asymmetry, YAML dispatcher, build + compressed transfer, cockpit self-deploy, server inventory, secrets, commit-before-deploy\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>10 — Facade and entrypoint catalogue\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Python facades + scripts by family, invocation mode (cron\u002FCLI\u002Fskill\u002Fhook\u002Flib), hooks catalogue\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>11 — Skills, agents and hooks\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Slash-command skills, sub-agent definitions, configuration hooks + permissions\u002Fenv\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n",null,{"slug":15,"chapterNum":16,"title":17,"titleEn":18},"data-layer","02","La couche données","The Data Layer",{"chapters":20},[21,22,25,32,39,46,53,60,67,74,81],{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10},{"slug":15,"chapterNum":16,"title":17,"titleEn":18,"summary":23,"summaryEn":24},"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":26,"chapterNum":27,"title":28,"titleEn":29,"summary":30,"summaryEn":31},"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":33,"chapterNum":34,"title":35,"titleEn":36,"summary":37,"summaryEn":38},"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":40,"chapterNum":41,"title":42,"titleEn":43,"summary":44,"summaryEn":45},"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":47,"chapterNum":48,"title":49,"titleEn":50,"summary":51,"summaryEn":52},"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":54,"chapterNum":55,"title":56,"titleEn":57,"summary":58,"summaryEn":59},"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":61,"chapterNum":62,"title":63,"titleEn":64,"summary":65,"summaryEn":66},"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":68,"chapterNum":69,"title":70,"titleEn":71,"summary":72,"summaryEn":73},"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":75,"chapterNum":76,"title":77,"titleEn":78,"summary":79,"summaryEn":80},"facades","10","catalogue des façades et points d'entrée du harness","harness facade and entry-point catalogue","comment le harness synedre organise ses centaines d'automates en familles fonctionnelles, avec les garde-fous en temps réel qui encadrent chaque action.","how the synedre harness organizes its hundreds of automations into functional families, with the real-time guard-rails that frame every action.",{"slug":82,"chapterNum":83,"title":84,"titleEn":85,"summary":86,"summaryEn":87},"skills-hooks","11","Skills, agents & hooks — harness agentique Synedre OS","Skills, agents & hooks — Synedre OS agentic harness","Décrit le câblage complet du harness Claude Code de synedre-os : skills disponibles, sous-agents délégables et hooks d'événements qui imposent la doctrine commit-en-flux, garde-fous prod\u002Femail et injection mémoire.","Describes the complete wiring of the synedre-os Claude Code harness: available skills, delegatable sub-agents, and event hooks that enforce the commit-in-flow doctrine, prod\u002Femail guardrails, and memory injection."]