Fiche AMEL1-W — Niveau N1 — Modèle prévu sonnet | utilisé claude-sonnet-5-5 — Agent lp-writer — Skills sk-protocol, lp-doc, lp-lot # AMEL1-W-TEXTES : textes proposés (avant / après) pour R1, R5 à R9, R11 à R14 (2026-10-14) Hors gabarit : ce livrable propose des textes, il n'en applique aucun. Les sections 1 à 6 suivent le gabarit DOC ; le corps (les textes) est dans `## Constats`. Rien n'a été écrit dans un skill, un agent, le doc 32 ni la mémoire. Les textes « Avant » sont recopiés des fichiers lus ce jour ; les numéros de ligne sont ceux de la lecture du 2026-10-14. Racines : `SK` = `D:\Game\LifePlay-Sandbox-5.8\Tools\claude\skills` ; `AG` = `%USERPROFILE%\.claude\agents` ; `DOCS` = `D:\Game\LifePlay-master 5.8\Docs` ; `ETAT` = `D:\Game\LifePlay-master 5.8\Docs\Migration\etat`. Le complément de Big Boss (3 réserves, message du coordinateur) est intégré tel quel dans R1. ## 1. Fichiers écrits - `D:\Game\LifePlay-master 5.8\Docs\Migration\etat\EVAL2\AMEL1\AMEL1-TEXTES.md` (ce fichier, créé). - Aucun autre fichier. ## 2. Numéros utilisés (CHG, ERR, doc) sans objet : aucune entrée de journal ni de registre écrite. Les changements ci-dessous, une fois approuvés, auront chacun leur CHG (réservé dans `ETAT\REPO\NUMEROS.md` par l'orchestrateur) et leur retour arrière (§ « Retour arrière commun »). ## 3. Index, plages et registre des reports mis à jour sans objet : aucun doc numéroté créé ; le doc 32 n'est modifié que si l'utilisateur approuve R1 / R11 / R12 (changements D1, D2). ## 4. Écarts à la fiche - Les consignes « script écrit par Write » ne s'appliquent pas telles quelles aux agents sans Edit (voir Contradictions C3) : le texte proposé pour `lp-inventory` et `sk-windows-shell` en tient compte. - Rien d'autre. ## 5. Fichiers à commiter - A `Docs/Migration/etat/EVAL2/AMEL1/AMEL1-TEXTES.md` (dépôt du jeu 5.8, branche `ue5.8`). Aucun fichier partagé touché. ## 6. À verser À verser : sans objet pour cette fiche (c'est elle qui prépare les versements) ; les contradictions du § C ci-dessous sont à trancher avant écriture. Tours : 9 / 40 ## Constats ### A. Synthèse : nombre de changements par fichier | Fichier | Changements | Recommandations | |---|---|---| | `SK\lp-lot\SKILL.md` | 4 (L1 rôle de Big Boss et rotation, L2 brouillon, L3 PubCheck, L4 renommage) | R1, R5, R6, R12 | | `SK\lp-lot\boss.md` | 4 (B1 rôle, B2 contrôles BUILD-FIN, B3 rotation, B4 horodatage) | R1, R5, R6, R11, R12 | | `SK\lp-doc\gabarits.md` | 8 (G1 fiche de tests, G2 bilan, G3 entrée de bilan, G4 brouillon, G5 TACHES, G6 DOC, G7 BUILD, G8 VAL) | R1, R3, R5, R6, R8, R11 | | `SK\lp-doc\SKILL.md` | 2 (D1 brouillon, D2 liste des gabarits et registre) | R5, R11 | | `SK\lp-validate\SKILL.md` | 3 (V1 PubCheck, V2 témoin en jeu, V3 `python -c` à retirer) | R6, R8, R7 | | `SK\sk-windows-shell\SKILL.md` | 2 (S1 section « code en ligne », S2 redirections) | R7 | | `SK\lp-paths\SKILL.md` | 1 (P1 pièges de poste) | R7, R13 | | `AG\lp-inventory.md` | 1 (A1) | R7, R13 | | `SK\sk-orchestrate\SKILL.md` | 2 (O1 fiche `lp-cart`, O2 surcharge du modèle) | R9 | | `SK\lp-build\SKILL.md` | 1 (LB1) | R14 | | `AG\lp-builder.md` | 1 (AB1, seulement si l'option A de R14 est choisie) | R14 | | `DOCS\32_Organisation_Agents.md` | 2 (DOC1 complément du § 15.9, DOC2 nouveau § 15.13) | R1, R11, R12 | | `ETAT\BOSS\BOSS-JOURNAL.md` (hors git) | 1 (J1 règle d'horodatage) | R11 | | **Total** | **33** | | ### B. Contradictions et points à trancher (textes actuels contre recommandations) | # | Texte actuel | Contredit | Traitement proposé | |---|---|---|---| | C1 | `lp-validate/SKILL.md` l. 42 : `python -c "import json;json.load(open('LifePlay.uproject'))"` | R7 (jamais `python -c`) | changement V3 | | C2 | `sk-windows-shell/SKILL.md` l. 31 recommande `> f 2>&1` et `Tee-Object` ; `lp-build/SKILL.md` l. 54 écrit `> "$log" 2>&1` (commande 5.5) | le crochet refuse `>` et `tee` aux agents | S2 (note) ; l. 54 de `lp-build` non modifiée, signalée (commande pour la copie 5.5, session principale) | | C3 | `sk-protocol` § 7 : un agent sans Edit n'utilise Write que pour son livrable ; les scripts à usage répété vont dans `Saved//` ou `Tools/` | R7 « script écrit par Write » | pour les agents sans Edit (`lp-inventory`, `lp-validator`, `lp-builder`, `lp-cart`) : Read pour un JSON ; un script n'est pas écrit par l'agent, il est fourni par la fiche (rubrique 4) ; sinon arrêt et demande. Pour les sessions principales et les agents avec Edit : script écrit par Write | | C4 | `lp-doc/gabarits.md` l. 90-92 : les quatre colonnes de mesure du registre sont remplies « à la clôture » par `FicheStats` | R11 (colonnes Tours et statut tenues) | G5 : statut écrit à chaque réception, `FicheStats` lancé après chaque VAL PASS | | C5 | `sk-orchestrate/SKILL.md` l. 49-50 : « Une fiche qui demande plus que le budget de son niveau est coupée en deux fiches, pas dotée d'un budget plus grand » ; `lp-builder` : `maxTurns: 50`, budget ≈ 40 | R14 (budget 60 tours) : 60 dépasse le plafond 50 de l'agent (la règle donne plafond = budget + 25 %, soit 75) | LB1 propose d'abord l'option B (VAL séparée, sans contradiction) ; l'option A (60 tours) exige `maxTurns: 75` et une exception à la règle de coupe : décision de l'utilisateur | | C6 | `sk-orchestrate/SKILL.md` l. 20 et l. 67 autorisent la surcharge du modèle (« `haiku` par surcharge pour un relevé trivial ») | R9 (pas de surcharge sans motif écrit) | O2 : la surcharge reste permise, avec motif écrit en 2b | | C7 | « Rotation à 250 k de contexte médian » (consigne du coordinateur) : le médian est une mesure d'ensemble (I1c, cible < 200 k), pas un seuil par session | `lp-lot` l. 68 et doc 32 § 15.9 disent « dès 250 k de contexte » (par session) | textes proposés : seuil par session = 250 k de contexte ; le médian reste la mesure de contrôle. À confirmer | | C8 | G3 (entrée de bilan) : « citation exacte de l'utilisateur » | « aucun contenu de jeu dans les docs publiques » (`etat/` est suivi en texte par git) | G3 : la citation reste exacte ; un nom ou un texte du jeu y est remplacé par `[…]`, l'original restant dans la transcription. À confirmer | | C9 | La règle « sessions réutilisées sous le titre du lot » n'existe que dans la mémoire (`sessions-reutilisees.md`) ; aucun skill ni doc ne la porte (Grep `réutilis\|renomm` sans résultat dans les skills et les docs 32-33) | R12 | L4, B3 et DOC2 la posent ; la mémoire renvoie ensuite au skill (usage de `lp-doc`, § Mémoire) | | C10 | Aucune. `doc 32 § 15.3` (« Une entrée CHG ne s'écrit que quand son commit est imminent ») ne contredit pas R5 : le brouillon vit dans `etat///`, pas dans le journal ; les textes R5 le disent | — | — | Retour arrière commun : pour les fichiers suivis par git (doc 32, `gabarits.md`, skills de l'addon) : `git revert` du commit du ticket `AMEL1-` ; pour un fichier non suivi (agents, `%USERPROFILE%\.claude\skills`, `BOSS-JOURNAL.md`) : restaurer depuis l'instantané `.\Tools\Snapshot.ps1 -Lot AMEL1-` pris avant l'écriture (`.\Tools\Restore.ps1 -Lot AMEL1- -WhatIf` d'abord, accord de l'utilisateur). Les deux exemplaires de skills (addon 5.8 et copie du profil) restent identiques. Écrire des skills ou des agents : le mode auto le refuse souvent, prévoir le geste de l'utilisateur (`lp-lot`, § Avant toute modification). --- ### R1. Recentrer Big Boss (indicateurs I1a, I1b, I1c ; fiches de tests et bilans : I3, I8b) #### L1 : `SK\lp-lot\SKILL.md`, section « Copie UE partagée, Big Boss et rotation » (l. 62-71), bullet « Rotation » (l. 68-71) Indicateur : I1a, I1b, I1c. Avant (l. 68-71) : ```` - Rotation : à chaque `FIN-LOT`, ou dès 250 k de contexte, la session principale passe la main (registre à jour, note de passage, `PASSATION` à Big Boss), jamais avec un GO ouvert, le jeton ou un verrou en main. Big Boss (Opus) : session neuve chaque jour, ouverte par l'utilisateur, qui repart de `etat\BOSS\BOSS-ETAT.md` (état courant), puis de la fin de `etat\BOSS\BOSS-JOURNAL.md` (ajout seul). ```` Après (deux bullets remplacent celui-ci) : ```` - Rôle de Big Boss (AMEL1, R1) : la file de la copie UE, les arbitrages, les GO, les jetons (copie UE et journal), la réservation des numéros, l'ordre des tickets du gardien. Il garde lui-même, sans les déléguer à un `lp-writer` : la copie du journal du jeu avant toute relance ; la contre-vérification des MD5 et de `UeState` avant chaque `BUILD-GO` ; le passage du jeton de la copie UE et du jeton du journal ; la réservation des numéros ; l'ordre des tickets du gardien. Il ne rédige ni la fiche de tests commune ni le bilan d'essai : un `lp-writer` les rédige à partir des gabarits FIT et BILAN de `lp-doc/gabarits.md`. Big Boss lui remet une « entrée de bilan par Big Boss » (gabarit ENTREE : 5 à 10 lignes, cas, verdict, citation exacte de l'utilisateur, heure) ; le `lp-writer` ne lit pas sa transcription. - Rotation de TOUTE session principale (session de lot, Big Boss, session d'évaluation) : à chaque `FIN-LOT`, ou dès 250 k de contexte. Une passation écrite est obligatoire avant d'ouvrir la nouvelle session : état à jour (`etat\BOSS\BOSS-ETAT.md` pour Big Boss ; registre `-TACHES.md` et `-ETAT` ou note de passage pour une session de lot), jetons tenus (copie UE, journal) ou rendus, sessions en cours, point de reprise ; puis `PASSATION` à Big Boss. Jamais avec un GO ouvert, le jeton ou un verrou en main. Big Boss (Opus) : session neuve chaque jour, ouverte par l'utilisateur, qui repart de `etat\BOSS\BOSS-ETAT.md` (état courant), puis de la fin de `etat\BOSS\BOSS-JOURNAL.md` (ajout seul). Mesure de contrôle : contexte médian des sessions principales < 200 k (`boss.md` § 8). ```` Contradiction : aucune avec le texte actuel (il disait « la session principale » ; la fiche d'EVAL2 G3 montre qu'il n'était pas appliqué). Voir C7. #### L4 : `SK\lp-lot\SKILL.md`, même section, nouveau bullet après les deux ci-dessus (R12, I12) Avant : (rien ; la règle n'existe que dans la mémoire, voir C9). Après : ```` - Session réutilisée (R12) : une session reprise pour un autre lot est renommée, dans l'application, au titre du lot qu'elle sert, dès le message de reprise et à chaque changement de lot ; le message de reprise le rappelle et la `PASSATION` cite le titre. Une session saturée (≥ 250 k) ne se réutilise pas : elle passe la main (bullet précédent). ```` #### B1 : `SK\lp-lot\boss.md`, en-tête (l. 1-7), nouvelle section « 0 » après la ligne 7 Indicateur : I1a, I1b. Avant (l. 5-7, dernière phrase de l'en-tête) : ```` 5.8\Docs\Migration\etat\`. ```` (suivie d'une ligne vide puis de `## 1. Messages`). Après (insertion entre les deux) : ```` ## 0. Rôle de Big Boss (AMEL1, R1, 2026-10-14) Big Boss tient : la file de la copie UE, les arbitrages, les GO, les jetons (copie UE, journal), la réservation des numéros et l'ordre des tickets du gardien. Il garde sans les déléguer : (1) la copie du journal du jeu avant toute relance ; (2) la contre-vérification des MD5 et de `UeState` avant chaque `BUILD-GO` (§ 4) ; (3) le passage des jetons ; (4) la réservation des numéros ; (5) l'ordre des tickets. Il ne rédige pas la fiche de tests commune ni le bilan d'essai : un `lp-writer` les rédige à partir des gabarits FIT et BILAN (`lp-doc/gabarits.md`). Big Boss remet au `lp-writer` une entrée de bilan (gabarit ENTREE) ; le `lp-writer` ne lit pas la transcription de Big Boss. `BOSS-ETAT.md` et `BOSS-JOURNAL.md` restent tenus par Big Boss. ```` #### B3 : `SK\lp-lot\boss.md`, § 8 « Rotation des sessions », bullet « Session de lot » (l. 97-100) et dernier bullet (l. 108) Indicateur : I1c. Avant (l. 97-100) : ```` - **Session de lot** : passation à chaque FIN-LOT, ou dès 250 k de contexte si le lot n'est pas fini. Avant : BUILD-FIN, JOURNAL-LIBRE, verrou rendu, sous-agents terminés avec compte rendu. Contenu : registre TACHES à jour (statuts, état de reprise), note de passage (dossier de notes fourni par l'application ; sinon `etat\\\-PASSATION.md`), `PASSATION` à Big Boss. La session suivante repart du registre et de la note, pas de la transcription. ```` Après : ```` - **Toute session principale (session de lot, session d'évaluation)** : passation à chaque FIN-LOT, ou dès 250 k de contexte si le lot n'est pas fini, sans exception (STE est restée vivante 79,6 h ; 13 sessions sur 25 au-dessus de 250 k). Avant : BUILD-FIN, JOURNAL-LIBRE, verrou rendu, sous-agents terminés avec compte rendu. Passation écrite obligatoire avant d'ouvrir la nouvelle session : registre TACHES à jour (statuts, état de reprise), `-ETAT` ou note de passage (dossier de notes fourni par l'application ; sinon `etat\\\-PASSATION.md`) avec les jetons tenus ou rendus, les sessions en cours et le point de reprise, puis `PASSATION` à Big Boss. La session suivante repart du registre et de la note, pas de la transcription. Une session reprise pour un autre lot est renommée au titre du lot qu'elle sert (R12). ```` Et, pour Big Boss (bullet « Big Boss », l. 101-107, après la phrase « La rotation est faite par l'utilisateur (il archive la session et en ouvre une neuve). ») : ajouter « La passation écrite est `BOSS-ETAT.md` à jour (jetons, sessions en cours, reprise) avant l'ouverture de la session neuve. » (Le texte actuel liste déjà ces éléments pour `BOSS-ETAT.md` ; l'ajout rend l'écriture préalable obligatoire.) #### DOC1 : `DOCS\32_Organisation_Agents.md`, § 15.9 (l. 492-501), ajout après le paragraphe « Motif » (l. 500-501) Indicateur : I1a, I1b, I1c. Ajout seul, le § 15.9 n'est pas réécrit. Avant (dernière ligne du § 15.9, l. 501) : ```` R1) ; mesure de contrôle : contexte médian < 200 k. Texte opératoire : `lp-lot/boss.md` § 8 ; `sk-orchestrate` § 4. ```` Après (ajout d'un paragraphe) : ```` **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, avec une passation écrite obligatoire avant d'ouvrir la nouvelle session (`BOSS-ETAT.md` ou `-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). ```` #### DOC2 : `DOCS\32_Organisation_Agents.md`, nouveau § 15.13 après le § 15.12 (fin du fichier, après l. 535) Indicateur : I1a, I1b, I11a, I12. Un doc daté, ajout seul ; une entrée CHG et la mise à jour de l'index ne sont pas nécessaires (pas de nouveau doc) mais le journal consigne le changement. Avant : (fin du fichier) : ```` (202 éléments, 7 538 Mo) ; commits `3967e9d` (index initial, 334 lignes) et TRACE1-R2 (statuts). ```` Après (ajout) : ```` ### 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 ()` é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. ```` #### Mémoire (information, hors compte) `sessions-reutilisees.md` : ajouter à la fin « Texte opératoire : `lp-lot/SKILL.md` (bullet « Session réutilisée »), doc 32 § 15.13 », pour que la mémoire renvoie au skill (usage de `lp-doc`, § Mémoire du projet). Fichier hors du livrable, proposé seulement. --- ### Gabarits de `SK\lp-doc\gabarits.md` (R1, R3, R5, R6, R8, R11) Insertion proposée : les quatre nouveaux gabarits G1 à G4 juste après le gabarit `TACHES` (avant `## TRACE`, l. 101). #### G1 : nouveau gabarit « FIT — fiche de tests commune » (R1, R3, R8 ; indicateurs I3, I8a, I8b) Avant : (n'existe pas ; S3 du rapport : 12 fiches différentes, validations implicites 32, en bloc 24). Après : ```` ## FIT — fiche de tests commune (lp-writer, à partir des fiches de lot ; Big Boss ne la rédige pas) Fichier `etat/BOSS/COMMUN--TESTS.md`. Tête commune (deux lignes), puis : 1. Build testé : chemin absolu du build et de l'exe, MD5 ou taille, date, lots et CHG / ERR couverts. 2. Faisabilité : pour chaque cas, la fonction ou le réglage existe dans ce build (`sk-orchestrate` § 3, « Test utilisateur ») ; sauvegarde et copie d'essai prêtes (`lp-validate` § 5) ; machine calme ou réserve « mesure ». 3. Cas : un tableau, un cas par ligne, numérotés `COMMUN-.` : | Cas | Lot | Correctif (CHG / ERR / ticket) | Action de l'utilisateur | Attendu | Contrôle automatique du journal | Verdict | Découvreur | Heure | - Contrôle automatique : motif cherché dans le journal de jeu et résultat attendu, lancé avant la remise par `Tools\EssaiJournal.ps1` quand il existe (AMEL1-R3) ; sinon `sans objet : `. - Verdict, Découvreur et Heure restent vides à l'écriture ; le BILAN les remplit. Verdict : `PASS`, `KO`, `KO partiel`, `non joué`. Découvreur : `utilisateur`, `agent` ou `script`. Heure : `HH:MM`. 4. Cas témoins : les VAL `PASS-STATIC` qui nomment un cas (`lp-validate` § 6) : cas → VAL (chemin). Aucun contenu de jeu (textes, noms) : décrire l'action par sa fonction, pas par ses mots. ```` #### G2 : nouveau gabarit « BILAN — bilan d'essai » (R1, R3, R8 ; indicateurs I3, I8b, I11a) Avant : (n'existe pas ; O5 : bilans après coup, C8-C10 écrits ensemble, C13 + 104 min). Après : ```` ## BILAN — bilan d'essai (lp-writer, écrit dans l'heure qui suit la fin de l'essai) Fichier `etat/BOSS/COMMUN--BILAN.md`. Sources : la fiche FIT, l'entrée ENTREE de Big Boss, les journaux et résumés cités. Le rédacteur n'ouvre pas la transcription de Big Boss. 1. Essai : fiche FIT, build, début et fin `HH:MM`, qui a joué, heure d'écriture du bilan (écart avec la fin de l'essai ≤ 60 min, sinon le dire). 2. Verdict par cas : | Cas | Verdict | Heure | Découvreur (`utilisateur`, `agent`, `script`) | Preuve (citation de l'entrée, ou `chemin:ligne` du journal) | 3. KO horodatés : un par ligne : heure `HH:MM`, cas (ou `hors fiche`), symptôme observé, découvreur, ligne ajoutée au brouillon du journal (`-JOURNAL-BROUILLON.md`). 4. Report sur les VAL : | Cas | VAL (chemin) | Verdict statique | Verdict en jeu | Écart |. Le rédacteur ajoute à chaque VAL concernée une ligne datée `Suite en jeu : COMMUN-. ()` ; la VAL elle-même n'est pas réécrite (le validateur n'y revient pas). 5. Contrôles automatiques : résultat de `Tools\EssaiJournal.ps1` par cas, ou `sans objet : `. 6. Suite : build suivant, fiches `-fix`, décisions qui reviennent à l'utilisateur. ```` #### G3 : nouveau gabarit « ENTREE — entrée de bilan par Big Boss » (réserve de Big Boss n° 2 ; indicateur I1a) Avant : (n'existe pas). Après : ```` ## ENTREE — entrée de bilan par Big Boss (Big Boss, 5 à 10 lignes) Fichier `etat/BOSS/COMMUN--ENTREE.md`. Hors gabarit de tête : une liste, rien d'autre. Une ligne par cas : `COMMUN-. | verdict (PASS, KO, KO partiel, non joué) | « citation exacte de l'utilisateur » | HH:MM`. 5 à 10 lignes. Big Boss la remet au `lp-writer` (chemin cité dans la fiche), qui rédige le BILAN sans lire la transcription de Big Boss. Une citation n'est jamais reformulée ; si elle contient un nom ou un texte du jeu, il est remplacé par `[…]` (l'original reste dans la transcription). ```` Point à confirmer (C8) : le caviardage `[…]` limite « exacte » ; l'utilisateur peut préférer garder la citation entière dans un fichier non publié. #### G4 : nouveau gabarit « BROUILLON — journal au fil de l'eau » (R5 ; indicateurs I5a, I5b) Avant : (n'existe pas ; S5 : ≈ 29 h sans CHG ni ERR, 50 ERR en un seul commit). Après : ```` ## BROUILLON — `-JOURNAL-BROUILLON.md` (session de lot ou lp-writer ; ajout seul) Fichier `etat///-JOURNAL-BROUILLON.md`, écrit à chaque BUILD-FIN et à chaque KO. Deux tableaux : CHG (brouillon) : | Heure du fait (AAAA-MM-JJ HH:MM) | Lot | Fichiers | Raison (fait observable + preuve) | Avant → après | Retour arrière | Versé | ERR (brouillon) : | Heure du fait (AAAA-MM-JJ HH:MM) | Signature | Source | Fréquence mesurée | Gravité | Lot cible | Statut | Versé | - Pas de numéro : `CHG-NNN` et `ERR-NNN` sont réservés dans `etat/REPO/NUMEROS.md` au versement, jamais avant (`lp-doc`). Colonne Versé : vide, puis `CHG-n` / `ERR-n` une fois la ligne versée. - Le brouillon n'est pas le journal (doc 32 § 15.3 : l'entrée CHG ne s'écrit qu'à l'approche du commit). Une correction = une nouvelle ligne, on ne réécrit pas le passé. - La date du fait est celle de l'événement, pas celle de l'inscription : elle permet de mesurer le rattrapage. ```` #### G5 : gabarit TACHES, paragraphe « Colonne « Tours » » (l. 93-94) (R11 ; indicateur I11b) Avant (l. 93-94) : ```` Colonne « Tours » : des tours seulement (`sk-protocol` § 8), ceux que mesure `FicheStats` (les agents sous-comptent : OBB, 12 fiches sur 15) ; le nombre d'outils, s'il est noté, va dans une note ou la colonne Statut, jamais dans « Tours ». ```` Après (ajout à la suite) : ```` Tout registre `*-TACHES.md` suit ce gabarit avec **toutes** ses colonnes dès l'ouverture, Tours et Statut compris (STG, CAM et STE ne l'ont pas fait : mesurable sur 16 fiches sur 52). Le statut est écrit à chaque envoi et à chaque réception (`acceptée`, `reprise ()`, …), jamais en bloc à la clôture ; `python -I Tools/FicheStats.py --lot ` est lancé après chaque VAL PASS pour renseigner Tours, Pic, Jetons et Durée, pas seulement à la clôture. Un registre sans ces colonnes est refusé à la réception. ```` Contradiction C4 : le texte actuel (l. 89-90 : « remplies par `FicheStats` à la clôture ») est étendu, pas retiré. #### G6 : gabarit DOC, rubrique 2 (R5) Avant (l. 56-57) : ```` 1. Fichiers écrits (chemins). 2. Numéros utilisés (CHG, ERR, doc), réservés à ce lot dans `etat/REPO/NUMEROS.md`, et commande de contrôle. ```` Après : ```` 1. Fichiers écrits (chemins). 2. Numéros utilisés (CHG, ERR, doc), réservés à ce lot dans `etat/REPO/NUMEROS.md`, et commande de contrôle ; si le lot a un `-JOURNAL-BROUILLON.md`, les lignes versées (brouillon → numéro), la colonne Versé mise à jour. ```` #### G7 : gabarit BUILD (R5, R6) Avant (l. 47-48) : ```` `Tools/Build.ps1 -FromLog`). 5. Toolchain (`lp-env`). 6. Preuve de chargement si addon (`lp-build`). 7. Journal archivé (chemin). Rien n'est corrigé ici. ```` Après : ```` `Tools/Build.ps1 -FromLog`). 5. Toolchain (`lp-env`). 6. Preuve de chargement si addon (`lp-build`). 7. Journal archivé (chemin). 8. PubCheck : commande et ligne `PubCheck : constat(s)` sur le livrable BUILD et sur les résumés `.md` du tour. 9. Lignes pour le brouillon du journal (faits mesurés, une par changement ou KO ; la session les verse) : `sans objet : ` si aucun fait. Rien n'est corrigé ici. ```` #### G8 : gabarit VAL (R6, R8) Avant (l. 53) : ```` `PASS` | `PASS-STATIC` | `FAIL` | `BLOCKED-*`. 6. Points à confirmer par l'utilisateur (cases). ```` Après : ```` `PASS` | `PASS-STATIC` | `FAIL` | `BLOCKED-*`. 6. Points à confirmer par l'utilisateur (cases). 7. PubCheck : commande et sortie sur les livrables relus. 8. Témoin en jeu : pour chaque correctif de comportement en `PASS-STATIC`, la ligne `Témoin en jeu : COMMUN-.` (ou `sans objet : ` pour une VAL sans correctif de comportement). ```` --- ### R5. Brouillon du journal (indicateurs I5a, I5b) #### L2 : `SK\lp-lot\SKILL.md`, section « Livrables et registres », nouveau bullet avant « Registre des reports » (l. 89) Avant (l. 89) : ```` - Registre des reports : liste unique de `21_Sandbox_Addon.md` ; chaque « reste à faire » y entre avec un lot ```` Après (bullet inséré avant) : ```` - **Brouillon du journal (AMEL1, R5).** À chaque `BUILD-FIN` et à chaque KO constaté, la session de lot (ou un `lp-writer`) écrit ou complète `etat\\\-JOURNAL-BROUILLON.md` (gabarit BROUILLON de `lp-doc/gabarits.md`) : une ligne CHG par changement fait, une ligne ERR par KO, avec l'heure du fait et sans numéro. Ce n'est pas le journal : les numéros se réservent dans `NUMEROS.md` au versement. Au commit, sous jeton (`JOURNAL-DEMANDE`), la DOC verse les lignes dans `Journal_Modifications.md` et `Registre_Erreurs.md` et marque la colonne Versé. Repère : plus de 4 h d'activité sans écriture au brouillon (ni CHG, ni ERR) est un écart à signaler à Big Boss. ```` #### D1 : `SK\lp-doc\SKILL.md`, nouvelle section après « Registre : `Docs/Registre_Erreurs.md` » (avant « Docs numérotées », l. 46) Avant (l. 44-46) : ```` portage, build 5.5 validé pour U58). Ne pas clore sans CHG ni validation en jeu quand le défaut est visuel. ## Docs numérotées `Docs/NN_Titre.md` ```` Après : ```` portage, build 5.5 validé pour U58). Ne pas clore sans CHG ni validation en jeu quand le défaut est visuel. ## Brouillon : `etat///-JOURNAL-BROUILLON.md` (AMEL1, R5) Écrit à chaque BUILD-FIN et à chaque KO (gabarit BROUILLON de `gabarits.md`) : lignes CHG et ERR sans numéro, avec l'heure du fait. Le versement au journal et au registre se fait par la DOC, sous jeton, quand le commit est imminent, avec les numéros réservés dans `NUMEROS.md` ; la ligne versée porte `CHG-n` / `ERR-n` en colonne Versé. Une correction du brouillon = une nouvelle ligne. Un ERR versé plus de 24 h après l'heure de son fait compte comme rattrapage (indicateur I5a du plan AMEL1). ```` #### B2 : `SK\lp-lot\boss.md`, § 4 « Contrôles exigés à chaque BUILD-FIN » (R5, R6) Avant (l. 66) : ```` 5. Journaux et résumés archivés sous `etat\\\`, cités par chemin. ```` Après : ```` 5. Journaux et résumés archivés sous `etat\\\`, cités par chemin. 6. Brouillon du journal à jour : lignes CHG / ERR de ce tour dans `-JOURNAL-BROUILLON.md` (R5), ou `sans objet : `. 7. PubCheck : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers ` rend 0 (R6) ; sortie citée dans le message `BUILD-FIN`. ```` Et, deux lignes plus bas (l. 67), la phrase « regroupera 1 à 4 en une commande » reste exacte : 6 et 7 ne sont pas dans `CopieEtat.ps1`. --- ### R6. PubCheck dès la fiche (indicateur I6) Syntaxe lue dans l'en-tête de `D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1` (l. 1-33) : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers [ …]` (le premier chemin après `-Fichiers`, les suivants en arguments restants) ; codes 0 net, 1 constat, 2 erreur ; sortie `::` puis `PubCheck : constat(s)` ; les valeurs cherchées (nom du compte, machine) ne sont jamais imprimées. Lancé depuis la racine du jeu 5.8. #### L3 : `SK\lp-lot\SKILL.md`, section « Commits et dépôts » (l. 58-60) Avant : ```` Avant de déposer un ticket, l'orchestrateur lance `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers ` (0 exigé, cité au ticket) ; un livrable ne cite jamais le nom du compte : ``, `%USERPROFILE%`, motif lu dans `$env:USERNAME`. ```` Après : ```` Dès qu'un livrable est écrit (VAL, BUILD-FIN, DOC), son rédacteur lance `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers ` depuis la racine du jeu 5.8 (R6) et cite la ligne `PubCheck : 0 constat(s)` dans le livrable (1 = constat à corriger avant de rendre, 2 = erreur à rapporter). Avant de déposer un ticket, l'orchestrateur le relance sur `` (0 exigé, cité au ticket) ; un livrable ne cite jamais le nom du compte : ``, `%USERPROFILE%`, motif lu dans `$env:USERNAME`. ```` #### V1 : `SK\lp-validate\SKILL.md`, § 1 « Diff (statique) », bullet après le bullet « Tag annoté » (après l. 47) Avant (l. 47, fin du dernier bullet de § 1, après lequel l'insertion se fait) : ```` `git rev-parse ^{commit}`. `git diff ` et `git show :` n'en ont pas besoin. Source : lot OBP (OBP-T2), `OBB-EVAL.md` § 6 P10 ; `OBB-T3-VAL.md` Constats 3. ```` (Ancre à re-citer à l'écriture : la fin du bullet est la phrase `Source : lot OBP (OBP-T2), …Constats 3.` de la l. 47.) Après (bullet inséré à la suite) : ```` - **Fuite de donnée personnelle (R6)** : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers ` depuis la racine du jeu 5.8. Attendu : `PubCheck : 0 constat(s)`, code 0. Code 1 : écart numéroté (catégorie et `fichier:ligne`, jamais la valeur) ; code 2 : `BLOCKED-pubcheck`. Citer la commande et la sortie dans la VAL. ```` Indicateur : I6. --- ### R7 et R13. Consignes de shell et pièges de poste (indicateurs I7a, I7b, I13) #### S1 : `SK\sk-windows-shell\SKILL.md`, nouvelle section avant « ## Interdits » (l. 40) Avant (l. 38-40) : ```` - Un script à `ValidateSet` appelé en `-File` peut refuser l'argument (liste `-Kind Editeur,Compilation` passée en une seule chaîne) : `pwsh -NoProfile -Command "& '