5.4 KiB
Prompt de démarrage 0.0.3 — templates initiaux et audits réutilisables
Base et cible
Dépôt canonique :
https://git.sasedev.com/Sasedev/pgr
Baseline attendue au démarrage effectif de 0.0.3 : archive source issue du tag stable :
v0.0.2
L'archive taggée Gitea est la baseline autoritaire du dépôt. Elle peut légitimement ne pas contenir .git.
Version cible :
0.0.3
Première tranche attendue :
0.0.3-alpha.1
Entrées de reprise à fournir
La nouvelle session doit recevoir au minimum :
pgr-v0.0.2.zip
après téléchargement depuis le tag Gitea v0.0.2.
Après la publication stable, la session de clôture doit également produire une preuve post-tag séparée, normalement :
pgr-0.0.2-publish.001-report.md
Si ce rapport existe et que publish.001 est PASS, il SHOULD être fourni à la nouvelle session avec l'archive taggée. Il complète la preuve d'intake mais ne remplace jamais l'audit de l'archive par la nouvelle session et ne fait pas partie du tag stable.
Si le rapport n'a pas été produit ou n'est pas disponible, la nouvelle session doit l'indiquer explicitement au lieu d'en supposer l'existence.
Prompt manuel de nouvelle session
Après publish.001 PASS, le texte manuel canonique à utiliser pour ouvrir la session 0.0.3 est :
Partir de v0.0.2 (téléchargé via le lien ZIP de la version taggée sur Gitea) et du rapport post-tag pgr-0.0.2-publish.001-report.md, lire et exécuter prompts/003-V0_0_3_START_PROMPT.md, faire une vérification complète de l'archive et surtout des règles, de la gouvernance, de la structure documentaire, des deltas/histories et de la cohérence globale avant de démarrer 0.0.3-alpha.1.
Ce texte doit être présenté spontanément à l'opérateur pendant la clôture stable de 0.0.2; il ne doit pas dépendre d'une demande supplémentaire.
Mission
0.0.3 doit introduire les premiers templates techniques réutilisables et les premiers patterns d'audit issus de besoins réellement démontrés par les profils 0.0.2 et par les projets de référence.
La release ne doit pas chercher à construire un catalogue exhaustif. alpha.1 MUST commencer par auditer intégralement la stable v0.0.2, vérifier les profils et audits réellement présents, inventorier les templates/patterns qui apportent une valeur immédiate et découper la version en tranches proportionnées avant de matérialiser massivement des fichiers.
Acquis de 0.0.2
La baseline stable attendue doit notamment contenir :
docs/architecture/003-RULE_PROFILE_MODEL.md
docs/rules/500-LANGUAGES.md
docs/rules/510-RUST_CARGO.md
docs/rules/520-JAVA_MAVEN_GRADLE.md
docs/rules/600-PLATFORMS.md
docs/rules/610-ANDROID.md
scripts/audit_markdown_tables.py
scripts/audit_markdown_links.py
Les profils matérialisés sont volontairement limités à Rust/Cargo, Java/Maven/Gradle et Android. Les autres domaines restent différés et ne deviennent pas automatiquement le scope de 0.0.3.
Principes pour les templates
Un template 0.0.3 doit :
- répondre à un besoin concret et répété ;
- avoir un owner et un scope clairs ;
- respecter les structures canoniques de l'écosystème ;
- rester minimal et paramétrable plutôt que copier un projet complet ;
- ne pas figer des versions arbitraires de toolchain ou de dépendances ;
- ne pas introduire un générateur tant que la spécification Markdown du template suffit ;
- rester distinct d'une skeleton specification complète, réservée à
0.0.4.
Les templates de workflow, notamment la forme du prompt manuel de nouvelle session et la transmission explicite d'une preuve publish.001, MAY être examinés en 0.0.3 s'ils peuvent être factorisés sans créer un générateur prématuré.
Principes pour les audits
Les audits PGR restent read-only, déterministes et monotâches autant que raisonnablement possible.
Le point de départ est le besoin réellement éprouvé :
tables Markdown
liens Markdown locaux
Les audits plus complexes de KSP ou sasedev-games sont des corpus de comparaison. 0.0.3 doit les décomposer par propriété stable au lieu de copier leurs scripts combinés tels quels.
Un audit spécialisé n'est matérialisé que lorsqu'il possède :
- une propriété objectivement contrôlable ;
- un owner documentaire ;
- un sujet réel dans un template, skeleton ou projet ;
- une valeur distincte d'un compilateur, linter ou build tool officiel.
Hors périmètre attendu
Sauf REPLAN justifié, 0.0.3 ne doit pas encore :
- créer les skeleton specifications complètes prévues pour
0.0.4; - créer un générateur PGR ;
- réécrire KSP ou
sasedev-games; - matérialiser tous les profils technologiques différés ;
- transformer des exemples de configuration en versions obligatoires universelles ;
- regrouper plusieurs contrôles indépendants dans un audit monolithique uniquement pour réduire le nombre de scripts.
Règles de travail
Le cycle PGR reste :
delta N
→ validation opérateur
→ history N
→ commit N
→ delta N+1
Le delta suivant MUST NOT être appliqué avant le commit de la tranche courante.
Une interruption de session ne crée pas une nouvelle version. Reprendre depuis la dernière tranche réellement committée et son history ; produire un handoff uniquement lorsqu'il apporte une valeur réelle.