106 lines
5.4 KiB
Markdown
106 lines
5.4 KiB
Markdown
<!-- file: docs/studies/005-V0_1_5_HORIZON_REVIEW.md -->
|
||
<!-- version: 2 -->
|
||
|
||
# Revue d’horizon 0.1.5 — adoption Games après stabilisation des contrats transversaux
|
||
|
||
## Objet
|
||
|
||
Cette étude clôt la revue d’horizon limitée exigée par le plan `0.1.5`. Elle vérifie si la stabilisation de la sémantique normative, de l’autonomie locale et de la frontière PGR / SaseDev Knowledge révèle un nouveau prérequis avant l’adoption réelle de `sasedev-games`.
|
||
|
||
La revue ne cherche pas à prolonger artificiellement la roadmap. Elle réévalue uniquement les dépendances déjà engagées et les faits démontrés pendant `0.1.5`.
|
||
|
||
## Contrats acquis en 0.1.5
|
||
|
||
La release candidate s’appuie sur trois contrats désormais réconciliés :
|
||
|
||
```text
|
||
SHOULD / SHOULD NOT forte recommandation non obligatoire
|
||
baseline locale autorité des sessions/releases suivantes
|
||
PGR / Knowledge PGR normatif auto-suffisant, Knowledge pratique complémentaire
|
||
```
|
||
|
||
La gate `beta.1` confirme qu’aucun nouveau renforcement accidentel de `SHOULD`, aucune dépendance implicite à une version PGR plus récente et aucune dépendance normative vers SaseDev Knowledge ne restent démontrés dans les owners relus.
|
||
|
||
## Vérification du prochain prérequis réel
|
||
|
||
La trajectoire précédente réserve :
|
||
|
||
```text
|
||
0.1.6 adoption sasedev-games
|
||
0.1.7 adoption khadhroony-solana-project
|
||
0.1.8 audits Rust/Clippy read-only
|
||
```
|
||
|
||
`0.1.5` n’a révélé aucun owner transversal supplémentaire qui devrait obligatoirement précéder l’adoption Games.
|
||
|
||
Les contrats maintenant disponibles suffisent pour engager une adoption proportionnée :
|
||
|
||
- classification `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
|
||
- distinction explicite entre obligations `MUST` et recommandations `SHOULD` ;
|
||
- baseline locale autonome après adoption ;
|
||
- réalignement futur uniquement explicite et fondé sur un snapshot PGR choisi ;
|
||
- validation proportionnée au scope réellement applicable ;
|
||
- absence de dépendance normative vers Knowledge.
|
||
|
||
Décision : **conserver `0.1.6` comme prochaine release et y effectuer l’adoption réelle de `sasedev-games`**.
|
||
|
||
## Corpus requis pour 0.1.6
|
||
|
||
La future session `0.1.6` doit disposer de deux baselines autoritaires distinctes :
|
||
|
||
1. la stable PGR `v0.1.5` réellement publiée et vérifiée post-tag ;
|
||
2. une archive récente et explicitement autoritaire de `sasedev-games`, fournie comme corpus d’adoption.
|
||
|
||
Cette revue confirme qu’aucun numéro de version Games n’est figé par cette étude. Le corpus Games doit être celui réellement fourni au démarrage de la session ; ne pas reconstruire ou supposer une baseline à partir d’un ancien historique PGR.
|
||
|
||
L’absence d’un corpus Games autoritaire empêche de commencer l’adoption réelle, mais n’autorise pas à inventer ses décisions, son architecture ou son applicabilité technologique.
|
||
|
||
## Méthode attendue pour l’adoption Games
|
||
|
||
`0.1.6` doit commencer par un audit, pas par une réécriture globale.
|
||
|
||
Pour chaque règle, profil, skeleton, template ou validation PGR potentiellement applicable, la session doit décider explicitement. La classification canonique est `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A` :
|
||
|
||
```text
|
||
ADOPT intégré dans la baseline locale Games
|
||
KEEP-LOCAL décision Games conservée comme autorité locale
|
||
OVERRIDE contradiction réelle avec un MUST PGR applicable, documentée et bornée
|
||
DEFER applicable potentiellement mais non justifié dans le scope courant
|
||
N/A non applicable au corpus Games observé
|
||
```
|
||
|
||
Un simple écart à un `SHOULD / SHOULD NOT` ne constitue pas à lui seul un `OVERRIDE`.
|
||
|
||
L’adoption doit préserver les décisions produit et architectures locales qui ne relèvent pas de PGR. Les anciens POCs, technologies historiques ou artefacts expérimentaux ne doivent pas devenir des surfaces applicables uniquement parce qu’ils existent dans l’historique : leur applicabilité doit être démontrée par la baseline Games fournie.
|
||
|
||
## Autorité après adoption
|
||
|
||
`0.1.6` doit exercer le contrat stabilisé en `0.1.5` : une fois l’adoption matérialisée, les règles, plans, architecture, histories et autres owners locaux de Games deviennent l’autorité des sessions/releases suivantes du projet.
|
||
|
||
PGR ne devient pas un upstream documentaire à suivre. Un futur réalignement Games/PGR doit rester une opération explicitement décidée à partir d’un snapshot PGR précis.
|
||
|
||
## Trajectoire conservée
|
||
|
||
Aucune dépendance nouvelle ne justifie un changement d’ordre :
|
||
|
||
```text
|
||
0.1.5 sémantique normative + autonomie + frontière PGR/Knowledge
|
||
0.1.6 adoption sasedev-games
|
||
0.1.7 adoption khadhroony-solana-project
|
||
0.1.8 audits Rust/Clippy read-only
|
||
```
|
||
|
||
`0.1.7` reste séparée afin que l’adoption KSP soit instruite contre son propre corpus et son propre scope applicable.
|
||
|
||
`0.1.8` reste postérieure aux deux adoptions : les audits Rust/Clippy statiques doivent être dérivés de besoins effectivement éprouvés et ne pas être inventés avant les retours d’adoption.
|
||
|
||
Aucun `0.1.9` n’est réservé par cette revue.
|
||
|
||
## Hors scope de la présente RC
|
||
|
||
Cette étude ne commence pas l’adoption Games et ne modifie aucune règle Games.
|
||
|
||
Elle ne commence ni l’adoption KSP, ni les audits Rust/Clippy `0.1.8`, ni une migration de contenu vers SaseDev Knowledge.
|
||
|
||
Elle ne transforme pas PGR en dépendance des projets adoptés et ne crée aucun mécanisme automatique de suivi de la dernière version PGR.
|