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