# Revue d’horizon 0.1.4 — sémantique normative, autonomie et frontière Knowledge ## Objet Cette étude clôt la revue d’horizon explicitement requise par le plan `0.1.4`. Elle décide si les adoptions Games/KSP peuvent suivre immédiatement la release Tauri ou si un contrat transversal doit être stabilisé auparavant. Le déclencheur provient d’un usage réel de PGR pour initialiser SaseDev Knowledge. Trois ambiguïtés ont été observées sans remettre en cause le travail Tauri de `0.1.4` : force réelle de `SHOULD`, relation d’un projet avec PGR après adoption, et emplacement futur des howtos/recettes/snippets lorsque Knowledge devient suffisamment fonctionnel. ## Sources PGR examinées Les owners actuels pertinents sont : ```text RULES.md rules/200-GOVERNANCE.md rules/210-WORKFLOW.md rules/220-SKELETONS.md rules/230-ADOPTION.md rules/400-VALIDATION.md skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md templates/003-NEW_SESSION_PROMPT.md templates/007-EXISTING_PROJECT_ADOPTION.md ``` Ces documents contiennent déjà des éléments compatibles avec l’intention recherchée, notamment l’autonomie du projet et la copie locale des règles applicables. Le défaut est une insuffisance de précision et de propagation du contrat, pas l’absence totale du principe. ## 1. Force normative de `SHOULD` La formulation actuelle décrit `SHOULD / SHOULD NOT` comme un comportement attendu par défaut avec dérogation possible si une autre solution est mieux adaptée et justifiée. Cette rédaction peut être interprétée comme une obligation conditionnelle. La prochaine clarification doit établir sans ambiguïté : ```text MUST / MUST NOT exigence normative ; écart = non-conformité sauf exception/override autorisé SHOULD / SHOULD NOT forte recommandation ; préférence par défaut mais non obligatoire MAY possibilité neutre ; aucune préférence implicite ``` Un écart à un `SHOULD` : - MUST NOT devenir à lui seul une non-conformité ; - MUST NOT faire échouer à lui seul une gate ; - MUST NOT exiger automatiquement un `OVERRIDE` ; - MAY être documenté lorsqu’il est significatif pour la maintenance, l’architecture ou la reprise future. La distinction est suffisamment structurante pour être stabilisée avant toute nouvelle adoption réelle. ## 2. Autonomie après instanciation ou adoption PGR doit être un référentiel d’initialisation, de comparaison et de réalignement volontaire, pas un upstream vivant implicitement suivi par chaque projet. Le contrat cible est : ```text snapshot PGR choisi ↓ instanciation / adoption / adaptation ↓ baseline locale du projet ↓ règles locales = autorité des sessions/releases suivantes ``` Après établissement de la baseline locale : - le projet MUST fonctionner sans rechercher une version PGR plus récente ; - le projet MUST NOT considérer PGR comme une dépendance documentaire implicite à mettre à jour à chaque session ; - ses règles, architecture, plans, templates et validations locales deviennent l’autorité de son évolution ; - la version PGR utilisée MAY être conservée comme provenance historique ; - un réalignement futur avec PGR est une opération explicite, bornée et volontaire, utilisant un snapshot PGR choisi et une nouvelle comparaison des écarts. Ce point doit être propagé dans les contrats de reprise et d’adoption, sinon l’autonomie déjà annoncée dans les règles reste trop facile à contourner involontairement. ## 3. Frontière PGR / SaseDev Knowledge PGR et Knowledge doivent rester utilisables indépendamment. La frontière cible est : ```text PGR contrats normatifs et de gouvernance owners et règles applicables skeleton specifications minimales templates nécessaires à un contrat réutilisable contrats de validation/audit directement liés à ces règles SaseDev Knowledge howtos détaillés recettes et procédures pratiques snippets exemples d’intégration dépannage et variantes d’implémentation explications pédagogiques et comparatifs pratiques ``` PGR MUST rester auto-suffisant pour comprendre et appliquer une règle. Une règle PGR ne doit pas dépendre d’un howto Knowledge pour déterminer ce qu’elle exige. La future disponibilité de Knowledge MAY justifier l’épuration de contenus pratiques devenus redondants dans PGR, mais aucune extraction ne doit être effectuée uniquement pour anticiper cette disponibilité. Le déplacement physique exige un corpus Knowledge suffisamment fonctionnel et explicitement fourni comme source autoritaire de destination. ## Décision d’horizon Les trois sujets sont transversaux à toutes les adoptions futures. Les reporter après Games/KSP ferait courir le risque de propager une sémantique ambiguë ou une liaison implicite à PGR dans les projets précisément utilisés pour éprouver le modèle d’adoption. Décision : **une release de gouvernance/autonomie doit précéder les adoptions Games/KSP**. La trajectoire devient : ```text 0.1.4 Tauri et skeleton contrôlé 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 ``` Aucun numéro au-delà de `0.1.8` n’est réservé par cette étude. ## Scope attendu de 0.1.5 `0.1.5` devra au minimum : 1. clarifier la force de `MUST / SHOULD / MAY` et les conséquences de gate ; 2. rendre explicite l’autorité locale après instanciation/adoption dans `230-ADOPTION`, les skeletons et les patterns de reprise concernés ; 3. définir un mécanisme de réalignement PGR volontaire sans mise à jour automatique ; 4. formaliser la frontière PGR / SaseDev Knowledge et classifier les contenus qui doivent rester normatifs ou devenir candidats à un futur transfert ; 5. vérifier que PGR reste autonome sans dépendance à Knowledge ; 6. ne pas commencer les adoptions Games/KSP ni les audits Rust réservés aux releases suivantes. Une archive SaseDev Knowledge MAY être utilisée comme corpus d’observation si elle est explicitement fournie, mais `0.1.5` ne doit pas dépendre de son existence pour corriger les contrats PGR. ## Hors scope de la présente RC La présente étude ne modifie pas encore `RULES.md`, `230-ADOPTION.md`, `400-VALIDATION.md`, les skeletons de fondation ou les templates de reprise. Ces modifications appartiennent à `0.1.5` afin que `0.1.4-rc.1` reste une phase de freeze Tauri et de handoff. Elle ne migre ni Games ni KSP et ne déplace aucun contenu vers SaseDev Knowledge.