Framework d'organisations hiérarchiques récursives d'agents IA.
Donnez un objectif en langage naturel à une session Claude Code racine : elle décompose récursivement le travail en créant sa propre organisation d'instances spécialisées (façon entreprise), chacune persistée sous forme de fichiers markdown, jusqu'à livraison d'un résultat compilé et auditable — le tout tracé dans Git.
Un holon (Arthur Koestler) est une entité à la fois tout et partie d'un tout plus grand : chaque instance est une mini-organisation complète (mission, mémoire, éventuels subordonnés) tout en étant un rouage de l'organisation de son parent.
Aucun code à écrire ni à maintenir : le framework est un ensemble de fichiers markdown normatifs que les sessions Claude Code lisent et appliquent elles-mêmes. Choisissez un preset, écrivez votre objectif, lancez une commande.
Voir framework/BOOTSTRAP.md — Étape 0 : Node.js et Claude Code installés, identité Git, allowlist des instances (framework/claude/instance-settings.json) élargie si vos missions exécutent d'autres outils que git, python3, node et npm. Ni confiance préalable du dossier ni .claude/settings.json ne sont nécessaires : le lanceur porte les règles d'autorisation de chaque session.
Deux façons de faire : le dialogue guidé (node tools/holon-init/holon-init.js — six questions
en français ordinaire, aucun vocabulaire du framework requis), ou l'édition manuelle ci-dessous.
cp framework/presets/solo-light.md framework/CONFIG.md # ou team-standard.md
# éditer framework/CONFIG.md : remplacer <nom de la mission>
echo "Votre objectif ici." > mission/OBJECTIVE.md| Preset | Usage |
|---|---|
solo-light |
Test, petite à moyenne tâche — décomposition minimale, garde-fous serrés |
team-standard |
Projet moyen — décomposition assumée, coordination par dépendances |
GIT_AUTHOR_NAME="HOLON" GIT_AUTHOR_EMAIL="holon@localhost" \
GIT_COMMITTER_NAME="HOLON" GIT_COMMITTER_EMAIL="holon@localhost" \
node framework/bin/holon-spawn.js --bootstrapLa racine valide la configuration, s'incarne, décompose (ou non) le travail, supervise, livre dans mission/shared/, et rend un rapport final. Le lanceur applique à chaque session les options Claude Code adaptées (modèle et effort par profil, contexte fixe réduit et mis en cache, plafonds de tours, de dépense et de contexte, garde-fous mécaniques) et consigne le coût réel de chaque session dans mission/registry/SESSIONS.md — détail dans docs/holon.md §16. --dry-run affiche la commande résolue sans rien lancer.
framework/ ← le produit : invariant pendant une mission (KERNEL, modules, presets, templates, BOOTSTRAP)
mission/ ← l'espace de travail : généré et vivant (OBJECTIVE, registry, shared, graveyard, instances)
docs/ ← spécification complète, historique de conception, exemples figés (docs/examples/)
tools/ ← outils optionnels vivant hors du KERNEL (ex. external-orchestrator, §14 feuille de route v2)
Aucune instance n'écrit jamais dans framework/ ; toute écriture a lieu dans mission/. Le comportement du noyau (KERNEL.md) est invariant ; tout le reste (orchestration, synchronisation, mémoire, récursion, conflits, registre) est un module interchangeable déclaré dans CONFIG.md.
v1 — noyau, 11 modules, 2 presets, bootstrap. Testé : validation de configuration invalide (T1) et mission réelle bout-en-bout (T3 — docs/examples/t3-csvjson-mission/ en contient la trace complète, du CONFIG.md au rapport final). Spécification complète et journal des décisions dans docs/holon.md.
v1.1 (2026-09-02) — harnais d'exécution : lanceur framework/bin/holon-spawn.js (modèle et effort par profil, contexte fixe −41 % mesuré, plafonds de tours/dépense/contexte, coût réel par session dans mission/registry/SESSIONS.md), trois garde-fous mécaniques (framework/hooks/), module context-budget désormais mesuré et actif par défaut. Motivation et mesures : docs/holon.md §15 (décisions 7-8) et §16.
v2, premiers pas — reprise après crash et budget épuisé désormais testés (T4, T6, avec réserve méthodologique assumée — docs/examples/t4-crash-recovery/, docs/examples/t6-budget-exhausted/) ; parallélisme réel démontré via un orchestrateur externe (tools/external-orchestrator/, ~33% de gain mesuré — docs/examples/external-orchestrator-demo/) ; nouveau module context-budget (garde-fou de contexte intra-session). Détail : docs/holon.md §13-14.
Ajouter un module = ajouter un fichier, zéro modification du noyau. Voir CONTRIBUTING.md.
Le besoin a été défini via une session de conception sur OpenRouter avec Fable 5 : 1,53 $. L'implémentation qui a suivi (ce dépôt, en session interactive Claude Code) a coûté nettement plus de tokens — d'après /cost, 67 % de l'usage de cette session s'est fait avec plus de 150k tokens de contexte : une session longue, avec beaucoup de contexte accumulé (relectures de fichiers, sorties d'outils, exécutions récursives de bootstrap) plutôt qu'un enchaînement de conversations courtes.
Voir LICENSE.