# 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`. ```text 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 : ```text 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 : ```text 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 : ```text 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 : ```text 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. ```text 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 `beta.1` 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` a ensuite appliqué la sémantique centrale sans réécrire les `242` occurrences de recommandations. Les modifications ont été bornées aux owners et artefacts où l'inventaire avait 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`. Sa gate opérateur du `2026-10-01` est `PASS` avec `55/55` tests et les audits documentaires propres. Décisions acquises en `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 est mise en œuvre par `alpha.3` ; la frontière Knowledge reste réservée à `alpha.4`. Décisions de mise en œuvre `alpha.3` : - après instanciation ou adoption, la baseline locale et ses owners deviennent l'autorité des sessions/releases suivantes ; - PGR ne devient ni dépendance documentaire implicite ni upstream à suivre et aucun mécanisme ne doit rechercher automatiquement « la dernière version de PGR » ; - un réalignement futur exige une opération explicitement décidée et bornée, fondée sur un snapshot PGR précis choisi par le projet ; - ce réalignement compare le snapshot choisi à la baseline locale, reclassifie les écarts utiles et préserve les histories au lieu de mettre à jour silencieusement la gouvernance ; - `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : leur contrat de reprise depuis la baseline autoritaire du projet est déjà compatible ; - la frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`. La gate opérateur de `alpha.3` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres et le scope Git attendu. Le contrat d'autonomie locale est donc acquis avant ouverture de `alpha.4`. Décisions de mise en œuvre `alpha.4` : - remplacer les formulations « recette Markdown » des skeletons par « spécification Markdown composable » afin de ne pas confondre contrat structurel PGR et recette pratique ; - formaliser dans `300-DOCUMENTATION.md` une frontière documentaire où PGR possède les éléments nécessaires à ses contrats normatifs et où les howtos détaillés, recettes, snippets, exemples, dépannage, comparatifs et variantes MAY vivre dans une base de connaissances séparée ; - mentionner SaseDev Knowledge uniquement comme destination pratique possible, jamais comme owner normatif ni dépendance requise ; - imposer l'auto-suffisance de PGR : aucun howto/snippet externe ne peut être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR ; - conserver toute migration physique hors scope de `0.1.5` tant qu'une destination Knowledge autoritaire n'est pas explicitement fournie et vérifiée ; - ne créer aucun nouvel owner Knowledge et ne modifier aucun history antérieur. La gate opérateur de `alpha.4` du `2026-10-01` est `PASS` avec `55/55` tests, les audits documentaires propres, les owners hors scope inchangés et le scope Git attendu. La frontière PGR / Knowledge est donc acquise avant ouverture de `beta.1`. ## Réconciliation transversale préparée en `beta.1` Le rescan préparatoire de la baseline post-`alpha.4` n'a démontré aucun nouveau défaut normatif exigeant une modification d'owner. Les formulations `SHOULD / SHOULD NOT` des owners vivants ont été relues avec attention lorsqu'un `MUST`, une justification ou une contrainte conditionnelle apparaissait dans le même contexte. Les cas conservés portent des responsabilités distinctes et ne transforment pas le simple écart à la recommandation en non-conformité : outputs/caches générés à ignorer lorsqu'ils restent dans l'arbre, ouverture réseau/CORS à borner, identité Android à rendre explicite, dépendance Sass interne à garder visible/révisable et surface de sécurité Tauri à décider explicitement. La réconciliation confirme également : - `RULES.md`, `230-ADOPTION.md` et `400-VALIDATION.md` portent une sémantique cohérente : un écart à `SHOULD / SHOULD NOT` ne crée à lui seul ni `FAIL`, ni `OVERRIDE`, ni justification obligatoire ; - `220-SKELETONS.md`, `230-ADOPTION.md`, `001-PROJECT_GOVERNANCE_FOUNDATION.md` et `007-EXISTING_PROJECT_ADOPTION.md` conservent la baseline locale comme autorité et le réalignement PGR comme opération explicite sur snapshot choisi ; - `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent `KEEP` : aucune recherche automatique de version PGR plus récente n'y est introduite ; - `001-PROJECT_OBJECTIVES.md`, `002-GOVERNANCE_ARCHITECTURE.md` et `300-DOCUMENTATION.md` maintiennent PGR auto-suffisant et Knowledge strictement complémentaire ; - la référence vivante Games dans `540-JAVASCRIPT_PACKAGE_ECOSYSTEM.md` pointe bien vers `0.1.6` ; les anciennes mentions `0.1.5` conservées dans des études/index historiques restent des descriptions de l'horizon de leur époque et ne sont pas réécrites ; - les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` restent réservés et aucun `0.1.9` n'est créé. Décision `beta.1` : **KEEP des owners normatifs acquis**. La tranche documente et valide la réconciliation ; elle n'ajoute aucun owner, ne modifie aucune règle normative et ne commence aucun scope futur. La gate opérateur de `beta.1` du `2026-10-01` est `PASS` avec `55/55` tests, l'audit d'hygiène texte propre sur `321` fichiers, les audits Markdown propres et le scope Git attendu. La phase de réconciliation est donc acquise avant ouverture de `rc.1`. ## Freeze et revue d’horizon préparés en `rc.1` `rc.1` gèle les owners normatifs acquis : aucune règle, skeleton, template ou validation stabilisés pendant `alpha.2` à `alpha.4` n'est réouvert sans défaut démontré. La revue d'horizon limitée matérialisée dans `docs/studies/005-V0_1_5_HORIZON_REVIEW.md` conclut qu'aucun nouveau prérequis transversal ne doit précéder l'adoption Games. La trajectoire reste : ```text 0.1.6 adoption sasedev-games 0.1.7 adoption khadhroony-solana-project 0.1.8 audits Rust/Clippy read-only 0.1.9 NOT RESERVED ``` Le prompt `012-V0_1_6_START_PROMPT.md` prépare donc une reprise `0.1.6-alpha.1` à partir d'une future stable PGR `v0.1.5` réellement publiée et d'une archive Games récente explicitement autoritaire. Il impose un intake/cartographie avant toute migration et conserve le contrat d'autonomie locale après adoption. La RC ne commence ni l'adoption Games, ni KSP, ni les audits `0.1.8`. ## 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.