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 observées en alpha.1

Avant alpha.2, RULES.md décrivait SHOULD / SHOULD NOT comme un comportement attendu avec dérogation lorsque l’alternative était « mieux adaptée et justifiée ». Cette formulation pouvait rendre la justification obligatoire et a désigné RULES.md comme owner primaire de la clarification.

Avant alpha.2, RULES.md exigeait aussi un override pour toute contradiction intentionnelle sans distinguer explicitement une contradiction à une obligation d’un simple choix différent d’une recommandation.

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

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

docs/rules/500-LANGUAGES.md et docs/rules/700-FRAMEWORKS.md utilisaient des formulations d’exception/override pouvant renforcer accidentellement un SHOULD ; alpha.2 les a donc inclus dans la réconciliation ciblée.

Les cas concrets observés pendant alpha.1 confirmaient que l’ambiguïté n’était pas théorique :

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

Ces cas ont été retenus pour une correction ciblée en alpha.2, sans affaiblir les MUST réellement applicables.

Ambiguïté de trajectoire observée en alpha.1

Avant alpha.2, docs/rules/540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md conservait une référence vivante à « l’adoption 0.1.5 de Games ». La revue d’horizon 0.1.4 avait déplacé cette adoption en 0.1.6. alpha.2 corrige cette référence 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 issus de l'inventaire

L'inventaire alpha.1 a fixé les owners ci-dessous. Leur modification reste répartie par tranche afin de ne pas mélanger sémantique normative, autonomie et frontière Knowledge.

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

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

autonomie
  RULES.md                                      MODIFY alpha.3
  docs/rules/220-SKELETONS.md                   MODIFY alpha.3
  docs/rules/230-ADOPTION.md                    MODIFY alpha.3
  docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md MODIFY alpha.3
  docs/templates/007-EXISTING_PROJECT_ADOPTION.md MODIFY alpha.3
  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 alpha.4
  docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY alpha.4
  docs/rules/300-DOCUMENTATION.md               MODIFY alpha.4

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

Progression acquise avant alpha.2

La première gate alpha.1 a acquis les tests et audits principaux mais n'a pas exécuté toutes les assertions contractuelles prévues par son delta. Son history conserve donc le résultat réel PARTIAL.

alpha.1.fix.1 a été limité à l'acquisition des preuves manquantes : trajectoire ROADMAP, frontière delta/history, assertions du prompt 011, assertions du présent plan et audits documentaires. Cette récupération est PASS et n'a modifié aucun owner normatif.

La tranche alpha.2 peut donc appliquer la sémantique centrale sans réécrire les 242 occurrences de recommandations. Les modifications sont bornées aux owners et artefacts où l'inventaire a démontré un renforcement accidentel ou une référence vivante obsolète : RULES.md, 230, 400, 500, 530, 540, 700, le skeleton Web 003 et le guide 008.

Décisions de mise en œuvre alpha.2 :

• SHOULD / SHOULD NOT devient explicitement une forte recommandation non obligatoire ;
• un écart à cette recommandation ne crée ni non-conformité, ni FAIL de gate, ni OVERRIDE automatique ;
• un projet MAY documenter la raison d'un écart lorsqu'elle apporte une valeur durable ;
• les contradictions avec des obligations MUST / MUST NOT restent soumises aux contrats d'exception/override applicables ;
• la référence vivante à l'adoption Games est corrigée de 0.1.5 vers 0.1.6 ;
• l'autonomie post-adoption reste réservée à alpha.3 et la frontière Knowledge à alpha.4.

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 — historique

alpha.1 était 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.