Fiche AMEL1-W3 — Niveau N1 — Modèle prévu sonnet | utilisé claude-sonnet-5-5 — Agent lp-writer — Skills sk-protocol, lp-doc, lp-lot
# AMEL1-W3-TEXTES : corrections des résidus de la VAL V1a et règle A5 (textes proposés, 2026-10-14)

Hors gabarit : ce livrable propose des textes (avant / après exacts), il n'en applique aucun ; rien n'est écrit dans un skill.
Sources : `AMEL1-V1a-VAL.md` § V4 (résidus a à c) ; règle A5 (décision de l'utilisateur : « Arrêt et compte rendu »).
Racine `SK` = `D:\Game\LifePlay-Sandbox-5.8\Tools\claude\skills`. Les « Avant » sont recopiés des fichiers lus ce jour (numéros
de ligne de la lecture du 2026-10-14, après les écritures de W2) ; chaque ancre est à re-citer au moment d'écrire.

## 1. Fichiers écrits
- `D:\Game\LifePlay-master 5.8\Docs\Migration\etat\EVAL2\AMEL1\AMEL1-TEXTES-W3.md` (ce fichier, créé). Aucun autre.

## 2. Numéros utilisés (CHG, ERR, doc)
sans objet : aucune entrée de journal ni de registre.

## 3. Index, plages et registre des reports mis à jour
sans objet : aucun doc numéroté créé ni modifié.

## 4. Écarts à la fiche
- La consigne dit « `FileCheck.ps1` = un fichier par appel ». Rejoué ce jour : `FileCheck.ps1 -Path @('a','b')` accepte un tableau
  (comme `PubCheck.ps1 -Fichiers @('a','b')`), voir § « Syntaxe rejouée ». Le texte T5 donne donc le tableau pour les deux
  scripts ; « un fichier par appel » reste permis. À confirmer si l'orchestrateur préfère l'imposer.
- Aucun autre écart.

## 5. Fichiers à commiter
A `Docs/Migration/etat/EVAL2/AMEL1/AMEL1-TEXTES-W3.md` (dépôt du jeu 5.8). Aucun skill modifié.

## 6. À verser
À verser : aucun.

Tours : 11 / 30

## Constats

### Syntaxe rejouée (avant d'écrire T5)
En-tête de `D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1` (l. 20-22, 37-41) : `-Path` est un `string[]` positionnel, exemple
`.\Tools\FileCheck.ps1 Source\...\LPCoupleSimCore.cpp, Config\DefaultEngine.ini` (virgule PowerShell, pas d'espace). Commande rejouée :
````
pwsh -NoProfile -Command '& "D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1" -Path @("D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1","D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1"); "code=$LASTEXITCODE"; & "D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1" -Fichiers @("D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1","D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1"); "pub=$LASTEXITCODE"'
````
Sortie : `fichiers=2 LF=2 alertes=0 introuvables=0`, `code=0`, puis `PubCheck : 0 constat(s)`, `pub=0`. Les chemins séparés par des
espaces échouent (`Nous ne pouvons pas trouver un paramètre positionnel…`, exit 1, constaté en V1a et en W2).

---

### T1. `sk-windows-shell` : redirections (résidu b ; indicateurs I7a, I7b)

Fichier : `SK\sk-windows-shell\SKILL.md`, section « Sortie et codes », bullet « Redirections » (l. 31-33).

Avant :
````
- Redirections : `> f 2>&1`. En PowerShell 5.1, `>` écrit en UTF-16 : utiliser `Out-File -Encoding utf8`. `Tee-Object` pour voir et garder.
  Un agent `lp-*` sous crochet n'écrit pas par redirection (`>`, `tee`) : il lance les scripts du projet, qui écrivent
  eux-mêmes leur journal et leur résumé (`Build.ps1`, `LogStats.ps1`), et cite ce chemin.
````
Après :
````
- Redirections : garder la sortie d'un programme natif par `Start-Process -Wait -PassThru -RedirectStandardOutput
  <sortie.txt> -RedirectStandardError <erreur.txt>` (deux fichiers distincts), ou par la sortie que le script du projet écrit
  lui-même (`Build.ps1`, `LogStats.ps1` : journal et résumé), dont on cite le chemin. Un agent `lp-*` sous crochet ne
  redirige jamais (`>` et `tee` sont refusés) : il lance le script du projet et cite ce chemin. Hors crochet (session
  principale), `>` et `Tee-Object` restent possibles ; en PowerShell 5.1 `>` écrit en UTF-16 : utiliser `Out-File -Encoding utf8`.
````
Contrôle de cohérence : le bullet « Pas de code en ligne » (S1) et `lp-paths` ne citent pas `> f 2>&1`.

### T2. `lp-build` : commande brute de la copie 5.5 (résidu b ; indicateurs I7a)

Fichier : `SK\lp-build\SKILL.md`, § 3 « Compiler (copie 5.5, branche main) : commande brute » (l. 51-56), bloc de code, l. 52-54.

Avant :
````
$UE='D:\Game\Launcher\Engine\UE_5.5\Engine'; $Proj='D:\Game\LifePlay-master 5.5\LifePlay.uproject'
$env:VSLANG='1033'; $log="D:\Game\LifePlay-master 5.5\Saved\Logs\portage\<lot>_Build_$(Get-Date -f yyyyMMdd-HHmmss).log"
cmd /c "`"$UE\Build\BatchFiles\Build.bat`" LifePlayEditor Win64 Development `"-Project=$Proj`" -WaitMutex -NoHotReloadFromIDE > `"$log`" 2>&1"
````
Après :
````
$UE='D:\Game\Launcher\Engine\UE_5.5\Engine'; $Proj='D:\Game\LifePlay-master 5.5\LifePlay.uproject'
$env:VSLANG='1033'; $log="D:\Game\LifePlay-master 5.5\Saved\Logs\portage\<lot>_Build_$(Get-Date -f yyyyMMdd-HHmmss).log"
Start-Process -FilePath "$UE\Build\BatchFiles\Build.bat" -ArgumentList 'LifePlayEditor','Win64','Development',"`"-Project=$Proj`"",'-WaitMutex','-NoHotReloadFromIDE' -Wait -PassThru -RedirectStandardOutput $log -RedirectStandardError "$log.err"
````
Le reste du bloc (ligne `Build.ps1 -FromLog $log`) est inchangé. **Incertain, non rejoué** : cette commande lance un build UE 5.5 (copie UE, `BUILD-GO` requis) ; avant adoption, un essai sur la copie 5.5 par `lp-builder` doit confirmer (a) que `Start-Process` lance bien le `.bat`, (b) que le journal `$log` contient les mêmes lignes qu'avant (UBT écrit sur la sortie standard ; `$log.err` doit rester vide ou sans erreur), (c) le code de sortie (`-PassThru`, `.ExitCode`). Repli : garder le texte actuel avec la mention « session principale hors crochet seulement ».

### T3. `lp-doc/gabarits.md` : un seul texte pour FicheStats (résidu C4 ; indicateur I11b)

Fichier : `SK\lp-doc\gabarits.md`, gabarit TACHES, deux endroits (l. 94-95 et l. 100-104). Principe : le registre est tenu au fil du lot (statuts à chaque envoi et réception, mesures reportées après chaque VAL PASS) ; la clôture contrôle.

Avant (l. 94-95) :
````
retrouve par `git log --grep <ticket>` (R-REPO1). Les quatre colonnes de mesure sont remplies par
`python -I Tools/FicheStats.py --lot <LOT>` (copie 5.8) à la clôture ; une fiche au-delà du budget de son niveau
````
Après :
````
retrouve par `git log --grep <ticket>` (R-REPO1). Les quatre colonnes de mesure sont remplies par
`python -I Tools/FicheStats.py --lot <LOT>` (copie 5.8), au fil du lot (après chaque VAL PASS) et contrôlées à la clôture ;
une fiche au-delà du budget de son niveau
````
Avant (l. 100-104) :
````
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 (<fiche b>)`, …), jamais en bloc à la clôture ; `python -I Tools/FicheStats.py --lot <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.
````
Après :
````
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 registre est tenu au fil du lot : le statut est écrit à
chaque envoi et à chaque réception (`acceptée`, `reprise (<fiche b>)`, …), et les mesures de `FicheStats` (Tours, Pic,
Jetons, Durée) sont reportées après chaque VAL PASS. À la clôture, `FicheStats` est relancé une dernière fois pour contrôler le
registre. Un registre sans ces colonnes est refusé à la réception.
````

### T4. `lp-validate` : lecture d'une roue Python (résidu a ; indicateur I7a)

Fichier : `SK\lp-validate\SKILL.md`, § 1, bullet « roue Python » (l. 40-41).

Avant :
````
- Une roue Python (`.whl`) se lit sans l'installer : extraction par `python -I` + `zipfile` depuis le scratchpad
  (`tar -xf` de Git Bash refuse un zip), sha256 de `RECORD` vérifié, rien exécuté (P7-T7).
````
Après :
````
- Une roue Python (`.whl`) se lit sans l'installer, sans code en ligne : soit par un script fourni par la fiche (rubrique 4,
  chemin dans `Saved/<lot>/` ou `Tools/`) lancé par `python -I -X utf8 <script> <roue> <dossier du scratchpad>`, soit par
  `pwsh -NoProfile -Command "Copy-Item -LiteralPath '<roue>' -Destination '<scratchpad>\roue.zip'; Expand-Archive
  -LiteralPath '<scratchpad>\roue.zip' -DestinationPath '<scratchpad>\roue'"` (`tar -xf` de Git Bash refuse un zip). Le sha256
  de chaque fichier est comparé à `RECORD` par `Get-FileHash -Algorithm SHA256`. Rien n'est exécuté (P7-T7).
````
**Incertain, non rejoué** : `Expand-Archive` sur une copie renommée en `.zip` n'a pas été essayé ici (pas de roue sous la main) ; un essai de deux lignes sur une roue du scratchpad le confirme avant adoption. Aucun agent n'écrit le script (`sk-protocol` § 7, C3 de `AMEL1-TEXTES.md`).

### T5. `lp-validate` : syntaxe de FileCheck et de PubCheck (résidu c ; indicateurs I7a, I7b)

Fichier : `SK\lp-validate\SKILL.md`, § 1, bloc « Fins de ligne » (l. 26-29) et bullet « Fuite de donnée personnelle » (l. 50-52).

Avant (l. 26-29) :
````
```powershell
.\Tools\FileCheck.ps1 <fichiers>                # Fins (CRLF / LF / mixte / binaire), nombre de CRLF, LF et CR seuls, BOM, MD5
.\Tools\FileCheck.ps1 -Lot <lot> -OnlyChanged   # fichiers du manifeste Snapshot.ps1, comparés à la copie sauvegardée
```
````
Après :
````
```powershell
# Fins (CRLF / LF / mixte / binaire), nombre de CRLF, LF et CR seuls, BOM, MD5 ; plusieurs fichiers = un tableau, chemins absolus
pwsh -NoProfile -Command "& 'D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1' -Path @('<chemin absolu 1>','<chemin absolu 2>')"
# fichiers du manifeste Snapshot.ps1, comparés à la copie sauvegardée
pwsh -NoProfile -Command "& 'D:\Game\LifePlay-master 5.8\Tools\FileCheck.ps1' -Lot <lot> -OnlyChanged"
```
Jamais de chemins séparés par des espaces (« paramètre positionnel », code 1, constaté en V1a) : tableau `@('a','b')`, ou un fichier par appel.
````
Avant (l. 50-52) :
````
- **Fuite de donnée personnelle (R6)** : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers <livrables amont et fichiers du diff>`
  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.
````
Après :
````
- **Fuite de donnée personnelle (R6)** : `pwsh -NoProfile -Command "& 'D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1'
  -Fichiers @('<chemin absolu 1>','<chemin absolu 2>')"` sur les livrables amont et les fichiers du diff (tableau, chemins
  absolus). 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.
