0.1.5-alpha.4
This commit is contained in:
@@ -1,5 +1,5 @@
|
||||
<!-- file: README.md -->
|
||||
<!-- version: 30 -->
|
||||
<!-- version: 31 -->
|
||||
|
||||
# Project Governance Rules
|
||||
|
||||
@@ -11,7 +11,7 @@ Le dépôt officiel est `https://git.sasedev.com/Sasedev/pgr`.
|
||||
|
||||
## Statut
|
||||
|
||||
La stable autoritaire courante reste `0.1.4`. Le travail `0.1.5-alpha.3` stabilise maintenant le second contrat transversal décidé par sa revue d’horizon : après instanciation ou adoption, la baseline locale du projet devient l’autorité de ses sessions et releases suivantes ; PGR n’est pas un upstream documentaire implicite et aucun mécanisme ne doit rechercher automatiquement « la dernière version de PGR ». Un réalignement futur reste possible uniquement comme opération explicite et bornée, à partir d’un snapshot PGR choisi puis comparé à la baseline locale. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4`, et les adoptions Games `0.1.6`, KSP `0.1.7` ainsi que les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
La stable autoritaire courante reste `0.1.4`. Le travail `0.1.5-alpha.4` stabilise maintenant le troisième contrat transversal décidé par sa revue d’horizon : PGR conserve localement tout ce qui est nécessaire pour comprendre et appliquer ses contrats normatifs, tandis que les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation peuvent devenir des contenus externes complémentaires, notamment dans SaseDev Knowledge lorsqu’une destination autoritaire existe. Cette frontière ne crée aucune dépendance de PGR vers Knowledge et ne déclenche aucun déplacement automatique de contenu. Les adoptions Games `0.1.6`, KSP `0.1.7` ainsi que les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
|
||||
La version courante est définie par [`VERSION`](VERSION). La release `0.0.1` établit la gouvernance normative et documentaire de PGR lui-même. La release `0.0.2` ajoute les premiers profils réutilisables Rust/Cargo, Java/Maven/Gradle et Android, ainsi que deux audits Markdown. La release `0.0.3` fournit les premiers modèles Rust/Cargo, deux audits de style Rust facultatifs, l'audit des headers Markdown et la spécification du message manuel de reprise. La release `0.0.4` définit le contrat transversal des skeleton specifications, ajoute une fondation composable de gouvernance locale et une première spécialisation Rust/Cargo workspace fondée sur les profils `500 + 510` et les cinq templates existants. La release `0.0.5` réconcilie PGR avec les baselines réelles de `khadhroony-solana-project` et `sasedev-games` : prompts versionnés, contrats documentaires locaux, lifecycle inter-release, profil Rust strict et audits monotâches, premier profil Tauri 2 et décision explicite de différer son skeleton complet jusqu'à matérialisation d'owners Web suffisants. La release `0.1.0` stabilise la première baseline réutilisable : adoption `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, skeletons/templates Rust/Cargo exercés par dry-run, clôture `rel.N`, handoff opérateur automatique et trajectoire `0.1.1` à `0.1.7` issue d'une revue d'horizon explicite. La release `0.1.1` stabilise la fondation frontend Web : owners indépendants TypeScript/package/Vite/CSS-Sass, déclarations de types externes conditionnelles, package manager neutre, validation frontend indépendante du host et skeleton Web composable, tout en conservant le skeleton Tauri en `DEFER` jusqu’à son réexamen `0.1.4`. La release `0.1.2` stabilise trois owners indépendants `520-JAVA`, `521-MAVEN` et `522-GRADLE`, clarifie JDK/source/bytecode et l'ownership Gradle, conserve Maven cohérent sans corpus artificiel et maintient les responsabilités Android dans `610-ANDROID.md` pour leur réévaluation distincte en `0.1.3`. La release `0.1.3` stabilise le profil Android générique : séparation des responsabilités SDK et identité applicative, contraintes natives conditionnelles, Android Lint explicite, niveaux de tests distincts, frontières APK/AAB et compatibilité 16 KB liée au code natif et au canal de distribution, sans imposer les versions ou ABI propres à Games. La release `0.1.4` stabilise le domaine Tauri : owner `710` recentré sur host/orchestration/ACL/plugins, skeleton `004` composable avec Rust/Cargo et Web, absence assumée de template technique générique ou de validation Tauri redondante, audit d’hygiène texte réutilisable et handoff vers `0.1.5` pour clarifier la sémantique normative et l’autonomie des projets.
|
||||
|
||||
|
||||
186
deltas/0.1.5/alpha.4.md
Normal file
186
deltas/0.1.5/alpha.4.md
Normal file
@@ -0,0 +1,186 @@
|
||||
<!-- file: deltas/0.1.5/alpha.4.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# Delta 0.1.5-alpha.4 — frontière PGR / SaseDev Knowledge
|
||||
|
||||
## Objet
|
||||
|
||||
Stabiliser la frontière durable entre le référentiel normatif PGR et les contenus pratiques qui peuvent vivre dans une base de connaissances séparée.
|
||||
|
||||
PGR doit rester auto-suffisant pour comprendre et appliquer ses règles. SaseDev Knowledge MAY accueillir des howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation, mais ne devient ni owner normatif de PGR ni dépendance nécessaire à son interprétation.
|
||||
|
||||
La tranche ne déplace aucun contenu vers Knowledge et ne crée aucun lien de dépendance vers un dépôt externe.
|
||||
|
||||
## Précondition
|
||||
|
||||
Le history `history/0.1.5/alpha.3.md` doit être présent avec statut `PASS` avant application de ce delta.
|
||||
|
||||
La séquence acquise reste conservée :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
```
|
||||
|
||||
Les histories précédents ne sont pas réécrits.
|
||||
|
||||
## Taxonomie stabilisée
|
||||
|
||||
PGR conserve les informations nécessaires à son propre contrat :
|
||||
|
||||
```text
|
||||
PGR
|
||||
règles et contrats de gouvernance
|
||||
objectifs et architecture
|
||||
owners normatifs
|
||||
skeleton specifications minimales
|
||||
templates nécessaires à un contrat réutilisable
|
||||
validations directement liées aux règles
|
||||
```
|
||||
|
||||
Les contenus suivants sont pratiques et MAY vivre dans une base de connaissances séparée :
|
||||
|
||||
```text
|
||||
contenus pratiques complémentaires
|
||||
howtos détaillés
|
||||
recettes pratiques
|
||||
snippets
|
||||
exemples d'intégration
|
||||
dépannage
|
||||
comparatifs
|
||||
variantes d'implémentation
|
||||
```
|
||||
|
||||
Cette classification est sémantique. Elle ne déclenche aucun déplacement automatique.
|
||||
|
||||
## Auto-suffisance
|
||||
|
||||
Une règle PGR doit rester interprétable depuis PGR lui-même. Un document pratique externe MAY aider à l'implémentation, mais MUST NOT être nécessaire pour déterminer la force, le scope ou les exigences d'une règle PGR.
|
||||
|
||||
SaseDev Knowledge est une destination possible pour les contenus pratiques, pas un upstream normatif. PGR MUST NOT dépendre de sa disponibilité.
|
||||
|
||||
Une extraction physique future exige une destination autoritaire explicitement fournie et vérifiée. `0.1.5-alpha.4` ne réalise aucune migration.
|
||||
|
||||
## Owners réconciliés
|
||||
|
||||
- `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` : remplace « recette Markdown » par « spécification Markdown composable », ajoute l'auto-suffisance PGR et sépare les contenus pratiques externes ;
|
||||
- `docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` : clarifie la nature du skeleton et formalise la frontière architecturale avec les contenus pratiques externes ;
|
||||
- `docs/rules/300-DOCUMENTATION.md` révision `5` : devient l'owner documentaire de la taxonomie normative/pratique, de l'auto-suffisance et du caractère non automatique d'une extraction future.
|
||||
|
||||
Aucun owner Knowledge supplémentaire n'est créé.
|
||||
|
||||
## Cohérence documentaire
|
||||
|
||||
- `README.md` présente `0.1.5-alpha.4` comme tranche active ;
|
||||
- `docs/000-README.md` présente les trois owners comme réconciliés en `alpha.4` ;
|
||||
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `4`, enregistre `alpha.3 PASS` et les décisions de mise en œuvre `alpha.4`.
|
||||
|
||||
`RULES.md`, `ROADMAP.md` et `CHANGELOG.md` restent inchangés. Les adoptions Games `0.1.6`, KSP `0.1.7` et les audits Rust/Clippy `0.1.8` restent hors scope.
|
||||
|
||||
## Gate opérateur
|
||||
|
||||
Après commit/push de `alpha.3` avec son history `PASS`, appliquer ce delta puis exécuter :
|
||||
|
||||
```bash
|
||||
cat VERSION
|
||||
|
||||
test -f history/0.1.5/alpha.3.md
|
||||
test -f deltas/0.1.5/alpha.4.md
|
||||
test ! -e history/0.1.5/alpha.4.md
|
||||
|
||||
grep -Fx '0.1.5-alpha.4' VERSION
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.md | grep -Fx 'PARTIAL'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.1.fix.1.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.2.md | grep -Fx 'PASS'
|
||||
grep -A2 '^## Statut$' history/0.1.5/alpha.3.md | grep -Fx 'PASS'
|
||||
|
||||
grep -Fx '<!-- version: 2 -->' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'spécifications Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
grep -F 'howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation vivent dans une base de connaissances séparée' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
! grep -F 'recettes Markdown composables' docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'Un skeleton est une spécification Markdown composable' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F '## Frontière avec les contenus pratiques externes' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F 'SaseDev Knowledge est une destination possible' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
grep -F "MUST NOT dépendre d'un dépôt Knowledge" docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
! grep -F 'Un skeleton est une recette Markdown' docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
|
||||
grep -Fx '<!-- version: 5 -->' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F '## Frontière normative et pratique' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'PGR MUST rester auto-suffisant' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F "MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR" docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'Classifier un contenu comme pratique ne crée pas une obligation de déplacement' docs/rules/300-DOCUMENTATION.md
|
||||
grep -F 'MUST NOT créer de dépendance de PGR vers SaseDev Knowledge' docs/rules/300-DOCUMENTATION.md
|
||||
|
||||
grep -Fx '<!-- version: 4 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'La gate opérateur de `alpha.3` du `2026-10-01` est `PASS`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'Décisions de mise en œuvre `alpha.4`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
grep -F 'ne créer aucun nouvel owner Knowledge' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
|
||||
grep -Fx '<!-- version: 16 -->' RULES.md
|
||||
grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
|
||||
grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
|
||||
|
||||
grep -F -- '- `( ) 0.1.6`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.7`' ROADMAP.md
|
||||
grep -F -- '- `( ) 0.1.8`' ROADMAP.md
|
||||
! grep -F -- '- `( ) 0.1.9`' ROADMAP.md
|
||||
|
||||
python3 -B -c "from pathlib import Path; expected={'0.0.1':12,'0.0.2':12,'0.0.3':10,'0.0.4':9,'0.0.5':19,'0.1.0':10,'0.1.1':11,'0.1.2':7,'0.1.3':6,'0.1.4':7}; assert all({p.name for p in Path('deltas',r).glob('*.md')} == {p.name for p in Path('history',r).glob('*.md')} and len(list(Path('deltas',r).glob('*.md'))) == n for r,n in expected.items()); assert {p.name for p in Path('deltas/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md','alpha.4.md'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md','alpha.3.md'}; print('0.1.5 alpha.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)')"
|
||||
|
||||
git diff --exit-code -- history/0.1.4
|
||||
git diff --exit-code -- RULES.md ROADMAP.md CHANGELOG.md docs/rules/210-WORKFLOW.md docs/rules/230-ADOPTION.md
|
||||
|
||||
python3 -B -m unittest discover -s tests -v
|
||||
|
||||
python3 -B scripts/audit_text_hygiene.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md VERSION \
|
||||
docs deltas history prompts scripts tests templates .gitignore .settings
|
||||
|
||||
python3 -B scripts/audit_markdown_headers.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
python3 -B scripts/audit_markdown_tables.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
python3 -B scripts/audit_markdown_links.py \
|
||||
README.md RULES.md ROADMAP.md CHANGELOG.md docs deltas history prompts
|
||||
|
||||
git diff --check
|
||||
git status --short
|
||||
|
||||
git add VERSION README.md docs/000-README.md \
|
||||
docs/objectives/001-PROJECT_OBJECTIVES.md \
|
||||
docs/architecture/002-GOVERNANCE_ARCHITECTURE.md \
|
||||
docs/rules/300-DOCUMENTATION.md \
|
||||
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
|
||||
deltas/0.1.5/alpha.4.md
|
||||
|
||||
git diff --cached --check
|
||||
git status --short
|
||||
```
|
||||
|
||||
Le scope indexé attendu avant ajout du history est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.4.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
M docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
```
|
||||
|
||||
## Revue opérateur attendue
|
||||
|
||||
La revue doit confirmer que la frontière est sémantique et non une dépendance entre dépôts : PGR reste utilisable seul, Knowledge reste une destination pratique possible, aucun contenu n'est déplacé et aucun owner externe n'est requis pour interpréter une règle.
|
||||
|
||||
Elle doit aussi confirmer que la tranche ne modifie pas les contrats d'autonomie acquis en `alpha.3` et ne commence pas les adoptions Games/KSP.
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/000-README.md -->
|
||||
<!-- version: 49 -->
|
||||
<!-- version: 50 -->
|
||||
|
||||
# Documentation PGR
|
||||
|
||||
@@ -22,11 +22,11 @@ Les templates techniques copiables sous `templates/` restent séparés des instr
|
||||
|
||||
## Points d'entrée de 0.1.5
|
||||
|
||||
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale `alpha.3`, frontière PGR / Knowledge, réconciliation puis freeze.
|
||||
- [`plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md`](plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md) — plan actif de `0.1.5` : inventaire `alpha.1`, récupération de preuve `alpha.1.fix.1`, sémantique normative `alpha.2`, autonomie locale `alpha.3`, frontière PGR / Knowledge `alpha.4`, réconciliation puis freeze.
|
||||
- [`studies/004-V0_1_4_HORIZON_REVIEW.md`](studies/004-V0_1_4_HORIZON_REVIEW.md) — décision autoritaire de fermeture `0.1.4` qui place la release de gouvernance/autonomie avant les adoptions Games/KSP.
|
||||
- [`../RULES.md`](../RULES.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md) et [`rules/400-VALIDATION.md`](rules/400-VALIDATION.md) — owners primaires réconciliés en `alpha.2` : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, sans `FAIL` de gate ni `OVERRIDE` automatique pour un simple écart.
|
||||
- [`rules/220-SKELETONS.md`](rules/220-SKELETONS.md), [`rules/230-ADOPTION.md`](rules/230-ADOPTION.md), [`skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md`](skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md) et [`templates/007-EXISTING_PROJECT_ADOPTION.md`](templates/007-EXISTING_PROJECT_ADOPTION.md) — owners réconciliés en `alpha.3` : baseline locale autoritaire, absence d'upstream PGR implicite et réalignement volontaire fondé sur un snapshot choisi.
|
||||
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners proposés pour formaliser la frontière PGR / SaseDev Knowledge sans dépendance externe.
|
||||
- [`objectives/001-PROJECT_OBJECTIVES.md`](objectives/001-PROJECT_OBJECTIVES.md), [`architecture/002-GOVERNANCE_ARCHITECTURE.md`](architecture/002-GOVERNANCE_ARCHITECTURE.md) et [`rules/300-DOCUMENTATION.md`](rules/300-DOCUMENTATION.md) — owners réconciliés en `alpha.4` : PGR reste auto-suffisant pour ses contrats normatifs ; les contenus pratiques externes restent complémentaires, sans dépendance PGR vers Knowledge ni déplacement automatique.
|
||||
- [`../prompts/011-V0_1_5_START_PROMPT.md`](../prompts/011-V0_1_5_START_PROMPT.md) — contrat de reprise exécuté pour ouvrir `0.1.5-alpha.1` à partir de la stable `v0.1.4` vérifiée.
|
||||
|
||||
## Points d'entrée de 0.1.4
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/architecture/002-GOVERNANCE_ARCHITECTURE.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Architecture de gouvernance PGR
|
||||
|
||||
@@ -23,7 +23,7 @@ Après instanciation, le projet possède sa copie et ne dépend plus de PGR.
|
||||
|
||||
### Skeleton specification
|
||||
|
||||
Un skeleton est une recette Markdown décrivant comment initialiser un type de projet ou composer plusieurs profils.
|
||||
Un skeleton est une spécification Markdown composable décrivant comment initialiser un type de projet ou composer plusieurs profils.
|
||||
|
||||
Il décrit notamment les profils applicables, la structure requise ou optionnelle, les templates à utiliser, les points de décision, la politique de version et la validation de base. Le contrat transversal de sélection et de composition appartient à [`../rules/220-SKELETONS.md`](../rules/220-SKELETONS.md) ; les spécifications concrètes sont indexées sous [`../skeletons/`](../skeletons/000-README.md).
|
||||
|
||||
@@ -37,6 +37,16 @@ Les scripts `audit_*.py` sont read-only : ils ne modifient, ne formatent, ne gé
|
||||
|
||||
Les audits PGR sont ajoutés progressivement à partir de besoins réels et de contrôles éprouvés. PGR ne cherche pas à anticiper un catalogue exhaustif d'audits.
|
||||
|
||||
## Frontière avec les contenus pratiques externes
|
||||
|
||||
PGR doit rester auto-suffisant pour comprendre et appliquer ses contrats normatifs. Les règles, owners, objectifs, décisions architecturales, skeleton specifications, templates nécessaires à un contrat réutilisable et validations directement liées aux règles restent possédés par PGR lorsqu'ils sont nécessaires à cette compréhension.
|
||||
|
||||
Les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation MAY vivre dans une base de connaissances séparée. SaseDev Knowledge est une destination possible pour cette famille de contenus, mais sa disponibilité n'est pas une précondition d'utilisation de PGR.
|
||||
|
||||
Un contenu pratique externe MAY compléter PGR, mais MUST NOT devenir la source nécessaire pour déterminer ce qu'une règle PGR exige. PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
|
||||
|
||||
Cette frontière est sémantique avant d'être physique : classifier un contenu comme pratique ne déclenche pas automatiquement son déplacement. Une extraction future exige une destination autoritaire explicitement fournie et doit préserver dans PGR tout contrat nécessaire à son auto-suffisance.
|
||||
|
||||
## Instanciation d'un projet
|
||||
|
||||
Le flux conceptuel est :
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/objectives/001-PROJECT_OBJECTIVES.md -->
|
||||
<!-- version: 1 -->
|
||||
<!-- version: 2 -->
|
||||
|
||||
# Objectifs de Project Governance Rules
|
||||
|
||||
@@ -18,9 +18,11 @@ PGR doit permettre de :
|
||||
- favoriser des validations ciblées pendant le développement et des gates plus larges aux jalons appropriés ;
|
||||
- automatiser les contrôles déterministes et fiables sans automatiser artificiellement les décisions nécessitant du jugement ;
|
||||
- fournir des templates techniques éprouvés sans créer de dépendance vers PGR après instanciation ;
|
||||
- décrire des skeletons de projets sous forme de recettes Markdown composables plutôt que de générateurs rigides ;
|
||||
- décrire des skeletons de projets sous forme de spécifications Markdown composables plutôt que de générateurs rigides ;
|
||||
- supporter plusieurs langages, plateformes et frameworks sans chercher une uniformité artificielle ;
|
||||
- conserver une traçabilité historique utile tout en gardant les documents vivants lisibles ;
|
||||
- rester auto-suffisant pour comprendre et appliquer les contrats normatifs PGR, sans dépendre d’un howto, snippet ou dépôt documentaire externe ;
|
||||
- permettre que les howtos détaillés, recettes pratiques, snippets, exemples d’intégration, dépannage, comparatifs et variantes d’implémentation vivent dans une base de connaissances séparée lorsqu’une telle séparation apporte une valeur réelle ;
|
||||
- permettre des règles project-specific et des exceptions explicites sans contaminer les règles générales ;
|
||||
- privilégier la sécurité, l'explicité, la maintenabilité et la proportionnalité.
|
||||
|
||||
@@ -45,6 +47,7 @@ PGR n'a pas pour objectif de :
|
||||
- créer des audits regex pour remplacer le jugement architectural ;
|
||||
- réimplémenter les fonctionnalités des toolchains officielles sans bénéfice réel ;
|
||||
- maintenir automatiquement les projets créés à partir de PGR ;
|
||||
- devenir une base exhaustive de howtos, recettes, snippets ou dépannage lorsque ces contenus ne sont pas nécessaires pour comprendre ou appliquer un contrat PGR ;
|
||||
- imposer une stratégie Git complexe ou une topologie universelle de branches.
|
||||
|
||||
## Critères de succès à terme
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
|
||||
<!-- version: 3 -->
|
||||
<!-- version: 4 -->
|
||||
|
||||
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
|
||||
|
||||
@@ -214,7 +214,7 @@ frontière PGR / Knowledge
|
||||
|
||||
Aucun nouveau owner Knowledge n’est prévu par défaut.
|
||||
|
||||
## Progression acquise avant `alpha.3`
|
||||
## Progression acquise avant `alpha.4`
|
||||
|
||||
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`.
|
||||
|
||||
@@ -240,6 +240,17 @@ Décisions de mise en œuvre `alpha.3` :
|
||||
- `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.
|
||||
|
||||
## Trajectoire de release
|
||||
|
||||
### `alpha.1` — intake, audit transversal et plan
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
<!-- file: docs/rules/300-DOCUMENTATION.md -->
|
||||
<!-- version: 4 -->
|
||||
<!-- version: 5 -->
|
||||
|
||||
# Documentation rules
|
||||
|
||||
@@ -145,6 +145,27 @@ Un répertoire générique tel que `misc/` SHOULD NOT devenir la destination par
|
||||
|
||||
Une technologie ou un projet MAY introduire des familles supplémentaires lorsqu'elles représentent une responsabilité documentaire stable.
|
||||
|
||||
## Frontière normative et pratique
|
||||
|
||||
La documentation gouvernée par PGR distingue les informations nécessaires au contrat PGR des contenus pratiques complémentaires.
|
||||
|
||||
Restent possédés par PGR lorsqu'ils sont nécessaires à la compréhension ou à l'application du référentiel :
|
||||
|
||||
- règles et contrats de gouvernance ;
|
||||
- objectifs et architecture qui définissent le sens durable du référentiel ;
|
||||
- owners normatifs ;
|
||||
- skeleton specifications minimales ;
|
||||
- templates nécessaires à un contrat réutilisable ;
|
||||
- matrices, validations et preuves 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 MAY être maintenus dans une base de connaissances séparée lorsqu'une destination réelle et autoritaire existe. SaseDev Knowledge MAY jouer ce rôle, sans devenir un owner normatif de PGR.
|
||||
|
||||
PGR MUST rester auto-suffisant : une règle PGR MUST être compréhensible et applicable sans consulter un howto ou snippet externe. Un contenu externe MAY fournir des exemples ou une aide opérationnelle, mais MUST NOT être requis pour déterminer la force, le scope ou les exigences d'une règle PGR.
|
||||
|
||||
Classifier un contenu comme pratique ne crée pas une obligation de déplacement. Une migration physique vers une base de connaissances externe MUST être une opération explicitement décidée, fondée sur une destination autoritaire fournie et vérifiée. Tant que cette condition n'est pas remplie, le contenu existant MAY rester dans PGR s'il conserve une utilité réelle.
|
||||
|
||||
Cette séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou vers un autre dépôt documentaire externe.
|
||||
|
||||
## Idées, études et décisions
|
||||
|
||||
Une idée est une possibilité non engagée. Elle ne doit pas être présentée comme une décision ou une promesse de roadmap.
|
||||
|
||||
121
history/0.1.5/alpha.4.md
Normal file
121
history/0.1.5/alpha.4.md
Normal file
@@ -0,0 +1,121 @@
|
||||
<!-- file: history/0.1.5/alpha.4.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# History 0.1.5-alpha.4 — frontière PGR / Knowledge stabilisée
|
||||
|
||||
## Statut
|
||||
|
||||
PASS
|
||||
|
||||
La gate opérateur de `0.1.5-alpha.4` exécutée le `2026-10-01` est propre. La tranche fixe la frontière durable entre le référentiel normatif PGR et les contenus pratiques externes possibles sans créer de dépendance vers SaseDev Knowledge ni déplacer automatiquement de contenu.
|
||||
|
||||
## Baseline opérateur
|
||||
|
||||
La tranche `0.1.5-alpha.3` et son history `PASS` ont été committés puis publiés avant application de `alpha.4` :
|
||||
|
||||
```text
|
||||
commit alpha.3 7079b15
|
||||
push e94b786..7079b15 master -> master
|
||||
```
|
||||
|
||||
La version observée pendant la gate est :
|
||||
|
||||
```text
|
||||
0.1.5-alpha.4
|
||||
```
|
||||
|
||||
Les histories précédents conservent la séquence réelle :
|
||||
|
||||
```text
|
||||
alpha.1 PARTIAL
|
||||
alpha.1.fix.1 PASS
|
||||
alpha.2 PASS
|
||||
alpha.3 PASS
|
||||
```
|
||||
|
||||
Le history `alpha.4` était absent pendant la gate.
|
||||
|
||||
## Frontière PGR / Knowledge acquise
|
||||
|
||||
Les assertions opérateur ont confirmé dans `docs/objectives/001-PROJECT_OBJECTIVES.md` révision `2` :
|
||||
|
||||
- les skeletons sont des spécifications Markdown composables et non des recettes pratiques ;
|
||||
- PGR reste auto-suffisant pour comprendre et appliquer ses contrats normatifs ;
|
||||
- les howtos détaillés, recettes pratiques, snippets, exemples d'intégration, dépannage, comparatifs et variantes d'implémentation peuvent vivre dans une base de connaissances séparée lorsqu'une telle séparation apporte une valeur réelle.
|
||||
|
||||
`docs/architecture/002-GOVERNANCE_ARCHITECTURE.md` révision `5` confirme qu'un skeleton est une spécification Markdown composable, que SaseDev Knowledge n'est qu'une destination pratique possible et que PGR MUST NOT dépendre d'un dépôt Knowledge pour être interprétable ou applicable.
|
||||
|
||||
`docs/rules/300-DOCUMENTATION.md` révision `5` devient l'owner documentaire de cette frontière :
|
||||
|
||||
- SaseDev Knowledge MAY accueillir des contenus pratiques sans devenir owner normatif de PGR ;
|
||||
- une règle PGR MUST rester compréhensible et applicable sans howto/snippet externe ;
|
||||
- classifier un contenu comme pratique ne déclenche aucun déplacement automatique ;
|
||||
- la séparation MUST NOT créer de dépendance de PGR vers SaseDev Knowledge ou un autre dépôt documentaire externe.
|
||||
|
||||
## Owners gelés et trajectoire
|
||||
|
||||
Les contrôles ont confirmé que les owners hors scope de `alpha.4` restent inchangés :
|
||||
|
||||
```text
|
||||
RULES.md version 16
|
||||
docs/rules/210-WORKFLOW.md version 9
|
||||
docs/rules/230-ADOPTION.md version 3
|
||||
```
|
||||
|
||||
`git diff --exit-code` sur ces fichiers, `ROADMAP.md`, `CHANGELOG.md` et `history/0.1.4` n'a produit aucun écart.
|
||||
|
||||
La ROADMAP conserve :
|
||||
|
||||
```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 non réservé
|
||||
```
|
||||
|
||||
Le contrôle d'appariement a affiché :
|
||||
|
||||
```text
|
||||
0.1.5 alpha.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)
|
||||
```
|
||||
|
||||
## Tests et audits
|
||||
|
||||
La suite Python complète est propre :
|
||||
|
||||
```text
|
||||
Ran 55 tests in 0.916s
|
||||
OK
|
||||
```
|
||||
|
||||
Les audits documentaires sont également propres :
|
||||
|
||||
```text
|
||||
Text hygiene audit: clean (319 file(s))
|
||||
Markdown header audit: clean (292 file(s))
|
||||
Markdown table audit: clean (11 table(s), 292 file(s))
|
||||
Markdown link audit: clean (371 local link(s), 292 file(s))
|
||||
```
|
||||
|
||||
`git diff --check` et `git diff --cached --check` n'ont produit aucun diagnostic.
|
||||
|
||||
## Scope Git observé
|
||||
|
||||
Avant indexation, le dépôt contenait uniquement les modifications prévues par le delta `alpha.4`. Après indexation explicite, le scope observé est exactement :
|
||||
|
||||
```text
|
||||
M README.md
|
||||
M VERSION
|
||||
A deltas/0.1.5/alpha.4.md
|
||||
M docs/000-README.md
|
||||
M docs/architecture/002-GOVERNANCE_ARCHITECTURE.md
|
||||
M docs/objectives/001-PROJECT_OBJECTIVES.md
|
||||
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
|
||||
M docs/rules/300-DOCUMENTATION.md
|
||||
```
|
||||
|
||||
## Décision
|
||||
|
||||
`0.1.5-alpha.4` est validée `PASS`.
|
||||
|
||||
La tranche suivante peut ouvrir `beta.1` pour la réconciliation transversale des trois contrats stabilisés : rescan des `SHOULD / SHOULD NOT`, vérification de l'autonomie/snapshots/overrides, recherche de références vivantes obsolètes et confirmation que les scopes Games `0.1.6`, KSP `0.1.7` et audits Rust/Clippy `0.1.8` n'ont pas commencé.
|
||||
Reference in New Issue
Block a user