pgr/docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md

Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge

Objet

0.1.5 stabilise trois contrats transversaux décidés par la revue d’horizon 0.1.4 avant toute nouvelle adoption réelle : la force de MUST / SHOULD / MAY, l’autonomie d’un projet après instanciation ou adoption, et la frontière entre le référentiel normatif PGR et les contenus pratiques candidats à SaseDev Knowledge.

La release ne doit ni réécrire mécaniquement toutes les recommandations existantes, ni traiter PGR comme un upstream vivant des projets déjà adoptés, ni déplacer du contenu vers Knowledge sans corpus de destination autoritaire.

Baseline et preuves d’ouverture

La baseline autoritaire est l’archive du tag Gitea v0.1.4.

archive canonique     pgr-v0.1.4.zip
archive reçue         pgr-v0.1.4(1).zip
SHA-256               9f85ac16a5ad9fd788df51883b6ebf592602c5189d94e338a86edab2288b8f77
CRC                    PASS
VERSION                0.1.4
racine ZIP             pgr/
fichiers               310
répertoires            44
symlink                 0
.git dans l'archive     absent — attendu pour une archive de tag

La publication post-tag associée a été clôturée PASS sous pgr-0.1.4-publish.001-report.md. Sa preuve établit le SHA canonique ci-dessus, la publication de la stable 0.1.4 et l’autorisation du handoff vers prompts/011-V0_1_5_START_PROMPT.md.

Le replay indépendant de la baseline avant préparation de alpha.1 confirme :

tests Python                     55/55 PASS
audit hygiène texte              309 fichiers PASS
audit headers Markdown           282 fichiers PASS
audit tables Markdown            11 tables / 282 fichiers PASS
audit liens Markdown             357 liens locaux / 282 fichiers PASS
JSON                             2 fichiers parsés
TOML                             5 fichiers parsés
deltas historiques              103
histories historiques           103
appariement delta/history        exact pour 0.0.1 à 0.1.4

La séquence 0.1.4 est conservée telle que publiée :

alpha.1          PASS
alpha.2          FAIL
alpha.2.fix.1    PASS
alpha.3          PASS
beta.1           PASS
rc.1             PASS
rel.1            PASS

Le FAIL de alpha.2 et son correctif restent des faits historiques ; 0.1.5 ne les réécrit pas.

Sources de cadrage

La release part au minimum de :

• RULES.md ;
• docs/rules/200-GOVERNANCE.md ;
• docs/rules/210-WORKFLOW.md ;
• docs/rules/220-SKELETONS.md ;
• docs/rules/230-ADOPTION.md ;
• docs/rules/400-VALIDATION.md ;
• docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md ;
• docs/templates/003-NEW_SESSION_PROMPT.md ;
• docs/templates/007-EXISTING_PROJECT_ADOPTION.md ;
• docs/studies/004-V0_1_4_HORIZON_REVIEW.md ;
• prompts/011-V0_1_5_START_PROMPT.md.

Les owners et artefacts adjacents ne sont modifiés que lorsqu’une ambiguïté transversale réelle les concerne.

Contrats cibles

Force normative

La release doit rendre non ambigu le contrat suivant :

MUST / MUST NOT       obligation ou interdiction normative
SHOULD / SHOULD NOT   forte recommandation non obligatoire
MAY                   possibilité neutre

Un écart à un SHOULD ou SHOULD NOT :

• ne constitue pas à lui seul une non-conformité ;
• ne fait pas échouer à lui seul une gate ;
• n’exige pas automatiquement un OVERRIDE ;
• peut être documenté lorsque la raison apporte une valeur durable de maintenance, architecture ou reprise.

Une contradiction avec un MUST réellement applicable reste distincte et continue d’exiger le traitement prévu par l’owner concerné, l’exception ou l’override autorisé.

Autonomie après instanciation ou adoption

Le cycle cible est :

snapshot PGR explicitement choisi
        ↓
instanciation / adoption / adaptation
        ↓
baseline locale du projet
        ↓
autorité locale pour les sessions et releases suivantes

Après établissement de la baseline locale, le projet destinataire ne recherche pas automatiquement une version PGR plus récente et ne traite pas PGR comme une dépendance documentaire implicite. Un réalignement futur reste possible uniquement comme opération explicite et bornée, à partir d’un nouveau snapshot PGR choisi et d’une nouvelle comparaison des écarts.

Frontière PGR / SaseDev Knowledge

PGR reste auto-suffisant pour comprendre et appliquer ses exigences.

PGR conserve notamment les contrats normatifs et de gouvernance, les owners, les skeleton specifications minimales, les templates nécessaires à un contrat réutilisable et les validations directement liées aux règles.

Les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation sont des candidats à Knowledge. Cette classification n’autorise aucun déplacement automatique pendant 0.1.5 et ne crée aucune dépendance de PGR vers Knowledge.

Inventaire transversal alpha.1

L’inventaire a recherché les formulations SHOULD / SHOULD NOT, les contrats d’override, l’autonomie post-adoption et les termes qui confondent spécification normative et recette pratique.

