LifePlay-Revival/Docs/34_Transposition_Projet7.md

# 34 — Transposition du dispositif « Projet 7 » à LifePlay

- **Date :** 2026-10-12 | **Statut :** adopté en partie, décisions D-P7.1 à D-P7.17 tranchées par l'utilisateur le 2026-10-12 | **Entrée journal :** `CHG-333` | **Lot :** P7
- **Numéro de doc :** 34 (réservé sous verrou dans `etat/REPO/NUMEROS.md`, lot P7). Les § 1 à 8 reprennent la
  proposition du 2026-10-12 sans changement (historique, `etat/AG/P7-TRANSPOSITION.md`) ; les résultats du lot sont au § 9.
- **Rédaction :** session claude.ai liée au poste, lecture seule ; seul ce fichier est écrit. Aucun skill, agent,
  réglage ni dépôt modifié.
- **Sources lues, projet 7** (`E:\Download\7 - Organisation Agents`, version 0.4.0 du 12/10/2026) : `README.md`,
  `CONTEXT.md`, `Architecture.md` (1.3.0), `définition des objectifs.md` (§ Lot 0, § Gardes 1-4, § Discipline de
  contexte, § Workflow, § Non garanti), skills `protocole-agents`, `decoupage-objectif`, `sonde-empirique` (§ 1-2),
  `archivage-traces` (§ 1-3), `verification-non-regression` (§ 1-2), `repo-map` (§ 1-2) ; agents `aks-gardien`,
  `aks-mgr-realisation`, `aks-sonde` ; hooks `git-gardien.py`, `ecriture-gardien.py` ; `settings.json` ;
  `traces/OBJ-04/barreaux-echelle.md` ; en-tête de `workflows/objectif-aks.js`. Non lus : les 5 journaux OBJ, le
  `Cahier des Charges.md`, le `Référentiel.md`, les 19 autres agents, les skills `methode-spirale`,
  `journal-operations`, `cloudbolt-cmp`, `surveyjs`, `pytest-playwright-testing`.
- **Sources lues, LifePlay** (état du 2026-10-12, HEAD `78d9ce6`) : doc 32 § 15 (en vigueur), doc 33 (évaluation 72 h),
  `git log`, `etat/REPO/` (9 tickets, 5 verrous), `etat/AG/`, agents `~/.claude/agents` (copie `Documents\agents`).

---

## 1. Résumé

Les deux projets ont été conçus la même semaine, à partir des mêmes idées (niveaux, fiches, gardien unique, quatre
tentatives, budget de tours) et ont divergé sur ce que chacun a mesuré. **LifePlay a résolu le problème de la copie
partagée** (Big Boss, file de compilation, jeton du journal, verrou, tickets) que le projet 7 n'a pas, parce qu'AKS
n'a ni éditeur Unreal ni plusieurs sessions sur un même arbre. **Le projet 7 a résolu le problème du coût par appel**
(98,6 % de cache rechargé, enveloppe de sortie, contexte vidé après succès, transmission directe entre agents,
séparation des pouvoirs par `tools`) que LifePlay vient de mesurer sans l'avoir encore traité : doc 33 note 130 M de
jetons lus par heure, un contexte médian des sessions principales à 323 k, et « N2 qui fait du N0 ».

Six apports du projet 7 sont transposables tels quels ou presque (§ 3), quatre demandent une adaptation (§ 4), trois
sont à écarter (§ 5). Ils s'inscrivent dans les recommandations déjà retenues du doc 33 (E1 rotation, E2 outils, E5
règles de fiche) et les complètent plutôt qu'ils ne les contredisent. Un lot **P7** en quatre étapes (§ 6), **9
décisions** (§ 7).

---

## 2. Correspondance des deux dispositifs

