93 lines
10 KiB
Markdown
93 lines
10 KiB
Markdown
|
Fiche UES1-RECH-01 — Niveau N1 — Modèle prévu sonnet | utilisé claude-sonnet-5-5 — Agent lp-validator — Skills sk-protocol, lp-validate, sk-recount
|
|||
|
|
# UES1-RECH-01 : scénarios de déclenchement des clauses « Pas pour » (SK-ARBRE R8, idée A3) (2026-10-15)
|
|||
|
|
|
|||
|
|
Hors gabarit : la RECH n'a pas de gabarit dans `lp-doc/gabarits.md` ; sections libres, tête commune reprise.
|
|||
|
|
|
|||
|
|
## 0. Méthode et niveau de preuve
|
|||
|
|
- **Niveau de preuve : estimé.** Analyse sur texte seulement : aucun appel de modèle, aucun essai de sélection réelle.
|
|||
|
|
Je lis les descriptions avant (instantané `D:\Game\LifePlay_Backup_5.5\UES1-addon58\Tools\claude\skills\<skill>\SKILL.md`, ligne 3)
|
|||
|
|
et après (addon actuel), plus les descriptions des skills voisins telles que listées dans la session, et je dis
|
|||
|
|
quel skill un agent choisirait en lisant ces seules descriptions. Le choix réel d'un modèle peut différer.
|
|||
|
|
- 6 skills × 3 demandes = 18 scénarios : (N) nette, (L) limite, (V) doit aller au voisin nommé par « Pas pour ».
|
|||
|
|
- Essai qui trancherait (incertain → établi) : donner à `claude -p` (modèle réel lu dans `modelUsage`) la liste des
|
|||
|
|
descriptions avant, puis après, avec chaque demande, et compter le skill invoqué, 5 passes par demande.
|
|||
|
|
- Changement de description : `lp-mcp` (clause + ligne `Triggers -`), `lp-commandlets`, `lp-build`, `lp-validate`, `lp-repo`
|
|||
|
|
(clause seule). `lp-doc` : description **inchangée** (diff de l'IMPL : hunk `71a72-76`, ligne 3 intacte), seule la section
|
|||
|
|
« Rédiger un skill » est nouvelle ; ses scénarios testent donc si cette section est atteignable.
|
|||
|
|
- Verdict par scénario : **améliore** / **ne change pas** / **dégrade** (le choix avant → après).
|
|||
|
|
|
|||
|
|
## 1. lp-mcp
|
|||
|
|
Après : « … Pas pour : un commandlet ou un script pythonscript éditeur fermé (lp-commandlets), une compilation (lp-build). Triggers - MCP, unreal-mcp, Blueprint, BP_, Accessed None, call_tool, toolset. » Voisins : `lp-commandlets`, `lp-build` ; concurrent hors LifePlay : `unreal-mcp` (plugin Epic, déclencheurs `BP_`, `.uproject`, « in my game »).
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Le journal PIE montre 40 Accessed None sur BP_Person ; trie-les et pose une garde IsValid par MCP, l'éditeur est ouvert. » | `lp-mcp` (« Accessed None », « petit correctif Blueprint par MCP ») | `lp-mcp` | ne change pas. Le plugin `unreal-mcp` couvre aussi « edit a Blueprint », mais `lp-mcp` nomme « Accessed None » et la copie 5.8. |
|
|||
|
|
| L | « Le toolset MSVC 14.50 n'est pas trouvé par UBT, que faire ? » | `lp-build` (« toolset MSVC » dans sa description) | `lp-build` | ne change pas, **risque noté** : le mot nu « toolset » est maintenant un déclencheur de `lp-mcp` ; la clause « Pas pour : une compilation (lp-build) » le compense. Faible dégradation possible si le modèle ne lit que `Triggers -`. |
|
|||
|
|
| L' | « Ajoute un jeu d'outils MCP qui lit les noms d'événements d'un Blueprint. » | `create-toolset` (plugin) : `lp-mcp` sans mot « toolset » | `create-toolset` ou `lp-mcp` (déclencheur « toolset », corps : `references/toolset.md`) | améliore **si** le plugin Epic est désactivé (geste de l'utilisateur prévu) : `lp-mcp` devient atteignable ; sinon ne change pas (le plugin décrit exactement ce cas). |
|
|||
|
|
| V | « Lance LPDumpFunction -Pins sur BP_Person, l'éditeur est fermé. » | `lp-commandlets` ou `lp-mcp` (« lecture … de Blueprint ») | `lp-commandlets` (`lp-mcp` : « Pas pour … commandlet … éditeur fermé ») | **améliore** |
|
|||
|
|
|
|||
|
|
(Le scénario L est la demande « limite » demandée par la fiche ; L' est un cas additionnel dû à la ligne `Triggers - toolset`.)
|
|||
|
|
|
|||
|
|
## 2. lp-commandlets
|
|||
|
|
Après : « … Pas pour : un Blueprint lu ou corrigé éditeur ouvert par MCP (lp-mcp), une compilation (lp-build). » Voisins : `lp-mcp`, `lp-build`.
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Écris un script pythonscript qui resauvegarde tous les assets du dossier Maps, éditeur fermé. » | `lp-commandlets` | `lp-commandlets` | ne change pas |
|
|||
|
|
| L | « Je veux lire le graphe de la fonction Foo de BP_Person ; je ne sais pas si je dois ouvrir l'éditeur. » | `lp-mcp` ou `lp-commandlets` (« dump », « lecture de Blueprint ») | `lp-commandlets` si éditeur fermé, `lp-mcp` si ouvert : la distinction passe par l'état de l'éditeur, nommée des deux côtés | **améliore** (frontière explicite) ; le « je ne sais pas » reste ambigu, l'agent doit poser la question |
|
|||
|
|
| V | « L'éditeur est ouvert avec le MCP : corrige l'Accessed None de BP_Person en ajoutant un IsValid. » | `lp-mcp` ; `lp-commandlets` attire par « fix » | `lp-mcp` | améliore légèrement (`lp-commandlets` écarte le cas « éditeur ouvert par MCP ») |
|
|||
|
|
|
|||
|
|
## 3. lp-build
|
|||
|
|
Après : « … Complète ue-cpp-build ; ne corrige rien. Validation : lp-validate. Pas pour : les règles C++ UE générales (ue-cpp-build), un commandlet seul (lp-commandlets). » Voisins : `ue-cpp-build`, `lp-commandlets` (autre voisin non nommé : `lp-ue-compat`).
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Build.ps1 s'arrête sur C2374 en compilant LifePlayEditor 5.8 ; recompile et donne le résumé compté. » | `lp-build` | `lp-build` | ne change pas |
|
|||
|
|
| L | « Comment j'appelle RunCommandlet.ps1 pour lancer LPTestStringCompat ? » | `lp-build` (qui nomme `RunCommandlet.ps1`) ou `lp-commandlets` ou `lp-validate` (§ 3 du corps) | `lp-commandlets` (« un commandlet seul ») ; `lp-validate` reste possible si la demande vient d'une VAL | **améliore** : le piège « RunCommandlet.ps1 dans la description de `lp-build` » est désamorcé |
|
|||
|
|
| V | « Explique-moi BuildSettingsVersion et IncludeOrderVersion dans un Target.cs, sans lien avec notre build. » | `ue-cpp-build` ou `lp-build` (« pièges de compilation ») | `ue-cpp-build` (« règles C++ UE générales ») | **améliore** |
|
|||
|
|
|
|||
|
|
## 4. lp-validate
|
|||
|
|
Après : « … Pas pour : recompter un livrable hors fiche VAL (sk-recount), la preuve avant de clore sa propre tâche (debug-verification). » Voisins : `sk-recount`, `debug-verification`.
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Valide la fiche U3-VAL : recompte le build depuis le journal, rejoue LPTestStringCompat et la porte G-U3. » | `lp-validate` | `lp-validate` | ne change pas |
|
|||
|
|
| L | « Le sous-agent dit avoir corrigé 12 fichiers ; vérifie son livrable et ses chiffres (pas de fiche VAL). » | `lp-validate` (« recompter », « contre-vérifier », « IMPL deliverable ») ou `sk-recount` | `sk-recount` (« hors fiche VAL »), `lp-validate` encore possible via ses mots-clés | **améliore** modérément : les triggers « recompter » et « contre-vérifier » restent dans `lp-validate` ; l'exclusion est une seule phrase en fin de description |
|
|||
|
|
| V | « Avant de dire que j'ai fini mon correctif, quelle preuve dois-je rejouer ? » | `debug-verification` (« terminé », « PASS ») ou `lp-validate` (« PASS », « FAIL », « verifying ») | `debug-verification` | **améliore** |
|
|||
|
|
|
|||
|
|
## 5. lp-repo
|
|||
|
|
Après : « … Triggers - commit, tag, pin, push, ticket, gardien, verrou, NUMEROS, ue5.8, lot/DC3-atelier, Content/Modules, LifePlay-Sandbox. Pas pour : la méthode générale du gardien unique hors LifePlay (sk-repo). » Voisin : `sk-repo`.
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Prépare le ticket au gardien : commit de l'addon 5.8, puis pin dans le jeu. » | `lp-repo` | `lp-repo` | ne change pas |
|
|||
|
|
| L | « Comment un gardien unique et un verrou évitent-ils les collisions de commit entre agents ? » (sans dire LifePlay) | `lp-repo` ou `sk-repo` (mots communs : gardien, verrou, ticket) | `sk-repo` si l'agent lit la clause « méthode générale » | **améliore** légèrement ; reste ambigu, car « hors LifePlay » n'aide pas quand la question est générale mais posée dans le dépôt LifePlay |
|
|||
|
|
| V | « Je monte le dépôt d'un autre projet : une seule session écrit dans git, quelle méthode ? » | `lp-repo` (triggers commit, tag, gardien, verrou) | `sk-repo` | **améliore** |
|
|||
|
|
|
|||
|
|
## 6. lp-doc (description inchangée, section « Rédiger un skill » ajoutée l. 72-76)
|
|||
|
|
Description (avant = après) : « Formats documentaires LifePlay : entrée CHG …, ligne ERR …, docs numérotées …, fiches de lot, mémoire du projet. À utiliser pour consigner un changement, une erreur, créer ou renuméroter un document, ou mettre à jour un index. » Aucun mot « skill » ni « rédiger un skill ».
|
|||
|
|
|
|||
|
|
| # | Demande | Avant | Après | Effet |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| N | « Ajoute l'entrée CHG du lot UES1 au journal. » | `lp-doc` | `lp-doc` | ne change pas |
|
|||
|
|
| L | « Rédige le nouveau skill lp-xyz et coupe ce qui est inutile. » | aucun skill LifePlay évident ; `skill-creator` (générique) possible | idem : la section est invisible depuis la description, donc **non atteinte** par ce choix ; si `lp-doc` est chargé pour une autre raison (CHG), la règle est lue | ne change pas ; **la section n'apporte rien au déclenchement** |
|
|||
|
|
| V | « Écris un Agent Skill enregistré dans un plugin Unreal (dossier Skills/ du plugin). » | `unreal-skill` (plugin) | `unreal-skill` | ne change pas (le plugin décrit ce cas ; `lp-doc` n'a pas de « Pas pour », ni besoin) |
|
|||
|
|
|
|||
|
|
Observation : pour que la règle R13 atteigne les rédacteurs de skills, il faut soit citer « rédiger un skill » dans la description de `lp-doc`
|
|||
|
|
(donc un nouveau R8), soit la lire par `SK-ARBRE.md` (R13) ; recommandation à l'orchestrateur, non appliquée ici.
|
|||
|
|
|
|||
|
|
## 7. Bilan
|
|||
|
|
| Skill | N | L | V | Bilan |
|
|||
|
|
|---|---|---|---|---|
|
|||
|
|
| lp-mcp | ne change pas | ne change pas (risque « toolset ») | améliore | net positif |
|
|||
|
|
| lp-commandlets | ne change pas | améliore | améliore | positif |
|
|||
|
|
| lp-build | ne change pas | améliore | améliore | positif |
|
|||
|
|
| lp-validate | ne change pas | améliore (modéré) | améliore | positif |
|
|||
|
|
| lp-repo | ne change pas | améliore (léger) | améliore | positif |
|
|||
|
|
| lp-doc | ne change pas | ne change pas | ne change pas | neutre ; section non atteinte par la description |
|
|||
|
|
Aucune dégradation établie ; un risque estimé : le déclencheur nu « toolset » de `lp-mcp` face à « toolset MSVC » (`lp-build`, `lp-env`).
|
|||
|
|
Pairs hors clause : `lp-build` / `lp-ue-compat` (erreurs C4996 5.8), `lp-validate` / `lp-lot` ; non traités (R11 : couche 1-2 `sk-*` non touchée,
|
|||
|
|
donc aucune clause de retour côté `sk-recount`, `debug-verification`, `sk-repo`, `ue-cpp-build`).
|
|||
|
|
|
|||
|
|
Tours : 13 / 30 (décompte propre ; `FicheStats.py` non lancé)
|