````
Syntaxe rejouée : voir « Syntaxe rejouée » ci-dessus (codes 0 et sorties citées).

### T5b. `lp-lot` et `boss.md` : même forme de PubCheck (cohérence ; indicateur I7a)

Facultatif (les deux écritures de W2 utilisent `-File`, qui accepte aussi plusieurs chemins d'après l'en-tête de `PubCheck.ps1` ; le tableau évite l'erreur des espaces).

`SK\lp-lot\SKILL.md` l. 58-59, avant :
````
Dès qu'un livrable est écrit (VAL, BUILD-FIN, DOC), son rédacteur lance `pwsh -NoProfile -File Tools\PubCheck.ps1
-Fichiers <livrables écrits>` depuis la racine du jeu 5.8 (R6) et cite la ligne `PubCheck : 0 constat(s)` dans le
````
après :
````
Dès qu'un livrable est écrit (VAL, BUILD-FIN, DOC), son rédacteur lance `pwsh -NoProfile -Command "& 'D:\Game\LifePlay-master
5.8\Tools\PubCheck.ps1' -Fichiers @('<livrable 1>','<livrable 2>')"` (chemins absolus, R6) et cite la ligne `PubCheck : 0 constat(s)` dans le
````
`SK\lp-lot\boss.md` l. 79, avant :
````
7. PubCheck : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers <livrables et résumés .md du tour>` rend 0 (R6) ; sortie
````
après :
````
7. PubCheck : `pwsh -NoProfile -Command "& 'D:\Game\LifePlay-master 5.8\Tools\PubCheck.ps1' -Fichiers @('<livrable 1>','<résumé 2>')"` (chemins absolus, livrables et résumés .md du tour) rend 0 (R6) ; sortie
````

---

### T6. Règle A5 : après un refus UTILE du crochet `ecriture-gardien` (indicateurs I10b, I7a)

Décision de l'utilisateur (citée) : « Arrêt et compte rendu ». Cas d'origine : STE-ORG4c, l'orchestrateur a déplacé lui-même
l'autosauvegarde refusée à l'agent, sans MD5 (`etat\ST\STE\STE-ORG4c-IMPL.md` l. 113 : « n'a pas été déplacée (refus du crochet, § 2), et
son MD5 n'a pas été mesuré » ; l. 120 : « déplacée par l'orchestrateur vers `D:\Game\LifePlay_Backup_5.5\STE-ORG4c\autosave\` »).

#### T6a. `SK\lp-lot\SKILL.md`, section « Copie UE partagée, Big Boss et rotation », nouveau bullet après « Session réutilisée » (l. 84-86)

Ancre (dernière ligne du bullet, l. 86) :
````
  `PASSATION` cite le titre. Une session saturée (≥ 250 k) ne se réutilise pas : elle passe la main (bullet précédent).
````
Après (bullet ajouté juste dessous) :
````
- Refus utile du crochet `ecriture-gardien` (A5, décision de l'utilisateur : « Arrêt et compte rendu ») : après un refus
  UTILE (une écriture que la fiche interdit à l'agent, ou qui vise un fichier qu'elle ne nomme pas), l'orchestrateur de lot
  s'arrête et rend compte à Big Boss : commande refusée, motif du refus, effet attendu de la commande. Il ne refait pas
  lui-même l'écriture refusée (cas d'origine : STE-ORG4c, autosauvegarde déplacée sans MD5, `etat\ST\STE\STE-ORG4c-IMPL.md`
  l. 120). L'écriture n'a lieu que sur décision explicite de l'utilisateur ou de Big Boss, avec un instantané
  (`Snapshot.ps1`) et le MD5 avant et après relevés (`FileCheck.ps1`), cités au livrable.
````

#### T6b. `SK\lp-lot\boss.md`, § 9 « Refus d'autorisation » (l. 129-131)

Avant :
````
## 9. Refus d'autorisation
Un refus 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 (doc 32 § 15.7).
````
Après :
````
## 9. Refus d'autorisation
Un refus 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 (doc 32 § 15.7).
Refus UTILE du crochet `ecriture-gardien` (A5) : l'orchestrateur de lot s'arrête et rend compte à Big Boss (commande refusée,
motif, effet attendu) ; il ne refait pas lui-même l'écriture refusée. Elle n'a lieu que sur décision explicite de
l'utilisateur ou de Big Boss, avec un instantané et le MD5 avant et après (`lp-lot`, bullet « Refus utile du crochet »).
````

### Points à trancher
1. **A5 et le doc 32 § 15.7 / `boss.md` § 9** : ces textes disent que « seul un ordre ou une approbation de l'utilisateur » lève un refus, et
   que Big Boss ne change aucune règle d'autorisation. A5 (selon la consigne reçue) admet une décision explicite « de l'utilisateur ou
   de Big Boss » pour refaire l'écriture. Lecture retenue ici : Big Boss décide un geste ponctuel (déplacer un fichier précis), il ne
   modifie pas la règle d'autorisation ; mais la phrase de T6b et celle du § 9 se lisent en tension. Variante plus stricte, sans tension :
   remplacer « de l'utilisateur ou de Big Boss » par « de l'utilisateur, relayée par Big Boss ». À choisir.
2. **« Refus utile » contre « à tort »** : A5 ne dit rien d'un refus à tort (faux positif du crochet v1 : 36 sur 76 en P3). Texte proposé : aucun ; tant que
   le crochet v2 (AMEL1-R2) n'est pas en place, un refus à tort se traite comme un refus utile (arrêt et compte rendu), ce qui est conservateur.
3. **T2** : adoption conditionnée à un essai sur la copie 5.5 (BUILD-GO) ; **T4** : essai d'`Expand-Archive` sur une roue.
4. **FileCheck** : « un fichier par appel » (consigne) contre « tableau accepté » (rejoué) : voir § 4.

Retour arrière, une fois appliqués : instantané `Tools\Snapshot.ps1 -Lot AMEL1-W3 -ProjectRoot D:\Game\LifePlay-Sandbox-5.8 -Path <fichiers>` avant d'écrire ;
`git revert` du ticket pour les fichiers suivis (`lp-lot`, `lp-doc/gabarits.md`, `lp-validate`, `lp-build`) ; `sk-windows-shell` est non suivi
par git (instantané seul) ; sa copie du profil `%USERPROFILE%\.claude\skills\sk-windows-shell\SKILL.md` est à redéployer (geste de l'utilisateur).

Non mesuré : aucun effet sur les indicateurs (mesure P4) ; T2 et T4 non rejoués.