Chapitres

Sur cette page

DOC-04 / Référence technique · Chapitre 06

Le Hub : cockpit d'administration du harness

Architecture du cockpit privé du harness Synedre : couches Nuxt, navigation, familles d'endpoints, authentification, consoles et gardes de livraison des secrets.

À quoi ça sert : le Hub est l'interface d'administration privée du harness agentique Synedre OS. Ce périmètre est celui de la plateforme d'orchestration (une base unique, centralisée) : Synedre orchestre CodeMyShop, il n'est pas le produit CodeMyShop (multi-tenant) lui-même. Le Hub est une application Nuxt autonome, servie sur la boucle locale du serveur d'orchestration et atteignable uniquement par tunnel SSH derrière une porte d'accès au niveau du reverse-proxy ; le fondateur y pilote agents, chantiers, runs, négociations, mémoire et infrastructure.

1. L'application Nuxt du Hub

1.1 Localisation et nature

L'application est autonome : elle n'étend pas le cœur CodeMyShop (« autonomie totale ») et ne charge ni module d'internationalisation ni module de thème clair/sombre (FR seul, thème sombre seul). Les modules Nuxt réellement chargés sont quatre : Tailwind, gestion d'images, polices et icônes.
Elle est privée : elle écoute sur la boucle locale du serveur d'orchestration. Ce n'est pas le site vitrine du fondateur, qui est un tenant séparé sur un autre serveur.
Le cockpit est sombre uniquement : le sélecteur clair/sombre a été retiré (décision de mai 2026) ; le layout force la classe dark sur la racine du document au montage et la retire au démontage.
Sélecteur d'interface : le layout unique sert deux interfaces logiques — le cockpit du harness (actif) et une interface « foyer » qui n'est pour l'instant qu'une coquille vide (« à venir »). Le choix est mémorisé côté navigateur et le titre de page suit l'interface active. L'interface foyer n'a aucune page dédiée : c'est un mécanisme de bascule posé en avance des agents domestiques (repas, budget, animaux). Le même menu porte une entrée « mode démo », grisée tant que l'URL de la démonstration n'est pas renseignée (§1.3).
Pas de scheduler en démo : si le build est produit en mode démo, la liste des tâches planifiées Nitro est vide — la pile de démonstration n'enregistre aucune tâche, ne fait aucun appel réseau et n'écrit pas dans ses données d'exemple.

1.2 Architecture en couches (modules = Nuxt layers)

Le Hub n'est pas un monolithe : les fonctionnalités sont éclatées en modules chargés comme Nuxt layers (clé extends), pas comme modules Nuxt.

Cicatrice d'une phase de migration (mai 2026) : ces dossiers portent un manifeste et une configuration vide, c'est le motif d'un layer. Déclarés comme modules Nuxt, ils échouent au chargement (« Could not load module »).

Chaque layer auto-découvre ses pages, ses endpoints serveur et ses middlewares serveur via Nitro. Un module peut donc apporter :

des pages du cockpit,
des endpoints serveur répartis en trois familles : cockpit, back-office et voix,
du code serveur (accès base, utilitaires).

