5.9 KiB
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
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.
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.
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.
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.
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.
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.
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 :
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.