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

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.

Gate rc.1 en échec documentaire et correctif rc.1.fix.1

La gate opérateur de rc.1 du 2026-10-01 conserve les 55/55 tests PASS, les audits documentaires propres, le freeze des owners et le scope Git attendu, mais trois assertions textuelles exactes du delta n'ont produit aucune correspondance. Le history history/0.1.5/rc.1.md enregistre donc le résultat réel FAIL.

Le correctif rc.1.fix.1 est borné à la présentation documentaire :

• employer dans CHANGELOG.md la formule canonique forte recommandation non obligatoire attendue par la gate ;
• rendre explicite dans la revue d'horizon que aucun numéro de version Games n’est figé ;
• matérialiser la classification canonique ADOPT / KEEP-LOCAL / OVERRIDE / DEFER / N/A dans cette même étude ;
• ne modifier aucun owner normatif, skeleton, template, contrat de validation, roadmap, handoff 012 ou history antérieur.

rel.1 reste bloqué tant que rc.1.fix.1 n’est pas validé PASS.

Gate rc.1.fix.1 acquise et promotion stable

La gate opérateur de rc.1.fix.1 du 2026-10-01 est PASS : les trois assertions documentaires qui avaient fait échouer rc.1 correspondent désormais, les 55/55 tests passent, les audits d'hygiène/Markdown sont propres et le scope Git est exactement celui du correctif.

Le history history/0.1.5/rc.1.fix.1.md conserve ce PASS sans modifier le FAIL historique de rc.1.

rel.1 peut donc promouvoir mécaniquement la candidate vers la stable 0.1.5. Cette promotion :

• fixe VERSION à 0.1.5 ;
• retire le marqueur candidate du changelog ;
• marque 0.1.5 terminé dans la roadmap ;
• présente README.md, l'index documentaire et le présent plan comme état stable/historique ;
• conserve 0.1.6 Games, 0.1.7 KSP et 0.1.8 audits comme trajectoire engagée ;
• ne commence aucun scope 0.1.6 et ne réserve aucun 0.1.9.

Après un history rel.1 PASS, le commit produit MUST être 0.1.5 sans suffixe rel.1, puis le tag annoté v0.1.5 et son archive doivent être publiés et vérifiés indépendamment. Le rapport pgr-0.1.5-publish.001-report.md ne peut être produit qu'après cette publication réelle.

Le plan devient historique avec la stable 0.1.5.

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.