# Mapping d'adoption PGR v0.1.3 vers Knowledge ## Objet Ce document ferme la réconciliation PGR explicitement engagée au démarrage de `0.0.2`. Il conserve la provenance des contrats examinés et indique leur owner Knowledge durable. Après cette tranche, le développement courant se fonde sur les artefacts locaux Knowledge. Les règles sélectionnées ci-dessous sont adaptées et suffisamment matérialisées localement pour leur usage quotidien ; ce mapping ne crée aucune dépendance de lecture vers PGR. ## Source d'adoption observée ```text PGR tag v0.1.3 PGR commit fe80dbbb737390a7ea99df27d979bd59ccfb86e3 PGR archive SHA-256 f3a7dffd5fe0fd3542e6b5207fda0b94bca2bd05bd5a54542d0a08d635a5d6ee publish report pgr-0.1.3-publish.001-report.md = PASS ``` Cette source sert uniquement à expliquer les décisions ci-dessous. ## Décisions ADOPT ### Gouvernance — provenance PGR owner 200 Décision : `ADOPT`. Owner local : [`../rules/200-GOVERNANCE.md`](../rules/200-GOVERNANCE.md). Adaptation : proportionnalité, versioning/lifecycle, fixes, REPLAN, baseline autoritaire, décisions différées et autonomie normative sont exprimés sans dépendre d'un dépôt PGR courant. ### Workflow — provenance PGR owner 210 Décision : `ADOPT`. Owner local : [`../rules/210-WORKFLOW.md`](../rules/210-WORKFLOW.md). Adaptation : contrats delta/history, cycle gate/commit/push, prompts/handoffs, fixes, REPLAN, fermeture stable, tag/archive et preuve post-tag sont spécialisés pour Knowledge et `origin/master` lorsqu'il est établi. ### Adoption d'un projet existant — provenance PGR owner 230 Décision : `ADOPT`, puis scope fermé après matérialisation. Owner local durable : gouvernance locale et présent mapping. Adaptation : toute future adoption externe doit être explicitement engagée ; aucune surveillance continue de PGR n'est créée. ### Documentation — provenance PGR owner 300 Décision : `ADOPT`. Owner local : [`../rules/300-DOCUMENTATION.md`](../rules/300-DOCUMENTATION.md). Adaptation : rôles README/RULES/ROADMAP/CHANGELOG/index, familles documentaires, documents vivants/historiques, headers, plans, revue d'horizon et prompts sont possédés localement. ### Validation — provenance PGR owner 400 Décision : `ADOPT`. Owner local : [`../rules/400-VALIDATION.md`](../rules/400-VALIDATION.md). Adaptation : validation proportionnée, statuts, catégories de preuve, autorité opérateur, ordre des gates et scripts read-only sont possédés localement. ### Rust / Cargo — provenance PGR owners 500 + 510 Décision : `ADOPT` pour le profil Rust applicable ; le méta-owner langage 500 n'est pas matérialisé séparément. Owner local : [`../rules/510-RUST_CARGO.md`](../rules/510-RUST_CARGO.md). Adaptation : Rust 2024, workspace, nomenclature, façade crate-root, tests et audits stricts sont exprimés directement pour Knowledge. ### Web — provenance PGR owners 530 + 540 + 550 + 560 Décision : `ADOPT` pour les contrats réellement utilisés. Owner local consolidé : [`../rules/530-WEB_FRONTEND.md`](../rules/530-WEB_FRONTEND.md). Adaptation : TypeScript, npm, Vite et Sass sont regroupés avec les décisions locales Bootstrap et Maud afin d'éviter quatre owners locaux artificiellement séparés. ## Décisions KEEP-LOCAL ### Skeletons — provenance PGR owner 220 Décision : `KEEP-LOCAL` après instanciation. Les skeletons de fondation, workspace Rust et frontend ont servi à amorcer l'état existant. Ils ne sont pas réappliqués ni conservés comme dépendances normatives. Les fichiers réellement instanciés dans Knowledge sont les propriétaires de leur configuration. ### Frameworks — provenance PGR owner 700 Décision : `KEEP-LOCAL`. Le méta-owner framework n'apporte pas de règle quotidienne supplémentaire : Actix Web, Maud et Bootstrap sont des choix locaux documentés dans `RULES.md`, l'architecture et l'owner Web local. ### Audits Rust déjà adaptés Décision : `KEEP-LOCAL` lorsque les scripts locaux divergent ou spécialisent la baseline générique. Les audits Rust présents dans `scripts/` sont les copies autoritaires Knowledge. Ils ne sont pas remplacés automatiquement par des scripts PGR portant le même nom. ## Décisions DEFER / non applicables - `710-TAURI` : `DEFER`, aucun host Tauri dans le scope courant. - Java/Maven/Gradle : non applicables au workspace actuel. - Android : non applicable au produit Web actuel. - autres plateformes/langages absents : non sélectionnés. Aucun `OVERRIDE` de règle PGR applicable n'est nécessaire pour clôturer cette adoption ; les décisions produit distinctes sont classées `KEEP-LOCAL` plutôt que présentées comme des overrides artificiels. ## Artefacts localement matérialisés L'adoption est considérée autonome lorsque les artefacts suivants sont présents et validés : ```text RULES.md docs/rules/200-GOVERNANCE.md docs/rules/210-WORKFLOW.md docs/rules/300-DOCUMENTATION.md docs/rules/400-VALIDATION.md docs/rules/510-RUST_CARGO.md docs/rules/530-WEB_FRONTEND.md docs/templates/001-NEW_SESSION_PROMPT.md docs/templates/002-RELEASE_PLAN.md docs/templates/003-OPERATOR_HANDOFF.md docs/templates/004-RUST_LIBRARY_CRATE.md scripts/audit_markdown_headers.py scripts/audit_markdown_links.py scripts/audit_markdown_tables.py scripts/audit_rust_crate_root_facades.py ``` Les configurations déjà instanciées (`Cargo.toml`, `rustfmt.toml`, `clippy.toml`, `.cargo/config.toml`, package npm, tsconfig et Vite) restent leurs propres artefacts autoritaires ; elles ne sont pas dupliquées dans un répertoire de templates uniquement pour reproduire PGR. ## Critère de fermeture Après `PASS` d'`alpha.4`, une nouvelle session Knowledge doit pouvoir comprendre et développer le projet à partir de la stable Knowledge et de ses artefacts locaux, sans charger PGR. Une future adoption PGR demeure possible, mais seulement comme opération explicitement planifiée.