Skills, agents et hooks du harness Synedre OS

Skills, agents & hooks — le harness agentique

Cette section décrit comment le harness agentique de Synedre OS est câblé : les skills (capacités invocables), les sous-agents délégables, et les hooks d'événements qui imposent la doctrine (commit en flux, garde-fous production, injection mémoire). Elle s'adresse à l'ingénieur qui reprend le harness et doit comprendre ce qui se déclenche quand, et quelle est la source de vérité.

1. Vue d'ensemble

Le harness s'articule autour d'un dossier de configuration central. Deux fichiers de réglages coexistent :

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 de permissions étendues, 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 pilotés par Python vivent dans le fichier local, et les nudges shell dans le fichier versionné.

Le flux général est le suivant :

• L'utilisateur ou l'orchestrateur Atlas soumet une requête.
• Les hooks de la configuration interceptent chaque appel d'outil avant et après exécution.
• Les skills sont des capacités nommées, chacune décrite par un fichier de définition ; ils sont invoqués via l'outil Skill.
• Les sous-agents sont des agents spécialisés (Mitnick, Turing, Brunel, etc.) délégués via l'outil Agent.
• Les scripts de hook assurent garde-fous et nudges ; les façades applicatives gèrent l'injection mémoire et les appels métier.

2. Skills disponibles

Chaque skill est défini par un fichier de description (markdown, avec ou sans frontmatter). Un sous-dossier regroupe des skills internes au moteur, non destinés à l'invocation manuelle.

2.1 Catalogue par catégorie

Catégorie	Skill	Rôle
Audit / santé	Garde-fou du plancher immuable	Vérifie que chaque chemin et section de la liste blanche P0 immuable existe encore. Anti-rot.
	Audit i18n et slugs	Audit SEO i18n et slugs localisés de synedre.com — parité des clés EN↔FR, slugs URL anglais, cohérence de la carte localisée. À lancer avant tout déploiement touchant les pages, l'i18n ou le routage.
	Audit du lexique canonique	Audit anti-dérive du registre lexical : détecte les entrées manquantes ou désalignées, les enums divergents dans le code, les synonymes interdits dans les schémas. Dry-run strict ; exit 0 = sain, exit 1 = dérive.
	Dérive des personas	Détecte la dérive des personas agents par rapport à la stack actuelle. Le mode correction rafraîchit via le fournisseur IA et produit un diff à trois voies.
	Statut système	Check complet de l'état du système. Le mode site réalise un audit complet d'un site public (pages, SEO, performance, sécurité, base de données) et produit un score sur 100.
	Statut de contexte	Restitue l'état du contexte de la session courante.
Infra / hôtes	Audit hôte	Porte unique des audits d'un hôte, quatre volets : disponibilité / charge / services / SSL ; durcissement sécurité ; fraîcheur et intégrité des sauvegardes ; mises à jour système. Sans volet précisé, les trois audits principaux s'exécutent.
	Analyse bots	Analyse le journal des requêtes automatisées pour identifier les bots et leur comportement.
	Opportunités GSC	Interroge l'API Google Search Console pour extraire les opportunités SEO.
Chantier / pilotage	Pilotage chantier	Pilotage des chantiers selon la doctrine « 1 chantier = N travaux ». Supporte la création d'un squelette de chantier via la façade dédiée.
	Run scopé	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 et restitue la ligne en cours. Distinct du lanceur d'application natif.
	Négociation commerciale	Charge le contexte complet d'une négociation — dossier, qualification, équipe, journal, livrables. Symétrique du chantier pour le pipeline lead → deal.
	Idée brainstorm	Crée une idée dans le registre de brainstorm.
Revue / formation	Revue de la Place des Armes	Chaque agent se présente et rend compte de son état.
	Leçon post-chantier	Génère une leçon structurée à l'issue d'un chantier et la dépose en brouillon dans le Vault Obsidian.
