718 lines
45 KiB
Markdown
718 lines
45 KiB
Markdown
|
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/<lot>/` 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/<projet>/<lot>/`, 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-<n>` ; pour un fichier non suivi (agents, `%USERPROFILE%\.claude\skills`, `BOSS-JOURNAL.md`) : restaurer depuis
|
||
|
|
l'instantané `.\Tools\Snapshot.ps1 -Lot AMEL1-<n>` pris avant l'écriture (`.\Tools\Restore.ps1 -Lot AMEL1-<n> -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 `<LOT>-TACHES.md` et `<LOT>-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\<projet>\<lot>\<LOT>-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), `<LOT>-ETAT` ou note
|
||
|
|
de passage (dossier de notes fourni par l'application ; sinon `etat\<projet>\<lot>\<LOT>-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 `<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).
|
||
|
|
````
|
||
|
|
|
||
|
|
#### 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 (<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.
|
||
|
|
````
|
||
|
|
|
||
|
|
#### 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-<n>-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-<n>.<k>` :
|
||
|
|
| 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 : <motif>`.
|
||
|
|
- 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-<n>-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 (`<LOT>-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-<n>.<k> <verdict> (<date HH:MM>)` ; 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 : <motif>`.
|
||
|
|
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-<n>-ENTREE.md`. Hors gabarit de tête : une liste, rien d'autre. Une ligne par cas :
|
||
|
|
`COMMUN-<n>.<k> | 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 — `<LOT>-JOURNAL-BROUILLON.md` (session de lot ou lp-writer ; ajout seul)
|
||
|
|
Fichier `etat/<projet>/<lot>/<LOT>-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 (<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.
|
||
|
|
````
|
||
|
|
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 `<LOT>-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 : <n> 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 : <motif>` 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-<n>.<k>` (ou `sans objet : <motif>` 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\<projet>\<lot>\<LOT>-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/<projet>/<lot>/<LOT>-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\<projet>\<lot>\`, cités par chemin.
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
5. Journaux et résumés archivés sous `etat\<projet>\<lot>\`, cités par chemin.
|
||
|
|
6. Brouillon du journal à jour : lignes CHG / ERR de ce tour dans `<LOT>-JOURNAL-BROUILLON.md` (R5), ou `sans objet : <motif>`.
|
||
|
|
7. PubCheck : `pwsh -NoProfile -File Tools\PubCheck.ps1 -Fichiers <livrables et résumés .md du tour>` 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 <chemin> [<chemin> …]` (le premier chemin après `-Fichiers`, les suivants en arguments restants) ; codes 0 net, 1 constat, 2 erreur ; sortie `<où>:<ligne>:<CATEGORIE>` puis `PubCheck : <n> 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 <chemins du
|
||
|
|
ticket>` (0 exigé, cité au ticket) ; un livrable ne cite jamais le nom du compte : `<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 <livrables écrits>` 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 `<chemins du ticket>` (0 exigé, cité au ticket) ; un livrable ne cite jamais le nom du compte :
|
||
|
|
`<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 <tag>^{commit}`. `git diff <tag>` et
|
||
|
|
`git show <tag>:<fichier>` 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 <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.
|
||
|
|
````
|
||
|
|
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 "& '<script>' -Kind Editeur,Compilation"` (`OBB-T7c`, `lp-build` § 8).
|
||
|
|
|
||
|
|
## Interdits
|
||
|
|
````
|
||
|
|
Après (insertion avant « ## Interdits ») :
|
||
|
|
````
|
||
|
|
## Pas de code en ligne (AMEL1, R7 ; agents et sessions principales)
|
||
|
|
- Jamais `python -c`, jamais `python - <<EOF`, jamais de heredoc Bash ni de here-string PowerShell, même pour tester
|
||
|
|
l'interpréteur (`python --version` suffit, sans `-c`) ou lire un JSON. P3 : 17 refus que les agents se sont causés,
|
||
|
|
322 heredocs Python dans les sessions principales.
|
||
|
|
- Lire un JSON : Read. Le filtrer ou le compter : un script `.py` ou `.ps1` écrit par Write (scratchpad de la session),
|
||
|
|
lancé par `python -I -X utf8 <fichier>` ou `pwsh -NoProfile -File <fichier>`. Un agent sans Edit (`sk-protocol` § 7) n'écrit
|
||
|
|
pas de script : il utilise celui que sa fiche fournit (rubrique 4, rangé dans `Saved/<lot>/` ou `Tools/`), sinon Read,
|
||
|
|
sinon il s'arrête et le dit.
|
||
|
|
- Le crochet `ecriture-gardien` voit `>` et `->` même entre guillemets ou apostrophes (`grep "^>"`, `awk 'NR>=…'`,
|
||
|
|
`echo "a -> b"` : 36 refus à tort sur 76 en P3). Chercher avec l'outil Grep, lire un intervalle avec Read (`offset`,
|
||
|
|
`limit`) ; jamais `grep`, `awk` ni `sed -n` dans le shell. Cette consigne tombe quand le crochet v2 (AMEL1-R2) est en
|
||
|
|
place : la retirer alors.
|
||
|
|
- Guillemets : le code va dans un fichier, les chemins en arguments (26 erreurs de guillemets en 5 910 appels shell).
|
||
|
|
- Pièges de poste (Python du Store et chemin MSIX, `git ls-remote`) : `lp-paths`.
|
||
|
|
````
|
||
|
|
Contradictions : C2, C3.
|
||
|
|
|
||
|
|
#### S2 : `SK\sk-windows-shell\SKILL.md`, § « Sortie et codes », bullet « Redirections » (l. 31)
|
||
|
|
|
||
|
|
Avant :
|
||
|
|
````
|
||
|
|
- Redirections : `> f 2>&1`. En PowerShell 5.1, `>` écrit en UTF-16 : utiliser `Out-File -Encoding utf8`. `Tee-Object` pour voir et garder.
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
- 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.
|
||
|
|
````
|
||
|
|
|
||
|
|
#### V3 : `SK\lp-validate\SKILL.md`, § 1, ligne 42 (contradiction C1)
|
||
|
|
|
||
|
|
Avant :
|
||
|
|
````
|
||
|
|
- `.uproject` : JSON valide (`python -c "import json;json.load(open('LifePlay.uproject'))"`).
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
- `.uproject` : JSON valide. Lire le fichier avec Read ; test de syntaxe, depuis PowerShell :
|
||
|
|
`pwsh -NoProfile -Command 'Get-Content -Raw LifePlay.uproject | ConvertFrom-Json | Out-Null'`, code 0 attendu (jamais
|
||
|
|
`python -c`, `sk-windows-shell`).
|
||
|
|
````
|
||
|
|
À vérifier avant écriture : cette commande n'a pas été rejouée dans ce livrable (incertain). Même remarque, sans changement proposé : l. 40-41 (roue Python lue « par `python -I` + `zipfile` ») doit passer par un script fourni, pas par une ligne de commande.
|
||
|
|
|
||
|
|
#### P1 : `SK\lp-paths\SKILL.md`, nouvelle section avant « ## Inventaires types » (l. 59) (R7, R13 ; I13)
|
||
|
|
|
||
|
|
Avant (l. 57-59) :
|
||
|
|
````
|
||
|
|
- `Docs\Migration\etat\` est organisé en `etat/<projet>/<lot>/` ; index `etat/INVENTAIRE.md`, correspondances
|
||
|
|
`etat/MAPPING.csv`.
|
||
|
|
|
||
|
|
## Inventaires types (lecture seule, pwsh 7, depuis la racine du dépôt)
|
||
|
|
````
|
||
|
|
Après (insertion avant « ## Inventaires types ») :
|
||
|
|
````
|
||
|
|
## Pièges de poste (AMEL1, R7 et R13)
|
||
|
|
- **Python du Store (MSIX)** : il voit une copie virtualisée de `AppData\Roaming` et ne trouve pas
|
||
|
|
`AppData\Roaming\Claude`. Les métadonnées des sessions de l'application se lisent par le chemin MSIX :
|
||
|
|
`%USERPROFILE%\AppData\Local\Packages\Claude_*\LocalCache\Roaming\Claude\claude-code-sessions`. Ne jamais écrire le nom
|
||
|
|
du compte dans un livrable (`<compte>`, `%USERPROFILE%`).
|
||
|
|
- **`git ls-remote`** (et tout `git` qui interroge le distant) : `GIT_TERMINAL_PROMPT=0` et un délai, sinon il bloque sur le
|
||
|
|
gestionnaire d'identifiants (un processus est resté bloqué, T2). PowerShell : `$env:GIT_TERMINAL_PROMPT = '0'` avant la
|
||
|
|
commande ; Bash : `GIT_TERMINAL_PROMPT=0 git ls-remote …` avec le paramètre `timeout` de l'outil (≤ 30 000 ms).
|
||
|
|
- **`Tools\FicheStats.py`** : `AGENTS_N3` doit contenir `lp-mcp-bp`, `lp-diag` et `lp-cart-max` (fiche AMEL1-R13) ; avant
|
||
|
|
ce correctif, `lp-mcp-bp` est compté hors budget à 46 % au lieu de 14 % : recompter à la main.
|
||
|
|
- Pas de `python -c`, ni de heredoc, ni de `>` / `->` dans le shell : `sk-windows-shell`.
|
||
|
|
````
|
||
|
|
Incertain : la phrase « il voit une copie virtualisée » explique la cause d'après le rapport (O7 : « ne voit pas `AppData\Roaming\Claude` ») ; le mécanisme exact de virtualisation n'a pas été relu ici.
|
||
|
|
|
||
|
|
#### A1 : `AG\lp-inventory.md`, corps, après la 5e ligne de consigne (l. 18-19)
|
||
|
|
|
||
|
|
Avant (l. 18-19) :
|
||
|
|
````
|
||
|
|
- Lire et chercher : Read, Grep (`output_mode: count` pour compter), Glob, pas `grep`, `head`, `cat` en Bash ; git et
|
||
|
|
`Measure-Object` restent au shell. Aucune édition par script ni `sed -i` (`sk-protocol` § 7).
|
||
|
|
````
|
||
|
|
Après (ajout à la suite) :
|
||
|
|
````
|
||
|
|
- Pas de `python -c`, de heredoc ni de here-string, même pour tester l'interpréteur ou lire un JSON : Read pour un JSON,
|
||
|
|
ou le script que ta fiche fournit (tu n'écris pas de script, `sk-protocol` § 7). Le crochet refuse `>` et `->` même
|
||
|
|
entre guillemets : Grep pour chercher. `git ls-remote` : `GIT_TERMINAL_PROMPT=0` et un délai. Python du Store et
|
||
|
|
chemin MSIX des sessions : `lp-paths`, « Pièges de poste ».
|
||
|
|
````
|
||
|
|
Les agents sont lus depuis `%USERPROFILE%\.claude\agents` : écriture par le geste de l'utilisateur (`lp-lot`). Modèle `sonnet`, `tools`, `maxTurns: 50` inchangés.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### R8. VAL « témoin en jeu » (indicateurs I8a, I8b)
|
||
|
|
|
||
|
|
#### V2 : `SK\lp-validate\SKILL.md`, § 6 « Verdict et livrable », après le bullet « Verdicts » (l. 108-109)
|
||
|
|
|
||
|
|
Avant :
|
||
|
|
````
|
||
|
|
- Verdicts : `PASS` (tout rejoué, conforme), `PASS-STATIC` (conforme sans exécution rejouée), `FAIL` (écart avec
|
||
|
|
preuve), `BLOCKED-<cause>`. Un critère non vérifié n'est jamais compté comme passé.
|
||
|
|
````
|
||
|
|
Après (bullet inséré à la suite) :
|
||
|
|
````
|
||
|
|
- **Témoin en jeu (R8)** : une VAL `PASS-STATIC` d'un correctif de comportement (ce que le jeu fait change ; pas une doc, un
|
||
|
|
outil ni une configuration sans effet visible) nomme le cas de la fiche de tests commune qui le prouvera : ligne
|
||
|
|
`Témoin en jeu : COMMUN-<n>.<k>` par correctif. Si la fiche n'existe pas encore, la VAL écrit `Témoin en jeu : à créer`
|
||
|
|
et demande à l'orchestrateur le cas (fiche FIT, gabarit de `lp-doc`). Une VAL `PASS-STATIC` sans cette ligne est
|
||
|
|
incomplète. Le bilan d'essai reporte le verdict en jeu sur la VAL : le rédacteur du bilan y ajoute une ligne datée
|
||
|
|
`Suite en jeu : COMMUN-<n>.<k> <verdict>` ; le validateur ne réécrit pas sa VAL.
|
||
|
|
````
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### R9. Fiches `lp-cart` plus étroites (indicateur I9)
|
||
|
|
|
||
|
|
#### O1 : `SK\sk-orchestrate\SKILL.md`, § 3 « Pièges de rédaction », bullet après « Test utilisateur » (l. 59)
|
||
|
|
|
||
|
|
Avant (l. 59) :
|
||
|
|
````
|
||
|
|
- **Test utilisateur** : avant de soumettre un test à l'utilisateur, vérifier qu'il est faisable (fonction ou réglage présent dans la version testée, build disponible, ressource partagée accordée) ; sinon, pas de demande (U8-T6 : réglage absent de la V1.5, une session de jeu perdue).
|
||
|
|
````
|
||
|
|
Après (bullet ajouté) :
|
||
|
|
````
|
||
|
|
- **Fiche `lp-cart`** (R9) : une question en rubrique 1, une liste fermée de fichiers en rubrique 4 (chemins, ou un dossier nommé
|
||
|
|
et un motif Grep), un budget en tours et un pic en rubrique 9. Une fiche « cartographier tout X » est coupée avant
|
||
|
|
l'envoi (une hypothèse ou un domaine par fiche, § 3 « Découpage »). Le modèle de l'en-tête de l'agent est respecté (voir
|
||
|
|
« 2b »). P3 : 11 passages `lp-cart` sur 14 hors budget, 4 lancés en Opus contre l'en-tête.
|
||
|
|
````
|
||
|
|
|
||
|
|
#### O2 : `SK\sk-orchestrate\SKILL.md`, § 1 (l. 20) et rubrique 2b (l. 38 et l. 52)
|
||
|
|
|
||
|
|
Avant (l. 20) :
|
||
|
|
````
|
||
|
|
Descendre = surcharge du modèle à l'appel ; monter = agent de niveau supérieur. Vérifier la disponibilité du modèle visé ; sinon prendre le niveau au-dessus.
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
Descendre = surcharge du modèle à l'appel ; monter = agent de niveau supérieur. Vérifier la disponibilité du modèle visé ; sinon prendre le niveau au-dessus. Toute surcharge du paramètre `model`, vers le bas comme vers le haut, porte son motif écrit en rubrique 2b ; sans motif, le modèle de l'en-tête de l'agent s'applique.
|
||
|
|
````
|
||
|
|
Avant (modèle de fiche, l. 38) :
|
||
|
|
````
|
||
|
|
2b Agent : <nom> (modèle surchargé : <m> | aucun) — préchargés : <liste> — à invoquer : <liste> — outils retirés : <liste>
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
2b Agent : <nom> (modèle surchargé : <m>, motif : <écrit> | aucun) — préchargés : <liste> — à invoquer : <liste> — outils retirés : <liste>
|
||
|
|
````
|
||
|
|
Même remplacement à la l. 52 (`Agent : <nom> (modèle surchargé : <m> | aucun) — skills préchargés : …`). Contradiction C6 : l. 67 (« `haiku` par surcharge pour un relevé trivial ») reste valable, son motif est « relevé trivial ».
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### R11 et R12. Horodatage, registres, sessions
|
||
|
|
|
||
|
|
#### B4 : `SK\lp-lot\boss.md`, § 1 « Messages » (l. 29-31), ajout en fin de section (R11 ; I11a)
|
||
|
|
|
||
|
|
Avant (l. 29-31) :
|
||
|
|
````
|
||
|
|
Attendre la réponse avant d'agir, et ne pas renvoyer un message sur le même objet tant que le premier est sans réponse
|
||
|
|
(messages croisés : 4 cas en 72 h, `EVAL-RAPPORT.md` § 5). Une consigne qui arrive après le lancement d'une action
|
||
|
|
s'applique à l'étape suivante et se signale (U8-T5cr, BOSS l. 224).
|
||
|
|
````
|
||
|
|
Après (ajout à la suite) :
|
||
|
|
````
|
||
|
|
Toute ligne que Big Boss ajoute à `etat\BOSS\BOSS-JOURNAL.md` commence par l'heure `AAAA-MM-JJ HH:MM` (heure locale) ; une
|
||
|
|
ligne sans heure n'est pas écrite. Un événement dont l'heure exacte est inconnue porte l'heure d'écriture et `(approx.)`.
|
||
|
|
````
|
||
|
|
|
||
|
|
#### J1 : `ETAT\BOSS\BOSS-JOURNAL.md` (hors git), « Règle d'écriture documentaire », ajout en fin de section (après la l. 17) (R11 ; I11a)
|
||
|
|
|
||
|
|
Avant (l. 16-17) :
|
||
|
|
````
|
||
|
|
it à Lot 29). **Fait** : `b7f8efc`
|
||
|
|
(CHG-298), contre-vérifié par Big Boss ; gel levé le 2026-10-10.
|
||
|
|
````
|
||
|
|
Après (paragraphe ajouté) :
|
||
|
|
````
|
||
|
|
|
||
|
|
**Horodatage (utilisateur via AMEL1, 2026-10-14).** Chaque ligne du journal porte `AAAA-MM-JJ HH:MM` (heure locale) en tête.
|
||
|
|
Une ligne sans heure est un écart (P3 : 86 lignes sur 462 en avaient une). Le journal reste en ajout seul : les lignes
|
||
|
|
anciennes ne sont pas réécrites.
|
||
|
|
````
|
||
|
|
(Ancre à re-citer exactement à l'écriture : la ligne 16 du fichier actuel commence par « Il doit passer… » et se termine par `**Fait** : `b7f8efc``, lue en l. 16-17 ; l'ajout se place après la l. 17.)
|
||
|
|
|
||
|
|
#### D2 : `SK\lp-doc\SKILL.md`, § « Contrôles avant de rendre », fin du paragraphe (l. 66-68) (R11, R1, R3, R5 ; I11b)
|
||
|
|
|
||
|
|
Avant :
|
||
|
|
````
|
||
|
|
Gabarits à remplir (lot TPL1) : `gabarits.md` — livrables INV, CART, DIAG, SPEC, IMPL, BUILD, VAL, DOC, INT, EVAL
|
||
|
|
(sections numérotées dans l'ordre, chacune remplie ou `sans objet : <motif>`) et registre `<LOT>-TACHES.md` du lot.
|
||
|
|
Tout livrable de fiche suit le gabarit de son rôle ; le lire avant d'écrire.
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
Gabarits à remplir (lot TPL1) : `gabarits.md` — livrables INV, CART, DIAG, SPEC, IMPL, BUILD, VAL, DOC, INT, EVAL
|
||
|
|
(sections numérotées dans l'ordre, chacune remplie ou `sans objet : <motif>`), fiche de tests commune (FIT), bilan
|
||
|
|
d'essai (BILAN), entrée de bilan par Big Boss (ENTREE), brouillon du journal (BROUILLON) et registre `<LOT>-TACHES.md`
|
||
|
|
du lot, avec ses colonnes Tours et Statut (un registre sans ces colonnes est refusé à la réception).
|
||
|
|
Tout livrable de fiche suit le gabarit de son rôle ; le lire avant d'écrire.
|
||
|
|
````
|
||
|
|
|
||
|
|
R12 : voir L4 (lp-lot), B3 (boss.md § 8), DOC2 (doc 32 § 15.13) et la mention de mémoire. Indicateur I12.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### R14. Budget de tours du build (indicateur I14)
|
||
|
|
|
||
|
|
Constat : COMMUN-9, 55 tours contre 40 déclarés, chaîne de 64 / 65 étapes (`EVAL2-RAPPORT.md` § 3 A4). Contradiction C5 : un budget de 60 pour `lp-builder` (agent N0, `maxTurns: 50`, budget ≈ 40) viole la règle « plafond = budget + 25 % » et la règle de coupe de `sk-orchestrate`. Deux options ; l'option B est recommandée (aucune règle existante à lever).
|
||
|
|
|
||
|
|
#### LB1 : `SK\lp-build\SKILL.md`, § 9 « Preuves exigées dans le compte rendu », après le dernier paragraphe (l. 139)
|
||
|
|
|
||
|
|
Avant (l. 139) :
|
||
|
|
````
|
||
|
|
Exception : aucun code changé depuis le build précédent → « Target is up to date » attendu (`shipping.md`, U8P).
|
||
|
|
````
|
||
|
|
Après (option B, recommandée) :
|
||
|
|
````
|
||
|
|
Exception : aucun code changé depuis le build précédent → « Target is up to date » attendu (`shipping.md`, U8P).
|
||
|
|
**Chaîne de vérification longue (R14).** Si la chaîne de contrôles que la fiche demande après le build dépasse 50 étapes
|
||
|
|
(COMMUN-9 : 64 / 65 étapes, 55 tours contre 40), l'orchestrateur la confie à une fiche VAL séparée (`lp-validator`, budget
|
||
|
|
propre) ; la fiche BUILD s'arrête aux sections 1 à 9 du gabarit BUILD. Un `lp-builder` qui voit la chaîne dépasser 50
|
||
|
|
étapes à l'ouverture le dit et s'arrête avant de commencer (livrable partiel, état de reprise).
|
||
|
|
````
|
||
|
|
Après (option A, seulement si l'utilisateur la préfère) : remplacer le second paragraphe par
|
||
|
|
````
|
||
|
|
**Chaîne de vérification longue (R14).** Si la chaîne de contrôles dépasse 50 étapes, la fiche BUILD porte un budget de
|
||
|
|
60 tours en rubrique 9 (pic ≤ 150 k) et l'agent `lp-builder` un plafond `maxTurns: 75` (budget + 25 %) ; sinon la chaîne
|
||
|
|
est confiée à une fiche VAL séparée.
|
||
|
|
````
|
||
|
|
Option A exige aussi une exception écrite à `sk-orchestrate` § 3 (« Une fiche qui demande plus que le budget de son niveau est coupée… ») et à `gabarits.md` l. 91-92 (N0-N2 : 40 tours, 150 k, `maxTurns` 50).
|
||
|
|
|
||
|
|
#### AB1 : `AG\lp-builder.md` (seulement si l'option A est retenue)
|
||
|
|
|
||
|
|
Avant (en-tête, l. 7, et dernière ligne l. 30) :
|
||
|
|
````
|
||
|
|
maxTurns: 50
|
||
|
|
````
|
||
|
|
````
|
||
|
|
- Tours : budget de la rubrique 9 (≈ 40) sous le plafond `maxTurns: 50` ; au budget, arrêt avec livrable partiel et état de reprise ; ligne `Tours : <n> / <budget>` dans le compte rendu (`sk-protocol` § 8).
|
||
|
|
````
|
||
|
|
Après :
|
||
|
|
````
|
||
|
|
maxTurns: 75
|
||
|
|
````
|
||
|
|
````
|
||
|
|
- Tours : budget de la rubrique 9 (≈ 40 ; 60 si la chaîne de vérification de la fiche dépasse 50 étapes) sous le plafond `maxTurns: 75` ; au budget, arrêt avec livrable partiel et état de reprise ; ligne `Tours : <n> / <budget>` dans le compte rendu (`sk-protocol` § 8).
|
||
|
|
````
|
||
|
|
Option B : `lp-builder.md` inchangé, sauf cette ligne de rappel à ajouter (facultative) : « Chaîne de vérification de plus de 50 étapes dans la fiche : arrête-toi à l'ouverture et dis-le (`lp-build` § 9). »
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### C. Ce qui n'a pas été fait ni mesuré
|
||
|
|
- Aucun texte n'a été appliqué ; aucun effet n'est mesuré (les indicateurs se mesurent en P4).
|
||
|
|
- Non rejoué : la commande `ConvertFrom-Json` de V3 ; la syntaxe PubCheck est lue dans l'en-tête, pas exécutée ici.
|
||
|
|
- Non relu : les copies des skills dans `%USERPROFILE%\.claude\skills` (supposées identiques à l'addon 5.8 ; `lp-doc` l'est, vérifié par `cmp` : « same » pour la copie `D:\Game\LifePlay-master 5.8\.claude\skills`).
|
||
|
|
- Non traité (hors fiche) : R2, R3, R4, R10 (outils et agents hors des fichiers listés) ; ces recommandations n'ont pas de texte ici sauf les gabarits G1 et G2 qui servent R3.
|
||
|
|
|
||
|
|
Suite : l'orchestrateur soumet ces textes à l'utilisateur (« approuvé tel quel ») ; décisions à obtenir : C5 (option A ou B pour R14), C7 (seuil par session), C8 (citation exacte et caviardage). État : livrable complet, aucun fichier de skill modifié.
|