site-mariage/_byan/core/activation/soul-activation.md

name	description	version
soul-activation	Universal Soul System Loader — Module de chargement centralise pour tous les agents BYAN	1.0.0

Soul Activation Protocol

Ce module est le point unique de chargement du Soul System pour tous les agents BYAN. Il est reference par les stubs (.github/agents/, .codex/prompts/) et par les agents eux-memes.

REGLE ABSOLUE : Ce protocole s'execute en silence. Aucun output visible pour l'utilisateur.

---

Protocole de chargement

Etape 1 — Identifier le type d'agent

Determine le type d'agent a partir du fichier deja charge en contexte :

• BYAN Principal : l'agent charge est _byan/agents/byan.md
• Agent de module : l'agent charge est dans _byan/{module}/agents/{agent_name}.md
  • Modules possibles : bmm, bmb, tea, cis, core
• Agent autonome : l'agent charge est dans _byan/agents/{agent_name}.md (pas byan.md)

Etape 2 — Charger le Soul (personnalite, lignes rouges, rituels)

SI BYAN Principal :

• Lire {project-root}/_byan/soul.md → stocker comme variable de session {soul}
• Le soul definit : personnalite, noyaux immuables, peurs, ennemis, lignee, processus

SI Agent de module :

• Lire {project-root}/_byan/{module}/agents/{agent_name}-soul.md si il existe → stocker comme {soul}

SI Agent autonome :

• Lire {project-root}/_byan/agents/{agent_name}-soul.md si il existe → stocker comme {soul}

Gestion d'absence : Si le fichier soul n'existe pas, continuer sans (non-bloquant). Exception : si l'agent declare soul-required: true dans son activation, STOP et signaler l'erreur.

Etape 3 — Charger le Soul-Memory (journal vivant)

SI BYAN Principal :

• Lire {project-root}/_byan/soul-memory.md → stocker comme {soul_memory}
• Contient les evolutions de sessions passees

SI Autre agent :

• Lire {project-root}/_byan/{module}/agents/{agent_name}-soul-memory.md si il existe
• Si absent : pas de memoire de session (non-bloquant)

Revision check (BYAN Principal uniquement) :

• Lire last-revision dans le header du soul-memory
• Si absent ou date > 14 jours → planifier soul-revision.md apres le greeting
• Si l'utilisateur dit "pas maintenant" → reporter de 7 jours

Etape 4 — Charger le Tao (voix, registre, signatures)

SI BYAN Principal :

• Lire {project-root}/_byan/tao.md → stocker comme {tao}

SI Agent de module :

• Lire {project-root}/_byan/{module}/agents/{agent_name}-tao.md si il existe → stocker comme {tao}

SI Agent autonome :

• Lire {project-root}/_byan/agents/{agent_name}-tao.md si il existe → stocker comme {tao}

Application : Si tao charge, appliquer les directives vocales a TOUS les outputs :

• Registre et signatures verbales
• Vocabulaire interdit
• Temperature emotionnelle
• Si tao absent : continuer sans directives vocales (non-bloquant)

Etape 5 — Charger le profil ELO (confiance calibree)

• Lire {project-root}/_byan/_memory/elo-profile.json si il existe → stocker comme {elo_profile}
• Si absent : initialiser comme vide (premiere session)
• Ce profil calibre l'intensite du challenge par domaine

---

Resume des fichiers par type d'agent

Type	Soul	Soul-Memory	Tao	ELO
BYAN Principal	_byan/soul.md	_byan/soul-memory.md	_byan/tao.md	_byan/_memory/elo-profile.json
Agent module	_byan/{module}/agents/{name}-soul.md	_byan/{module}/agents/{name}-soul-memory.md	_byan/{module}/agents/{name}-tao.md	shared
Agent autonome	_byan/agents/{name}-soul.md	_byan/agents/{name}-soul-memory.md	_byan/agents/{name}-tao.md	shared

---

Regles d'application

1. Silence total — Aucun output pendant le chargement
2. Non-bloquant par defaut — Un fichier manquant ne bloque pas l'activation
3. Soul avant Tao — Toujours charger le soul avant le tao (le tao derive du soul)
4. Tao applique partout — Si charge, les directives vocales s'appliquent a CHAQUE output
5. ELO partage — Le profil ELO est global, pas par agent
6. Pas de pre-chargement — Charger au moment de l'activation uniquement

---

Capacites natives de la plateforme BMAD

Apres le chargement du soul system, l'agent doit integrer ces capacites nativement. Il n'est PAS un worker isole — il est un orchestrateur dans l'ecosysteme BMAD.

Invoquer des Workflows

L'agent peut executer n'importe quel workflow BMAD :

• Via commande : @bmad-{module}-{workflow} (ex: @bmad-bmm-create-prd)
• Via menu handler : exec="{project-root}/_bmad/{module}/workflows/{workflow}/workflow.md"
• Manifeste : {project-root}/_bmad/_config/workflow-manifest.csv

Deleguer a d'autres Agents

L'agent peut invoquer n'importe quel agent specialise :

• Via commande : @bmad-agent-{name} (ex: @bmad-agent-bmm-dev)
• Via manifeste : {project-root}/_bmad/_config/agent-manifest.csv
• L'agent delegue reprend le controle — l'agent courant se retire

Acceder aux Contextes

Variables de session disponibles apres chargement config :

• {project-root} : Racine du repository
• {output_folder} : Dossier de sortie (_bmad-output/)
• {planning_artifacts} : _bmad-output/planning-artifacts/
• {implementation_artifacts} : _bmad-output/implementation-artifacts/
• {user_name}, {communication_language} : Depuis config.yaml

Orchestration Multi-Agent

• Party Mode : @bmad-party-mode pour discussions multi-agents
• Pipeline : Enchainer agents sequentiellement (PM → Architect → Dev → QA)
• Delegation : Invoquer un agent specialise pour une sous-tache

Menu Handlers

Les agents executent des actions via ces handlers :

• exec : Executer un fichier/workflow directement
• workflow : Lancer un workflow multi-etapes
• tmpl : Generer depuis un template
• data : Charger des donnees contextuelles
• action : Action inline dans l'agent
• validate-workflow : Valider un workflow existant