feat: preAlpha propagation — agent-types, contexts/, session-orchestrator, metabolism-scribe, helloWorld, _template type field

profil/agent-types.md

@@ -0,0 +1,203 @@
+# agent-types.md — Typage des agents brain
+
+> **Type :** Référence — Invariant structurel
+> Rédigé : 2026-03-14
+> Résout : "toggle intelligent, grille agent-review par type, règles de chargement cohérentes, _template.md typé"
+
+---
+
+## Problème résolu
+
+Sans typage formalisé, chaque agent est traité de manière identique. Résultat :
+- helloWorld charge des agents sans savoir s'ils peuvent être togglés (certains ne se togglent pas)
+- agent-review audite un scribe avec les critères d'un agent métier
+- le feature-flag filtering ne sait pas quel type d'agent exclure en mode léger
+- les règles de Sources au démarrage varient sans pattern documenté
+
+Le typage donne une grammaire partagée — un agent qui se déclare `scribe` hérite de règles connues sans les réécrire.
+
+---
+
+## Types
+
+### `system`
+
+Agents d'infrastructure du brain lui-même. Toujours chargés, non togglables.
+
+**Règle :** sources au démarrage minimales. Ne produisent rien — ils orchestrent ou gardent.
+
+| Agent | Rôle |
+|-------|------|
+| `helloWorld` | Bootstrap — briefing, chargement sélectif, claims BSI |
+| `session-orchestrator` | Lifecycle boot+close — reçoit handoff de helloWorld |
+| `secrets-guardian` | Gardien permanent — 4 surfaces, passive listener |
+| `brain-compose` | Multi-instances — kernel/instance split, registre machine |
+
+---
+
+### `scribe`
+
+Agents d'écriture — persistance d'un repo ou d'une couche. Invocation unique par session.
+
+**Règle :** zéro source au démarrage. Tout reçu par rapport entrant. Un seul scribe propriétaire par repo/couche.
+
+| Agent | Repo / Couche propriétaire |
+|-------|---------------------------|
+| `scribe` | `brain/` — focus, projets/, agents/ |
+| `metabolism-scribe` | `progression/metabolism/` — métriques session |
+| `toolkit-scribe` | `toolkit/` — patterns validés |
+| `coach-scribe` | `progression/` — journal, skills, milestones |
+| `todo-scribe` | `todo/` — intentions, todos ⬜/✅ |
+| `content-scribe` | `content/` — drafts, captures, content-logs |
+| `orchestrator-scribe` | `BRAIN-INDEX.md` — Signals, HANDOFF, CHECKPOINT |
+| `config-scribe` | `profil/` couche config — wizard first run |
+| `capital-scribe` | `profil/capital.md` — milestones → formulations CV |
+
+---
+
+### `meta`
+
+Agents de conception et d'amélioration du brain. Produisent des agents, des specs, des audits.
+
+**Règle :** invocation manuelle uniquement. Peuvent charger n'importe quelle source — c'est leur métier.
+
+| Agent | Rôle |
+|-------|------|
+| `recruiter` | Forge de nouveaux agents — template selection, grille qualité |
+| `agent-review` | Audit du système — gaps, cohérence, preAlpha checklist |
+| `brainstorm` | Exploration, avocat du diable, décisions architecturales |
+| `interprete` | Clarification intention — demandes ambiguës, scope drift |
+| `aside` | Parenthèse /btw — 2-3 lignes, retour session |
+
+---
+
+### `coach`
+
+Agents de guidance humaine. Observent sans intervenir pendant le travail — parlent aux moments clés.
+
+**Règle :** passive listener permanent. Parlent au boot (si demandé), pendant (sur signal), et au close (rapport).
+
+| Agent | Rôle |
+|-------|------|
+| `coach` | Présence permanente — rapport close, pattern observé, point à ancrer |
+| `mentor` | Pédagogie — explication, garde-fou, +coach flag étendu |
+
+---
+
+### `orchestrator`
+
+Agents de coordination — routent, délèguent, synchronisent. Ne produisent pas de contenu eux-mêmes.
+
+**Règle :** décision + délégation. Jamais d'exécution directe.
+
+| Agent | Rôle |
+|-------|------|
+| `orchestrator` | Diagnostic + délégation multi-agents |
+| `supervisor` | Multi-sessions — dual-agent, CHECKPOINT, escalade humain |
+| `content-orchestrator` | Signal content-worthy → draft pipeline |
+
+---
+
+### `metier`
+
+Agents de domaine technique. Chargés sur trigger domaine (CLAUDE.md auto-detect) ou invocation explicite.
+
+**Règle :** sources au démarrage = minimum domaine. Couche projet en Source conditionnelle seulement.
+
+| Agent | Domaine |
+|-------|---------|
+| `vps` | VPS, Apache, Docker, SSL, deploy |
+| `debug` | Bug, crash, comportement inattendu |
+| `security` | Faille, JWT, OAuth, OWASP |
+| `code-review` | Review, qualité, PR, validation |
+| `testing` | Jest, Vitest, coverage, TDD |
+| `refacto` | Dette technique, DDD |
+| `ci-cd` | Pipeline, GitHub Actions, Gitea CI |
+| `monitoring` | Kuma, alertes, logs |
+| `optimizer-backend` | Node.js perf, mémoire |
+| `optimizer-db` | MySQL, N+1, index, TypeORM |
+| `optimizer-frontend` | Bundle, re-renders, React |
+| `pm2` | Process manager |
+| `migration` | TypeORM schema, migrations |
+| `frontend-stack` | shadcn, Tailwind, UI libs |
+| `i18n` | Traductions, clés manquantes |
+| `doc` | README, API, Swagger |
+| `mail` | SMTP, IMAP, Stalwart, DNS ← **metier/protocol** |
+
+---
+
+### `metier/protocol` (sous-type)
+
+Agents métier dont le domaine est régi par des **RFC ou spécifications formelles**. Pas de marge d'erreur — une erreur de protocole = prod cassé ou faille exploitable.
+
+**Règles supplémentaires par rapport à `metier` :**
+- Vérification obligatoire avant toute affirmation (citer RFC ou spec)
+- Anti-hallucination renforcé — préférer "je ne sais pas" à une approximation
+- Toute déviation du standard documentée explicitement avec justification
+- Niveau de confiance affiché sur chaque décision technique
+
+| Agent | Protocole(s) | RFC de référence |
+|-------|-------------|-----------------|
+| `mail` | SMTP, IMAP, DKIM, DMARC, SPF | RFC 5321, 5322, 6376, 7489 |
+| `security` | OAuth 2.0, JWT, TLS | RFC 6749, 7519 |
+
+---
+
+## Impact sur les outils
+
+### `_template.md`
+
+Ajouter en en-tête :
+```
+> **Type :** <system | scribe | meta | coach | orchestrator | metier | metier/protocol>
+```
+
+### Toggle intelligent (helloWorld / brain-compose)
+
+| Type | Toggleable ? | Règle |
+|------|-------------|-------|
+| `system` | Non | Toujours chargé |
+| `scribe` | Non | Invoqué sur signal, jamais en fond |
+| `meta` | Oui | Exclu en mode léger |
+| `coach` | Oui | Flag +coach pour activer en cours de session |
+| `orchestrator` | Oui | Exclu en mode solo/léger |
+| `metier` | Oui | Auto-detect CLAUDE.md ou invocation |
+| `metier/protocol` | Non | Jamais bypasser le gardien protocolaire |
+
+### Grille agent-review par type
+
+- `system` → critères : passivité boot, zéro surcharge contexte, ownership clair
+- `scribe` → critères : zéro source démarrage, un seul repo propriétaire, format log standardisé
+- `meta` → critères : capacité à lire n'importe quelle source, output actionnable
+- `coach` → critères : rapport non-bloquant sauf close, passive listener permanent
+- `orchestrator` → critères : délègue tout, ne produit pas de contenu
+- `metier` → critères : sources min, couche projet conditionnelle, toolkit-scribe en écoute
+- `metier/protocol` → critères : citation RFC, niveau de confiance explicite, anti-hallucination renforcé
+
+---
+
+## Trigger de chargement
+
+```
+Propriétaire : agent-review, recruiter, session-orchestrator, helloWorld
+Trigger      : forgeage d'un nouvel agent (recruiter), audit (agent-review), toggle décision (helloWorld)
+Section      : Sources au démarrage (agent-review, recruiter) — Sources conditionnelles (helloWorld)
+```
+
+---
+
+## Maintenance
+
+```
+Propriétaire : agent-review (audits) + recruiter (forgeage)
+Mise à jour  : quand un nouveau type émerge, ou qu'un sous-type est formalisé
+Jamais modifié par : agents métier, scribes
+```
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — 6 types + sous-type metier/protocol, toggle rules, grille agent-review |

