4.2 KiB
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 :
commit alpha.3 7079b15
push e94b786..7079b15 master -> master
La version observée pendant la gate est :
0.1.5-alpha.4
Les histories précédents conservent la séquence réelle :
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 :
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 :
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.4 history boundary: clean (107 closed prior pairs, current alpha.4 pending)
Tests et audits
La suite Python complète est propre :
Ran 55 tests in 0.916s
OK
Les audits documentaires sont également propres :
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 :
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é.