Sur le corpus normatif/documentaire courant analysé, 29 fichiers contiennent au moins un SHOULD ou SHOULD NOT, pour 242 occurrences textuelles brutes. Ce volume interdit une conversion mécanique : la majorité de ces recommandations sont légitimes et doivent seulement hériter d’une sémantique globale claire.

Ambiguïtés normatives confirmées

RULES.md décrit actuellement SHOULD / SHOULD NOT comme un comportement attendu avec dérogation lorsque l’alternative est « mieux adaptée et justifiée ». Cette formulation peut rendre la justification obligatoire et doit devenir l’owner primaire de la clarification.

RULES.md exige aussi un override pour une contradiction intentionnelle. Le texte doit distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.

docs/rules/400-VALIDATION.md ne précise pas encore qu’un écart à un SHOULD ne peut pas, à lui seul, faire échouer une gate.

docs/rules/230-ADOPTION.md définit OVERRIDE comme le remplacement ou raffinement d’une règle PGR applicable. Sans clarification de la force normative, cette définition peut pousser à créer un override pour une simple recommandation non suivie.

docs/rules/500-LANGUAGES.md et docs/rules/700-FRAMEWORKS.md utilisent des formulations d’exception/override qui doivent être relues après stabilisation de la sémantique globale afin de ne pas renforcer accidentellement un SHOULD.

Des cas concrets confirment que l’ambiguïté n’est pas théorique :

• docs/rules/530-TYPESCRIPT.md associe une recommandation à une incompatibilité documentée ;
• docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md demande actuellement, pour la politique de lockfile, soit l’adoption de la recommandation soit un OVERRIDE ;
• docs/skeletons/003-WEB_FRONTEND.md exige une justification lorsqu’une nouvelle baseline durable n’adopte pas la recommandation TypeScript ;
• docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md impose une décision locale ou un OVERRIDE avec justification pour une politique de lockfile différente.

Ces cas doivent être corrigés de façon ciblée après la définition centrale, sans affaiblir les MUST réellement applicables.

Ambiguïté de trajectoire confirmée

docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md conserve une référence vivante à « l’adoption 0.1.5 de Games ». La revue d’horizon 0.1.4 a déplacé cette adoption en 0.1.6. Cette référence est donc obsolète et doit être corrigée comme cohérence documentaire vivante, sans modifier les plans, études, prompts ou histories qui décrivent correctement l’ancien horizon dans leur contexte historique.

Autonomie — acquis à conserver

Plusieurs contrats sont déjà compatibles avec la cible :

• docs/objectives/001-PROJECT_OBJECTIVES.md interdit de créer une dépendance vers PGR après instanciation et exclut la maintenance automatique des projets créés ;
• docs/architecture/002-GOVERNANCE_ARCHITECTURE.md dit déjà que le projet possède sa copie et qu’une évolution ultérieure de PGR ne le modifie pas automatiquement ;
• docs/rules/220-SKELETONS.md attribue les fichiers, décisions et règles locales au projet après instanciation ;
• docs/templates/003-NEW_SESSION_PROMPT.md repart de la baseline stable du projet lui-même et ne reconstruit pas une source absente ;
• docs/templates/007-EXISTING_PROJECT_ADOPTION.md conclut déjà sur un projet autonome.

Ces acquis doivent être consolidés plutôt que réécrits en bloc.

Autonomie — gaps à fermer

RULES.md interdit seulement la dépendance runtime/build et doit expliciter l’absence d’upstream documentaire PGR implicite.

docs/rules/230-ADOPTION.md doit établir clairement que la baseline locale devient l’autorité des sessions/releases suivantes et qu’un réalignement PGR ultérieur est une opération explicite.

docs/rules/220-SKELETONS.md, docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md et docs/templates/007-EXISTING_PROJECT_ADOPTION.md doivent propager ce contrat au point d’instanciation/adoption. Une éventuelle dépendance documentaire externe explicitement choisie par un projet reste sa décision locale ; elle ne transforme pas PGR en upstream implicite.

docs/rules/210-WORKFLOW.md et docs/templates/003-NEW_SESSION_PROMPT.md sont, à ce stade, classés KEEP sauf contradiction découverte pendant la réconciliation : leur notion de baseline autoritaire est déjà celle du projet courant.

Frontière Knowledge — ambiguïtés confirmées

docs/objectives/001-PROJECT_OBJECTIVES.md et docs/architecture/002-GOVERNANCE_ARCHITECTURE.md qualifient encore un skeleton de « recette Markdown ». Or 0.1.5 réserve précisément les recettes pratiques à la famille de contenus candidats à Knowledge. Le terme doit être remplacé par une formulation de type « spécification Markdown composable » afin de préserver la nature normative/structurelle du skeleton.

docs/rules/300-DOCUMENTATION.md est l’owner naturel pour formaliser la frontière documentaire sans créer un owner Knowledge artificiel. PGR ne doit pas créer une règle ou une collection dédiée uniquement parce que Knowledge existe comme produit séparé.

Owners proposés