| Sujet | Projet 7 (AKS) | LifePlay (doc 32 § 15, doc 33) | Écart |
|---|---|---|---|
| Orchestration | session principale, « n'est pas un agent », ne garde que les VERDICT | une session principale **par lot**, plus **Big Boss** (arbitre de la copie partagée, Opus) | LifePlay a un étage de plus, justifié par la copie UE partagée |
| Chef de projet | l'utilisateur, point G5b bloquant avant tout commit | l'utilisateur, porte par lot ; accord cité dans le ticket seulement pour push, restore, histoire | AKS bloque **chaque** commit ; LifePlay commite sur VAL PASS |
| Gardien | `aks-gardien`, haiku low, **6 tours**, `tools: [Bash]` seul, hook `git-gardien.py` sur `agent_type` | `lp-gardien`, sonnet, 50 tours, Edit pour tickets / journal / pin, verrou `mkdir`, 48 passages, 0 commit sans ticket | LifePlay plus lourd (index privé, verrou, multi-dépôts) ; AKS a le hook actif, LifePlay pas encore (R11) |
| Niveaux | **11 barreaux** modèle × effort (haiku low → opus max), identifiants explicites, un cran à la fois, aucune réalisation > N4 | N0-N5 (haiku, sonnet, opus xhigh, opus max, fable), alias `sonnet` / `opus` dans les agents | AKS étale l'effort ; LifePlay saute de sonnet à opus xhigh |
| Barème | 5 critères sur 15, **calibré à rebours** sur 7 objectifs ; ≥ 13 → scinder, pas escalader | grille a-f sur 12, non calibrée (doc 33 : les reprises viennent des consignes, pas des agents) | AKS a une courbe de décroissance mesurable (C3, C4 par `grep`) |
| Budget | `maxTurns` 6 à 46 selon le barreau ; enveloppe en **jetons de sortie** ; prolongation 50 % ne compte pas comme tentative | 40 / 60 tours, pic 150 / 250 k, `maxTurns` 50 / 75 ; prolongation = une tentative par niveau | AKS plus serré d'un facteur 2 à 3 ; compte les sorties, pas le pic |
| Contexte | un agent, une session, **contexte vidé après succès** ; transmission directe agent → agent ; fichier seulement si le contenu traverse la session principale ou lui survit | livrables en fichiers systématiques (gabarits), comptes rendus ≈ 1 k ; rotation des principales à 250 k (E1) | AKS a une règle de contexte par agent ; LifePlay par session |
| Séparation des pouvoirs | analyse / production / rapport portés par **trois agents**, frontière par `tools` ; hook `ecriture-gardien.py` bloque `sed -i`, `tee`, redirections pour les non-rédacteurs | VAL ≠ IMPL, VAL ≠ DOC (agents sans Edit) ; un seul Write pour le livrable | LifePlay a la règle, pas le hook ; pas d'agent « rapporteur » distinct |
| Messages | 4 formats, 6 états, refus d'un message hors format **dans le format attendu en retour** | messages `[SESSION→BOSS]`, ORDRE / DÉCISION / VERDICT (conçus, pas en place) | AKS a `RELAIS_APRES_ETUDE` (options transmises) et `À verser` (retour dans la skill) |
| Preuve | `Mesuré` = sorties brutes collées ; sonde empirique avant toute hypothèse ; note de contexte obligatoire sur chaque trace | `sk-recount`, `debug-verification`, résumés `Build.ps1` ; doc 33 § 5 : 538 empreintes improvisées contre 60 `FileCheck.ps1` | AKS a une règle de trace datée (« `603 passed` valait `619` deux jours après ») |
| Mesure | référence OBJ-00 **avant** le dispositif, critère d'arrêt écrit à l'avance, `session-report` par sous-agent et par skill | docs 31 et 33 après coup, scripts maison `eval_*.py`, pas de critère d'arrêt | AKS est falsifiable ; LifePlay mesure mais ne s'est pas fixé de seuil de renoncement |
| Workflow scripté | `objectif-aks.js` : `pipeline()`, `parallel()`, compteurs ; s'arrête à G5b | aucun | à essayer sur un lot de type STB (Blueprint par MCP) |

---

## 3. Transposable tel quel (six apports)