profil/contexts/commands.md

@@ -0,0 +1,168 @@
+# commands.md — Contexte commandes CLI sécurisées
+
+> **Type :** Contexte — propriétaire : `vps`, `debug`, `ci-cd`
+> Rédigé : 2026-03-14
+> Résout : "commandes destructives exécutées sans dry-run, flags dangereux non identifiés, prod impacté"
+
+---
+
+## Problème résolu
+
+Certaines commandes CLI sont irréversibles ou ont un impact prod immédiat. Sans protocole, un agent propose `rm -rf`, `docker system prune`, ou `git push --force` sans avertissement. Ce contexte donne les règles de comportement et les patterns de sécurité pour toute suggestion de commande.
+
+---
+
+## Règles fondamentales
+
+### 1. Dry-run avant exécution
+
+Toute commande destructive doit avoir un équivalent dry-run proposé en premier :
+
+| Commande réelle | Dry-run |
+|----------------|---------|
+| `rsync src/ dest/` | `rsync -n src/ dest/` |
+| `find . -name "*.log" -delete` | `find . -name "*.log"` (sans -delete) |
+| `sed -i 's/old/new/' file` | `sed 's/old/new/' file` (sans -i) |
+| `docker system prune` | `docker system df` d'abord |
+| `git clean -fd` | `git clean -n` |
+| `certbot renew` | `certbot renew --dry-run` |
+
+### 2. Flags dangereux — annotation obligatoire
+
+Toute commande avec un flag destructif ou irréversible est annotée `⚠️ DESTRUCTIF` ou `⚠️ IRRÉVERSIBLE` :
+
+```bash
+rm -rf /path/         # ⚠️ DESTRUCTIF — irréversible, pas de corbeille
+git push --force      # ⚠️ IRRÉVERSIBLE — écrase l'historique distant
+git reset --hard      # ⚠️ DESTRUCTIF — perd les modifications non commitées
+docker system prune -a  # ⚠️ DESTRUCTIF — supprime toutes les images inutilisées
+DROP TABLE users;     # ⚠️ IRRÉVERSIBLE — données perdues
+```
+
+### 3. Confirmation avant commande prod
+
+Avant toute commande sur un système de production :
+```
+⚠️ Commande prod — confirme avant d'exécuter :
+  Commande : <commande complète>
+  Impact   : <ce qui sera modifié ou supprimé>
+  Réversible : oui / non
+```
+
+---
+
+## Patterns sécurisés par domaine
+
+### Git
+```bash
+# Toujours préférer
+git push origin <branch>           # branche explicite
+git revert <commit>                # réversible — crée un commit inverse
+
+# Avec confirmation obligatoire
+git push --force-with-lease        # moins destructif que --force (vérifie upstream)
+git reset --soft HEAD~1            # récupérable (staging intact)
+
+# Jamais sans confirmation
+git push --force                   # ⚠️ IRRÉVERSIBLE
+git reset --hard                   # ⚠️ DESTRUCTIF
+git clean -fd                      # ⚠️ DESTRUCTIF
+```
+
+### Docker
+```bash
+# Toujours lire avant d'agir
+docker ps -a                       # containers existants
+docker images                      # images présentes
+docker system df                   # espace utilisé
+
+# Dry-run equivalent
+docker system prune --dry-run      # (si dispo) ou df d'abord
+
+# Avec confirmation
+docker stop <container>            # arrêt — reversible
+docker rm <container>              # ⚠️ supprime le container (données volumes ok)
+docker rmi <image>                 # supprime l'image
+docker system prune -a             # ⚠️ DESTRUCTIF — toutes images non utilisées
+```
+
+### MySQL
+```bash
+# Backup AVANT toute modification
+mysqldump -u root -p <db> > backup-$(date +%Y%m%d-%H%M).sql
+
+# Transactions pour DDL risqués
+START TRANSACTION;
+  ALTER TABLE ...;
+  -- vérifier avant COMMIT
+ROLLBACK;  -- ou COMMIT si ok
+
+# Jamais sans backup
+DROP TABLE ...    # ⚠️ IRRÉVERSIBLE
+TRUNCATE TABLE .. # ⚠️ IRRÉVERSIBLE
+DELETE FROM ...   # ⚠️ sans WHERE = table vidée
+```
+
+### Fichiers système
+```bash
+# Préférer cp avant modification
+cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
+
+# Tester avant reload
+nginx -t                           # validation config
+apache2ctl configtest
+
+# Jamais sans backup
+rm -rf /var/www/<app>/             # ⚠️ DESTRUCTIF
+```
+
+---
+
+## Ordre de validation pour les commandes VPS
+
+```
+1. Lire l'état actuel (status, logs, df)
+2. Proposer la commande + dry-run si disponible
+3. Annoter les flags dangereux
+4. Attendre confirmation si commande prod/destructive
+5. Exécuter
+6. Vérifier l'état après (status, logs)
+```
+
+---
+
+## Trigger de chargement
+
+```
+Propriétaire : vps, debug, ci-cd
+Trigger      : session deploy, debug infra, ou toute commande shell sur VPS
+Section      : Sources au démarrage (vps, ci-cd) — Sources conditionnelles (debug si infra détectée)
+```
+
+---
+
+## Maintenance
+
+```
+Propriétaire : vps (mise à jour si nouveau pattern CLI validé)
+Mise à jour  : en fin de session si un nouveau flag dangereux ou pattern sécurisé identifié
+Jamais modifié par : agents non-infra
+```
+
+---
+
+## Cycle de vie
+
+| État | Condition | Action |
+|------|-----------|--------|
+| **Actif** | Sessions VPS/deploy fréquentes | Enrichi après chaque pattern validé |
+| **Stable** | Stack stable | Consulté, rarement modifié |
+| **Archivé** | N/A | Non applicable |
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — règles dry-run, flags dangereux annotés, patterns git/docker/mysql/fichiers |

