LifePlay-Revival/Docs/Migration/etat/AG/PUB3/PUB3-T2-PROPOSITION.md
edujiro5972 8084622450 LifePlay UE 5.8 : état de développement au 2026-10-19
Tickets : REP1-T4

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
2026-10-19 22:57:42 +02:00

14 KiB
Raw Blame History

Fiche PUB3-T2 — Niveau N2 — Modèle prévu opus | utilisé opus-5-5 (claude-opus-5-5, déclaré par l'environnement) — Agent orchestrateur PUB3 (session principale) — Skills lp-repo (lecture), sk-change-safety, lp-paths

PUB3-T2-PROPOSITION : retirer le nom du compte avant tout push de ue5.8 (2026-10-13)

Décision de l'utilisateur (2026-10-13, dans la session du lot) : « Q1 a, Q2 a, Q8 PUB3 ; le reste comme recommandé ». Donc : voie A puis publication C2 ; %USERPROFILE% ; Q3 (a), Q4 (a), Q5 (a) ; Q6 (b) si D-REPO5 est accordée, sinon (a) ; Q7 sans objet ; lot renommé PUB3. GO de Big Boss attendu.

Proposition soumise à l'utilisateur. Rien n'est appliqué : aucun fichier corrigé, aucun commit, aucune réécriture, aucun script installé. Chiffres : PUB3-T1-INV.md. Le nom est écrit <compte>.

1. Le fait qui décide

Pousser ue5.8 envoie tout son historique, soit 103 commits, dont 23 qui portent le nom (le premier est 1542dfa, CHG-249). Un commit de correction seul (voie A) nettoie la pointe de la branche, mais pas ces 23 commits : ils restent lisibles sur GitHub après un git push origin ue5.8. La voie A ne suffit donc que si la publication se fait autrement qu'en poussant ue5.8 telle quelle. C'est déjà le cas depuis le lot PUB2 : les tags publics v1.0 à v1.5 pointent sur une copie filtrée de l'historique local (ue5.5-v1.x ≠ v1.x, PUB3-T1-INV § 2.3). J'ajoute donc une voie C qui reprend ce précédent.

Ce qu'il y a à corriger :

Dépôt Fichiers Lignes Forme Commits avec le nom (non publics)
jeu ue5.8 69 (2 sous Docs/, 67 sous Docs/Migration/etat/) 109 (116 occurrences) toujours C:\Users\<compte> 23
addon ue5.8 et lot/DC3-atelier (privé) 1 (Tools/claude/skills/lp-doc/SKILL.md), plus 1 fichier non suivi (Docs/CG/CG-METHODE.md) 1 C:\Users\<compte> 1 (f0af432)
jeu 5.5 main (copie figée, jamais poussée) 2 5 C:\Users\<compte> 2
branches locales ue5.5-v1.1 à v1.5, claude/… 6 à 8 — — 4 (lots L7, 2026-10-01)

0 nom de machine, 0 occurrence du nom dans les binaires et dans les refs publiques. Correction (T5) : 1 adresse personnelle est publique sur origin/main (PUB3-T1-INV § 2.1), hors du périmètre de cette proposition : signalée à Big Boss.

2. Remplacement proposé (commun à A, B et C)

Une seule règle, casse ignorée : C:\Users\<compte> → %USERPROFILE%. Elle couvre les 116 occurrences ; il n'y a pas de nom hors chemin. Après le remplacement : %USERPROFILE%\.claude\…, %USERPROFILE%\AppData\…. C'est la notation déjà utilisée par TRACE1 et EVAL-R2. <utilisateur> ne servirait que si une commande citée doit rester exécutable dans Git Bash, ce qui n'est le cas d'aucune des 116 occurrences : ce sont des chemins dans du texte. Script de remplacement par fichier, avec liste fermée (PUB3-T1-fichiers.csv), recompte avant / après et diff --word-diff lu en entier, sans sed -i global.

3. Les voies

A. Commit de correction (l'historique local garde le nom)

  • Geste : un commit jeu ue5.8 (69 fichiers, ticket au gardien, avec le jeton du journal pour la ligne CHG). Un commit pour chaque branche de l'addon (1 fichier, deux tickets jumeaux comme P7-R1 et R2). Instantané Snapshot.ps1 avant.
  • Hash : aucun ne change. Journal CHG, doc 21 (pin), REPO-JOURNAL, NUMEROS et registres restent justes.
  • Risques : le nom reste dans 23 commits. Un git push origin ue5.8 le publierait (voir § 1). C'est seulement acceptable si un contrôle avant le push (§ 4) bloque ce push, et si la publication suit la voie C. Risque faible de conflit avec les sessions actives : 0 des fichiers concernés n'est modifié dans l'arbre actuellement, mais STE-TACHES.md et d'autres *-TACHES.md bougent souvent. Le ticket prend le fichier tel qu'il est au moment du passage.
  • Durée : ≈ 1 h (script et recompte 20 min, VAL 15 min, 3 tickets au gardien 25 min).

B. Réécriture de l'historique non poussé, puis A si besoin

  • Geste : arrêt de toutes les sessions qui écrivent dans le dépôt du jeu, puis git bundle create D:\Game\LifePlay_Backup_5.5\<lot>\jeu-58-avant.bundle --all. Ensuite, réécriture de 1542dfa^..ue5.8 par git filter-repo --replace-text (règle du § 2) sur ue5.8, main (local) et les 24 tags locaux qui en dépendent. Contrôles : arbre de la pointe identique à « A appliquée » (git diff des deux = vide), pickaxe 0, nombre de commits inchangé (102). La règle s'applique aussi à la pointe : A n'est plus utile que pour les fichiers non encore commités.
  • Hash : 102 commits changent, et avec eux les 24 tags *-avant / *-apres / OUTC-valide / ue5.5-final. Hash cités qui ne résolvent plus : 24 dans le journal CHG, 51 dans REPO-JOURNAL, 3 dans le doc 21 (hash du jeu ; le pin de l'addon ne change pas si l'addon n'est pas réécrit), 1 dans NUMEROS, environ 116 dans Docs + Tools. On ne réécrit pas les textes, car corriger un hash dans un commit le change à nouveau. On publie plutôt la correspondance ancien → nouveau (.git/filter-repo/commit-map, copiée en PUB3-B-commit-map.csv). S'y ajoute une ligne CHG qui renvoie vers ce fichier.
  • Risques :
    • (1) Il faut geler toutes les sessions du dépôt du jeu, CAM et P7 comprises, pendant ≈ 1 h. L'arbre doit être propre : aujourd'hui, 9 fichiers modifiés et 15 entrées non suivies d'autres lots.
    • (2) git filter-repo n'est pas installé. Il faut le télécharger depuis PyPI, avec l'accord de l'utilisateur. git filter-branch est interdit aux agents (settings.local.json, deny).
    • (3) Le clone 5.5 partage 190bd56 à 1825884 : il diverge. Il est figé, mais une citation croisée deviendrait fausse.
    • (4) Le piège lp-repo § 10 « ne jamais repartir d'une sauvegarde .git antérieure » s'applique : le bundle sert au retour arrière seulement.
    • (5) Les commits non publics des branches ue5.5-v1.x ne sont pas concernés : il faut une décision à part (Q5).
  • Durée : ≈ 3 h à 4 h, dont 1 h de gel, plus la reprise des sessions.

C (recommandée). A maintenant, puis publication par une branche propre (modèle PUB2)

  • Geste : A tout de suite. Ensuite, le jour du push, on crée une branche de publication dont l'historique ne contient pas les 23 commits. C'est cette branche que l'utilisateur pousse ; ue5.8 locale ne bouge pas.
    • C2, un commit par publication (recommandée) : git commit-tree ue5.8^{tree} -p origin/main -m "<titre>" crée un seul commit dont l'arbre est celui d'ue5.8 corrigée. Il est posé sur origin/main, puis sur la publication précédente aux fois suivantes. Contrôle PubCheck -Plage (§ 4) sur ce commit, puis ref pub/ue5.8. Aucun outil à installer.
    • C1, historique détaillé filtré : même résultat, mais les 103 commits sont rejoués filtrés par git filter-repo --refs sur une copie de branche. Il faut installer l'outil (Q7) et refaire le filtre sur la plage nouvelle à chaque publication.
  • Hash : aucun hash local ne change. Les hash publics diffèrent des hash cités, comme pour v1.x depuis PUB2 : c'est déjà la règle du dépôt.
  • Risques :
    • (1) Pousser ue5.8 par erreur au lieu de pub/ue5.8 publierait le nom. Le contrôle pre-push du § 4 refuse ce push.
    • (2) C2 publie un historique grossier, un commit par publication : on ne peut pas faire de blame fin sur GitHub. Le détail reste local et dans le journal CHG.
    • (3) Il faut tenir deux lignées (locale et publique), ce qui est déjà le cas.
  • Durée : A ≈ 1 h ; C2 ≈ 20 min par publication ; C1 ≈ 1 h la première fois, puis ≈ 20 min.

Comparaison

A seule B C2 (recommandée)
Nom absent du public après push non si ue5.8 est poussée telle quelle oui oui
Hash cités (journal, doc 21, REPO-JOURNAL, NUMEROS, tags) intacts 102 commits et 24 tags changent, table de correspondance intacts
Gel des sessions non oui, ≈ 1 h non
Outil à installer non git-filter-repo non
Retour arrière git revert bundle supprimer la branche pub/ue5.8
Durée ≈ 1 h ≈ 3-4 h ≈ 1 h + 20 min par publication

Addon (privé) : A seule suffit (Q4). Le nom n'y est que dans 1 fichier et 1 commit, dans un dépôt non public. Réécrire l'addon changerait le pin (28 commits d'ue5.8, 25 de DC3, 6 tags).

4. Contrôle automatique avant chaque ticket du gardien

Un script, trois points d'appel.

  • Script : Tools\PubCheck.ps1 dans le jeu, en lecture seule, avec 4 modes :

    • -Fichiers <liste> : contenu entier, mode d'orchestrateur avant ticket ;
    • -Index : lignes ajoutées de l'index privé, git diff --cached -U0 ;
    • -Plage <a>..<b> : lignes ajoutées de toute la plage, plus les blobs binaires en ASCII et UTF-16LE (méthode de PUB3-T1-INV § 1) ;
    • -Arbre <ref>.

    Il sort chemin:ligne:catégorie sans jamais la valeur (masquée <compte>). Codes de sortie : 0 net, 1 trouvé, 2 erreur.

  • Points d'appel :

    1. L'orchestrateur lance -Fichiers sur la liste de son ticket avant de le déposer. Cela supprime les refus tardifs (4 refus jusqu'ici).
    2. Le gardien l'appelle à l'étape 4 de lp-repo, en mode -Index sur l'index privé. Il cite « PubCheck : 0 » au REPO-JOURNAL, ce qui remplace les recherches faites à la main ligne par ligne aujourd'hui.
    3. Un hook pre-push appelle -Plage <distant>..<local> pour chaque ref poussée. C'est la seule barrière qui protège le public, et elle vaut aussi pour l'utilisateur, qui pousse lui-même : pas d'exemption LP_REPO_HUMAIN pour ce hook.

    En option, le pre-commit existant (etat\REPO\hooks\) reçoit une 5ᵉ règle qui appelle -Index. Mais core.hooksPath n'est installé dans aucun arbre (décision D-REPO5 en attente) : les deux hooks s'installent par un même ticket.

  • Pas dans le hook Claude PreToolUse (ecriture-gardien.py) : il voit des commandes, pas le contenu commité, et ralentirait chaque appel.

  • Motifs et faux positifs :

Catégorie Motif (lu à l'exécution, jamais écrit) Admis (pas d'alerte) Faux positifs évités
nom du compte $env:USERNAME, casse ignorée, borné par un caractère non alphanumérique — 0 occurrence hors chemin aujourd'hui
dossier personnel [A-Za-z]:[\\/]{1,2}Users[\\/]{1,2} et /[a-z]/Users/ suivis d'un caractère de nom <…>, %…%, $env:, Public, Default, All Users le motif du script lui-même (suivi de [) ne déclenche pas
nom de machine $env:COMPUTERNAME, mot entier — sans -w, des milliers de sous-chaînes (PUB3-T1-INV § 2.1)
adresse expression d'adresse générique *@users.noreply.github.com, noreply@anthropic.com, @example.(com|org|net) les mots gmail et googlemail sans @ (13 fichiers de règles) ne déclenchent pas
binaires nom en ASCII et UTF-16LE dans les blobs (-Plage seulement) — -I en mode texte
  • Portée : en -Index, on ne regarde que les ajouts. Les 69 fichiers actuels ne bloquent donc pas les commits des autres lots avant la correction A. En -Plage, on regarde tout l'historique poussé, ce qui bloque git push origin ue5.8 tant que les 23 commits y sont (voies A et C).
  • Durée : IMPL 1 h (lp-impl), VAL 30 min (lp-validator, preuve par l'échec sur un fichier témoin hors dépôt). Installation des hooks : 1 ticket au gardien par arbre (jeu 5.8, addon 5.8, addon 5.5).

5. Déroulé proposé (après GO)

T3 SPEC (liste fermée, textes exacts, script de remplacement, PubCheck.ps1), T4 IMPL de A (instantané, script, recompte 0), T5 IMPL PubCheck.ps1, T6 VAL (recompte par les deux formulations, preuve par l'échec), T7 DOC (CHG, lp-repo § 4 et § 9, lp-paths : tag ue5.5-final non public, ref c55/main orpheline), puis tickets au gardien (jeu, addon ×2, hooks). La publication C2 se fait plus tard, le jour du push, sur l'ordre de l'utilisateur.

6. Questions fermées à l'utilisateur

# Question Choix Recommandé
Q1 Quelle voie pour le jeu ? (a) A puis publication C2 (un commit par publication) ; (b) A puis C1 (historique filtré, outil à installer) ; (c) B, réécriture en place ; (d) A seule (a)
Q2 Texte de remplacement ? (a) %USERPROFILE% ; (b) <utilisateur> (a)
Q3 Copie 5.5 (main, 2 fichiers, figée, jamais poussée) ? (a) laisser telle quelle ; (b) corriger aussi (a)
Q4 Addon privé (1 fichier, 2 branches, plus CG-METHODE.md non suivi) ? (a) commit de correction A ; (b) rien ; (c) réécriture (a)
Q5 Branches locales ue5.5-v1.1 à v1.5 et claude/… (4 commits avec le nom, jamais poussées) ? (a) laisser, jamais poussées, et pre-push les bloque ; (b) bundle dans Backup_5.5 puis suppression (a)
Q6 Contrôle automatique ? (a) PubCheck.ps1 + étape du gardien + pre-push ; (b) idem + règle pre-commit ; (c) script seul, sans hook (b) si D-REPO5 est accordée, sinon (a)
Q7 Téléchargement de git-filter-repo depuis PyPI (seulement si Q1 = b ou c) ? oui / non sans objet si Q1 = (a)
Q8 Nom du lot : un lot PUB1 a déjà existé (Backup_5.5\PUB1\git_avant, puis PUB2, règles de publication du doc 27) (a) renommer en PUB3 (dossier, instantanés) ; (b) garder PUB1, instantanés sous Backup_5.5\PUB1-2026-10-13\ (a)

Hors périmètre, signalé : avant tout push de ue5.8, il faudra aussi appliquer à tous les .md et .csv suivis de Docs/Migration/etat/ (et pas seulement aux 67 fichiers concernés ici) les règles PUB1/PUB2 du doc 27 (pas de contenu de jeu ni de contenu sexuel sur GitHub). Ce lot ne les a pas contrôlées.