0.1.4-rc.1

prompts/011-V0_1_5_START_PROMPT.md

@@ -0,0 +1,81 @@
+<!-- file: prompts/011-V0_1_5_START_PROMPT.md -->
+<!-- version: 1 -->
+
+# Prompt de démarrage 0.1.5 — sémantique normative et autonomie des projets
+
+## Baseline et cible
+
+Dépôt canonique : `https://git.sasedev.com/Sasedev/pgr`.
+
+La baseline attendue au démarrage effectif de `0.1.5` est l’archive source téléchargée depuis le tag Gitea `v0.1.4`, accompagnée du rapport post-tag `pgr-0.1.4-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
+
+Version cible : `0.1.5`. Première tranche attendue : `0.1.5-alpha.1`.
+
+Une archive source de tag peut légitimement ne pas contenir `.git`. Ne pas lui attribuer une preuve Git qu’elle ne peut contenir.
+
+## Mission
+
+Stabiliser avant les adoptions Games/KSP trois contrats transversaux révélés par l’utilisation réelle de PGR :
+
+1. `SHOULD / SHOULD NOT` exprime une forte recommandation non obligatoire et ne doit pas être traité comme un `MUST` affaibli ;
+2. après instanciation/adoption, le projet destinataire devient autonome et ses règles locales sont l’autorité de ses sessions/releases suivantes ;
+3. PGR reste centré sur les contrats de gouvernance/règles réutilisables tandis que howtos, recettes et snippets pratiques pourront vivre dans SaseDev Knowledge lorsque celui-ci est suffisamment fonctionnel, sans créer de dépendance normative de PGR vers Knowledge.
+
+La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/004-V0_1_4_HORIZON_REVIEW.md`](../docs/studies/004-V0_1_4_HORIZON_REVIEW.md).
+
+## Intake obligatoire
+
+Avant toute modification :
+
+- vérifier intégralement l’archive stable `v0.1.4` et le rapport post-tag réellement fourni ;
+- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md` et `400-VALIDATION.md` ;
+- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/003-NEW_SESSION_PROMPT.md` et `007-EXISTING_PROJECT_ADOPTION.md` ;
+- relire la revue d’horizon `004-V0_1_4_HORIZON_REVIEW.md` et le plan historique `010-V0_1_4_TAURI_REEVALUATION_PLAN.md` ;
+- vérifier les deltas/histories `0.1.4`, notamment le `FAIL` explicite de `alpha.2` et son `alpha.2.fix.1 PASS`, sans réécrire cette histoire ;
+- vérifier que la première tranche préparée est bien `0.1.5-alpha.1`.
+
+## Contrat normatif à établir
+
+Le travail doit converger vers les propriétés suivantes sans supposer leur rédaction finale :
+
+```text
+MUST / MUST NOT       obligation ou interdiction normative
+SHOULD / SHOULD NOT   forte recommandation non obligatoire
+MAY                   possibilité neutre
+```
+
+Un écart à un `SHOULD` ne doit pas, à lui seul, provoquer un échec de gate ni exiger un `OVERRIDE`. Une justification locale peut rester utile lorsqu’elle apporte une valeur durable, mais elle ne transforme pas la recommandation en obligation.
+
+## Contrat d’autonomie à établir
+
+L’utilisation de PGR est ponctuelle : sélection d’un snapshot, instanciation/adoption, adaptation, puis établissement d’une baseline locale autonome.
+
+Les sessions/releases ultérieures d’un projet destinataire doivent partir de ses propres règles, plans, architecture et historiques. Elles ne doivent ni rechercher automatiquement « la dernière version de PGR », ni traiter PGR comme un upstream à suivre.
+
+Un réalignement futur avec PGR reste possible uniquement comme scope explicite utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts.
+
+## Frontière avec SaseDev Knowledge
+
+PGR doit rester auto-suffisant pour comprendre ses exigences. `0.1.5` doit formaliser une frontière entre :
+
+- contrats normatifs, owners, skeleton specifications minimales et validations directement liées aux règles, qui restent dans PGR ;
+- howtos, recettes, snippets, exemples pratiques, dépannage et variantes d’implémentation, qui deviennent candidats à Knowledge.
+
+Ne pas déplacer automatiquement du contenu vers SaseDev Knowledge. Si un corpus Knowledge autoritaire est explicitement fourni pendant la session, il MAY servir à vérifier la frontière ou préparer une migration future ; son absence ne bloque pas `0.1.5`.
+
+## Hors scope
+
+`0.1.5` ne doit pas :
+
+- commencer l’adoption de `sasedev-games`, désormais réservée à `0.1.6` ;
+- commencer l’adoption de `khadhroony-solana-project`, désormais réservée à `0.1.7` ;
+- commencer les audits Rust/Clippy read-only, désormais réservés à `0.1.8` ;
+- rouvrir le domaine Tauri `0.1.4` sans défaut transversal réellement démontré ;
+- convertir tous les `SHOULD` existants en `MUST` ou `MAY` mécaniquement ;
+- rendre PGR dépendant de SaseDev Knowledge pour interpréter une règle.
+
+## Première tranche attendue
+
+`0.1.5-alpha.1` doit commencer par un audit transversal des formulations et artefacts concernés, classifier les ambiguïtés réelles, créer/consolider le plan de release et proposer les owners exacts à modifier. Elle ne doit pas réécrire massivement les règles avant cet inventaire.
+
+La validation doit rester proportionnée et inclure au minimum les tests/audits PGR applicables, l’audit d’hygiène texte et des contrôles structurels prouvant que les adoptions Games/KSP n’ont pas été commencées prématurément.