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.

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 :

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.

5.4 KiB Raw Blame History Unescape Escape