pgr/prompts/011-V0_1_5_START_PROMPT.md

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.

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 :

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.