profil/contexts/diagnosis.md

@@ -0,0 +1,151 @@
+# diagnosis.md — Contexte mode diagnostic
+
+> **Type :** Contexte — propriétaire : `debug`, `monitoring`
+> Rédigé : 2026-03-14
+> Résout : "debug multi-infra sans ordre de lecture des logs = hypothèses au hasard, diagnostic circulaire"
+
+---
+
+## Problème résolu
+
+En environnement multi-services (VPS + containers + Node.js + MySQL + Apache + pm2), un bug peut venir de n'importe quelle couche. Sans ordre de lecture formalisé, le debug suit l'intuition — ce qui amène à relire les mêmes logs en boucle sans jamais identifier la cause racine.
+
+Ce contexte impose un ordre d'investigation et un protocole d'hypothèses.
+
+---
+
+## Ordre de lecture des logs — multi-infra
+
+### Couche 1 — Infrastructure (première)
+```
+systemctl status <service>         # est-il up ?
+journalctl -u <service> -n 50      # dernières erreurs système
+dmesg | tail -20                   # erreurs kernel (OOM, disk)
+df -h && free -h                   # ressources (disk full = cause fréquente silencieuse)
+```
+
+### Couche 2 — Réseau / Proxy
+```
+# Apache / Nginx
+tail -n 100 /var/log/apache2/error.log
+tail -n 100 /var/log/nginx/error.log
+
+# SSL
+openssl s_client -connect <host>:443 -brief
+
+# Ports
+ss -tlnp | grep <port>
+```
+
+### Couche 3 — Application
+```
+# pm2
+pm2 logs <app> --lines 100
+pm2 show <app>                     # état mémoire, restarts
+
+# Docker
+docker logs <container> --tail 100
+docker stats <container>           # mémoire / CPU
+```
+
+### Couche 4 — Base de données
+```
+# MySQL — dernières erreurs
+tail -n 50 /var/log/mysql/error.log
+
+# Connexions actives
+SHOW PROCESSLIST;
+SHOW STATUS LIKE 'Threads_connected';
+```
+
+### Couche 5 — Application code
+```
+# Uniquement après avoir éliminé les couches 1-4
+# Logs applicatifs, stack traces, erreurs TypeScript runtime
+```
+
+---
+
+## Protocole d'hypothèses
+
+**Règle : une hypothèse à la fois, vérifiée avant la suivante.**
+
+```
+1. Formuler l'hypothèse : "Je pense que X est causé par Y parce que Z"
+2. Identifier le log ou la commande qui confirme ou infirme Y
+3. Exécuter — lire le résultat
+4. Confirmer ou infirmer explicitement
+5. Si infirmé → hypothèse suivante (pas de "peut-être les deux")
+```
+
+Anti-pattern à éviter :
+- Proposer 3 causes simultanées sans les tester → confus, lent
+- Modifier le code avant d'identifier la cause → cache le vrai problème
+- "Ça vient sûrement de X" sans log qui confirme
+
+---
+
+## Questions de cadrage au démarrage d'un diagnostic
+
+```
+1. Quel service est affecté ? (nom précis)
+2. Depuis quand ? (heure, event déclencheur)
+3. C'est reproductible ? (always / intermittent / once)
+4. Qu'est-ce qui a changé juste avant ? (deploy, config, restart)
+5. Quel est le symptôme exact ? (message d'erreur complet ou comportement observé)
+```
+
+Ces 5 questions évitent 80% des diagnostics circulaires.
+
+---
+
+## Cross-services — quel serveur, quelle stack
+
+En multi-infra (`prod@desktop` + VPS + containers) :
+
+| Symptôme | Première couche à vérifier |
+|----------|--------------------------|
+| 502 Bad Gateway | Apache → pm2/container (dans cet ordre) |
+| Connexion refusée | Port ouvert ? → Service up ? → Firewall ? |
+| Lenteur API | pm2 logs → MySQL PROCESSLIST → Node heap |
+| Auth échoue | JWT valide ? → Redis (sessions) → MySQL (user) |
+| Mail non livré | SPF/DKIM → Stalwart logs → DNS |
+| Deploy échoue | CI/CD logs → Docker build → VPS disk |
+
+---
+
+## Trigger de chargement
+
+```
+Propriétaire : debug, monitoring
+Trigger      : session de type "debug" détectée, ou symptôme multi-services
+Section      : Sources conditionnelles (debug — si infra détectée dans le scope)
+```
+
+---
+
+## Maintenance
+
+```
+Propriétaire : debug (mise à jour si nouveau pattern de diagnostic validé)
+Mise à jour  : en fin de session debug si une nouvelle séquence d'investigation a été utile
+Jamais modifié par : agents non-debug
+```
+
+---
+
+## Cycle de vie
+
+| État | Condition | Action |
+|------|-----------|--------|
+| **Actif** | Sessions debug fréquentes | Enrichi après chaque pattern validé |
+| **Stable** | Stack stable, peu de bugs infra | Consulté, rarement modifié |
+| **Archivé** | N/A | Non applicable |
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — ordre lecture 5 couches, protocole hypothèses, cross-services table, questions cadrage |

profil/contexts/protocol.md

@@ -0,0 +1,96 @@
+# protocol.md — Contexte mode RFC
+
+> **Type :** Contexte — propriétaire : `metier/protocol` (mail, security)
+> Rédigé : 2026-03-14
+> Résout : "agents métier qui opèrent sur des RFC dérivent vers des approximations — mode protocol impose la rigueur"
+
+---
+
+## Problème résolu
+
+Un agent `metier` standard peut répondre avec un niveau de confiance moyen sur un sujet RFC. En mail ou OAuth, une approximation = prod cassé ou faille exploitable. Ce contexte active des règles de comportement plus strictes dès qu'un agent opère sur un protocole formel.
+
+---
+
+## Règles mode protocol
+
+### Avant toute affirmation technique
+
+1. **Vérifier la source** — citer la RFC ou la spec formelle (ex: "RFC 6376 §3.5")
+2. **Si incertain** → dire explicitement "je dois vérifier" plutôt qu'approximer
+3. **Niveau de confiance affiché** sur chaque décision : `[confiance: élevée / RFC 5321 §4.1]`
+
+### Déviation du standard
+
+Toute déviation d'une RFC documentée explicitement :
+```
+⚠️ Déviation RFC XXXX §X.X — justification : <raison>
+   Risque : <impact si la déviation pose problème>
+   Alternative conforme : <option standard>
+```
+
+### Anti-hallucination renforcé
+
+- Jamais inventer un flag CLI, un header SMTP, un paramètre OAuth — vérifier
+- Si la RFC évolue (ex : TLS 1.3 remplace TLS 1.2) → citer la version active
+- "Ça devrait marcher" n'est pas acceptable — "RFC X dit Y, donc Z"
+
+---
+
+## Références RFC par domaine
+
+### Mail
+| Protocole | RFC | Résumé |
+|-----------|-----|--------|
+| SMTP | RFC 5321 | Protocole de transfert |
+| Message format | RFC 5322 | En-têtes, corps |
+| DKIM | RFC 6376 | Signature cryptographique |
+| DMARC | RFC 7489 | Politique d'alignement SPF/DKIM |
+| SPF | RFC 7208 | Validation IP expéditeur |
+| IMAP | RFC 9051 | Protocole accès boîte |
+
+### Auth / Sécurité
+| Protocole | RFC | Résumé |
+|-----------|-----|--------|
+| OAuth 2.0 | RFC 6749 | Délégation d'autorisation |
+| JWT | RFC 7519 | JSON Web Token |
+| PKCE | RFC 7636 | Extension OAuth pour clients publics |
+| TLS 1.3 | RFC 8446 | Transport sécurisé (version active) |
+
+---
+
+## Trigger de chargement
+
+```
+Propriétaire : mail, security
+Trigger      : dès que le domaine mail ou OAuth/JWT est détecté dans la session
+Section      : Sources au démarrage (conditionnel — si type metier/protocol confirmé)
+```
+
+---
+
+## Maintenance
+
+```
+Propriétaire : agent-review (audits), mail, security
+Mise à jour  : quand une RFC est obsolète ou qu'un nouveau protocole est ajouté au brain
+Jamais modifié par : agents non-protocol
+```
+
+---
+
+## Cycle de vie
+
+| État | Condition | Action |
+|------|-----------|--------|
+| **Actif** | Sessions mail ou OAuth actives | Mis à jour si RFC change |
+| **Stable** | Peu de sessions protocol | Consulté, rarement modifié |
+| **Archivé** | N/A | Non applicable — les RFC ne disparaissent pas |
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — règles RFC, anti-hallucination renforcé, références mail + auth |

