pgr/docs/plans/004-V0_0_4_SKELETONS_PLAN.md

Plan 0.0.4 — skeleton specifications et composition

Statut et sources

Plan actif créé pendant 0.0.4-alpha.1 après audit indépendant de la stable publiée v0.0.3 demandé par prompts/004-V0_0_4_START_PROMPT.md.

La baseline autoritaire est l'archive source fournie pgr-v0.0.3.zip, déclarée téléchargée depuis le tag Gitea v0.0.3. Son SHA-256 vérifié pendant le cadrage est :

517fb46ada098fdc221ae53a8ff4b409b81e0244ec5ce4d0e6fca0c3da61b866

Le rapport externe pgr-0.0.3-publish.001-report.md est fourni séparément, conclut PASS et annonce le même hash. Il atteste une vérification post-tag distincte et ne fait pas partie de la stable. L'archive source ne contient pas .git, ce qui est conforme au contrat de reprise ; l'identité du commit et du tag décrite dans le rapport n'est pas déduite du contenu du ZIP.

Les règles applicables au cadrage sont RULES.md, les familles 200, 210, 300, 400, 500, 510, 520, 600, 610, ainsi que docs/architecture/003-RULE_PROFILE_MODEL.md. Les guides docs/templates/001 à 003, les cinq modèles Rust/Cargo, les trois audits Markdown et les deux audits facultatifs de style Rust complètent l'inventaire réel de la stable.

Audit indépendant de la stable v0.0.3

L'archive fournie est lisible et son contenu distribué est cohérent dans les contrôles effectués :

• SHA-256 égal au rapport post-tag ;
• 140 entrées ZIP : 115 fichiers et 25 répertoires, avec une seule racine pgr/ ;
• test CRC propre, aucun doublon, aucune collision de casse, aucun chemin absolu ou avec traversée .., aucun chemin Windows ambigu et aucun lien symbolique ;
• extraction propre de 115 fichiers ; VERSION contient exactement 0.0.3 suivi d'un retour à la ligne ; .git est absent comme attendu ;
• les fichiers distribués sont UTF-8, sans octet NUL, retour CR, espace de fin de ligne ou retour final manquant ;
• aucun chemin distribué de build/cache ou secret contrôlé n'est présent ; .settings/org.eclipse.core.resources.prefs reste l'exception Eclipse versionnée prévue ;
• 99 fichiers Markdown possèdent des headers file/version mécaniquement conformes ;
• les trois audits Markdown sont propres : 99 fichiers pour les headers, 3 tableaux et 79 liens locaux ;
• les 15 tests Python ciblés réussissent ;
• les cinq fichiers TOML sous templates/rust-cargo/ se parsèrent correctement ;
• les deux audits de style Rust facultatifs n'ont pas de corpus Rust produit à inspecter dans PGR ; leur comportement est couvert par tests/test_rust_audits.py et leur sélection doit rester explicite dans un projet destinataire.

La chaîne workflow est complète :

0.0.1 : 12 deltas / 12 histories
0.0.2 : 12 deltas / 12 histories
0.0.3 : 10 deltas / 10 histories

Chaque delta possède son history homonyme. Les histories 0.0.3, de alpha.1 à rel.001, sont tous PASS. Les échecs historiques des séries antérieures sont conservés comme snapshots et sont suivis par leurs corrections explicites ; ils ne sont pas réécrits rétroactivement.

Les limites annoncées restent visibles et cohérentes : l'audit des liens ne valide pas les anchors, l'audit des headers ne juge pas la pertinence sémantique d'une révision, les audits Rust utilisent une analyse lexicale ciblée et l'archive source ne prouve pas elle-même une référence Git distante. Aucun de ces points ne constitue un défaut bloquant de la stable.

Revue des règles, profils et propriétaires

La hiérarchie normative reste cohérente avec le modèle de profils : règles générales, langage/écosystème, plateforme, puis scopes plus spécifiques et exceptions explicites. Aucun profil n'est applicable par simple fréquence ou provenance historique.

