pgr/docs/rules/710-TAURI.md

Profil Tauri 2

Rôle et applicabilité

Ce document possède les règles réutilisables propres à une application utilisant Tauri 2 comme host natif et orchestrateur d'intégration entre un backend Rust et un frontend WebView.

Il complète 700-FRAMEWORKS.md et 510-RUST_CARGO.md. Les profils plateforme réellement ciblés, par exemple 610-ANDROID.md, restent applicables et possèdent leurs contraintes de SDK, packaging et smoke de plateforme.

Le profil est volontairement borné à Tauri 2. Une future génération incompatible du framework doit être réévaluée avant d'hériter automatiquement de ces règles.

Composition avec le frontend

Tauri ne détermine pas à lui seul le framework frontend, le bundler ou le package manager du projet.

PGR MUST NOT imposer Vite, TypeScript, npm, pnpm, yarn, Bun, WASM ou une arborescence frontend particulière uniquement parce que Tauri est utilisé.

Le frontend peut être possédé par son propre profil ou par les règles locales du projet. Le profil Tauri possède seulement le contrat d'intégration entre ce frontend et le host natif.

Layout et fichiers possédés par Tauri

PGR MUST NOT imposer universellement un répertoire src-tauri/ ni recopier le layout d'un corpus source. Le projet peut utiliser le layout standard de Tauri ou une intégration colocalisée différente lorsque la toolchain la supporte clairement.

Les éléments suivants appartiennent néanmoins au scope Tauri lorsqu'ils existent :

• le manifeste Cargo du host natif ;
• l'intégration build-time Tauri, généralement via tauri-build ;
• la configuration Tauri supportée par la version du framework, par exemple tauri.conf.json ;
• les capability files et permissions Tauri ;
• les icônes, ressources ou métadonnées de bundle référencées par la configuration ;
• les projets ou fichiers de plateforme produits/consommés par la toolchain Tauri.

Leur emplacement exact reste une décision du projet tant qu'il est supporté par la toolchain retenue.

Ownership du build et hooks frontend

Lorsqu'une validation concerne l'intégration Tauri complète, le CLI Tauri est l'owner de l'orchestration.

Si beforeDevCommand, beforeBuildCommand ou un hook Tauri équivalent est configuré, la gate d'intégration SHOULD invoquer le CLI Tauri afin que ce hook soit exécuté dans le contexte prévu.

Ainsi :

cargo check / cargo clippy
→ preuve Rust ciblée

frontend build/test direct
→ preuve frontend ciblée

Tauri CLI dev/build
→ preuve d'orchestration Tauri + hooks correspondants

Un projet MUST NOT considérer npm run build, cargo build ou une autre sous-commande isolée comme équivalente à un build Tauri lorsque la propriété à valider dépend des hooks, de frontendDist, des capabilities, du contexte Tauri ou du bundling.

Le CLI MAY être invoqué via cargo tauri, un script du package manager frontend ou une autre forme officiellement supportée. PGR n'impose pas le package manager qui sert de lanceur.

devUrl, frontendDist et sorties frontend

devUrl et frontendDist doivent pointer vers les entrées/sorties réellement possédées par la chaîne frontend du projet.

PGR ne fixe ni port, ni nom de répertoire de distribution, ni profondeur relative universelle.

Le répertoire produit par le frontend est un artefact de build lorsqu'il est reproductible ; il SHOULD rester hors du source control sauf besoin explicite contraire. La configuration Tauri qui le référence reste, elle, source durable.

Version produit

Lorsque l'application Tauri appartient au même release train que le projet, VERSION reste la version canonique de cette unité de release.

Pour Tauri 2, une configuration qui omet la propriété applicative version peut utiliser la version du package Cargo du host. Lorsqu'un workspace PGR hérite déjà workspace.package.version, cette chaîne SHOULD être préférée si elle évite une duplication sans perdre d'information :

VERSION
↓
workspace.package.version
↓
package Cargo du host
↓
version applicative Tauri

