Sasedev/pgr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

0.1.5-alpha.3

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-10-01 10:04:31 +02:00
parent e94b78610d
commit 7079b150a8
11 changed files with 375 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
README.md
View File

@@ -1,5 +1,5 @@
<!-- file: README.md -->
<!-- version: 29 -->
<!-- version: 30 -->
# 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.2` stabilise maintenant le premier contrat transversal décidé par sa revue d’horizon : `SHOULD / SHOULD NOT` est une forte recommandation non obligatoire, distincte des obligations `MUST / MUST NOT`, et son non-respect ne crée ni `FAIL` de gate ni `OVERRIDE` automatique. La tranche corrige uniquement les renforcements accidentels démontrés par l'inventaire `alpha.1` ; l'autonomie post-adoption reste réservée à `alpha.3`, la frontière PGR / SaseDev Knowledge à `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.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 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.

7
RULES.md
View File

@@ -1,5 +1,5 @@
<!-- file: RULES.md -->
<!-- version: 15 -->
<!-- version: 16 -->
# Index normatif Project Governance Rules
@@ -49,8 +49,9 @@ Une règle plus spécifique MAY raffiner ou renforcer localement une règle gén
## Principes fondamentaux
- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables.
- PGR MUST NOT devenir une dépendance runtime ou build des projets qu'il aide à initialiser.
- Les projets instanciés depuis PGR MUST rester autonomes et posséder leurs propres copies des règles et configurations applicables. Après établissement de la baseline locale, cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes.
- PGR MUST NOT devenir une dépendance runtime, build ou documentaire implicite des projets qu'il aide à initialiser ou adopter. Un projet gouverné localement MUST NOT rechercher automatiquement « la dernière version de PGR » ni traiter PGR comme un upstream à suivre.
- Un réalignement futur avec PGR MAY être engagé comme opération explicite et bornée : le projet choisit un snapshot PGR précis, compare ce snapshot à sa baseline locale, décide les écarts applicables et conserve ses historiques. Le réalignement ne constitue jamais une mise à jour automatique de la gouvernance locale.
- Les skeletons PGR sont des spécifications Markdown et MUST NOT devenir un générateur qui fige l'architecture d'un projet.
- Les audits `audit_*.py` MUST être read-only, déterministes autant que raisonnablement possible et sans effets de bord sur le dépôt inspecté.
- Une propriété déjà correctement contrôlée par le compilateur, le linter ou le build system SHOULD NOT être dupliquée par un test ou audit maison sans besoin réel.

2
VERSION
View File

@@ -1 +1 @@
0.1.5-alpha.2
0.1.5-alpha.3

185
deltas/0.1.5/alpha.3.md Normal file
View File

