pgr/docs/plans/002-V0_0_2_RULE_PROFILES_PLAN.md

Plan 0.0.2 — premiers profils de règles technologiques

Statut

Plan actif créé pendant 0.0.2-alpha.1 après audit de la baseline stable v0.0.1 fournie sous forme d'archive ZIP issue du tag Gitea.

La baseline v0.0.1 est cohérente pour démarrer 0.0.2. L'absence de .git dans cette archive est normale et n'est pas une anomalie de baseline.

Le présent plan reste prévisionnel. Il peut être révisé lorsqu'un résultat réel invalide son dimensionnement ou son découpage, conformément aux règles de REPLAN.

Mission

0.0.2 introduit les premiers profils de règles technologiques réutilisables de PGR sans dupliquer les responsabilités déjà possédées par RULES.md et les familles 200, 300 et 400.

La release doit démontrer concrètement la composition :

GENERAL
    ↓
ecosystem / language
    ↓
platform
    ↓
framework
    ↓
project type / subsystem
    ↓
project-specific / explicit exception

Un profil matérialisé doit posséder un contenu normatif réel, un scope explicite et un propriétaire documentaire identifiable. Il ne doit pas devenir un catalogue de dépendances ni répéter les règles générales sous une autre forme.

Autorité des sources pendant la consolidation

Pour cette release :

• l'archive source issue du tag v0.0.1 est la baseline autoritaire de l'état PGR ;
• prompts/002-V0_0_2_START_PROMPT.md est le contrat opératoire de démarrage de 0.0.2 ;
• les corpus de conception externes ou historiques peuvent servir de matière d'analyse, mais ne constituent pas l'état courant du dépôt ;
• aucune règle, décision, version de fichier ou structure absente de la baseline et du prompt ne doit être supposée déjà acquise ;
• chaque proposition réutilisée doit être requalifiée selon les règles PGR actuelles avant de devenir normative.

Audit de la baseline v0.0.1

L'inspection de l'archive taggée a constaté :

• une racine unique pgr/ ;
• 44 fichiers et 13 répertoires dans l'archive, sans entrée dupliquée ;
• aucune entrée absolue, traversée .. ou symlink ;
• aucune arborescence .git, conformément au contrat des archives de tag ;
• VERSION égal exactement à 0.0.1 ;
• aucun cache/build connu, __pycache__, .pyc, node_modules, target, dist ou secret local distribué ;
• tous les fichiers Markdown avec headers file/version cohérents avec leur emplacement ;
• aucun lien Markdown local cassé parmi les liens vérifiés ;
• 12 deltas 0.0.1 et 12 histories correspondants, sans delta ou history orphelin ;
• une chaîne de résultats cohérente : les FAIL de alpha.1, alpha.1.fix.1, alpha.4 et rc.1 restent historiques et sont suivis par leurs corrections validées avant progression ;
• la promotion rel.001 enregistrée PASS, le plan 0.0.1 clôturé et le prompt 0.0.2 présent ;
• les compteurs internes version: des documents vivants cohérents avec les opérations ADD/REPLACE observées dans les deltas 0.0.1.

Aucun défaut bloquant de gouvernance, de structure documentaire, de pairing delta/history ou de cohérence interne n'a été trouvé.

Preuve post-tag publish.001

Le rapport post-tag pgr-0.0.1-publish.001-report.md a été retrouvé dans la bibliothèque de travail après la première revue de alpha.1.

Il enregistre Status: PASS pour pgr-v0.0.1.zip et confirme le SHA-256 déjà observé pour l'archive de baseline :

48bfed6acc50d2c5bdd69db764ae29fe8c5a06b64375943f5d4120c7bb8429ef

Cette preuve est volontairement extérieure au tag v0.0.1 parce qu'elle vérifie un artefact produit après le tag. Elle ne doit ni être injectée rétroactivement dans la stable ni remplacer l'audit d'intake de la session courante.

La revue a également identifié un besoin de maturité futur : un handoff/prompt de reprise doit finir par indiquer explicitement si une preuve post-publication telle que publish.001 doit être fournie à la session suivante. Ce besoin de workflow reste hors scope fonctionnel de 0.0.2.