Si une version Tauri explicite est conservée dans la configuration, elle MUST représenter la même release ou documenter clairement pourquoi elle constitue une unité indépendante.

Les numéros de version propres aux plateformes, par exemple Android versionCode, restent possédés par le profil plateforme concerné et ne sont pas assimilés au SemVer produit.

Capabilities, permissions et frontière WebView/native

Les capability files et permissions Tauri sont du source de sécurité et SHOULD être versionnés lorsqu'ils définissent intentionnellement la surface exposée au frontend.

Le projet SHOULD accorder uniquement les permissions nécessaires aux fenêtres/webviews concernées. Ajouter un plugin ou une commande native ne justifie pas automatiquement une capability globale plus large.

Les schémas générés référencés par les capability files servent à l'outillage et à la validation de configuration ; ils ne deviennent pas pour autant la source normative de la politique de permissions.

Toute permission distante, origine distante ou extension de scope sensible doit être explicitement justifiée et validée comme frontière de sécurité.

Plugins, CSP, fenêtres et bundles

PGR ne définit aucun catalogue de plugins Tauri obligatoires.

Plugins, CSP, nombre de fenêtres, labels, tailles, ports, bundle.active, targets de bundle, icônes et ressources restent des décisions du produit ou de la plateforme tant qu'aucun invariant plus général ne les impose.

Une règle locale MAY renforcer ces choix. Elle ne doit pas être remontée dans le profil Tauri uniquement parce qu'elle apparaît dans plusieurs applications d'un même projet.

Artefacts générés et projets mobiles

Les dépendances frontend téléchargées et sorties de build reproductibles, telles que node_modules/ ou le frontendDist, SHOULD rester hors Git.

PGR MUST NOT appliquer en revanche une exclusion universelle de tout répertoire gen/. Tauri peut générer des projets de plateforme qui deviennent ensuite le lieu de personnalisations Android/iOS intentionnelles. Le projet doit classifier chaque sous-arbre : reproductible/transitoire, configuration durable ou généré modifié volontairement.

Les secrets de signature, keystores, credentials et fichiers locaux restent hors Git conformément aux règles générales et aux profils plateforme applicables.

Validation proportionnée

Scope modifié	Preuve Tauri normalement pertinente	Ce que cette preuve ne remplace pas
backend Rust uniquement	gates Rust/Cargo sélectionnées	frontend, hooks, WebView ou packaging
frontend uniquement	build/tests/smoke du frontend selon son owner	host natif ou packaging Tauri
hooks, config, capabilities, IPC ou intégration	tauri dev ou équivalent + smoke ciblé	package release de plateforme
bundling, ressources ou version packagée	tauri build ou équivalent + inspection/smoke de l'artefact	exigences d'un store ou d'une plateforme non exercée
Android/iOS	commande mobile Tauri applicable + gates du profil plateforme concerné	autres plateformes

La syntaxe exacte de la commande dépend du lanceur choisi (cargo, npm, pnpm, etc.) et de la plateforme. Le delta/plan du projet doit fournir la commande concrète.

Un cargo check direct MAY rester utile pour une modification Rust ciblée, mais il ne constitue pas un smoke Tauri complet. Inversement, un full tauri build n'est pas requis lorsqu'aucune propriété d'intégration ou de packaging n'a été invalidée.

Ce que le profil n'impose pas

Ce profil ne crée pas :

• de tauri.conf.json universel ;
• de port de développement par défaut PGR ;
• de frontend Vite/WASM obligatoire ;
• de plugin obligatoire ;
• de nombre ou taille de fenêtres ;
• de politique de bundle unique ;
• de layout src-tauri/ obligatoire ;
• de version exacte de Tauri, tauri-build ou du CLI.

Ces décisions appartiennent au projet, à un profil plus spécifique ou à une future skeleton specification seulement lorsqu'une valeur réutilisable est réellement démontrée.