561 lines
45 KiB
Markdown
561 lines
45 KiB
Markdown
# 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 <projet> » | 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).
|