pgr/docs/studies/004-V0_1_4_HORIZON_REVIEW.md

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 :

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é :

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 :

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 :

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 :

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.