Skills, agents & hooks — harness agentique Synedre OS

Vue d'ensemble du harness agentique

Le harness agentique de Synedre OS est organisé autour de trois piliers complémentaires : les compétences (répertoires de comportement invocables), les sous-agents (entités délégataires) et les hooks d'événements (garde-fous et nudges déclenchés automatiquement). Ces trois piliers sont configurés dans un répertoire de réglages central, via deux fichiers distincts.

         ┌──────────────── Répertoire de configuration ────────────────┐
         │                                                              │
utilisat.│  réglages versionnés (git)  +  réglages locaux (non commités)│
/ Atlas  │    └── hooks PreToolUse / PostToolUse / Stop / UserPrompt   │
         │                                                              │
         │  compétences/  ──▶ invoquées via le moteur de compétences   │
         │  sous-agents/  ──▶ délégués via le moteur d'agents          │
         └──────────────────────────────────────────────────────────────┘
                        │                        │
                        ▼                        ▼
             scripts de garde-fous       façades métier + injection mémoire
             (hooks shell)               (modules Python / JS)

Deux fichiers de réglages coexistent et sont cumulatifs : pour un même événement (par exemple PreToolUse sur un outil Bash), les commandes des deux fichiers s'exécutent dans l'ordre. Cette séparation permet de versionner les nudges génériques tout en gardant les garde-fous sensibles hors du dépôt.

Fichier	Versionné git	Contenu
Réglages versionnés	Oui	Hooks PreToolUse / PostToolUse / Stop / UserPromptSubmit, variables d'environnement, mode de permissions par défaut
Réglages locaux	Non	Liste étendue de permissions autorisées, hooks SessionStart / UserPromptSubmit / PreToolUse / PostToolUse, mode automatique

Catalogue des compétences

Chaque compétence est un répertoire autonome contenant une fiche de description en markdown — avec ou sans frontmatter. Un sous-répertoire regroupe les compétences internes au moteur, non destinées à l'invocation manuelle. Les compétences sont organisées par domaine fonctionnel.

Audit et santé système

Compétence	Rôle
Audit général	Healthcheck complet d'un site public : infra, pages, SEO, performance, sécurité, base de données — score sur 100.
Anti-rot liste blanche	Vérifie que chaque chemin et section de la liste blanche immuable P0 existe encore dans le dépôt.
Audit i18n & slugs	Parité des clés de traduction FR ↔ EN, slugs URL anglais corrects, cohérence de la carte localisée. À lancer avant tout déploiement touchant les pages ou le routage.
Audit lexical	Détecte les dérives du registre lexical canonique : entrées manquantes ou désalignées en base, enums divergents dans le code, synonymes interdits dans les schémas. Mode dry-run strict ; retourne 0 si sain, 1 si dérive détectée.
Audit personas	Détecte les écarts entre les personas documentées et la stack réelle ; consigne un instantané historique.
État système	Check complet de l'état courant du système.
État du contexte	Rapport sur l'état du contexte de la session en cours.

Infrastructure et hôtes

Compétence	Rôle
Audit infra	Disponibilité, charge, services, SSL et sauvegardes d'un hôte donné.
Audit sécurité	Audit sécurité d'un hôte (le VPS du vaisseau-mère ou un VPS client).
Vérification sauvegardes	Contrôle la fraîcheur et l'intégrité des sauvegardes locales d'un hôte.
Mise à jour système	Upgrade APT non-interactif d'un hôte avec gel du démon de conteneurisation.
Analyse bots	Analyse le journal de hits de robots du serveur applicatif.
Search Console	Interroge l'API Google Search Console via la façade dédiée.

Pilotage des chantiers

Compétence	Rôle
Chantier	Pilotage des chantiers selon la doctrine « 1 chantier = N travaux » ; lecture et écriture dans les tables dédiées ; supporte la création d'un squelette de chantier depuis la ligne de commande.
Run	Ouvre un run scopé — unité légère symétrique du chantier. Charge le périmètre (vaisseau-mère / tenant / négociation) depuis la base de données 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 lead → deal.
Idée	Crée une entrée de brainstorm dans la table dédiée.
Revue	Revue de la Place des Armes — chaque agent se présente et rend compte.
Leçon post-chantier	Génère une leçon Montessori après un chantier via l'agent Academy ; produit un draft dans le Vault Obsidian.

