LifePlay-Revival/Docs/Migration/etat/AG/VAG1/VAG1-DOC-01.md

VAG1-DOC-01 : textes proposés pour lp-repo § 6 et § 8, sk-repo § 2 / § 4 et l'agent lp-gardien

Fiche VAG1-DOC-01 — Niveau N1 — Modèle prévu sonnet | utilisé sonnet (claude-sonnet-5-5) — Agent session « Sonnet · VAG1 » — Skills lp-doc, lp-repo, sk-repo, sk-protocol, sk-change-safety. Date : 2026-10-20. Propositions seulement : aucun skill, aucun agent, aucun script ni dépôt modifié. Demande de Big Boss (session local_104ff22d, 2026-10-20) : aligner le gabarit de ticket sur Tools\Vague.ps1 (statut « demandé », HEAD exact sauf PARTAGES, « ; corps Tickets : … » dans Message) et dire que la vague passe par le script.

Instantané de référence (état actuel des trois textes, avant toute application) : Snapshot.ps1 -Lot VAG1-DOC-01 -ProjectRoot D:\Game\LifePlay-Sandbox-5.8 → D:\Game\LifePlay_Backup_5.5\VAG1-DOC-01\manifest.csv. MD5 : lp-repo/SKILL.md 24AC155D9057AE6213A1D67D50EB375B ; sk-repo/SKILL.md DADC07A62D0B72DA835ABA9A181D995F (identique à la copie du profil %USERPROFILE%\.claude\skills\sk-repo\SKILL.md, MD5 relu égal) ; agents/lp-gardien.md E078ED03F9C085DF2FA35D51BE685826. Tous dans l'addon Tools/claude/. Fins de ligne : LF (relevé pour lp-repo ; à revérifier avant d'appliquer).

1. Ce que le script exige (source : Tools\Vague.ps1 v2, MD5 24b2ef4f…, VAG1-SPEC-01.md § 3-4)

Champ du ticket	Lu par le script	Écart avec le gabarit actuel de lp-repo § 8
Titre	# Ticket <id> — <TYPE> (tiret cadratin) ; COMMIT traité, PIN arrête la vague, les autres types sont refusés (TYPE-NON-GERE)	le gabarit nomme <LOT>-R<n> : la charte 36 impose <LOT>-T<n> pour les nouveaux tickets
Statut :	doit être demandé au départ (P2, avant toute écriture) ; le script écrit en cours, puis fait ou refusé (<contrôle> : <motif>)	le gabarit liste `demandé
Dépôt : <arbre> — Branche attendue : <b> — HEAD attendu : <h>	les deux tirets cadratins ; Sandbox dans l'arbre = addon ; <h> = hash d'au moins 7 caractères hexadécimaux, ou quelconque seulement pour un ticket VAGUE-…-PARTAGES	le gabarit admet quelconque partout
Fichiers :	lignes `A	M
Message :	une ligne : <LOT> : <résumé> (CHG-nnn) ; corps + Tickets : <id>[, <id>] entre accents graves ; le script fabrique le message : résumé, ligne vide, Tickets : …, ligne vide, -Trailer	le gabarit dit « corps Tickets : … » sans la forme exacte ; les vagues 1 à 4 écrivaient « Tickets : » sur une ligne à part
CHG / ERR :	seulement pour le PARTAGES : liste des numéros versés (contrôle V5 ligne à ligne)	déjà dans le gabarit PARTAGES

Constat de Big Boss (essai à blanc sur ROAD1-T2) : trois refus de forme avant l'essai-OK — P2 « à faire », C2 HEAD quelconque, C9 ligne « Tickets : » séparée. Le gabarit ci-dessous les rend impossibles.

2. lp-repo § 8 : texte de remplacement (gabarit de ticket)

