# Delta 0.1.4-pre.001-fix.003 — provenance Gitea et gabarit Tauri/frontend final ## Base requise ```text 0.1.4-pre.001-fix.002 workspace.package.version = "0.1.4-pre.1" ``` Ce troisième correctif reste exclusivement documentaire. Il finalise le plan de `pre.001` avant son approbation et n'ouvre pas `pre.002`. Les deltas historiques : ```text deltas/0.1.4/pre.001.md deltas/0.1.4/pre.001-fix.001.md deltas/0.1.4/pre.001-fix.002.md ``` restent inchangés. ## 1. Provenance des archives stables KSP La réserve précédente sur l'absence de métadonnées `.git` dans `khadhroony-solana-project-v0.1.3.zip` est retirée du plan. Les archives KSP fournies comme bases de session sont les archives source **générées automatiquement par Gitea à partir du tag concerné**, et non des ZIP fabriqués manuellement depuis un workspace local. Leur nom reprend le tag/version de la release. Le plan traite donc `khadhroony-solana-project-v0.1.3.zip` comme l'export matériel normal du tag stable `v0.1.3`. L'absence du répertoire `.git` à l'intérieur de l'archive est attendue pour ce mode de distribution et n'est plus présentée comme une impossibilité de valider la provenance de la base. Cette règle de lecture s'applique également aux futures archives de tags KSP fournies pour ouvrir une nouvelle session/version. ## 2. Gabarit frontend : SimpleBar et resize observer conservés Le plan corrige l'audit bot3 : - `simplebar` fait partie du gabarit frontend KSP ; - `resize-observer-polyfill` fait partie du gabarit frontend KSP ; - ils sont introduits avec le squelette frontend, pas reportés comme dépendances propres aux démos. SimpleBar fournit le scrolling applicatif retenu pour une expérience plus confortable/cohérente que les scrollbars WebKitGTK par défaut. Le resize observer participe à la robustesse des composants/layouts lorsqu'ils doivent réagir aux changements de dimensions. Le découpage candidat de `pre.005` est mis à jour en conséquence. ## 3. DataTables : conditionnel au premier tableau interactif, mais attendu DataTables n'est pas requis pour construire un squelette qui ne contient encore aucun tableau fonctionnel. Il ne doit cependant pas être considéré comme une dépendance bot3 écartée de Config Desk. Dès qu'un tableau HTML de l'application nécessite une ou plusieurs capacités telles que : - tri ; - filtrage/recherche ; - sélection ; - cases à cocher ; - pagination ou interactions tabulaires structurées ; la tranche concernée doit introduire DataTables plutôt que réimplémenter ces fonctions manuellement. Le couple utilisé dans bot3 : ```text datatables.net-bs5 datatables.net-select-bs5 ``` reste la référence à réauditer au moment de sa première introduction dans KSP. Le plan signale les panneaux Documents/Environnement comme premiers emplacements possibles selon l'UX réellement construite. ## 4. Construction de `tauri::Builder` Le contrat `tauri.rs` est précisé : `run` ne doit pas devenir une longue chaîne monolithique de calls builder. La direction retenue est conceptuellement : ```text let mut builder = tauri::Builder::default(); builder = configure_tracing(builder, ...); builder = configure_state(builder, ...); builder = configure_plugins(builder, ...); builder = configure_setup(builder, ...); builder = configure_commands(builder, ...); ``` Les signatures finales dépendront des APIs Tauri réellement utilisées, mais l'organisation doit conserver des étapes courtes et indépendantes. Cela permet notamment de commenter/désactiver temporairement un plugin, un bloc de setup ou un groupe de commandes sans restructurer toute la fonction `run`. Les règles KSP existantes restent inchangées : retours explicites, pas de `?`, `unwrap`, `expect` ou `panic`, wrappers `#[tauri::command]` uniquement dans `tauri.rs`. ## 5. Tableaux Markdown Les tableaux Markdown du plan sont conservés/normalisés sous forme alignée pour faciliter la relecture du document source. Cette modification est purement documentaire et ne change pas leur contenu fonctionnel. ## 6. Découpage souple Le budget cible reste **environ 15–20 minutes de travail effectif par prerelease**. Les ajustements de ce fix ne changent pas le principe du découpage : - `pre.004` porte la convention builder Tauri en étapes courtes ; - `pre.005` introduit SimpleBar et `resize-observer-polyfill` avec le gabarit frontend ; - DataTables est ajouté dans la première tranche de panneau qui en a réellement besoin (`pre.009`, `pre.011` ou une tranche issue d'une scission), plutôt que prématurément au squelette. Les prereleases restent scindables, fusionnables ou réordonnables si le budget réel l'exige. ## Fichier modifié ```text docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md ``` Le header du plan passe de `version: 3` à `version: 4`. ## Fichier ajouté ```text deltas/0.1.4/pre.001-fix.003.md ``` ## Version Cargo Aucune modification de `Cargo.toml`. Le correctif est documentaire uniquement ; `workspace.package.version` reste : ```text 0.1.4-pre.1 ``` L'identifiant de livraison est : ```text 0.1.4-pre.001-fix.003 ``` ## Validations du correctif À contrôler avant livraison : - header `file:` / `version:` des deux fichiers ; - plan en `version: 4` ; - absence de modification de `Cargo.toml` ; - absence de modification des trois deltas historiques `pre.001`, `pre.001-fix.001`, `pre.001-fix.002` ; - provenance Gitea/tag stable explicitement décrite sans réserve `.git` inadaptée ; - SimpleBar et `resize-observer-polyfill` présents dans le gabarit frontend ; - DataTables prévu dès le premier besoin tabulaire interactif, mais non ajouté prématurément ; - `tauri::Builder` organisé en étapes courtes/réassignées et non en chaîne monolithique ; - tableaux Markdown alignés ; - découpage souple ~15–20 minutes maintenu ; - équilibre des fences Markdown ; - archive limitée au plan modifié et au nouveau delta. Aucune commande Cargo n'est requise spécifiquement pour ce correctif documentaire. Les validations Cargo globales restent celles prévues au passage aux tranches de développement et à la clôture de la release.