Email et boîte de réception

Compétence	Rôle
Inbox (façade)	Lit et recherche les emails dans la table de réception via la façade Nuxt.
Inbox directe	Fallback IMAP direct, lecture seule — n'écrit pas en base de données.
Recherche inbox	Wrapper IMAP ergonomique : récupère les messages, exporte en .eml, liste les pièces jointes sans les extraire (approche scan-first).
Scan pièces jointes	Analyse antivirus d'une pièce jointe avant ouverture, via la façade dédiée (agent Mitnick).
QA proposition commerciale	Contrôle qualité d'une proposition commerciale avant envoi, via un pool de quatre agents.

Mémoire et connaissance

Compétence	Rôle
Recall sémantique	Recherche vectorielle RAG sur la mémoire documentaire et les tables de cicatrices, doctrine et chantiers (embeddings Mistral 1024 dimensions, similarité cosinus).
Zettel	Éclate un document monolithique en notes atomiques pour le Vault Obsidian.
Dictionnaire	Ajoute des termes au dictionnaire technique canonique.
Victoire	Grave une victoire dans la table des cicatrices avec le type victory.
Refresh persona	Rafraîchit la fiche d'un agent via Mistral, diff à trois voies et revue, puis met à jour la table des agents.

Finance et business

Compétence	Rôle
Banque	Consulte les comptes et transactions via la façade bancaire.
Import transactions	Import manuel de transactions depuis un export CSV externe vers la table de transactions bancaires.
Facturation	Crée, liste, génère en PDF et envoie factures et devis via la façade de facturation ; gère les abonnements récurrents. L'entité émettrice canonique est définie par la doctrine fiscale — jamais une autre entité sans ordre explicite.
Prospects plateforme	Récupère les conversations prospect depuis la plateforme freelance configurée.

Publication et SEO

Compétence	Rôle
Publication article	Publie un article de blog sur le site public configuré.
Publication cicatrices	Pipeline complet : curation → assainissement → revue adverse (agent Mitnick) → publication des cicatrices publiques sur synedre.com. Sélection depuis la table des cicatrices, écriture en base, déploiement et scan de fuite live. Publie uniquement la cicatrice-trophée (la leçon) — jamais la cicatrice-tutoriel (repro exploitable).
Sentinelle SEO	Surveillance SEO technique multi-tenant : détecte précocement les pertes de positions, lance l'automate et produit un rapport reformulé.

Documentation et QA

