0.0.2-alpha.3.fix.1

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 12 -->
+<!-- version: 13 -->
 
 # Règles SaseDev Knowledge
 
@@ -9,13 +9,11 @@ Ce document gouverne le workspace applicatif `sasedev-knowledge` et sert de poin
 
 Le contenu éditorial publié par PGR, HOWTOs et snippets vit dans des dépôts Git distincts et conserve sa propre gouvernance. Les règles de ce dépôt ne transforment pas ces contenus en sous-modules normatifs de l'application.
 
-## Baseline PGR
+## Provenance PGR et autonomie normative
 
 La fondation stable `0.0.1` a été cadrée à partir de PGR `v0.1.1`. Cette référence reste historique et n'est pas réécrite rétroactivement.
 
-À partir de `0.0.2-alpha.1`, Knowledge adopte comme baseline PGR courante la stable `v0.1.3`, vérifiée par `pgr-0.1.3-publish.001-report.md = PASS`.
-
-Identité de la baseline PGR courante :
+Au démarrage explicite de `0.0.2`, Knowledge a réévalué PGR et retenu `v0.1.3` comme **source d'adoption** vérifiée par `pgr-0.1.3-publish.001-report.md = PASS` :
 
 ```text
 tag      v0.1.3
@@ -23,9 +21,13 @@ commit   fe80dbbb737390a7ea99df27d979bd59ccfb86e3
 SHA-256  f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee
 ```
 
-La migration depuis `v0.1.1` suit `230-ADOPTION` : seuls les owners réellement applicables sont adoptés, les choix locaux compatibles sont conservés et l'historique `0.0.1` n'est pas réécrit pour simuler une conformité rétroactive.
+Cette identité documente la provenance de l'adoption ; elle n'est pas une dépendance normative vivante. Une migration réussie doit laisser Knowledge autonome : les règles réellement retenues sont sélectionnées, adaptées et possédées localement par Knowledge. PGR n'est ni une dépendance runtime/build, ni un référentiel à charger automatiquement au début d'une version, d'une session ou d'une tranche.
 
-Les contrats PGR adoptés sont instanciés localement dans ce dépôt. PGR n'est pas une dépendance runtime ou build de Knowledge.
+Le prompt `prompts/002-V0_0_2_START_PROMPT.md` reste historique : sa vérification de la stable PGR courante appartenait à l'adoption explicitement engagée au démarrage de `0.0.2`. Ce comportement ne devient pas le modèle des futurs prompts Knowledge.
+
+Une future version de PGR n'a aucun effet automatique sur Knowledge. Elle n'est consultée que lorsqu'une réévaluation/adoption PGR est explicitement inscrite au scope d'une tranche ou d'une release. Cette réévaluation doit alors comparer la baseline locale Knowledge avec la version PGR choisie, classifier les décisions `ADOPT / KEEP-LOCAL / OVERRIDE / DEFER`, puis matérialiser localement les décisions retenues avant de refermer l'adoption.
+
+`0.0.2-alpha.4` est la tranche de réconciliation qui doit terminer l'autonomie normative de l'adoption `v0.1.3` : inventorier les owners réellement retenus, vérifier où chaque contrat nécessaire est possédé localement, adapter les règles/templates/audits manquants sans recopier mécaniquement l'arborescence PGR et supprimer les références externes nécessaires à la compréhension courante du projet.
 
 ## Owners PGR applicables
 