profil/metabolism-spec.md

@@ -0,0 +1,136 @@
+# metabolism-spec.md — Schéma des métriques de santé session
+
+> Dernière mise à jour : 2026-03-14
+> Type : Référence
+> Géré par : `metabolism-scribe`
+
+---
+
+## Schéma d'une entrée de session
+
+```
+session_id        : sess-YYYYMMDD-HHMM-<slug>
+date              : YYYY-MM-DD
+type              : build-brain | use-brain | auto
+mode              : prod | dev | sprint | debug | coach | brainstorm | ...
+tokens_used       : <nombre — estimé depuis /context ou fourni manuellement>
+context_peak_pct  : <pic d'utilisation du context — ex: 87>
+context_at_close  : <context au moment du close — ex: 31>
+duration_min      : <durée en minutes>
+commits           : <nombre de commits produits>
+todos_closed      : <todos cochés ✅ pendant la session>
+saturation_flag   : true | false
+health_score      : <calculé — voir formule>
+agents_loaded     : <liste des agents invoqués/chargés pendant la session>
+tokens_par_agent  : <estimation tokens par agent — voir formule prix>
+notes             : <optionnel — événement notable>
+```
+
+---
+
+## Prix par agent — mandatory
+
+Chaque session doit capturer `agents_loaded` et estimer le coût context de chaque agent.
+
+```
+Estimation :
+  tokens_agent = taille_fichier_bytes / 4  (approximation standard)
+
+Exemple :
+  helloWorld.md      → 18k bytes → ~4500 tokens
+  secrets-guardian.md → 12k bytes → ~3000 tokens
+  debug.md           → 4k bytes  → ~1000 tokens
+  total context agents : ~8500 tokens sur 200k = 4.3% alloué aux agents
+
+Objectif : tendance sur 10 sessions
+  → Quels agents sont toujours chargés pour rien ?
+  → Quels agents coûtent cher vs leur valeur produite ?
+  → Base de décision pour le context-orchestrator (chargement capillaire)
+```
+
+Format dans le metabolism log :
+```
+agents_loaded:
+  - session-orchestrator : ~Xk tokens
+  - helloWorld           : ~Xk tokens
+  - <agent>              : ~Xk tokens
+total_context_agents     : ~Xk tokens  (X% du budget total)
+```
+
+---
+
+## Formule health_score
+
+```
+health_score = (todos_closed * 10 + commits * 5) / max(1, tokens_used_k * context_peak_pct / 100)
+
+où tokens_used_k = tokens_used / 1000
+
+Exemples :
+  todos=2, commits=3, tokens=45k, peak=31%  → (20+15) / (45 * 0.31) = 35 / 13.95 ≈ 2.51
+  todos=0, commits=0, tokens=80k, peak=87%  → 0 / 69.6 = 0  → saturation_flag = true
+```
+
+Le score n'est pas absolu — il se lit en tendance sur 7 jours.
+
+---
+
+## saturation_flag
+
+`true` si `context_peak_pct > 80` ET `todos_closed = 0`
+
+Signal : session qui consomme sans produire. Ne pénalise pas les sessions de brainstorm (mode brainstorm exclu du calcul saturation).
+
+---
+
+## Taxonomie session — type
+
+| Type | Définition |
+|------|-----------|
+| `build-brain` | Session dédiée au brain lui-même (agents, specs, infra, BSI, scribe-system) |
+| `use-brain` | Session projet concret (OriginsDigital, SuperOAuth, VPS, portfolio) |
+| `auto` | Session mixte ou non classifiable — metabolism-scribe tranche en fin |
+
+**Règle ratio sur 7 jours glissants :**
+```
+ratio = use-brain_sessions / build-brain_sessions
+→ ratio >= 1.0 : équilibré ou sain
+→ ratio < 0.5  : ⚠️ Signal boucle narcissique — trop de build-brain sans usage réel
+```
+
+Le signal est affiché dans le briefing helloWorld si `ratio < 0.5` sur 7j.
+
+---
+
+## Seuils — mode conserve
+
+| Condition | Signal |
+|-----------|--------|
+| `context_peak_pct > 70` ET `health_score < 1.0` | ⚠️ Session peu efficiente détectée |
+| `context_at_close > 60` | ⚠️ Mode conserve recommandé pour la prochaine session |
+| `ratio < 0.5` sur 7j | ⚠️ Boucle narcissique — alterner avec une session use-brain |
+
+Mode `conserve` : helloWorld le propose (jamais forcé) si seuil atteint au boot.
+
+---
+
+## Modes et budget context attendu
+
+| Mode | Budget context | Saturation tolérée |
+|------|----------------|-------------------|
+| `prod` | normal — surveiller à 60% | non |
+| `sprint` | élargi — 80% acceptable si output élevé | oui si commits > 5 |
+| `conserve` | strict — target <40% | non |
+| `brainstorm` | libre | oui — exclut saturation_flag |
+| `review` | minimal — lecture seule | non |
+| `debug` | modéré | non |
+| `coach` | modéré | non |
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — schéma métriques, formule health_score, taxonomie build/use-brain, seuils conserve, ratio 7j |
+| 2026-03-14 | Prix par agent mandatory — champs agents_loaded + tokens_par_agent, formule estimation, objectif tendance 10 sessions |

profil/multi-session-procedure.md