Compétence	Rôle
Doc technique	Génère ou rafraîchit la documentation technique via orchestration multi-agents (écriture → vérification → correction). Supporte un mode rafraîchissement (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 le soumet à un sous-agent multimodal pour vérifier que l'intention visuelle est effectivement 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 reproduire le site existant d'un client sur un VPS et rédige la demande d'accès par email client.

Le catalogue ci-dessus reflète les quarante compétences actives au moment de la rédaction. Le moteur expose également des compétences internes (création automatique de compétence, réaction automatique sur tâche) non destinées à l'invocation manuelle.

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

Les compétences ne stockent pas la donnée métier : elles interrogent et écrivent dans la base de données relationnelle via les façades dédiées. Les correspondances principales sont les suivantes :

• Chantiers et travaux → tables chantier et travaux associés
• Recall sémantique → tables cicatrices, doctrine, chantiers
• Victoires → table cicatrices (type victory)
• Brainstorm / idées → table brainstorm
• Historique personas → table d'historique de dérive des personas
• Agents → table des agents
• Emails → table de réception des emails
• Transactions bancaires → table des transactions bancaires

Un hook de pré-invocation consulte la taille en base de chaque compétence pour décider s'il convient de proposer un chargement différé (lazy-load en trois niveaux), afin de préserver la fenêtre de contexte lors des sessions longues.

Sous-agents délégables

Le système repose sur une trentaine de profils d'agents spécialisés, chacun défini par un fichier de configuration dédié. Ces fichiers sont partiellement générés depuis la base de données : un script de régénération lit la vue agents (elle-même construite sur la table de base des agents) et met à jour une zone délimitée par des marqueurs dans chaque fichier. La zone éditoriale restante — doctrine, mode opératoire — est rédigée manuellement et préservée entre chaque régénération. Il ne faut donc jamais modifier manuellement la zone gérée automatiquement.

Note d'architecture : La vue agents est en lecture seule. La table de base sous-jacente est la source de vérité physique : le script de mise à jour des personas y écrit directement, tandis que le script de régénération des fichiers agents lit via la vue. Les deux sont cohérents — il n'existe aucune divergence ni risque lié à une double table.

Chaque profil d'agent expose trois métadonnées clés : un nom, une description (critère de sélection pour la délégation automatique) et la liste des outils auxquels il a accès. Tous tournent sur le même niveau de modèle de langage.

Agents exécutants

Ces agents disposent d'un accès en lecture et en écriture, ainsi que de la capacité d'exécuter des commandes système. Ils sont les bras opérationnels du système.

Codename public	Rôle	Périmètre d'outils
Brunel	DevOps / Infrastructure — conteneurisation, reverse proxy, SSL, DNS, gestion des serveurs	Lecture, écriture, exécution, recherche
Turing	Ingénierie backend — serveur applicatif, modules métier, intégrité base de données	Lecture, écriture, exécution, recherche
Eames	Frontend — interfaces Vue 3, design system, pages du hub de pilotage	Lecture, écriture, exécution, recherche
Otlet	SEO technique — balisage structuré, sitemap, Core Web Vitals, redirections, indexabilité IA	Lecture, écriture, exécution, recherche
Lovelace	QA — dernier rempart avant production, tests d'acceptance, détection de régressions	Lecture et recherche uniquement — aucune écriture
Mitnick	Sécurité offensive et défensive — analyse de pièces jointes, détection de secrets, conformité OWASP	Lecture et recherche uniquement — aucune écriture

Observation : Lovelace et Mitnick ne disposent d'aucun droit de modification. Leurs rôles sont de contrôle, pas de mutation — c'est une contrainte délibérée et non une omission.

Agents conseil et connaissance

Ces agents n'ont accès qu'à la lecture. Ils produisent des analyses, des drafts et des recommandations, mais n'exécutent jamais d'action directe sur le système. Aucun d'eux ne dispose d'accès Bash ni d'accès en écriture.

Codename public	Rôle
Atlas	Architecte et chef de projet — partitionne le travail, dispatche aux agents spécialisés, orchestre les chantiers
Audiard	Auteur audio — réécriture pour l'oreille (rythme, oralité, souffle)
Bernays	Croissance commerciale — pipeline, 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	Narration — 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 et illustration manga/manhwa assistée par IA
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 du numérique
Montessori	Pédagogie — modules de formation, 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 — coûts IA, infrastructure, services, réconciliation budgétaire
Pulitzer	Contenu et blog SEO — articles, couvertures, maillage interne
Renoir	Supervision des automates — ordonnancement des tâches planifiées, gestion des silences et des horaires
Socrate	Dialogue et communauté — maïeutique, challenger de présupposés, FAQ, clarté
Winnicott	Équilibre opérationnel — détection de surcharge, ajustements de rythme

Garanties structurelles et doctrine de délégation

• Lovelace et Mitnick sont des agents de contrôle : ils lisent, analysent et alertent, mais ne modifient jamais rien. Cette contrainte est inscrite dans leur configuration.
• Nightingale n'a pas accès à l'exécution système — la règle selon laquelle le système ne s'adresse jamais directement aux clients est ainsi appliquée de façon structurelle, pas seulement doctrinale.
• Tous les agents conseil (section précédente) sont strictement limités à la lecture : zéro exécution, zéro écriture.
• En cas de dérive entre la zone gérée automatiquement et la zone éditoriale d'un fichier agent, la table de base des agents fait foi. Les outils de mise à jour des personas et d'audit permettent de resynchroniser l'ensemble.

La doctrine de délégation impose qu'Atlas mobilise au minimum deux agents distincts pour tout chantier touchant au périmètre d'un client, et délègue via le mécanisme d'orchestration prévu à cet effet. L'intervention de Mitnick en analyse de pièces jointes est traitée comme une étape d'outillage préliminaire — non comme un recrutement d'équipe à part entière.

4. Hooks

4.1 Carte des événements

Le harnais s'articule autour de plusieurs points d'ancrage qui interceptent le cycle de vie de chaque interaction. Le tableau suivant résume, pour chaque événement, le ou les mécanismes activés :

Événement	Périmètre	Mécanismes déclenchés
SessionStart	local	Remise à zéro du contexte, brief de session, injection des cicatrices
UserPromptSubmit	versionné + local	Synchronisation du schéma DB, synchronisation de la boîte de réception (agent Nightingale)
PreToolUse Read	versionné	Garde antivirus sur les pièces jointes en attente de scan
PreToolUse Bash	versionné + local	8 nudges et gardes shell, 3 garde-fous supplémentaires
PreToolUse Agent	versionné + local	Réacteur d'agent, injection de cicatrices
PreToolUse Skill	versionné	Pré-invocation (suggère la vue allégée si la fiche compétence est volumineuse)
PreToolUse Edit|Write	versionné + local	Moteur de réflexes décentralisés, injection de cicatrices
PostToolUse Bash	versionné	Journal de réaction, déploiement preprod post-commit
PostToolUse Agent	versionné	Réacteur, journal de réaction, télémétrie agent
PostToolUse Edit|Write|…	versionné	Suivi des éditions de la session
PostToolUse (tous outils)	versionné	Événement cockpit CLI (best-effort)
PostToolUse (tous outils)	local	Comptage de tokens / contexte
Stop	versionné	Arrêt cockpit → libération du verrou → cicatrice → avertissement non-commité → synchronisation chantier

4.2 SessionStart (configuration locale)

Trois commandes sont exécutées à chaque ouverture de session, chacune avec un délai maximum de 5 secondes :

1. Remise à zéro du compteur de contexte — réinitialise le suivi de la fenêtre de contexte pour la nouvelle session.
2. Brief de session — lit le rapport pré-calculé produit chaque nuit à 5 h UTC (type daily_meet) et l'enrichit en temps réel : état git, crontab, emails clients en attente, backlog, cicatrices récentes. Aucune dépendance npm.
3. Injection des cicatrices — pousse dans le contexte de démarrage les cicatrices jugées pertinentes pour la session.

⚠️ Le hook SessionStart ne figure pas dans la configuration versionnée partagée — il vit uniquement dans la configuration locale de la machine hôte, volontairement hors dépôt.

4.3 UserPromptSubmit

• Configuration versionnée : synchronisation du dump de schéma de base de données vers un fichier de référence consulté par l'agent.
• Configuration locale : synchronisation de la boîte de réception IMAP (agent Nightingale, délai maximum 15 s) — les emails entrants sont ingérés dans la table de messagerie à chaque nouveau prompt.
  Note de maintenance (corrigée) : un ancien script fantôme — jamais migré — était référencé à tort dans cette configuration ; il échouait silencieusement. La référence morte a été remplacée par le script de synchronisation correct, et la même erreur de pointeur avait été recopiée dans la liste blanche du garde email (également corrigée).

4.4 PreToolUse

Matcher Read — garde antivirus (bloquant)

Mécanisme	Effet
Garde de lecture des pièces jointes	BLOQUANT (exit 2) : interdit toute lecture d'une pièce jointe en attente tant qu'un verdict antivirus propre (empreinte SHA-256 validée) n'existe pas. Réflexe fail-closed, zéro dépendance base de données.

Matcher Bash — nudges et gardes (configuration versionnée)

Mécanisme	Effet
Garde antivirus (commandes Bash)	Même logique que pour Read : bloque aussi les commandes shell qui tenteraient d'ouvrir une pièce jointe non scannée.
Blocage du déploiement vers les cibles non autorisées	BLOQUANT (exit 2) : consulte la table de configuration des environnements clients (auto_ship_allowed) et bloque la commande ./ship pour les cibles dont le champ est false ou inconnues (fail-closed). Les cibles autorisées passent librement. Réflexe TRONC, zéro dépendance runtime.
Garde mutation base de données	Bloque toute mutation de données de configuration (UPDATE/INSERT/ALTER) sans commit de code aligné dans les 5 dernières minutes — applique le principe « code avant base ».
Auto-commit avant déploiement	Déclenche un commit automatique avant toute exécution de ./deploy.
Nudge squelette de chantier	Avertit si un chantier est créé via un INSERT SQL brut au lieu de la commande create_with_skeleton.
Scan anti-fuite avant commit	Analyse le contenu du commit (délai max 10 s) pour détecter d'éventuelles fuites de données sensibles.
Recall de chantiers existants	Non-bloquant (délai max 30 s) : au moment de la création d'un chantier, effectue un rappel hybride (lexical + sémantique, fusion RRF) sur le titre et injecte les 4 résultats les plus proches via stderr — évite de recréer un chantier ou une doctrine déjà existant.
Nudge de liaison documentaire	Avertissement seul (toujours exit 0) : au moment d'un git commit, croise les fichiers stagés avec les contrats de liaison des chapitres de documentation. Si un fichier sous contrat est modifié, rappelle de vérifier que le chapitre correspondant est encore exact.

ℹ️ Un script de garde supplémentaire existe dans le dépôt mais n'est référencé dans aucune configuration active — il est dormant. Les 8 mécanismes ci-dessus sont les seuls effectivement câblés en PreToolUse Bash.

Matcher Bash — garde-fous supplémentaires (configuration locale, bloquants)

Mécanisme	Effet
Garde écriture en production	BLOQUANT : détecte les commandes shell ciblant un environnement de production client avec un pattern d'écriture destructeur (TRUNCATE, DROP TABLE, DROP DATABASE, DELETE FROM, ALTER TABLE, RENAME TABLE, UPDATE … SET, et les formes d'invocation directe du client SQL) et exige le passage par le script de déploiement sécurisé dédié. Anti-faux-positifs (3 couches) : (1) les commandes ciblant le vaisseau-mère lui-même sont court-circuitées avant le test de production — évite les faux positifs si le nom d'un client apparaît dans une note textuelle ; (2) les commandes ciblant la preprod passent sans contrôle ; (3) les requêtes non destructives (SELECT, SHOW, INSERT standard) ne sont pas ciblées — seuls les 9 patterns destructeurs sont bloquants.
Garde façade email	BLOQUANT : interdit tout usage direct des bibliothèques bas niveau d'envoi ou de lecture d'email (SMTP, IMAP, composition MIME) hors des scripts officiellement whitelistés. La liste blanche couvre le script d'envoi, le script de synchronisation IMAP, le script de lecture directe et le script de boîte secondaire. L'ancien script fantôme (jamais migré) a été retiré de cette liste blanche.
Injection de cicatrices (Bash local)	Non-bloquant (délai max 3 s) : injecte les cicatrices associées à la commande en cours d'exécution.