Les modifications ne sont engagées qu’après validation de cet inventaire.

sémantique primaire
  RULES.md                                      MODIFY
  docs/rules/230-ADOPTION.md                    MODIFY
  docs/rules/400-VALIDATION.md                  MODIFY

réconciliation ciblée des effets SHOULD
  docs/rules/500-LANGUAGES.md                   REVIEW / MODIFY IF NEEDED
  docs/rules/530-TYPESCRIPT.md                  MODIFY
  docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md MODIFY
  docs/rules/700-FRAMEWORKS.md                  REVIEW / MODIFY IF NEEDED
  docs/skeletons/003-WEB_FRONTEND.md            MODIFY
  docs/templates/008-WEB_TYPESCRIPT_PACKAGE.md  MODIFY

autonomie
  RULES.md                                      MODIFY
  docs/rules/220-SKELETONS.md                   MODIFY
  docs/rules/230-ADOPTION.md                    MODIFY
  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY
  docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY
  docs/rules/210-WORKFLOW.md                    KEEP / REVIEW
  docs/templates/003-NEW_SESSION_PROMPT.md      KEEP / REVIEW

frontière PGR / Knowledge
  docs/objectives/001-PROJECT_OBJECTIVES.md     MODIFY
  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY
  docs/rules/300-DOCUMENTATION.md               MODIFY

Aucun nouveau owner Knowledge n’est prévu par défaut.

Trajectoire de release

alpha.1 — intake, audit transversal et plan

• vérifier la baseline stable 0.1.4 et sa chaîne delta/history ;
• relire le handoff 011 et la revue d’horizon 004 ;
• inventorier les ambiguïtés normatives, d’autonomie et de frontière Knowledge ;
• proposer les owners exacts ;
• ne modifier aucune règle normative.

alpha.2 — sémantique normative et conséquences de gate/adoption

• stabiliser MUST / SHOULD / MAY dans l’owner primaire ;
• aligner 230-ADOPTION.md et 400-VALIDATION.md ;
• corriger les cas concrets où une recommandation est transformée en justification/override obligatoire ;
• corriger la référence vivante obsolète à l’adoption Games 0.1.5 ;
• conserver les obligations réelles et les histories inchangées.

alpha.3 — autonomie locale et réalignement volontaire

• expliciter la baseline locale comme autorité après instanciation/adoption ;
• interdire la recherche automatique de « la dernière PGR » dans le contrat d’adoption ;
• définir le réalignement futur comme scope explicite fondé sur un snapshot choisi ;
• propager le contrat aux skeleton/patterns concernés sans réécriture des documents déjà corrects.

alpha.4 — frontière PGR / SaseDev Knowledge

• clarifier la taxonomie normative/pratique ;
• remplacer les formulations « recette Markdown » qui brouillent la nature des skeleton specifications ;
• maintenir PGR auto-suffisant ;
• ne déplacer aucun contenu vers Knowledge sans destination autoritaire fournie.

beta.1 — réconciliation transversale

• rescanner toutes les formulations SHOULD / SHOULD NOT pour détecter les renforcements accidentels restants ;
• vérifier les références à l’autonomie, aux snapshots et aux overrides ;
• rechercher les références vivantes devenues obsolètes après la revue d’horizon ;
• vérifier que Games 0.1.6, KSP 0.1.7 et les audits Rust 0.1.8 n’ont pas été commencés ;
• exécuter les validations PGR complètes et proportionnées.

rc.1 — freeze et handoff

• figer les contrats stabilisés ;
• mettre à jour la présentation stable/candidate et la roadmap selon l’état réellement atteint ;
• préparer le prompt de reprise suivant uniquement si la trajectoire vers 0.1.6 reste valide ;
• effectuer une revue d’horizon limitée aux dépendances réellement révélées par 0.1.5.

rel.1 — promotion stable

• promouvoir la RC validée sans nouveau scope fonctionnel ;
• produire le history réel de clôture ;
• préparer la publication/tag stable puis sa vérification post-tag selon le workflow PGR.

Hors scope maintenu

0.1.5 ne commence pas :

• l’adoption réelle de sasedev-games, réservée à 0.1.6 ;
• l’adoption réelle de khadhroony-solana-project, réservée à 0.1.7 ;
• les audits Rust/Clippy read-only, réservés à 0.1.8 ;
• une réouverture du domaine Tauri sans défaut transversal démontré ;
• une migration physique vers SaseDev Knowledge ;
• une conversion globale de tous les SHOULD en MUST ou MAY.

Gate de planification

alpha.1 est prête à validation opérateur lorsque :

• la baseline 0.1.4 a été rejouée proprement ;
• l’historique 0.1.4 reste intact, y compris alpha.2 FAIL puis alpha.2.fix.1 PASS ;
• les ambiguïtés ci-dessus sont traçables à des owners existants ;
• aucune règle normative n’est modifiée par la tranche ;
• le plan conserve une séparation explicite entre sémantique, autonomie et frontière Knowledge ;
• les scopes 0.1.6, 0.1.7 et 0.1.8 restent réservés.