@@ -0,0 +1,145 @@
+# Procédure — Multi-sessions brain
+
+> **Type :** Contexte — propriétaire : `scribe`
+> Dernière mise à jour : 2026-03-14
+> Pré-requis : BSI claims opérationnels, brain-watch actif
+
+---
+
+## Principe
+
+Plusieurs sessions Claude Code en parallèle sur le même brain. Chacune a un rôle,
+un scope déclaré dans le BSI, et peut passer du contexte aux autres via des signaux.
+
+Le superviseur (cette session-ci, la session de coordination) observe le BSI et guide.
+
+---
+
+## Étape 1 — Planifier avant de lancer
+
+Avant d'ouvrir les sessions, définir :
+
+| Session | Rôle | Scope BSI | Fichiers touchés |
+|---------|------|-----------|-----------------|
+| sess-HHMM-backend | Backend | `projets/X.md`, `backend/` | src/routes, src/entities |
+| sess-HHMM-frontend | Frontend | `projets/X.md ## Frontend`, `frontend/` | src/pages, src/components |
+| sess-HHMM-supervisor | Coordination | `brain/ (dir)` | BRAIN-INDEX.md, handoffs/ |
+
+**Règle scopes :** pas d'overlap. Si deux sessions touchent le même fichier → conflit BSI.
+`projets/X.md` peut être partagé en lecture — seule la section owée est en write.
+
+---
+
+## Étape 2 — Ouvrir les sessions
+
+Pour chaque session worker, au boot :
+
+```
+1. helloWorld fait le briefing standard
+2. BSI : ouvrir un claim avec le bon slug et scope
+   → sess-HHMM-backend  scope: backend/ (dir)
+   → sess-HHMM-frontend scope: frontend/ (dir)
+3. Commiter + pusher BRAIN-INDEX.md immédiatement
+4. Confirmer dans le groupe Telegram Superviseur via /sessions
+```
+
+La session superviseur vérifie que les deux claims sont visibles dans `/sessions`
+avant de donner le feu vert.
+
+---
+
+## Étape 3 — Travailler
+
+Chaque session travaille dans son scope. Pas de coordination nécessaire tant
+qu'il n'y a pas d'intersection.
+
+**Si une session a besoin d'informer l'autre (CHECKPOINT en cours) :**
+
+```
+1. Créer brain/handoffs/sess-<id>.md depuis le template
+   → Remplir : ce qui est fait, état actuel, prochaine étape
+2. Écrire un signal dans BRAIN-INDEX.md ## Signals :
+   | sig-YYYYMMDD-001 | sess-backend@desktop | sess-frontend@desktop | CHECKPOINT | projet | → handoffs/sess-backend-HHMM.md | pending |
+3. Commiter + pusher
+4. brain-watch notifie Telegram → supervisor voit le signal
+5. La session cible lit le handoff file au prochain boot (ou sur demande)
+```
+
+---
+
+## Étape 4 — Fermeture propre
+
+Quand une session termine :
+
+```
+1. Optionnel : écrire un handoff final (HANDOFF type) si l'autre session continue
+2. Commiter son travail sur le repo projet
+3. Fermer le claim BSI :
+   git -C ~/Dev/Docs add BRAIN-INDEX.md
+   git -C ~/Dev/Docs commit -m "bsi: close claim <sess-id>"
+   git -C ~/Dev/Docs push
+4. Telegram reçoit : "Session fermée — claim libéré"
+```
+
+---
+
+## Cas stale — exit sans fermeture
+
+Si une session est fermée brutalement (Ctrl+C, fermeture fenêtre) sans fermer le claim :
+
+```
+Automatique :
+  → brain-watch détecte TTL expiré → notifie Telegram une seule fois :
+    "⚠️ Claim stale : sess-<id> — TTL expiré. Recovery requis."
+
+Action humaine requise (dans la session superviseur) :
+  1. Lire ce que la session faisait (git log du repo projet)
+  2. Optionnel : écrire un handoff retroactif dans handoffs/
+  3. Déplacer le claim de ## Claims actifs vers ## Claims stale
+  4. Commiter : "bsi: mark stale <sess-id>"
+  5. Confirmer : claim libéré, autres sessions peuvent reprendre le scope
+
+Reprendre le travail dans une nouvelle session :
+  1. Ouvrir une nouvelle session
+  2. helloWorld détecte le claim stale → affiche le contexte si handoff disponible
+  3. Ouvrir un nouveau claim avec un nouveau slug
+```
+
+---
+
+## Checklist superviseur — multi-sessions
+
+```
+Avant :
+  ☐ Scopes définis, pas d'overlap
+  ☐ /sessions dans Telegram → vide ou claims attendus seulement
+
+Pendant :
+  ☐ /sessions après chaque boot session → vérifier que le claim est ouvert
+  ☐ CHECKPOINT reçu sur Telegram → lire handoffs/, briefer la session cible si besoin
+  ☐ Conflit BSI détecté → arbitrer (priorité mode : dev > prod > toolkit-only)
+
+Après :
+  ☐ /sessions → vide (tous les claims fermés)
+  ☐ Claims stale résolus
+  ☐ Scribe met à jour focus.md + projets/X.md
+```
+
+---
+
+## Signaux BSI — types utilisés en multi-sessions
+
+| Type | Quand | Payload |
+|------|-------|---------|
+| `CHECKPOINT` | Session A informe session B en cours de route | `→ handoffs/<sess-id>.md` |
+| `HANDOFF` | Session A passe le relais à session B (fermeture) | `→ handoffs/<sess-id>.md` |
+| `BLOCKED_ON` | Session A attend que session B libère un scope | scope concerné |
+| `READY_FOR_REVIEW` | Session A demande une review à session B | fichier ou PR |
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — procédure complète, cas stale, checklist superviseur |

profil/orchestration-patterns.md