ℹ️ Évolution de la façade email (2026-06-08) : le script d'envoi officiel envoie automatiquement une copie de validation à l'administrateur à chaque brouillon (--draft), appliquant en pratique la doctrine « montrer avant d'envoyer ». Le mode --send appende automatiquement la signature HTML canonique avant l'envoi SMTP. Le mode --markdown convertit le corps Markdown en HTML email-compatible. Au moment de la rédaction du brouillon, le ton attendu pour le destinataire est affiché (best-effort, non-bloquant). Un nouveau mode --validate --draft-id <N> permet de renvoyer la copie de validation d'un brouillon existant sans en créer un nouveau.

Matcher Edit|Write — moteur de réflexes (configuration versionnée)

Mécanisme

Effet

Moteur de réflexes décentralisés

Lit l'événement hook entrant, charge les règles actives depuis la table de réflexes, prend une décision (deny / warn / allow) et trace l'audit. Gestion fail-closed ciblée : si la base primaire est injoignable, bloque uniquement les zones sensibles du cœur de l'application ; hors zone sensible, laisse passer. Un bug du moteur lui-même produit un exit 0 avec message d'erreur — il ne bloque jamais le travail en cas de défaillance de la façade.

Matcher Edit|Write — configuration locale

Mécanisme	Effet
Injection de cicatrices (édition locale)	Même script que pour Bash local : injecte les cicatrices liées au fichier en cours d'édition.