### 3.1 Enveloppe de contexte par agent : vider après succès, transmettre directement
Règle AKS : *« une tâche réussie consomme une enveloppe, et une seule »* ; après succès, l'agent n'est pas repris ;
après échec, le manager choisit entre reprendre (contexte gardé) et abandonner (nouvel appel). Entre agents, on
transmet le contenu ; on n'écrit un fichier que s'il traverse la session principale ou lui survit.
**Chez LifePlay** : doc 33 mesure 414 livrables pour 79 CHG et 108 M jetons par heure dans les principales. Une part
vient des fichiers intermédiaires relus. Transposition : garder les livrables qui **font preuve** (CART, VAL, BUILD,
INT, EVAL, DIAG) et transmettre directement ce qui ne sert qu'au maillon suivant (dossier d'entrée, plan d'IMPL,
tableau de delta). À écrire dans `sk-protocol` § 3 et `lp-doc/gabarits.md`. **Attention** : la prolongation LifePlay
(même agent repris) est précisément l'exception « échec » d'AKS ; les deux règles sont déjà compatibles.

### 3.2 `Mesuré` = sorties brutes, et note de contexte sur chaque trace
*« Un compte rendu qui reconstitue un chiffre est un échec de protocole »* ; chaque trace archivée porte commande,
environnement, résultat attendu **écrit avant de lancer**, résultat obtenu, piège de lecture. **Chez LifePlay** :
`sk-recount` recompte après coup ; la note de contexte manque (les relevés `etat/<lot>/*.txt` n'ont pas de
« attendu avant »). Transposition : section « Mesuré » dans le gabarit de compte rendu (`sk-protocol` § 3, point 3
renforcé : *collé, jamais reformulé*) et un gabarit de note de trace dans `lp-doc/gabarits.md` (5 champs). Coût : nul.
Gain attendu : les reprises de cause consigne (OBB 4/4, U8) viennent en partie de critères relus hors contexte.

### 3.3 État `RELAIS_APRES_ETUDE` et champ `Options`
À la moitié des tours sans sortie brute nouvelle : arrêter de raisonner, chercher dehors (doc à la version, web),
comparer 2-3 options en tableau, conclure ou passer la main **avec les options**. L'agent suivant ne repaie pas la
recherche. **Chez LifePlay** : la mémoire `feedback-web-research-first` et `sk-protocol` § 2 disent « recherche web
d'abord » sans déclencheur ni format de sortie ; `sk-manage` (brouillon) classe l'échec en budget / capacité /
consigne sans ce quatrième cas. Transposition : déclencheur `maxTurns / 2` dans `sk-protocol` § 8, état
`RELAIS_APRES_ETUDE` ajouté aux six issues du compte rendu et à la table de décision de `sk-orchestrate` § 4
(cause : connaissance → escalade **avec** `Options`, consomme une tentative).

### 3.4 Champ `À verser` : la boucle d'apprentissage
Chaque compte rendu nomme ce qui doit enrichir une skill, et laquelle. **Chez LifePlay** : la règle existe (« chaque
échec produit une ligne dans le skill concerné », `sk-orchestrate` § 5 ; U8-EVAL § 5 traité par U8P) mais à l'EVAL
de lot, donc tard et agrégé. Transposition : ligne `À verser` obligatoire dans le compte rendu (`sk-protocol` § 3),
reprise par l'orchestrateur dans le registre `TACHES` (colonne nouvelle) et versée par la fiche DOC de clôture.

