[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fxmPzOB4ncg4L7MLQWRZfm93T4xluhWMpH8QgwQEpgHA":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":24},{"chapter":4,"prev":14,"next":19},{"slug":5,"slugEn":6,"chapterNum":7,"title":8,"titleEn":9,"summary":10,"summaryEn":11,"contentHtml":12,"contentHtmlEn":13},"automates","automata","05","Automates, crons et runs","Automata, scheduling and runs","Comment le harness Synedre orchestre CodeMyShop : agents contre automates, planification, navigateur distribué et boucle nocturne d'auto-maintenance de la documentation.","How the Synedre harness orchestrates CodeMyShop: agents vs automata, scheduling, distributed browsing and the nightly documentation self-maintenance loop.","\u003Ch2 id=\"modele-mental-agent-automate\">1. Modèle mental : agent qui pense, automate qui exécute\u003C\u002Fh2>\n\u003Cp>Synedre orchestre CodeMyShop : ce chapitre documente le \u003Cstrong>harness Synedre\u003C\u002Fstrong>, la couche d'orchestration interne — mono-organisation, centralisée — qui pilote le produit et les opérations. Il ne décrit pas CodeMyShop lui-même, le PaaS e-commerce multi-tenant que Synedre opère pour ses clients.\u003C\u002Fp>\n\u003Cp>Le harness sépare deux registres bien distincts :\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>\u003C\u002Fth>\u003Cth>Agent\u003C\u002Fth>\u003Cth>Automate\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Rôle\u003C\u002Ftd>\u003Ctd>Pense, décide, délègue\u003C\u002Ftd>\u003Ctd>Exécute une routine déterministe\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Support\u003C\u002Ftd>\u003Ctd>Un modèle de langage incarnant une persona\u003C\u002Ftd>\u003Ctd>Un script d'automatisation\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Déclenchement\u003C\u002Ftd>\u003Ctd>Délégation depuis l'orchestrateur, ou tâche assignée\u003C\u002Ftd>\u003Ctd>Planification (horaire ou événementielle), ligne de commande\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Cp>Un automate ne « réfléchit » pas : il peut appeler un modèle de langage pour une tâche précise (génération de contenu, classification), mais son flux de contrôle reste codé en dur. La décision vit du côté des agents ; l'exécution répétable vit du côté des automates.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>  déclencheur (message, email, tâche planifiée)\n         │\n         ▼\n  orchestrateur (Atlas)\n         │ délègue\n         ▼\n  exécution déléguée à un agent\n         │ spawn\n         ▼\n  modèle de langage  \u002F  automate d'automatisation\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch2 id=\"facades-automatisees\">2. Les façades automatisées\u003C\u002Fh2>\n\u003Cp>Le harness regroupe plusieurs centaines de points d'entrée d'automatisation (« façades »), chacun exposant une capacité unique et invocable : synchronisation, audit, génération de contenu, sauvegarde, surveillance, etc. Une minorité sont planifiées ; la majorité sont des outils invoqués à la demande par un agent, ou des librairies partagées non exécutables seules.\u003C\u002Fp>\n\u003Cp>Un registre central classe chaque façade selon deux axes :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Nature technique\u003C\u002Fstrong> — planifiée (récurrente), déclenchée à la demande (ponctuelle), outil invocable par un agent, librairie partagée, ou méta-outillage (le superviseur d'exécution lui-même).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Groupe propriétaire\u003C\u002Fstrong> — chaque façade est rattachée à une des familles d'agents qui la maintiennent conceptuellement : audits\u002FQA, veille\u002Freporting, rédaction, build\u002Fdéploiement, infrastructure\u002Fsauvegarde, SEO\u002Fmaillage, finances\u002Ftrésorerie, et une famille dédiée à l'arbitrage stratégique. Cette classification reste un métier de terrain : la casse et la nomenclature ne sont pas encore parfaitement homogènes sur l'ensemble du registre.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Familles fonctionnelles\u003C\u002Fh3>\n\u003Ctable>\n\u003Ctr>\u003Cth>Famille\u003C\u002Fth>\u003Cth>Rôle\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Orchestration\u003C\u002Ftd>\u003Ctd>Pipeline boîte de réception → intention → délégation → mise en production. Un incident de nettoyage a supprimé à tort deux composants de supervision santé\u002Fmonitoring dédiés à cette famille ; la surveillance générique (coûts, alerting) continue de couvrir ce besoin par un autre chemin.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Audits\u003C\u002Ftd>\u003Ctd>Détection d'écarts et de findings (schéma, sauvegardes, accessibilité, sécurité). Une sortie non nulle signale un constat d'audit, pas un plantage. Un audit de sécurité périodique multi-site (reconnaissance hebdomadaire + alerte sur finding critique) a remplacé un ancien outil de test d'intrusion générique retiré pour dette technique.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Sauvegardes\u003C\u002Ftd>\u003Ctd>Extraction base de données et fichiers vers un stockage objet, avec test de restauration mensuel.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Brainstorm\u003C\u002Ftd>\u003Ctd>File de traitement asynchrone pour l'idéation (promotion, contestation, mise en récit).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Blog \u002F SEO\u003C\u002Ftd>\u003Ctd>Génération et hygiène de contenu, détection de cannibalisation, SEO technique.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Email \u002F boîte de réception\u003C\u002Ftd>\u003Ctd>Lecture\u002Fécriture de courrier électronique — l'envoi vers un client passe systématiquement par un point d'entrée unique.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Navigation automatisée\u003C\u002Ftd>\u003Ctd>Automatisation de navigateur (voir §6).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Banque \u002F facturation\u003C\u002Ftd>\u003Ctd>Synchronisation bancaire, facturation récurrente, relances. Un module de relance générique a été absorbé dans un package plus large mais n'est aujourd'hui plus câblé à aucune planification — seule une relance spécifique à un client tourne réellement.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Veille marque\u003C\u002Ftd>\u003Ctd>Surveillance de marque, veille technologique, avis clients.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Mémoire \u002F apprentissage\u003C\u002Ftd>\u003Ctd>Recherche sémantique, consolidation, retours d'expérience post-incident.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Fiabilité opérationnelle\u003C\u002Ftd>\u003Ctd>Surveillance des coûts, détection d'emballement (« runaway »), alerting, garde-fous d'écriture en production.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Auto-maintenance documentaire\u003C\u002Ftd>\u003Ctd>Boucle nocturne décrite en détail au §7.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Rythme d'autonomie\u003C\u002Ftd>\u003Ctd>Amorçage du pipeline d'exécution autonome, borné par une fenêtre horaire (voir §8).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Cp>Une régression non alertée mérite d'être signalée ici en exemple : un chantier de nettoyage automatisé (destiné à purger le code mort) a supprimé par erreur plusieurs scripts pourtant encore appelés par l'orchestrateur nocturne de maintenance documentaire (§7) et par un module d'audit d'accessibilité. Ces appels échouent depuis lors, silencieusement absorbés par les garde-fous existants — aucune alerte dédiée ne s'est déclenchée. Détail et portée au §7 et §9.\u003C\u002Fp>\n\n\u003Ch2 id=\"cron-wrapper-watchdog\">3. Le superviseur d'exécution planifiée\u003C\u002Fh2>\n\u003Cp>Tout automate planifié passe par un superviseur d'enrobage commun, responsable de :\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Chargement de configuration\u003C\u002Fstrong> — charge les variables d'environnement nécessaires sans écraser celles déjà présentes.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Disjoncteur\u003C\u002Fstrong> — au-delà d'un seuil de dix échecs consécutifs, le script est automatiquement désactivé (une seule alerte au moment du seuil, pas de spam).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Exécution encadrée\u003C\u002Fstrong> — lancement en sous-processus isolé, avec un temps limite par défaut de cinq minutes, étendu jusqu'à trente minutes pour les tâches longues connues.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auto-réparation\u003C\u002Fstrong> — pour une poignée de classes d'erreurs identifiées (import manquant, dépendance manquante, dossier de log inexistant, conflit de nommage local, erreur réseau transitoire), le superviseur tente un correctif automatique puis relance une fois. Les erreurs réseau bénéficient d'un ré-essai en cascade avec délai croissant.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Tolérance aux findings\u003C\u002Fstrong> — les scripts d'audit sortant en erreur volontaire (un audit qui trouve un problème) ne déclenchent pas le disjoncteur : ce n'est pas un plantage, c'est un résultat.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Journalisation\u003C\u002Fstrong> — chaque exécution en échec est journalisée (type d'erreur, trace, correctif tenté, succès du ré-essai, compteur d'échecs consécutifs) pour permettre l'audit quotidien (§9).\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Le verrouillage anti-recouvrement n'est pas systématique : le superviseur lui-même ne pose pas de verrou générique par script ; certaines tâches sensibles au recouvrement l'ajoutent explicitement, la majorité s'appuie sur le temps limite et la fréquence de planification pour éviter le chevauchement.\u003C\u002Fp>\n\n\u003Ch2 id=\"systeme-de-runs\">4. Le système de runs\u003C\u002Fh2>\n\u003Ch3 id=\"doctrine-run\">4.1 La doctrine « run »\u003C\u002Fh3>\n\u003Cp>Un \u003Cstrong>run\u003C\u002Fstrong> est une exécution scopée pilotée par l'orchestrateur sur un périmètre donné (interne au harness, ou un tenant client) — le périmètre chargeant automatiquement son contexte (infrastructure, client, interlocuteur, boîte mail) depuis le référentiel central. C'est la voie d'exécution par défaut du harness : un run enchaîne édition → mise en production, sans cérémonial, pour tout travail scopé et réversible.\u003C\u002Fp>\n\u003Cp>Deux portes d'entrée principales alimentent le volume de runs observés : le forward d'un email entrant classifié par intention (run \u002F question \u002F chantier plus lourd \u002F bruit), et une console de chat scopée pilotée par l'orchestrateur. Une troisième porte d'entrée planifiée (cron) est prévue en doctrine mais encore peu utilisée en pratique.\u003C\u002Fp>\n\u003Ch3 id=\"unite-execution-agent\">4.2 L'unité d'exécution déléguée à un agent\u003C\u002Fh3>\n\u003Cp>Un run n'est \u003Cstrong>pas\u003C\u002Fstrong> lui-même une unité d'exécution agent : c'est l'orchestrateur qui, en déléguant, engendre une exécution déléguée à un agent (comparable à une tâche de fond exécutée par un modèle de langage sandboxé).\u003C\u002Fp>\n\u003Cp>Le créateur le plus fréquent de ces exécutions déléguées est le rythme d'autonomie nocturne (§8), suivi par l'auto-chaînage interne du worker d'exécution, puis l'interface en ligne de commande et les appels API de mise en production automatique.\u003C\u002Fp>\n\u003Cp>L'exécuteur principal tourne à cadence rapprochée (environ une minute) : il choisit la plus ancienne tâche en attente, la marque en cours, spawn le processus correspondant selon le type de tâche (recherche, audit, ou code), diffuse la sortie en direct, puis marque le résultat terminé ou échoué. Les permissions accordées dépendent du type de tâche : une tâche de recherche est limitée à la lecture (pas d'écriture) ; une tâche de code obtient un accès élargi mais confiné strictement au périmètre déclaré.\u003C\u002Fp>\n\u003Cp>Le modèle de langage utilisé pour chaque tâche est désormais résolu dynamiquement selon une recommandation calculée en amont (par exemple, une tâche jugée complexe est orientée vers un modèle plus capable), avec repli sûr sur un modèle par défaut en cas d'absence ou d'erreur de lecture de cette recommandation — un câblage récemment corrigé, après avoir constaté que cette recommandation était calculée mais jamais effectivement appliquée au moment du lancement réel.\u003C\u002Fp>\n\u003Cp>Pour les tâches dont la cible est un environnement réellement en ligne (déploiement, certificat, infrastructure), un contrôle visuel additionnel a été ajouté avant de considérer la tâche comme terminée : un navigateur réel va vérifier que la cible répond correctement, plutôt que de se fier uniquement à la déclaration textuelle de l'agent et à une relecture du code. Si la cible s'avère cassée malgré une validation textuelle positive, le verdict est rétrogradé en échec ; si le contrôle visuel lui-même est indisponible, la tâche reste autorisée à passer (échec ouvert), mais l'incident est journalisé et un garde-fou de mise en production reste le filet de sécurité final.\u003C\u002Fp>\n\u003Ch3 id=\"journal-execution\">4.3 Le journal d'exécution des automates\u003C\u002Fh3>\n\u003Cp>Chaque exécution d'automate planifié est journalisée de façon détaillée (durée, compteurs d'étapes, erreurs, avertissements, contexte) — à distinguer du journal d'erreurs du superviseur (§3), qui ne trace que les plantages du superviseur lui-même.\u003C\u002Fp>\n\n\u003Ch2 id=\"ordonnancement-schedulers\">5. Ordonnancement : deux planificateurs en parallèle\u003C\u002Fh2>\n\u003Ch3 id=\"planificateur-applicatif\">5.1 Planificateur applicatif\u003C\u002Fh3>\n\u003Cp>Le harness expose ses propres tâches planifiées applicatives, en plus du filet crontab système. Ces tâches couvrent notamment : le traitement de la file d'envoi email, la surveillance de disponibilité, la veille de dictionnaire technique, la veille de dépendances, un point de synthèse quotidien, la surveillance de certificats, et la veille de marque. Chaque tâche sensible est protégée par un garde qui la court-circuite si elle tourne hors du contexte interne attendu.\u003C\u002Fp>\n\u003Cp>Deux tâches restent volontairement désactivées : la synchronisation de boîte mail et la synchronisation email côté client, car le protocole de messagerie utilisé bloque la boucle d'événements et provoque des ralentissements en cascade — à réactiver après correction du client de messagerie pour un mode non bloquant.\u003C\u002Fp>\n\u003Ch3 id=\"filet-crontab\">5.2 Filet crontab système\u003C\u002Fh3>\n\u003Cp>Le crontab système de la machine hôte porte l'essentiel de la charge planifiée et sert de filet indépendant du planificateur applicatif. Sur plusieurs centaines de lignes au total, une fraction importante (environ 40 %) est effectivement active ; le reste est un journal de bord de tâches désactivées, conservées en commentaire pour mémoire historique.\u003C\u002Fp>\n\u003Cp>Grandes familles de tâches actives :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Via le superviseur d'exécution\u003C\u002Fstrong> — surveillance système, sauvegarde, audits quotidiens, synchronisation bancaire, facturation récurrente, traitement de boîte de réception, rêverie de consolidation mémoire, boucle de maintenance documentaire, rythme d'autonomie (câblé en exécution réelle, cadencé toutes les deux minutes, mais borné par une fenêtre horaire configurable par jour).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Hors superviseur, modules Python directs\u003C\u002Fstrong> — indexation mémoire, exécuteur de tâches déléguées (cadence d'une minute), indexation de compétences, détection de blocage automatique, alerte de fiabilité, alerte de coût, détection d'emballement, extraction d'événements de négociation, veille avis clients.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Hors superviseur, sans wrapper\u003C\u002Fstrong> — publication documentaire, test de restauration mensuel, rotation de logs, métriques mémoire, indexation de session, surveillance de propositions, synthèse quotidienne. Ces scripts ne bénéficient ni de la journalisation centralisée ni de l'auto-réparation du superviseur.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Scripts d'infrastructure\u003C\u002Fstrong> — audit de flotte, audit de dépendances, sauvegardes vers stockage objet (locales et distantes, par tenant), test de restauration, synchronisation mémoire, nettoyage de verrous orphelins.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Appels HTTP directs\u003C\u002Fstrong> — déclenchement du traitement de file d'envoi email, synchronisation de rejoue de session. Une dette de hardening est signalée à ce sujet : une des lignes embarque un jeton d'authentification en clair — à migrer vers un stockage de secrets dédié.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Un chantier de réconciliation reste à mener : le registre canonique des automates planifiés n'est pas encore automatiquement recoupé avec les lignes crontab et les tâches applicatives réellement actives — impossible aujourd'hui de savoir combien d'automates enregistrés comme « récurrents » sont en réalité orphelins (non planifiés nulle part).\u003C\u002Fp>\n\n\u003Ch2 id=\"browser-worker-distribue\">6. L'automate de navigation distribué\u003C\u002Fh2>\n\u003Cp>L'automatisation de navigateur est le seul sous-système où l'exécution sort physiquement de l'infrastructure serveur. Deux raisons distinctes motivent cette sortie, donc deux topologies différentes, à ne pas confondre :\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>Topologie\u003C\u002Fth>\u003Cth>Où tourne le navigateur\u003C\u002Fth>\u003Cth>Contourne\u003C\u002Fth>\u003Cth>Mode\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Proxy résidentiel\u003C\u002Ftd>\u003Ctd>Navigateur sans interface sur le serveur\u003C\u002Ftd>\u003Ctd>La réputation de l'adresse IP\u003C\u002Ftd>\u003Ctd>Sans fenêtre visible, avec furtivité renforcée\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Poste distant avec interface\u003C\u002Ftd>\u003Ctd>Navigateur avec fenêtre visible sur un poste résidentiel\u003C\u002Ftd>\u003Ctd>La signature du navigateur (empreinte)\u003C\u002Ftd>\u003Ctd>Fenêtre visible, adresse IP résidentielle directe\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Ch3 id=\"pourquoi-navigateur-distant\">6.1 Pourquoi un navigateur résidentiel avec interface\u003C\u002Fh3>\n\u003Cp>Un tunnel réseau inversé établi depuis un point résidentiel permet de faire sortir le trafic par une adresse IP résidentielle plutôt que par l'adresse du serveur. C'est suffisant pour les sites qui ne discriminent que sur la réputation de l'adresse IP. Un garde-fou dédié refuse de lancer l'automatisation si le tunnel est indisponible ou si l'adresse de sortie observée correspond à celle du serveur — aucune sortie accidentelle par le mauvais chemin réseau.\u003C\u002Fp>\n\u003Cp>Mais certains mécanismes de protection anti-robot ne jugent pas l'adresse IP : ils jugent la \u003Cstrong>signature du navigateur\u003C\u002Fstrong> lui-même (signaux techniques trahissant un navigateur piloté automatiquement). Un navigateur sans interface, même via un tunnel résidentiel propre, conserve une signature de robot. D'où le second mode : un vrai navigateur avec fenêtre visible, tournant sur un poste résidentiel réellement allumé, avec l'adresse IP résidentielle native — pas de tunnel nécessaire, la protection anti-robot passe naturellement.\u003C\u002Fp>\n\u003Cp>Règle opérationnelle : classer le type de protection rencontrée \u003Cem>avant\u003C\u002Fem> de coder le flux d'automatisation. Une protection qui juge le navigateur, pas seulement l'adresse IP, impose le mode avec interface visible ; le mode furtif sans interface ne suffit pas.\u003C\u002Fp>\n\u003Ch3 id=\"cycle-de-vie-job\">6.2 Cycle de vie d'une tâche de navigation\u003C\u002Fh3>\n\u003Cp>Les tâches sont mises en file d'attente centralement, avec un statut (en attente \u002F en cours \u002F terminée \u002F échouée), un type d'opération restreint à une liste blanche explicite, un résultat structuré et un compteur de tentatives.\u003C\u002Fp>\n\u003Cp>Le point clé de conception est l'inversion de contrôle : le serveur n'a \u003Cstrong>aucun accès entrant\u003C\u002Fstrong> vers le poste résidentiel (adresse IP dynamique, pas de port ouvert). C'est le poste résidentiel qui interroge le serveur à intervalle régulier via une connexion sortante sécurisée.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>  [Serveur]                              [Poste résidentiel]\n  mise en file d'attente                  interrogation en boucle (toutes les ~5s)\n       │                                       │  (1) mise à jour automatique du code si besoin\n       ▼                                       │  (2) revendication atomique de la tâche\n  file d'attente centralisée ◄──────────────────┘\n       │\n       │  (3) exécution : navigateur avec interface visible,\n       │      routage strict par type d'opération (liste blanche)\n       ▼\n  file d'attente ◄──── rapport de fin (terminée\u002Féchouée, résultat structuré)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Détails de mécanisme :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Mise en file\u003C\u002Fstrong> — refuse tout type d'opération hors liste blanche, valide la charge utile avant insertion.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Revendication atomique\u003C\u002Fstrong> — la plus ancienne tâche en attente est prise de façon exclusive ; plusieurs postes distants ne peuvent pas se voler mutuellement une tâche.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Routage strict\u003C\u002Fstrong> — aucune exécution de code arbitraire à partir de la charge utile de la tâche, uniquement des paramètres métier prédéfinis vers un handler connu.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Authentification à deux facteurs\u003C\u002Fstrong> — pour les opérations qui en ont besoin, le code de vérification transite via le serveur (qui le lit dans sa propre boîte mail) plutôt que d'arriver directement sur le poste distant, et n'est jamais journalisé en clair.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Rapport de fin\u003C\u002Fstrong> — le résultat est transmis en un seul bloc structuré, jamais en argument de ligne de commande brut, pour éviter toute rupture sur un caractère spécial.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mise à jour automatique\u003C\u002Fstrong> — le poste distant se met à jour lui-même à l'état de repos uniquement (jamais en plein traitement d'une tâche).\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3 id=\"garde-fou-anti-fuite-cle\">6.3 Le garde-fou en cas de fuite de clé d'accès\u003C\u002Fh3>\n\u003Cp>La clé d'accès du poste distant est installée côté serveur avec des restrictions strictes : pas de terminal interactif, pas de redirection de port, pas de transfert d'agent. Si le poste résidentiel est compromis, la clé volée n'ouvre \u003Cstrong>pas\u003C\u002Fstrong> un accès serveur libre.\u003C\u002Fp>\n\u003Cp>Un garde dédié intercepte la commande reçue, la découpe en tokens stricts (jamais d'interprétation shell libre), et n'exécute que si le préfixe de commande correspond exactement à l'attendu, le sous-type d'opération appartient à une liste explicite, et chaque paramètre respecte un format strict prédéfini. Tout token inconnu ou valeur non conforme est refusé et journalisé. Pire cas d'une clé volée : polluer la file d'attente, jamais exécuter du code arbitraire côté serveur.\u003C\u002Fp>\n\u003Cp>Les données personnelles retournées par certaines opérations (noms, extraits de messages) ne sont jamais journalisées en clair — seul un compteur agrégé l'est. Les captures d'écran de débogage sont purgées automatiquement en fin de traitement. Une dette latente est signalée : un temps limite de traitement par tâche existe dans le code mais n'est aujourd'hui pas réellement appliqué, ce qui peut laisser une tâche de navigation bloquer indéfiniment.\u003C\u002Fp>\n\n\u003Ch2 id=\"boucle-auto-maintenance-doc\">7. La boucle nocturne d'auto-maintenance de la documentation\u003C\u002Fh2>\n\u003Cp>Le harness dispose d'un sous-système qui mesure l'écart entre sa propre documentation technique et son code réel, et corrige cet écart de façon largement autonome, sous garde-fous explicites. C'est la couche d'automatisation la plus récente et la plus imbriquée du harness.\u003C\u002Fp>\n\u003Ch3 id=\"architecture-pipeline-doc\">7.1 Architecture du pipeline\u003C\u002Fh3>\n\u003Cp>Un orchestrateur nocturne unique enchaîne, dans l'ordre, les étapes suivantes :\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Mesurer l'écart\u003C\u002Fstrong> — compare chaque chapitre documenté à son code lié réel.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mesurer la couverture\u003C\u002Fstrong> — détecte les angles morts (parties du code jamais mentionnées dans la documentation).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Cartographier les composants\u003C\u002Fstrong> — vérifie la cohérence entre le statut déclaré d'un composant et son état réel d'activation.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Relier les composants\u003C\u002Fstrong> — dérive les relations factuelles entre composants documentés (qui produit quoi, qui surveille quoi).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Réparer les références mortes\u003C\u002Fstrong> — corrige de façon déterministe les pointeurs vers du code qui a bougé, sans jamais inventer.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Régénérer en profondeur\u003C\u002Fstrong> — réécrit un chapitre entier en relisant le code réel, sous budget de temps borné.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Proposer la republication\u003C\u002Fstrong> — met en file les chapitres modifiés pour publication.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publier la documentation\u003C\u002Fstrong> — pousse les chapitres validés vers le site public, sous gate anti-fuite automatisé.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publier la cartographie\u003C\u002Fstrong> — synchronise le statut public des composants.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Re-mesurer l'écart\u003C\u002Fstrong> — remesure après réparation, pour que le diagnostic final reflète l'état réel de fin de cycle.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Établir le diagnostic\u003C\u002Fstrong> — bilan de synthèse (voir §7.2 ci-dessous).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publier le résumé\u003C\u002Fstrong> — pousse un instantané assaini du diagnostic vers le site public.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Le diagnostic final est volontairement calculé \u003Cem>après\u003C\u002Fem> la re-mesure, pas juste après la mesure de couverture initiale : sinon le résumé publié restait en retard d'un cycle sur l'état réellement corrigé.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Incident non alerté à signaler ici en exemple de transparence\u003C\u002Fstrong> : un chantier de nettoyage automatisé du code mort a supprimé par erreur trois scripts pourtant encore appelés par cet orchestrateur nocturne (les étapes « cartographier les composants », « proposer la republication » et « publier la cartographie »). Depuis cet incident, ces trois étapes échouent chaque nuit — l'échec est absorbé silencieusement par le garde-fou existant (seul un plantage franc de l'orchestrateur lui-même, pas l'échec d'une sous-étape isolée, remonte comme une alerte), donc aucune notification dédiée ne s'est déclenchée. Conséquence concrète : le statut\u002Fnom des composants ne se resynchronise plus automatiquement vers le site public, et la mise en file de republication passe désormais uniquement par le chemin de publication directe (étape 8). Ces scripts restent restaurables dans une fenêtre de grâce ; à défaut, les appels correspondants seront proprement retirés.\u003C\u002Fp>\n\u003Ch3 id=\"mesure-ecart-doc-code\">7.2 Le miroir de fidélité (mesurer l'écart)\u003C\u002Fh3>\n\u003Cp>Fonctionne en lecture seule stricte : n'écrit jamais ni le code ni la documentation, se contente d'enregistrer l'écart constaté. Trois types d'écart détectés : un fichier de code lié a été modifié après la dernière mise à jour du chapitre documenté ; le chapitre cite un chemin de code qui n'existe plus ; le chapitre publié sur le site retarde sur sa version interne. Idempotent (une mesure par chapitre par jour), et appelé deux fois par cycle (au début, et à la fin après réparation) pour que le diagnostic final reflète l'état réel.\u003C\u002Fp>\n\u003Ch3 id=\"mesure-couverture-doc\">7.3 L'auditeur de couverture (mesurer la couverture)\u003C\u002Fh3>\n\u003Cp>Complète le miroir de fidélité : là où celui-ci vérifie « ce que je dis est-il vrai ? », l'auditeur de couverture vérifie « y a-t-il une partie du système que je ne mentionne jamais ? », par différence d'ensembles entre le code documentable réel et ce qui est effectivement couvert par au moins un chapitre. Un point isolé non couvert n'est pas grave ; plusieurs points de la même famille non couverts deviennent candidats à une nouvelle section ou un nouveau chapitre. Lecture seule stricte.\u003C\u002Fp>\n\u003Ch3 id=\"reparation-deterministe\">7.4 Le réparateur déterministe de références mortes\u003C\u002Fh3>\n\u003Cp>Comble le trou entre le diagnostic (qui détecte un chemin mort) et la réécriture par modèle de langage (qui corrige la prose mais ne sait pas qu'un fichier a bougé) : la résolution ici est \u003Cstrong>déterministe, zéro improvisation\u003C\u002Fstrong>. Pour chaque référence morte, recherche le nouvel emplacement possible par le nom du fichier : un seul candidat trouvé → correction automatique ; zéro candidat → signalement humain requis ; plusieurs candidats ambigus → signalement, jamais de correction automatique à l'aveugle. Réversible (un seul geste annule tout un cycle de correction).\u003C\u002Fp>\n\u003Ch3 id=\"regeneration-profonde\">7.5 Le régénérateur profond\u003C\u002Fh3>\n\u003Cp>Sous un budget de temps borné, un modèle de langage headless relit le code réel d'un chapitre et (a) réécrit sa version interne, (b) produit directement sa version publique assainie, en français et en anglais. La version interne est validée avant que la version publique ne passe par un contrôle anti-fuite dédié.\u003C\u002Fp>\n\u003Ch3 id=\"auto-reparation-mecanique\">7.6 L'auto-réparateur mécanique (cycle indépendant)\u003C\u002Fh3>\n\u003Cp>Tourne sur son propre rythme, indépendamment de l'orchestrateur nocturne principal. Touche uniquement les fichiers de documentation, jamais le code. Règle de sûreté stricte : une référence morte n'est corrigée que si son nom de fichier correspond à exactement un fichier suivi dans le dépôt de code — zéro candidat ou plusieurs candidats ambigus, aucune correction automatique. Réversible, plafonné en volume par exécution, avec un interrupteur d'arrêt dédié.\u003C\u002Fp>\n\u003Ch3 id=\"diagnostic-nocturne\">7.7 Le diagnostic de fin de cycle\u003C\u002Fh3>\n\u003Cp>Calculé en toute fin de cycle, après la re-mesure de l'écart. Agrège cinq dimensions indépendantes, sans en modifier aucune : l'écart doc↔code, la couverture documentaire, la dette technique ouverte, le signal issu des retours d'expérience post-incident, et la santé opérationnelle des automates planifiés (taux d'erreur récent, scripts désactivés par le disjoncteur). Le résultat alimente un point de synthèse quotidien à destination du fondateur.\u003C\u002Fp>\n\u003Ch3 id=\"publication-documentaire\">7.8 La publication vers le site public\u003C\u002Fh3>\n\u003Cp>Détecte les chapitres dont la version interne a divergé de sa version publiée, les met en file d'attente de republication, avec un contrôle anti-fuite multi-couches avant toute écriture. La publication effective vers l'état public visible se fait soit par un geste humain délibéré, soit automatiquement pour les chapitres qui passent tous les contrôles machine (anti-fuite, et un contrôle spécifique anti-dérive de registre — cf. §VII de la charte éditoriale) ; les chapitres refusés restent en attente et génèrent une alerte au fondateur.\u003C\u002Fp>\n\u003Ch3 id=\"regard-externe\">7.9 Le processus de revue externe\u003C\u002Fh3>\n\u003Cp>Dépile des revues soumises par un regard extérieur (retour d'un autre modèle de langage sur une réponse du harness), les évalue via un modèle de langage sandboxé avec délimiteurs anti-injection stricts, et n'en tire qu'un signal (pas de régénération immédiate) — la régénération effective reste consommée par l'orchestrateur nocturne principal, pour éviter la perte de calcul en cas de coupure.\u003C\u002Fp>\n\n\u003Ch2 id=\"tick-autonomie\">8. Le rythme d'autonomie nocturne\u003C\u002Fh2>\n\u003Ch3 id=\"amorcage-pipeline\">8.1 Amorçage, fenêtre horaire, garde-fous\u003C\u002Fh3>\n\u003Cp>Le pipeline d'exécution autonome se chaîne lui-même à l'intérieur d'un travail en cours, mais rien n'amorce le tout premier pas : un travail marqué en mode autonome, avec des tâches en attente et aucune exécution en cours, resterait dormant sans un déclencheur externe. Ce rythme comble précisément ce trou : il seede une tâche en attente pour la prochaine étape éligible de chaque travail actif sans exécution en cours.\u003C\u002Fp>\n\u003Cp>Le rythme tourne à cadence rapprochée (toutes les deux minutes), mais ne seed réellement que si l'heure courante tombe dans une fenêtre horaire configurable par jour de la semaine. Hors fenêtre, il repasse en mode observation silencieuse (il note, il n'agit pas). Un pilotage manuel explicite peut court-circuiter la fenêtre — un geste délibéré du fondateur, pas un comportement par défaut.\u003C\u002Fp>\n\u003Cp>Garde-fous en place :\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Plafond de coût\u003C\u002Fstrong> — si le coût cumulé d'un chantier atteint son plafond, il est gelé, plus aucune nouvelle tâche n'est seedée.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Interrupteurs d'arrêt\u003C\u002Fstrong> — plusieurs interrupteurs indépendants permettent de couper tout ou partie de l'autonomie sans toucher au code.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Mise en production autonome, gouvernée par la flotte\u003C\u002Fstrong> — le rythme peut exécuter un déploiement en préproduction systématiquement, et une mise en production réelle uniquement si l'infrastructure cible l'autorise explicitement (drapeau par site, activé par défaut, avec exclusions explicites décidées au cas par cas). La mise en production autonome, non surveillée, exige \u003Cstrong>en plus\u003C\u002Fstrong> une preuve de validation qualité positive et récente — sans cette preuve, le rythme signale sans agir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Filet de restauration post-déploiement\u003C\u002Fstrong> — une porte de santé HTTP vérifie la cible après déploiement ; en cas d'échec, une restauration automatique de la version précédente est déclenchée. Sur les mises en production autonomes spécifiquement, l'ancienne version est conservée un cran plus longtemps que sur un déploiement manuel, pour permettre une restauration manuelle a posteriori d'un déploiement « techniquement en ligne mais fonctionnellement faux » que la seule porte de santé HTTP ne peut pas détecter.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Plancher en dur, indépendant de la base de données\u003C\u002Fstrong> — pour un site explicitement identifié comme sensible, un refus de mise en production automatique est codé en dur, testé \u003Cem>avant même\u003C\u002Fem> toute lecture du drapeau d'autorisation en base. Raison : ce rythme s'exécute en tâche planifiée, hors de toute session interactive protégée — un garde-fou qui ne protège que les sessions interactives ne verrait jamais cet appel. Une seule ligne de configuration corrompue ne doit jamais suffire, à elle seule, à faire passer ce site en production automatiquement. C'est le miroir, en deux surfaces de code indépendantes, du même principe de double verrou.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"garde-fous-operations\">9. Garde-fous & dette technique\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Disjoncteur\u003C\u002Fstrong> — un automate est désactivé après dix échecs consécutifs.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Audit quotidien\u003C\u002Fstrong> — relit chaque jour le journal d'erreurs et le journal d'exécution des automates.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Coût \u002F emballement\u003C\u002Fstrong> — plusieurs surveillances indépendantes, à cadence variable (quelques minutes à une demi-heure), couvrent le coût cumulé et la détection d'emballement.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sauvegardes + test de restauration\u003C\u002Fstrong> — dumps nocturnes (base de données, fichiers, sites clients distants) et un test de restauration réel mensuel.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Déblocage automatique\u003C\u002Fstrong> — retente les exécutions bloquées, plafonné en nombre de tentatives, avec interrupteur dédié.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Boucle documentaire\u003C\u002Fstrong> — voir §7.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3 id=\"dette-signalee\">Dette signalée\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Un cron mort a été nettoyé sans remplaçant : l'audit de fuite d'URL qu'il exécutait n'est aujourd'hui plus couvert, à recréer si le besoin réapparaît.\u003C\u002Fli>\n\u003Cli>Un jeton d'authentification apparaît en clair dans une ligne de tâche planifiée — dette de hardening à corriger (migration vers un stockage de secrets dédié).\u003C\u002Fli>\n\u003Cli>Une tâche de traitement de file email tourne en double (planificateur applicatif + appel HTTP direct) — redondance sans impact fonctionnel (la file elle-même est idempotente) mais à nettoyer.\u003C\u002Fli>\n\u003Cli>Absence de verrouillage générique dans le superviseur d'exécution planifiée : recouvrement possible sur les tâches lentes non protégées explicitement.\u003C\u002Fli>\n\u003Cli>Régression non alertée (détaillée au §7.1) : trois étapes de la boucle documentaire échouent chaque nuit depuis un incident de nettoyage de code mort, sans alerte dédiée déclenchée. Un quatrième composant (audit d'accessibilité) est touché par la même classe de régression.\u003C\u002Fli>\n\u003Cli>Bug latent : un temps limite de traitement pour les tâches de navigation automatisée existe dans le code mais n'est pas appliqué en pratique — une tâche peut bloquer indéfiniment.\u003C\u002Fli>\n\u003C\u002Ful>\n","\u003Ch2 id=\"modele-mental-agent-automate\">1. Mental model: an agent that thinks, an automaton that executes\u003C\u002Fh2>\n\u003Cp>Synedre orchestrates CodeMyShop: this chapter documents the \u003Cstrong>Synedre harness\u003C\u002Fstrong>, the internal orchestration layer — single-organization, centralized — that drives the product and operations. It does not describe CodeMyShop itself, the multi-tenant e-commerce PaaS that Synedre operates for its clients.\u003C\u002Fp>\n\u003Cp>The harness keeps two distinct registers apart:\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>\u003C\u002Fth>\u003Cth>Agent\u003C\u002Fth>\u003Cth>Automaton\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Role\u003C\u002Ftd>\u003Ctd>Thinks, decides, delegates\u003C\u002Ftd>\u003Ctd>Executes a deterministic routine\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Backing\u003C\u002Ftd>\u003Ctd>A language model embodying a persona\u003C\u002Ftd>\u003Ctd>An automation script\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Trigger\u003C\u002Ftd>\u003Ctd>Delegation from the orchestrator, or an assigned task\u003C\u002Ftd>\u003Ctd>Scheduling (time- or event-based), command line\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Cp>An automaton does not \"think\": it may call a language model for a specific step (content generation, classification), but its control flow stays hard-coded. Decision-making lives on the agent side; repeatable execution lives on the automaton side.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>  trigger (chat, email, scheduled task)\n         │\n         ▼\n  orchestrator (Atlas)\n         │ delegates\n         ▼\n  execution delegated to an agent\n         │ spawn\n         ▼\n  language model  \u002F  automation script\n\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Ch2 id=\"facades-automatisees\">2. Automated entry points\u003C\u002Fh2>\n\u003Cp>The harness groups several hundred automation entry points (\"facades\"), each exposing a single invokable capability: sync, audit, content generation, backup, monitoring, and so on. A minority are scheduled; the majority are tools invoked on demand by an agent, or shared libraries not runnable on their own.\u003C\u002Fp>\n\u003Cp>A central registry classifies each entry point along two axes:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Technical nature\u003C\u002Fstrong> — scheduled (recurring), triggered on demand (one-shot), a tool invoked by an agent, a shared library, or meta-tooling (the execution supervisor itself).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Owning group\u003C\u002Fstrong> — each entry point is attached to one of the agent families that conceptually maintains it: audits\u002FQA, watch\u002Freporting, writing, build\u002Fdeployment, infrastructure\u002Fbackup, SEO\u002Finternal linking, finance\u002Ftreasury, and a dedicated strategic-arbitration family. This classification is still a work in progress: casing and naming are not yet fully consistent across the whole registry.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Functional families\u003C\u002Fh3>\n\u003Ctable>\n\u003Ctr>\u003Cth>Family\u003C\u002Fth>\u003Cth>Role\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Orchestration\u003C\u002Ftd>\u003Ctd>Inbox → intent → delegation → shipping pipeline. A cleanup effort mistakenly removed two dedicated health\u002Fmonitoring components for this family; generic monitoring (cost, alerting) still covers this need through another path.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Audits\u003C\u002Ftd>\u003Ctd>Drift and finding detection (schema, backups, accessibility, security). A non-zero exit signals an audit finding, not a crash. A periodic multi-site security audit (weekly recon + alert on critical finding) replaced an older generic penetration-testing tool that was retired as technical debt.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Backups\u003C\u002Ftd>\u003Ctd>Database and file extraction to object storage, with a monthly restore test.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Brainstorm\u003C\u002Ftd>\u003Ctd>Asynchronous processing queue for ideation (promotion, challenge, narrative framing).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Blog \u002F SEO\u003C\u002Ftd>\u003Ctd>Content generation and hygiene, cannibalization detection, technical SEO.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Email \u002F inbox\u003C\u002Ftd>\u003Ctd>Reading\u002Fwriting email — sending to a client always goes through a single entry point.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Automated browsing\u003C\u002Ftd>\u003Ctd>Browser automation (see §6).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Bank \u002F invoicing\u003C\u002Ftd>\u003Ctd>Bank sync, recurring invoicing, reminders. A generic reminder module was absorbed into a larger package but is no longer wired to any scheduling — only a client-specific reminder actually runs today.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Brand watch\u003C\u002Ftd>\u003Ctd>Brand monitoring, technology watch, customer reviews.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Memory \u002F learning\u003C\u002Ftd>\u003Ctd>Semantic search, consolidation, post-incident learnings.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Operational reliability\u003C\u002Ftd>\u003Ctd>Cost monitoring, runaway detection, alerting, production write guardrails.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Documentation self-maintenance\u003C\u002Ftd>\u003Ctd>Nightly loop detailed in §7.\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Autonomy cadence\u003C\u002Ftd>\u003Ctd>Bootstrapping the autonomous execution pipeline, bounded by a time window (see §8).\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Cp>An unalerted regression is worth flagging here as an example: an automated cleanup effort (meant to purge dead code) mistakenly removed several scripts that were still being called by the nightly documentation-maintenance orchestrator (§7) and by an accessibility audit module. These calls have been failing silently ever since, absorbed by an existing guardrail — no dedicated alert fired. Detail and scope in §7 and §9.\u003C\u002Fp>\n\n\u003Ch2 id=\"cron-wrapper-watchdog\">3. The scheduled-execution supervisor\u003C\u002Fh2>\n\u003Cp>Every scheduled automaton runs through a common supervising wrapper, responsible for:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Configuration loading\u003C\u002Fstrong> — loads the required environment variables without overwriting ones already set.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Circuit breaker\u003C\u002Fstrong> — beyond a threshold of ten consecutive failures, the script is automatically disabled (a single alert fires at the threshold, no spam).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bounded execution\u003C\u002Fstrong> — runs in an isolated subprocess, with a default five-minute timeout, extended up to thirty minutes for known long-running tasks.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Self-repair\u003C\u002Fstrong> — for a handful of identified error classes (missing import, missing dependency, missing log directory, local naming conflict, transient network error), the supervisor attempts an automatic fix and retries once. Network errors get a backoff-based retry cascade.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Finding tolerance\u003C\u002Fstrong> — audit scripts that intentionally exit with an error (an audit that found a problem) do not trip the circuit breaker: that's a result, not a crash.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Logging\u003C\u002Fstrong> — every failed run is logged (error type, traceback, fix attempted, retry success, consecutive-failure count) to feed the daily audit (§9).\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Anti-overlap locking is not universal: the supervisor itself does not apply a generic per-script lock; a handful of overlap-sensitive tasks add one explicitly, while most rely on the timeout and scheduling frequency to avoid overlap.\u003C\u002Fp>\n\n\u003Ch2 id=\"systeme-de-runs\">4. The run system\u003C\u002Fh2>\n\u003Ch3 id=\"doctrine-run\">4.1 The \"run\" doctrine\u003C\u002Fh3>\n\u003Cp>A \u003Cstrong>run\u003C\u002Fstrong> is a scoped execution driven by the orchestrator over a given perimeter (internal to the harness, or a client tenant) — the perimeter automatically loading its context (infrastructure, client, contact, mailbox) from the central registry. It is the harness's default execution path: a run chains edit → ship, with no ceremony, for any scoped and reversible piece of work.\u003C\u002Fp>\n\u003Cp>Two main entry points feed the observed run volume: forwarding an incoming email classified by intent (run \u002F question \u002F larger initiative \u002F noise), and a scoped chat console driven by the orchestrator. A third, scheduled entry point (cron) is envisioned in doctrine but still lightly used in practice.\u003C\u002Fp>\n\u003Ch3 id=\"unite-execution-agent\">4.2 The unit of execution delegated to an agent\u003C\u002Fh3>\n\u003Cp>A run is \u003Cstrong>not\u003C\u002Fstrong> itself a unit of agent execution: it is the orchestrator that, by delegating, spawns an execution delegated to an agent (comparable to a background task run by a sandboxed language model).\u003C\u002Fp>\n\u003Cp>The most frequent creator of these delegated executions is the nightly autonomy cadence (§8), followed by the execution worker's internal auto-chaining, then the command-line interface and the automatic-shipping API calls.\u003C\u002Fp>\n\u003Cp>The main executor runs at a tight cadence (about once a minute): it picks the oldest pending task, marks it running, spawns the corresponding process based on the task type (research, audit, or code), streams the output live, then marks the result done or failed. Granted permissions depend on the task type: a research task is limited to reading (no writes); a code task gets broader access but strictly confined to its declared perimeter.\u003C\u002Fp>\n\u003Cp>The language model used for each task is now resolved dynamically from a recommendation computed upstream (for instance, a task judged complex is routed to a more capable model), with a safe fallback to a default model if that recommendation is missing or fails to read — a wiring that was recently fixed, after discovering the recommendation was being computed but never actually applied at launch time.\u003C\u002Fp>\n\u003Cp>For tasks targeting a genuinely live environment (deployment, certificate, infrastructure), an additional visual check was added before marking a task done: a real browser verifies the target actually responds correctly, rather than relying solely on the agent's textual claim and a code read-through. If the target turns out broken despite a positive textual check, the verdict is downgraded to failed; if the visual check itself is unavailable, the task is still allowed through (fail-open), but the incident is logged and a production-shipping guardrail remains the final safety net.\u003C\u002Fp>\n\u003Ch3 id=\"journal-execution\">4.3 The automaton execution log\u003C\u002Fh3>\n\u003Cp>Every scheduled automaton run is logged in detail (duration, step counters, errors, warnings, context) — distinct from the supervisor's error log (§3), which only traces the supervisor's own crashes.\u003C\u002Fp>\n\n\u003Ch2 id=\"ordonnancement-schedulers\">5. Scheduling: two parallel schedulers\u003C\u002Fh2>\n\u003Ch3 id=\"planificateur-applicatif\">5.1 Application-level scheduler\u003C\u002Fh3>\n\u003Cp>The harness exposes its own application-level scheduled tasks, in addition to the system crontab net. These tasks notably cover: email send-queue processing, uptime monitoring, technical dictionary watch, dependency watch, a daily digest, certificate monitoring, and brand watch. Each sensitive task is protected by a guard that short-circuits it if it runs outside the expected internal context.\u003C\u002Fp>\n\u003Cp>Two tasks remain intentionally disabled: mailbox sync and client-side email sync, because the mail protocol in use blocks the event loop and causes cascading slowdowns — to be re-enabled once the mail client is fixed for non-blocking mode.\u003C\u002Fp>\n\u003Ch3 id=\"filet-crontab\">5.2 System crontab safety net\u003C\u002Fh3>\n\u003Cp>The host machine's system crontab carries most of the scheduled load and acts as a net independent of the application-level scheduler. Out of several hundred total lines, a significant fraction (roughly 40%) is actually active; the rest is a log book of disabled tasks, kept as comments for historical memory.\u003C\u002Fp>\n\u003Cp>Main families of active tasks:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Through the execution supervisor\u003C\u002Fstrong> — system monitoring, backup, daily audits, bank sync, recurring invoicing, inbox processing, memory-consolidation dreaming, documentation-maintenance loop, autonomy cadence (wired to real execution, running every two minutes, but bounded by a configurable daily time window).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Outside the supervisor, direct Python modules\u003C\u002Fstrong> — memory indexing, delegated-task executor (one-minute cadence), skill indexing, automatic stuck-task detection, reliability alerting, cost alerting, runaway detection, negotiation-event extraction, review watch.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Outside the supervisor, no wrapper\u003C\u002Fstrong> — documentation publishing, monthly restore test, log rotation, memory metrics, session indexing, proposal monitoring, daily digest. These scripts get neither centralized logging nor the supervisor's self-repair.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Infrastructure scripts\u003C\u002Fstrong> — fleet audit, dependency audit, backups to object storage (local and remote, per tenant), restore test, memory sync, orphan-lock cleanup.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Direct HTTP calls\u003C\u002Fstrong> — triggering the email send-queue processing, session-replay sync. A hardening debt is flagged here: one of these lines embeds a bearer token in plain text — to be migrated to a dedicated secrets store.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>A reconciliation effort is still pending: the canonical registry of scheduled automata is not yet automatically cross-checked against the actual active crontab lines and application-level tasks — today there is no way to know how many automata registered as \"recurring\" are in fact orphaned (not scheduled anywhere).\u003C\u002Fp>\n\n\u003Ch2 id=\"browser-worker-distribue\">6. The distributed browser automation\u003C\u002Fh2>\n\u003Cp>Browser automation is the only subsystem where execution physically leaves the server infrastructure. Two distinct reasons drive this, hence two different topologies that should not be confused:\u003C\u002Fp>\n\u003Ctable>\n\u003Ctr>\u003Cth>Topology\u003C\u002Fth>\u003Cth>Where the browser runs\u003C\u002Fth>\u003Cth>Works around\u003C\u002Fth>\u003Cth>Mode\u003C\u002Fth>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Residential proxy\u003C\u002Ftd>\u003Ctd>Headless browser on the server\u003C\u002Ftd>\u003Ctd>IP address reputation\u003C\u002Ftd>\u003Ctd>No visible window, with hardened stealth\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Remote machine with a window\u003C\u002Ftd>\u003Ctd>Visible-window browser on a residential machine\u003C\u002Ftd>\u003Ctd>Browser fingerprint\u003C\u002Ftd>\u003Ctd>Visible window, direct residential IP address\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftable>\n\u003Ch3 id=\"pourquoi-navigateur-distant\">6.1 Why a residential browser with a visible window\u003C\u002Fh3>\n\u003Cp>A reverse network tunnel set up from a residential point lets traffic exit through a residential IP address rather than the server's own address. That's enough for sites that discriminate only on IP address reputation. A dedicated guardrail refuses to launch the automaton if the tunnel is unavailable or if the observed exit address matches the server's own address — no accidental exit through the wrong network path.\u003C\u002Fp>\n\u003Cp>But some anti-bot protections don't judge the IP address: they judge the \u003Cstrong>browser's own fingerprint\u003C\u002Fstrong> (technical signals that reveal an automated browser). A headless browser, even through a clean residential tunnel, still carries a bot fingerprint. Hence the second mode: a real browser with a visible window, running on a residential machine that is genuinely powered on, with the native residential IP address — no tunnel needed, the anti-bot check passes naturally.\u003C\u002Fp>\n\u003Cp>Operating rule: classify the type of protection encountered \u003Cem>before\u003C\u002Fem> coding the automation flow. A protection that judges the browser itself, not just the IP address, requires the visible-window mode; stealth-without-window is not enough.\u003C\u002Fp>\n\u003Ch3 id=\"cycle-de-vie-job\">6.2 Lifecycle of a browsing task\u003C\u002Fh3>\n\u003Cp>Tasks are queued centrally, with a status (queued \u002F running \u002F done \u002F failed), an operation type restricted to an explicit allowlist, a structured result, and an attempt counter.\u003C\u002Fp>\n\u003Cp>The key design point is inversion of control: the server has \u003Cstrong>no inbound access\u003C\u002Fstrong> to the residential machine (dynamic IP address, no open port). It is the residential machine that polls the server at a regular interval over an outbound secure connection.\u003C\u002Fp>\n\u003Cpre>\u003Ccode>  [Server]                                [Residential machine]\n  enqueue                                  polling loop (~every 5s)\n       │                                       │  (1) automatic code update if needed\n       ▼                                       │  (2) atomic claim of the task\n  central queue ◄────────────────────────────────┘\n       │\n       │  (3) execution: browser with a visible window,\n       │      strict routing by operation type (allowlist)\n       ▼\n  queue ◄──── completion report (done\u002Ffailed, structured result)\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Mechanism details:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Enqueue\u003C\u002Fstrong> — refuses any operation type outside the allowlist, validates the payload before insertion.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Atomic claim\u003C\u002Fstrong> — the oldest pending task is claimed exclusively; multiple remote workers cannot steal a task from each other.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Strict routing\u003C\u002Fstrong> — no arbitrary code execution from the task payload, only predefined business parameters routed to a known handler.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Two-factor authentication\u003C\u002Fstrong> — for operations that need it, the verification code flows back through the server (which reads it from its own mailbox) rather than arriving directly on the remote machine, and is never logged in plain text.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Completion report\u003C\u002Fstrong> — the result is transmitted as a single structured block, never as a raw command-line argument, to avoid breaking on a special character.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Automatic update\u003C\u002Fstrong> — the remote machine updates itself only while idle (never mid-task).\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3 id=\"garde-fou-anti-fuite-cle\">6.3 The guardrail against a leaked access key\u003C\u002Fh3>\n\u003Cp>The remote machine's access key is installed server-side with strict restrictions: no interactive terminal, no port forwarding, no agent forwarding. If the residential machine is compromised, the stolen key does \u003Cstrong>not\u003C\u002Fstrong> open free server access.\u003C\u002Fp>\n\u003Cp>A dedicated gate intercepts the received command, splits it into strict tokens (never free shell interpretation), and only executes if the command prefix matches exactly what's expected, the operation sub-type belongs to an explicit list, and every parameter matches a strict predefined format. Any unknown token or non-conforming value is refused and logged. Worst case of a stolen key: polluting the queue, never executing arbitrary code server-side.\u003C\u002Fp>\n\u003Cp>Personal data returned by certain operations (names, message excerpts) is never logged in plain text — only an aggregate count is. Debug screenshots are automatically purged at the end of processing. A latent debt item is flagged: a per-task processing timeout exists in the code but is not actually enforced today, which can leave a browsing task hanging indefinitely.\u003C\u002Fp>\n\n\u003Ch2 id=\"boucle-auto-maintenance-doc\">7. The nightly documentation self-maintenance loop\u003C\u002Fh2>\n\u003Cp>The harness has a subsystem that measures the gap between its own technical documentation and its real code, and closes that gap largely autonomously, under explicit guardrails. It is the harness's newest and most intertwined automation layer.\u003C\u002Fp>\n\u003Ch3 id=\"architecture-pipeline-doc\">7.1 Pipeline architecture\u003C\u002Fh3>\n\u003Cp>A single nightly orchestrator runs the following steps, in order:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Measure the gap\u003C\u002Fstrong> — compares each documented chapter to its real linked code.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Measure coverage\u003C\u002Fstrong> — detects blind spots (parts of the code never mentioned in the documentation).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Map components\u003C\u002Fstrong> — checks consistency between a component's declared status and its real activation state.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Link components\u003C\u002Fstrong> — derives factual relationships between documented components (what produces what, what monitors what).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Repair dead references\u003C\u002Fstrong> — deterministically fixes pointers to code that has moved, never inventing anything.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Deep-regenerate\u003C\u002Fstrong> — rewrites an entire chapter by re-reading the real code, under a bounded time budget.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Propose republishing\u003C\u002Fstrong> — queues changed chapters for publication.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publish documentation\u003C\u002Fstrong> — pushes validated chapters to the public site, under an automated anti-leak gate.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publish the component map\u003C\u002Fstrong> — syncs the public status of components.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Re-measure the gap\u003C\u002Fstrong> — re-measures after repair, so the final diagnosis reflects the real end-of-cycle state.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Produce the diagnosis\u003C\u002Fstrong> — a summary report (see §7.2 below).\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Publish the summary\u003C\u002Fstrong> — pushes a sanitized snapshot of the diagnosis to the public site.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>The final diagnosis is deliberately computed \u003Cem>after\u003C\u002Fem> the re-measure step, not right after the initial coverage measurement: otherwise the published summary would stay one cycle behind the actually-corrected state.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>An unalerted incident worth flagging here as a transparency example\u003C\u002Fstrong>: an automated dead-code cleanup effort mistakenly removed three scripts still being called by this nightly orchestrator (the \"map components\", \"propose republishing\", and \"publish the component map\" steps). Since that incident, these three steps have been failing every night — the failure is absorbed silently by the existing guardrail (only an outright crash of the orchestrator itself, not the failure of an isolated sub-step, surfaces as an alert), so no dedicated notification fired. Concrete consequence: component status\u002Fname no longer automatically re-syncs to the public site, and republish queuing now only flows through the direct publishing path (step 8). These scripts remain restorable within a grace window; failing that, the corresponding calls will be cleanly removed.\u003C\u002Fp>\n\u003Ch3 id=\"mesure-ecart-doc-code\">7.2 The fidelity mirror (measure the gap)\u003C\u002Fh3>\n\u003Cp>Runs strictly read-only: never writes either the code or the documentation, only records the observed gap. Three types of gap detected: a linked code file was modified after the documented chapter's last update; the chapter cites a code path that no longer exists; the chapter published on the site lags behind its internal version. Idempotent (one measurement per chapter per day), and called twice per cycle (at the start, and again at the end after repair) so the final diagnosis reflects the real state.\u003C\u002Fp>\n\u003Ch3 id=\"mesure-couverture-doc\">7.3 The coverage auditor (measure coverage)\u003C\u002Fh3>\n\u003Cp>Complements the fidelity mirror: where that one checks \"is what I say true?\", the coverage auditor checks \"is there a part of the system I never mention?\", via a set difference between the real documentable code and what is actually covered by at least one chapter. A single uncovered item isn't a problem; several uncovered items in the same family become a candidate for a new section or a new chapter. Strictly read-only.\u003C\u002Fp>\n\u003Ch3 id=\"reparation-deterministe\">7.4 The deterministic dead-reference repairer\u003C\u002Fh3>\n\u003Cp>Bridges the gap between diagnosis (which detects a dead path) and language-model rewriting (which fixes prose but doesn't know a file has moved): resolution here is \u003Cstrong>deterministic, zero improvisation\u003C\u002Fstrong>. For each dead reference, it searches for the possible new location by file name: exactly one candidate found → automatic fix; zero candidates → flags for human review; multiple ambiguous candidates → flags, never a blind automatic fix. Reversible (a single action undoes an entire repair cycle).\u003C\u002Fp>\n\u003Ch3 id=\"regeneration-profonde\">7.5 The deep regenerator\u003C\u002Fh3>\n\u003Cp>Under a bounded time budget, a headless language model re-reads a chapter's real code and (a) rewrites its internal version, (b) directly produces its sanitized public version, in both French and English. The internal version is validated before the public version goes through a dedicated anti-leak check.\u003C\u002Fp>\n\u003Ch3 id=\"auto-reparation-mecanique\">7.6 The mechanical auto-repairer (independent cycle)\u003C\u002Fh3>\n\u003Cp>Runs on its own cadence, independent of the main nightly orchestrator. Touches only documentation files, never code. Strict safety rule: a dead reference is only fixed if its file name matches exactly one file tracked in the code repository — zero candidates or multiple ambiguous candidates, no automatic fix. Reversible, capped in volume per run, with a dedicated kill switch.\u003C\u002Fp>\n\u003Ch3 id=\"diagnostic-nocturne\">7.7 The end-of-cycle diagnosis\u003C\u002Fh3>\n\u003Cp>Computed at the very end of the cycle, after the gap re-measure. Aggregates five independent dimensions without modifying any of them: the doc-to-code gap, documentation coverage, open technical debt, the signal drawn from post-incident learnings, and the operational health of scheduled automata (recent error rate, scripts disabled by the circuit breaker). The result feeds a daily digest for the founder.\u003C\u002Fp>\n\u003Ch3 id=\"publication-documentaire\">7.8 Publishing to the public site\u003C\u002Fh3>\n\u003Cp>Detects chapters whose internal version has diverged from its published version, queues them for republishing, with a multi-layer anti-leak check before any write. Actual publication to the visible public state happens either through a deliberate human action, or automatically for chapters that pass every machine check (anti-leak, plus a dedicated anti-drift register check — see §VII of the editorial charter); rejected chapters stay queued and generate an alert to the founder.\u003C\u002Fp>\n\u003Ch3 id=\"regard-externe\">7.9 The external review process\u003C\u002Fh3>\n\u003Cp>Pulls reviews submitted from an outside perspective (feedback from another language model on a harness response), evaluates them via a sandboxed language model with strict anti-injection delimiters, and only draws a signal from it (no immediate regeneration) — actual regeneration remains consumed by the main nightly orchestrator, to avoid losing compute on an interruption.\u003C\u002Fp>\n\n\u003Ch2 id=\"tick-autonomie\">8. The nightly autonomy cadence\u003C\u002Fh2>\n\u003Ch3 id=\"amorcage-pipeline\">8.1 Bootstrapping, time window, guardrails\u003C\u002Fh3>\n\u003Cp>The autonomous execution pipeline self-chains within an ongoing piece of work, but nothing bootstraps the very first step: a piece of work marked as autonomous, with pending tasks and no run in progress, would stay dormant without an external trigger. This cadence fills exactly that gap: it seeds a pending task for the next eligible step of every active piece of work that has no run in progress.\u003C\u002Fp>\n\u003Cp>The cadence runs at a tight interval (every two minutes), but only actually seeds if the current time falls within a configurable time window for that day of the week. Outside the window, it falls back to silent observation mode (it notes, it does not act). An explicit manual override can bypass the window — a deliberate action by the founder, not a default behavior.\u003C\u002Fp>\n\u003Cp>Guardrails in place:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Cost cap\u003C\u002Fstrong> — if an initiative's cumulative cost reaches its cap, it is frozen and no new task gets seeded.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kill switches\u003C\u002Fstrong> — several independent switches allow cutting all or part of autonomy without touching the code.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Autonomous shipping, fleet-governed\u003C\u002Fstrong> — the cadence can run a preproduction deployment systematically, and an actual production deployment only if the target infrastructure explicitly allows it (a per-site flag, enabled by default, with explicit case-by-case exclusions). Unsupervised autonomous production shipping additionally requires a recent, positive quality-check proof — without that proof, the cadence signals without acting.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Post-deploy rollback net\u003C\u002Fstrong> — an HTTP health gate checks the target after deployment; on failure, an automatic rollback to the previous version is triggered. On autonomous production ships specifically, the previous version is kept one notch longer than on a manual deploy, to allow a manual after-the-fact rollback of a deployment that is \"technically live but functionally wrong\" — something the HTTP health gate alone cannot detect.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Hard-coded, database-independent floor\u003C\u002Fstrong> — for one site explicitly flagged as sensitive, a refusal of automatic production shipping is hard-coded, checked \u003Cem>before\u003C\u002Fem> even reading the authorization flag from the database. Reason: this cadence runs as a scheduled task, outside any protected interactive session — a guardrail that only protects interactive sessions would never see this call. A single corrupted configuration line must never, by itself, be enough to auto-ship this site to production. It mirrors, across two independent code surfaces, the same double-lock principle.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"garde-fous-operations\">9. Guardrails & technical debt\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>Circuit breaker\u003C\u002Fstrong> — an automaton is disabled after ten consecutive failures.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Daily audit\u003C\u002Fstrong> — re-reads the error log and the automaton execution log every day.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Cost \u002F runaway\u003C\u002Fstrong> — several independent monitors, at varying cadences (a few minutes to half an hour), cover cumulative cost and runaway detection.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Backups + restore test\u003C\u002Fstrong> — nightly dumps (database, files, remote client sites) and a real monthly restore test.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Automatic unblocking\u003C\u002Fstrong> — retries stuck runs, capped in attempt count, with a dedicated kill switch.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Documentation loop\u003C\u002Fstrong> — see §7.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3 id=\"dette-signalee\">Flagged debt\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>A dead cron was cleaned up with no replacement: the URL-leak audit it used to run is no longer covered — to be recreated if the need resurfaces.\u003C\u002Fli>\n\u003Cli>An authentication token appears in plain text on a scheduled-task line — a hardening debt to fix (migration to a dedicated secrets store).\u003C\u002Fli>\n\u003Cli>An email-queue processing task runs twice (application scheduler + direct HTTP call) — redundant with no functional impact (the queue itself is idempotent) but worth cleaning up.\u003C\u002Fli>\n\u003Cli>No generic locking in the scheduled-execution supervisor: overlap is possible on slow tasks not explicitly protected.\u003C\u002Fli>\n\u003Cli>Unalerted regression (detailed in §7.1): three steps of the documentation loop have been failing every night since a dead-code cleanup incident, with no dedicated alert firing. A fourth component (accessibility audit) is affected by the same class of regression.\u003C\u002Fli>\n\u003Cli>Latent bug: a processing timeout for automated browsing tasks exists in the code but is not enforced in practice — a task can hang indefinitely.\u003C\u002Fli>\n\u003C\u002Ful>\n",{"slug":15,"slugEn":15,"chapterNum":16,"title":17,"titleEn":18},"chantiers","04","Chantiers, travaux & tâches — modèle de données et API","Worksites, Jobs & Tasks — Data Model and API",{"slug":20,"slugEn":20,"chapterNum":21,"title":22,"titleEn":23},"hub","06","Hub — Interface d'administration Synedre OS","Hub — Synedre OS Administration Interface",{"chapters":25},[26,33,40,47,50,51,54,61,68,75,82],{"slug":27,"slugEn":27,"chapterNum":28,"title":29,"titleEn":30,"summary":31,"summaryEn":32},"overview","01","Vue d'ensemble du harness agentique Synedre OS","Overview of the Synedre OS Agentic Harness","Cette page présente l'architecture globale du harness — ses trois couches d'exécution (Nuxt, Python, scripts), leur articulation autour de la base PostgreSQL unique, et le cycle de vie complet d'une demande jusqu'au déploiement.","This page presents the overall architecture of the harness — its three execution layers (Nuxt, Python, scripts), their organization around the single PostgreSQL database, and the complete lifecycle of a request through to deployment.",{"slug":34,"slugEn":34,"chapterNum":35,"title":36,"titleEn":37,"summary":38,"summaryEn":39},"data-layer","02","Couche données de Synedre OS","Synedre OS data layer","Ce chapitre décrit l'architecture de persistance du harness Synedre OS : une base PostgreSQL unique, trois chemins d'accès distincts (Nuxt, Python agentique, Drizzle ORM), et les conventions de nommage qui organisent les familles de tables CodeMyShop et Synedre.","This chapter describes the persistence architecture of the Synedre OS harness: a single PostgreSQL database, three distinct access paths (Nuxt, agentic Python, Drizzle ORM), and the naming conventions that organize the CodeMyShop and Synedre table families.",{"slug":41,"slugEn":41,"chapterNum":42,"title":43,"titleEn":44,"summary":45,"summaryEn":46},"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":15,"slugEn":15,"chapterNum":16,"title":17,"titleEn":18,"summary":48,"summaryEn":49},"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":5,"slugEn":6,"chapterNum":7,"title":8,"titleEn":9,"summary":10,"summaryEn":11},{"slug":20,"slugEn":20,"chapterNum":21,"title":22,"titleEn":23,"summary":52,"summaryEn":53},"Description de l'app Nuxt mothership-app, son architecture en layers modulaires et la carte complète des pages \u002Fhub\u002F* qu'elle expose.","Description of the Nuxt mothership-app, its modular layer architecture and the complete map of \u002Fhub\u002F* pages it exposes.",{"slug":55,"slugEn":55,"chapterNum":56,"title":57,"titleEn":58,"summary":59,"summaryEn":60},"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":62,"slugEn":62,"chapterNum":63,"title":64,"titleEn":65,"summary":66,"summaryEn":67},"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":69,"slugEn":69,"chapterNum":70,"title":71,"titleEn":72,"summary":73,"summaryEn":74},"deploy","09","Déploiement & infrastructure","Deployment & infrastructure","Décrit le pipeline de mise en ligne de Synedre OS et ses tenants, notamment l'asymétrie entre .\u002Fdeploy (preprod\u002FIA) et .\u002Fship (production, gaté par flotte), le dispatcher YAML, le pattern build-host sans build VPS, et les doctrines associées aux secrets et commits.","Describes the Synedre OS release pipeline and its tenants, including the asymmetry between .\u002Fdeploy (preprod\u002FAI) and .\u002Fship (production, gated by fleet), the YAML dispatcher, the build-host-without-build-VPS pattern, and the doctrines associated with secrets and commits.",{"slug":76,"slugEn":76,"chapterNum":77,"title":78,"titleEn":79,"summary":80,"summaryEn":81},"facades","10","Catalogue des automatismes du harness Synedre","Synedre harness automata catalog","Comment Synedre orchestre CodeMyShop via des agents, des files de tâches et des garde-fous automatiques, du courrier entrant jusqu'au déploiement.","How Synedre orchestrates CodeMyShop through agents, task queues, and automatic guardrails, from incoming mail to deployment.",{"slug":83,"slugEn":83,"chapterNum":84,"title":85,"titleEn":86,"summary":87,"summaryEn":88},"skills-hooks","11","Skills, agents & hooks — harness agentique Synedre OS","Skills, agents & hooks — Synedre OS agentic harness","Ce chapitre décrit l'architecture du harness Claude Code de synedre-os : les skills invocables, les sous-agents délégables et les hooks d'événements qui orchestrent la doctrine (garde-fous, injection mémoire, commit-en-flux).","This chapter describes the architecture of the synedre-os Claude Code harness: the invocable skills, the delegable sub-agents, and the event hooks that orchestrate the doctrine (guardrails, memory injection, stream-commits)."]