pgr/CHANGELOG.md

Changelog Project Governance Rules

Ce fichier décrit les changements utiles aux utilisateurs ou intégrateurs des releases publiées de PGR.

Les tranches alpha, beta, rc, fixes, validations, audits et détails de développement appartiennent aux plans, deltas et historiques. Ils ne sont pas recopiés ici par défaut.

0.1.2

• sépare l'ancien profil combiné Java/Maven/Gradle en trois owners indépendants et composables : 520-JAVA, 521-MAVEN et 522-GRADLE, afin qu'un build tool ne devienne pas implicitement applicable à tout projet Java ;
• clarifie la distinction entre JDK utilisé pour construire, niveau Java du code source et niveau de bytecode/runtime supporté, sans généraliser les versions particulières observées dans Games ;
• formalise pour Gradle l'ownership settings / root / modules / propriétés partagées, ainsi que le choix proportionné entre Wrapper et Gradle système avec contrainte effectivement vérifiée ;
• conserve Maven comme spécialisation indépendante et cohérente sans prétendre l'avoir éprouvée par Games ni créer d'artefact Maven en l'absence de corpus réel ;
• conserve l'ancien chemin 520-JAVA_MAVEN_GRADLE.md uniquement comme bridge documentaire SUPERSEDED pour les références historiques et n'ajoute aucun template, skeleton, audit Python ou contrat de validation Java/Maven/Gradle non justifié ;
• maintient les responsabilités AGP, SDK/NDK, ABI/JNI, manifests/resources, packaging/signing et smokes Android dans l'owner Android, dont la réévaluation pratique reste la cible distincte 0.1.3.

0.1.1

