Des actions dans un cadre explicite.

AI-Brain · Execution Engine · 2 / 11

Brancher un atelier fictif

Un dépôt central local et un registre par espace de travail.

# Exemple de registre : projects/atelier-demo/project.yaml
# Le registre décrit l’identité, les alias,
# les assistants choisis et, si besoin, la stack.

# Ressources associées
projects/atelier-demo/CLAUDE.md
projects/atelier-demo/skills.manifest
skills/atelier-demo/
plans/atelier-demo/

• Une seule installation ai-brain est partagée sur la machine.
• Chaque espace branché possède ses instructions et sa sélection de compétences.
• Le registre est la source de vérité du branchement.

AI-Brain · Execution Engine · 3 / 11

Setup : initialiser ou synchroniser

# Depuis la racine de l’atelier fictif
# Premier branchement : identité et assistants explicites
bash ~/.ai-brain/scripts/setup.sh init \
  --project=atelier-demo \
  --tools=claude-code,copilot,codex,mistral

# Atelier déjà déclaré, ou nouvelle machine
bash ~/.ai-brain/scripts/setup.sh update \
  --project=atelier-demo

• init crée les ressources du registre puis synchronise les liens.
• update relit le registre et recrée les ressources locales attendues.
• Les conflits avec des fichiers réels sont à examiner, pas à supprimer aveuglément.

Le bootstrap setup.sh constitue l’entrée d’installation. Une fois branché, l’atelier utilise son interface bin/tools. Ces commandes sont montrées, jamais exécutées par cette page.

AI-Brain · Execution Engine · 4 / 11

Tools : une interface de commandes

Un nom stable pour une opération connue.

bin/tools help
bin/tools capabilities

# Exemples de commandes d’un atelier
bin/tools qa:lint
bin/tools test:run

• Le routeur associe domaine:action à une implémentation et un niveau de capacité.
• L’assistant choisit une opération déclarée plutôt qu’une commande arbitraire.
• Les noms disponibles dépendent du kit et de l’espace de travail : help fait foi.
• Une commande absente se définit avec ses arguments et ses permissions avant utilisation.

qa:lint est ici un nom illustratif, pas une commande garantie dans chaque installation.

AI-Brain · Execution Engine · 5 / 11

Permissions et autorisations

• SAFE : contrôles et opérations locales prévues par le routeur.
• READ ou PROD_READ : inspection des informations autorisées.
• WRITE_REPO : modifications du dépôt telles que commit et push.
• WRITE_PROD : opérations de publication expressément prévues.
• USER_ONLY et FORBIDDEN : opérations réservées à l’utilisateur ou refusées à l’agent.

Le niveau technique ne remplace pas l’autorisation humaine. Les garde-fous techniques doivent appliquer les règles : un fichier Markdown seul ne constitue pas une barrière de sécurité.

AI-Brain · Execution Engine · 6 / 11

Hooks : le garde-fou avant chaque outil

Une règle écrite guide l’assistant ; un hook la fait appliquer.

# Décision pour une commande (exemple fictif)
bin/tools brain:guard-check "ssh serveur-demo"
# deny — commande « ssh » : bin/tools help prod

# Vérifier le branchement dans les assistants du projet
bin/tools brain:guard-hooks --check

• Avant chaque appel d’outil, le hook de l’assistant transmet la commande au même script de garde-fou.
• Les règles refusent ce qui contourne l’interface de commandes ou lit des secrets, et indiquent la commande à utiliser ; bin/tools passe toujours.
• Un projet peut ajouter ses règles, sans jamais lever un refus de base.
• Le setup branche ce garde-fou dans Claude Code, Codex, Copilot et Mistral Vibe, en fusionnant avec les réglages locaux.

Par défaut, le garde-fou fonctionne en mode avertissement : il journalise les refus sans bloquer. Le passage en blocage intervient après relecture de ce journal.

AI-Brain · Execution Engine · 7 / 11

Les plans : garder le fil

Un journal d’implémentation pour les changements non triviaux.

# 001_formulaire-accessible.md — exemple fictif
**Statut** : en cours
**Branche** : feature/formulaire

### [ ] Phase 1 — Clarifier les libellés
Vérif : `bin/tools qa:lint`

### [ ] Phase 2 — Contrôler le parcours clavier
Vérif : `bin/tools test:run`

• Créer le plan avant l’implémentation et avancer phase par phase.
• Cocher les étapes après vérification et laisser une reprise compréhensible.
• Conserver les décisions durables dans la documentation vivante : le plan peut être supprimé.

AI-Brain · Execution Engine · 8 / 11

Les commandes du plan

# Depuis un atelier branché : exemple fictif
bin/tools plan:new formulaire-accessible --dry-run
bin/tools plan:new formulaire-accessible

# Relire l’avancement sans charger tout le journal
bin/tools brain:plan-status 001

# Rejouer les vérifications déclarées pour une phase
bin/tools plan:verify 001 --phase 1

• Le numéro est attribué selon les plans déjà présents : 001 est un exemple.
• plan:verify ne rejoue que les commandes SAFE et READ autorisées.
• Les fichiers durables expliquent les décisions ; les plans retracent leur réalisation.

AI-Brain · Execution Engine · 9 / 11

Synchroniser les branchements

# Depuis un atelier déjà branché
bin/tools brain:setup update
bin/tools brain:links

# Depuis le dépôt central : aperçu des hôtes à resynchroniser
bin/tools fleet:setup --dry-run

• Une modification de la source partagée est visible par ses liens.
• Un changement des assistants ou des compétences exposées demande une resynchronisation.
• Sur une nouvelle machine, rétablir le dépôt central et relancer setup update.
• Vérifier les liens et les exclusions locales avant de conclure.

AI-Brain · Execution Engine · 10 / 11

Du changement à la livraison

• Lire le contexte et délimiter le changement.
• Implémenter la phase prévue par le plan.
• Faire exécuter les contrôles pertinents par le moteur de vérification.
• Demander les autorisations requises avant commit, push ou publication.
• Après publication, vérifier la cible réelle avant de déclarer la livraison réussie.

Aucune publication automatique n’est impliquée par la création d’un plan ou par le passage des tests.

AI-Brain · Explorer la suite

Les moteurs se complètent.

Le contexte oriente l’action, la vérification contrôle son résultat et l’évaluation nourrit les améliorations.

Tous les exemples sont génériques ou fictifs. Aucun projet, client, chemin personnel ou relevé d’usage réel n’est présenté.