For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/desktop/first-feature.md (or send Accept: text/markdown).
Construire votre première fonctionnalité
Un parcours de bout en bout, d'un changement natif du shell à une fenêtre vérifiée.
Parcours pas à pas pour débuter
Prérequis : lisez les deux guides débutants ci-dessous, terminez la configuration locale Desktop et ouvrez ce dépôt à sa racine dans votre éditeur. Le shell lit SUPASTACK_APP_URL comme un paramètre de terminal au démarrage — pas depuis un fichier .env enregistré.
Termes rapides : un espace de travail est constitué des utilisateurs, des données et des paramètres distincts d'une équipe. Le serveur est le backend de confiance ; gardez les clés du fournisseur hors du code du navigateur et du téléphone. Une migration est une modification de base de données versionnée qui crée ou met à jour des tables. Un modèle d'IA est le moteur qui répond ; le catalogue de modèles est la liste du serveur des identifiants de modèles et des prix disponibles. Un fournisseur est un service externe tel qu'un service d'IA, de messagerie ou de facturation. Un droit est une subvention qui permet à un espace de travail d'utiliser une fonctionnalité. Un webhook est un message qu'un service envoie au URL d'un autre service.
1. Ouvrez .agents/skills/add-a-desktop-capability/SKILL.md — ou demandez à votre agent de codage de le suivre — et faites un petit changement natif, par exemple une nouvelle entrée du menu Affichage ou un raccourci d'appel différent.
2. Exécutez cargo check, démarrez le shell et éprouvez le changement dans la fenêtre ouverte.
3. Répétez sur chaque système d'exploitation que vous prévoyez de livrer — le comportement de la barre d'état, du raccourci et des menus diffère par plateforme.
Pour du code personnalisé, nommez le comportement, le menu ou le raccourci qu'il affecte et ce qui doit se passer sur chaque OS. Donnez cette tâche à votre agent de codage et demandez-lui de lire AGENTS.md, .ai/PROJECT_CONTEXT.md et les miroirs .ai/ des fichiers qu'il touchera ; de lister les fichiers et les vérifications avant de modifier ; et de vous montrer le diff. Utilisez des valeurs d'exemple ; ne collez jamais un vrai secret.
Décider d'abord natif ou produit
Tout ce qu'un utilisateur vit comme UI produit — écrans, données, paramètres — appartient à l'application web et arrive automatiquement dans la fenêtre. Seul le comportement au niveau OS appartient à Rust : fenêtres, barre d'état, menus, raccourcis globaux, lancement à la connexion et vérifications de mises à jour.
apps/desktop/src-tauri/src/lib.rs
apps/desktop/src-tauri/tauri.conf.json
apps/desktop/src-tauri/capabilities/default.jsonGarder le sandbox de la webview étroit
La webview ne peut appeler que ce que capabilities/default.json liste. Un changement nécessitant un nouveau plugin ajoute la crate dans Cargo.toml, l'enregistre dans lib.rs et accorde la permission minimale dans capabilities — jamais de joker.
L'état persistant du shell — position de la fenêtre, zoom, canal de mise à jour, préférences de fenêtre — vit dans le répertoire de données de l'application via les sidecars livrés, pas dans des fichiers que vous gérez à la main.
Vérifier sur chaque OS cible
Exécutez cargo test, puis une vraie fenêtre sous Windows, macOS et Linux : restauration de l'état de la fenêtre, fermeture vers la barre d'état, focus d'instance unique et le raccourci d'appel avec votre changement actif. Un OS qui passe ne prouve pas les deux autres.