0.0.2-alpha.1

RULES.md

@@ -1,5 +1,5 @@
 <!-- file: RULES.md -->
-<!-- version: 9 -->
+<!-- version: 10 -->
 
 # Règles SaseDev Knowledge
 
@@ -11,14 +11,20 @@ Le contenu éditorial publié par PGR, HOWTOs et snippets vit dans des dépôts
 
 ## Baseline PGR
 
-La fondation `0.0.1` est cadrée à partir de la stable PGR `v0.1.1`, vérifiée par son rapport post-tag `publish.001` `PASS`.
+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.
 
-Empreinte de l'archive PGR autoritaire utilisée pour ce cadrage :
+À 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 :
 
 ```text
-SHA-256 caaf8f456f7f8520172ea7705fd0cf5c5bf0e942dc4a773410bcbe7fe4ce243a
+tag      v0.1.3
+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.
+
 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.
 
 ## Owners PGR applicables
@@ -29,6 +35,7 @@ La fondation retient les owners suivants dans leur scope réel :
 200  gouvernance et lifecycle
 210  workflow plan/delta/history/handoff
 220  composition des skeletons pendant l'instanciation
+230  adoption d'une nouvelle baseline PGR par un projet existant
 300  documentation
 400  validation proportionnée
 500  famille langage/écosystème
@@ -40,11 +47,11 @@ 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` sont les spécialisations retenues pour `0.0.1`, avec matérialisation progressive selon le plan.
+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é.
 
-Le profil `710-TAURI` n'est pas applicable au produit Web actuel. Aucun skeleton Tauri n'est adopté.
+Le profil `710-TAURI` reste `DEFER` / non applicable au produit Web actuel. Aucun skeleton Tauri n'est adopté.
 
-Les profils Java/Maven/Gradle, Android et les autres technologies absentes du projet restent hors scope.
+Les owners Java/Maven/Gradle réorganisés en PGR `0.1.2`, le profil Android réévalué en `0.1.3` et les autres technologies absentes du projet restent hors scope.
 
 ## Priorité et décisions locales
 
@@ -52,7 +59,7 @@ Les obligations PGR réellement adoptées priment sur une préférence locale de
 
 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.
 
-Aucun `OVERRIDE` PGR n'est établi par `0.0.1-alpha.1.fix.1`.
+Aucun `OVERRIDE` PGR n'est requis par l'adoption `v0.1.3` de `0.0.2-alpha.1`.
 
 Les décisions différées sont explicites dans [`docs/architecture/001-PROJECT_PROFILE.md`](docs/architecture/001-PROJECT_PROFILE.md). Une valeur différée ne doit pas être remplacée par un choix arbitraire provenant d'un autre projet.
 
@@ -118,6 +125,12 @@ Une proposition externe MUST conserver la révision Git de base et MUST NOT écr
 
 La synchronisation générique MUST disposer d'une voie indépendante des webhooks. Les hooks et webhooks MAY accélérer une synchronisation qui converge vers le même cas d'usage interne.
 
+Pour `0.0.2`, la première implémentation générique retenue utilise un processus `git` contrôlé derrière `knowledge-git-api`. Cette décision est locale à Knowledge et reste remplaçable derrière le contrat.
+
+La configuration physique des sources Git et la matérialisation locale appartiennent à `knowledge-git-lib` lorsqu'elle sera créée. Les copies générées MUST résider sous une racine d'état explicitement fournie au backend, hors du dépôt applicatif et des dépôts éditoriaux. Ni une URL remote ni un `SourceId` brut ne doivent devenir directement un chemin de stockage.
+
+La racine d'état Git n'est pas un stockage métier. En `0.0.2`, elle est possédée exclusivement par une instance de backend/processus ; un partage concurrent inter-processus reste différé tant qu'un verrouillage dédié n'est pas matérialisé.
+
 ## PostgreSQL
 
 PostgreSQL est destiné à l'état applicatif : comptes, sessions, propositions, revues, audit applicatif, index, recherche, synchronisation et jobs.