Skills, agents & hooks — harness agentique Synedre OS

Vue d'ensemble du harness agentique

Le harness agentique de Synedre OS repose sur trois couches complémentaires : les skills (modules de compétence invocables), les agents (sous-agents délégables avec une identité propre) et les hooks d'événements (garde-fous et nudges déclenchés automatiquement à chaque étape du cycle de vie d'une session). L'ensemble est piloté par deux fichiers de configuration qui coexistent.

Fichier de configuration	Versionné	Contenu
Fichier de réglages versionné	Oui	Hooks PreToolUse / PostToolUse / Stop / UserPromptSubmit, variables d'environnement, mode de permissions par défaut
Fichier de réglages local	Non	Liste blanche de permissions (plusieurs centaines d'entrées), hooks SessionStart / UserPromptSubmit / PreToolUse / PostToolUse, mode automatique

Les deux jeux de hooks sont cumulatifs : pour un même événement (par exemple PreToolUse sur l'outil Bash), les commandes des deux fichiers s'exécutent. C'est pourquoi les garde-fous Python vivent dans le fichier local tandis que les nudges shell figurent dans le fichier versionné.

Catalogue des skills

Chaque skill est un module de compétence autonome, défini par un fichier de description en markdown. Il peut être invoqué manuellement ou déclenché par le moteur. Certains skills internes ne sont pas destinés à l'invocation directe.

Audit et santé du système

• Audit général — Audit complet d'un site ou d'une propriété : healthcheck infrastructure, pages publiques, SEO, performances, sécurité, base de données. Produit un score sur 100.
• Anti-rot de liste blanche — Vérifie que chaque chemin et section nommée dans la liste blanche immuable de niveau P0 existe encore. Protège contre la dérive silencieuse des références critiques.
• Audit SEO i18n — Contrôle la parité des clés de traduction FR↔EN, la cohérence des slugs URL localisés et la carte de routage. À lancer avant tout déploiement touchant les pages, l'internationalisation ou le routage.
• Audit du registre lexical — Détecte les dérives entre le dictionnaire canonique en base et les schémas de code. Mode lecture seule strict ; retourne un code de sortie sain ou dérivé.
• Audit des personas — Compare les personas des agents à la stack courante et enregistre un snapshot de dérive dans l'historique dédié.
• État du système — Vérifie l'état global du système (services, connectivité, ressources).
• État du contexte de session — Restitue l'état du contexte de la session en cours.

Infrastructure et hôtes

• Audit infra — Vérifie disponibilité, charge, services, certificats SSL et backups d'un hôte donné.
• Audit sécurité — Audit de sécurité d'un hôte (le VPS du vaisseau-mère ou un VPS client).
• Vérification des sauvegardes — Contrôle la fraîcheur et l'intégrité des sauvegardes locales d'un hôte.
• Mise à jour système — Lance une mise à jour APT non-interactive avec gel des paquets Docker.
• Analyse des bots — Analyse le journal des hits de robots collecté par le serveur.
• Interrogation GSC — Interroge l'API Google Search Console pour remonter les opportunités SEO.

Pilotage des chantiers

• Chantier — Pilote la doctrine « 1 chantier = N travaux » : création de squelette, suivi des travaux, lecture en base des chantiers et de leurs travaux associés.
• Run — Ouvre un run scopé (unité légère symétrique du chantier). Charge le périmètre depuis la base de données (vaisseau-mère, tenant, négociation) et restitue la ligne en cours. Distinct du lanceur d'application natif.
• Négociation — Charge le contexte complet d'une négociation commerciale : dossier, qualification, équipe, journal, livrables. Symétrique du chantier pour le pipeline prospect → contrat.
• Idée — Crée une note de brainstorm dans la table dédiée.
• Revue — Revue de la Place des Armes : chaque agent se présente et rapporte son état.
• Leçon post-chantier — Génère une leçon pédagogique après un chantier (méthode Montessori) et la dépose dans la boîte de réception du Vault Obsidian.

Email et boîte de réception

• Inbox (façade) — Lit et recherche les emails via la façade applicative, en base de données.
• Inbox directe — Accès IMAP de secours, lecture seule, sans écriture en base. Utilisé en cas d'indisponibilité de la façade.
• Recherche inbox — Wrapper ergonomique pour la récupération et l'analyse des emails : téléchargement au format .eml, liste des pièces jointes sans extraction préalable (approche scan-first).
• Scan de pièce jointe — Analyse antivirus d'une pièce jointe avant ouverture, via l'agent Mitnick.
• Vérification de proposition commerciale — QA d'une proposition commerciale avant envoi par email, orchestrée sur un pool de quatre agents.

Mémoire et connaissance

• Recall sémantique — Recherche RAG (retrieval-augmented generation) par similarité vectorielle sur la mémoire documentaire et les cicatrices, doctrines et chantiers en base. Utilise des embeddings cosine haute dimension.
• Zettelkasten — Décompose un document monolithique en notes atomiques pour le Vault Obsidian.
• Dictionnaire technique — Ajoute des termes au dictionnaire technique partagé.
• Victoire — Grave une victoire comme cicatrice de type victory dans la base.
• Rafraîchissement de persona — Met à jour la persona d'un agent via un modèle IA, une comparaison trois-voies et une revue, puis persiste la mise à jour en base.

Finance et business

• Banque — Consulte les comptes et transactions via la façade bancaire.
• Import bancaire — Import manuel de transactions depuis un export CSV N26 vers la table de transactions en base.
• Facturation — Crée, liste, génère des PDF et envoie factures et devis via la façade de facturation. Gère les abonnements récurrents. L'entité émettrice canonique est toujours l'entité juridique du titulaire du système.
• Prospects Malt — Récupère les conversations prospect depuis la plateforme Malt.

Publication et SEO

• Publication d'article — Publie un article de blog sur la propriété web désignée.
• Publication de cicatrices — Pipeline complet : curation → assainissement → revue contradictoire par Mitnick → publication des cicatrices publiques de Synedre. Publie la cicatrice-trophée (leçon extraite) ; ne publie jamais la cicatrice-tutoriel (repro exploitable).
• Sentinelle SEO — Détection précoce d'hémorragie de positions sur plusieurs propriétés. Lance l'automate de surveillance et reformule le rapport.

Documentation et QA

• Documentation technique — Génère ou rafraîchit la documentation technique via une orchestration multi-agents (rédaction → vérification → correction). Supporte un mode rafraîchissement sélectif (pages périmées uniquement) et un mode sans synthèse. Ne committe jamais sans validation explicite.
• QA visuelle — Capture un screenshot via Playwright et soumet l'image à un sous-agent multimodal pour vérifier que l'intention visuelle est bien rendue — au-delà du simple succès d'exécution du code.
• Clone de site — Génère le protocole d'intake « accès et informations serveur » pour cloner le site existant d'un client sur un VPS, et rédige la demande d'accès par email.

Sources de vérité en base de données

Les skills ne stockent pas la donnée métier : ils interrogent la base de données centrale via des tables dédiées. Voici la correspondance entre les principaux skills et les entités persistées :

Skill	Entités en base
Chantier	Table des chantiers, table des travaux de chantier
Recall sémantique	Table des cicatrices, table des doctrines, table des chantiers
Victoire	Table des cicatrices (kind = 'victory')
Idée	Table de brainstorm
Audit des personas	Table d'historique de dérive des personas
Rafraîchissement de persona	Table des agents
Inbox	Table des emails de la boîte de réception
Import bancaire	Table des transactions bancaires

Note d'architecture : un hook de pré-invocation consulte la taille déclarée de chaque skill en base pour décider si un chargement différé (lazy-load à trois niveaux) doit être suggéré, afin de préserver le contexte de session sur les skills volumineux.

Sous-agents : fichiers de personnalité délégables

Le système embarque une trentaine de fichiers de personnalité d'agent, chacun délégable via le mécanisme de délégation interne. Chaque fichier décrit un agent nommé : son rôle, ses critères de délégation, ses outils autorisés et le modèle de langage cible.

Une partie de chaque fichier est générée automatiquement depuis la base de données (données de persona : nom canonique, description, capacités) et encadrée par des marqueurs de zone managée. La zone éditoriale — doctrine, mode opératoire, consignes métier — est rédigée à la main et préservée entre chaque regénération. Il ne faut jamais modifier manuellement la zone managée : toute modification serait écrasée à la prochaine synchronisation.

Source de vérité : la table physique des agents (accessible en lecture via une vue dédiée) est l'unique référence. Le script de regénération lit la vue ; l'outil de rafraîchissement de persona écrit dans la table de base. Les deux opèrent sur la même source : aucun risque de divergence entre vue et table.

Chaque fichier de personnalité expose trois métadonnées de frontmatter : un nom public, une description servant de critère de délégation automatique, et la liste des outils autorisés.

Agents exécutants

Ces agents disposent d'un accès en lecture et en écriture, ainsi que de la capacité à exécuter des commandes système. Ils interviennent directement sur les artefacts du dépôt et l'infrastructure.

Codename public	Domaine	Capacités
Brunel	Infrastructure & DevOps — orchestration des conteneurs, reverse proxy, certificats SSL, DNS, gestion du VPS du vaisseau-mère	Lecture, écriture, exécution, recherche
Turing	Backend & fiabilité serveur — couche applicative Nuxt, modules métier, scripts Python, intégrité base de données	Lecture, écriture, exécution, recherche
Eames	Frontend — interface Nuxt 4 / Vue 3 / Tailwind, design system, pages du hub	Lecture, écriture, exécution, recherche
Otlet	SEO technique — balisage structuré, sitemap, Core Web Vitals, redirections, indexabilité IA	Lecture, écriture, exécution, recherche
Lovelace	Assurance qualité — dernier rempart avant mise en production, tests d'acceptance, détection de régressions	Lecture et recherche uniquement (pas d'écriture)
Mitnick	Sécurité offensive & défensive — analyse de pièces jointes, détection de secrets exposés, audit OWASP	Lecture et recherche uniquement (pas d'écriture)

Lovelace et Mitnick n'ont délibérément aucun droit d'écriture ni d'exécution : leur rôle est le contrôle, non la mutation. Mitnick en analyse de pièce jointe est un outil d'outillage (étape préalable à tout chantier), non un membre d'équipe recruté.

Agents conseil et connaissance

Ces agents n'ont accès qu'à la lecture du dépôt et des sources documentaires. Ils produisent des analyses, des recommandations, des drafts et des rapports — jamais d'exécution directe ni de modification de fichiers.

Codename public	Rôle
Atlas	Architecte & chef de projet — partitionne le travail en chantiers, dispatche aux agents spécialisés, orchestre la doctrine de délégation
Audiard	Auteur audio — réécriture pour l'oreille (rythme, oralité, souffle)
Bernays	Croissance commerciale — pipeline de leads, tunnels de conversion
Bernhardt	Contrôle qualité audio — notation (seuil 9,5/10 bloquant), diction, fidélité au texte source
Braille	Accessibilité — conformité WCAG 2.2 AA (navigation clavier, contrastes, ARIA)
Clausewitz	Stratégie — cohérence des décisions produit vis-à-vis du positionnement
Coco	Gardien de la marque — épuration tonale, cohérence visuelle cross-canal
Colbert	Direction générale — priorisation des chantiers, allocation de ressources, pilotage
Dumas	Narrateur — storytelling sérialisé, arcs émotionnels, épisodes, personnages
Gauss	Analyse de données — métriques (trafic, conversion, coûts), restitution d'insights
Hill	Vision long terme — cap stratégique, North Star
Hokusai	Illustration — character design & illustration manga/manhwa par IA générative
Itten	Direction artistique — palette chromatique, typographie, design tokens
Marco Polo	Veille — technologique, concurrentielle et marché
Méliès	Production visuelle IA — portraits, scènes, couvertures, ingénierie de prompts
Montesquieu	Conseil juridique (droit UE) — RGPD, CGV, droit numérique
Montessori	Pédagogie — modules d'apprentissage, dictionnaire, parcours apprenants
Nightingale	Succès client — rédaction de communications client, jamais d'envoi direct
Ogilvy	Copywriting — ton persuasif, clarté du message, CTA, cohérence cross-canal
Pacioli	FinOps — suivi des coûts IA, infrastructure, services, réconciliation financière
Pulitzer	Content & blog SEO — articles, couvertures, maillage interne
Renoir	Supervision du scheduling — orchestration des automates, horaires, silences entre tâches
Socrate	Dialogue & communauté — questionnement maïeutique, FAQ, clarification des présupposés
Winnicott	Équilibre opérationnel — détection de surcharge, ajustements de rythme

Invariants de conception

• Nightingale ne dispose d'aucune capacité d'exécution système : il est strictement en lecture, ce qui garantit que le système ne communique jamais directement avec un client sans validation humaine.
• Tous les agents conseil (section précédente) opèrent en lecture seule : zéro exécution, zéro écriture.
• Atlas applique la doctrine de chantier : pour tout périmètre significatif, au moins deux agents distincts sont mobilisés, et la délégation passe par le mécanisme de délégation interne — jamais par appel direct.
• Un drift résiduel peut apparaître entre la zone managée d'un fichier d'agent et les données réelles en base si une synchronisation manuelle a eu lieu. La source de vérité reste toujours la table physique des agents ; les outils refresh-persona et audit-personas permettent de corriger tout écart.

4. Hooks

4.1 Carte des événements

Le harnais intercepte le cycle de vie de l'agent à six points clés. Chaque interception peut être bloquante (l'agent ne continue pas) ou non-bloquante (avertissement seul). Le tableau suivant résume la carte complète :

Point d'interception	Outil ciblé	Mécanismes déclenchés
Démarrage de session	(local)	Remise à zéro du contexte, génération du brief, injection des cicatrices
Soumission d'un prompt utilisateur	versionné + local	Synchronisation du schéma DB, synchronisation de la boîte mail (agent Nightingale)
Avant utilisation — Lecture	versionné	Contrôle antivirus des pièces jointes (fail-closed)
Avant utilisation — Commande shell	versionné + local	8 nudges et gardes shell, 3 garde-fous Python
Avant utilisation — Agent	versionné + local	Réacteur d'agent, injection de cicatrices
Avant utilisation — Skill	versionné	Suggestion de vue allégée si la fiche de compétence est volumineuse
Avant utilisation — Édition/Écriture	versionné	Moteur de réflexes décentralisés (décision deny/warn/allow, trace d'audit)
Avant utilisation — Édition/Écriture	local	Injection de cicatrices
Après utilisation — Commande shell	versionné	Journal de réaction, déploiement preprod post-commit
Après utilisation — Agent	versionné	Réacteur, journal de réaction, télémétrie
Après utilisation — Éditions multiples	versionné	Suivi des fichiers édités dans la session
Après utilisation — Tous outils	versionné	Événement cockpit CLI (best-effort, non-bloquant)
Après utilisation — Tous outils	local	Comptage de tokens / contexte
Fin de session (Stop)	versionné	Signal cockpit de fin de tour → libération du verrou chantier → rappel cicatrices → vérification commits → synchronisation chantier

4.2 Démarrage de session

Trois opérations s'exécutent à l'ouverture de chaque session, chacune avec un délai d'expiration de 5 secondes :

1. Remise à zéro du compteur de contexte — le module de suivi de contexte repart à zéro pour la session courante.
2. Génération du brief — le générateur de rapport lit un rapport pré-calculé (produit chaque nuit vers 5 h UTC par une tâche planifiée de type audit quotidien) et l'enrichit en temps réel : état git, crontab, emails clients en attente, backlog, cicatrices. Le résultat est injecté dans le contexte de démarrage. Aucune dépendance npm n'est requise ; la lecture de la base se fait via le moteur de base de données conteneurisé du vaisseau-mère.
3. Injection des cicatrices — les cicatrices pertinentes pour la session sont injectées dans le contexte initial.

Note de configuration : le hook de démarrage de session n'est pas présent dans le fichier de configuration versionné partagé — il vit uniquement dans le fichier de configuration local (non versionné). Cette séparation est intentionnelle : les opérations de démarrage accèdent à des ressources locales (base de données, inbox) qui ne sont disponibles que sur le vaisseau-mère.

4.3 Soumission d'un prompt utilisateur

• Fichier versionné : synchronisation du dump de schéma de base de données à chaque prompt — l'agent dispose toujours d'une vue fraîche de la structure des tables.
• Fichier local : synchronisation de la boîte mail (agent Nightingale, délai d'expiration 15 s) — à chaque prompt, les nouveaux emails entrants sont rapatriés dans la table de suivi de l'inbox. Ce mécanisme est implémenté comme un skill dédié exposé via la façade applicative ; le script de synchronisation réelle est distinct du script de lecture directe.

Historique correctif : jusqu'à mi-2026, ce hook pointait vers un script fantôme jamais migré, ce qui le faisait échouer silencieusement. La correction a également mis à jour la liste blanche du garde-fou email, qui référençait le même script obsolète.

4.4 Avant utilisation (PreToolUse)

Garde antivirus — outil Lecture (bloquant, versionné)

Toute tentative de lecture d'une pièce jointe dans la zone de quarantaine temporaire est bloquée si un marqueur de verdict antivirus propre n'est pas présent pour ce fichier. Ce réflexe est fail-closed : en l'absence du marqueur, l'accès est refusé. Il n'a aucune dépendance envers la base de données — il s'évalue sur la seule présence ou absence du fichier de verdict.

Gardes shell — outil Commande (versionné)

Huit scripts s'enchaînent avant toute exécution de commande shell :

Garde	Comportement
Contrôle antivirus pièces jointes	Même logique fail-closed que pour l'outil Lecture : bloque les commandes shell qui ouvriraient une pièce jointe non scannée.
Blocage de la commande de mise en production (./ship)	Bloquant — l'agent ne peut jamais déclencher lui-même la mise en production publique. Réflexe de tronc, zéro dépendance runtime.
Contrôle de mutation base de données	Bloque toute mutation destructive sur les tables internes du système si aucun commit de code aligné n'a eu lieu dans les cinq dernières minutes. Incarne la doctrine « le code avant la base ».
Auto-commit avant déploiement	Effectue automatiquement un commit avant l'exécution d'un ./deploy.
Nudge squelette de chantier	Avertit si une insertion SQL brute sur un chantier est tentée au lieu d'utiliser la commande de création avec squelette dédiée.
Scan anti-fuite pré-commit	Analyse les fichiers à committer pour détecter d'éventuelles fuites (secrets, données sensibles) avant qu'ils n'entrent dans l'historique git. Délai d'expiration : 10 s.
Rappel de chantiers existants	Non-bloquant (délai 30 s) — lors de la création d'un nouveau chantier, effectue un rappel hybride (recherche lexicale + sémantique) et injecte les quatre chantiers ou doctrines les plus proches. Évite de réinventer l'existant.
Nudge de liaison documentation	Avertissement seul (jamais bloquant) — au moment d'un commit git, croise les fichiers modifiés avec les contrats de liaison des chapitres de documentation. Si un fichier lié à un chapitre est touché, rappelle de vérifier que le chapitre est encore exact.

Note repreneur : un script de contrôle d'authentification back-office existe dans le dépôt mais n'est référencé dans aucun fichier de configuration actif — il est dormant et sans effet.

Garde-fous Python — outil Commande (local)

Trois garde-fous supplémentaires, bloquants, s'exécutent depuis la configuration locale :

Garde-fou	Comportement
Protection des environnements de production client	Bloque toute commande shell ciblant un environnement de production client avec un pattern d'écriture destructive (TRUNCATE, DROP, DELETE, ALTER, UPDATE, import direct via pipe). Trois couches d'anti-faux-positifs : (1) les commandes visant le vaisseau-mère lui-même sont court-circuitées avant le test client ; (2) les commandes visant la preprod client passent sans contrôle ; (3) les requêtes non destructives (SELECT, SHOW, INSERT simple) ne sont pas ciblées — seules neuf familles d'opérations dangereuses sont effectivement bloquées. Les commandes d'écriture autorisées doivent transiter par le script de sécurisation dédié.
Protection de la façade email	Bloque tout contournement de la façade d'envoi email officielle. Interdit l'utilisation directe des bibliothèques SMTP/IMAP bas niveau ou d'alias d'envoi non officiels. Seuls les scripts d'envoi, de synchronisation inbox, de lecture directe et de mailbox spécialisée figurant dans la liste blanche sont autorisés — chacun accepté avec ou sans chemin relatif. Le script fantôme jamais migré a été retiré de la liste blanche lors de la correction de mi-2026.
Injection de cicatrices contextuelles	Injecte les cicatrices liées à la commande en cours d'évaluation. Délai d'expiration : 3 s.

Évolution de la façade email (mi-2026) : la façade auto-envoie une copie de validation à l'opérateur humain à chaque brouillon créé (mécanisme show-before-send appliqué en pratique, pas seulement déclaratif). L'envoi réel appose automatiquement la signature HTML canonique. Un mode de conversion Markdown vers HTML email-safe est disponible. Au moment du brouillon, le ton de rédaction adapté au destinataire est affiché (best-effort, non-bloquant). Un mode de renvoi de copie de validation sur brouillon existant est également disponible, sans recréer le brouillon.

Moteur de réflexes — outil Édition/Écriture (versionné)

Avant toute édition de fichier, le moteur de réflexes décentralisés entre en jeu. Il lit l'événement hook entrant, charge les règles actives depuis la table de réflexes du système, évalue une décision (deny, warn ou allow) et trace l'événement dans la table d'audit des réflexes. Gestion fail-closed ciblée :

• Si la base de données primaire est injoignable : blocage uniquement pour les zones de code sensibles (le cœur du produit principal) ; hors zone sensible, la main est laissée à l'agent.
• Si une erreur Python survient dans le moteur lui-même : passage en allow avec trace sur l'erreur standard — un bug du garde-fou ne bloque jamais le travail.

En parallèle, le script d'injection de cicatrices (configuration locale) s'exécute cumulativement pour le même événement d'édition.

Agent et Skills

• Outil Agent : le réacteur d'agent (versionné) et le script d'injection de cicatrices agent (local) s'exécutent avant tout sous-appel d'agent.
• Outil Skill : un hook non-bloquant (délai 5 s, exit 0 garanti) suggère d'utiliser la vue allégée d'une fiche de compétence lorsque celle-ci dépasse un seuil de taille configuré.

4.5 Après utilisation (PostToolUse)

• Commande shell : deux hooks s'enchaînent.
  1. Le journal de réaction enregistre le résultat de la commande.
  2. Le déploiement preprod automatique post-commit analyse les chemins touchés et détermine le site impacté. Nuance importante : pour les sites client, il s'agit d'un déploiement en preprod ; pour le vaisseau-mère lui-même, il n'existe pas de preprod — ./deploy déclenche un rebuild en direct. Le hook saute le déploiement si le message de commit contient une directive d'exclusion ([skip-deploy] / [no-deploy] / préfixe wip:), si le commit ne touche que de la documentation sans fichier runtime, ou si le répertoire de travail est sale après le commit.
• Agent : réacteur, journal de réaction, télémétrie (délai 5 s).
• Éditions multiples : le traqueur de fichiers édités par session (délai 3 s) maintient la liste des fichiers modifiés, utilisée ensuite par le hook de fin de session.
• Tous outils : le miroir d'activité cockpit CLI (délai 10 s) émet un événement vers le cadran de suivi du chantier actif. Il s'active uniquement si un chantier actif est enregistré ; si la variable d'environnement de désactivation est positionnée ou si aucun chantier n'est lié, il sort immédiatement sans coût. Non-bloquant : un événement raté ne bloque jamais l'appel d'outil.
• Tous outils (local) : le compteur de tokens de contexte (délai 5 s) met à jour les métriques de consommation de la session.

4.6 Fin de session (Stop)

Cinq opérations s'exécutent séquentiellement à la clôture de chaque session :

1. Signal de fin de tour au cockpit (délai 9 s) — émet un fragment de fin de tour dans la chronologie du cadran de suivi du chantier, uniquement si la fonctionnalité est activée et qu'un chantier est lié.
2. Libération du verrou chantier (délai 3 s) — libère le verrou de session sur le chantier en cours.
3. Rappel de cicatrices — déclenché uniquement si le dernier message utilisateur contient un mot-clé de clôture (« clôture », « fin de session », « on ferme »…). Lorsqu'il se déclenche, liste les commits correctifs depuis la dernière mise en preprod via le canal d'erreur standard, et retourne un code bloquant.
4. Vérification des commits (délai 5 s, bloquant) — refuse la clôture si des fichiers modifiés dans cette session ne sont pas commités. Force le commit en flux continu. Mécaniques clés :
   • Session-aware : seuls les fichiers de la session courante sont vérifiés — plusieurs sessions Claude parallèles ne se bloquent pas mutuellement.
   • Anti-boucle : si le hook détecte qu'il est déjà en deuxième passe, il bascule en avertissement non-bloquant au lieu d'un blocage dur.
   • Court-circuit worker : si la session est un sous-agent spawné par le moteur de tâches automatisées, le hook sort silencieusement — le worker gère son propre cycle de commit.
   • Le fichier de configuration de session lui-même est exclu de la vérification.
5. Synchronisation du chantier (délai 8 s) — rappel de synchronisation entre l'état local du chantier et la base du hub.

4.7 Convention de contexte worker

Un module utilitaire partagé, sourcé par les quatre hooks de fin de session, implémente une sortie anticipée systématique lorsque la session est un sous-agent spawné par le moteur de tâches automatisées. Cette convention garantit qu'un sous-agent :

• ne déclenche pas les rappels de cicatrices de clôture,
• ne libère pas des verrous qui appartiennent à la session parente,
• n'est pas bloqué par la vérification de commits (il gère son propre cycle),
• ne pollue pas la synchronisation de chantier de la session utilisateur principale.

La variable d'environnement de contexte worker est injectée par le module de spawn du moteur de tâches au moment de la création du sous-agent. Cette séparation est une règle générale : ce qui appartient à la session utilisateur ne s'applique pas aux agents automatisés, et vice-versa.

Permissions et environnement d'exécution

Configuration principale

Le fichier de configuration principal de l'agent définit deux paramètres clés :

• Un bloc env activant les variables d'expérimentation du moteur (équipes d'agents, rendu sans scintillement).
• Un bloc permissions avec defaultMode: auto — l'agent s'exécute sans demander de confirmation à chaque étape, ce qui est cohérent avec la doctrine d'autonomie portée par la commande ./deploy.

Configuration locale et politique d'accès aux données

Un second fichier de configuration, propre à la machine hôte et exclu du dépôt versionné, affine la politique d'autorisation :

• La liste d'autorisation recense plusieurs centaines d'outils et de commandes pré-approuvés ; aucune liste de refus explicite n'est définie à ce niveau.
• Les variables d'environnement locales sont délibérément vides : aucun secret n'est injecté par ce canal.
• Un bloc de politique en langage naturel précise les règles d'accès aux bases de données selon l'environnement :
  • Lecture seule autorisée sur l'environnement de staging d'un client donné.
  • Écriture en production soumise à confirmation explicite à chaque opération — la règle ne peut pas être contournée par accumulation de contexte.
  • Un rappel explicite distingue les deux VPS concernés (production et staging) afin d'éviter toute confusion lors des interventions.

Cette politique déclarative est doublée par un garde-fou exécutable (décrit en section 4) : la règle est donc appliquée à deux niveaux indépendants — la configuration et le hook de vérification — ce qui constitue une défense en profondeur.

Prévention des fuites de secrets

Aucun secret n'apparaît en clair dans les hooks, compétences ou définitions d'agents. Les identifiants de messagerie (réception et envoi), les mots de passe de base de données et les clés API sont référencés uniquement par leur nom de variable dans un fichier d'environnement local exclu du versionnement. Leur valeur n'est jamais inscrite dans un fichier suivi par le dépôt.

Deux mécanismes de surveillance complémentaires assurent la détection des fuites :

• Un hook de pré-validation scanne les transcriptions avant tout commit pour détecter toute valeur sensible qui aurait pu être capturée dans l'historique de session.
• Une compétence dédiée à l'analyse des pièces jointes détecte les contenus malveillants potentiels avant leur traitement.

Modèle de données — vue d'ensemble des flux

Le tableau suivant récapitule les principaux domaines fonctionnels du modèle de données, en indiquant pour chacun quel composant produit les données et quel composant les consomme.

Domaine fonctionnel	Producteur	Consommateur
Référentiel des agents (table de base + vue de lecture)	Édition manuelle ou compétence de rafraîchissement des personas	Script de régénération des fichiers de définition d'agents (lit la vue de lecture)
Chantiers et travaux associés	Compétence chantier, entité métier chantier	Hooks de synchronisation et de verrouillage des chantiers
Cicatrices (événements mémorisés)	Compétence de victoire, hook d'arrêt	Compétence de rappel, injection au démarrage de session et avant chaque outil
Rapports d'audit quotidiens	Tâche d'audit planifiée	Script de briefing de session (injecté au démarrage)
Index des compétences (taille en octets)	Indexation automatique des compétences	Hook de pré-invocation des compétences
Historique de dérive des personas	Audit des personas	Revue manuelle de dérive
Idées / brainstorm	Compétence de soumission d'idées	Cadran de brainstorm du hub
Boîte de réception e-mail	Façade de messagerie entrante	Compétence de lecture de la boîte
Transactions bancaires	Import automatisé depuis la banque	Compétence de consultation bancaire

Note architecturale : le référentiel des agents repose sur une table de base unique exposée via une vue de lecture. Le script de régénération lit la vue ; la compétence de rafraîchissement des personas écrit directement dans la table de base. Il n'existe pas deux tables divergentes : la cohérence est garantie et aucune migration n'est nécessaire.