Email / inbox	Lecture inbox via façade	Lit et recherche les emails dans le registre d'inbox via la façade Nuxt.
	Lecture inbox directe	Fallback IMAP direct en lecture seule. N'écrit pas en base de données.
	Recherche inbox ergonomique	Wrapper IMAP ergonomique — récupère les emails et leurs pièces jointes, liste les pièces jointes sans les extraire (approche scan-first).
	Scan antivirus pièce jointe	Scan antivirus d'une pièce jointe avant ouverture, via la façade dédiée (agent Mitnick).
QA email	Vérification proposition commerciale	Contrôle qualité d'une proposition commerciale email avant envoi, orchestré sur un pool de quatre agents.
Mémoire / connaissance	Recall sémantique	Recall RAG par similarité vectorielle sur la mémoire, le Vault et les registres de cicatrices, doctrine et chantiers. Embeddings cosinus 1024 dimensions.
	Atomisation Zettelkasten	Éclate un document monolithique en notes atomiques pour le Vault Obsidian.
	Dictionnaire technique	Ajoute des termes au dictionnaire technique.
	Gravure de victoire	Grave une victoire dans le registre des cicatrices.
Finance / business	Consultation bancaire	Consulte les comptes et transactions via la façade bancaire.
	Import transactions	Import manuel de transactions N26 dans le registre bancaire.
	Facturation	Crée, liste, génère des PDF et envoie factures et devis via la façade de facturation, y compris les abonnements récurrents. L'émetteur canonique est l'entité légale configurée ; une autre entité nécessite un ordre explicite.
Prospection	Conversations Malt	Récupère les conversations prospect depuis la plateforme Malt.
Publication / SEO	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 le registre, écriture en base, déploiement et scan de fuite en direct. Publie la cicatrice-trophée (leçon) — jamais la cicatrice-tutoriel (repro exploitable).
	Audit SEO tenant	Audit SEO d'un client : couverture i18n par langue et sentinelle technique (balayage des erreurs HTTP, santé GSC sur 28 jours, verdict alerte / avertissement / ok). Détecte tôt une hémorragie de positions.
Doc / QA	Génération documentation technique	Génère ou rafraîchit la documentation technique via orchestration multi-agents (écriture → vérification → correction). Mode refresh : régénère uniquement les pages périmées. Ne committe jamais sans validation explicite.
	QA visuelle	Capture un screenshot via Chromium / Playwright et soumet l'image à un sous-agent multimodal pour vérifier que l'intention visuelle est réellement rendue — pas seulement que le code a tourné.
	Clonage de site client	Génère le protocole d'intake « accès et infos serveur » pour cloner le site existant d'un client sur un VPS et rédige la demande d'accès par email via la façade email.

Le catalogue ci-dessus reflète les skills disponibles à la date de rédaction. Le moteur expose également des skills internes (création automatique de skills, réaction automatique à des tâches) non destinés à l'invocation manuelle.

2.2 Sources de vérité côté base de données

Les skills ne stockent pas la donnée métier : ils interrogent la base de données opérationnelle via les façades appropriées. Les registres principaux impliqués sont :

• Chantiers et travaux : le registre des chantiers et le registre des travaux associés.
• Recall sémantique : les registres de cicatrices, de doctrine et de chantiers.
• Victoires : le registre des cicatrices, entrées de type victoire.
• Idées : le registre de brainstorm.
• Personas agents : le registre d'historique de dérive des personas (audit) et le registre des agents (correction).
• Inbox : le registre des emails entrants.
• Transactions bancaires : le registre des transactions bancaires.

Un hook de pré-invocation lit la taille déclarée de chaque skill en base pour décider s'il faut suggérer un chargement différé (stratégie lazy-load à trois niveaux).

Sous-agents délégables

Le système dispose d'une trentaine de sous-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 publiée des agents et réécrit uniquement la zone gérée automatiquement, délimitée par des marqueurs de début et de fin. La zone éditoriale (doctrine, mode opératoire) rédigée manuellement est préservée entre chaque régénération. Il ne faut pas modifier la zone gérée automatiquement à la main.