ℹ️ Pour un même événement Edit|Write, les deux hooks s'exécutent cumulativement : le moteur de réflexes (versionné, décisions depuis la base) puis l'injection de cicatrices (local).

Matcher Agent : réacteur d'agent (versionné) + injection de cicatrices spécifique agent (local).

Matcher Skill : pré-invocation non-bloquante (délai max 5 s, toujours exit 0) — suggère la vue allégée de la fiche compétence si sa taille dépasse un seuil configuré.

4.5 PostToolUse (configuration versionnée sauf mention)

• Bash : journal de réaction + déploiement preprod post-commit (délai max 10 s). Le hook mappe les chemins modifiés vers le site impacté et déclenche un déploiement automatique après chaque commit. Nuance importante : pour les tenants, il s'agit d'un déploiement vers la preprod ; pour le vaisseau-mère lui-même, il n'existe pas d'environnement preprod — ./deploy reconstruit directement le site live. Le terme « preprod » dans le nom du hook est donc trompeur pour ce cas. Skips : le déploiement est ignoré si le message de commit contient [skip-deploy] ou [no-deploy], s'il commence par wip:, si le commit ne touche que de la documentation (aucun fichier runtime), ou si le répertoire de travail est sale après le commit.
• Agent : réacteur d'agent + journal de réaction + télémétrie agent (délai max 5 s).
• Edit|Write|MultiEdit|NotebookEdit : suivi des éditions de la session (délai max 3 s) — écrit la liste des fichiers modifiés, base du hook Stop session-aware.
• Tous outils (Bash, Read, Write, Edit, MultiEdit, NotebookEdit, Glob, Grep, Skill, Agent, Task) : événement cockpit CLI (délai max 10 s) — reflète l'activité de la session vers le tableau de bord du chantier en cours. No-op conditionnel : si le cockpit CLI est désactivé ou si aucun chantier actif n'est détecté, sortie immédiate sans coût. Non-bloquant : exit 0 garanti même en cas de défaillance de la base — un événement raté ne doit jamais bloquer un appel d'outil.
• Tous outils (configuration locale) : comptage de tokens et suivi de la fenêtre de contexte (délai max 5 s).

