82 lines
5.1 KiB
Markdown
82 lines
5.1 KiB
Markdown
<!-- 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.
|