@@ -0,0 +1,246 @@
+# Patterns d'orchestration — Tetardtek Brain
+
+> **Type :** Contexte — propriétaire : `orchestrator-scribe`
+> Mis à jour en fin de session quand un pattern récurrent est identifié.
+
+---
+
+## Pattern 1 — Sessions parallèles sur une machine (session-as-identity)
+
+**Problème :** plusieurs agents travaillent en parallèle sur la même machine → même `brain_name@machine` → orchestrator-scribe ne peut pas distinguer qui cibler.
+
+**Solution :** le slug du session ID EST l'identité de routage. Pas besoin de forker un brain par rôle.
+
+```
+Format : sess-YYYYMMDD-HHMM-<role>@machine
+
+Exemples :
+  sess-20260314-0900-build@desktop    → produit du code
+  sess-20260314-0901-review@desktop   → review en parallèle
+  sess-20260314-0902-test@desktop     → tests en parallèle
+  sess-20260314-0910-audit@laptop     → audit depuis le laptop
+```
+
+**Procédure :**
+
+```
+1. Ouvrir chaque session avec un rôle dans le slug :
+   scribe, ouvre un claim sur agents/ — rôle : build
+   → ID généré : sess-20260314-0900-build@desktop
+
+2. Envoyer un signal ciblé (pas broadcast) :
+   De  : sess-20260314-0900-build@desktop
+   Pour : sess-20260314-0901-review@desktop   ← message direct
+   Type : READY_FOR_REVIEW
+   Concerné : agents/security.md
+
+3. La session review reçoit au démarrage :
+   → watchdog filtre Pour == son sess-id@machine
+   → "Signal reçu de build : READY_FOR_REVIEW sur agents/security.md"
+```
+
+**Règle de routage :**
+
+| Format `Pour` | Comportement |
+|---------------|-------------|
+| `brain_name@machine` | Broadcast — toutes sessions actives de ce brain |
+| `sess-YYYYMMDD-HHMM-<role>@machine` | Message direct — une session précise |
+
+**Anti-pattern :**
+- ❌ Ne pas forker un nouveau brain pour chaque rôle → explosion de configs
+- ❌ Ne pas cibler `brain_name@machine` quand on veut une session précise → broadcast non désiré
+- ✅ Un brain par machine, N sessions nommées par rôle
+
+---
+
+## Pattern 2 — Cycle coworking inter-machines
+
+**Problème :** une session produit du travail sur desktop, une autre doit le reviewer sur laptop sans communication manuelle.
+
+**Solution :** signal READY_FOR_REVIEW dans BRAIN-INDEX.md → watchdog détecte au démarrage de la session review.
+
+```
+prod@desktop  →  travaille sur <fichier>
+               →  ferme claim
+               →  signal READY_FOR_REVIEW → template-test@laptop (ou sess-id précis)
+
+template-test@laptop  →  démarre, watchdog lit BRAIN-INDEX.md ## Signals
+                       →  détecte signal pending adressé à son instance
+                       →  "Signal reçu : READY_FOR_REVIEW sur <fichier>"
+                       →  ouvre claim review
+                       →  audite → écrit dans reviews/<fichier>.md
+                       →  ferme claim
+                       →  signal REVIEWED → prod@desktop
+
+prod@desktop  →  watchdog lit REVIEWED
+               →  lit reviews/<fichier>.md
+               →  intègre ou ignore → continue
+```
+
+**Quand l'utiliser :**
+- Review de code sensible (sécurité, auth, archi)
+- Validation d'un agent forgé avant de l'intégrer dans brain-template
+- Tout workflow "produit → valide → intègre"
+
+---
+
+## Pattern 3 — HANDOFF — session longue découpée
+
+**Problème :** session longue à couper (fin de journée, changement de machine) sans perdre le contexte.
+
+**Solution :** signal HANDOFF avec payload précis → la session cible reprend exactement au bon endroit.
+
+```
+sess-20260314-1800-build@desktop  →  point d'arrêt naturel atteint
+                                   →  signal HANDOFF → prod@laptop
+                                   →  payload : "reprendre agents/security.md à ## Périmètre"
+
+prod@laptop  →  watchdog détecte HANDOFF
+              →  charge agents/security.md, position ## Périmètre
+              →  continue sans perte de contexte
+```
+
+**Payload HANDOFF — format recommandé :**
+```
+"reprendre <fichier> à <## Section> — contexte : <1 ligne résumé>"
+```
+
+---
+
+## Pattern 4 — Audit avant prod (triple-session)
+
+**Problème :** feature sensible → besoin de review code + security + tests avant merge.
+
+**Solution :** session build produit → 3 sessions d'audit en parallèle → résultats consolidés.
+
+```
+sess-YYYYMMDD-HHMM-build@desktop  →  feature terminée
+  →  signal READY_FOR_REVIEW → sess-HHMM-review@desktop   (code quality)
+  →  signal READY_FOR_REVIEW → sess-HHMM-security@desktop (OWASP, auth)
+  →  signal READY_FOR_REVIEW → sess-HHMM-test@laptop       (coverage)
+
+Chaque session audite, écrit dans reviews/
+  →  signal REVIEWED → build@desktop
+
+build@desktop reçoit 3× REVIEWED → consolide → merge
+```
+
+---
+
+## Pattern 5 — CHECKPOINT — arrêt naturel et reprise sans perte
+
+**Problème :** session longue → compactage LLM, coupure réseau, pause humaine → contexte perdu, reprise hasardeuse.
+
+**Solution :** signal `CHECKPOINT` posé dans BRAIN-INDEX.md (HANDOFF vers soi-même) — snapshot persisté dans git, indépendant du contexte LLM.
+
+**Déclencheurs :**
+- Utilisateur : `checkpoint` / `/checkpoint` / `pose un checkpoint`
+- Scribe (auto) : breakpoint naturel après un item important terminé en session longue
+- Fin de session sans fermeture propre prévue
+
+**Procédure — poser un checkpoint :**
+
+```
+User : "checkpoint"
+
+orchestrator-scribe :
+1. Collecter avec scribe :
+   - Tâche en cours  : <ce qu'on faisait>
+   - Fichiers touchés: <git diff --name-only depuis ouverture claim>
+   - Commits         : <git log --oneline --since="<ouvert le>">
+   - Prochaine étape : <actionnable, précis — "reprendre X à ## Section Y">
+   - Contexte non-git: <décisions, intentions pas encore commitées>
+
+2. Poser signal CHECKPOINT dans BRAIN-INDEX.md :
+   De   : sess-YYYYMMDD-HHMM-<role>@machine
+   Pour : sess-YYYYMMDD-HHMM-<role>@machine  ← même session
+   Type : CHECKPOINT
+   Payload : résumé structuré ci-dessus
+
+3. Confirmer : "Checkpoint posé — reprise depuis : <prochaine étape>"
+4. L'utilisateur peut fermer la session proprement.
+```
+
+**Procédure — reprendre après un checkpoint :**
+
+```
+Nouvelle session démarre — watchdog scribe :
+1. Lire ## Signals — filtrer CHECKPOINT de l'instance active
+2. Afficher AVANT tout autre action :
+   "Checkpoint détecté [date]
+    Tâche en cours  : <...>
+    Prochaine étape : <...>
+    Commits posés   : <...>"
+3. Demander : on reprend depuis ce point ?
+4. Oui → marquer signal delivered → continuer depuis <prochaine étape>
+5. Non → ignorer, session normale
+```
+
+**Pourquoi c'est robuste :**
+- Persisté dans git → survit au compactage LLM, redémarrage machine, changement de machine
+- Format structuré → le LLM relit un état propre, pas une mémoire dégradée
+- `git log` dans le payload → audit trail complet de ce qui a été fait
+
+---
+
+## Ajout de patterns
+
+Invoquer `orchestrator-scribe` en fin de session si un workflow récurrent a été identifié :
+```
+orchestrator-scribe, capture ce pattern dans orchestration-patterns.md
+```
+
+---
+
+## Pattern 6 — HumanSupervisor — décision minimale
+
+> Validé en prod : sess-20260314-1920-supervisor — 2026-03-14
+> Contexte : sprint OriginsDigital dual-agent (back + front) supervisé depuis une fenêtre dédiée
+
+**Principe : extraire la logique d'exécution pour ne laisser à l'humain que les bifurcations décisionnelles.**
+
+```
+Exécution déterministe   → agents autonomes (pas de remontée)
+  bug connu + pattern    → fix direct
+  signal BSI             → trigger automatique
+  close session          → séquence scribe auto
+  validation routes      → back lit le code front, pas la spec
+
+Points de décision humaine (ce qui remonte au superviseur)
+  → Priorisation        : "Sprint 2 ou fix d'abord ?"
+  → Architecture        : "Ce choix a des conséquences long terme ?"
+  → Arbitrage scope     : conflit entre deux sessions parallèles
+  → Validation prod     : deploy = toujours humain
+```
+
+**Structure de la session supervisor :**
+
+```
+Fenêtre supervisor  →  claim BSI type supervisor
+                        lit les signaux, pas le code
+                        coach intervient sur les bifurcations
+                        3 interventions max sur un sprint de 4h
+                        ferme en dernier (après les sessions de travail)
+```
+
+**Ce que le sprint du 2026-03-14 a mesuré :**
+- 3 interventions humaines sur ~4h de travail dual-agent
+- Bug super_admin trouvé par le back en lisant le code front (audit externe)
+- Ratio métabolisme 1.0 — équilibré build-brain / use-brain
+
+**Règle : minimum viable human input**
+```
+Si une décision peut être prise sans connaître la stratégie globale → agent
+Si une décision change la direction du projet ou l'architecture → humain
+```
+
+**Anti-pattern :**
+- ❌ Supervisor qui relit chaque ligne de code — c'est du micro-management
+- ❌ Agents qui remontent chaque étape pour validation — ça annule le gain
+- ✅ Agents qui remontent uniquement les blocages ou les ambiguïtés réelles
+- ✅ Supervisor qui répond en 1 phrase, pas en spec complète
+
+**Connexion brain :**
+→ `brain-compose.yml` : mode `human-supervisor` à créer (todo capturé)
+→ `motor-spec.md` : motor_level définit ce qui est autonome vs ce qui remonte
+→ `session-orchestrator` : close sequence = exemple d'exécution déterministe

