pgr/docs/skeletons/000-README.md

Index des skeleton specifications PGR

Cette collection contient les recettes Markdown utilisées pour initialiser des baselines de projet ou composer plusieurs profils PGR sans transformer PGR en générateur.

Le contrat normatif commun des skeletons appartient à ../rules/220-SKELETONS.md. Le modèle de composition des profils reste défini par ../architecture/003-RULE_PROFILE_MODEL.md.

Rôle de la collection

Chaque specification concrète doit décrire un besoin réel et actionnable. Elle sélectionne les owners normatifs et templates nécessaires, rend visibles les décisions propres au projet, définit l'ordre de composition utile et fournit une validation initiale proportionnée.

Les fichiers techniques copiables ne vivent pas ici : ils restent sous templates/. Leurs guides d'adaptation restent sous docs/templates/. Les règles restent sous docs/rules/.

Une specification peut se composer avec une fondation plus générale, mais la collection ne duplique pas artificiellement une recette pour chaque combinaison possible de technologies.

Specifications actives

• 001-PROJECT_GOVERNANCE_FOUNDATION.md — fondation composable pour établir la gouvernance locale, la version, la documentation minimale, le workflow retenu et sa validation initiale sans imposer d'architecture applicative.
• 002-RUST_CARGO_WORKSPACE.md — specialization composable d'un workspace Rust/Cargo fondée sur 001, les profils 500 + 510, les cinq templates Rust/Cargo et une validation réelle de la toolchain.
• 003-WEB_FRONTEND.md — specialization composable d'un frontend Web contrôlé fondée sur les owners 530/540/550/560, avec TypeScript/Vite recommandés, Sass conditionnel et validation indépendante du host.

Pour un projet existant, ces specifications servent de références de comparaison et non de recettes à recopier aveuglément. Le chemin canonique passe alors par ../rules/230-ADOPTION.md et son mapping ADOPT / KEEP-LOCAL / OVERRIDE / DEFER.

Les familles Java/Android, JNI et autres domaines sans pièces suffisantes restent différées tant que leurs owners normatifs et artefacts d'instanciation ne permettent pas une baseline réellement actionnable.

Le skeleton Web 003 est matérialisé en 0.1.1-alpha.5 parce que les owners 530/540/550/560, les guides d'adaptation et la validation frontend indépendante du host permettent désormais une composition sans ownership caché. Il ne fixe ni npm, ni Vite/Sass comme obligations, ni Bootstrap, ni un layout frontend/ universel.

Le skeleton Tauri a fait l'objet d'une décision explicite en 0.0.5-alpha.9 : son host Rust/Tauri est cadré par 510 et 710, mais sa promotion avait été différée tant que les owners Web nécessaires n'existaient pas. La décision DEFER et ses conditions de sortie restent enregistrées dans ../studies/002-TAURI_SKELETON_DECISION.md.

La création du skeleton Web ne lève pas automatiquement ce DEFER. 0.1.1-beta.1 doit encore réconcilier objectivement les conditions de sortie avant que 0.1.4 ne réexamine un éventuel skeleton Tauri, qui devra composer les owners Web au lieu de posséder leurs règles.

Aucun fichier placeholder ne doit être ajouté pour réserver un skeleton futur.