# 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.