### 3.5 Hook `ecriture-gardien` : la séparation des pouvoirs dans le harnais
Mesure AKS : un agent déclaré sans Edit a **tenté** `sed -i` hors dépôt et refusé dans le dépôt ; « la séparation
reposait sur l'humeur du modèle ». Le hook `PreToolUse` sur Bash lit `agent_type` et refuse `cp`, `mv`, `tee`,
`sed -i`, redirections aux agents hors liste blanche. **Chez LifePlay** : `sk-protocol` § 7 interdit l'édition par
script, et EDIT1 a compté 588 éditions par script Python avant la règle. Le même hook, avec la liste des rédacteurs
LifePlay (`lp-impl`, `lp-impl-max`, `lp-writer`, `lp-gardien`, `lp-tooling`, `lp-content`), s'installe dans
`.claude/settings.json` des deux copies. Il complète `git-gardien.py`, équivalent du `pre-commit` conçu pour
LifePlay (R11) mais côté harnais : les deux couvrent des accidents différents (le hook git protège l'index ; le hook
`agent_type` protège avant même l'appel). **Limite** connue et écrite par AKS : `python -c`, `pwsh -Command`,
`node -e` passent. Comme pour `pre-commit`, dire « empêche l'accidentel », jamais « garantit ».

### 3.6 Identifiants de modèle explicites, barreaux éprouvés
AKS a trouvé que `sonnet` résolvait vers `claude-sonnet-4-6`, inaccessible à **ce** compte : six agents sur dix ne
démarraient pas, sans signal avant le premier appel réel. **Chez LifePlay** : les 11 agents portent les alias
`haiku`, `sonnet`, `opus`, `fable` ; ils démarrent (260 sous-agents sur 72 h), donc le compte LifePlay résout
autrement. Le risque n'est pas le même, mais la méthode est reprise : un agent jouet par barreau, une fois, résultat
archivé avec sa note (compte, version du CLI), avant d'étendre l'échelle (§ 4.1). Vérification en 11 appels de
`-p "ping"`, à faire avant tout autre point de ce document.

---

## 4. Transposable avec adaptation (quatre apports)

### 4.1 Échelle à barreaux serrés (modèle × effort)
AKS étale l'effort de chaque modèle avant de changer de modèle : N0-N2 haiku, N3-N6 sonnet, N7-N10 opus. Avec quatre
tentatives, une fiche gravit N3 → N6 sans jamais toucher opus. **Chez LifePlay** l'échelle saute de sonnet (N1) à
opus xhigh (N3) ; `lp-cart` est hors budget dans 55 % des cas et consomme 40 % des jetons des sous-agents (doc 33
§ 4). Deux barreaux intermédiaires (`sonnet high`, `sonnet xhigh`) donneraient une marche entre N1 et N3 pour les
CART et DIAG, et `opus medium` une entrée dans opus moins chère que xhigh. **Adaptation** : ne pas renuméroter
N0-N5 (toute la documentation LifePlay les cite) ; ajouter des demi-niveaux `N1+` (sonnet high), `N2+` (sonnet xhigh,
hors session principale), `N3−` (opus medium) comme variantes d'agents (`lp-cart` → `lp-cart` sonnet xhigh par
défaut, `lp-cart-max` inchangé), après l'épreuve § 3.6. La règle AKS « on monte d'un cran à la fois » devient :
escalade = barreau suivant, pas niveau suivant.

### 4.2 Barème calibré à rebours et courbe de décroissance
AKS a noté ses 7 objectifs passés avec un barème à 7 critères, constaté qu'il ne discriminait pas (4 critères
constants), et l'a réduit à 5 critères dont deux ne décrivent pas la tâche mais **l'état du projet** (couverture par
skill, précédent), constatables par `grep`. **Chez LifePlay** la grille a-f n'a jamais été confrontée aux issues
réelles ; doc 33 établit pourtant un jeu de données : 260 sous-agents, leurs budgets, leurs reprises, les EVAL de
lot. **Adaptation** : une fiche `lp-inventory` note à rebours 30 fiches de P1-P2 (issue connue : acceptée, reprise,
escaladée, hors budget) avec a-f **et** avec C3 / C4 / C5 d'AKS ; on garde les critères qui séparent les reprises des
succès. Hypothèse à vérifier : chez LifePlay, le critère discriminant sera « consigne » (reprises OBB 4/4, U8),
c'est-à-dire l'équivalent du C9 d'AKS (spécification connue avant de coder). Règle AKS à reprendre telle quelle :
**au-dessus du seuil, scinder la fiche au lieu d'escalader** (déjà dans `sk-orchestrate` § 3 « Taille » pour le
budget, pas pour la complexité).