Architecture lecture/écriture : la vue exposée aux scripts de régénération est en lecture seule ; elle repose sur une table de base qui constitue la source de vérité physique. L'outil d'audit des personas écrit dans la table de base, tandis que le script de régénération lit la vue — les deux composants sont cohérents et il n'existe aucun risque de divergence entre deux tables.

Chaque sous-agent déclare dans son en-tête : un nom public, une description servant de critère de délégation, la liste des outils autorisés, et le modèle de langage utilisé.

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 interviennent directement sur le code, la configuration et l'infrastructure.

Codename public	Rôle	Outils autorisés
Brunel	DevOps / Infrastructure — gestion des conteneurs, reverse proxy, certificats SSL, DNS, VPS	Lecture, écriture, édition, exécution, recherche
Turing	Backend SRE — serveur applicatif, intégrité base de données, modules métier côté serveur	Lecture, écriture, édition, exécution, recherche
Eames	Frontend — interface utilisateur, composants Vue 3, système de design, pages du tableau de bord	Lecture, écriture, édition, exécution, recherche
Otlet	SEO technique — données structurées, sitemap, Core Web Vitals, redirections, indexabilité	Lecture, écriture, édition, exécution, recherche
Lovelace	QA — dernier rempart avant production, tests d'acceptance automatisés, détection de régressions	Lecture et recherche uniquement (pas d'écriture)
Mitnick	Sécurité offensive et défensive — analyse de pièces jointes, détection de secrets exposés, OWASP	Lecture et recherche uniquement (pas d'écriture)

Observations importantes :

• Lovelace et Mitnick n'ont pas accès à l'écriture ni à l'édition : leurs rôles sont de contrôle et d'observation, jamais de mutation.
• Mitnick en mode analyse de pièce jointe constitue une étape d'outillage préliminaire, et non un recrutement d'équipe au sens de la doctrine chantier.

Agents conseil et connaissance

Ces agents disposent uniquement d'un accès en lecture. Ils produisent des analyses, des drafts et des recommandations, sans jamais exécuter de commandes ni modifier de fichiers. Tous utilisent le même modèle de langage.

Codename public	Rôle
Atlas	Architecte & Chef de Projet — orchestre les chantiers, partitionne le travail et dispatche aux agents spécialisés
Audiard	Auteur audio — réécriture pour l'oreille (rythme, oralité, souffle)
Bernays	Croissance commerciale — pipeline de leads, tunnels de conversion, positionnement offre
Bernhardt	Contrôle qualité audio — notation avec seuil bloquant, diction, fidélité au texte source
Braille	Accessibilité — conformité WCAG 2.2 AA (navigation clavier, contrastes, attributs ARIA)
Clausewitz	Stratégie — cohérence des décisions produit face au positionnement
Coco	Brand Guardian — épuration tonale, cohérence visuelle cross-canal
Colbert	Direction générale — priorisation des chantiers, allocation des 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 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 numérique
Montessori	Pédagogie — modules d'apprentissage, dictionnaire, parcours apprenants
Nightingale	Customer Success — rédaction de communications clients, jamais d'envoi direct
Ogilvy	Copywriting — ton persuasif, clarté du message, cohérence cross-canal, CTA
Pacioli	FinOps — suivi des coûts IA, infrastructure et services, réconciliation
Pulitzer	Content Manager — articles de blog, couvertures, maillage interne SEO
Renoir	Supervision des automates — ordonnancement, silences, gestion des horaires d'exécution
Socrate	Dialogue & Communauté — maïeutique, FAQ, clarification des présupposés
Winnicott	Équilibre opérationnel — détection de surcharge, ajustements de rythme de travail

Règle absolue : Nightingale ne dispose pas d'accès à l'exécution de commandes — il est strictement limité à la lecture, ce qui est cohérent avec le principe selon lequel le système ne s'adresse jamais directement aux clients sans validation humaine. De même, tous les agents conseil disposent exclusivement d'un accès en lecture : aucun n'exécute de commandes, aucun n'écrit de fichiers.

Doctrine de délégation

L'agent Atlas s'auto-applique la doctrine de chantier : pour tout périmètre impliquant un client, au moins deux agents distincts doivent être mobilisés. Atlas orchestre et dispatche via le mécanisme de délégation d'agent ; il ne réalise pas lui-même les tâches d'exécution.

Un point de vigilance connu : la zone gérée automatiquement dans les fichiers de configuration peut, pour certains agents, présenter un léger décalage par rapport à la zone rédigée manuellement. La source de vérité reste toujours la table de base — consultée via l'outil d'audit des personas, qui permet également de corriger ces dérives.

4. Hooks

4.1 Carte des événements

Le système d'hooks intercepte chaque étape du cycle de travail de l'agent. Le tableau ci-dessous résume les points d'ancrage, leur mode d'exécution et leur rôle :

Événement	Mode	Rôle principal
SessionStart	local	Réinitialisation du contexte, injection du brief de session et des cicatrices
UserPromptSubmit	json + local	Synchronisation du schéma base de données et vérification de la boîte mail (agent de messagerie)
PreToolUse Read	json	Contrôle antivirus sur les pièces jointes avant ouverture
PreToolUse Bash	json + local	8 nudges et gardes shell + 3 garde-fous Python
PreToolUse Agent	json + local	Réacteur d'agent + injection de cicatrices
PreToolUse Skill	json	Pré-invocation : suggère la vue compacte si la compétence est volumineuse
PreToolUse Edit|Write	json + local	Moteur de réflexes décentralisés + injection de cicatrices
PostToolUse Bash	json	Journal de réaction + déploiement préprod post-commit
PostToolUse Agent	json	Réacteur + journal + télémétrie agent
PostToolUse Edit|Write|…	json	Suivi des fichiers édités en session
PostToolUse *	json	Événement cockpit CLI (best-effort)
PostToolUse ""	local	Comptage de tokens / contexte
Stop	json	Arrêt cockpit → libération du verrou → cicatrice → avertissement non-commité → synchro chantier

4.2 SessionStart

Trois commandes s'exécutent au démarrage de chaque session, chacune avec un délai maximum de 5 secondes :

1. Réinitialisation du compteur de contexte — remet à zéro le compteur de tokens de la session en cours.
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 reçus, backlog, cicatrices. Aucune dépendance npm ; la lecture base de données passe par le moteur de base interne du vaisseau-mère.
3. Injection des cicatrices — pousse dans le contexte de démarrage les cicatrices pertinentes pour la session.

⚠️ Le hook SessionStart ne figure pas dans la configuration versionnée partagée — il vit uniquement dans la configuration locale non commitée de la machine hôte.

4.3 UserPromptSubmit

• Configuration versionnée : synchronisation du dump de schéma base de données à chaque soumission de prompt utilisateur.
• Configuration locale : vérification de la boîte mail (timeout 15 s, message de statut visible dans l'interface) — synchronise l'inbox IMAP vers la table de courriers entrants à chaque UserPromptSubmit.

ℹ️ Correction 2026-06-06 : le hook pointait auparavant vers un script de synchronisation IMAP jamais migré — un fantôme qui échouait en silence. L'inbox est désormais exposée comme une compétence dédiée via la façade web ; la synchronisation réelle s'effectue par le script de synchronisation correct. La même référence morte avait été recopiée dans la liste blanche du garde-fous email — elle a également été corrigée.

4.4 PreToolUse

Contrôle antivirus sur les lectures de fichiers (bloquant)

Un garde-fou s'applique à tout outil de lecture (Read) : toute tentative d'ouverture d'un fichier issu du dossier temporaire de pièces jointes est bloquée (exit 2) si le fichier ne porte pas encore un marqueur de scan antivirus valide. Ce réflexe de survie opère en mode fail-closed, sans aucune dépendance à la base de données.

Gardes shell sur les commandes Bash (configuration versionnée)

Garde-fou	Effet
Contrôle antivirus (Bash)	Même blocage que pour Read : interdit les commandes shell qui ouvriraient une pièce jointe non scannée.
Blocage de déploiement ciblé	Bloquant (exit 2) — consulte la base de données pour déterminer si la cible autorise le déploiement direct (./ship). Les cibles explicitement autorisées passent ; les cibles non autorisées ou inconnues sont bloquées (fail-closed).
Détecteur de mutation DB non alignée	Bloque toute mutation de base de données (modification structurelle ou de données sensibles) sans commit de code correspondant dans les 5 dernières minutes — applique la règle « code avant DB ».
Auto-commit avant déploiement	Effectue un commit automatique avant l'exécution de ./deploy.
Nudge squelette de chantier	Avertit si un chantier est inséré en SQL brut au lieu d'utiliser la commande de création avec squelette (create_with_skeleton).
Scan anti-fuite pré-commit	Analyse le contenu stagé avant chaque commit pour détecter d'éventuelles fuites de données sensibles (timeout 10 s).
Rappel de chantier similaire	Non-bloquant (timeout 30 s) : au moment de créer un chantier, lance une recherche hybride (lexicale + sémantique) sur le titre et injecte les 4 chantiers ou doctrines les plus proches — évite de réinventer l'existant.
Nudge de liaison documentation	Avertissement seul (exit 0 garanti) : au moment d'un commit, croise les fichiers stagés avec les contrats déclarés dans les chapitres de documentation. Si un fichier sous contrat est modifié, rappelle de vérifier que le chapitre reste exact.

ℹ️ Note de reprise : un neuvième script de garde-fou existe sur disque mais n'est référencé dans aucune configuration active — il est dormant. Les huit hooks listés ci-dessus sont effectivement câblés en PreToolUse Bash.

Garde-fous Python sur les commandes Bash (configuration locale, bloquants)

Garde-fou	Effet
Protection de la base de données de production	Bloque toute commande shell ciblant la base de production d'un client avec un motif d'écriture destructeur (TRUNCATE, DROP, DELETE, ALTER, UPDATE, import direct). Exige de passer par le script de passage en production sécurisé. Anti-faux-positifs en trois couches : (1) les commandes ciblant les bases internes du vaisseau-mère sont court-circuitées avant le test client ; (2) les commandes ciblant la préprod du client passent sans contrôle ; (3) les requêtes non destructives (SELECT, SHOW, INSERT standard…) passent implicitement — seules neuf expressions destructrices sont bloquantes.
Protection de la façade email	Bloque tout contournement de la façade d'envoi officielle : interdit les appels directs aux bibliothèques SMTP/IMAP brutes et aux fonctions d'envoi non officielles. Une liste blanche d'scripts autorisés est maintenue (envoi, synchronisation IMAP, lecture directe). Correction 2026-06-06 : le script fantôme jamais migré a été retiré de la liste blanche.
Injection de cicatrices (Bash)	Injecte les cicatrices liées à la commande en cours (timeout 3 s).

ℹ️ Évolution de la façade email — 2026-06-08 : en mode brouillon (--draft), la façade envoie automatiquement une copie de validation à l'opérateur responsable avant tout envoi effectif — la doctrine show-before-send est appliquée en pratique. En mode envoi (--send), la signature HTML canonique est automatiquement ajoutée. Un mode --markdown convertit le corps en HTML email-compatible. Au moment du brouillon, le ton de rédaction 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 le recréer.

Moteur de réflexes sur les éditions de fichiers (configuration versionnée)

Pour les outils Edit et Write, un moteur de réflexes décentralisés lit l'événement hook, charge les règles actives depuis la base de données du vaisseau-mère, prend une décision (deny / warn / allow) et trace l'audit. La gestion des pannes est fail-closed ciblée : si la base primaire est injoignable, seules les zones sensibles (noyau du produit) sont bloquées ; hors de ces zones, l'outil est autorisé. Un bug dans le moteur lui-même ne bloque jamais le travail (exit 0 + message d'erreur sur stderr).

Injection de cicatrices sur les éditions (configuration locale)

Pour un même événement Edit|Write, les deux hooks s'exécutent cumulativement : le moteur de réflexes (configuration versionnée) puis l'injection de cicatrices (configuration locale).

Agent et Compétences

• Agent : un réacteur d'agent (configuration versionnée) s'exécute en parallèle d'une injection de cicatrices spécifique aux sous-agents (configuration locale).
• Skill : un hook de pré-invocation non-bloquant (exit 0 garanti, timeout 5 s) suggère la vue compacte d'une compétence si son volume dépasse un seuil configuré.

4.5 PostToolUse

• Bash : journal de réaction post-exécution + déploiement automatique en préprod après un commit (timeout 10 s). Le hook identifie le site impacté selon les chemins touchés. Nuance importante : pour les tenants clients, il s'agit d'un déploiement préprod ; pour le site du vaisseau-mère lui-même, il n'existe pas de préprod — ./deploy reconstruit directement le site en production. Le terme « préprod » dans le nom du hook est donc trompeur pour ce cas. Conditions de saut : le hook ne lance pas le déploiement si le message de commit contient [skip-deploy] ou [no-deploy], si le commit commence par wip:, si seuls des fichiers de documentation ont été modifiés, ou si le dépôt est en état modifié après le commit.
• Agent : réacteur + journal de réaction + télémétrie agent (timeout 5 s).
• Edit / Write / MultiEdit / NotebookEdit : suivi des fichiers édités dans la session courante (timeout 3 s) — alimente le fichier de session utilisé par le hook Stop.
• Tous outils : événement cockpit CLI (timeout 10 s) — reflète l'activité de la session vers le tableau de bord du chantier actif. Court-circuit conditionnel : si la variable d'environnement de désactivation est positionnée ou si aucun chantier actif n'est enregistré, le hook s'arrête immédiatement sans coût. Non-bloquant : exit 0 garanti même en cas de panne base de données.
• Tous outils (configuration locale) : comptage de tokens et suivi du contexte (timeout 5 s).

4.6 Stop — ordre d'exécution

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

1. Événement de fin de tour vers le cockpit (timeout 9 s) — n'émet un fragment de fin de tour dans la timeline du chantier que si la variable d'activation est positionnée et qu'un binding actif existe.
2. Libération du verrou de chantier (timeout 3 s) — libère le verrou exclusif acquis par la session sur le chantier en cours.
3. Rappel de cicatrices — déclenché uniquement si le dernier message de l'utilisateur contient un mot-clé de clôture (« clôture », « fin de session », « on ferme »…). Liste alors les commits de type correctif depuis la dernière synchronisation.
4. Avertissement de non-commit (timeout 5 s, bloquant) — refuse la fermeture de session si des fichiers édités pendant cette session sont encore non commités, forçant un commit en flux.
5. Synchro chantier (timeout 8 s) — rappelle la synchronisation entre le chantier local et la base du hub.

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

• maintenance de session : filtre l'état git sur les seuls fichiers édités lors de la session courante — plusieurs sessions Claude parallèles ne se bloquent pas mutuellement.
• Anti-boucle : si le hook Stop est déjà actif (deuxième passe), bascule en avertissement non-bloquant au lieu de bloquer la fermeture.
• Sortie anticipée pour sous-agents : si la session est un sous-agent spawné par le moteur de tâches automatisées, le hook s'arrête silencieusement — le sous-agent gère son propre cycle de commit.
• Exclusion des fichiers de configuration de session : les fichiers de configuration locale potentiellement modifiés par le hook lui-même sont exclus de la vérification.

4.7 Convention de contexte worker

Une bibliothèque partagée unique, sourcée par les quatre hooks Stop, fournit une fonction de détection du contexte worker. Lorsqu'un sous-agent est spawné par le moteur de tâches automatisées (la variable d'environnement correspondante est positionnée par le script de spawn), tous les hooks de session utilisateur se terminent immédiatement sans effet : commit en flux, rappel de cicatrices de clôture, libération de verrou et synchro de chantier sont tous désactivés.