@@ -47,7 +49,7 @@ La fondation retient les owners suivants dans leur scope réel :
 700  famille framework pour les frameworks réellement utilisés
 ```
 
-Les skeletons `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` restent les références de composition de l'état existant. L'adoption PGR `v0.1.3` ne les réapplique pas mécaniquement sur le projet déjà matérialisé.
+Les skeletons `001-PROJECT_GOVERNANCE_FOUNDATION`, `002-RUST_CARGO_WORKSPACE` et `003-WEB_FRONTEND` documentent la provenance de composition de l'état existant. Ils ne sont pas des dépendances documentaires à relire pour développer Knowledge. `alpha.4` doit vérifier que les responsabilités effectivement retenues sont possédées localement avant de considérer l'adoption `v0.1.3` comme complètement matérialisée.
 
 Le profil `710-TAURI` reste `DEFER` / non applicable au produit Web actuel. Aucun skeleton Tauri n'est adopté.
 
@@ -55,7 +57,7 @@ Les owners Java/Maven/Gradle réorganisés en PGR `0.1.2`, le profil Android ré
 
 ## Priorité et décisions locales
 
-Les obligations PGR réellement adoptées priment sur une préférence locale de Knowledge dans le même scope.
+Les contrats issus de PGR et explicitement adoptés par Knowledge deviennent des règles **locales Knowledge** après adaptation/matérialisation. C'est leur formulation locale qui gouverne ensuite le projet ; PGR conserve uniquement la provenance de la décision.
 
 Les choix propres au produit restent locaux lorsqu'aucun owner PGR plus spécifique ne les impose. C'est notamment le cas de l'architecture Git/forge/PostgreSQL, du choix Actix Web/Maud, de Bootstrap, de la topologie à trois applications Web et de la topologie des dépôts de contenu.
 
@@ -67,7 +69,7 @@ Les décisions différées sont explicites dans [`docs/architecture/001-PROJECT_
 
 `VERSION` est le repère canonique simple de la release unit applicative.
 
-Knowledge adopte le workflow PGR :
+Knowledge possède localement le workflow suivant, issu de l'adoption PGR :
 
 ```text
 delta -> application -> gate opérateur -> history observé -> application du history -> commit/push -> delta suivant
@@ -101,7 +103,7 @@ knowledge-howtos-server
 knowledge-snippets-server
 ```
 
-Chaque package exécutable reste une couche de composition mince conformément au profil Rust/Cargo PGR. La logique partagée appartient aux crates `-lib` appropriées et ne doit pas être dupliquée entre les trois `main.rs`.
+Chaque package exécutable reste une couche de composition mince conformément au contrat Rust/Cargo retenu localement par Knowledge. La logique partagée appartient aux crates `-lib` appropriées et ne doit pas être dupliquée entre les trois `main.rs`.
 
 Les trois applications peuvent être déployées, redémarrées et dimensionnées séparément. Cette séparation de launchers ne constitue pas une autorisation à fragmenter arbitrairement le domaine en microservices.
 
@@ -245,9 +247,9 @@ Les responsabilités candidates sont documentées dans l'architecture. Une crate
 
 `alpha.3` matérialise ainsi `knowledge-git-api` pour la frontière `GitRepository` et `knowledge-sync-api` pour la frontière `RepositoryEventSource`. Ces crates restent passives, sans runtime ni logging propre, et dépendent seulement des types de domaine nécessaires. Les implémentations Git, hooks, polling, webhooks ou forge restent hors de ces crates de contrat.
 
-Le profil Rust strict PGR s'applique aux crates matérialisées, notamment Rust 2024, `unsafe` interdit par défaut, lints stricts, exports publics maîtrisés et chemins intra-crate explicites via la façade crate-root.
+Le contrat Rust strict retenu par Knowledge s'applique aux crates matérialisées, notamment Rust 2024, `unsafe` interdit par défaut, lints stricts, exports publics maîtrisés et chemins intra-crate explicites via la façade crate-root. `alpha.4` doit vérifier que l'ensemble des obligations réellement nécessaires de ce contrat est possédé localement sans devoir relire PGR.
 
-Les audits read-only PGR sélectionnés avec les premiers contrats publics sont `audit_rust_blank_lines.py`, `audit_rust_item_spacing.py`, `audit_rust_module_order.py`, `audit_rust_trait_import_blocks.py`, `audit_rust_reexport_blocks.py` et `audit_rust_export_completeness.py`. L'audit `const` n'est pas sélectionné globalement : il reste opt-in par fichier lorsqu'un ordre mécanique de constantes est réellement approprié.
+Les audits read-only sélectionnés et possédés localement avec les premiers contrats publics sont `audit_rust_blank_lines.py`, `audit_rust_item_spacing.py`, `audit_rust_module_order.py`, `audit_rust_trait_import_blocks.py`, `audit_rust_reexport_blocks.py` et `audit_rust_export_completeness.py`. L'audit `const` n'est pas sélectionné globalement : il reste opt-in par fichier lorsqu'un ordre mécanique de constantes est réellement approprié.
 
 ## Secrets et configuration locale