Monorepo + multi-projet — un espace de travail, plusieurs stores brainclaw

Un seul dépôt est le cas simple. Le cas intéressant — et celui dans lequel la plupart des utilisateurs d’agents vivent réellement — est un espace de travail où plusieurs projets doivent communiquer. Il peut s’agir d’un monorepo avec frontend/ + backend/ + worker/, chacun gérant son cycle de vie. Il peut aussi s’agir de deux dépôts frères (my-app + my-app-cms) partageant un contexte. brainclaw gère les deux.

Modèle 1 — Monorepo avec des stores imbriqués

Vous disposez d’un dépôt de niveau supérieur contenant plusieurs projets exploitables. Chacun possède son propre store brainclaw, et un store parent à la racine de l’espace de travail coordonne les opérations entre eux.

my-monorepo/
├── .brainclaw/                # store de l'espace de travail (parent)
├── apps/
│   ├── web/
│   │   ├── .brainclaw/        # store enfant
│   │   └── package.json
│   └── api/
│       ├── .brainclaw/        # store enfant
│       └── package.json
└── packages/
    └── shared/
        ├── .brainclaw/        # store enfant
        └── package.json

cd my-monorepo
brainclaw init                  # racine de l'espace de travail
brainclaw init --cwd apps/web   # store enfant pour le frontend
brainclaw init --cwd apps/api   # store enfant pour le backend

La racine de l’espace de travail voit tous les stores enfants via sa chaîne de stores. Depuis la racine : bclaw_context kind=board affiche les plans / les claims / les handoffs pour chaque enfant. Depuis un enfant : le même appel affiche uniquement l’état de cet enfant. Même grammaire canonique, portée différente.

Basculer le projet actif depuis n’importe où dans l’espace de travail :

brainclaw --project=web list-plans       # liste les plans dans apps/web/
bclaw_coordinate intent=assign \
  targetAgents=[codex] \
  project=api \
  task="Add JWT verify middleware"

L’agent effectuant le dispatch n’a pas besoin de cd dans apps/api/ — l’argument project dirige l’appel là-bas. C’est le modèle qui permet de maintenir votre shell ancré à la racine de l’espace de travail tout en orchestrant le travail à travers les projets enfants.

Modèle 2 — Dépôts frères liés ensemble

Vous disposez de deux (ou trois) dépôts Git séparés qui partagent un contexte : par exemple, my-app et my-app-marketing-site. Ils vivent dans des répertoires différents, mais vous souhaitez qu’un piège capturé sur l’un soit interrogeable depuis l’autre, ou qu’un travail soit dispatché vers le projet de site depuis la session du projet d’application.

~/code/
├── my-app/
│   ├── .brainclaw/            # store autonome
│   └── package.json
└── my-app-marketing-site/
    ├── .brainclaw/            # store autonome
    └── package.json

# Depuis my-app, lier le projet frère
cd ~/code/my-app
brainclaw link add ../my-app-marketing-site

# Vérifier
brainclaw link list
# → my-app-marketing-site  ✓
#       path: ../my-app-marketing-site
#       role: subscriber

# Depuis la session my-app, interroger les pièges du site nativement
bclaw_get entity=trap id=trp#36 project=my-app-marketing-site

# Dispatcher un bref dans la boîte de réception du projet de site
bclaw_coordinate intent=assign \
  targetAgents=[claude-code] \
  project=my-app-marketing-site \
  task="Update the changelog block for v1.5.3"

L’accès inter-projets fonctionne sur tous les verbes de grammaire canonique (bclaw_find/get/create/update/remove/transition), sur bclaw_context, et sur bclaw_coordinate. L’identité est tirée du projet appelant ; les écritures + l’audit atterrissent dans la cible. Les noms de projets inconnus provoquent une erreur — pas de retour en arrière silencieux.

L’interface de ligne de commande expose la même fonctionnalité qu’un flag global --project <name>, mutuellement exclusif avec --cwd :

brainclaw --project=my-app-marketing-site list-plans
brainclaw --project=my-app-marketing-site decision "Drop /pricing route"

Quand choisir quoi

Situation	Modèle
Un dépôt, plusieurs packages de niveau supérieur, configuration racine partagée	Monorepo + stores imbriqués — la racine de l’espace de travail voit tout via la chaîne de stores.
Deux dépôts ou plus séparés qui doivent partager des pièges / des décisions / un contexte	Dépôts frères + cross_project_links — brainclaw link add depuis chaque côté qui a besoin du lien.
Mix : un espace de travail racine ET un dépôt frère ailleurs	Les deux modèles se composent — la chaîne de stores de l’espace de travail gère les enfants, et cross_project_links gère le frère. L’argument project résout à travers les deux de manière transparente.

Le dispatch inter-projets est limité à la boîte de réception

Lorsque vous effectuez un dispatch avec project=<name>, brainclaw désactive de force l’auto-spawn et émet un avertissement. L’agent cible récupère le bref de manière asynchrone via son propre bclaw_work la prochaine fois qu’il s’exécute. Raison : les sémantiques de spawn cwd / worktree sont liées au dépôt git cible — un auto-spawn depuis le processus source atterrirait dans le mauvais répertoire de travail. La récupération asynchrone maintient la cohérence du cycle de vie et correspond à la manière dont la v1.5.3 a intentionnellement limité la Phase 1.

Ce qui n’est PAS encore pris en charge

• La fédération inter-machines — chaque projet dans une configuration cross_project_links doit être atteignable via un chemin local. La synchronisation inter-machines (Pull-and-Materialize via le transport brainclaw-cloud) est prévue dans la feuille de route en tant que Phase 1 de fédération (pln#365 / EPIC pln#499), et n’est pas encore livrée.
• L’auto-spawn inter-projets — voir ci-dessus. La Phase 1b-β reste une optimisation en cours.

Pour le quotidien : orchestrez un ou plusieurs projets sur la même machine, le tout depuis la même session, sans jongler avec cd. C’est le modèle.