pgr/prompts/010-V0_1_4_START_PROMPT.md

Prompt de démarrage 0.1.4 — réexamen Tauri et skeleton contrôlé

Baseline et cible

Dépôt canonique : https://git.sasedev.com/Sasedev/pgr.

La baseline attendue au démarrage effectif de 0.1.4 est l'archive source téléchargée depuis le tag Gitea v0.1.3, accompagnée du rapport post-tag pgr-0.1.3-publish.001-report.md uniquement si ce rapport a réellement été produit avec statut PASS.

Version cible : 0.1.4. Première tranche attendue : 0.1.4-alpha.1.

Les corpus principaux attendus pour réexaminer Tauri sont des archives autoritaires récentes de khadhroony-solana-project et sasedev-games. Si aucune baseline plus récente n'est explicitement fournie, les dernières baselines Tauri déjà auditées par PGR restent des références de comparaison, sans être présumées représenter l'état courant des projets :

khadhroony-solana-project-v0.3.17.zip  2a9cabcb9f147a348dcf8d24df8bc6c5029089b6d49feb17bd4a42b4293c329a
games-v0.3.6.zip                       ad6e44a1332eb7d6069cf1189d9433f0fbb8fac19c5aac9f4641ac45c1c556e8

Une archive source peut légitimement ne pas contenir .git. Ne pas lui attribuer une preuve Git qu'elle ne peut contenir.

Reprise manuelle après publication

Après vérification réelle de l'archive du tag v0.1.3 et du rapport post-tag PASS, la consigne de nouvelle session doit suivre le pattern de ../docs/templates/003-NEW_SESSION_PROMPT.md et citer les artefacts réellement obtenus.

La forme attendue, si les noms et le statut sont confirmés, est :

Partir de l'archive pgr-v0.1.3.zip téléchargée depuis le tag Gitea v0.1.3 et du rapport post-tag pgr-0.1.3-publish.001-report.md. Lire et exécuter prompts/010-V0_1_4_START_PROMPT.md. Vérifier intégralement la stable PGR et les baselines autoritaires fournies de KSP/Games avant de réexaminer le DEFER du skeleton Tauri et de préparer 0.1.4-alpha.1, sans commencer l'adoption Games réservée à 0.1.5 ni l'adoption KSP réservée à 0.1.6.

Ce texte ne doit pas être remis comme preuve de publication avant le publish.001 PASS réel.

Mission

Réexaminer objectivement la décision DEFER enregistrée dans ../docs/studies/002-TAURI_SKELETON_DECISION.md à partir des corpus Tauri réellement fournis, du profil ../docs/rules/710-TAURI.md, des owners Web stabilisés par 0.1.1, du profil Android stabilisé par 0.1.3 et des règles de skeletons.

La release 0.1.4 ne part pas du principe qu'un skeleton Tauri doit être créé. Elle doit confirmer, modifier ou abandonner le candidat historique selon les preuves courantes. Si un skeleton contrôlé est justifié, il doit sélectionner et composer des owners existants plutôt que devenir leur propriétaire implicite.

alpha.1 MUST commencer par :

1. auditer indépendamment la stable v0.1.3 et son rapport post-tag lorsqu'il est fourni ;
2. auditer les corpus KSP/Games réellement fournis et inventorier leurs hosts Tauri actuels, sans supposer que les layouts, versions ou plugins historiques sont encore représentatifs ;
3. relire 710-TAURI.md, 220-SKELETONS.md, 510-RUST_CARGO.md, 003-WEB_FRONTEND.md, les owners Web 530/540/550/560, 005-WEB_FRONTEND_VALIDATION.md, 600-PLATFORMS.md, 610-ANDROID.md, l'étude 002-TAURI_SKELETON_DECISION.md et la revue d'horizon 003 ;
4. vérifier la documentation Tauri 2 officielle courante pour les points susceptibles d'avoir évolué ;
5. créer le plan 0.1.4 avant toute matérialisation importante ;
6. classifier les choix observés avec ADOPT / KEEP-LOCAL / OVERRIDE / DEFER et décider explicitement si les conditions de sortie du report historique sont réellement satisfaites par le corpus courant.

Questions à instruire

La release doit notamment réexaminer :