@@ -0,0 +1,185 @@
<!-- file: deltas/0.1.5/alpha.3.md -->
<!-- version: 1 -->
# Delta 0.1.5-alpha.3 — autonomie locale et réalignement PGR volontaire
## Objet
Stabiliser le contrat d'autonomie après instanciation ou adoption : une fois la baseline locale établie, le projet gouverne ses sessions et releases suivantes depuis ses propres owners, sans dépendance documentaire implicite vers PGR ni recherche automatique d'une version plus récente du référentiel.
La tranche définit également le seul mécanisme prévu pour revenir volontairement vers PGR : un réalignement explicite, borné, fondé sur un snapshot PGR précis choisi par le projet puis comparé à la baseline locale.
## Précondition
Le history `history/0.1.5/alpha.2.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
```
Le `PARTIAL` initial n'est pas réécrit et les histories précédents restent inchangés.
## Contrat d'autonomie
Après instanciation ou adoption :
```text
snapshot PGR explicitement choisi
↓
instanciation / adoption / adaptation
↓
baseline locale du projet
↓
autorité locale des sessions et releases suivantes
```
Le projet possède alors ses règles, plans, architecture, décisions et historiques applicables. PGR ne devient ni dépendance runtime/build, ni upstream documentaire implicite.
Le projet MUST NOT rechercher automatiquement « la dernière version de PGR » pour reprendre une session ou ouvrir une release suivante.
## Réalignement futur
Un réalignement PGR reste possible lorsqu'il est explicitement décidé. Il ne constitue pas une mise à jour continue.
L'opération doit :
1. identifier un snapshot PGR précis — version, tag, commit ou archive ;
2. repartir de la baseline locale autoritaire ;
3. comparer les owners PGR réellement applicables ;
4. classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
5. définir un scope et des validations proportionnés ;
6. préserver les histories et snapshots historiques du projet.
Entre deux réalignements explicitement décidés, la baseline locale reste suffisante et autoritaire.
## Owners réconciliés
- `RULES.md` révision `16` : autonomie générale, absence d'upstream PGR implicite et réalignement borné ;
- `docs/rules/220-SKELETONS.md` révision `2` : la baseline locale devient autoritaire dès l'instanciation et aucune version PGR plus récente n'est recherchée automatiquement ;
- `docs/rules/230-ADOPTION.md` révision `3` : contrat complet d'autorité locale et procédure de réalignement futur ;
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : propagation du contrat au point d'entrée normatif local ;
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : snapshot PGR choisi, baseline locale de sortie et pattern de réalignement explicite.
`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` restent `KEEP` : leur reprise part déjà de la baseline autoritaire du projet courant et aucune contradiction n'a été démontrée.
## Cohérence documentaire
- `README.md` présente `0.1.5-alpha.3` comme tranche active ;
- `docs/000-README.md` identifie les owners d'autonomie réconciliés ;
- `docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md` passe en révision `3`, enregistre `alpha.2 PASS` et la mise en œuvre `alpha.3`.
`ROADMAP.md` et `CHANGELOG.md` restent inchangés. La frontière PGR / SaseDev Knowledge reste réservée à `alpha.4` ; 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.2` avec son history `PASS`, appliquer ce delta puis exécuter :
```bash
cat VERSION
test -f history/0.1.5/alpha.2.md
test -f deltas/0.1.5/alpha.3.md
test ! -e history/0.1.5/alpha.3.md
grep -Fx '0.1.5-alpha.3' 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 -Fx '<!-- version: 16 -->' RULES.md
grep -F 'cette baseline et ses owners locaux deviennent l'autorité des sessions et releases suivantes' RULES.md
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' RULES.md
grep -F 'réalignement futur avec PGR MAY être engagé comme opération explicite et bornée' RULES.md
grep -Fx '<!-- version: 2 -->' docs/rules/220-SKELETONS.md
grep -F 'Cette baseline locale devient l'autorité de ses sessions et releases suivantes' docs/rules/220-SKELETONS.md
grep -F 'MUST NOT rechercher automatiquement une version PGR plus récente' docs/rules/220-SKELETONS.md
grep -F "snapshot PGR précis choisi par le projet" docs/rules/220-SKELETONS.md
grep -Fx '<!-- version: 3 -->' docs/rules/230-ADOPTION.md
grep -F 'elle devient l'autorité des sessions et releases suivantes du projet' docs/rules/230-ADOPTION.md
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/rules/230-ADOPTION.md
grep -F '## Autorité locale et réalignement futur' docs/rules/230-ADOPTION.md
grep -F 'identifier le snapshot PGR choisi' docs/rules/230-ADOPTION.md
grep -F 'Le réalignement ne doit pas être présenté comme une mise à jour automatique' docs/rules/230-ADOPTION.md
grep -Fx '<!-- version: 5 -->' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
grep -F "la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes" docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
grep -F 'MUST NOT rechercher automatiquement « la dernière version de PGR »' docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
grep -Fx '<!-- version: 2 -->' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
grep -F 'snapshot PGR choisi' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
grep -F '## Autorité après adoption' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
grep -F 'réalignement PGR automatique : non' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
grep -F 'Elles ne recherchent pas automatiquement « la dernière version de PGR »' docs/templates/007-EXISTING_PROJECT_ADOPTION.md
grep -Fx '<!-- version: 9 -->' docs/rules/210-WORKFLOW.md
grep -Fx '<!-- version: 2 -->' docs/templates/003-NEW_SESSION_PROMPT.md
grep -Fx '<!-- version: 3 -->' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -F 'Sa gate opérateur 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.3`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
grep -F 'la frontière Knowledge reste réservée à `alpha.4`' docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.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'}; assert {p.name for p in Path('history/0.1.5').glob('*.md')} == {'alpha.1.md','alpha.1.fix.1.md','alpha.2.md'}; print('0.1.5 alpha.3 history boundary: clean (106 closed prior pairs, current alpha.3 pending)')"
git diff --exit-code -- history/0.1.4
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 RULES.md docs/000-README.md \
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md \
docs/rules/220-SKELETONS.md docs/rules/230-ADOPTION.md \
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md \
docs/templates/007-EXISTING_PROJECT_ADOPTION.md \
deltas/0.1.5/alpha.3.md
git diff --cached --check
git status --short
```
Le scope indexé attendu avant ajout du history est exactement :
```text
M README.md
M RULES.md
M VERSION
A deltas/0.1.5/alpha.3.md
M docs/000-README.md
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
M docs/rules/220-SKELETONS.md
M docs/rules/230-ADOPTION.md
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
M docs/templates/007-EXISTING_PROJECT_ADOPTION.md
```
## Revue opérateur attendue
La revue doit confirmer qu'un projet adopté reste effectivement gouvernable sans consulter PGR, que le réalignement futur est une opération explicite et non un abonnement implicite, et qu'aucune règle n'oblige un projet à suivre automatiquement les nouvelles releases PGR.
Elle doit aussi confirmer que `210-WORKFLOW.md` et `003-NEW_SESSION_PROMPT.md` restent corrects sans modification et que `alpha.3` ne commence ni la frontière Knowledge ni les adoptions Games/KSP.

6
docs/000-README.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/000-README.md -->
<!-- version: 48 -->
<!-- version: 49 -->
# Documentation PGR
@@ -22,10 +22,10 @@ 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, 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, 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), [`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) — propagation du contrat d'autonomie après instanciation/adoption.
- [`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.
- [`../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.

19
docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Plan 0.1.5 — sémantique normative, autonomie et frontière PGR / Knowledge
@@ -214,22 +214,31 @@ frontière PGR / Knowledge
Aucun nouveau owner Knowledge n’est prévu par défaut.
## Progression acquise avant `alpha.2`
## Progression acquise avant `alpha.3`
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`.
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 de mise en œuvre `alpha.2` :
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 reste réservée à `alpha.3` et la frontière Knowledge à `alpha.4`.
- 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`.
## Trajectoire de release

6
docs/rules/220-SKELETONS.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/220-SKELETONS.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Skeleton specification rules
@@ -23,7 +23,9 @@ Un skeleton MUST NOT devenir :
- un moyen de figer une architecture au-delà du scope qu'il déclare ;
- un catalogue de technologies ou de fichiers créés par anticipation.
Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet.
Après instanciation, le projet destinataire possède ses fichiers, ses décisions et ses règles locales. Cette baseline locale devient l'autorité de ses sessions et releases suivantes. Une évolution ultérieure de PGR ne modifie pas automatiquement ce projet et le projet MUST NOT rechercher automatiquement une version PGR plus récente.
Un réalignement futur MAY être décidé explicitement. Il doit alors partir d'un snapshot PGR précis choisi par le projet, comparer ce snapshot à la baseline locale et appliquer uniquement les écarts explicitement retenus. Ce réalignement est une nouvelle opération bornée ; il ne transforme pas PGR en upstream documentaire permanent.
## Applicabilité

22
docs/rules/230-ADOPTION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/rules/230-ADOPTION.md -->
<!-- version: 2 -->
<!-- version: 3 -->
# Existing project adoption rules
@@ -17,7 +17,7 @@ PGR s’adapte au besoin réel du projet existant ; il ne cherche pas à effacer
Une adoption MUST partir d’une baseline autoritaire réellement observée : commit, tag, archive de release ou autre état explicitement accepté par le projet. Le travail d’adoption MUST distinguer ce qui existe déjà de ce que PGR propose d’ajouter ou de modifier.
Une migration réussie produit un projet autonome gouverné localement. Le projet destinataire ne devient pas dépendant runtime ou build du dépôt PGR.
Une migration réussie produit un projet autonome gouverné localement. Une fois la baseline locale établie, elle devient l'autorité des sessions et releases suivantes du projet. Le projet destinataire ne devient pas dépendant runtime, build ou documentaire implicite du dépôt PGR et MUST NOT rechercher automatiquement « la dernière version de PGR ».
## Audit initial de la baseline
@@ -98,6 +98,22 @@ Les conventions nouvelles s’appliquent à partir du point d’adoption explici
Une adoption MAY documenter des écarts hérités comme dette, exception temporaire ou contexte historique sans modifier les snapshots qui les ont produits.
## Autorité locale et réalignement futur
Après clôture du scope d'adoption, les règles, plans, décisions, validations et historiques locaux gouvernent les travaux suivants. Les sessions et releases ultérieures MUST partir de cette baseline locale et non d'une recherche automatique d'une version PGR plus récente.
PGR n'est pas un upstream documentaire implicite. Une référence, URL ou archive PGR utilisée pendant l'adoption reste une source de comparaison de cette opération ; elle ne crée pas un abonnement aux évolutions futures du référentiel. Une dépendance documentaire externe MAY exister uniquement si le projet la choisit et la possède explicitement comme contrat local.
Un réalignement futur avec PGR MAY être engagé lorsqu'il apporte une valeur réelle. Cette opération MUST être explicite et bornée. Elle doit au minimum :
1. identifier le snapshot PGR choisi, par exemple version, tag, commit ou archive ;
2. repartir de la baseline locale autoritaire du projet ;
3. comparer les owners applicables et classifier les écarts utiles selon `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER` ;
4. définir le scope et les validations de la migration ;
5. préserver les histories, tags et décisions historiques au lieu de les réécrire pour simuler une conformité continue.
Le réalignement ne doit pas être présenté comme une mise à jour automatique. Entre deux opérations explicitement décidées, la gouvernance locale reste autonome et suffisante pour reprendre le projet.
## Relation avec les skeletons et templates
Un skeleton PGR MAY servir de checklist de comparaison pour un projet existant. Il ne doit pas être appliqué comme si le dépôt était vide.
@@ -118,7 +134,7 @@ Une adoption n’est terminée que lorsque les décisions de son scope sont clas
Une adoption PGR réussie laisse :
- un projet autonome ;
- un projet autonome dont la baseline locale gouverne les sessions et releases suivantes ;
- uniquement les owners PGR réellement applicables ;
- les choix locaux légitimes préservés ;
- les overrides explicites lorsqu'une obligation applicable est volontairement remplacée ;

6
docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Skeleton — Project governance foundation
@@ -70,7 +70,9 @@ Ce document doit au minimum :
- expliquer la priorité ou la spécialisation locale lorsqu'une adaptation existe ;
- renvoyer vers les documents détaillés au lieu de recopier leur contenu sans nécessité.
Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable.
Le projet doit rester autonome : ses règles nécessaires vivent dans son dépôt ou dans un mécanisme de dépendance documentaire explicitement choisi et possédé par lui. Une URL vers PGR ne remplace pas à elle seule une baseline locale exploitable et ne crée pas un upstream documentaire implicite.
À l'issue de l'instanciation, la baseline locale et ses owners deviennent l'autorité des sessions et releases suivantes. Le projet MUST NOT rechercher automatiquement « la dernière version de PGR ». Un réalignement ultérieur MAY être entrepris uniquement comme opération explicite à partir d'un snapshot PGR précis choisi puis comparé à cette baseline locale.
### Version

21
docs/templates/007-EXISTING_PROJECT_ADOPTION.md vendored
View File

@@ -1,5 +1,5 @@
<!-- file: docs/templates/007-EXISTING_PROJECT_ADOPTION.md -->
<!-- version: 1 -->
<!-- version: 2 -->
# Pattern — adoption PGR d’un projet existant
@@ -14,13 +14,14 @@ Il peut être instancié comme étude, plan, tableau de décision ou section d
Consigner uniquement ce qui est réellement établi :
```text
repository / archive : <source>
repository / archive : <source locale autoritaire>
commit / tag : <si connu>
version : <si applicable>
snapshot PGR choisi : <version / tag / commit / archive de comparaison>
validation connue : <preuves déjà acquises et encore pertinentes>
```
Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR.
Ne pas reconstruire une baseline à partir d’hypothèses ou d’une version plus récente de PGR. Le snapshot PGR est une entrée de comparaison explicitement choisie pour cette opération ; il n'est pas un upstream que le projet doit suivre ensuite.
## Inventaire utile
@@ -74,6 +75,20 @@ Exemples :
- dette héritée documentée mais non réécrite rétroactivement.
```
## Autorité après adoption
À la clôture du scope, consigner explicitement que la baseline locale obtenue devient l'autorité des sessions et releases suivantes. Une forme courte suffit :
```text
baseline locale autoritaire : <version / commit / état accepté>
réalignement PGR automatique : non
```
Les reprises ultérieures partent des règles, plans, architecture et histories du projet. Elles ne recherchent pas automatiquement « la dernière version de PGR ».
Si un réalignement futur est souhaité, ouvrir une nouvelle opération bornée : choisir un snapshot PGR précis, comparer ses owners applicables à la baseline locale, classifier les écarts `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis valider seulement le scope retenu. Les snapshots historiques locaux restent inchangés.
## Validation de sortie
L’adoption du scope est prête lorsque :

121
history/0.1.5/alpha.3.md Normal file
View File

@@ -0,0 +1,121 @@
<!-- file: history/0.1.5/alpha.3.md -->
<!-- version: 1 -->
# History 0.1.5-alpha.3 — autonomie locale stabilisée
## Statut
PASS
La gate opérateur de `0.1.5-alpha.3` exécutée le `2026-10-01` est propre. La tranche établit la baseline locale comme autorité des sessions et releases suivantes après instanciation/adoption et définit tout réalignement futur avec PGR comme une opération volontaire, explicite et bornée.
## Baseline opérateur
La tranche `0.1.5-alpha.2` et son history `PASS` ont été committés puis publiés avant application de `alpha.3` :
```text
commit alpha.2 e94b786
push 32433ca..e94b786 master -> master
```
La version observée pendant la gate est :
```text
0.1.5-alpha.3
```
Les histories précédents conservent la séquence réelle :
```text
alpha.1 PARTIAL
alpha.1.fix.1 PASS
alpha.2 PASS
```
Le history `alpha.3` était absent pendant la gate.
## Autorité locale acquise
Les assertions opérateur ont confirmé dans `RULES.md` révision `16` :
- après établissement de la baseline locale, cette baseline et ses owners deviennent l'autorité des sessions et releases suivantes ;
- PGR ne devient pas un upstream documentaire implicite ;
- un projet MUST NOT rechercher automatiquement « la dernière version de PGR » ;
- un réalignement futur MAY être engagé uniquement comme opération explicite et bornée à partir d'un snapshot PGR précis.
`docs/rules/220-SKELETONS.md` révision `2` propage ce contrat au point d'instanciation : le projet possède sa baseline locale, ne recherche pas automatiquement une version PGR plus récente et ne revient vers PGR que depuis un snapshot explicitement choisi.
`docs/rules/230-ADOPTION.md` révision `3` établit le même contrat après adoption et formalise la procédure de réalignement futur : identification du snapshot, comparaison avec la baseline locale et absence de mise à jour automatique.
## Propagation aux artefacts d'adoption
Les assertions ont confirmé :
- `docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md` révision `5` : la baseline locale et ses owners deviennent autoritaires après instanciation ;
- `docs/templates/007-EXISTING_PROJECT_ADOPTION.md` révision `2` : le snapshot PGR choisi est explicite, l'autorité après adoption est locale et le réalignement automatique est `non`.
`docs/rules/210-WORKFLOW.md` révision `9` et `docs/templates/003-NEW_SESSION_PROMPT.md` révision `2` sont restés `KEEP` comme prévu : leur reprise depuis la baseline autoritaire du projet courant est déjà compatible avec le contrat d'autonomie.
Le plan `011` révision `3` enregistre `alpha.2 PASS`, les décisions de mise en œuvre `alpha.3` et maintient explicitement la frontière PGR / SaseDev Knowledge en `alpha.4`.
## Frontières et historique
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.3 history boundary: clean (106 closed prior pairs, current alpha.3 pending)
```
`git diff --exit-code -- history/0.1.4` n'a produit aucun écart : les histories de la stable précédente restent inchangés.
## Tests et audits
La suite Python complète est propre :
```text
Ran 55 tests in 0.902s
OK
```
Les audits documentaires sont également propres :
```text
Text hygiene audit: clean (317 file(s))
Markdown header audit: clean (290 file(s))
Markdown table audit: clean (11 table(s), 290 file(s))
Markdown link audit: clean (371 local link(s), 290 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.3`. Après indexation explicite, le scope observé est exactement :
```text
M README.md
M RULES.md
M VERSION
A deltas/0.1.5/alpha.3.md
M docs/000-README.md
M docs/plans/011-V0_1_5_NORMATIVE_AUTONOMY_PLAN.md
M docs/rules/220-SKELETONS.md
M docs/rules/230-ADOPTION.md
M docs/skeletons/001-PROJECT_GOVERNANCE_FOUNDATION.md
M docs/templates/007-EXISTING_PROJECT_ADOPTION.md
```
## Décision
`0.1.5-alpha.3` est validée `PASS`.
La tranche suivante peut ouvrir `alpha.4`, strictement consacrée à la frontière PGR / SaseDev Knowledge : taxonomie normative/pratique, auto-suffisance de PGR et suppression de l'ambiguïté « recette Markdown » sans migration physique vers Knowledge et sans dépendance externe.