0.1.5-alpha.2
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
|
||||
|
||||
@@ -126,30 +126,30 @@ L’inventaire a recherché les formulations `SHOULD / SHOULD NOT`, les contrats
|
||||
|
||||
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
|
||||
### Ambiguïtés normatives observées en `alpha.1`
|
||||
|
||||
`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.
|
||||
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.
|
||||
|
||||
`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.
|
||||
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.
|
||||
|
||||
`docs/rules/400-VALIDATION.md` ne précise pas encore qu’un écart à un `SHOULD` ne peut pas, à lui seul, faire échouer une gate.
|
||||
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.
|
||||
|
||||
`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.
|
||||
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` 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`.
|
||||
`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.
|
||||
|
||||
Des cas concrets confirment que l’ambiguïté n’est pas théorique :
|
||||
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` 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.
|
||||
- `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 doivent être corrigés de façon ciblée après la définition centrale, sans affaiblir les `MUST` réellement applicables.
|
||||
Ces cas ont été retenus pour une correction ciblée en `alpha.2`, sans affaiblir les `MUST` réellement applicables.
|
||||
|
||||
### Ambiguïté de trajectoire confirmée
|
||||
### Ambiguïté de trajectoire observée en `alpha.1`
|
||||
|
||||
`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.
|
||||
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
|
||||
|
||||
@@ -179,41 +179,58 @@ Ces acquis doivent être consolidés plutôt que réécrits en bloc.
|
||||
|
||||
`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
|
||||
## Owners issus de l'inventaire
|
||||
|
||||
Les modifications ne sont engagées qu’après validation de cet 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
|
||||
docs/rules/230-ADOPTION.md MODIFY
|
||||
docs/rules/400-VALIDATION.md MODIFY
|
||||
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 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
|
||||
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
|
||||
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
|
||||
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
|
||||
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md MODIFY
|
||||
docs/rules/300-DOCUMENTATION.md MODIFY
|
||||
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
|
||||
@@ -278,9 +295,9 @@ Aucun nouveau owner Knowledge n’est prévu par défaut.
|
||||
- une migration physique vers SaseDev Knowledge ;
|
||||
- une conversion globale de tous les `SHOULD` en `MUST` ou `MAY`.
|
||||
|
||||
## Gate de planification
|
||||
## Gate de planification `alpha.1` — historique
|
||||
|
||||
`alpha.1` est prête à validation opérateur lorsque :
|
||||
`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` ;
|
||||
|
||||
Reference in New Issue
Block a user