LifePlay-Revival/Docs/32_Organisation_Agents.md

32 — Organisation hiérarchique des agents : chef de projet, orchestrateur, planificateur, managers

• Date : 2026-10-10 | Statut : appliqué en partie depuis le 2026-10-10 (lot AG, CHG-299 : gardien du dépôt, Big Boss) ; chef de projet, planificateur et managers conçus, non mis en place ; D-AG1 à D-AG8 non tranchées | Entrée journal : CHG-299 (lot AG) ; révision ci-dessous : entrée du lot DOCSTAT
• Rédaction : Claude (session claude.ai liée au poste), hors fiche, lecture seule du projet ; seul ce fichier est écrit. Aucun skill, agent, réglage, journal ni registre modifié.
• Sources lues : etat/SK/SK-ARBRE.md (§ 1-10), etat/SK/SK-T1-TACHES.md (§ 0-1), SK-T4-V1a/b/c.md ; skills de l'addon D:\Game\LifePlay-Sandbox\Tools\claude\skills\ (lp-lot, lp-doc et gabarits.md, lp-validate, en-têtes des 8 skills) ; docs 10, 22, 26, 27 (§ Orchestration), 29 (§ Méthode, règle 7), 31 ; registres etat/ST/STA/STA-TACHES.md, etat/OB/OBA/OBA-TACHES.md, etat/TPL1/, etat/ETAT2/ (en-têtes).
• Lu ensuite (révision du 2026-10-10, 08 h 30) : copies fournies par l'utilisateur de ~/.claude/skills (sk-*, debug-verification, ue-cpp-build), ~/.claude/agents (10 agents) et de la mémoire du projet ; état des dépôts (jeu 5.5, jeu 5.8, addon). Détail, constats et conception : etat/AG/AG-T1-CONCEPTION.md ; brouillons de skills et d'agents : etat/AG/brouillons/ (dossier etat de référence, copie 5.5).
• Organigramme : page « Organigramme des agents Claude » (claude.ai), même contenu que § 2 à § 8.
• Révision du 2026-10-10 (session « Big Boss ») : rôle Big Boss ajouté (§ 2, § 8, § 9, D-AG10), décision de l'utilisateur du même jour. Entrée journal : à prendre par le gardien (aucun CHG écrit ici).
• Révision du 2026-10-10 (lot DOCSTAT, décision de l'utilisateur « 1 - 5 oui ») : statut mis à jour ; règles en vigueur au § 15, avec leurs sources ; la conception d'origine (§ 1 à § 14) n'est pas modifiée.
• Révision du 2026-10-11 (lot ORGA1, décisions de l'utilisateur E1, E4, E5 « approuvé » sur etat/EVAL/EVAL-RAPPORT.md § 9) : § 15.2 et § 15.8 complétés, § 15.9 à § 15.11 ajoutés ; protocole Big Boss porté dans lp-lot (annexe boss.md), règles de fiche et rotation dans sk-orchestrate § 3 et § 4. Entrée journal : CHG-328.

Décisions de l'utilisateur (2026-10-10) : le cahier des charges est rédigé par le chef de projet à partir des demandes de l'utilisateur ; une tâche s'arrête après 3 ou 4 échecs (retenu ici : 4 tentatives au plus, D-AG3) ; les critères de réussite sont dans la fiche de la tâche ; les tâches peuvent être lancées en parallèle, à la discrétion de l'orchestrateur. Demande du même jour : un seul agent gère le dépôt (aujourd'hui toutes les sessions commitent) ; concevoir les skills manquants.

---

1. Résumé

1. Ce qui change. Aujourd'hui une session principale (Opus high, N2) fait tout : elle parle à l'utilisateur, écrit la fiche projet, découpe, rédige les fiches, lance et contre-vérifie les sous-agents. La proposition sépare ces rôles : un chef de projet (seul interlocuteur de l'utilisateur, auteur du cahier des charges), un orchestrateur général (exécute les lots), un planificateur (découpe en lots et fiches) et des managers spécialisés (choisissent l'agent, fixent budget et tours, jugent le résultat, décident des reprises). Les sous-agents restent ceux du lot SK : 12 rôles lp-*, variantes -max, et opus-xhigh / opus-max / fable-top pour l'escalade.
2. Contrainte qui fixe l'implémentation. Un sous-agent Claude Code ne peut pas lancer un autre sous-agent : seule une session principale dispose de l'outil Agent (incertain ici, test AG0-T3). Une chaîne orchestrateur → manager → sous-agent ne peut donc pas être un emboîtement de sous-agents. Elle devient : deux sessions principales (chef, orchestrateur) qui se parlent par SendMessage, et des managers conseillers : sous-agents de l'orchestrateur, repris par SendMessage à chaque étape, qui décident des lancements que l'orchestrateur exécute (§ 3).
3. Budget et reprises. Budget par niveau des gabarits TPL1 (N0-N2 : 40 tours, pic 150 k ; N3-N5 : 60 tours, 250 k), plafond dur par maxTurns. Sur échec, le manager classe la cause : budget → prolonger le même sous-agent ; capacité → l'arrêter et lancer le niveau supérieur ; consigne → rendre la main sans reprise. 4 tentatives au plus par fiche, puis verdict ÉCHEC à l'orchestrateur (§ 6).
4. Dépôt : un seul gardien (§ 10). L'agent lp-gardien (rôle A-INT) est le seul à écrire dans git ; il est lancé par l'orchestrateur, un ticket à la fois. Commit par chemins explicites sur un index privé (les fichiers des autres sessions ne sont jamais emportés), hook pre-commit (sans règles de refus sur git, qui bloqueraient aussi le gardien), journal du dépôt, réservation des numéros CHG / ERR / doc sous verrou, et un dépôt de méthode unique pour les skills et agents, qui met fin aux 10 doubles commits de skills constatés depuis le 2026-10-08.
5. Skills manquants (§ 11) : 6 brouillons écrits (sk-repo, lp-repo, sk-manage, sk-plan, sk-chef, lp-mcp), 7 conçus, 6 absorbés ou abandonnés ; 3 brouillons d'agents (lp-gardien, lp-planificateur, lp-mgr-realisation).
6. Mise en œuvre en lots AG0-AG3, le gardien d'abord (§ 12). 8 décisions D-AG (§ 13) et 8 décisions D-REPO (AG-T1-CONCEPTION.md § 6).

---

2. Rôles et correspondance dans Claude Code

Rôle	Mécanisme	Modèle	Parle à	Écrit	Skills
Client final	l'utilisateur	—	chef de projet seulement ; Big Boss pour un arbitrage	—	—
Big Boss (commun aux projets, décision de l'utilisateur 2026-10-10)	session principale « Big Boss »	Opus (N2)	utilisateur ; chefs de projet, orchestrateur, toute session (SendMessage)	file de compilation (ordre de passage sur la copie UE, gels annoncés), arbitrages des conflits entre chefs de projet, orchestrateur et agents (fichiers, numéros, priorités entre lots)	sk-orchestrate, lp-lot, lp-build
Chef de projet (un par projet : ST, OB…)	session principale « Chef »	Opus high (N2)	utilisateur ; orchestrateur (SendMessage)	fiche projet = cahier des charges (NN_Projet_<Nom>.md), décisions datées, portes	sk-chef (nouveau), lp-doc, lp-lot
Orchestrateur général (commun aux projets)	session principale « Orchestrateur », jamais en contact avec l'utilisateur	Opus high (N2)	chefs de projet (SendMessage) ; planificateur, managers, sous-agents (Agent, SendMessage)	<LOT>-TACHES.md, ouverture et clôture de lot (tag, instantané), gel de la copie, <LOT>-EVAL.md	sk-orchestrate (étendu, § 10), lp-lot
Planificateur	sous-agent lp-planificateur	opus, effort xhigh (escalade opus-max pour un plan lourd)	orchestrateur	plan des lots, registres TACHES en brouillon, fiches d'entrée	sk-protocol, sk-plan (nouveau), lp-lot, lp-paths
Gardien du dépôt	sous-agent lp-gardien, lancé par l'orchestrateur seul	sonnet (N1)	orchestrateur	commits, tags, pins, tickets, REPO-JOURNAL.md	sk-protocol, sk-repo, lp-repo, sk-change-safety
Managers spécialisés (6, § 5)	sous-agents lp-mgr-*, repris à chaque étape	sonnet ou opus selon la famille	orchestrateur	<LOT>-Tn-SUIVI.md (tentatives)	sk-protocol, sk-recount, sk-manage (nouveau), skill de la famille
Sous-agents	agents de rôle lp-* et d'escalade (inchangés, SK-ARBRE § 3.2)	N0 à N5	rendent leur compte rendu	livrable de la fiche (gabarits lp-doc)	ceux du frontmatter

Règles communes : seul le chef utilise AskUserQuestion et parle à l'utilisateur ; planificateur et managers ont disallowedTools: Agent, Edit, AskUserQuestion ; l'orchestrateur ne pose jamais de question à l'utilisateur, il écrit au chef. Un test en jeu (doc 10 § 4) est préparé par l'orchestrateur et transmis par le chef.

Big Boss. Il ne lance ni lot ni sous-agent de réalisation : il ordonne et arbitre. Toute session qui veut la copie UE (compilation, commandlet, cuisson, éditeur ou MCP) lui demande son tour et attend BUILD-GO ; elle rend la main par BUILD-FIN. Un conflit que deux sessions ne règlent pas entre elles (même fichier, même numéro, priorité entre lots) lui est soumis ; il tranche, ou remonte à l'utilisateur quand la décision lui revient (liste fermée). Ses décisions sont tracées dans etat/BOSS/BOSS-JOURNAL.md (une ligne par demande ou arbitrage).

---

3. Pourquoi deux sessions et des managers conseillers

Le chef doit être une session principale : c'est la seule qui converse avec l'utilisateur. L'orchestrateur aussi : il doit lancer des sous-agents, ce qu'un sous-agent ne peut pas faire. Deux sessions principales se parlent déjà dans ce projet : gel annoncé à toutes les sessions par ListAgents (doc 29, règle 7), passation « session mère / session fille » (etat/OUT1/OUT1-IMPL.md:108, etat/EDIT1/EDIT1-IMPL.md:1).

Le manager ne peut pas lancer son sous-agent. Il rend donc une décision que l'orchestrateur exécute, puis il est repris avec le résultat :

Orchestrateur                      Manager (sous-agent repris)          Sous-agent
  │ 1. lance lp-mgr-x (fiche) ───────▶ étudie, choisit agent/niveau,
  │                                    budget, rédige le brief
  │ ◀──────────────────────────────── ORDRE (agent, modèle, brief)
  │ 2. lance l'agent de l'ORDRE ─────────────────────────────────────▶ exécute
  │ ◀─────────────────────────────────────────────── compte rendu + mesures (outils, jetons, durée)
  │ 3. SendMessage au manager ───────▶ recompte le critère de la fiche
  │                                    (sk-recount), classe la cause
  │ ◀──────────────────────────────── DÉCISION : ACCEPTER | PROLONGER | ESCALADER | ABANDONNER
  │ 4. si PROLONGER / ESCALADER : retour à 2 (4 tentatives au plus)
  │ ◀──────────────────────────────── VERDICT : ACCEPTÉE | ÉCHEC | BLOCKED (+ SUIVI écrit)

L'orchestrateur ne juge pas : il relaie et mesure. Son contexte reçoit un compte rendu d'environ 1 k caractères par lancement (doc 31 § 4.1), plus l'ORDRE et la DÉCISION (quelques lignes) : le coût est faible.

Variante B (non surveillée, plus tard). Le manager, qui a Bash, lance lui-même le sous-agent en session autonome (claude -p --agent <lp-x> --max-turns <n> --output-format json) et lit le résultat. Avantage : vraie hiérarchie et plafond appliqué à l'appel ; inconvénients : CLI à installer et à autoriser sous Git Bash, permissions sans dialogue, aucun suivi dans l'application. Options et comportement à vérifier (AG0-T6, incertain) ; à réserver aux lots longs sans surveillance (D-AG7).

---

4. Déroulé

Le modèle de séquençage reste celui des docs 29 et 30 (0 fiche projet → 1 audit → 2 effort, risques, porte → 3 lots → 4 exécution → 5 évaluation) ; ce document dit qui fait quoi.

Phase A — Cahier des charges et plan (phases 0 à 2)

#	Qui	Action	Trace
A1	utilisateur → chef	demande, objectifs, contraintes	chat du chef
A2	chef	rédige la fiche projet (gabarit des docs 29 / 30) : objectif mesurable, périmètre dans / hors, entrées connues, décisions proposées, dépôts / outils / livrables, critère de sortie	Docs/NN_Projet_<Nom>.md
A3	chef → orchestrateur	[CHEF→ORCH] <PROJ> CDC <chemin>	message
A4	orchestrateur → planificateur	fiche projet + registres existants + règles de taille	—
A5	planificateur	découpe en lots (un objectif mesurable, une famille de causes, une session : doc 10 § 1.2 ; S3 du doc 29) puis en fiches (un résultat vérifiable, ≈ 40 tours, pic ≤ 150 k, ≈ 20 min : SEQ1, doc 31 § 8) ; pour chaque fiche : type SK-T1, note a-f → Nx, manager, agent, dépendances, critère d'acceptation, budget	etat/<projet>/<PROJ>-PLAN.md, <LOT>-TACHES.md (brouillon), fiches/<LOT>-Tn.md
A6	orchestrateur	contrôle : 9 rubriques + 2b remplies, propriétaire de chaque compilation et de chaque commit (doc 22 § 5), critère rejouable, aucune VAL qui écrit la doc qu'elle valide	—
A7	orchestrateur → chef	[ORCH→CHEF] <PROJ> PLAN-A-VALIDER <chemin>	message
A8	chef ↔ utilisateur	ajustements, décisions (liste fermée), porte validée	décisions datées dans la fiche projet
A9	chef → orchestrateur	[CHEF→ORCH] <LOT> LOT-APPROUVÉ (un lot à la fois)	message

Phase B — Exécution d'un lot (phases 3 et 4)

#	Qui	Action
B1	orchestrateur	ouvre le lot (lp-lot) : registre TACHES, ticket TAG <lot>-avant au gardien, Snapshot.ps1 ; gel annoncé si la copie UE est utilisée
B2	orchestrateur	prend les fiches prêtes (dépendances satisfaites) dans l'ordre du registre ; en parallèle si § 8 le permet
B3	orchestrateur + manager	boucle du § 3 pour chaque fiche
B4	orchestrateur	décide de la suite après chaque verdict (§ 7)
B5	orchestrateur	clôture : VAL de lot, DOC (CHG), tickets du gardien (commits, tags, pin ; rien poussé), EVAL ; [ORCH→CHEF] <LOT> FIN-LOT <EVAL>
B6	chef ↔ utilisateur	compte rendu, test en jeu si prévu, lot suivant

---

5. Managers spécialisés

Un manager par famille de types SK-T1 ; le pilotage (A1-A5) reste à l'orchestrateur et au planificateur (A4 / A5 : opus-max lancé par l'orchestrateur, sans manager).

Manager	Types SK-T1	Sous-agents dirigés	Modèle	Skill de famille	Règles propres (sources)
lp-mgr-analyse	B1-B7, J1-J2	lp-inventory, lp-cart (-max), lp-research	sonnet	lp-paths	0 résultat = échec probable ; tout compte recompté par une seconde formulation (SK-T1 A2)
lp-mgr-realisation	C1, D1-D9	lp-spec, lp-impl (-max), lp-tooling, lp-content	opus high	lp-ue-compat	une IMPL finit par un build vert quand la fiche le prévoit (22 § 9.2) ; note d'écarts et « points à confirmer » obligatoires (26 § 6.1)
lp-mgr-build	E1-E5	lp-builder	sonnet	lp-build	une compilation à la fois ; « code 0 sans module recompilé = échec » (lp-build)
lp-mgr-verif	F1-F6	lp-validator, lp-measure	sonnet	lp-validate	VAL par un agent distinct de l'IMPL ; relit toutes les IMPL amont ; F6 jamais confié à N0
lp-mgr-debug	G1-G5	lp-debugger (-max), lp-measure	opus high	lp-build	ordre « préexistant ? → conditions → mesure → correctif » (doc 10 § 3) ; une hypothèse par DIAG
lp-mgr-doc	I1-I3	lp-writer	sonnet	lp-doc	seul manager dont les agents écrivent Journal et Registre : numéros réservés par Repo.ps1 -Reserve, DOC suivie aussitôt du ticket de commit

Les types H1-H5 (intégration) n'ont pas de manager : ils vont au gardien du dépôt (§ 10), sur ticket de l'orchestrateur ; l'agent lp-integrator prévu par SK-ARBRE est remplacé par lp-gardien.

Ce que fait un manager (contenu de sk-manage) :

1. Étudier la fiche : rubriques complètes, type SK-T1, agent et niveau par défaut (SK-ARBRE § 4), surcharge de modèle motivée, disponibilité du modèle (Fable bloqué en VQ, doc 26 § 4), budget du niveau (§ 6).
2. Rendre un ORDRE : agent, modèle, budget (tours, pic), brief = fiche + état de départ + ce que les skills ne contiennent pas (SK-ARBRE § 6.2 point 5).
3. Juger sans croire sur parole : rejouer le critère de la fiche (commande → attendu), vérifier les fichiers écrits et leurs dates, les ajouts non demandés, l'en-tête complet (FAIL-TRACE sinon). Les échecs fabriqués déjà vus (DC4-T1, SB2-T0, « 0 contre 52 ») sont la raison d'être de cette étape.
4. Décider selon le § 6 et tenir <LOT>-Tn-SUIVI.md.
5. Rendre un VERDICT : ACCEPTÉE, ÉCHEC ou BLOCKED, avec preuves, tentatives, coût cumulé et, en cas d'échec, options pour l'orchestrateur.

Formats (une ligne d'en-tête, puis le détail) :

ORDRE <LOT>-Tn tentative k/4 — agent <a> — modèle <m> — budget <t> tours / <p> k — brief : <chemin ou texte>
DÉCISION <LOT>-Tn tentative k/4 — <ACCEPTER|PROLONGER|ESCALADER|ABANDONNER> — cause <budget|capacité|consigne|—> — preuve <commande → résultat>
VERDICT <LOT>-Tn — <ACCEPTÉE|ÉCHEC|BLOCKED-<cause>> — tentatives k — agents <liste> — SUIVI <chemin>

---

6. Budget, tours et reprises

6.1 Budget par niveau (établi : lp-doc/gabarits.md, § TACHES)

Niveau	Tours	Pic de contexte	Plafond dur
N0-N2	40	150 k	maxTurns: 40 dans le frontmatter de l'agent
N3-N5	60	250 k	maxTurns: 60

Aujourd'hui seul maxTurns de lp-builder et lp-inventory est prévu (SK-ARBRE D8) ; il faut le poser sur tous les agents. Les jetons ne se plafonnent pas dans une session : ils sont mesurés (le résultat de l'outil Agent donne outils, jetons et durée, ce que les registres STA / OBA recopient) et jugés par le manager.

Budget tranché par BUD1 (CHG-295, 2026-10-09 23 h 46). Les registres STA et OBA, antérieurs, marquent « hors budget » toute fiche au-delà de 150 k (règle SEQ1) : 12 des 17 fiches closes. Avec la table par niveau de BUD1, en vigueur dans sk-orchestrate § 3, seules 3 le dépassent : STA-T2c (N1, 204 k), OBA-T1 (N1, 167 k), OBA-T5 (N4, 311 k). Le manager applique la table par niveau.

6.2 Classement d'un échec et action

Constat du manager	Cause	Action	Compte
arrêt sur maxTurns ou sur la règle de taille, avec état de reprise et progrès vérifié	budget	PROLONGER : reprendre le même sous-agent par SendMessage (contexte intact) pour une tranche de 50 % du budget nominal ; si la reprise est impossible, relancer le même agent avec l'état de reprise	+1 tentative
résultat faux, succès fabriqué, critère non atteint, même erreur deux fois, réponse « incertain » sur le point demandé	capacité	ESCALADER : arrêter, lancer le niveau supérieur (§ 6.3) avec une fiche -fix (compte rendu échoué, état de reprise, motif)	+1 tentative
fiche ambiguë, prérequis absent, décision utilisateur nécessaire, BLOCKED-UI, hors périmètre, opération destructive non prévue	consigne	ABANDONNER sans reprise : VERDICT BLOCKED-<cause>	—
critère rejoué conforme	—	ACCEPTER	—

Plafond : 4 tentatives par fiche (1 nominale + 3 reprises), dont une seule prolongation par niveau : un agent qui épuise deux fois son budget au même niveau tourne en rond, la reprise suivante est une escalade. Au 4e échec, VERDICT ÉCHEC. La règle « 3 correctifs ratés → remettre l'hypothèse en question » de debug-systematic reste valable à l'intérieur d'une tentative.

6.3 Chaînes d'escalade (d'après SK-ARBRE § 4)

Départ	2e niveau	3e niveau	4e niveau
lp-builder (haiku)	lp-builder (sonnet)	lp-debugger (G3)	lp-debugger-max
lp-inventory (sonnet)	lp-cart	lp-cart-max	fable-top
lp-cart	lp-cart-max	fable-top	—
lp-impl (sonnet, IMPL-L)	lp-impl	lp-impl-max	fable-top
lp-validator (sonnet)	lp-validator (opus)	opus-max	—
lp-writer	lp-writer (opus)	opus-max	—
lp-debugger	lp-debugger-max	fable-top	—

Exemple : CART N3 confiée à lp-cart, arrêt à 60 tours avec état de reprise et 6 clés sur 9 vérifiées → PROLONGER (tentative 2, +30 tours) ; arrêt sans progrès → ESCALADER vers lp-cart-max (tentative 3) ; résultat contredit par le recompte → ESCALADER vers fable-top (tentative 4) ; échec → VERDICT ÉCHEC, l'orchestrateur écrit au chef.

---

7. Décision de l'orchestrateur après un verdict

Verdict	Action par défaut
ACCEPTÉE	fiche suivante du registre (ou groupe de fiches parallèles, § 8)
ÉCHEC ou BLOCKED	suspendre les fiches qui en dépendent ; continuer les fiches indépendantes sans risque ; [ORCH→CHEF] <LOT> CONSIGNES <SUIVI> avec la cause, les options (liste fermée) et une recommandation

L'orchestrateur écrit toujours au chef, même sans échec, pour : un retour arrière (proposé, jamais lancé : doc 10 § 3.4) ; un test en jeu ; un changement de périmètre ou de plan révélé par une fiche ; une décision listée Dx ; un push ; un lot hors budget global (somme des jetons > 1,5 × somme des budgets des fiches, proposition) ; un résultat qui contredit la fiche projet.

---

8. Parallélisme (à la discrétion de l'orchestrateur)

Des fiches partent ensemble seulement si toutes ces conditions tiennent :

1. leurs dépendances (colonne « Dépend de ») sont acceptées ;
2. elles n'écrivent pas les mêmes fichiers ;
3. une seule utilise la copie UE (compilation, commandlet, cuisson, éditeur ou MCP), avec gel annoncé à toutes les sessions (doc 29, règle 7 : « éditeur MCP, commandlets et builds s'excluent ») ; l'ordre de passage entre sessions et projets est fixé par le Big Boss (BUILD-DEMANDE → BUILD-GO, § 9) ;
4. Journal et Registre ne sont écrits que par une fiche à la fois (lp-mgr-doc) ;
5. une IMPL et sa VAL ne tournent jamais ensemble ;
6. au plus 4 sous-agents simultanés (proposition, D-AG5).

Les fiches en lecture seule (INV, CART, recherche) sont les candidates naturelles : précédents STA-T2b (5 lp-cart) et OBA-T23 (4 lp-cart), lancées en parallèle sans incident.

---

9. Fichiers et messages

Fichier	Auteur	Emplacement
Fiche projet (cahier des charges)	chef	Docs/NN_Projet_<Nom>.md (comme 29 et 30)
Plan des lots et portes	planificateur	etat/<projet>/<PROJ>-PLAN.md
Registre du lot	planificateur (brouillon), orchestrateur	etat/<projet>/<lot>/<LOT>-TACHES.md ; colonnes ajoutées : Manager, Tentatives (k/4), Décision
Fiche d'entrée	planificateur	etat/<projet>/<lot>/fiches/<LOT>-Tn.md (gabarit sk-orchestrate § 3) ; aujourd'hui la fiche n'est que le message de lancement (D-AG8)
Suivi d'une fiche	manager	etat/<projet>/<lot>/<LOT>-Tn-SUIVI.md : une ligne par tentative (agent, modèle, budget, tours, jetons, durée, cause, décision)
Livrables	sous-agents	inchangés (gabarits de lp-doc), plus une section « Fichiers à commiter » (IMPL, DOC, BUILD)
Tickets du dépôt	orchestrateur, gardien	etat/REPO/tickets/<LOT>-R<n>.md ; journal etat/REPO/REPO-JOURNAL.md ; numéros etat/REPO/NUMEROS.md
Journal CHG, registre ERR, index, docs numérotées, correctifs/	DOC (lp-writer), orchestrateur	Docs/ de la copie 5.8 (lot DOCMV, CHG-300) ; etat/… ci-dessus = Docs/Migration/etat/…

Messages entre sessions : une ligne, le détail dans un fichier, pour que tout reste lisible après la fermeture d'une session.

[CHEF→ORCH] ST CDC Docs/29_Projet_Stabilisation_V2.md
[ORCH→CHEF] ST PLAN-A-VALIDER etat/ST/ST-PLAN.md
[CHEF→ORCH] GI-A LOT-APPROUVÉ
[ORCH→CHEF] GI-A CONSIGNES etat/ST/GI-A/GI-A-T3-SUIVI.md
[ORCH→CHEF] GI-A TEST-JEU etat/ST/GI-A/GI-A-T6-MESURE.md
[ORCH→CHEF] GI-A FIN-LOT etat/ST/GI-A/GI-A-EVAL.md
[ORCH→BOSS] GI-A BUILD-DEMANDE etat/ST/GI-A/fiches/GI-A-T4.md
[BOSS→ORCH] GI-A BUILD-ATTENTE 2
[BOSS→ORCH] GI-A BUILD-GO
[ORCH→BOSS] GI-A BUILD-FIN
[CHEF→BOSS] ST CONFLIT <objet en une ligne, détail dans un fichier>
[BOSS→CHEF] ST ARBITRAGE <décision> etat/BOSS/BOSS-JOURNAL.md

<SESSION> est le nom vu par ListAgents quand l'émetteur n'est ni chef ni orchestrateur (session de lot, par exemple [STF→BOSS]).

---

10. Gestion du dépôt : un seul gardien

Constat (détail et preuves : AG-T1-CONCEPTION.md § 2.1) : aucun propriétaire des commits, aucun hook, sessions parallèles sur la même branche et le même index (13 commits en 48 min pendant STB), 10 changements de skills commités deux fois (deux branches de l'addon), ETAT2 commité dans les deux copies du jeu, une modification de skill en cours dans la mauvaise copie au moment de la lecture, collisions de numéros CHG et de docs.

Élément	Proposition
Titulaire	lp-gardien (A-INT), seul agent qui écrit dans git ; lancé par l'orchestrateur seul, un ticket à la fois
Demande	les livrables listent « Fichiers à commiter » ; le manager les reprend dans son VERDICT ; l'orchestrateur écrit le ticket etat/REPO/tickets/<LOT>-R<n>.md
Commit	par chemins explicites, sur index privé (GIT_INDEX_FILE) : les fichiers et l'index des autres sessions ne sont jamais emportés ; diff lu en entier ; git show --name-status HEAD = liste du ticket
Garde-fous	hook pre-commit (ticket en cours, identité noreply, Mods/ vide, fichiers interdits) et journal relu à l'EVAL. Pas de règles de refus sur les commandes git dans settings.local.json : elles s'appliquent aussi aux sous-agents lancés depuis la copie, donc au gardien (D-REPO5 révisée le 2026-10-10). git push reste refusé à tous les agents : l'utilisateur pousse
Push	préparé par le gardien, fait par l'utilisateur (pratique actuelle, git push déjà refusé)
Numéros	CHG, ERR, docs réservés par Repo.ps1 -Reserve sous verrou
Branches	actives : ue5.8 du jeu et de l'addon ; gelées : main du jeu 5.5, lot/DC3-atelier de l'addon
Skills et agents	un dépôt de méthode privé unique (skills sk-* et lp-*, agents, hooks, Repo.ps1), relié par jonctions aux deux copies et à ~/.claude : plus de double commit, sk-* et agents enfin versionnés

Brouillons : etat/AG/brouillons/skills/sk-repo, lp-repo, agents/lp-gardien.md. Décisions D-REPO1 à D-REPO8 : AG-T1-CONCEPTION.md § 6. Changements à l'existant (sk-protocol, sk-orchestrate, lp-lot, lp-doc, lp-paths, gabarits, agents, mémoire) : même document, § 3.6.

---

11. Skills et agents à produire

Inventaire et fiches de conception : AG-T1-CONCEPTION.md § 4. Résumé :

Statut	Skills	Agents
Brouillon écrit (etat/AG/brouillons/)	sk-repo, lp-repo, sk-manage, sk-plan, sk-chef, lp-mcp	lp-gardien, lp-planificateur, lp-mgr-realisation
Conçu, à rédiger, P1 (pilote ST)	lp-measure, sk-comparability, debug-systematic (adaptation, revue R1), lp-diag-options	5 autres managers, lp-debugger (+-max), lp-measure, lp-blueprint (MCP)
P2 (projet OB, synthèses)	lp-debug-build (reprise Cursor), ue-commandlet-pattern, sk-estimate	lp-spec, lp-research, lp-tooling, lp-cart-max
P3 (U8 et après)	lp-publish, lp-cook, lp-mods, lp-content-pipelines, ue-* à la demande	lp-content
Absorbé ou abandonné	git-phase-commits, lp-git (→ sk-repo, lp-repo) ; lp-val-profiles (→ lp-validate) ; sk-web-data (→ sk-protocol § 2) ; sk-spec-template (→ gabarit SPEC)	lp-integrator (→ lp-gardien)

Corrections aux agents existants : maxTurns 40 ou 60 sur tous (absent de 8 sur 10), chemin périmé du livrable de lp-builder (etat\U58\<lot>), disallowedTools: AskUserQuestion, ligne « aucune commande git qui écrit ».

---

12. Plan de mise en œuvre (lot AG)

Lot	Contenu	Niveau	Effort
AG0 — tests des mécanismes	T1 : deux sessions locales s'écrivent par SendMessage (nom vu par ListAgents, message reçu) ; T2 : l'orchestrateur reprend un sous-agent par SendMessage, contexte intact ; T3 : un sous-agent n'a pas l'outil Agent (pas d'emboîtement) ; T4 : arrêt sur maxTurns (ce que rend le sous-agent, reprise possible ?) ; T5 : deux sous-agents en parallèle + gel ; T6 : claude -p --agent sk-probe-agent --max-turns 3 --output-format json depuis Git Bash (variante B) ; T7 : la session « Orchestrateur » ne déclenche aucune question à l'utilisateur	N1 + orchestrateur	0,5 séance
AG0-R — essai des garde-fous	hooks sur une copie jetable : commit refusé sans ticket, accepté avec, index commun intact après commit sur index privé, git -C … commit arrêté, journal écrit par post-commit	N1 + orchestrateur	0,25 séance
AG1-R — dépôt, en premier	dépôt de méthode, hook pre-commit installé (Repo.ps1 facultatif, + VAL s'il est écrit), sk-repo, lp-repo, lp-gardien, changements de l'existant (AG-T1-CONCEPTION.md § 3.6) ; ensuite plus aucun commit hors gardien	lp-tooling + lp-validator ; orchestrateur relit	1 séance
AG1 — rédaction	sk-manage, sk-plan, sk-chef, planificateur, 6 managers, maxTurns partout, puis les skills et agents P1 du pilote ST (§ 11) ; relecture contre R9-R12 de SK-ARBRE ; test de type T5a (marqueur) sur un manager	N1 rédige, orchestrateur relit	1 à 1,5 séance
AG2 — pilote	un lot ST réel de la porte G-ST (GI-A, par exemple) mené avec la nouvelle organisation	selon les fiches	1 lot
AG3 — évaluation	indicateurs du doc 31 (§ 3 et § 5) + messages de l'utilisateur par heure, tentatives, escalades, prolongations, contexte de la session du chef ; GO / GO conditionnel / NO-GO	opus-max + lp-writer	0,5 séance

Si AG0-T2 échoue (pas de reprise d'un sous-agent), le manager devient un appel unique par étape (étude, puis jugement) qui relit son SUIVI au lieu de garder son contexte ; le reste ne change pas.

---

13. Décisions à soumettre à l'utilisateur (liste fermée)

#	Décision	Options	Recommandation
D-AG1	Orchestrateur	(a) une session unique commune aux projets ; (b) une par projet ; (c) la session du chef	(a) : elle seule voit toute la copie partagée et peut sérialiser builds et gels entre projets
D-AG2	Managers	(a) 6 managers par famille (l'intégration va au gardien) ; (b) un manager générique, skill de famille nommé dans la fiche ; (c) aucun (l'orchestrateur juge, comme aujourd'hui)	(a)
D-AG3	Plafond	(a) 4 tentatives, une prolongation par niveau ; (b) 3 tentatives	(a) (« 3 ou 4 échecs », 2026-10-10)
D-AG4	Modèle des managers	(a) sonnet, sauf réalisation et débogage en opus ; (b) tous opus ; (c) tous sonnet	(a)
D-AG5	Parallélisme	(a) 4 sous-agents au plus, un seul sur la copie UE ; (b) 2 ; (c) sans limite	(a)
D-AG6	Prolongation	(a) reprise du même sous-agent ; (b) relance neuve avec état de reprise	(a) si AG0-T2 et T4 passent, sinon (b)
D-AG7	Variante B (claude -p)	(a) après le pilote, pour les lots non surveillés ; (b) non	(a)
D-AG8	Fiches d'entrée	(a) fichiers fiches/ lus par managers et sous-agents ; (b) message seulement	(a) : le manager et l'escalade relisent la même fiche
D-AG10	Big Boss	décidé par l'utilisateur (2026-10-10) : session « Big Boss », file de compilation et arbitrage des conflits entre chefs de projet et agents	— ; conséquence sur D-AG1 : l'orchestrateur ne sérialise plus lui-même builds et gels entre projets, il demande son tour au Big Boss

Décisions sur le dépôt : D-REPO1 à D-REPO8, AG-T1-CONCEPTION.md § 6 (forme du gardien, dépôt de méthode, branches gelées, règle git rm, garde-fous, push, main de l'addon, réservation des numéros). Le budget par niveau (ancienne D-AG9) est tranché par BUD1.

---

14. Établi / estimé / incertain

Établi (source citée)

• Budgets par niveau, statuts du registre (reprise, escaladée), gabarits des livrables : lp-doc/gabarits.md.
• 12 agents de rôle, chaînes d'escalade, table type → agent : SK-ARBRE § 3.2 et § 4 ; 8 skills lp-* présents dans l'addon (lu le 2026-10-10).
• Coordination entre sessions par ListAgents et gel : doc 29, règle 7 ; passation de session : OUT1, EDIT1.
• Dépassements de budget STA / OBA (12 / 17 au seuil de 150 k, 3 / 17 avec la table par niveau) : registres cités ; indicateurs avant / après : doc 31.

Estimé

• Coût d'un manager : 10 à 20 tours par fiche (étude, deux à quatre jugements), surtout en sonnet.
• Gain : contexte du chef réduit à la conversation et aux décisions ; moins de reprises non tracées.

Incertain (test qui tranche)

• Interdiction de l'emboîtement de sous-agents : rappel de la documentation Claude Code, page non relue pendant cette rédaction (accès web non accordé) → AG0-T3.
• Reprise d'un sous-agent par SendMessage dans l'application de bureau → AG0-T2, T4.
• Options et résultat JSON de claude -p sous Git Bash → AG0-T6.
• Effet de maxTurns atteint (compte rendu partiel ou coupure) → AG0-T4.

---

15. En vigueur depuis le 2026-10-10 (révision DOCSTAT ; complété le 2026-10-11, lot ORGA1)

Ce qui suit est appliqué. Source principale : etat/BOSS/BOSS-JOURNAL.md (« BOSS l. N » : numéro de ligne au commit du lot DOCSTAT), journal de Big Boss où chaque demande et chaque arbitrage tient sur une ligne. Les § 1 à § 14 restent la conception de référence pour ce qui n'est pas encore en place.

15.1 En place, pas en place

	Éléments	Sources
En place	Big Boss (D-AG10) ; gardien lp-gardien, seul à écrire dans git (skills sk-repo, lp-repo) ; une session par lot, qui orchestre son lot et lance elle-même le gardien sur ticket ; livrables et traces de lot sous Docs\Migration\etat\ de la copie 5.8 seulement	BOSS l. 51, 67 (« aucune session orchestrateur dédiée »), l. 9-10 ; commits AG bdb8f6b, a8dea6d, ee9dce2, 2cca224 (CHG-299)
Pas en place	chef de projet, orchestrateur général unique, planificateur, 6 managers, fichiers SUIVI et fiches/ ; décisions D-AG1 à D-AG8 non tranchées	§ 11, § 13 ; ~/.claude/agents (aucun lp-mgr-* ni lp-planificateur)

15.2 File de compilation

Une seule session à la fois sur la copie UE (compilation, commandlet, cuisson, éditeur ou MCP) : BUILD-DEMANDE, puis BUILD-ATTENTE <rang> ou BUILD-GO, puis BUILD-FIN. Un BUILD-GO par fiche ; jamais deux sessions ensemble sur la copie UE ; le travail hors copie UE reste libre en parallèle. Seul Big Boss prolonge un BUILD-GO en cours. Il contre-vérifie chaque BUILD-FIN (processus Unreal, MD5 des assets, git status) avant le BUILD-GO suivant. Sources : BOSS l. 4-5, 34-35, 65, 99, 108.

Réserve « mesure » : pour une mesure sensible à la charge, Big Boss n'accorde aucun BUILD-GO de compilation, cuisson, paquet ou parcours disque lourd jusqu'au signal de fin de la mesure. Contrôles d'un BUILD-FIN : processus de la copie (UeState.ps1), MD5 des assets (FileCheck.ps1), git status de tout l'arbre, absence de dossier parasite sous etat\, journaux archivés ; un processus lancé sur la copie par une autre session entraîne l'arrêt, un rapport à Big Boss et la fermeture par l'utilisateur, jamais par une autre session (BOSS l. 235-236) ; Tools\CopieEtat.ps1 (à venir, lot OUTC, décision E2) les regroupera. Big Boss annonce la réserve par MACHINE CALME et arrête un GO en plusieurs étapes par PAUSE (un GO par étape). Texte opératoire : lp-lot, annexe boss.md § 1 à § 4. Sources : BOSS l. 222, 227, 235-236, 255, 259, 270, 289.

15.3 Jeton du journal

Un seul rédacteur à la fois de Docs/Journal_Modifications.md : JOURNAL-DEMANDE → jeton accordé par Big Boss → entrée → commit → JOURNAL-LIBRE <hash>. Ordre de disponibilité : qui n'est pas prêt à son tour cède au suivant. Une entrée CHG ne s'écrit que quand son commit est imminent : le gardien vérifie que le diff du journal se réduit à la ligne du ticket (une entrée en attente serait emportée par le commit d'un autre lot). La plage de l'index Docs/README.md suit dans le même commit. Sources : BOSS l. 83, 107, 117, 186.

15.4 Traces du gardien (R-REPO1)

Le gardien écrit le statut fait du ticket et sa ligne de REPO-JOURNAL.md avant le commit et les inclut dans le même commit, sans hash (le journal note le HEAD d'avant ; le hash se retrouve par git log --grep <TICKET>). Précision : les traces d'un ticket sans commit (tag, pin, configuration) partent avec le prochain commit du dépôt, quel que soit le lot ; NUMEROS.md et REPO-JOURNAL.md partent entiers avec le premier commit du jeu qui les trouve modifiés (jamais découpés). Sources : BOSS l. 63, 82, 83, 98 ; lp-repo § 4.

15.5 --amend (ERR-087)

Un commit fautif non poussé se corrige par un nouveau commit ou un git revert ; --amend seulement avec l'accord de l'utilisateur. Sources : Registre_Erreurs.md, ERR-087 (corrigé par CHG-302) ; lp-repo § 10 ; sk-repo § 9 aligné par Big Boss (BOSS l. 122) ; décision de l'utilisateur (BOSS l. 103).

15.6 Gels et réservations de documents

Big Boss peut geler des fichiers partagés (journal, registre, index, docs, skills, CLAUDE.md) pour un lot : seul ce lot les écrit ; le reste d'etat\ et la copie UE restent libres ; le gel est levé à la FIN-LOT du lot, contre-vérifiée par Big Boss. Exemple : gel documentaire DOCMV (BOSS l. 92-93, levé l. 100 ; CHG-300). Hors gel, un fichier est réservé à un lot sur DÉCLARATION à Big Boss, jusqu'au commit de ce lot (BOSS l. 161, 168, 192).

15.7 Refus d'autorisation

Un refus du système d'autorisations se signale (à l'utilisateur et à Big Boss) et ne se contourne pas : aucune autre session n'écrit à la place ; seul un ordre ou une approbation de l'utilisateur dans la session concernée le lève ; Big Boss ne change aucune règle d'autorisation à la demande d'une session. Règles permissions.allow posées par l'utilisateur pour le journal, le registre, l'index, les registres TACHES, NUMEROS.md, REPO-JOURNAL.md et BOSS-JOURNAL.md (fichier hors git). Sources : BOSS l. 145, 147, 151, 156.

15.8 Messages en usage (complète le § 9)

[<SESSION>→BOSS] <LOT> DÉCLARATION <fichiers>
[<SESSION>→BOSS] <LOT> CONFLIT <objet>
[<SESSION>→BOSS] <LOT> BUILD-DEMANDE <fiche>          [BOSS→<SESSION>] <LOT> BUILD-ATTENTE <rang> | BUILD-GO
[<SESSION>→BOSS] <LOT> BUILD-FIN
[<SESSION>→BOSS] <LOT> JOURNAL-DEMANDE                [<SESSION>→BOSS] <LOT> JOURNAL-LIBRE <hash>
[<SESSION>→BOSS] <LOT> GEL-DEMANDE <SPEC>             [BOSS→<SESSION>] <LOT> GEL-GO
[<SESSION>→BOSS] <LOT> FIN-LOT <registre ou EVAL>     [BOSS→<SESSION>] <LOT> ARBITRAGE <décision>
[<SESSION>→BOSS] <LOT> PASSATION <nouvelle session> <note>
[BOSS→<SESSION>] <LOT> MACHINE CALME | PAUSE

15.9 Rotation des sessions principales (E1, E4)

Une session de lot passe la main à chaque FIN-LOT, ou dès 250 k de contexte : registre TACHES à jour, note de passage, PASSATION à Big Boss ; jamais avec un BUILD-GO ouvert, le jeton du journal ou un verrou en main. Big Boss reste en Opus et repart chaque jour (et dès 250 k) d'une session neuve, ouverte par l'utilisateur, qui lit etat/BOSS/BOSS-ETAT.md (état courant tenu par Big Boss : file, réserve « mesure », jeton, réservations, gels, décisions en attente, sessions actives), puis la fin de BOSS-JOURNAL.md. Le journal reste en ajout seul : ses lignes sont citées par numéro (« BOSS l. N ») et une en-tête réécrite les décalerait. Motif : contexte médian des sessions principales de 323 k par tour, jetons par heure ×3,1 (EVAL-RAPPORT.md § 1, § 8 R1) ; mesure de contrôle : contexte médian < 200 k. Texte opératoire : lp-lot/boss.md § 8 ; sk-orchestrate § 4.

Complément du 2026-10-14 (lot AMEL1, EVAL2-RAPPORT.md § 3 G3, § 4 R1, F1 = a). La rotation s'applique à TOUTE session principale, à chaque FIN-LOT ou dès 250 k de contexte (seuil par session, décision de l'utilisateur du 2026-10-14), avec une passation écrite obligatoire avant d'ouvrir la nouvelle session (BOSS-ETAT.md ou <LOT>-ETAT à jour, jetons tenus, sessions en cours, reprise). Mesure de contrôle inchangée : contexte médian < 200 k. Motif : STE vivante 79,6 h, 13 sessions sur 25 au-dessus de 250 k, médian 295 k (P3).

15.10 Règles de fiche (E5)

Un critère d'entrée ou d'acceptation n'est jamais recopié d'une fiche précédente ; la fiche nomme la copie visée par son chemin absolu ; la faisabilité d'un test utilisateur est vérifiée avant de le soumettre ; une VAL de lot se découpe par famille de livrables, un diagnostic lp-cart porte une hypothèse par fiche, une EVAL de lot se confie en N2 au moins. Motif : 4 reprises d'OBB sur 4 de cause consigne, U8-T6, lp-cart hors budget dans 55 % des cas (EVAL-RAPPORT.md § 3, § 4, R5, R6). Texte opératoire : sk-orchestrate § 3.

15.11 Où vivent ces règles

Protocole Big Boss (§ 15.2 à § 15.8) et rotation : lp-lot/SKILL.md (résumé) et lp-lot/boss.md (détail), dans les deux addons (LifePlay-Sandbox-5.8, branche ue5.8 ; LifePlay-Sandbox, branche lot/DC3-atelier, chargée par la copie 5.8 par jonction). Règles de fiche et rotation : sk-orchestrate (~/.claude/skills, copie identique dans l'addon 5.8). Ce § 15 reste la référence datée et sourcée ; en cas d'écart, le signaler à Big Boss.

15.12 Traces et journaux des sessions

Règle de l'utilisateur (2026-10-13), mise en place par le lot TRACE1. Les traces (Insights .utrace, profilage, dumps, sorties de commandlets, plantages d'une fiche) et les journaux de commandes (compilation, UAT, cuisson, commandlets, jeu, éditeur) sont périssables : on ne les conserve pas, on en garde un court résumé (contexte, résultat, suite). Chaque lot écrit à sa FIN-LOT etat\<projet>\<lot>\<LOT>-TRACES.csv, une ligne par fiche qui a produit des traces ; les fichiers restent où ils ont été produits. Le passage mensuel (session TRACE-AAAA-MM, le 1er du mois) reporte ces lignes dans Docs\Migration\etat\TRACES\TRACES-INDEX.csv, complète les résumés manquants, commite l'index, puis envoie à la corbeille de Windows, sur accord de l'utilisateur, les traces de plus d'1 mois (Tools\Traces.ps1 pour la liste, Tools\Corbeille.ps1 pour l'envoi, à blanc d'abord) ; jamais rm, del ni Remove-Item ; un refus d'autorisation arrête le passage sans contournement (§ 15.7). Hors règle : transcriptions des sessions Claude (copiées avant la suppression d'une session par Tools\SauverTranscriptions.ps1 -Session <id>, décision de l'utilisateur « Copier avant suppression », 2026-10-14 ; lp-lot), livrables .md / .csv, builds, instantanés de Snapshot.ps1, journaux tournants des outils d'Epic dans le profil (UBT, UHT, Zen, UnrealTrace, Launcher, CrashReportClient). Aucune trace ni aucun chemin C:\Users\<compte> dans un fichier commité. Le vidage automatique de la corbeille par l'assistant de stockage de Windows (30 jours sur ce poste) reste au choix de l'utilisateur ; aucune session ne touche ce réglage. Sources : etat/AG/TRACE1/TRACE1-T1-INV.md, TRACE1-T2-PROPOSITION.md (révision 1, approuvée par l'utilisateur le 2026-10-13), TRACE1-T3-SPEC.md ; scripts validés par TRACE1-T4cv-VAL.md ; premier passage TRACE1-T7-IMPL.md (202 éléments, 7 538 Mo) ; commits 3967e9d (index initial, 334 lignes) et TRACE1-R2 (statuts).

15.13 Rôle de Big Boss recentré, journal horodaté, sessions renommées (lot AMEL1, 2026-10-14)

Décisions de l'utilisateur du 2026-10-14 sur EVAL2-RAPPORT.md § 5 (F1 = a, F5 = a). Texte opératoire : lp-lot/SKILL.md, lp-lot/boss.md § 0 et § 8, lp-doc/gabarits.md.

• Big Boss tient la file de la copie UE, les arbitrages, les GO, les jetons et l'ordre des tickets. Il garde sans les déléguer la copie du journal du jeu avant toute relance, la contre-vérification des MD5 et de UeState avant chaque BUILD-GO, le passage des jetons et la réservation des numéros. La fiche de tests commune et le bilan d'essai sont rédigés par un lp-writer à partir des gabarits FIT et BILAN ; Big Boss lui remet une entrée de bilan de 5 à 10 lignes (gabarit ENTREE). Cible : part de Big Boss dans les jetons ≤ 15 % (clause D-P7.8).
• BOSS-JOURNAL : chaque ligne porte l'heure AAAA-MM-JJ HH:MM (heure locale). P3 : 86 lignes sur 462 en portaient une.
• Registres *-TACHES.md : colonnes Tours et statut tenues (statut acceptée ou reprise (<fiche b>) écrit à la réception). P3 : mesurable sur 16 fiches sur 52.
• Sessions : une session réutilisée est renommée au titre du lot qu'elle sert, à chaque changement de lot (règle de l'utilisateur du 2026-10-12, mémoire sessions-reutilisees, désormais dans lp-lot). P3 : 3 sessions sur 25 sous un mauvais titre.
• Chaîne de vérification longue d'un build (R14, option B de l'utilisateur) : au-delà de 50 étapes, VAL séparée (lp-build § 9).