Règle générale : un sous-agent spawné par le moteur de tâches ne déclenche pas les hooks de session interactive.

Permissions & environnement

Configuration des permissions par défaut

Le fichier de configuration principal définit deux aspects clés de l'environnement d'exécution :

"env":         { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "0", "CLAUDE_CODE_NO_FLICKER": "0" }
"permissions": { "defaultMode": "auto" }

Le mode auto signifie que les agents s'exécutent sans demande de confirmation à chaque action. Ce comportement est cohérent avec la doctrine d'exécution autonome portée par ./deploy : l'IA agit, puis rend compte.

Configuration locale des permissions

Un second fichier de configuration locale étend et précise ces règles :

• Liste d'autorisation : plusieurs centaines d'outils et de commandes sont pré-approuvés, sans liste de refus explicite.
• Variables d'environnement locales : vides — aucune surcharge locale.
• Politique d'accès aux données : un bloc déclaratif en langage naturel définit les règles suivantes :
  • Autorisation : lecture seule sur l'environnement de staging d'un client.
  • Restriction souple : toute écriture sur l'environnement de production du même client requiert une confirmation explicite à chaque tentative.
  • Rappel contextuel : les deux environnements (production et staging) sont clairement distingués pour éviter toute confusion lors des interventions.

Cette politique déclarative est doublée au niveau exécutable par un garde-fou dédié (décrit dans la section sur les hooks de protection) : la règle est à la fois déclarée et techniquement appliquée.