## 8. Gabarit de ticket
Le ticket est lu par `Tools\Vague.ps1` : la forme ci-dessous est exigée à la lettre (tirets cadratins, une ligne par champ).
Nom : `<LOT>-T<n>` (charte 36 ; les anciens `-R<n>` gardent leur nom).
~~~
# Ticket <LOT>-T<n> — <COMMIT | PIN | TAG | REPORT | RESTORE | PUSH | BRANCHE | HISTOIRE>
Statut : demandé
Demandeur : <session / orchestrateur> (fiche <LOT>-<TYPE>-<nn>) — Date : <AAAA-MM-JJ HH:MM>
Dépôt : <arbre> — Branche attendue : <b> — HEAD attendu : <hash d'au moins 7 caractères>
Fichiers :
M <chemin relatif à l'arbre, séparateur />
A <chemin>
D <chemin>
Message : <LOT> : <résumé sans contenu de jeu> (CHG-nnn) ; corps `Tickets : <LOT>-T<n>[, …]`
Preuve : <chemin du livrable VAL> — verdict <PASS | PASS-STATIC> | sans objet (<motif>)
PubCheck : 0 (orchestrateur, -Fichiers sur la liste du ticket)
Suite : tag <nom> | ticket <id> | aucune
Accord utilisateur : « <citation> » (<date>) | non requis
~~~
Règles lues par le script : `Statut : demandé` à la dépose (le script écrit `en cours`, puis `fait` ou
`refusé (<contrôle> : <motif>)`) ; le HEAD attendu est un hash exact (le HEAD du dépôt à la dépose, ou celui d'un
ticket précédent de la même vague) ; `quelconque` n'est admis que pour le ticket PARTAGES ; les chemins sont relatifs,
avec `/`, sans `.` ni `..` ; le ticket n'est jamais corrigé en file : on le retire et on en dépose un autre (V7, V9).
Statut `en attente d'accord` : réservé à `RESTORE`, `HISTOIRE`, suppression de branche ou de worktree (traités par
l'agent, pas par le script). Un ticket `PIN` arrête la vague : le pin du doc 21 est un geste du gardien.
Ticket des fichiers partagés d'une vague (§ 6) : `# Ticket VAGUE-<AAAAMMJJ>-<n>-PARTAGES — COMMIT`, une ligne
`CHG / ERR :` qui liste les numéros versés dans la vague (`CHG-369, ERR-139`), `Fichiers :` les seuls fichiers partagés
du § 6 et les tickets de la vague (`A Docs/Migration/etat/REPO/tickets/<id>.md`), `HEAD attendu : quelconque`.

3. lp-repo § 6 : paragraphe à ajouter à la fin de la section (après la phrase « REPO-JOURNAL.md et le statut du ticket restent écrits… (R-REPO1). »)

- **Exécution de la vague : `Tools\Vague.ps1`** (lot VAG1, CHG de l'outil à la vague ; validé par VAG1-VAL, PASS avec
  réserves). Big Boss lance `.\Tools\Vague.ps1 -File etat\REPO\FILE.md` **à blanc** (par défaut : aucun verrou pris,
  rien d'écrit), lit les `VERDICT`, puis `-Executer -Session "Big Boss"`. Le script prend un verrou pour toute la vague,
  traite les tickets COMMIT dans l'ordre V4 (12 contrôles par ticket, V5 ligne à ligne pour le PARTAGES, commit sur
  index privé, statut `fait` et ligne de journal emportés par le commit, R-REPO1), s'arrête au premier refus avec la
  ligne fautive, liste les suivants `EN-FILE`, rend le verrou. Il ne pousse jamais, n'amende jamais et s'arrête avant
  un ticket PIN. **L'agent `lp-gardien` n'est plus lancé que pour** : un ticket PIN (pose du pin du doc 21), les types
  TAG, REPORT, RESTORE, PUSH, BRANCHE, HISTOIRE, et un refus que Big Boss ne sait pas lire seul. La correction d'un
  ticket refusé reste à Big Boss (V9).

4. sk-repo § 2 et § 4 : phrases à ajouter (texte générique, sans nom de projet sauf en exemple)

§ 2, à la fin de l'étape 4 (après « … un verrou couvre toute la vague et se rend à sa fin. ») :

Un projet peut confier l'exécution de la vague à un script (LifePlay : `Tools\Vague.ps1`), qui prend et rend le verrou
par le script de verrou du projet ; pendant qu'il tourne, aucun gardien ne prend le verrou (il serait « occupé »).

§ 4, en tête de la section, après le titre :

Le script de vague du projet, s'il existe, applique les étapes 1 à 7 pour les tickets `COMMIT` ; l'agent les applique
à la main pour les autres types et pour un refus à diagnostiquer. Les contrôles et leurs messages sont les mêmes.

Les deux copies de sk-repo (addon et profil) sont identiques (MD5 DADC07A6…) : appliquer le même texte aux deux, par deux écritures sous instantané.

5. Agent lp-gardien (Tools/claude/agents/lp-gardien.md) : remplacements proposés

Puce « Vague » (lignes « Vague (W7, lp-repo § 6) … rien d'autre. ») à remplacer par :

- **Vague** (W7, `lp-repo` § 6) : la vague COMMIT normale est exécutée par `Tools\Vague.ps1` (Big Boss), pas par toi.
  Tu es lancé sur un message `VAGUE` de Big Boss seulement pour : (a) un ticket `PIN` (pose du pin du doc 21 : un seul,
  dernier hash addon, intermédiaires en « précédents », commité avec le ticket qui le porte) ; (b) les types TAG, REPORT,
  RESTORE, PUSH, BRANCHE, HISTOIRE ; (c) un refus du script que Big Boss te demande de diagnostiquer (lecture seule :
  tu rapportes la ligne fautive, tu ne corriges ni le ticket ni le fichier, V9). Verrou, index privé, R-REPO1 et
  `sk-repo` § 4 restent tes règles pour (a) et (b) ; un seul verrou si plusieurs tickets sont enchaînés.

Puce « Budget » / Tours : « Budget d'une vague = 10 + 6 par ticket (8 tickets : 58) » → « Budget : 10 tours + 6 par ticket PIN ou hors COMMIT, 12 tours pour un diagnostic de refus ; plafond maxTurns inchangé ». Le champ maxTurns: 60 n'est pas touché (le plafond reste utile pour une vague de PIN et de TAG). Première phrase du corps (« Tu reçois un ou plusieurs tickets …\<LOT>-R<n>.md ») : remplacer <LOT>-R<n> par <LOT>-T<n> (anciens -R<n> inclus). Rien d'autre ne change (index privé, interdits, livrable INT, accord pour RESTORE / HISTOIRE).

6. Ordre d'application et contrôles (quand Big Boss décidera)

1. Instantané (déjà pris pour l'état actuel, § en-tête ; en reprendre un juste avant l'application si les fichiers ont bougé : lp-gardien.md portait une modification d'une autre session au tri du 2026-10-20).
2. Une écriture par texte (Edit), dans cet ordre : lp-repo § 8, lp-repo § 6, sk-repo (addon), sk-repo (profil, geste de l'utilisateur ou de Big Boss), lp-gardien.md.
3. Contrôles : PubCheck 0 sur les fichiers de l'addon ; LF conservé ; grep -R<n> restant dans lp-repo (les sections 2 et 7 citent encore <LOT>-R<n> : à relire) ; test de bout en bout : un ticket au nouveau gabarit passe Vague.ps1 à blanc.
4. CHG à verser avec le CHG de l'outil Vague.ps1 (réservé à la vague par Big Boss). Retour arrière : Restore.ps1 -Lot VAG1-DOC-01 -ProjectRoot D:\Game\LifePlay-Sandbox-5.8.

7. Limites

• Texte non appliqué : ni validé en jeu, ni relu par un second agent. lp-repo cite le nom <LOT>-R<n> ailleurs que § 8 (§ 2 « Push », § 7 numéros) : à harmoniser à l'application.
• La copie du profil de sk-repo est hors du dépôt : seul l'utilisateur ou Big Boss la modifie.

8. Fichiers à commiter

Jeu (A) : Docs/Migration/etat/AG/VAG1/VAG1-DOC-01.md. Aucun skill ni agent modifié.

Tours : environ 9. À verser : lp-repo § 8 — le gabarit de ticket est une interface lue par un script (voir § 2). Suite : Big Boss doit décider d'appliquer (fiche VAG1-DOC-02 d'application) ; état : propositions écrites.