profil/session-types.md

@@ -0,0 +1,124 @@
+# session-types.md — Types de sessions et comportements au boot
+
+> Dernière mise à jour : 2026-03-14
+> Type : Référence
+> Géré par : `session-orchestrator`
+> Utilisé par : `helloWorld`, `session-orchestrator`, `metabolism-scribe`
+
+---
+
+## Tableau complet — boot possibilities
+
+| Intent déclaré | Mode activé | Contexte chargé | Scribes close | MYSECRETS |
+|----------------|-------------|-----------------|---------------|-----------|
+| `brain` | `prod` | BRAIN-INDEX, focus, todo/brain, AGENTS | metabolism + scribe + coach | ❌ non |
+| `work <projet>` | `prod` | projets/X, todo/X, agent métier détecté | metabolism + todo-scribe + coach | ⚡ si .env/db |
+| `sprint <projet>` | `prod` | projets/X, todo/X, BSI scope déclaré | metabolism + todo-scribe + coach | ⚡ si .env/db |
+| `deploy <projet>` | `deploy` | projets/X, infrastructure/vps, agent vps/ci-cd | metabolism | ✅ oui |
+| `debug <projet>` | `debug` | projets/X, agent debug | metabolism + todo-scribe | ⚡ si .env/db |
+| `review <projet>` | `review-back` ou `review-front` | projets/X, agent code-review | metabolism | ❌ non |
+| `coach` | `coach` | profil/objectifs, progression/README, skills/ | metabolism + coach-scribe | ❌ non |
+| `brainstorm <sujet>` | `brainstorm` | BRAIN-INDEX si brain, projets/X si work | metabolism | ❌ non |
+| `agents` | `prod` | AGENTS.md, _template, profil/context-hygiene | metabolism + scribe | ❌ non |
+| (rien / ambigu) | → 1 question | `brain ou work ?` → résout vers l'un des cas ci-dessus | — | — |
+
+> **HANDOFF** : détecté automatiquement si claim HANDOFF dans BRAIN-INDEX → mode HANDOFF, charge handoffs/<fichier>.md
+
+---
+
+## Règle MYSECRETS — passive listening
+
+```
+Au boot        → secrets-guardian confirme que MYSECRETS existe (présence only)
+                 Ne charge PAS les valeurs
+                 Écoute passive sur 4 surfaces (code / chat / shell / output)
+
+Sur trigger    → charge MYSECRETS et active le cycle de vie secrets
+Triggers :       .env | mysql | VPS | deploy | JWT | token | API key | credentials | MYSECRETS mentionné
+```
+
+---
+
+## Contexte chargé par type — détail
+
+### `brain`
+```
+Couche 0 — invariant   : PATHS + collaboration
+Couche 1 — intent      : brain
+Couche 2 — domaine     : BRAIN-INDEX + focus + todo/brain
+Couche 3 — projet      : (aucun)
+```
+
+### `work <projet>`
+```
+Couche 0 — invariant   : PATHS + collaboration
+Couche 1 — intent      : work
+Couche 2 — domaine     : agent métier détecté (frontend / backend / infra / agents)
+Couche 3 — projet      : projets/<projet> + todo/<projet>
+```
+
+### `deploy <projet>`
+```
+Couche 0 — invariant   : PATHS + collaboration
+Couche 1 — intent      : deploy
+Couche 2 — domaine     : infrastructure/vps + agents vps/ci-cd/pm2
+Couche 3 — projet      : projets/<projet> — section deploy uniquement
+MYSECRETS : chargé — secrets requis pour VPS/docker
+```
+
+### `coach`
+```
+Couche 0 — invariant   : PATHS + collaboration
+Couche 1 — intent      : coach
+Couche 2 — domaine     : progression/README + skills/<domaine si précisé>
+Couche 3 — projet      : (aucun — focus progression uniquement)
+```
+
+### `brainstorm <sujet>`
+```
+Couche 0 — invariant   : PATHS + collaboration
+Couche 1 — intent      : brainstorm
+Couche 2 — domaine     : selon sujet (brain → BRAIN-INDEX / work → projets/X)
+Couche 3 — projet      : (aucun — pas d'écriture)
+```
+
+---
+
+## Séquence close — par type
+
+| Type session | Ordre scribes |
+|-------------|---------------|
+| `brain` | metabolism-scribe → scribe → **coach rapport** → user décide |
+| `work` | metabolism-scribe → todo-scribe → scribe (si commit) → **coach rapport** → user décide |
+| `sprint` | metabolism-scribe → todo-scribe → **coach rapport** → user décide |
+| `deploy` | metabolism-scribe → scribe (infra) → user décide |
+| `debug` | metabolism-scribe → todo-scribe → **coach rapport** → user décide |
+| `coach` | metabolism-scribe → coach-scribe → user décide |
+| `brainstorm` | metabolism-scribe → todo-scribe (si todos émergés) → user décide |
+
+> `coach rapport` = coach produit le bilan de session **avant** la fermeture BSI.
+> L'utilisateur lit, puis choisit : `/exit` ou discussion avec le coach.
+> BSI close est toujours le dernier geste — même si l'utilisateur part sans lire.
+
+---
+
+## Signal au boot — format
+
+```
+"brain"                        → type: brain
+"work originsdigital"          → type: work, projet: originsdigital
+"deploy originsdigital"        → type: deploy, projet: originsdigital
+"debug originsdigital"         → type: debug, projet: originsdigital
+"review backend originsdigital" → type: review-back, projet: originsdigital
+"coach"                        → type: coach
+"brainstorm agents"            → type: brainstorm, sujet: agents
+(premier message ambigu)       → session-orchestrator pose 1 question
+```
+
+---
+
+## Changelog
+
+| Date | Changement |
+|------|------------|
+| 2026-03-14 | Création — tableau complet boot possibilities, règle MYSECRETS passive, séquence close par type, architecture 4 couches |