4.6 Stop (configuration versionnée) — ordre d'exécution

À la fin de chaque session, cinq mécanismes s'enchaînent dans l'ordre suivant :

1. Signal de fin au cockpit (délai max 9 s) — no-op par défaut ; si le mode beat est activé et qu'un chantier est lié, émet un fragment de fin de tour dans la chronologie du cockpit.
2. Libération du verrou de chantier (délai max 3 s) — relâche le verrou exclusif pris par la session sur le chantier actif.
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 »…) ; liste alors les commits de correctifs depuis l'origine via stderr et sort avec exit 2.
4. Avertissement non-commité (délai max 5 s) — BLOQUANT : refuse la fermeture de session si des fichiers modifiés au cours de cette session ne sont pas commités, forçant un commit en flux.
5. Synchronisation du chantier (délai max 8 s) — rappelle la synchronisation entre l'état du chantier local et la base de données du hub.

Mécaniques clés du garde non-commité

• Session-aware : filtre le statut git sur la liste des fichiers modifiés par cette session — plusieurs sessions Claude parallèles ne se bloquent pas mutuellement.
• Anti-boucle : si le hook est déjà actif (deuxième passe), bascule en avertissement non-bloquant au lieu d'un blocage dur.
• Sortie anticipée pour les workers : si la session est un sous-agent spawné par le moteur de tâches, le hook sort silencieusement sans bloquer — le worker gère son propre cycle de commit.
• Exclusion du fichier de configuration locale — le hook peut l'avoir modifié lui-même ; il n'est pas pris en compte dans le contrôle.

4.7 Convention de contexte worker