Les responsabilités utiles à 0.0.4 sont distinctes :

• 200 possède le lifecycle et le rôle de alpha.1 comme gate de cadrage ;
• 210 possède plans, deltas, histories, prompts, baselines et séparation pré-tag/post-tag ;
• 300 possède rôles documentaires, documents vivants, snapshots et headers ;
• 400 possède la sélection proportionnelle des preuves et l'autorité du gate opérateur ;
• 500 et 600 possèdent les contrats communs des profils langage et plateforme ;
• 510, 520 et 610 possèdent respectivement Rust/Cargo, Java/Maven/Gradle et Android ;
• docs/architecture/003-RULE_PROFILE_MODEL.md possède le modèle de composition et interdit les profils composites sans contrat propre réel.

La séparation règle / template / skeleton / audit de docs/architecture/002-GOVERNANCE_ARCHITECTURE.md reste adaptée. 0.0.4 doit l'étendre par des artefacts concrets sans déplacer les propriétaires normatifs existants.

Inventaire des capacités disponibles pour des skeletons

Fondation gouvernée PGR — prête à être spécifiée

Une baseline de projet gouverné constitue une fondation composable, pas une architecture applicative. Les contrats nécessaires existent déjà : versioning, workflow, documentation, validation et modèle de profils. Le skeleton devra indiquer quels artefacts locaux créer ou copier, comment sélectionner les règles réellement applicables et quelles décisions restent propres au projet.

Il ne doit pas recopier l'historique de PGR, imposer toutes les familles de règles ni créer une dépendance dynamique vers le dépôt PGR.

Rust/Cargo workspace — prêt à être spécifié

Le besoin est suffisamment couvert par des artefacts réels : profil 510, deux guides d'adaptation, cinq templates Rust/Cargo et deux audits de style facultatifs documentés. Le skeleton pourra composer une fondation gouvernée avec 500 + 510 et sélectionner uniquement les templates nécessaires.

Les décisions destinataire restent explicites : nom du projet et des crates, version de release, édition/toolchain, métadonnées de publication, membres du workspace, dépendances et features, politique Cargo.lock, chemin des artefacts Cargo, seuils Clippy, politique de lints et sélection éventuelle des audits de style. Les valeurs d'exemple 0.1.0, 2024, project-name, project-core-lib, les seuils Clippy et les chemins de build ne deviennent jamais universels.

Java / Maven / Gradle — différé

Le profil 520 définit des règles, mais PGR ne possède encore aucun template Maven/Gradle ou corpus technique éprouvé à instancier. Le choix Maven/Gradle, la politique de wrapper et les versions de toolchain doivent être déterminés dans un chantier justifié avant de produire un skeleton concret.

Android — différé

Le profil 610 définit la structure de responsabilité et les décisions Android, mais aucun template AGP/Gradle, manifest applicatif, matrice SDK ou projet réel n'existe dans PGR. Un skeleton Android serait prématuré avant ces pièces et avant la sélection explicite de sa composition avec Java/Gradle ou un autre stack réel.

Web, JNI, Tauri et autres familles absentes — différés

Ces domaines ne possèdent pas encore tous leurs propriétaires normatifs et templates nécessaires. 0.0.4 ne crée pas de profils ou skeletons placeholders pour eux.

Contrat visé pour une skeleton specification

La tranche de composition devra fixer un contrat commun minimal. Chaque skeleton doit au moins permettre d'identifier :

applicabilité et objectif
profils/règles sélectionnés
fichiers à créer, copier ou adapter
templates applicables et source de leurs choix
décisions obligatoires propres au destinataire
options et exceptions explicites
ordre de composition
validation initiale proportionnée
éléments volontairement hors scope

Un skeleton reste une procédure Markdown. Il ne génère pas le projet, ne télécharge pas de dépendances, ne remplace pas les toolchains et ne fige pas l'architecture future. Après instanciation, le projet possède ses copies locales et ses décisions.

