23 KiB
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), skillsprotocole-agents,decoupage-objectif,sonde-empirique(§ 1-2),archivage-traces(§ 1-3),verification-non-regression(§ 1-2),repo-map(§ 1-2) ; agentsaks-gardien,aks-mgr-realisation,aks-sonde; hooksgit-gardien.py,ecriture-gardien.py;settings.json;traces/OBJ-04/barreaux-echelle.md; en-tête deworkflows/objectif-aks.js. Non lus : les 5 journaux OBJ, leCahier des Charges.md, leRéférentiel.md, les 19 autres agents, les skillsmethode-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(copieDocuments\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 logetgit statusdu 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_typesous 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.