Files
pgr/history/0.1.5/alpha.3.md
2026-10-01 10:04:31 +02:00

122 lines
4.4 KiB
Markdown

<!-- 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.