Les règles communes de sélection et de composition doivent avoir un propriétaire normatif unique sous docs/rules/. Les spécifications concrètes vivront dans une collection documentaire dédiée créée seulement avec son premier contenu réel. Les fichiers techniques copiables restent sous templates/ et leurs instructions d'adaptation sous docs/templates/.

Découpage prévisionnel de 0.0.4

alpha.1 — audit de stable et cadrage

Vérifier indépendamment v0.0.3, le rapport post-tag, les règles 200 à 610, les cinq templates Rust/Cargo, les trois audits Markdown, les deux audits Rust facultatifs et la chaîne de deltas/histories. Inventorier les skeletons réellement justifiés et fixer le présent plan avant toute matérialisation importante.

alpha.2 — contrat de composition des skeletons

Créer le propriétaire normatif des règles de sélection et de composition des skeletons, puis la collection documentaire des skeleton specifications avec son index. Définir la frontière entre règles copiées/adaptées, templates techniques, décisions propres au projet, overrides et validation. Réconcilier les index et l'architecture sans créer encore de domaine technologique supplémentaire.

Le nom et le numéro exacts du document normatif seront choisis à l'application selon la responsabilité finale ; le plan ne transforme pas un chemin prévisionnel en règle déjà active.

alpha.3 — fondation de projet gouverné

Matérialiser une première specification composable décrivant la baseline de gouvernance locale d'un projet utilisant PGR : version, règles sélectionnées, documentation minimale, workflow réellement retenu et validation initiale. Elle doit rester proportionnée et permettre d'omettre les collections ou artefacts sans contenu réel.

Cette fondation n'est ni un framework ni une architecture applicative et ne doit pas recopier les deltas, histories ou décisions propres au dépôt PGR.

alpha.4 — skeleton Rust/Cargo workspace

Matérialiser la première specialization technologique en composant la fondation gouvernée avec 500 + 510, les cinq templates Rust/Cargo et les guides d'adaptation existants. Documenter les décisions destinataire avant copie et les audits facultatifs explicitement sélectionnés.

La gate doit inclure une instanciation temporaire minimale ou une vérification équivalente lorsque la toolchain Rust est disponible, afin de distinguer la validité syntaxique des templates de leur adoption correcte. Cette preuve ne transforme pas PGR lui-même en workspace Rust.

beta.1 — réconciliation interne

Vérifier ownership, liens, index, absence de duplication normative, non-universalisation des valeurs d'exemple, limites des audits et cohérence des deux premières specifications. Confirmer explicitement que Java/Android/Web/JNI/Tauri restent différés tant que leurs pièces requises manquent.

Aucun chantier de réconciliation complète avec KSP ou Games n'entre ici : la roadmap réserve cette mission à 0.0.5.

rc.1 — gate de release candidate

Geler le scope, préparer l'entrée 0.0.4 du changelog et le prompt 005 de 0.0.5 si la trajectoire est confirmée. Rejouer les validations documentaires, tests et smokes réellement invalidés par la release.

stable — 0.0.4

Promouvoir la RC validée, finaliser les documents vivants, produire le history pré-tag, committer et tagger v0.0.4, puis vérifier séparément l'archive publiée. La preuve post-tag reste extérieure au tag.

Points de décision et stratégie de validation

Un REPLAN devient nécessaire si la fondation gouvernée exige des templates génériques inexistants pour rester actionnable, si le contrat de composition duplique des règles existantes au lieu de les référencer, si le skeleton Rust impose une architecture plus étroite que le profil 510, ou si l'instanciation minimale révèle qu'un template technique ne peut pas être adopté sans nouvelle décision normative.

Les tranches documentaires utilisent les trois audits Markdown et les contrôles Git applicables. Toute modification des scripts ou de leurs contrats rejoue leurs tests ciblés. Toute modification d'un template Rust/Cargo vérifie sa syntaxe et, lorsqu'elle prétend à une instanciation fonctionnelle, une gate Cargo proportionnée dans un environnement temporaire. Aucun build Java/Android n'est demandé tant qu'aucun artefact concret de ces écosystèmes n'entre dans le scope.