0.0.2-rc.1

prompts/003-V0_0_3_START_PROMPT.md

@@ -0,0 +1,146 @@
+<!-- file: prompts/003-V0_0_3_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.0.3 — templates initiaux et audits réutilisables
+
+## Base et cible
+
+Dépôt canonique :
+
+```text
+https://git.sasedev.com/Sasedev/pgr
+```
+
+Baseline attendue au démarrage effectif de `0.0.3` : archive source issue du tag stable :
+
+```text
+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 :
+
+```text
+0.0.3
+```
+
+Première tranche attendue :
+
+```text
+0.0.3-alpha.1
+```
+
+## Entrées de reprise à fournir
+
+La nouvelle session doit recevoir au minimum :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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 :
+
+```text
+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é :
+
+```text
+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 :
+
+```text
+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.