# 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 — ` (tiret cadratin) ; `COMMIT` traité, `PIN` arrête la vague, les autres types sont refusés (`TYPE-NON-GERE`) | le gabarit nomme `-R` : la charte 36 impose `-T` pour les nouveaux tickets | | `Statut :` | doit être `demandé` au départ (P2, avant toute écriture) ; le script écrit `en cours`, puis `fait` ou `refusé ( : )` | le gabarit liste `demandé | en cours | fait | refusé | en attente d'accord` (inchangé), mais les tickets de Big Boss portaient « à faire » | | `Dépôt : — Branche attendue : — HEAD attendu : ` | les deux tirets cadratins ; `Sandbox` dans l'arbre = addon ; `` = 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|D ` avec `/`, relatif à l'arbre, sans `..` ni `.` ni `C:` (chemin non normalisé = refus) ; fichiers partagés seulement dans un PARTAGES (sauf `REPO-JOURNAL.md`) | le gabarit ne dit rien du séparateur | | `Message :` | une ligne : ` : (CHG-nnn) ; corps` + `Tickets : [, ]` 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 : `-T` (charte 36 ; les anciens `-R` gardent leur nom). ~~~ # Ticket -T — Statut : demandé Demandeur : (fiche --) — Date : Dépôt : — Branche attendue : — HEAD attendu : Fichiers : M A D Message : : (CHG-nnn) ; corps `Tickets : -T[, …]` Preuve : — verdict | sans objet () PubCheck : 0 (orchestrateur, -Fichiers sur la liste du ticket) Suite : tag | ticket | aucune Accord utilisateur : « » () | non requis ~~~ Règles lues par le script : `Statut : demandé` à la dépose (le script écrit `en cours`, puis `fait` ou `refusé ( : )`) ; 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---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/.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 `…\-R.md` ») : remplacer `-R` par `-T` (anciens `-R` 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` restant dans `lp-repo` (les sections 2 et 7 citent encore `-R` : à 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 `-R` 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.