### 4.3 Rapporteurs et exécutants distincts
AKS sépare celui qui écrit (`aks-webhook-plugin`) de celui qui rapporte le diff contre le plan (`aks-dev-rapporteur`,
lecture seule) et de celui qui lance les tests (`aks-test-executant`, haiku low, 6 tours) et celui qui les lit
(`aks-test-rapporteur`). **Chez LifePlay** `lp-builder` lance **et** rapporte (il recopie le résumé de `Build.ps1`), et
la VAL relit l'IMPL. Le découpage AKS a un coût (deux appels, deux contextes) que LifePlay vient de chiffrer : 0,7 M
jetons par passage du gardien, ≈ 27 k de démarrage par fiche. **Adaptation** : ne pas dédoubler `lp-builder`
(`Build.ps1` produit déjà le résumé compté, c'est le rapporteur) ; en revanche, pour les diagnostics Blueprint par
MCP (lot MCPA, agent `lp-mcp` à venir), séparer **sonde** (lecture, MCP) et **rédacteur** (correctif par outils Epic)
comme `aks-sonde` / rédacteur : c'est là que le mélange lecture-écriture a coûté (STB, ERR-057).

### 4.4 Mesure de référence et critère d'arrêt
AKS a mesuré son coût par objectif **avant** le dispositif, depuis les transcriptions, et a écrit : *« si après deux
objectifs le dispositif coûte plus cher que la référence sans réduire les anomalies trouvées après coup, il est
réduit ou abandonné »*. **Chez LifePlay** la référence existe (doc 31 « avant », doc 33 P0-P1) mais aucun seuil de
renoncement n'est écrit, et doc 33 § 7 fixe des cibles sans conséquence si elles sont manquées. **Adaptation** :
ajouter au doc 33 § 7 une clause d'arrêt par mécanisme : *Big Boss est réduit à la file de compilation si son coût
reste > 15 % de la période après E1 et E2 ; les demi-niveaux (§ 4.1) sont retirés si le taux hors budget de
`lp-cart` ne baisse pas sous 30 % sur 20 fiches ; le hook `ecriture-gardien` est retiré s'il produit plus de refus
légitimes que de refus utiles sur un lot.* Écrit maintenant, avant le lot P7, « pendant que c'est encore
désintéressé ».

---

## 5. À écarter (trois points)

| Point AKS | Pourquoi pas chez LifePlay |
|---|---|
| Point G5b : **accord de l'utilisateur avant chaque commit** | LifePlay fait 4 commits par heure active avec un gardien et une VAL par fiche ; un accord par commit multiplierait les messages utilisateur (déjà 10 / h, doc 33). Garder la règle LifePlay : accord cité seulement pour push, restore, histoire, branche gelée. |
| Gardien haiku à 6 tours, `tools: [Bash]` seul | Le gardien LifePlay tient 4 dépôts, un index privé, un verrou, des tickets chaînés et le pin addon → jeu ; 48 passages à 0 % hors budget en sonnet. Le réduire ferait remonter la vérification dans la session principale (le « N2 qui fait du N0 » de doc 33). |
| Plugin `session-report`, `serena`, MCP `context7` / `microsoft-docs` | Dépendent d'un marketplace et d'un compte entreprise ; LifePlay a ses scripts `eval_*.py` (à encapsuler, R7) et un moteur UE sans LSP utile. À réévaluer si le marketplace devient accessible ; ne rien attendre d'ici là. |

Un quatrième point reste ouvert : **une seule session principale** (AKS) contre **une par lot + Big Boss**
(LifePlay). AKS n'a pas de copie partagée ; LifePlay ne peut pas revenir en arrière sans perdre la file de
compilation (0 MD5 changé sur 32 BUILD-FIN). Doc 33 E1 (rotation) traite déjà le coût de ce choix.

---

## 6. Lot P7 (proposition)

| Étape | Contenu | Agent | Préalable |
|---|---|---|---|
| P7-T1 | Épreuve des barreaux (§ 3.6) : 11 appels, un agent jouet par barreau, trace avec note (compte, CLI, date) | lp-builder (haiku) | — |
| P7-T2 | `sk-protocol` : § 3 `Mesuré` collé, `Options`, `À verser` ; § 8 déclencheur `maxTurns / 2` et `RELAIS_APRES_ETUDE` ; `sk-orchestrate` § 4 : cause « connaissance », scinder au-dessus du seuil ; `lp-doc/gabarits.md` : note de trace, colonne `À verser` | lp-writer | P7-T1 |
| P7-T3 | Hook `ecriture-gardien.py` adapté (liste des rédacteurs LifePlay, pwsh et Git Bash), essai sur copie jetable (même protocole que AG0-R), installation par ticket dans `.claude/settings.json` des deux copies | lp-tooling, puis lp-gardien | D-P7.3 |
| P7-T4 | Calibrage à rebours : 30 fiches de P1-P2 notées a-f et C3 / C4 / C5 / C9, issue réelle en regard ; rapport et barème proposé | lp-inventory (relevé), opus-max (analyse) | — |
| P7-T5 | Demi-niveaux `N1+`, `N2+`, `N3−` : variantes d'agents, escalade par barreau, mise à jour de `sk-orchestrate` § 1 | lp-writer | P7-T1, D-P7.1 |
| P7-T6 | Clause d'arrêt par mécanisme au doc 33 § 7 ; EVAL du lot P7 avec les scripts `eval_*.py` | lp-writer, puis EVAL en N2 | P7-T2 à T5 |

Le lot n'ouvre **aucune** fiche de réalisation sur le jeu : il ne touche que les skills, les agents, les hooks et
les docs. Budget estimé : une séance et demie ; T4 est la seule fiche longue.

---

## 7. Décisions à soumettre (liste fermée)

| # | Décision | Options | Recommandation |
|---|---|---|---|
| D-P7.1 | Échelle | (a) demi-niveaux `N1+` / `N2+` / `N3−` comme variantes d'agents ; (b) renumérotation complète en 11 barreaux ; (c) inchangée | **(a)** : garde la numérotation citée partout, donne une marche à `lp-cart` |
| D-P7.2 | Contexte des sous-agents | (a) vider après succès, transmettre directement, fichier seulement pour ce qui fait preuve ; (b) livrables en fichiers systématiques (actuel) | **(a)** ; les gabarits de preuve (CART, VAL, BUILD, INT, EVAL, DIAG) restent des fichiers |
| D-P7.3 | Hook d'écriture | (a) `ecriture-gardien` sur `agent_type`, liste blanche des rédacteurs ; (b) consigne seule (actuel) | **(a)**, après l'essai sur copie jetable ; installé avec le `pre-commit` (R11) |
| D-P7.4 | `RELAIS_APRES_ETUDE` | (a) quatrième cause d'échec, avec `Options` transmises ; (b) non | **(a)** |
| D-P7.5 | Barème | (a) calibrage à rebours sur 30 fiches avant tout changement ; (b) adopter le barème AKS tel quel ; (c) garder a-f | **(a)** : le barème AKS est calibré sur AKS (n = 7) ; LifePlay a plus de données |
| D-P7.6 | Rapporteur distinct | (a) seulement pour la chaîne MCP (sonde / rédacteur) ; (b) partout comme AKS ; (c) nulle part | **(a)** |
| D-P7.7 | Point G5b | (a) règle LifePlay inchangée (accord pour push, restore, histoire) ; (b) accord avant chaque commit | **(a)** |
| D-P7.8 | Critère d'arrêt | (a) une clause par mécanisme au doc 33 § 7 ; (b) aucune | **(a)** |
| D-P7.9 | Épreuve des barreaux | (a) avant tout (P7-T1) ; (b) seulement si un agent échoue au lancement | **(a)** : 11 appels, une trace, aucun risque |

---

## 8. Établi / estimé / incertain

- **Établi** : contenu des fichiers du projet 7 cités en tête ; état LifePlay au doc 32 § 15, doc 33 § 2-6 ;
  `git log` et `git status` du 2026-10-12 ; alias de modèle dans les 11 agents LifePlay (`Documents\agents`).
- **Estimé** : gain de D-P7.2 sur les jetons des principales (doc 33 n'isole pas la part des relectures de
  livrables) ; coût de P7-T4 (une demi-séance pour 30 fiches) ; hypothèse « consigne = C9 » du § 4.2.
- **Incertain** : résolution des alias de modèle sur le compte LifePlay (§ 3.6, tranché par P7-T1) ; comportement
  du hook `agent_type` sous pwsh 7 et Git Bash avec des chemins contenant une espace (P7-T3) ; pertinence des
  demi-niveaux tant que le barème n'est pas calibré (P7-T4 avant P7-T5 serait plus sûr ; ordre laissé à
  l'orchestrateur).

---

## 9. Résultats du lot P7

Décisions D-P7.1 à D-P7.9 : toutes (a) ; D-P7.10 à D-P7.17 ajoutées en cours de lot (`etat/AG/P7/P7-DECISIONS.md`). Livrables sous `etat/AG/P7/`.

| Fiche | Résultat | Livrable |
|---|---|---|
| T1 | 12 couples modèle × effort sur 12 répondent ; modèle réel lu dans `modelUsage`, effort non observable | `P7-T1-INV.md` |
| T2 | VAL des révisions hors fiche : PASS avec réserves, d'où D-P7.12 à D-P7.14 | `P7-T2-VAL.md` |
| T3a | hook appelé dans le harnais réel ; partielle (refus prouvé par rejeu de la charge seulement) | `P7-T3a-INV.md` |
| T3a2 | PASS : refus du hook constatés avec appel réel Bash et PowerShell | `P7-T3a2-INV.md` |
| T3b | hook installé pour la copie 5.8 seulement, sans fiche ; incident : script absent, commandes Bash et PowerShell refusées quelques minutes, rétabli ; copie 5.5 sans objet (D-P7.17) | registre `P7-TACHES.md` |
| T4a | 30 fiches P1-P2 relevées (28 colonnes) | `P7-T4a-INV.md`, `data/bareme.csv` |
| T4b | note a-f non discriminante (rho +0,14), taille = C3 + f ; essai D-P7.16 | `P7-T4b-EVAL.md` |
| T5 | demi-niveaux : `lp-cart` (sonnet), `lp-cart-max`, `lp-diag` (opus medium) ; `sk-orchestrate` § 1 ; déployés | `P7-T5-DOC.md` |
| T6a | À verser V1-V13 et essai D-P7.16 versés dans 7 skills, jumeaux dans l'addon 5.5 | `P7-T6a-DOC.md` |
| T7 | `unreal-api-mcp` 0.3.1 : NON ADOPTABLE (PASS-STATIC), roue jamais installée | `P7-T7-VAL.md` |
| T8 | non ouverte : porte G0 (compte, cadre) à l'utilisateur ; reste au registre des reports (doc 21) | — |
| T9 | corrections D-P7.10, .12, .13, .14 appliquées en trois passes (agent, session P7 sur ordre, utilisateur) | `P7-T9-DOC.md` |
| T9v | VAL de T9 : PASS avec réserves de forme | `P7-T9-VAL.md` |
| T10 | `sk-protocol` et `sk-orchestrate` déployés dans le profil par l'utilisateur, MD5 = addon | `P7-T10-DOC.md` |
| T6 | DOC de clôture : ce doc 34, clause d'arrêt au doc 33 § 7, index, registre | `P7-DOC.md` |

D-P7.6 et D-P7.7 : sans fiche (chaîne MCP au lot MCPA ; règle G5b de LifePlay inchangée). D-P7.13 : le texte appliqué dit « moitié du budget de tours de la fiche (rubrique 9) » et non `maxTurns / 2` ; retenu par l'orchestrateur, à confirmer par l'utilisateur. Clause d'arrêt (D-P7.8) et essai D-P7.16 : doc 33 § 7.