application Nuxt
├── configuration         extends : un layer par module   (32 layers)
├── layout unique         2 interfaces (cockpit / foyer), tiroir mobile
├── middleware de page    pass-through (contrôle d'accès en amont)
├── serveur/
│   ├── amorçage          polyfill Nitro : secrets lus au lancement
│   ├── middleware        session injectée côté plateforme
│   ├── utilitaires       garde de session (employé / fondateur / rôle)
│   └── api/              endpoints CORE (non portés en module)
├── pages cockpit         17 pages CORE (redirection d'entrée, SRE, coûts, maintenance, finances, playbooks, téléphonie…)
└── modules/
    ├── agents-ui      (60 pages cockpit + une vitrine publique)   pages, zéro serveur
    ├── agents-engine  (233 endpoints cockpit)                     serveur, zéro page
    ├── chantier       (cockpits, fiche chantier, console CLI)
    ├── acquisition / agenda / social
    ├── drill / cicatrices / conduite / automates / backlog / monitoring …
    ├── atelier3d      (2 pages + serveur dédié)
    ├── studio-video   (2 pages de montage)
    └── fleet / invoicing / reunions / academy …   (serveur seul, zéro page)

Les 32 layers étendus sont : academy, acquisition, aetracker, agenda, agents-engine, agents-ui, atelier3d, autoblog-article, automates, backlog, centaure, chantier, cicatrices, clientconfig, conduite, daily-meet, drill, employeeextra, expertise, feedback, fleet, hub, impersonation, incidents, invoicing, monitoring, page-meta, reunions, snake, social, studio-video, tools — soit les 32 dossiers de modules.

Limite connue : le commentaire de configuration annonce encore « 28 modules internes » alors que la liste en code en déclare 32 (acquisition, agenda et social se sont ajoutés). Le commentaire est périmé, la liste fait foi — même schéma de dérive que dans les passages précédents.

Historique : l'ancien module « agents » a été scindé (septembre 2026) en une couche d'interface (pages, zéro serveur) et une couche moteur (serveur, zéro page). L'interface foyer n'existe plus comme layer : c'est un mode d'affichage du layout. Les couches atelier 3D et studio vidéo portent des pages du cockpit depuis leur création.

1.3 Configuration runtime et build

Secrets lus au LANCEMENT, jamais au build (chantier de sécurité de l'automne 2026) : tous les secrets de la configuration runtime (secret de signature, clé de chiffrement d'API, clés des fournisseurs d'IA, chaîne de connexion à la base, clés d'objet-stockage) valent la chaîne vide au build. Une valeur lue à ce moment partirait en clair dans la sortie compilée et, pour la partie publique, dans le bundle navigateur. Ils sont fournis par l'environnement du conteneur, sous un nom canonique ou sous leur nom historique recopié au démarrage par un pont dédié ; un test échoue si une clé manque à la table d'alias. Nitro figeant sa configuration à l'import, le pont est branché comme polyfill de démarrage. Seuls des noms de variables circulent dans le code.
Configuration runtime publique : URL de base de l'API, URL de l'instance hub de démonstration isolée (vide par défaut), URL du pont Blender live de l'atelier 3D (§6.7), identifiant de client par défaut. Le jeton d'administration de l'onglet des clés d'API n'est plus en configuration publique : il est lu à l'exécution par le serveur et ne voyage que dans un cookie httpOnly.
Polices : le module de polices est désarmé — une seule police (une chasse fixe, pour la maille du réacteur) est auto-hébergée, avec tous les fournisseurs distants désactivés. Cause racine : le cache de build archivait en tar un nom de police de plus de 100 octets, tronqué sans erreur, d'où une police de 0 octet servie pendant environ cinq jours. Le cache de build est rallumé depuis, et le deploy du cockpit embarque une garde de polices, testée.
Gardes de livraison côté deploy — le principe « secrets au lancement » est adossé à trois gardes de la chaîne de déploiement, valables pour le hub comme pour les tenants :
- une garde de sortie scanne le répertoire compilé (partie serveur et partie publique) avec les fichiers d'environnement sources lus en mémoire ; une valeur de secret retrouvée dans le bundle fait échouer la livraison. Elle est pilotable (coupée, avertissement seul, ou bloquante) ; elle est bloquante par défaut depuis le 10 octobre 2026, après preuve qu'aucun secret n'est figé dans le cœur de démonstration ni dans le hub. Une erreur de configuration de la garde elle-même n'est jamais bloquante ;
- une garde « trou de secrets » refuse le déploiement d'un tenant dont des secrets ne vivaient que dans son build (son serveur ne les fournit pas au lancement : un nouveau build les perdrait). Une dérogation consciente existe ; le hub ne figure pas dans la liste ;
- le rechargement PM2 relit le fichier d'écosystème : celui-ci lit l'environnement à son chargement, donc le deploy recharge par le fichier (sans coupure en mode cluster) et redémarre à froid si le fichier a changé depuis le dernier déploiement (empreinte mémorisée). Une clé ajoutée à l'environnement est ainsi vue sans redémarrage manuel ;
- une garde de polices vérifie, avant l'empaquetage, qu'aucune police n'est vide ou manquante.
Scheduler Nitro : tâches expérimentales Nitro activées + liste de tâches planifiées (§3.1).

2. La carte des modules du cockpit

Extension de septembre 2026 — portabilité du harness. Une page authentifiée, rangée dans la zone avancée « agentique » sous le libellé « Portabilité », compose une sélection bornée de profils et de skills. Elle ne lit pas leur contenu depuis le navigateur : un endpoint relaie au daemon hôte, qui relit le registre des skills et construit le paquet canonique (schéma versionné, activation manuelle après validation, intégrité par empreinte SHA-256). L'interface se limite à prévisualiser puis télécharger ; aucun geste d'installation ou d'activation n'est exposé.

2.1 Où vivent les pages

17 pages CORE : une redirection d'entrée, SRE, coûts, téléphonie, apprentissage agentique, liste des chantiers, trois pages de finances, deux pages de playbooks, cinq pages de la famille « mothership » (anatomie, sauvegardes, maintenance, coût-budget, délibération) et une page système. La racine du cockpit n'est pas une vraie page : c'est une redirection 302 vers le terminal.
- Finances (3 pages) : une vue consolidée professionnelle ↔ foyer, une vue auto-entreprise, une vue foyer. La sidebar pointe sur la vue consolidée (libellé « Finances »).
- Cadran de maintenance — deux onglets :
  - Onglet 1 « Tableau de bord » : jauge globale, 4 dimensions (proprioception, dette, apprentissage, automates), sparkline sur 7 jours, tableau de dérive de la documentation (types de dérive : référence morte, publié périmé, code plus récent, non publié). Il lit deux tables : l'historique de santé de la boucle nocturne et le miroir de dérive documentaire.
  - Onglet 2 « Le regard des autres » : l'utilisateur choisit un chapitre de documentation publique, génère un prompt assaini, le soumet à une IA externe puis colle la réponse dans le formulaire (plafond de 50 000 caractères, statut « soumis »). L'historique est consultable. Une table dédiée porte ces revues. Les chapitres éligibles sont au nombre de 11 : overview, data-layer, agentic-core, chantiers, automates, hub, email, memory, deploy, facades, skills-hooks.
- Les pages d'anatomie et de délibération (libellés de sidebar dédiés) lisent chacune un endpoint back-office ; la page de téléphonie lit une liste et un détail.
- La vue détail des coûts par chantier et du budget annuel (onglet budget de la page de coûts) n'est pas exposée directement dans la sidebar.
60 pages du cockpit portées par le module d'interface (pages seules, zéro serveur), contre 49 en septembre 2026 (+11), plus une page publique hors cockpit : la vitrine orbitale des agents. Répartition :

Famille	Pages
Cœur agents / chantier	liste et fiche agent ; chantier (liste, fiche, kanban par travail, fiche travail) ; tâches (création, fiche) ; dispatch ; réacteur
Pilotage / doctrine	constitution, doctrine, emails, boîte de réception, juridique, questions, réglages, modèle utilisateur
Skills & runs	skills et propositions de skills ; runs (liste, fiche, run Atlas) ; sessions ; hooks
Négociations / conseil	négociations (liste, fiche) ; conseil (liste, fiche)
Mémoire	mémoire (index, arborescence, recherche)
Humains / clients	humains (liste, fiche, vue mesh) et fiche client ; la fiche technique affiche l'accès et le raccourci vers le cockpit in-situ des sites de démonstration ; nouveau : vue mesh des sites d'un client (3 pôles notés sur 10 — SEO, performance, sécurité — rattachés aux objectifs), file de revue LinkedIn (lecture seule), file de revue d'enrichissement de contacts (rien n'est appliqué depuis la liste)
Pilotage étendu	autonomie, objectifs, optimisations, WhatsApp, Bucéphale, cinémathèque, brainstorm (liste, fiche), playbooks de runbooks, terminal
Nouveau — flotte & mise en ligne	cockpit des tentacules et ventouses (profil, session, tenant, objectif, bureau, slot, worktree, modèle, santé git) ; page de mise en ligne (un bouton inscrit un deploy du serveur d'orchestration en base, repris par le worker de deploy hôte — la page survit au rebuild qu'elle déclenche) ; campagnes de recette fonctionnelle (génériques, aucun tenant en dur) ; cockpit expérimental d'un runtime Codex (événements structurés, sans pseudo-terminal) ; portabilité du harness (cf. extension ci-dessus)

Un runbook statique : un tutoriel de sculpture 3D tiers archivé, retranscrit page à page en français avec, pour chaque geste, la commande de l'API de cage de l'atelier 3D qui le réalise (42 étapes). Contenu documentaire figé, sans lecture en base.
La route de fiche de run reçoit un identifiant et non plus un codename.
Les fiches humaines et les fiches clients coexistent ; leur relation exacte : ⚠️ à confirmer.
233 endpoints cockpit dans le module moteur (serveur seul, zéro page ; 262 fichiers dont 20 specs/tests et 10 helpers), contre 230 le 10 octobre 2026 et 187 en septembre. Sous-domaines : atlas, autonomie, brainstorm, bucéphale, chantier, cinéma, clients, conseil, doctrine, fleet-control, hooks, humains, jukebox, mémoire, négociations, objectifs, optimisations, questions, recettes, runs, sessions, réglages, audits de sites, sites, skills, console CLI, tâches, modèle utilisateur — plus quelques fichiers non regroupés. La famille « console CLI » reste la plus étoffée (81 fichiers, §6.3).
4 endpoints CORE cockpit : un profil d'agent pour une tâche et trois endpoints de commandes éphémères (liste, rejet, exécution — pied de page du layout).
Total des endpoints cockpit : 257 (233 moteur + 15 chantier + 1 conduite + 4 monitoring + 4 CORE), hors specs et helpers, contre 254 le 10 octobre et 208 en septembre.
Modules sans page (serveur seul) : academy, aetracker, agents-engine, autoblog-article, centaure, clientconfig, daily-meet, employeeextra, feedback, fleet, hub, impersonation, incidents, invoicing, page-meta, reunions, snake, tools. Leur surface est consommée par API par d'autres pages ou par les automates Python.
- Le module hub expose des endpoints de statistiques, de constitution/charte et d'avatar, sans page du cockpit.

Modules avec pages du cockpit restants (hors module d'interface) :

Module	Pages
`backlog`	2 : backlog, planning
`chantier`	2 : fiche chantier, cockpits
`drill`	2 : index et fiche par agent
`cicatrices`	1 : index
`conduite`	1 : index des conduites
`automates`	1 : automates (Tools)
`monitoring`	2 : sentinelle SEO, rank-tracker de mots-clés (ajout et suppression de mots-clés, lecture)
`atelier3d`	2 : liste des projets, cockpit projet — sculpture 3D (§6.7)
`studio-video`	2 : montage (liste, projet) — studio cinéma multi-pistes
`acquisition`	1 : tableau de bord du bras 4 (développement commercial), lecture seule : pool, canaux (démarchage sous délégation, plateforme freelance, marchés publics, négociations), entonnoir, file des envois programmés ; un palier non relevé s'affiche « non relevé », jamais 0
`social`	2 : diffusion (tableau par canal, cadence, file des posts), retouche d'un short fini (notes par plan, rien n'entre en file)
`agenda`	1 page cockpit (rendez-vous souverains : demandes, créneaux, configuration) + 1 page publique de prise de rendez-vous ; 5 endpoints back-office de rendez-vous

Note : le module drill expose aussi 4 pages publiques hors cockpit (index, historique, cicatrices, épreuve par identifiant) : c'est la surface publique du Drill sur le site Synedre. Elles ne sont pas comptées dans les pages du cockpit ci-dessus.

Note : le module expertise apporte des pages publiques/SEO (index, catégories PrestaShop, fiches), pas des pages du cockpit — inchangé.

La sidebar du cockpit est définie en dur dans le layout. Modèle en 2 niveaux : des liens autonomes et 4 zones toujours visibles, puis 7 zones repliées derrière un bouton « Avancé » (réorganisations de juillet 2026, puis d'octobre 2026 : « regrouper acquisition et diffusion », « replier les accès d'administration »).

Limite connue : le commentaire d'en-tête du layout est partiellement périmé — il liste une zone « EXÉCUTION » à 4 entrées alors que la zone réelle en porte 7 (objectif en tête, recette et montage ajoutés), et « PILOTAGE » omet l'agenda. Sans impact fonctionnel : le tableau en code fait foi.

Liens autonomes (hors zones) : Terminal · Humans · Bucéphale. (Le lien « Founder DNA » a quitté les liens autonomes pour la zone ADMINISTRATION.)
Zones toujours visibles :

Zone	Entrées
ACQUISITION & DIFFUSION	Acquisition · Diffusion
PILOTAGE	Backlog · Agenda · Emails · WhatsApp · Téléphonie · Brainstorm
BUSINESS	Finances · Questions · Négociations · Conseil · Juridique
EXÉCUTION	Objectif · Autonomie · Runs · Chantier · Recette · A.W Factory (atelier 3D) · Montage

Zones repliées (ouvertes par défaut si la page active y vit, sinon derrière le bouton « Avancé » dont l'état est mémorisé côté navigateur) :

Zone	Entrées
DOCTRINE & APPRENTISSAGE	Doctrine · Runbooks (statique) · Playbooks conversationnels (base de données) · Cicatrices
AGENTIQUE	Agents · Skills · Portabilité · Tools (automates) · Hooks & Réflexes
MÉMOIRE	Brain · Recall RAG
ADMINISTRATION	Fleet Control · Mise en ligne · Founder DNA
SYSTÈME	SRE · cadran de maintenance · anatomie · délibération · Coût API · Backups S3 · Clés API · Optimisations · Apprentissage agentique
SEO	Rank-tracker · Sentinelle
MAISON	Cinémathèque — la page existait avant d'être atteignable par la navigation.

Plusieurs pages existent en code mais n'apparaissent dans aucune zone : dispatch, réacteur, cockpits, planning, vue mesh des sites, retouche de short, runtime Codex et Drill — elles s'atteignent par adresse directe ou depuis une autre page. Le lien « Hub e-commerce » (retiré en juillet 2026) reste absent.
Le libellé « Terminal » pointe vers une page réduite au seul terminal tmux (ancienne page « synedre », réduite en juillet 2026). La racine du cockpit n'est pas une landing distincte : c'est une redirection 302 vers le terminal.
L'entrée active est marquée sur correspondance exacte OU sur sous-route.
La sidebar reste en emoji volontairement (décision de juillet 2026) : c'est le seul endroit du cockpit qui n'a pas migré vers les icônes Tabler — liste finie, centralisée, chaque pictogramme doublé d'un libellé texte.
Mobile — tiroir (septembre 2026) : sous le palier md, la sidebar sort du flux et devient un tiroir rappelé par un bouton ☰ dans une barre de 40 px ; voile sombre, fermeture sur navigation ou sur Échap ; libellés rétablis dans le tiroir. Variante « écran court » (p. ex. paysage mobile) : racine à hauteur dynamique sans défilement parasite, chaque colonne défile chez elle ; la barre mobile affiche le titre de la navigation active, calculé (le lien le plus spécifique l'emporte).

3. Les familles d'endpoints serveur

Le découpage n'est pas qu'organisationnel : il porte une sémantique de droits.

back-office   "fondateur / cron" — derrière la porte d'accès, parfois SANS auth applicative
cockpit       surface employé — garde de session employé quasi-systématique
voix          transcription audio — garde de session employé + garde CSRF

S'y ajoutent quelques dossiers CORE plus petits : les clés d'API (liste, mise à jour, jeton d'administration en cookie httpOnly), un relais de médias WhatsApp, un callback OAuth de page, ainsi qu'un endpoint de santé et les endpoints WhatsApp.

3.1 Back-office

Endpoints CORE : 46 fichiers hors specs (contre 44). Sous-domaines : apprentissage (3), chantier (4), cicatrices (1), coûts (8), boîte de réception (7), famille « mothership » (10), playbooks (2), SRE (2), téléphonie (2), tenants (1), WhatsApp (6).
Endpoints en module (18) : automates (3), conduite (3), agenda (5), finances aetracker (7). Total back-office : 64.
La route historique de synchronisation de la boîte de réception est une sentinelle : elle répond 410 Gone sans exécuter la tâche IMAP. Le déclenchement manuel passe par un script dédié qui lance le worker externe de synchronisation. Statut des tâches Nitro : 9 déclarées, dont 2 désactivées en commentaire (synchronisation de la boîte et des emails clients — des timeouts IMAP du fournisseur bloquaient l'event loop) et 7 actives : traitement de la file d'emails (toutes les 2 min), surveillance d'uptime (15 min), veille du dictionnaire (30 min), audit des dépendances (2 h quotidien), daily meet (8 h), veille des certificats SSL (9 h), veille de marque (12 h). Liste vide en mode démo (§1.1).
Exemples par sous-domaine (échantillon, non exhaustif) :
- apprentissage : mise à jour, application, flux
- chantier : ré-éclatement, édition d'éclatement, statut d'éclatement, lancement de phase
- cicatrices : indicateurs
- coûts : tableau de bord, budget (lecture/écriture), coûts par chantier, équivalent API par chantier, automates, tâches, séries temporelles
- boîte de réception : synchronisation (410), liste, détail, mise à jour, pièces jointes, rattachement à un chantier
- famille « mothership » : anatomie, délibération, sauvegardes (liste, téléchargement), tableau de maintenance (santé + dérive documentaire) ; sous-chemin de revue externe : chapitres, prompt, historique, soumission
- SRE : métriques, déclenchement de tâche
- WhatsApp : liste, détail, mise à jour, réponse, statut d'envoi, médias
- playbooks : liste, détail ; téléphonie : liste, détail
- tenants : statut d'autorisation de mise en ligne automatique

3.2 Surface cockpit

257 endpoints au total (§2.1) — +49 depuis septembre 2026, portés par le module moteur (233, contre 187).
Authentification : la garde de session employé est appelée dans 316 fichiers du code de l'application (hors specs/tests ; mesuré par grep, contre 313 la veille, 234 en septembre et 144 en juin 2026). Les exceptions sont des helpers internes (client du daemon, tuyau de pane, profondeur, surcharge, politique de heartbeat) ou des flux SSE. Motif type, en tête de chaque handler :
```
export default defineEventHandler(async (event) => {
  requireEmployeeSession(event)
  ...
```
Familles principales (module moteur) : chantier (32), runs (10), négociations (17), conseil (9), clients (9), humains (9), brainstorm (14), jukebox (14), fleet-control (11), mémoire, doctrine, skills, sessions, questions, tâches, modèle utilisateur, réglages, console CLI (61 endpoints / 81 fichiers), hooks, atlas, autonomie, bucéphale, cinéma, objectifs, optimisations, recettes, sites, audits de sites.
Le module chantier ajoute ses propres 15 endpoints : cockpits actifs, sessions actives, tableau de bord, runs actifs et bugs découverts par chantier, la console CLI live (démarrage, arrêt, reset, état) avec flux SSE d'événements d'agents, et pour les runs Atlas : brouillon de réponse, lancement d'un correctif, profil et flux SSE. Le brouillon de réponse existe en lecture ET en écriture.
Les négociations (module moteur) comptent 17 fichiers : liste, archivage, reclassement, détail, et par négociation : événement, statut, chronologie, emails, contacts, livrable (fichier), propositions, événements, contact, démarrage du travail, assignation, livrables, plus la décision sur une proposition.

3.3 Transcription audio

Un seul endpoint — inchangé.
Contrat : requête POST multipart (audio WAV obligatoire, locale optionnelle — français par défaut) → texte, locale, durée, modèle, backend. Il délègue à un service de transcription.
Garde-fous : garde de session employé, 5 Mo maximum, limitation à 100 transcriptions par fenêtre de 5 minutes et par session, audio jamais persisté sur disque (mémoire vive seule), et défense CSRF par vérification Origin/Referer face à l'hôte.

4. Authentification

4.1 Le modèle en deux couches

┌──────────────────────────────────────────────────────────┐
│  COUCHE INFRA (la vraie porte)                            │
│  Tunnel SSH (boucle locale) + porte d'accès du proxy      │
└─────────────────────────────┬────────────────────────────┘
                              │  la requête arrive déjà « propriétaire seul »
┌─────────────────────────────▼────────────────────────────┐
│  COUCHE APPLICATIVE (Nuxt)                                │
│  middleware serveur de session : fournit une session      │
│  signée à la plateforme                                   │
│  → la garde de session voit toujours un employé valide    │
└──────────────────────────────────────────────────────────┘

4.2 Garde de session employé et assimilées

Inchangé (fichier ré-audité, dernier changement en mai 2026) :

La lecture de session décode le cookie de session (JSON base64url signé HMAC-SHA256, vérification par un module de cryptographie dédié). Elle renvoie null si le cookie est absent ou invalide.
La garde employé renvoie la session si le type d'utilisateur est « employé », sinon répond 401. C'est la garde standard des endpoints cockpit et voix (316 fichiers, cf. §3.2).
La garde fondateur exige en plus le statut de super-administrateur SaaS (403 sinon).
La garde « rôle ou SaaS » exige un rôle donné OU le statut de super-administrateur SaaS.
Le statut de super-administrateur repose sur une liste blanche statique en code, volontairement hors base : « toucher cette liste = changement de code + revue ».

Forme de la session : identifiant d'employé, email, prénom, nom, rôle, identifiant de profil, identifiant de client, type d'utilisateur, indicateur d'administration.

4.3 La session fournie par la plateforme

Le middleware serveur de session est inchangé : à chaque requête dépourvue de cookie de session valide, il signe un jeton (mis en cache) et pose un cookie httpOnly de 30 jours dont la charge utile est une session de profil administrateur. Conséquence : sur le runtime du serveur d'orchestration, la garde de session passe toujours — la sécurité réelle est l'infrastructure (tunnel SSH + porte d'accès). Ce middleware est scopé au serveur d'orchestration : il n'existe ni dans le cœur CodeMyShop ni dans les tenants ; sur les tenants publics, la garde de session reste obligatoire (cicatrice d'une phase antérieure : une porte d'accès n'est pas un substitut d'authentification).

4.4 Le middleware de page est un pass-through

Le middleware de page du Hub est un pass-through — inchangé. Il a été désactivé lors d'une phase de correction (mai 2026) car la porte d'accès du proxy et le tunnel SSH assurent le contrôle en amont. Il reste exporté car 71 pages le référencent dans leur métadonnée (contre 57 en septembre et 45 en juin 2026 — croissance proportionnelle au nombre de pages du cockpit).

Limite connue : le commentaire du middleware annonce encore « 16 pages » — périmé. Le pass-through étant volontaire, la divergence n'a pas d'impact fonctionnel ; le commentaire devra être mis à jour au prochain passage.

La porte d'accès du reverse-proxy (cookie + segment d'URL) vit côté infrastructure, pas dans cette application Nuxt. Le runbook d'infrastructure la documente. ⚠️ Le détail de sa configuration n'est pas dans le code de l'application — à confirmer côté infrastructure.

5. Layout du Hub

Layout unique, seul layout du cockpit de l'application autonome, partagé par les 2 interfaces (§1.1). Il n'override rien : l'application étant autonome (pas d'extension du cœur CodeMyShop), il n'existe aucun layout parent à surcharger.
- Limite connue : deux commentaires du fichier (« override du layout du cœur » et le mécanisme d'extension de layers) sont toujours obsolètes — vestiges d'avant la bascule en application autonome, non corrigés. Les tableaux de navigation font foi sur le commentaire d'en-tête (§2.2).
L'utilisateur du layout est une valeur fixe : l'authentification Nuxt a été retirée. Inchangé.
L'en-tête de page : titre réactif au sélecteur d'interface (« … — Synedre OS » ou nom de l'interface foyer) et favicon dédié.
Le pied de page du layout monte un composant de commandes éphémères à lancer (liste, rejet, exécution).
Les pages déclarent le layout du cockpit, le middleware pass-through et un rendu ssr: false (90 pages référencent le layout du cockpit, contre 74 en septembre). Le rendu client seul est fréquent sur les pages temps réel (réacteur, chantier).

6. Les surfaces console (runs · chantiers · négociations · fleet)

Le Hub matérialise plusieurs « consoles » de pilotage des agents. Modèle de données central : les entités Python de la couche entités et les tables PostgreSQL d'un schéma unique de la base centrale du harness.

6.1 Runs

Pages : liste des runs, fiche d'un run, fiche d'un run Atlas.
API : le dossier runs du module moteur (10 fichiers : liste, périmètres, périmètre, chat scopé, job) et, côté module chantier, les endpoints de run Atlas (brouillon de réponse, lancement de correctif, profil, flux SSE).
Modèle : entité sy_run. Un run est une exécution scopée d'Atlas (chat/email/cron) sur un périmètre « plateforme » ou « tenant ». Réponse de la liste : identifiant, source, déclencheur, périmètre, titre, statut, type et identifiant de référence, date d'ajout, date de fin. La source « atlas-inbox » est un email, « console » est un chat. Les emails d'intention question/chantier/bruit ne sont pas matérialisés en run (ils restent sur les pages de questions et de chantiers). Un run de tâche n'est pas un run.

6.2 Chantiers

Pages : liste, fiche, kanban par travail, fiche travail (module d'interface) ; fiche chantier et cockpits (module chantier) ; liste des chantiers CORE.
API (module chantier, 15 endpoints cockpit au total — §3.2) : cockpits actifs, sessions actives, tableau de bord, runs actifs et bugs découverts par chantier, la console CLI live (démarrage, arrêt, reset, état) avec flux SSE d'événements d'agents, et les endpoints de run Atlas (§6.1).
API (module moteur, 32 fichiers sous chantier) : par chantier (rédaction de la lettre de mission, run automatique, archivage, clôture avec brouillon d'email, passage en brainstorm, mise à jour, livrables), tâches/équipe/travail/contexte, audit de pertinence, mode de facturation, tenants, travaux (⚠️ contenu des sous-dossiers non ré-audité fichier par fichier).
Modèle : 1 chantier → N travaux → N tâches (entités chantier, travail, tâche). Tables réelles : chantier = ps_ac_chantier, travail = ps_ac_chantier_travail, tâches = sy_chantier_tache, liens sy_chantier_agent / sy_travail_agent. Création canonique = création avec squelette, atomique (procédure en 7 étapes).
- Limite connue : dette de nommage entre le préfixe historique ps_ac_* et sy_* (migration progressive) : le chantier et le travail restent ps_ac_*, alors que les tâches et les tables de liens sont déjà en sy_*. Il n'existe ni table ni vue sy_chantier ou sy_travail.
Entités de contrôle de concurrence et d'audit :

Entité	Table	Rôle
Lock chantier	`sy_chantier_lock`	Lock distribué par chantier — refuse 2 sessions sur le même chantier ; clé composite (chantier, type de propriétaire : session utilisateur ou worker spawné) ; TTL de 30 min + heartbeat ; mode de compatibilité (table absente → verrou acquis). Opérations : acquisition, libération, prise de force, heartbeat.
Erreur de lock	— (exception)	Levée à la lecture du contexte d'un chantier quand le lock est tenu par une autre session active. Interceptée par la commande de pilotage de chantier.
Audit d'éclatement	`sy_chantier_explode_run`	Journal d'audit de chaque invocation du pipeline d'éclatement : une ligne créée « pending », puis mise à jour en succès / validation échouée / échec LLM / coupé par kill-switch. Colonnes notables : modèle, fournisseur, tokens d'entrée et de sortie, coût en euros, plan JSON, travaux créés. Rétention 90 j. Recherche des runs récents et comptage sur 24 h (appelé avant le run pour le kill-switch à plafond configuré).
Dépendances de tâches	`sy_tache_dep`	DAG de dépendances intra-travail (tâche→tâche). L'ajout est soumis à des validations bloquantes : pas d'auto-boucle, même travail, pas de cycle (parcours en profondeur), profondeur maximale de 100. Retrait et liste par travail. Lève une erreur de cycle ou de travaux croisés. Les dépendances inter-travaux vivent dans `sy_travail_dep` (clé composite, clés étrangères, contrainte anti-boucle), qui n'a pas de classe Python : elle est manipulée en SQL direct côté serveur Nuxt (lecture pour le run automatique, écriture par remplacement atomique avec détection de cycle par parcours en largeur). ⚠️ message d'erreur d'ajout renvoyant vers `sy_travail_dep` non re-vérifié.

L'entité travail porte aussi, dans sa détection de cycle inter-travaux, une garde de profondeur maximale de 200 avec ensemble des nœuds visités — distincte de la profondeur de 100 des dépendances de tâches.

6.3 Console CLI

API de la console CLI : 81 fichiers (dont 61 endpoints hors specs/helpers ; contre 77 dont 58 la veille et 38 en septembre). Socle : état, envoi de touches, flux, flux multiple, usage, handoffs, sessions perdues, changement de camp, changement de modèle, réincarnation, bureaux (liste, renommage, affectation), pages de tentacule, lexique, tenants, historique de quota, mandat de boîte mail, objectif, configuration de boutons, modèles Antigravity, aperçu de périmètre, redimensionnement, envoi de fichier, démarrage/arrêt, slot, agents, système, sessions, spawn de pool. Nouveau depuis septembre : pools (liste, aperçu, recrutement, conduites), spawn de ventouse, spawn, relâchement, heartbeat (+ politique de heartbeat), demande d'effacement, réponse automatique, commande humaine, profils, santé git, paquet de portabilité (§2), et le sous-dossier du runtime Codex (démarrage, arrêt, statut, tour, réponse, interruption, événements). ⚠️ Périmètre non ré-audité poste par poste — un passage dédié à cette famille est recommandé.
L'endpoint d'état forwarde toujours vers un daemon hôte (et non le conteneur — travail « fix container vs host »), via des helpers de client du daemon. Il renvoie succès, indicateur d'activité, informations. En cas de daemon arrêté : pas de 5xx, indicateur d'activité à faux, et le message d'erreur n'est jamais exposé au client (correctif de revue QA). C'est la surface qui pilote une session CLI réelle depuis le cockpit.

6.4 Négociations

Pages : liste et fiche (module d'interface).
API riche (17 fichiers, §3.2) : liste, archivage, reclassement, détail, assignation, contacts, livrables, fichier de livrable, emails, événements, propositions, démarrage du travail, statut, chronologie, décision sur une proposition.
Modèle : table sy_negociation (entité négociation). Pipeline : email transféré → Atlas, intention « négociation » → élément de négociation → fiche où les agents travaillent.

6.5 Fleet — module serveur seul et cockpit de flotte

Module fleet : manifeste + configuration + couche d'accès base — inchangé. Pas de page propre.
Modèle : table ps_ac_fleet_instance, dans le schéma central. Colonnes : identifiant d'instance, client, nom, domaine, offre, MRR, frais d'installation, statut, IP et région du VPS, URL et identifiants d'administration, clé d'API, mot de passe de base, note, fournisseur et modèle d'IA, dates.
⚠️ La source de vérité opérationnelle des VPS reste la table d'inventaire des serveurs clients, pas ps_ac_fleet_instance. Relation exacte entre les deux tables : à confirmer.
Ne pas confondre avec la page de pilotage de flotte du cockpit (module d'interface + 11 fichiers du module moteur) : celle-ci pilote les tentacules/ventouses (sessions d'agent en panes tmux, bureau, slot, worktree, santé git), pas la flotte de VPS clients.

Limite connue : ps_ac_fleet_instance contient des colonnes d'identifiants (mot de passe d'administration, mot de passe de base, clé d'API). C'est un schéma legacy hérité de la plateforme — incohérent avec la doctrine « zéro secret en base métier ». À auditer ; ne pas considérer cette table comme la source canonique de secrets.

6.6 Réacteur

Page du cockpit (hors sidebar, cf. §2.2) : vue orbitale live (3 anneaux concentriques par groupe d'agents), logo pieuvre au centre, flux SSE via un composable dédié, rendu client seul. Source des agents : un endpoint d'agents. Endpoints serveur du module moteur : agents, agents-ia, revues, réacteur, flux du réacteur.
Page publique (sans layout du cockpit, thème sombre) : même mise en scène orbitale, alimentée par l'endpoint de statistiques (nombre d'agents), sans authentification cockpit.

6.7 Atelier 3D — cockpit de sculpture et pont Blender live

Pages du module atelier3d (§2.1) : liste des projets, et cockpit de projet — visionneuse three.js en iframe, timeline des versions, terminal Phidias live, générateur de prompt Gemini, lancement de jobs de retopologie / couleurs / découpe / contrôle.
API dédiée (44 endpoints, hors famille cockpit — non comptés dans le total §3.2) : CRUD projet/version, upload de références (character design, dessin technique, étude anatomique), lancement de jobs Phidias, et les familles cage, repère, asset, job, volume, version, planche de référence (atelier de cage à splines — verrou, opération, rejeu, volume, bordures…).
Pont Blender live : un process hôte séparé relaie en WebSocket, sous jeton d'authentification et lié en boucle locale, l'état de scène d'un add-on Blender (objets, mode, compteurs de mesh, sélection, aperçu image) vers le cockpit de projet. L'URL du pont n'est renseignée que dans une session cockpit disposant du tunnel SSH vers ce pont — sans elle, la connexion live n'est pas tentée. Le navigateur ne pilote Blender qu'en lecture (instantané de scène, capture d'aperçu) ; aucune écriture de fichier .glb ne part du cockpit.
Le protocole de messages (bonjour, commande, état, aperçu) est validé côté Python, avec tests.

7. Pour reprendre le code — points d'entrée

Tu veux…	Va voir
Ajouter une entrée de sidebar	les trois tableaux de navigation du layout du cockpit (liens autonomes, zones visibles, zones avancées)
Ajouter une page du cockpit	un nouveau fichier `.vue` dans le module d'interface (ou un autre module à pages seules), avec la déclaration du layout du cockpit
Ajouter un endpoint cockpit	le module moteur (ou un autre module serveur seul), avec la garde de session employé
Étudier l'authentification	l'utilitaire de session et le middleware serveur de session
Brancher un nouveau layer	la clé `extends` de la configuration Nuxt + le manifeste et la configuration du module
Ajouter un secret runtime	la table d'alias de variables d'environnement (testée) — chaîne vide dans la configuration runtime, jamais la lecture d'une variable au build (§1.3)
Gardes de livraison des secrets	la garde de sortie, la garde « trou de secrets » et le rechargement par fichier d'écosystème de la bibliothèque de deploy, avec le scanner de sortie (§1.3)
Runs / chantiers (base)	entités de la couche entités et tables `sy_run`, `ps_ac_chantier` (+ `ps_ac_chantier_travail`, `sy_chantier_tache`), `sy_negociation`
Cadran de maintenance / dérive documentaire	la page de maintenance du cockpit et son endpoint back-office (tables de santé et de dérive documentaire)
Revue externe de documentation	le composant de revue externe, ses endpoints back-office (chapitres, prompt, historique) et la liste des chapitres valides (table de revues dédiée)
Registre hooks & réflexes	la page des hooks et son endpoint de liste (table `sy_reflex`, niveaux tronc / bras)
Console CLI (tmux, sessions, quotas)	la famille d'endpoints de la console CLI du module moteur (§6.3)
Cockpit des tentacules / mise en ligne	les pages de pilotage de flotte et de mise en ligne + les endpoints de pilotage de flotte du module moteur
Lock de chantier (concurrence CLI)	l'entité de lock (table `sy_chantier_lock`) — acquisition, prise de force, libération, heartbeat
Audit des runs d'éclatement	l'entité d'audit (table `sy_chantier_explode_run`) — recherche récente, comptage 24 h
Dépendances de tâches (DAG)	l'entité de dépendances (table `sy_tache_dep`) — ajout, retrait, liste par travail ; anti-cycle par parcours en profondeur
Atelier 3D / pont Blender live	la page de cockpit de projet (connexion live), le process de pont et le protocole de messages (§6.7)

Secrets : aucun secret en clair dans cette documentation. Le secret de signature des cookies de session est consommé par le module de cryptographie de session (HMAC) ; sa variable d'environnement vit dans des fichiers d'environnement hors dépôt, jamais dans le code. Depuis le chantier de sécurité de l'automne 2026, les secrets de la configuration runtime sont injectés au lancement du conteneur (§1.3), plus au build.

PrécédentAutomates, crons et runs : couche d'exécution non-conversationnelle SuivantInbox hub et Atlas Inbox : deux pipelines IMAP distincts

Tous les chapitres