Une bibliothèque shell partagée, unique sous le répertoire des scripts utilitaires, est sourcée par les quatre hooks Stop. Elle implémente une règle uniforme : si la variable d'environnement SY_WORKER_CONTEXT indique qu'il s'agit d'un sous-agent spawné par le moteur de tâches, les hooks de session utilisateur (commit en flux, cicatrices de clôture, verrou de chantier, synchronisation) sortent immédiatement sans action.

Règle générale : un sous-claude spawné par le worker ne déclenche pas les hooks de session utilisateur. Le worker gère son propre cycle de vie de manière autonome.

Permissions & environnement d'exécution

Configuration principale

Le fichier de configuration principal définit deux paramètres structurants :

• Un bloc env qui active ou désactive des fonctionnalités expérimentales de l'agent (mode équipe, rendu sans scintillement).
• Un bloc permissions avec defaultMode: auto : l'agent s'exécute sans invite de confirmation par défaut, en cohérence avec la doctrine d'autonomie des déploiements pilotés par l'IA.

Configuration locale et politique d'accès

Un second fichier de configuration, local et non versionné, affine la politique d'autorisation :

• Liste d'autorisation : plusieurs centaines d'outils et de commandes sont pré-approuvés, sans liste de refus explicite.
• Variables d'environnement : aucune valeur sensible n'est déclarée à ce niveau ; le bloc est vide.
• Politique d'accès déclarative : un bloc structuré en langage naturel décrit les règles appliquées aux environnements d'un client de référence :
  • Autorisé : lecture seule sur la base de staging du client concerné.
  • Refus souple : toute écriture sur l'environnement de production du même client nécessite une confirmation explicite à chaque opération.
  • Rappel de contexte : les deux VPS du client (production et staging) sont clairement distingués pour éviter toute confusion.

Cette politique déclarative est doublée par un garde-fou exécutable (voir la section sur la protection des écritures en production) : la règle exprimée en configuration et le hook bloquant forment ensemble une défense en profondeur.

Protection contre les fuites de secrets

Aucun secret n'apparaît en clair dans les hooks, compétences ou agents. Les identifiants de messagerie (accès entrant et sortant) sont référencés uniquement par leur nom de variable dans un fichier d'environnement local exclu du contrôle de version. Deux mécanismes complémentaires assurent la détection :

• Un hook de pré-commit qui inspecte les transcriptions avant tout enregistrement.
• Une compétence de scan des pièces jointes, qui filtre également les contenus malveillants entrants.

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

Le tableau ci-dessous récapitule les principaux composants de stockage du système, en indiquant pour chacun quel mécanisme le produit et quel mécanisme le consomme.

Les noms techniques des tables et schémas sont des identifiants internes. Seuls les rôles fonctionnels sont décrits ici.

Composant (rôle fonctionnel)	Producteur	Consommateur
Registre 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 fiches agents → fichiers de configuration agents
Registre des chantiers et travaux	Compétence de gestion de chantier, entité métier associée	Hooks de synchronisation et de verrouillage des chantiers
Journal des cicatrices	Compétence de victoire, hook de clôture	Compétence de rappel, injection au démarrage de session et avant chaque outil
Rapports d'audit quotidien	Tâche planifiée d'audit	Script de briefing de session (chargé au démarrage)
Index des compétences (taille en octets)	Processus d'indexation des compétences	Hook de pré-invocation des compétences
Historique de dérive des personas	Compétence d'audit des personas	Revue manuelle de la dérive
Espace de brainstorming	Compétence d'idéation	Cadran de brainstorming du hub
File de messages entrants	Façade de réception des courriels	Compétence de gestion de la boîte de réception
Journal des transactions bancaires	Importateur de relevés bancaires	Compétence de suivi financier

Note d'architecture : le registre des agents repose sur deux objets distincts en base — une table de base (source d'autorité, modifiable) et une vue en lecture seule construite sur cette table. Le script de régénération lit la vue ; la compétence de rafraîchissement écrit dans la table. Ces deux objets sont parfaitement cohérents et ne présentent aucun risque de divergence : il n'existe pas deux tables concurrentes.