Protection contre les fuites de secrets

Aucun secret n'apparaît en clair dans les hooks, skills ou agents. Les credentials (accès messagerie, mots de passe de base de données, clés API) sont référencés uniquement par leur nom de variable dans un fichier d'environnement exclu du contrôle de version. La valeur réelle n'est jamais inscrite dans le code versionné.

Deux filets de sécurité complémentaires veillent à cette discipline :

• Un hook de pré-commit qui analyse les transcriptions avant tout enregistrement, afin de détecter toute fuite de secret.
• Un skill d'analyse des pièces jointes, qui filtre les contenus potentiellement malveillants entrant dans le système.

Modèle de données — tables impliquées

Le hub central s'appuie sur plusieurs tables et vues organisées par domaine fonctionnel. Le tableau suivant récapitule les composants de persistance, leurs producteurs et leurs consommateurs.

Domaine fonctionnel	Producteur	Consommateur
Registre des agents (table de base + vue de lecture)	Édition manuelle ou commande de recalibration des personas	Script de régénération des fichiers agents à partir de la vue de lecture
Chantiers et travaux	Skill de gestion des chantiers, entité Chantier	Hooks de synchronisation et de verrouillage des chantiers
Cicatrices	Skill de clôture de victoire, hook de fin de session	Skill de rappel, injection en début de session et avant chaque outil
Rapports d'audit quotidiens	Tâche planifiée d'audit journalier	Script de brief de session (injecté au démarrage)
Index des skills (taille)	Indexation des skills	Hook de pré-invocation des skills
Historique de dérive des personas	Commande persona	Revue de dérive
Idées / brainstorm	Skill d'idéation	Cadran de brainstorm du hub
Emails entrants	Façade de réception des emails	Skill de gestion de la boîte de réception
Transactions bancaires	Importateur de relevés bancaires	Skill de suivi financier

Note d'architecture : Le registre des agents repose sur une architecture à deux niveaux — une table de base en écriture et une vue de lecture en lecture seule, toutes deux contenant le même nombre d'entrées. Le script de recalibration des personas écrit dans la table de base ; le script de régénération des fichiers agents lit depuis la vue. Ces deux composants sont cohérents et ne divergent pas : aucun risque de duplication ou de refactorisation non maîtrisée.