khadhroony-solana-project/deltas/0.1.4/pre.001-fix.003.md

Delta 0.1.4-pre.001-fix.003 — provenance Gitea et gabarit Tauri/frontend final

Base requise

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 :

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 :

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 :

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é

docs/plans/006-V0_1_4_CONFIG_DESKTOP_PLAN.md

Le header du plan passe de version: 3 à version: 4.

Fichier ajouté

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 :

0.1.4-pre.1

L'identifiant de livraison est :

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.