Inventaire des profils candidats

Le prompt demande d'examiner le corpus suivant. Après revue du sizing initial, 0.0.2-alpha.1.fix.1 réduit volontairement le nombre de profils matérialisés afin de conserver une version terminable et correctement validable dans une session.

Domaine candidat	Décision 0.0.2	Propriétaire prévisionnel	Motif
modèle de profil et composition des scopes	inclure	architecture PGR	nécessaire avant de créer plusieurs profils cohérents
Rust / Cargo	inclure	famille 500 — languages / ecosystems	premier profil langage/écosystème, corpus éprouvé
Java / Maven / Gradle	inclure	famille 500 — languages / ecosystems + build	permet de distinguer langage et build tool avant Android
Android	inclure	famille 600 — platforms	premier exemple de spécialisation plateforme sur des règles de langage/build
Rust + Android / JNI	différer	future composition spécialisée	utile mais non nécessaire pour prouver le premier modèle
Web / TypeScript / Vite / WASM / serveurs Rust	différer	future composition Web	scope autonome suffisamment large pour une release ultérieure
Tauri desktop/mobile	différer	future famille 700 — frameworks	dépend de profils Rust/Web/plateforme suffisamment stabilisés
C / C++ / CMake	différer	future famille 500 — languages / ecosystems	corpus utile mais non nécessaire au premier lot
PHP / Composer	différer	future famille 500 — languages / ecosystems	ne pas matérialiser un profil uniquement pour remplir la taxonomie
Python 3 application/package	différer	future famille 500 — languages / ecosystems	à introduire lorsqu'un besoin concret le justifie
architecture/règles cross-cutting	conditionnel	famille 800 — architecture ou owner existant	uniquement si plusieurs profils révèlent une règle commune sans propriétaire

Les domaines différés restent des candidats légitimes. Leur absence de 0.0.2 ne vaut ni rejet ni interdiction future.

Le choix retenu cherche le plus petit ensemble qui exerce réellement plusieurs niveaux de composition : un modèle commun, un profil langage/écosystème, une distinction langage/build et une plateforme. Les compositions FFI, Web et framework restent séparées afin de ne pas transformer la première release de profils en catalogue.

Règles de consolidation

Chaque tranche technologique doit :

1. repartir des règles générales actuellement applicables ;
2. identifier ce qui est réellement spécifique au profil ;
3. éviter les duplications de gouvernance, documentation et validation générales ;
4. distinguer règle normative, exemple, choix de projet et point encore ouvert ;
5. documenter explicitement les overrides/contraintes spécialisées et leur scope ;
6. préférer les structures canoniques de l'écosystème lorsqu'elles apportent une vraie valeur ;
7. ne pas fixer une version d'outil ou de dépendance sans raison de compatibilité, reproductibilité, support ou sécurité ;
8. ne créer un audit que lorsqu'une propriété stable, objectivement automatisable et réellement utile a été démontrée ;
9. conserver PGR lui-même indépendant des toolchains qu'il documente ;
10. réviser le plan si une tranche devient sensiblement plus large que prévu au lieu d'absorber silencieusement le scope.

Découpage prévisionnel

alpha.1 — Baseline audit and profile sizing

Auditer intégralement v0.0.1, confronter le prompt à l'état réel, inventorier les profils candidats, fixer les domaines inclus/différés et créer le présent plan.

Aucune règle technologique détaillée n'est consolidée dans cette tranche.

alpha.2 — Rule profile model

Formaliser le contrat d'un profil PGR : ownership, composition général → spécifique, navigation des familles nécessaires, règles de non-duplication et traitement des choix encore ouverts.

Cette tranche doit créer uniquement les propriétaires documentaires réellement nécessaires à 0.0.2. Les familles 700 et 800 restent réservées tant qu'aucun contenu réel ne justifie leur matérialisation.

alpha.3 — Rust / Cargo

Consolider le premier profil langage/écosystème Rust/Cargo, notamment structure de workspace/crates, manifests et toolchain, dépendances/features, API/imports, erreurs/safety, tests et validation spécialisée lorsque ces sujets ne sont pas déjà possédés par une règle générale.

