[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f-mjQ1qa4BklHoWqSi_9js4EEORh7B7I-Xqa_6YO3iis":3,"$fk1oB-e5O_BgwF2c-QwDgsx2Y7SMPhf77z9g2mrpoBuM":23},{"chapter":4,"prev":13,"next":18},{"slug":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10,"contentHtml":11,"contentHtmlEn":12},"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.","\u003Ch2 id=\"hub-presentation\">Le Hub — tableau de bord de pilotage agentique\u003C\u002Fh2>\n\n\u003Cp>Le Hub est l'interface d'administration privée de Synedre OS. Accessible uniquement depuis le VPS du vaisseau-mère via un tunnel sécurisé, il permet de piloter l'ensemble du harnais agentique : agents, chantiers, runs, négociations, mémoire et infrastructure.\u003C\u002Fp>\n\n\u003Ch3>Une application cockpit dédiée\u003C\u002Fh3>\n\n\u003Cp>Le Hub repose sur une application Nuxt \u003Cstrong>autonome\u003C\u002Fstrong>, distincte de toute autre surface applicative. Elle n'hérite d'aucun module de localisation ni de gestion de thème : elle est \u003Cstrong>en français uniquement\u003C\u002Fstrong> et impose un affichage en mode sombre permanent (le commutateur clair\u002Fsombre a été retiré en mai 2026). Ce choix de sobriété visuelle reflète la nature opérationnelle de l'outil.\u003C\u002Fp>\n\n\u003Ch3>Architecture en couches fonctionnelles\u003C\u002Fh3>\n\n\u003Cp>Le Hub n'est pas un monolithe. Ses fonctionnalités sont réparties en \u003Cstrong>modules indépendants\u003C\u002Fstrong>, chargés comme des couches Nuxt (\u003Cem>layers\u003C\u002Fem>) au démarrage. Chaque couche apporte ses propres pages, ses propres API et son propre code serveur, découverts automatiquement par le moteur de routage.\u003C\u002Fp>\n\n\u003Cp>On distingue deux catégories :\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Les composants noyau\u003C\u002Fstrong> — pages et endpoints directement portés par l'application principale : tableau de bord général, vue des coûts, gestion des sauvegardes, cadran de maintenance.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Les modules thématiques\u003C\u002Fstrong> — chacun encapsule un domaine métier ou technique et expose ses propres routes \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode> ainsi que ses propres endpoints d'API.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Au total, le Hub agrège \u003Cstrong>27 couches fonctionnelles\u003C\u002Fstrong> actives, couvrant des domaines aussi variés que la gestion des agents, le suivi des chantiers, la facturation, la mémoire, les automates, le monitoring SEO ou encore la formation interne.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note architecture :\u003C\u002Fstrong> ces couches sont déclarées via la clé \u003Ccode>extends:\u003C\u002Fcode> de la configuration Nuxt, et \u003Cem>non\u003C\u002Fem> via la clé \u003Ccode>modules:\u003C\u002Fcode>. Une confusion entre les deux entraîne des erreurs de chargement au démarrage. Chaque couche possède son propre fichier de configuration Nuxt minimal.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"hub-pages-map\">Carte des pages et modules\u003C\u002Fh2>\n\n\u003Ch3>Pages noyau\u003C\u002Fh3>\n\n\u003Cp>L'application principale expose directement plusieurs pages de pilotage global :\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Racine \u003Ccode>\u002Fhub\u003C\u002Fcode>\u003C\u002Fstrong> — redirection automatique (302) vers le tableau de bord principal ; ce n'est pas une page autonome.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vue SRE\u003C\u002Fstrong> — supervision de la fiabilité du vaisseau-mère.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vue des coûts\u003C\u002Fstrong> — suivi des dépenses, accessible depuis la navigation principale ; une sous-vue détaillée ventile les coûts par chantier et par budget annuel.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vue apprentissage agentique\u003C\u002Fstrong> — tableau de suivi de la montée en compétence.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Vue des sauvegardes\u003C\u002Fstrong> — état des sauvegardes de l'infrastructure.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Cadran de maintenance\u003C\u002Fstrong> — interface de supervision de la santé documentaire et technique du système, détaillée ci-dessous.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Cadran de maintenance — deux onglets\u003C\u002Fh3>\n\n\u003Cp>Le cadran de maintenance est l'observatoire interne de la santé du système. Il se compose de deux onglets :\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\n    \u003Cstrong>Tableau de bord de santé\u003C\u002Fstrong> — une jauge globale agrège quatre dimensions de santé du système : proprioception, dette technique, apprentissage et automates. Un graphique d'évolution sur 7 jours accompagne un tableau de dérive documentaire, classant les écarts selon leur nature : référence morte, document publié obsolète, code plus récent que la doc, document non publié.\n  \u003C\u002Fli>\n  \u003Cli>\n    \u003Cstrong>Regard extérieur\u003C\u002Fstrong> — l'opérateur sélectionne un chapitre de documentation publique, génère un prompt épuré de toute donnée sensible, le soumet à un modèle IA externe, puis colle la réponse dans le formulaire pour archivage. L'historique des soumissions est consultable. La taille maximale d'une réponse soumise est de 50 000 caractères. Onze chapitres sont éligibles à cette revue externe.\n  \u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>Pages portées par les modules thématiques\u003C\u002Fh3>\n\n\u003Cp>Les 27 modules contribuent collectivement 49 pages supplémentaires sous \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode>. Le tableau ci-dessous en donne la répartition par domaine fonctionnel :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Domaine fonctionnel\u003C\u002Fth>\n      \u003Cth>Pages \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode>\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Agents & opérations agentiques\u003C\u002Ftd>\n      \u003Ctd>38 pages : tableau de bord principal, fiches agents, brainstorm, chantiers (liste, fiche, kanban, travail), clients, conseil, constitution, dispatch, doctrine, emails, hooks, inbox, juridique, mémoire (navigation, recherche RAG), négociations, questions, reactor, runs (liste, fiche, atlas), sessions, paramètres, compétences, compétences en attente, modèle utilisateur\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Backlog & planning\u003C\u002Ftd>\n      \u003Ctd>3 pages : backlog, planning, backlog système\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Cockpits & chantiers\u003C\u002Ftd>\n      \u003Ctd>2 pages : fiche chantier, vue cockpits\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Exercices & entraînement\u003C\u002Ftd>\n      \u003Ctd>2 pages : liste des exercices, détail par agent\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Cicatrices\u003C\u002Ftd>\n      \u003Ctd>1 page : registre des cicatrices\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Conduites\u003C\u002Ftd>\n      \u003Ctd>1 page : tableau des conduites\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Automates\u003C\u002Ftd>\n      \u003Ctd>1 page : gestion des automates système\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Monitoring SEO\u003C\u002Ftd>\n      \u003Ctd>1 page : cockpit SEO technique multi-tenant (taux 404, tendance clics\u002Fimpressions, mode observation ou auto-remédiation, journal des alertes) — accessible par URL directe, absent de la navigation latérale\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Surface publique du module Exercices :\u003C\u002Fstrong> ce module expose également quatre pages \u003Cem>publiques\u003C\u002Fem> sur synedre.com (hors espace \u003Ccode>\u002Fhub\u003C\u002Fcode>) : liste des exercices, historique, cicatrices et détail d'une épreuve. Ces pages ne sont pas comptées dans les 49 pages hub ci-dessus.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Modules sans page Vue (server-only)\u003C\u002Fh3>\n\n\u003Cp>Plusieurs modules n'exposent aucune page d'interface. Ils fournissent exclusivement des endpoints d'API et une couche de persistance, consommés par d'autres pages du Hub ou par les automates Python. Ils couvrent notamment : la gestion académique interne, le suivi des articles autoblog, la configuration client, la messagerie quotidienne, la facturation, les incidents, les réunions, les outils utilitaires et d'autres services transverses.\u003C\u002Fp>\n\n\u003Cp>Un module dédié aux statistiques du Hub expose les données de synthèse (\u003Ccode>\u002Fapi\u002Fstats\u003C\u002Fcode>), les ressources de constitution et de charte (\u003Ccode>\u002Fapi\u002Fun composant interne\u003C\u002Fcode>, \u003Ccode>\u002Fapi\u002Fun composant interne\u003C\u002Fcode>) ainsi que les statistiques d'avatar — sans jamais présenter de page d'interface propre.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>À noter :\u003C\u002Fstrong> le module de pages d'expertise contribue des pages SEO publiques (hors \u003Ccode>\u002Fhub\u002F\u003C\u002Fcode>), pas des pages de cockpit.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"hub-navigation\">Navigation latérale — les sept zones\u003C\u002Fh2>\n\n\u003Cp>La barre de navigation du cockpit est organisée en \u003Cstrong>sept zones thématiques\u003C\u002Fstrong>, restructurées en mai 2026 pour refléter le flux de travail opérationnel :\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Zone\u003C\u002Fth>\n      \u003Cth>Entrées\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Pilotage\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Tableau de bord principal · Emails · Brainstorm · Modèle utilisateur\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Business\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Clients · Négociations · Conseil · Juridique\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Exécution\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Backlog · Chantier · Runs · Questions · Nouvelle tâche · Sessions\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Doctrine & Apprentissage\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Doctrine · Constitution · Cicatrices · Exercices\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Agentique\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Agents · Reactor · Compétences · Compétences en attente · Automates système · Dispatch · Hooks & Réflexes · Apprentissage agentique\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Mémoire\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Brain (navigation mémoire) · Recall RAG (recherche sémantique)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Système\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>SRE · Cadran de maintenance · Coûts · Sauvegardes · Paramètres\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>Un lien séparé, placé en bas de la navigation, donne accès à la surface e-commerce PaaS. Cette surface est servie par une application distincte du cockpit Synedre OS — il ne s'agit pas d'une page interne au Hub.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Comportement actif :\u003C\u002Fstrong> une entrée de navigation est marquée comme active sur correspondance exacte de la route courante \u003Cem>ou\u003C\u002Fem> sur correspondance de préfixe (sous-route). La racine \u003Ccode>\u002Fhub\u003C\u002Fcode> redirige systématiquement vers le tableau de bord principal et ne constitue pas une destination propre.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"familles-endpoints\">Les trois familles d'endpoints\u003C\u002Fh2>\n\n\u003Cp>Le découpage des routes API n'est pas qu'organisationnel : il porte une sémantique de droits. Trois préfixes coexistent, chacun avec son niveau de protection.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fbo\u002F*\u003C\u002Fcode> — surface back-office « fondateur\u002Fcron », protégée en amont par la porte d'infrastructure, parfois sans garde applicative supplémentaire.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fhub\u002F*\u003C\u002Fcode> — surface cockpit employé, avec vérification de session quasi-systématique.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fvoice\u002F*\u003C\u002Fcode> — transcription audio, avec vérification de session et défense CSRF.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Surface back-office\u003C\u002Fh3>\n\n\u003Cp>Cette famille regroupe les endpoints réservés aux opérations fondateur et aux tâches planifiées. Elle se répartit en plusieurs sous-domaines fonctionnels :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Apprentissage\u003C\u002Fstrong> : consultation du fil d'apprentissage, application et mise à jour d'entrées.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Chantier\u003C\u002Fstrong> : déclenchement et édition d'explosions de chantier, consultation du statut, lancement de phase.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Indicateurs de qualité\u003C\u002Fstrong> : lecture des KPI de cicatrices.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Coûts\u003C\u002Fstrong> : tableau de bord, budget (lecture\u002Fécriture), séries temporelles, vision par chantier.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Boîte de réception\u003C\u002Fstrong> : synchronisation, liste, détail, pièces jointes, liaison à un chantier.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Infrastructure vaisseau-mère\u003C\u002Fstrong> : liste des sauvegardes, téléchargement, lecture de l'état de santé de la documentation et de la dérive détectée.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Revue externe de la documentation\u003C\u002Fstrong> : liste des chapitres éligibles, génération du prompt nettoyé pour un modèle IA externe, historique des revues (avec filtres), soumission d'une revue externe.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Métriques SRE\u003C\u002Fstrong> : lecture des métriques de fiabilité.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tenants\u003C\u002Fstrong> : statut d'expédition automatique par tenant.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>\u003Cstrong>Particularité d'authentification :\u003C\u002Fstrong> certains endpoints de cette surface s'appuient exclusivement sur la porte d'infrastructure (cookie de knock + slug) plutôt que sur la vérification de session applicative. C'est notamment le cas de l'endpoint de synchronisation de la boîte de réception, déclenché par une tâche cron système.\u003C\u002Fp>\n\n\u003Cp>Ce choix est lié à une contrainte technique : la synchronisation IMAP bloque la boucle d'événements Node.js et reste donc exclue du planificateur interne. Les sept autres tâches périodiques sont, elles, gérées par ce planificateur :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Traitement de la file d'e-mails (toutes les 2 minutes)\u003C\u002Fli>\n  \u003Cli>Surveillance de disponibilité (toutes les 15 minutes)\u003C\u002Fli>\n  \u003Cli>Veille du dictionnaire (toutes les 30 minutes)\u003C\u002Fli>\n  \u003Cli>Surveillance des dépendances (quotidien, 2 h)\u003C\u002Fli>\n  \u003Cli>Réunion quotidienne d'audit (quotidien, 8 h)\u003C\u002Fli>\n  \u003Cli>Surveillance des certificats SSL (quotidien, 9 h)\u003C\u002Fli>\n  \u003Cli>Veille de marque (quotidien, 12 h)\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Surface cockpit employé\u003C\u002Fh3>\n\n\u003Cp>Cette famille est de loin la plus volumineuse. Elle regroupe les endpoints utilisés par les interfaces du cockpit : gestion des agents, des chantiers, des runs, des négociations, du conseil, des clients, du brainstorming, de la mémoire, de la doctrine, des compétences, des sessions, des questions, des tâches, du modèle utilisateur, des paramètres, de la répartition des agents et de l'atlas.\u003C\u002Fp>\n\n\u003Cp>La vérification de session employé est appliquée dans la grande majorité des fichiers de cette surface. Les exceptions sont des helpers internes ou des flux SSE (Server-Sent Events). Le pattern standard s'écrit :\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>export default defineEventHandler(async (event) => {\n  requireEmployeeSession(event)\n  \u002F\u002F …\n})\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>Un sous-ensemble d'endpoints gère spécifiquement la vie d'un chantier : runs actifs, bugs découverts, sessions CLI (démarrage, arrêt, réinitialisation), flux d'événements agent en temps réel (SSE), ainsi que les actions sur un run donné (brouillon de réponse, déclenchement de correctif, profil, flux d'événements).\u003C\u002Fp>\n\n\u003Ch3>Surface de transcription audio\u003C\u002Fh3>\n\n\u003Cp>Un unique endpoint accepte un fichier audio WAV en multipart et retourne le texte transcrit, la locale détectée, la durée en millisecondes, le modèle utilisé et le backend sollicité. La locale par défaut est le français.\u003C\u002Fp>\n\n\u003Cp>Les garde-fous appliqués sont les suivants :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Vérification de session employé obligatoire.\u003C\u002Fli>\n  \u003Cli>Taille maximale de fichier : 5 Mo.\u003C\u002Fli>\n  \u003Cli>Limite de débit : 100 transcriptions par tranche de 5 minutes par session.\u003C\u002Fli>\n  \u003Cli>L'audio n'est jamais persisté sur disque : traitement en mémoire vive uniquement.\u003C\u002Fli>\n  \u003Cli>Défense CSRF par vérification de la correspondance Origin\u002FReferer avec le Host.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"authentification\">Authentification\u003C\u002Fh2>\n\n\u003Ch3>Le modèle en deux couches\u003C\u002Fh3>\n\n\u003Cp>La sécurité repose sur une architecture à deux niveaux indépendants :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Couche infrastructure\u003C\u002Fstrong> : tunnel chiffré vers le port local du serveur, combiné à une porte de knock nginx (cookie + slug). Toute requête qui franchit cette porte est déjà qualifiée « propriétaire ».\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Couche applicative\u003C\u002Fstrong> : un middleware de démarrage injecte automatiquement un cookie de session signé « fondateur » pour toute requête qui n'en présente pas. En conséquence, la vérification de session applicative passe toujours sur le runtime vaisseau-mère — la sécurité réelle est entièrement portée par l'infrastructure.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>Ce middleware d'auto-session est \u003Cstrong>strictement limité au vaisseau-mère\u003C\u002Fstrong>. Il n'existe pas dans le cœur du produit ni dans les instances tenant. Sur les tenants publics, la vérification de session reste obligatoire et constitue la vraie garde applicative.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Les fonctions de vérification de session\u003C\u002Fh3>\n\n\u003Cp>Quatre fonctions utilitaires encadrent le contrôle d'accès applicatif :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Lecture de session\u003C\u002Fstrong> : décode le cookie de session (JSON signé HMAC-SHA256). Retourne \u003Ccode>null\u003C\u002Fcode> si le cookie est absent ou invalide.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Garde employé\u003C\u002Fstrong> (\u003Ccode>requireEmployeeSession\u003C\u002Fcode>) : renvoie la session si le type d'utilisateur est \u003Ccode>employee\u003C\u002Fcode>, déclenche une erreur 401 sinon. C'est la garde standard des surfaces cockpit et transcription.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Garde fondateur\u003C\u002Fstrong> : exige en plus le statut Super-Admin SaaS, erreur 403 sinon.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Garde par rôle\u003C\u002Fstrong> : exige un rôle métier donné ou le statut Super-Admin SaaS.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>La liste des Super-Admins SaaS est une liste blanche statique dans le code source — volontairement non stockée en base de données, de sorte que toute modification exige un changement de code et une revue explicite.\u003C\u002Fp>\n\n\u003Cp>La session porte les champs suivants : identifiant employé, e-mail, prénom, nom, rôle, identifiant de profil, identifiant client, type d'utilisateur, indicateur administrateur.\u003C\u002Fp>\n\n\u003Ch3>Le middleware de routage est désactivé\u003C\u002Fh3>\n\n\u003Cp>Le middleware de routage Nuxt côté cockpit est intentionnellement réduit à un no-op (il retourne immédiatement sans effectuer aucun contrôle). La porte nginx et le tunnel chiffré assurent la protection en amont ; un contrôle supplémentaire côté Nuxt serait redondant.\u003C\u002Fp>\n\n\u003Cp>Ce middleware reste déclaré car de nombreuses pages y font référence dans leurs métadonnées de route. Le no-op étant volontaire, cette déclaration n'a aucun impact fonctionnel.\u003C\u002Fp>\n\n\u003Ch2 id=\"layout-cockpit\">Layout du cockpit\u003C\u002Fh2>\n\n\u003Cp>Le cockpit repose sur un layout unique qui structure l'ensemble des pages de l'interface. Ce layout n'hérite d'aucun layout parent : le vaisseau-mère est une application autonome.\u003C\u002Fp>\n\n\u003Cp>Points notables :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>L'identité affichée dans l'interface est un stub statique — l'authentification dynamique Nuxt a été retirée ; c'est la couche infrastructure qui garantit l'identité réelle de l'opérateur.\u003C\u002Fli>\n  \u003Cli>Le titre des pages suit le gabarit \u003Cem>… — Synedre OS\u003C\u002Fem>.\u003C\u002Fli>\n  \u003Cli>Les pages temps-réel (reactor, cockpit chantier) sont rendues côté client uniquement (\u003Ccode>ssr: false\u003C\u002Fcode>), ce qui leur permet de maintenir des connexions SSE persistantes.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note de cohérence :\u003C\u002Fstrong> le commentaire d'en-tête du layout liste les entrées de navigation de façon incomplète. La structure de navigation réelle, définie dans le tableau des sections du layout, fait toujours foi sur ces commentaires.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"surfaces-console\">Les surfaces console du Hub\u003C\u002Fh2>\n\n\u003Cp>Le Hub expose plusieurs consoles de pilotage des agents. Chaque console est une vue spécialisée sur un type d'activité : exécutions en cours, chantiers de développement, négociations commerciales, supervision de flotte, ou vue orbitale temps réel. Les données sont centralisées dans un modèle partagé, exposé via des entités métier Python et des tables relationnelles.\u003C\u002Fp>\n\n\u003Ch2 id=\"runs\">Exécutions scopées (Runs)\u003C\u002Fh2>\n\n\u003Cp>Un \u003Cstrong>run\u003C\u002Fstrong> représente une exécution scopée d'Atlas — qu'elle soit déclenchée par email, par chat console, ou par un cron. Chaque run porte les attributs suivants : identifiant unique, source de déclenchement, type de trigger, périmètre (vaisseau-mère ou tenant), titre, statut, type et identifiant de référence, dates d'ajout et de fin.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Source \u003Ccode>atlas-inbox\u003C\u002Fcode> : run déclenché par un email entrant.\u003C\u002Fli>\n  \u003Cli>Source \u003Ccode>console\u003C\u002Fcode> : run déclenché par le chat du Hub.\u003C\u002Fli>\n  \u003Cli>Les emails classifiés comme question, bruit ou intention de chantier \u003Cstrong>ne génèrent pas\u003C\u002Fstrong> de run : ils restent dans leurs espaces dédiés (questions, chantiers).\u003C\u002Fli>\n  \u003Cli>Un run d'exécution d'automate (\u003Cem>task run\u003C\u002Fem>) est une entité distincte — ne pas confondre avec un run Atlas.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>La vue runs liste toutes les exécutions, filtrables par périmètre. Une vue détaillée par agent permet de consulter le fil d'événements en temps réel via un flux SSE, de lire ou poster un brouillon de réponse, et de déclencher un correctif.\u003C\u002Fp>\n\n\u003Ch2 id=\"chantiers\">Chantiers, travaux et tâches\u003C\u002Fh2>\n\n\u003Cp>Un \u003Cstrong>chantier\u003C\u002Fstrong> est l'unité de pilotage d'un projet de développement. Il se décompose en \u003Cstrong>travaux\u003C\u002Fstrong>, eux-mêmes décomposés en \u003Cstrong>tâches\u003C\u002Fstrong>. Cette hiérarchie à trois niveaux structure l'ensemble du suivi opérationnel.\u003C\u002Fp>\n\n\u003Ch3>Modèle hiérarchique\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Chantier\u003C\u002Fstrong> : projet, porté par une entité dédiée. Lié à N travaux.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Travail\u003C\u002Fstrong> : unité de livraison au sein d'un chantier. Lié à N tâches.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tâche\u003C\u002Fstrong> : action atomique. Peut dépendre d'autres tâches (graphe orienté acyclique).\u003C\u002Fli>\n  \u003Cli>Des tables de liaison associent agents et chantiers d'une part, agents et travaux d'autre part.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>La création canonique d'un chantier passe par une procédure en sept étapes qui initialise le squelette complet (chantier + premiers travaux + tâches).\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note d'architecture :\u003C\u002Fstrong> le modèle de données présente une dette de nommage historique. Les entités chantier et travail utilisent un préfixe hérité de l'ère PaaS, tandis que les tâches et les tables de liaison ont déjà migré vers le préfixe cible. Il n'existe pas de vue ou table intermédiaire portant le nouveau préfixe pour les chantiers et travaux eux-mêmes — la migration est en cours selon le pattern Strangler Fig.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Entités de contrôle de concurrence et d'audit\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Composant\u003C\u002Fth>\n      \u003Cth>Rôle\u003C\u002Fth>\n      \u003Cth>Points clés\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Verrou de chantier\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Empêche deux sessions de modifier simultanément le même chantier\u003C\u002Ftd>\n      \u003Ctd>Clé composite (chantier × type de propriétaire) ; propriétaires possibles : session utilisateur ou sous-processus agent spawné. TTL 30 min avec heartbeat. Mode de compatibilité descendante si la table est absente.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Erreur de verrouillage\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Exception levée quand le verrou est tenu par une autre session active\u003C\u002Ftd>\n      \u003Ctd>Interceptée par la couche compétence chantier avant toute modification.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Journal d'audit des explosions\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Trace chaque invocation du pipeline de découverte automatique de travaux\u003C\u002Ftd>\n      \u003Ctd>Une ligne par invocation ; cycle de vie \u003Ccode>pending → success | validation_failed | llm_failed | killswitched\u003C\u002Fcode>. Stocke le modèle IA utilisé, le fournisseur, les tokens consommés, le coût estimé, le plan JSON produit et le nombre de travaux créés. Rétention 90 jours. Un quota sur 24 h déclenche un kill-switch configurable.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Dépendances de tâches (DAG)\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Modélise les relations de blocage entre tâches au sein d'un travail\u003C\u002Ftd>\n      \u003Ctd>Validations à l'ajout : pas d'auto-dépendance, tâches dans le même travail, pas de cycle (détection DFS). Lève des exceptions typées pour cycle détecté ou tentative de dépendance inter-travaux.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Vues et fonctionnalités de la console chantiers\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Vue liste des chantiers actifs et vue kanban par travail.\u003C\u002Fli>\n  \u003Cli>Vue cockpit : sessions agents en cours sur un chantier.\u003C\u002Fli>\n  \u003Cli>Console CLI en direct : démarrage, arrêt, reset de session, flux d'événements agents en temps réel (SSE).\u003C\u002Fli>\n  \u003Cli>Actions disponibles : rédiger la mission, lancer en mode automatique, archiver, clore avec brouillon d'email, basculer en brainstorming, gérer les livrables, gérer l'équipe, auditer la pertinence.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"console-cli\">Console CLI Synedre\u003C\u002Fh2>\n\n\u003Cp>Le cockpit embarque une surface de pilotage d'une session Claude CLI réelle, accessible depuis le navigateur. Le mécanisme repose sur un \u003Cstrong>daemon côté machine hôte\u003C\u002Fstrong> (et non dans un container isolé) qui relaie les interactions.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Statut\u003C\u002Fstrong> : interroge le daemon et retourne un état \u003Ccode>{ ok, alive, info }\u003C\u002Fcode>. Si le daemon ne répond pas, la surface renvoie \u003Ccode>alive: false\u003C\u002Fcode> sans exposer le message d'erreur interne au client — comportement de sécurité explicite.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Envoi de touches\u003C\u002Fstrong> : transmet des entrées clavier à la session active.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Flux temps réel\u003C\u002Fstrong> : stream SSE de la sortie de la session.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Point d'attention :\u003C\u002Fstrong> l'architecture daemon hôte (et non container) est intentionnelle — elle résout un problème d'isolation identifié lors d'un travail dédié à ce sujet.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"negociations\">Négociations\u003C\u002Fh2>\n\n\u003Cp>Les \u003Cstrong>négociations\u003C\u002Fstrong> modélisent le pipeline de traitement des leads entrants. Un email reçu est analysé par Atlas ; si l'intention détectée est \u003Ccode>negociation\u003C\u002Fcode>, un item de négociation est créé et apparaît dans la console dédiée.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Vue liste des négociations en cours et vue détail par négociation.\u003C\u002Fli>\n  \u003Cli>Actions disponibles sur une négociation : assigner, gérer les contacts, gérer les livrables (dont les fichiers joints), consulter les emails liés, créer un événement, suivre la timeline, gérer les propositions commerciales.\u003C\u002Fli>\n  \u003Cli>Sur chaque proposition : endpoint de décision (accepter \u002F refuser).\u003C\u002Fli>\n  \u003Cli>Action de démarrage de travail : bascule la négociation vers un chantier opérationnel.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"fleet\">Module flotte (Fleet)\u003C\u002Fh2>\n\n\u003Cp>Le module flotte est un composant \u003Cstrong>serveur uniquement\u003C\u002Fstrong>, sans interface Hub propre à ce jour. Il expose un schéma de données destiné à être consommé par une future interface dédiée.\u003C\u002Fp>\n\n\u003Cp>Le modèle de données du registre de flotte inclut, pour chaque instance client : identifiant, nom, domaine, offre souscrite, MRR, frais de setup, statut, région du VPS, URL d'administration, fournisseur IA et modèle IA configurés.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Avertissement :\u003C\u002Fstrong> ce registre comporte des colonnes historiques destinées à stocker des secrets (mots de passe d'administration, clés API). Ce schéma est hérité de l'ère PaaS et est \u003Cstrong>incohérent avec la doctrine zéro-secret en base de données métier\u003C\u002Fstrong>. Il est en attente d'audit et ne doit pas être considéré comme la source canonique des secrets opérationnels.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>La source de vérité opérationnelle pour le pilotage des VPS clients reste le registre VPS principal. La relation exacte entre ce registre et le modèle flotte est à confirmer. Le pilotage opérationnel des tenants s'effectue principalement via les consoles d'administration des sites et des clients.\u003C\u002Fp>\n\n\u003Ch2 id=\"reacteur\">Vue orbitale — Réacteur\u003C\u002Fh2>\n\n\u003Cp>La vue \u003Cstrong>Réacteur\u003C\u002Fstrong> est une représentation orbitale en direct de l'activité des agents. Elle s'organise en trois anneaux concentriques selon le rôle de chaque agent :\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Anneau 1 (centre)\u003C\u002Fstrong> : agents de direction.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Anneau 2\u003C\u002Fstrong> : agents de cadrage et d'exécution.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Anneau 3 (périphérie)\u003C\u002Fstrong> : agents de validation.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Un logo pieuvre occupe le centre. La vue est alimentée en temps réel par SSE. Elle est rendue côté client uniquement (pas de rendu serveur). Elle est adaptée de la page marketing publique du réacteur.\u003C\u002Fp>\n\n\u003Ch2 id=\"points-entree-developpeur\">Points d'entrée pour étendre le Hub\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Objectif\u003C\u002Fth>\n      \u003Cth>Mécanisme\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Ajouter une entrée dans la barre latérale\u003C\u002Ftd>\n      \u003Ctd>Modifier le tableau de sections de navigation dans le layout Hub principal.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Ajouter une page \u003Ccode>\u002Fhub\u002FX\u003C\u002Fcode>\u003C\u002Ftd>\n      \u003Ctd>Créer la page dans le module concerné et déclarer le layout \u003Ccode>hub\u003C\u002Fcode> dans les métadonnées de page.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Ajouter un endpoint cockpit\u003C\u002Ftd>\n      \u003Ctd>Créer l'endpoint dans le dossier API du module concerné et y appliquer le middleware de vérification de session employé.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Comprendre l'authentification\u003C\u002Ftd>\n      \u003Ctd>Consulter les utilitaires de session et le middleware d'auto-session, qui gèrent la signature HMAC des cookies de session Hub.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Brancher un nouveau module\u003C\u002Ftd>\n      \u003Ctd>Déclarer le module dans la configuration d'extension Nuxt et fournir un manifeste et une configuration locale au module.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Travailler sur les exécutions et chantiers (base de données)\u003C\u002Ftd>\n      \u003Ctd>Passer par les entités métier Python du dépôt et les tables correspondantes : runs Atlas, chantiers, travaux, tâches, négociations — toutes dans le schéma du vaisseau-mère.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Consulter le cadran de maintenance et de dérive documentaire\u003C\u002Ftd>\n      \u003Ctd>Utiliser la vue de maintenance du Hub et son endpoint associé, qui exploitent les tables de santé documentaire et de dérive détectée.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Revue externe de documentation\u003C\u002Ftd>\n      \u003Ctd>Utiliser le composant de panneau de revue externe et ses endpoints dédiés, appuyés sur la table de revues externes.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Registre des réflexes et hooks\u003C\u002Ftd>\n      \u003Ctd>Consulter la vue hooks du Hub et son endpoint de listing, qui expose le registre des réflexes organisés par niveau (tronc \u002F bras).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Verrou de chantier (concurrence CLI)\u003C\u002Ftd>\n      \u003Ctd>Utiliser l'entité de verrouillage distribuée : opérations \u003Ccode>try_acquire\u003C\u002Fcode>, \u003Ccode>force_claim\u003C\u002Fcode>, \u003Ccode>release\u003C\u002Fcode>, \u003Ccode>heartbeat\u003C\u002Fcode>.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Audit des invocations de découverte automatique\u003C\u002Ftd>\n      \u003Ctd>Consulter l'entité d'audit : méthodes de recherche des invocations récentes et de comptage sur 24 h.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Dépendances de tâches (DAG)\u003C\u002Ftd>\n      \u003Ctd>Utiliser l'entité de dépendances : opérations \u003Ccode>add_dep\u003C\u002Fcode>, \u003Ccode>remove_dep\u003C\u002Fcode>, \u003Ccode>list_deps_for_travail\u003C\u002Fcode> avec détection anti-cycle DFS.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Gestion des secrets :\u003C\u002Fstrong> aucun secret n'est stocké en clair dans le code. La clé de signature des cookies de session Hub est consommée via HMAC par la couche cryptographique de session ; sa variable d'environnement réside dans les fichiers d'environnement exclus du dépôt, conformément à la doctrine des secrets.\u003C\u002Fp>\n\u003C\u002Fblockquote>","\u003Ch2 id=\"hub-presentation\">The Hub — agentic control dashboard\u003C\u002Fh2>\n\n\u003Cp>The Hub is the private administration interface of Synedre OS. Accessible only from the mothership VPS via a secure tunnel, it enables full control over the agentic harness: agents, projects, runs, negotiations, memory, and infrastructure.\u003C\u002Fp>\n\n\u003Ch3>A dedicated cockpit application\u003C\u002Fh3>\n\n\u003Cp>The Hub is built on a \u003Cstrong>standalone\u003C\u002Fstrong> Nuxt application, distinct from any other application surface. It inherits no localization module and no theme management: it is \u003Cstrong>French-only\u003C\u002Fstrong> and enforces permanent dark mode (the light\u002Fdark toggle was removed in May 2026). This choice of visual austerity reflects the operational nature of the tool.\u003C\u002Fp>\n\n\u003Ch3>Layered functional architecture\u003C\u002Fh3>\n\n\u003Cp>The Hub is not a monolith. Its features are distributed across \u003Cstrong>independent modules\u003C\u002Fstrong>, loaded as Nuxt layers at startup. Each layer brings its own pages, its own API endpoints, and its own server-side code, automatically discovered by the routing engine.\u003C\u002Fp>\n\n\u003Cp>Two categories are distinguished:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Core components\u003C\u002Fstrong> — pages and endpoints directly carried by the main application: general dashboard, cost view, backup management, maintenance dial.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Thematic modules\u003C\u002Fstrong> — each encapsulates a business or technical domain and exposes its own \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode> routes along with its own API endpoints.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>In total, the Hub aggregates \u003Cstrong>27 active functional layers\u003C\u002Fstrong>, covering domains as varied as agent management, project tracking, billing, memory, automations, SEO monitoring, and internal training.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architecture note:\u003C\u002Fstrong> these layers are declared via the \u003Ccode>extends:\u003C\u002Fcode> key in the Nuxt configuration, and \u003Cem>not\u003C\u002Fem> via the \u003Ccode>modules:\u003C\u002Fcode> key. Confusing the two causes load errors at startup. Each layer has its own minimal Nuxt configuration file.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"hub-pages-map\">Page and module map\u003C\u002Fh2>\n\n\u003Ch3>Core pages\u003C\u002Fh3>\n\n\u003Cp>The main application directly exposes several global control pages:\u003C\u002Fp>\n\u003Cul>\n  \u003Cli>\u003Cstrong>Root \u003Ccode>\u002Fhub\u003C\u002Fcode>\u003C\u002Fstrong> — automatic redirect (302) to the main dashboard; this is not a standalone page.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>SRE view\u003C\u002Fstrong> — mothership reliability supervision.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Cost view\u003C\u002Fstrong> — expense tracking, accessible from the main navigation; a detailed sub-view breaks down costs by project and by annual budget.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Agentic learning view\u003C\u002Fstrong> — skill progression tracking dashboard.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Backup view\u003C\u002Fstrong> — infrastructure backup status.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Maintenance dial\u003C\u002Fstrong> — supervision interface for the documentary and technical health of the system, detailed below.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Maintenance dial — two tabs\u003C\u002Fh3>\n\n\u003Cp>The maintenance dial is the internal observatory for system health. It consists of two tabs:\u003C\u002Fp>\n\n\u003Col>\n  \u003Cli>\n    \u003Cstrong>Health dashboard\u003C\u002Fstrong> — a global gauge aggregates four system health dimensions: proprioception, technical debt, learning, and automations. A 7-day trend chart accompanies a documentary drift table, classifying discrepancies by type: dead reference, outdated published document, code more recent than its documentation, unpublished document.\n  \u003C\u002Fli>\n  \u003Cli>\n    \u003Cstrong>External review\u003C\u002Fstrong> — the operator selects a chapter of public documentation, generates a prompt stripped of any sensitive data, submits it to an external AI model, then pastes the response into the form for archiving. The submission history is browsable. The maximum size of a submitted response is 50,000 characters. Eleven chapters are eligible for this external review.\n  \u003C\u002Fli>\n\u003C\u002Fol>\n\n\u003Ch3>Pages carried by thematic modules\u003C\u002Fh3>\n\n\u003Cp>The 27 modules collectively contribute 49 additional pages under \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode>. The table below shows their distribution by functional domain:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Functional domain\u003C\u002Fth>\n      \u003Cth>Pages \u003Ccode>\u002Fhub\u002F*\u003C\u002Fcode>\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Agents & agentic operations\u003C\u002Ftd>\n      \u003Ctd>38 pages: main dashboard, agent profiles, brainstorm, projects (list, profile, kanban, work), clients, advisory, constitution, dispatch, doctrine, emails, hooks, inbox, legal, memory (navigation, RAG search), negotiations, questions, reactor, runs (list, profile, atlas), sessions, settings, skills, pending skills, user model\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Backlog & planning\u003C\u002Ftd>\n      \u003Ctd>3 pages: backlog, planning, system backlog\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Cockpits & projects\u003C\u002Ftd>\n      \u003Ctd>2 pages: project profile, cockpits view\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Exercises & training\u003C\u002Ftd>\n      \u003Ctd>2 pages: exercise list, detail by agent\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Scars\u003C\u002Ftd>\n      \u003Ctd>1 page: scar registry\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Conducts\u003C\u002Ftd>\n      \u003Ctd>1 page: conduct table\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Automations\u003C\u002Ftd>\n      \u003Ctd>1 page: system automation management\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>SEO monitoring\u003C\u002Ftd>\n      \u003Ctd>1 page: technical multi-tenant SEO cockpit (404 rate, click\u002Fimpression trend, observation or auto-remediation mode, alert log) — accessible by direct URL, absent from the side navigation\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Public surface of the Exercises module:\u003C\u002Fstrong> this module also exposes four \u003Cem>public\u003C\u002Fem> pages on synedre.com (outside the \u003Ccode>\u002Fhub\u003C\u002Fcode> space): exercise list, history, scars, and trial detail. These pages are not counted among the 49 hub pages above.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Modules with no Vue page (server-only)\u003C\u002Fh3>\n\n\u003Cp>Several modules expose no interface page. They exclusively provide API endpoints and a persistence layer, consumed by other Hub pages or by Python automations. They cover in particular: internal academic management, autoblog article tracking, client configuration, daily messaging, billing, incidents, meetings, utility tools, and other cross-cutting services.\u003C\u002Fp>\n\n\u003Cp>A module dedicated to Hub statistics exposes summary data (\u003Ccode>\u002Fapi\u002Fstats\u003C\u002Fcode>), constitution and charter resources (\u003Ccode>\u002Fapi\u002Fun composant interne\u003C\u002Fcode>, \u003Ccode>\u002Fapi\u002Fun composant interne\u003C\u002Fcode>), and avatar statistics — without ever presenting its own interface page.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong> the expertise pages module contributes public SEO pages (outside \u003Ccode>\u002Fhub\u002F\u003C\u002Fcode>), not cockpit pages.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"hub-navigation\">Side navigation — the seven zones\u003C\u002Fh2>\n\n\u003Cp>The cockpit navigation bar is organized into \u003Cstrong>seven thematic zones\u003C\u002Fstrong>, restructured in May 2026 to reflect the operational workflow:\u003C\u002Fp>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Zone\u003C\u002Fth>\n      \u003Cth>Entries\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Control\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Main dashboard · Emails · Brainstorm · User model\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Business\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Clients · Negotiations · Advisory · Legal\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Execution\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Backlog · Project · Runs · Questions · New task · Sessions\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Doctrine & Learning\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Doctrine · Constitution · Scars · Exercises\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Agentic\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Agents · Reactor · Skills · Pending skills · System automations · Dispatch · Hooks & Reflexes · Agentic learning\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Memory\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Brain (memory navigation) · Recall RAG (semantic search)\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>System\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>SRE · Maintenance dial · Costs · Backups · Settings\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cp>A separate link, placed at the bottom of the navigation, provides access to the PaaS e-commerce surface. This surface is served by an application distinct from the Synedre OS cockpit — it is not an internal Hub page.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Active behavior:\u003C\u002Fstrong> a navigation entry is marked as active on exact match of the current route \u003Cem>or\u003C\u002Fem> on prefix match (sub-route). The \u003Ccode>\u002Fhub\u003C\u002Fcode> root always redirects to the main dashboard and does not constitute a destination in its own right.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"familles-endpoints\">The three endpoint families\u003C\u002Fh2>\n\n\u003Cp>The API route split is not merely organizational: it carries an access-rights semantics. Three prefixes coexist, each with its own protection level.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fbo\u002F*\u003C\u002Fcode> — founder\u002Fcron back-office surface, protected upstream by the infrastructure gate, sometimes without an additional application-layer guard.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fhub\u002F*\u003C\u002Fcode> — employee cockpit surface, with near-systematic session verification.\u003C\u002Fli>\n  \u003Cli>\u003Ccode>\u002Fapi\u002Fvoice\u002F*\u003C\u002Fcode> — audio transcription, with session verification and CSRF defense.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Back-office surface\u003C\u002Fh3>\n\n\u003Cp>This family groups the endpoints reserved for founder operations and scheduled tasks. It is divided into several functional sub-domains:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Learning\u003C\u002Fstrong>: browsing the learning feed, applying and updating entries.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Project\u003C\u002Fstrong>: triggering and editing project explosions, checking status, launching a phase.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Quality indicators\u003C\u002Fstrong>: reading scar KPIs.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Costs\u003C\u002Fstrong>: dashboard, budget (read\u002Fwrite), time series, per-project view.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Inbox\u003C\u002Fstrong>: synchronization, list, detail, attachments, linking to a project.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Mothership infrastructure\u003C\u002Fstrong>: backup list, download, reading documentation health status and detected drift.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>External documentation review\u003C\u002Fstrong>: list of eligible chapters, generation of the sanitized prompt for an external AI model, review history (with filters), submission of an external review.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>SRE metrics\u003C\u002Fstrong>: reading reliability metrics.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Tenants\u003C\u002Fstrong>: automatic dispatch status per tenant.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>\u003Cstrong>Authentication specifics:\u003C\u002Fstrong> certain endpoints in this surface rely exclusively on the infrastructure gate (knock cookie + slug) rather than on application-layer session verification. This is notably the case for the inbox synchronization endpoint, triggered by a system cron job.\u003C\u002Fp>\n\n\u003Cp>This choice is tied to a technical constraint: IMAP synchronization blocks the Node.js event loop and is therefore excluded from the internal scheduler. The seven other periodic tasks are managed by that scheduler:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>E-mail queue processing (every 2 minutes)\u003C\u002Fli>\n  \u003Cli>Availability monitoring (every 15 minutes)\u003C\u002Fli>\n  \u003Cli>Dictionary watch (every 30 minutes)\u003C\u002Fli>\n  \u003Cli>Dependency monitoring (daily, 2 a.m.)\u003C\u002Fli>\n  \u003Cli>Daily audit meeting (daily, 8 a.m.)\u003C\u002Fli>\n  \u003Cli>SSL certificate monitoring (daily, 9 a.m.)\u003C\u002Fli>\n  \u003Cli>Brand watch (daily, 12 p.m.)\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch3>Employee cockpit surface\u003C\u002Fh3>\n\n\u003Cp>This family is by far the largest. It groups the endpoints used by the cockpit interfaces: management of agents, projects, runs, negotiations, advisory, clients, brainstorming, memory, doctrine, skills, sessions, questions, tasks, the user model, settings, agent allocation, and the atlas.\u003C\u002Fp>\n\n\u003Cp>Employee session verification is applied in the vast majority of files in this surface. Exceptions are internal helpers or SSE (Server-Sent Events) streams. The standard pattern is written as:\u003C\u002Fp>\n\n\u003Cpre>\u003Ccode>export default defineEventHandler(async (event) => {\n  requireEmployeeSession(event)\n  \u002F\u002F …\n})\u003C\u002Fcode>\u003C\u002Fpre>\n\n\u003Cp>A subset of endpoints specifically manages the lifecycle of a project: active runs, discovered bugs, CLI sessions (start, stop, reset), real-time agent event streams (SSE), as well as actions on a given run (response draft, fix trigger, profile, event stream).\u003C\u002Fp>\n\n\u003Ch3>Audio transcription surface\u003C\u002Fh3>\n\n\u003Cp>A single endpoint accepts a WAV audio file as multipart and returns the transcribed text, the detected locale, the duration in milliseconds, the model used, and the backend invoked. The default locale is French.\u003C\u002Fp>\n\n\u003Cp>The applied safeguards are as follows:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Mandatory employee session verification.\u003C\u002Fli>\n  \u003Cli>Maximum file size: 5 MB.\u003C\u002Fli>\n  \u003Cli>Rate limit: 100 transcriptions per 5-minute window per session.\u003C\u002Fli>\n  \u003Cli>Audio is never persisted to disk: in-memory processing only.\u003C\u002Fli>\n  \u003Cli>CSRF defense via Origin\u002FReferer matching against the Host header.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"authentification\">Authentication\u003C\u002Fh2>\n\n\u003Ch3>The two-layer model\u003C\u002Fh3>\n\n\u003Cp>Security relies on an architecture with two independent levels:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Infrastructure layer\u003C\u002Fstrong>: encrypted tunnel to the server's local port, combined with an nginx knock gate (cookie + slug). Any request that clears this gate is already qualified as \"owner\".\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Application layer\u003C\u002Fstrong>: a startup middleware automatically injects a signed \"founder\" session cookie for any request that does not present one. As a result, application-layer session verification always passes on the mothership runtime — real security is entirely carried by the infrastructure.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>This auto-session middleware is \u003Cstrong>strictly limited to the mothership\u003C\u002Fstrong>. It does not exist in the product core or in tenant instances. On public tenants, session verification remains mandatory and constitutes the true application-layer guard.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>The session verification functions\u003C\u002Fh3>\n\n\u003Cp>Four utility functions govern application-layer access control:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Session read\u003C\u002Fstrong>: decodes the session cookie (HMAC-SHA256 signed JSON). Returns \u003Ccode>null\u003C\u002Fcode> if the cookie is absent or invalid.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Employee guard\u003C\u002Fstrong> (\u003Ccode>requireEmployeeSession\u003C\u002Fcode>): returns the session if the user type is \u003Ccode>employee\u003C\u002Fcode>, raises a 401 error otherwise. This is the standard guard for the cockpit and transcription surfaces.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Founder guard\u003C\u002Fstrong>: additionally requires SaaS Super-Admin status, 403 error otherwise.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Role guard\u003C\u002Fstrong>: requires a given business role or SaaS Super-Admin status.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The SaaS Super-Admin list is a static whitelist in the source code — intentionally not stored in the database, so that any modification requires a code change and an explicit review.\u003C\u002Fp>\n\n\u003Cp>The session carries the following fields: employee identifier, e-mail, first name, last name, role, profile identifier, client identifier, user type, administrator flag.\u003C\u002Fp>\n\n\u003Ch3>The routing middleware is disabled\u003C\u002Fh3>\n\n\u003Cp>The Nuxt routing middleware on the cockpit side is intentionally reduced to a no-op (it returns immediately without performing any check). The nginx gate and the encrypted tunnel provide upstream protection; an additional check on the Nuxt side would be redundant.\u003C\u002Fp>\n\n\u003Cp>This middleware remains declared because many pages reference it in their route metadata. The no-op being intentional, this declaration has no functional impact.\u003C\u002Fp>\n\n\u003Ch2 id=\"layout-cockpit\">Cockpit layout\u003C\u002Fh2>\n\n\u003Cp>The cockpit relies on a single layout that structures all pages of the interface. This layout inherits from no parent layout: the mothership is a standalone application.\u003C\u002Fp>\n\n\u003Cp>Notable points:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>The identity displayed in the interface is a static stub — dynamic Nuxt authentication has been removed; the infrastructure layer guarantees the operator's actual identity.\u003C\u002Fli>\n  \u003Cli>Page titles follow the template \u003Cem>… — Synedre OS\u003C\u002Fem>.\u003C\u002Fli>\n  \u003Cli>Real-time pages (reactor, project cockpit) are rendered client-side only (\u003Ccode>ssr: false\u003C\u002Fcode>), allowing them to maintain persistent SSE connections.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Consistency note:\u003C\u002Fstrong> the layout header comment lists navigation entries incompletely. The actual navigation structure, defined in the layout's sections array, always takes precedence over these comments.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"surfaces-console\">Hub Console Surfaces\u003C\u002Fh2>\n\n\u003Cp>The Hub exposes several agent control consoles. Each console is a specialized view over a specific type of activity: active runs, development projects, commercial negotiations, fleet supervision, or live orbital view. Data is centralized in a shared model, exposed via Python business entities and relational tables.\u003C\u002Fp>\n\n\u003Ch2 id=\"runs\">Scoped Executions (Runs)\u003C\u002Fh2>\n\n\u003Cp>A \u003Cstrong>run\u003C\u002Fstrong> represents a scoped Atlas execution — whether triggered by email, hub console chat, or a cron job. Each run carries the following attributes: unique identifier, trigger source, trigger type, scope (mothership or tenant), title, status, reference type and identifier, creation and completion dates.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Source \u003Ccode>atlas-inbox\u003C\u002Fcode>: run triggered by an incoming email.\u003C\u002Fli>\n  \u003Cli>Source \u003Ccode>console\u003C\u002Fcode>: run triggered by the Hub chat.\u003C\u002Fli>\n  \u003Cli>Emails classified as questions, noise, or project intent \u003Cstrong>do not generate\u003C\u002Fstrong> a run: they remain in their dedicated spaces (questions, projects).\u003C\u002Fli>\n  \u003Cli>An automaton task run (\u003Cem>task run\u003C\u002Fem>) is a distinct entity — not to be confused with an Atlas run.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The runs view lists all executions, filterable by scope. A per-agent detail view allows browsing the event stream in real time via an SSE feed, reading or posting a draft reply, and triggering a corrective action.\u003C\u002Fp>\n\n\u003Ch2 id=\"chantiers\">Projects, Work Units, and Tasks\u003C\u002Fh2>\n\n\u003Cp>A \u003Cstrong>project\u003C\u002Fstrong> is the control unit for a development effort. It breaks down into \u003Cstrong>work units\u003C\u002Fstrong>, which in turn break down into \u003Cstrong>tasks\u003C\u002Fstrong>. This three-level hierarchy structures all operational tracking.\u003C\u002Fp>\n\n\u003Ch3>Hierarchical Model\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Project\u003C\u002Fstrong>: development effort, carried by a dedicated entity. Linked to N work units.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Work unit\u003C\u002Fstrong>: delivery unit within a project. Linked to N tasks.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Task\u003C\u002Fstrong>: atomic action. May depend on other tasks (directed acyclic graph).\u003C\u002Fli>\n  \u003Cli>Junction tables associate agents with projects on one hand, and agents with work units on the other.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>The canonical creation of a project follows a seven-step procedure that initializes the full skeleton (project + initial work units + tasks).\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Architecture note:\u003C\u002Fstrong> the data model carries a historical naming debt. Project and work unit entities use a prefix inherited from the PaaS era, while tasks and junction tables have already migrated to the target prefix. No intermediate view or table bearing the new prefix exists yet for projects and work units themselves — migration is ongoing following the Strangler Fig pattern.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch3>Concurrency Control and Audit Entities\u003C\u002Fh3>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Component\u003C\u002Fth>\n      \u003Cth>Role\u003C\u002Fth>\n      \u003Cth>Key points\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Project lock\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Prevents two sessions from concurrently modifying the same project\u003C\u002Ftd>\n      \u003Ctd>Composite key (project × owner type); possible owners: user session or spawned agent subprocess. 30-minute TTL with heartbeat. Backward-compatibility mode when the table is absent.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Lock error\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Exception raised when the lock is held by another active session\u003C\u002Ftd>\n      \u003Ctd>Intercepted by the project competency layer before any modification.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Explosion audit log\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Traces each invocation of the automatic work-unit discovery pipeline\u003C\u002Ftd>\n      \u003Ctd>One row per invocation; lifecycle \u003Ccode>pending → success | validation_failed | llm_failed | killswitched\u003C\u002Fcode>. Stores the AI model used, provider, tokens consumed, estimated cost, produced JSON plan, and number of work units created. 90-day retention. A 24-hour quota triggers a configurable kill-switch.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>\u003Cstrong>Task dependencies (DAG)\u003C\u002Fstrong>\u003C\u002Ftd>\n      \u003Ctd>Models blocking relationships between tasks within a work unit\u003C\u002Ftd>\n      \u003Ctd>Validations on insertion: no self-dependency, tasks must belong to the same work unit, no cycle (DFS detection). Raises typed exceptions for detected cycles or cross-work-unit dependency attempts.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Ch3>Project Console Views and Features\u003C\u002Fh3>\n\n\u003Cul>\n  \u003Cli>Active project list view and per-work-unit kanban view.\u003C\u002Fli>\n  \u003Cli>Cockpit view: active agent sessions on a project.\u003C\u002Fli>\n  \u003Cli>Live CLI console: session start, stop, reset, and real-time agent event stream (SSE).\u003C\u002Fli>\n  \u003Cli>Available actions: draft mission statement, launch in automatic mode, archive, close with email draft, switch to brainstorming mode, manage deliverables, manage team, audit relevance.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"console-cli\">Synedre CLI Console\u003C\u002Fh2>\n\n\u003Cp>The cockpit embeds a control surface for a real Claude CLI session, accessible from the browser. The mechanism relies on a \u003Cstrong>daemon running on the host machine\u003C\u002Fstrong> (not inside an isolated container) that relays interactions.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Status\u003C\u002Fstrong>: queries the daemon and returns a state \u003Ccode>{ ok, alive, info }\u003C\u002Fcode>. If the daemon does not respond, the surface returns \u003Ccode>alive: false\u003C\u002Fcode> without exposing the internal error message to the client — an explicit security behavior.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Keystroke forwarding\u003C\u002Fstrong>: transmits keyboard input to the active session.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Real-time stream\u003C\u002Fstrong>: SSE stream of the session output.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Note:\u003C\u002Fstrong> the host daemon architecture (rather than container) is intentional — it resolves an isolation issue identified during a dedicated work unit on this topic.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Ch2 id=\"negociations\">Negotiations\u003C\u002Fh2>\n\n\u003Cp>\u003Cstrong>Negotiations\u003C\u002Fstrong> model the inbound lead processing pipeline. An incoming email is analyzed by Atlas; if the detected intent is \u003Ccode>negociation\u003C\u002Fcode>, a negotiation item is created and appears in the dedicated console.\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>Negotiation list view and per-negotiation detail view.\u003C\u002Fli>\n  \u003Cli>Available actions on a negotiation: assign, manage contacts, manage deliverables (including attached files), view related emails, create an event, track the timeline, manage commercial proposals.\u003C\u002Fli>\n  \u003Cli>Per proposal: decision endpoint (accept \u002F reject).\u003C\u002Fli>\n  \u003Cli>Work start action: transitions the negotiation into an operational project.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2 id=\"fleet\">Fleet Module\u003C\u002Fh2>\n\n\u003Cp>The fleet module is a \u003Cstrong>server-only\u003C\u002Fstrong> component with no dedicated Hub interface at this time. It exposes a data schema intended to be consumed by a future dedicated interface.\u003C\u002Fp>\n\n\u003Cp>The fleet registry data model includes, for each client instance: identifier, name, domain, subscribed plan, MRR, setup fee, status, VPS region, administration URL, configured AI provider, and configured AI model.\u003C\u002Fp>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Warning:\u003C\u002Fstrong> this registry contains legacy columns intended to store secrets (administration passwords, API keys). This schema is inherited from the PaaS era and is \u003Cstrong>inconsistent with the zero-secret-in-business-database doctrine\u003C\u002Fstrong>. It is pending audit and must not be considered the canonical source of operational secrets.\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\n\u003Cp>The operational source of truth for client VPS management remains the main VPS registry. The exact relationship between that registry and the fleet model is to be confirmed. Operational tenant management is performed primarily through the site and client administration consoles.\u003C\u002Fp>\n\n\u003Ch2 id=\"reacteur\">Orbital View — Reactor\u003C\u002Fh2>\n\n\u003Cp>The \u003Cstrong>Reactor\u003C\u002Fstrong> view is a live orbital representation of agent activity. It is organized into three concentric rings according to each agent's role:\u003C\u002Fp>\n\n\u003Cul>\n  \u003Cli>\u003Cstrong>Ring 1 (center)\u003C\u002Fstrong>: director agents.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Ring 2\u003C\u002Fstrong>: scoping and execution agents.\u003C\u002Fli>\n  \u003Cli>\u003Cstrong>Ring 3 (periphery)\u003C\u002Fstrong>: validation agents.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>An octopus logo occupies the center. The view is fed in real time via SSE. It is rendered client-side only (no server-side rendering). It is adapted from the public marketing page of the reactor.\u003C\u002Fp>\n\n\u003Ch2 id=\"points-entree-developpeur\">Entry Points for Extending the Hub\u003C\u002Fh2>\n\n\u003Ctable>\n  \u003Cthead>\n    \u003Ctr>\n      \u003Cth>Objective\u003C\u002Fth>\n      \u003Cth>Mechanism\u003C\u002Fth>\n    \u003C\u002Ftr>\n  \u003C\u002Fthead>\n  \u003Ctbody>\n    \u003Ctr>\n      \u003Ctd>Add an entry to the sidebar\u003C\u002Ftd>\n      \u003Ctd>Modify the navigation sections array in the main Hub layout.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Add a \u003Ccode>\u002Fhub\u002FX\u003C\u002Fcode> page\u003C\u002Ftd>\n      \u003Ctd>Create the page in the relevant module and declare the \u003Ccode>hub\u003C\u002Fcode> layout in the page metadata.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Add a cockpit endpoint\u003C\u002Ftd>\n      \u003Ctd>Create the endpoint in the relevant module's API folder and apply the employee session verification middleware to it.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Understand authentication\u003C\u002Ftd>\n      \u003Ctd>Consult the session utilities and the auto-session middleware, which handle HMAC signing of Hub session cookies.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Plug in a new module\u003C\u002Ftd>\n      \u003Ctd>Declare the module in the Nuxt extension configuration and provide a manifest and local configuration for the module.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Work on runs and projects (database)\u003C\u002Ftd>\n      \u003Ctd>Use the Python business entities from the repository and the corresponding tables: Atlas runs, projects, work units, tasks, negotiations — all in the mothership schema.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Consult the maintenance and documentation drift dashboard\u003C\u002Ftd>\n      \u003Ctd>Use the Hub maintenance view and its associated endpoint, which rely on the documentation health and detected drift tables.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>External documentation review\u003C\u002Ftd>\n      \u003Ctd>Use the external review panel component and its dedicated endpoints, backed by the external reviews table.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Reflex and hook registry\u003C\u002Ftd>\n      \u003Ctd>Consult the Hub hooks view and its listing endpoint, which exposes the reflex registry organized by level (trunk \u002F arms).\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Project lock (CLI concurrency)\u003C\u002Ftd>\n      \u003Ctd>Use the distributed locking entity: operations \u003Ccode>try_acquire\u003C\u002Fcode>, \u003Ccode>force_claim\u003C\u002Fcode>, \u003Ccode>release\u003C\u002Fcode>, \u003Ccode>heartbeat\u003C\u002Fcode>.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Automatic discovery invocation audit\u003C\u002Ftd>\n      \u003Ctd>Consult the audit entity: methods for retrieving recent invocations and counting over a 24-hour window.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n    \u003Ctr>\n      \u003Ctd>Task dependencies (DAG)\u003C\u002Ftd>\n      \u003Ctd>Use the dependency entity: operations \u003Ccode>add_dep\u003C\u002Fcode>, \u003Ccode>remove_dep\u003C\u002Fcode>, \u003Ccode>list_deps_for_travail\u003C\u002Fcode> with DFS cycle detection.\u003C\u002Ftd>\n    \u003C\u002Ftr>\n  \u003C\u002Ftbody>\n\u003C\u002Ftable>\n\n\u003Cblockquote>\n  \u003Cp>\u003Cstrong>Secret management:\u003C\u002Fstrong> no secret is stored in plaintext in the codebase. The Hub session cookie signing key is consumed via HMAC by the session cryptographic layer; its environment variable resides in environment files excluded from the repository, in accordance with the secrets doctrine.\u003C\u002Fp>\n\u003C\u002Fblockquote>",{"slug":14,"chapterNum":15,"title":16,"titleEn":17},"automates","05","Automates, crons & runs","Automations, crons & runs",{"slug":19,"chapterNum":20,"title":21,"titleEn":22},"email","07","Inbox hub & Atlas Inbox — deux pipelines email","Inbox hub & Atlas Inbox — two email pipelines",{"chapters":24},[25,32,39,46,53,56,57,60,67,74,81],{"slug":26,"chapterNum":27,"title":28,"titleEn":29,"summary":30,"summaryEn":31},"overview","01","Vue d'ensemble du harness agentique","Agentic harness overview","Le harness transforme une demande (courriel, console, cron) en action déployée en enchaînant classification, spawn LLM via pseudo-TTY, validation qualité à deux niveaux et boucle d'apprentissage, le tout sans état métier hors base de données.","The harness transforms a request (email, console, cron) into a deployed action by chaining intent classification, pseudo-TTY LLM spawn, two-level quality validation, and a learning loop — with no business state stored outside the database.",{"slug":33,"chapterNum":34,"title":35,"titleEn":36,"summary":37,"summaryEn":38},"data-layer","02","La couche données","The Data Layer","Décrit l'architecture données de Synedre OS : une base PostgreSQL unique (un composant interne\u002Fun composant interne), les trois chemins d'accès (Nuxt\u002FNitro, Python agentique, Drizzle ORM DDL), les familles de tables par préfixe et les conventions de nommage associées.","Describes the Synedre OS data architecture: a single PostgreSQL database (un composant interne\u002Fun composant interne), the three access paths (Nuxt\u002FNitro, agentic Python, Drizzle ORM DDL), the table families by prefix, and the associated naming conventions.",{"slug":40,"chapterNum":41,"title":42,"titleEn":43,"summary":44,"summaryEn":45},"agentic-core","03","Le cœur agentique : Atlas et les agents","The Agentic Core: Atlas and the Agents","Décrit l'architecture du moteur agentique : classification LLM des emails entrants, spawn headless de Claude Code via pseudo-TTY, injection des personas agents et orchestration post-spawn (deploy, QA, récap).","Describes the architecture of the agentic engine: LLM classification of incoming emails, headless spawning of Claude Code via pseudo-TTY, injection of agent personas, and post-spawn orchestration (deploy, QA, recap).",{"slug":47,"chapterNum":48,"title":49,"titleEn":50,"summary":51,"summaryEn":52},"chantiers","04","Chantiers, travaux & tâches — modèle de données et API","Worksites, Jobs & Tasks — Data Model and API","Décrit la hiérarchie chantier\u002Ftravail\u002Ftâche de Synedre OS, le modèle de données DB, les statuts\u002Fscopes canoniques et l'API Python associée.","Describes the worksite\u002Fjob\u002Ftask hierarchy in Synedre OS, the DB data model, canonical statuses\u002Fscopes, and the associated Python API.",{"slug":14,"chapterNum":15,"title":16,"titleEn":17,"summary":54,"summaryEn":55},"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":5,"chapterNum":6,"title":7,"titleEn":8,"summary":9,"summaryEn":10},{"slug":19,"chapterNum":20,"title":21,"titleEn":22,"summary":58,"summaryEn":59},"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."]