# 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 : ```text 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`](../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 : ```text 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`](../docs/studies/002-TAURI_SKELETON_DECISION.md) à partir des corpus Tauri réellement fournis, du profil [`../docs/rules/710-TAURI.md`](../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`](../RULES.md), [`../docs/rules/210-WORKFLOW.md`](../docs/rules/210-WORKFLOW.md), [`../docs/rules/220-SKELETONS.md`](../docs/rules/220-SKELETONS.md), [`../docs/rules/230-ADOPTION.md`](../docs/rules/230-ADOPTION.md) et [`../docs/rules/400-VALIDATION.md`](../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`](../docs/templates/006-OPERATOR_COMMAND_HANDOFF.md).