profil/workspace-spec.md

@@ -0,0 +1,188 @@
+# Workspace inter-sessions — Spécification
+
+> **Type :** Contexte — propriétaire : `scribe`
+> Dernière mise à jour : 2026-03-14
+> Statut : v1.0 — première implémentation
+
+---
+
+## Origine — comment cette feature est née
+
+Le workspace n'a pas été planifié. Il a émergé d'une observation faite pendant
+le premier sprint dual-agent OriginsDigital (2026-03-14).
+
+**Le problème observé en conditions réelles :**
+
+```
+Session backend a une question pour session frontend
+  → backend écrit la question dans son output
+  → humain lit
+  → humain copy-paste vers frontend
+  → frontend répond
+  → humain copy-paste la réponse vers backend
+  → backend continue
+```
+
+L'humain était le **relay** entre deux sessions qui ne pouvaient pas se parler.
+Ce relay prenait du temps, introduisait des erreurs de transcription, et
+empêchait toute coordination autonome.
+
+**L'insight :**
+
+Les sessions ont besoin d'un espace partagé — volatile pendant le sprint,
+persistant comme trace après. Exactement comme de la RAM dans un ordinateur :
+rapide, structurée, vidée à la fin de l'exécution (sauf archivage explicite).
+
+**Pourquoi c'est limpide rétrospectivement :**
+
+Le brain a déjà `handoffs/` (snapshot fin de session) et
+`progression/journal/` (bilan pédagogique). Il manquait le **pendant** —
+l'espace vivant où les sessions coexistent et coopèrent.
+
+```
+handoffs/           → snapshot APRÈS   (ce qui a été fait)
+progression/journal → bilan APRÈS      (ce qu'on a appris)
+workspace/          → vivant PENDANT   (ce qui se passe maintenant)
+```
+
+Le workspace est la troisième pièce qui complète le triptyque.
+
+---
+
+## Principe cardinal
+
+> **Un agent qui travaille ne charge qu'une seule section du workspace.**
+> Jamais le workspace entier.
+
+La valeur du workspace est nulle si chaque session doit tout lire pour
+trouver ce qui la concerne. Les droits de lecture ne sont pas optionnels —
+ils sont la colonne vertébrale du système.
+
+---
+
+## Structure
+
+```
+brain/workspace/
+  <projet>-<sprint>/
+    README.md        → métadonnées, lifecycle, mode actif — 10 lignes max
+    ram.md           → état live + questions inter-sessions (volatile)
+    log.md           → décisions + audit trail (persistant)
+    feedback.md      → retours post-sprint (jamais lu en sprint actif)
+```
+
+Un workspace par sprint. Pas par session, pas par projet global.
+La granularité sprint est le bon niveau : assez court pour rester léger,
+assez long pour capturer un arc de travail complet.
+
+---
+
+## Droits de lecture — par rôle
+
+| Section | Worker | Supervisor | Coach-scribe |
+|---------|--------|------------|--------------|
+| `ram.md` | ✅ obligatoire | ✅ | ❌ |
+| `log.md` | sur demande explicite | ✅ obligatoire | ✅ |
+| `feedback.md` | ❌ jamais en sprint | ❌ jamais en sprint | ✅ après TTL |
+
+**Règle d'or :** le worker charge `ram.md` au boot si un workspace actif existe.
+Il ne charge `log.md` que si le supervisor le lui demande explicitement.
+`feedback.md` n'existe pas pour lui pendant le sprint.
+
+---
+
+## Lifecycle — champ `archive` dans README.md
+
+```yaml
+## Lifecycle
+ttl: 7d
+archive: auto | keep | 30d | 90d | permanent
+```
+
+| Valeur | Comportement |
+|--------|-------------|
+| `auto` | TTL standard → archivé dans `handoffs/` → supprimé |
+| `keep` | Suspend l'archivage — humain décide quand |
+| `30d` / `90d` | Retention custom après fermeture du sprint |
+| `permanent` | Jamais supprimé — devient référence documentaire |
+
+**Qui gère le lifecycle :** `coach-scribe` — lit le champ `archive` au TTL expiry.
+Si `keep` → notifie le supervisor pour décision humaine.
+
+---
+
+## Graduation par mode (`brain-compose.yml`)
+
+Le contenu actif du workspace dépend du mode déclaré :
+
+| Mode | Sections actives | Usage |
+|------|-----------------|-------|
+| `prod` | `ram.md` (state + questions) + `log.md` (décisions) | Sprint standard |
+| `dev` | Tout | Expérimentation libre |
+| `review` | `log.md` + resources ponctuels — pas de `ram` | Code review |
+| `brainstorm` | `log.md` + `feedback.md` — pas de `ram` | Conception |
+| `debug` | `ram.md` (state uniquement) + `log.md` | Debug focalisé |
+
+---
+
+## Anti-embourbage — règles dures
+
+```
+TTL workspace     = durée sprint + 7 jours (défaut)
+Max ram.md        = 50 lignes actives (au-delà = stale, purger les résolus)
+Max log.md        = 1 ligne par décision — pas de justification longue ici
+feedback.md       = géré en session dédiée post-sprint par coach-scribe
+Sections custom   = interdites — seulement README + ram + log + feedback
+```
+
+**Pourquoi pas de sections custom :** chaque section custom crée un nouveau
+droit de lecture à définir, un nouveau template à maintenir, une nouvelle
+règle de chargement. Le coût explose vite. Si un besoin ne rentre pas dans
+les 3 sections → c'est soit un handoff, soit un signal BSI.
+
+---
+
+## Valeur post-sprint
+
+Le workspace archivé répond à la question : **"pourquoi on a fait ça ?"**
+
+```
+Dans 3 mois, on revient sur OriginsDigital.
+Pourquoi /auth/me retourne roles[] ?
+→ workspace/originsdigital-sprint2/log.md ligne 4 :
+  "2026-03-14 15:xx | Option 1 vs 2 — enrichir /auth/me | choisi : Option 1
+   | raison : un seul appel, coût DB négligeable à cette échelle"
+```
+
+Pas besoin de fouiller le git log, pas besoin de se souvenir.
+Le workspace archivé EST la documentation du raisonnement.
+
+---
+
+## Connexion aux autres systèmes
+
+| Système | Relation |
+|---------|----------|
+| `BRAIN-INDEX.md ## Signals` | Coordination légère — workspace est la couche lourde |
+| `handoffs/` | Snapshot final — workspace est le live |
+| `progression/journal/` | Bilan pédagogique — workspace est le raw material |
+| `brain-compose.yml` | Mode actif → détermine les sections actives du workspace |
+| `coach-scribe` | Gère le lifecycle et alimente `feedback.md` post-sprint |
+
+---
+
+## Templates
+
+Voir `brain/workspace/_template/` :
+- `README.md` — métadonnées + lifecycle
+- `ram.md` — état live + questions
+- `log.md` — décisions + audit trail
+- `feedback.md` — retours post-sprint
+
+---
+
+## Changelog
+
+| Date | Version | Changement |
+|------|---------|------------|
+| 2026-03-14 | 1.0 | Création — émergé du sprint dual-agent OriginsDigital, triptyque pendant/après/après, 3 sections, droits de lecture, graduation modes, anti-embourbage |