pgr/history/0.1.5/alpha.3.md

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 :

commit alpha.2   e94b786
push             32433ca..e94b786  master -> master

La version observée pendant la gate est :

0.1.5-alpha.3

Les histories précédents conservent la séquence réelle :

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 :

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é :

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 :

Ran 55 tests in 0.902s
OK

Les audits documentaires sont également propres :

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 :

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.