88 lines
5.4 KiB
Markdown
88 lines
5.4 KiB
Markdown
<!-- file: prompts/012-V0_1_6_START_PROMPT.md -->
|
||
<!-- version: 1 -->
|
||
|
||
# Prompt de démarrage 0.1.6 — adoption réelle de PGR par sasedev-games
|
||
|
||
## Baselines et cible
|
||
|
||
Dépôt canonique PGR : `https://git.sasedev.com/Sasedev/pgr`.
|
||
|
||
La baseline PGR attendue au démarrage effectif de `0.1.6` est l’archive source téléchargée depuis le tag Gitea `v0.1.5`, accompagnée du rapport post-tag `pgr-0.1.5-publish.001-report.md` uniquement si ce rapport a réellement été produit avec statut `PASS`.
|
||
|
||
La session doit également recevoir une archive récente et explicitement autoritaire de `sasedev-games`. Le présent prompt ne fixe volontairement aucun numéro Games : utiliser la baseline réellement fournie et ne pas reconstruire une version depuis d’anciens documents PGR.
|
||
|
||
Version cible PGR : `0.1.6`. Première tranche attendue : `0.1.6-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
|
||
|
||
Exercer réellement le modèle d’adoption PGR contre `sasedev-games`, sans transformer PGR en upstream permanent du projet et sans généraliser les décisions propres à Games.
|
||
|
||
L’objectif est de produire une cartographie explicite `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, puis de matérialiser uniquement les changements réellement justifiés dans la baseline locale Games.
|
||
|
||
La décision de trajectoire autoritaire est enregistrée dans [`../docs/studies/005-V0_1_5_HORIZON_REVIEW.md`](../docs/studies/005-V0_1_5_HORIZON_REVIEW.md).
|
||
|
||
## Intake obligatoire
|
||
|
||
Avant toute modification :
|
||
|
||
- vérifier intégralement la stable PGR `v0.1.5` et le rapport post-tag réellement fourni ;
|
||
- vérifier intégralement l’archive Games fournie et identifier sa version/baseline autoritaire réelle ;
|
||
- relire `RULES.md`, `docs/rules/200-GOVERNANCE.md`, `210-WORKFLOW.md`, `220-SKELETONS.md`, `230-ADOPTION.md`, `300-DOCUMENTATION.md` et `400-VALIDATION.md` ;
|
||
- relire `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`, `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` et les profils techniques réellement applicables au corpus Games observé ;
|
||
- relire le plan historique `011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` et la revue d’horizon `005-V0_1_5_HORIZON_REVIEW.md` ;
|
||
- vérifier les deltas/histories `0.1.5` sans réécrire la vérité opérateur, notamment `alpha.1 PARTIAL` puis `alpha.1.fix.1 PASS` ;
|
||
- vérifier que la première tranche préparée est bien `0.1.6-alpha.1`.
|
||
|
||
## Contrat d’adoption
|
||
|
||
L’audit doit classifier chaque écart réellement pertinent :
|
||
|
||
```text
|
||
ADOPT règle/artefact PGR retenu pour la baseline locale Games
|
||
KEEP-LOCAL décision Games existante conservée comme autorité locale
|
||
OVERRIDE contradiction réelle et documentée avec un MUST PGR applicable
|
||
DEFER sujet potentiellement applicable mais non justifié dans le scope courant
|
||
N/A owner/profil non applicable au corpus Games observé
|
||
```
|
||
|
||
Un écart à un `SHOULD / SHOULD NOT` ne crée pas à lui seul un `OVERRIDE` et ne doit pas être traité comme une non-conformité.
|
||
|
||
Ne pas forcer l’adoption d’un profil uniquement parce qu’il existe dans PGR. L’applicabilité doit être démontrée par la baseline Games réellement fournie.
|
||
|
||
## Autorité locale après adoption
|
||
|
||
PGR sert de snapshot de comparaison et d’adoption. Une fois la baseline locale Games établie, cette baseline et ses owners deviennent l’autorité des sessions/releases suivantes de `sasedev-games`.
|
||
|
||
Les sessions Games ultérieures ne doivent pas rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream documentaire permanent.
|
||
|
||
Un futur réalignement reste possible uniquement comme opération explicitement décidée à partir d’un snapshot PGR précis.
|
||
|
||
## Préservation du contexte Games
|
||
|
||
Les décisions produit, architectures métier, POCs et contraintes propres à Games restent locales lorsqu’elles ne relèvent pas d’un contrat PGR générique.
|
||
|
||
Ne pas promouvoir automatiquement un ancien POC, une technologie historique ou un artefact expérimental au rang de surface produit/applicable. La baseline Games fournie doit démontrer son rôle courant.
|
||
|
||
Ne pas supprimer ou réécrire une décision locale uniquement pour obtenir une symétrie avec PGR.
|
||
|
||
## Hors scope
|
||
|
||
`0.1.6` ne doit pas :
|
||
|
||
- commencer l’adoption de `khadhroony-solana-project`, réservée à `0.1.7` ;
|
||
- commencer les audits Rust/Clippy read-only, réservés à `0.1.8` ;
|
||
- rouvrir les contrats transversaux de `0.1.5` sans contradiction réelle démontrée par l’adoption Games ;
|
||
- rendre Games dépendant de PGR ou de SaseDev Knowledge ;
|
||
- généraliser dans PGR des choix Games uniquement parce qu’ils sont présents dans le corpus ;
|
||
- fabriquer un corpus, une version Games ou une preuve runtime absente de l’archive fournie.
|
||
|
||
## Première tranche attendue
|
||
|
||
`0.1.6-alpha.1` doit être une tranche d’intake et de cartographie : vérifier les deux baselines, inventorier les surfaces Games réelles, déterminer les profils PGR applicables, produire la classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A`, proposer le plan de release et identifier les owners exacts à modifier.
|
||
|
||
Elle ne doit pas effectuer une migration massive avant cette cartographie.
|
||
|
||
La validation doit rester proportionnée au corpus Games réellement applicable et conserver séparées les preuves PGR, les preuves Games et les décisions d’adoption.
|