• établit une fondation frontend Web composable avec quatre owners indépendants : TypeScript, écosystème de package JavaScript, Vite et CSS/Sass, sans transformer un outil concret en obligation universelle ;
• recommande TypeScript pour les frontends durables avec vérification stricte et noEmit, tout en distinguant les types embarqués des packages @types/* réellement nécessaires à l'analyse, à l'intégration IDE et aux API consommées ;
• formalise un écosystème de package neutre vis-à-vis de npm/pnpm/yarn, un script typecheck indépendant et une politique de lockfile dépendant du rôle application/bibliothèque plutôt qu'une règle unique artificielle ;
• recommande Vite lorsque son modèle convient, avec ownership explicite du dev server, du cache, des outputs, des assets et des paramètres de sécurité, sans fournir de vite.config.ts, port, base ou layout universels ;
• conserve CSS comme baseline valide et recommande Sass lorsqu'il apporte une valeur réelle, notamment pour les packages exposant une API Sass, avec préférence pour @use / @forward et séparation stricte entre sources et styles générés ;
• ajoute une validation frontend indépendante du host et un skeleton Web composable, puis confirme que les cinq prérequis Web du futur réexamen Tauri sont couverts sans lever le DEFER, qui reste réservé à 0.1.4.

0.1.0

• établit la première baseline PGR réellement réutilisable pour initialiser de nouveaux projets et adopter progressivement des projets existants, avec une fondation de gouvernance, des skeleton specifications composables et une validation proportionnée ;
• stabilise le socle Rust/Cargo réutilisable : cinq templates techniques, composition 001 + 002, dry-run NEW avec Cargo/rustfmt/Clippy et chemin ADOPTION non destructif ;
• formalise l'adoption de projets existants avec baseline autoritaire, migration progressive et décisions ADOPT / KEEP-LOCAL / OVERRIDE / DEFER, sans réécriture rétroactive de l'historique ;
• corrige la convention de clôture stable vers rel.N sans zéro de padding et garantit que la première clôture qui obtient réellement PASS produit le commit produit X.Y.Z avant le tag vX.Y.Z ;
• rend obligatoire le handoff automatique des commandes opérateur entre history, commit/push, delta suivant et publication stable, avec distinction entre objet tag, commit déréférencé et rapport publish.* post-tag ;
• matérialise la revue d'horizon suivante : frontend Web, Java/Gradle, Android, Tauri conditionnel, adoption Games puis KSP et audits Rust/Clippy statiques Python-only, tout en laissant WASM, serveur Rust et deployment/operations sans réservation prématurée.

0.0.5

• consolide le lifecycle inter-release de PGR : prompts de reprise versionnés, contrats locaux de fichiers/familles, responsabilités de fermeture et revue d'horizon sans création artificielle de releases futures ;
• renforce le profil Rust/Cargo des nouveaux projets contrôlés avec Rust 2024, chemins explicites, façade crate-root, contrats de suffixes de crates, séparation bibliothèque/exécutable, erreurs explicites et ownership du tracing ;
• ajoute et sépare les validations Rust structurelles utiles : complétude des réexports/chemins crate::Item, espacement des items, ordre des modules, blocs d'imports de traits et blocs de réexports, tout en conservant les contrôles à ordre sémantique comme opt-in ;
• active les profils framework et Tauri 2, avec host Rust direct, frontière frontend explicite, TS-RS pour les DTO partagés, plugins/capabilities gouvernés, versions produit classifiées et exception Tauri encadrée au principe de séparation lib/bin ;
• enregistre le skeleton Tauri contrôlé comme trajectoire DEFER jusqu'à matérialisation d'owners Web suffisants, sans créer de skeleton décoratif ni réserver une release ;
• réconcilie les décisions avec les corpus KSP/Games, conserve leurs architectures métier locales hors du noyau PGR et prépare le prompt de reprise 006 vers la première baseline réutilisable 0.1.0.

0.0.4

• définit un contrat transversal de skeleton specifications pour sélectionner et composer règles, profils, templates, décisions destinataire, overrides et validation sans dupliquer les propriétaires normatifs ;
• ajoute une fondation composable de gouvernance locale pour initialiser version, documentation minimale, workflow retenu et validation proportionnée d'un projet utilisant PGR ;
• ajoute une spécialisation Rust/Cargo workspace composant la fondation avec les profils 500 + 510 et les cinq templates Rust/Cargo existants ;
• explicite les décisions à adapter avant instanciation, notamment version, édition/toolchain, membres, métadonnées, dépendances/features, Cargo.lock, lints, chemins d'artefacts et audits facultatifs ;
• conserve Java/Maven/Gradle, Android, Web, JNI, Tauri et les autres familles insuffisamment matérialisées comme domaines différés plutôt que créer des skeletons prématurés.

0.0.3

• fournit cinq fichiers modèles Rust/Cargo : rustfmt.toml, clippy.toml, .cargo/config.toml, un manifest workspace et un manifest de crate membre, avec instructions d'adaptation ;
• explicite l'héritage des métadonnées et lints Cargo, ainsi que les exceptions locales motivées ;
• ajoute deux audits facultatifs et ciblés du style Rust, pour l'espacement des lignes vides et les blocs de constantes racine sans ordre sémantique, sans remplacer Rustfmt ni Clippy ;
• ajoute un audit read-only des headers file et version des fichiers Markdown gouvernés par PGR ;
• fournit une spécification courte pour rédiger le message manuel de reprise après publication d'une stable.

0.0.2

• introduit le modèle de profils PGR avec ownership normatif, applicabilité, composition du général vers le spécifique et overrides bornés ;
• matérialise les familles 500 — languages / ecosystems et 600 — platforms sans créer prématurément les familles frameworks ou architecture ;
• ajoute les premiers profils réutilisables 510 — Rust / Cargo, 520 — Java / Maven / Gradle et 610 — Android ;
• formalise notamment les politiques de toolchain/target, dépendances et build, visibilité/API, safety/FFI, structure canonique, compatibilité Android, packaging et niveaux de preuve ;
• ajoute deux audits PGR read-only et monotâches : alignement des tableaux Markdown et existence des cibles de liens Markdown locaux ;
• confirme que Rust/JNI, Web/Vite/WASM, Tauri, C/C++/CMake, PHP/Composer et Python restent différés jusqu'à une release où leur contenu justifie un owner réel.

0.0.1

• établit la fondation normative de PGR : force MUST / SHOULD / MAY, hiérarchie des scopes et principe de proportionnalité ;
• définit le modèle SemVer PGR, le rôle limité du fichier racine VERSION et le lifecycle alpha → beta → rc → stable avec fixes, REPLAN, abandon et supersession ;
• formalise le workflow des plans, deltas, histories, prompts, handoffs, manifests, commits de tranche et baselines issues des tags stables ;
• fixe les responsabilités documentaires, les révisions internes de fichiers, la conservation des snapshots historiques et la politique linguistique du dépôt principal ;
• établit la validation proportionnée, la séparation TEST / AUDIT / DIAGNOSTIC, les tests utiles sans quota global de coverage et l'autorité du gate opérateur.