0.1.5-alpha.1
This commit is contained in:
290
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
290
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
Normal file
@@ -0,0 +1,290 @@
|
||||
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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 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.
|
||||
|
||||
```text
|
||||
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.
|
||||
Reference in New Issue
Block a user