• pertinence réelle d'un skeleton Tauri organisationnel pour les nouveaux projets contrôlés ;
• composition avec 001-PROJECT_GOVERNANCE_FOUNDATION, 002-RUST_CARGO_WORKSPACE et 003-WEB_FRONTEND sans duplication normative ;
• host Cargo direct versus layout src-tauri/, en distinguant convention organisationnelle et possibilité supportée par Tauri ;
• statut de frontend/, Vite, TypeScript, Sass et Bootstrap : choix éventuels du skeleton/projet, jamais obligations Tauri implicites ;
• TS-RS pour les DTO Rust/TypeScript lorsque cette frontière est réellement présente, sans le rendre universel ;
• ownership de tauri.conf.json, build.rs, capabilities/permissions, plugins, commandes et hooks frontend ;
• ajout manuel de plugins versus commandes de commodité telles que cargo tauri add, avec revue explicite des modifications générées ;
• devUrl, frontendDist, outputs/caches et séparation source/généré ;
• stratégie de version produit CANONICAL / MIRROR-EXACT / MIRROR-STABLE sans churn cérémoniel ;
• distinction entre preuves Rust, preuves frontend, tauri dev, tauri build et packaging plateforme ;
• projets mobiles générés/modifiés par Tauri et composition avec les profils Android/iOS applicables sans absorber leurs responsabilités dans 710 ;
• nécessité éventuelle de templates techniques ou d'un contrat de validation Tauri supplémentaire, uniquement si un besoin non couvert est démontré ;
• compatibilité du candidat avec plusieurs package managers et plusieurs choix frontend supportés.

Frontières obligatoires

0.1.4 MUST NOT :

• migrer KSP ou Games vers PGR ;
• créer le skeleton Tauri parce que la roadmap le mentionne ou parce que les cinq prérequis Web sont désormais couverts ;
• transformer Vite, TypeScript, Sass, Bootstrap, npm, TS-RS, frontend/ ou l'absence de src-tauri/ en obligations universelles du profil Tauri sans preuve correspondante ;
• rouvrir Android 0.1.3 sauf défaut transversal réellement démontré ;
• démarrer l'adoption Games 0.1.5 ou l'adoption KSP 0.1.6 ;
• intégrer WASM au host Tauri par défaut ;
• créer un owner serveur Rust, deployment/operations ou iOS par proximité ;
• réserver une nouvelle release au-delà de la roadmap engagée sans revue d'horizon justifiée.

Les personnalisations produit, plugins concrets, fenêtres, CSP, ports, targets de bundle, icônes, ABI et autres valeurs spécifiques aux corpus restent locales sauf invariant réutilisable démontré.

Principes

• Le skeleton doit composer des owners ; il ne remplace pas un owner manquant.
• Les conditions de sortie historiques autorisent un réexamen, pas une création automatique.
• Partir des hosts Tauri réellement présents dans les corpus courants et comparer leurs convergences/divergences.
• Vérifier les capacités officielles courantes de Tauri 2 avant de figer une convention organisationnelle.
• Maintenir une séparation claire entre host Rust, frontend Web, intégration Tauri et plateformes mobiles.
• Utiliser les toolchains propriétaires des preuves : Cargo/Rust pour Rust, toolchain frontend pour le Web, CLI Tauri pour l'orchestration Tauri et outils plateforme pour les artefacts mobiles.
• Ne pas exiger un tauri build complet lorsqu'une modification ne touche pas l'intégration ou le packaging ; inversement, ne pas assimiler un cargo check ou un build frontend isolé à une preuve Tauri complète lorsque la propriété dépend des hooks/capabilities/bundling.
• Conserver ADOPT / KEEP-LOCAL / OVERRIDE / DEFER afin de préparer les futures adoptions 0.1.5 et 0.1.6 sans les commencer.

Workflow

Suivre ../RULES.md, ../docs/rules/210-WORKFLOW.md, ../docs/rules/220-SKELETONS.md, ../docs/rules/230-ADOPTION.md et ../docs/rules/400-VALIDATION.md.

La séquence reste : delta → gate opérateur → history constaté → application du history → commit/push → delta suivant. Les commandes de handoff sont remises automatiquement conformément à ../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md.