Cette tranche sert aussi de mesure réelle du coût d'un profil. Si elle montre que le modèle documentaire est sensiblement plus lourd que prévu, un REPLAN doit intervenir avant d'enchaîner les autres profils.

alpha.4 — Java / Maven / Gradle

Consolider le profil Java et ses spécialisations de build Maven/Gradle en maintenant une frontière nette entre règles Java, contraintes de build tool et choix propres à une plateforme ou un framework.

alpha.5 — Android

Consolider le premier profil plateforme Android : structure canonique, toolchain compatible, SDK/targets, configuration locale/signing, modules, packaging, tests/smokes et règles de compatibilité de target.

Les règles Rust/JNI, Web et Tauri ne doivent pas être absorbées dans ce profil général. Elles restent différées jusqu'à une release où leurs compositions pourront être traitées sans surcharger 0.0.2.

beta.1 — Profile reconciliation

Réconcilier les profils créés, vérifier les scopes/overrides, éliminer les répétitions, vérifier la navigation et extraire vers un owner cross-cutting uniquement les règles réellement communes qui ne possèdent pas déjà de propriétaire normatif.

Aucun nouveau profil technologique majeur ne doit être introduit en beta sans REPLAN.

rc.1 — Rule profiles release candidate

Geler le scope, préparer l'entrée candidate 0.0.2 du changelog, finaliser le prompt 0.0.3 et exécuter la gate documentaire complète applicable.

stable — 0.0.2

Promouvoir mécaniquement la RC validée, finaliser les métadonnées de release, enregistrer rel.001, commit/tag v0.0.2, puis vérifier séparément l'archive publiée issue du tag.

Dimensionnement et points de replan

Le premier forecast alpha.2 à alpha.8 a été jugé trop large pendant la revue opérateur de alpha.1. Le présent plan réduit donc la release avant tout développement technologique lourd.

Après alpha.1.fix.1, le chemin prévu est :

alpha.2  modèle de profil
alpha.3  Rust / Cargo
alpha.4  Java / Maven / Gradle
alpha.5  Android
beta.1   réconciliation
rc.1     release candidate
stable   0.0.2

Ce découpage reste un forecast, pas une obligation de remplir tous les numéros coûte que coûte.

alpha.3 est un point de mesure explicite. Si la construction du premier profil montre qu'un profil complet dépasse sensiblement le sizing envisagé, la release doit être REPLANifiée avant alpha.4 au lieu de conserver mécaniquement le forecast.

Un nouveau besoin critique, plusieurs fixes consécutifs ou une évolution qui rend 0.0.2 non terminable dans la session doivent également déclencher un REPLAN. La qualité de la release prend le dessus sur la volonté de conserver artificiellement le nombre initial de profils.

Hors périmètre

0.0.2 ne doit pas :

• produire les templates techniques réservés à 0.0.3 ;
• créer les skeleton specifications complètes réservées à 0.0.4 ;
• créer un générateur ;
• réécrire KSP ou sasedev-games ;
• multiplier les audits spécialisés ; alpha.1.fix.1 introduit uniquement l'audit Markdown monotâche justifié par un défaut réellement observé ;
• transformer les exemples de technologies en dépendances du dépôt PGR ;
• modifier rétroactivement les deltas/histories 0.0.1 pour refléter des règles apparues après leur émission.

Critères de fermeture

0.0.2 peut atteindre RC lorsque :

• le modèle documentaire des profils est explicite et cohérent avec la hiérarchie PGR ;
• les profils retenus dans le scope possèdent chacun un propriétaire normatif réel ;
• les spécialisations de build et de plateforme retenues ne contaminent pas les règles générales ;
• les choix encore ouverts restent identifiés comme tels ;
• la navigation entre règles générales et profils spécifiques est claire ;
• aucune duplication importante avec les familles 200, 300 et 400 ne subsiste ;
• les profils différés ne sont pas artificiellement matérialisés ;
• les validations de la release restent documentaires et proportionnées au dépôt PGR lui-même.