0.0.5-alpha.6.fix.1

docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md

@@ -1,5 +1,5 @@
 <!-- file: docs/plans/005-V0_0_5_RECONCILIATION_PLAN.md -->
-<!-- version: 5 -->
+<!-- version: 6 -->
 
 # Plan 0.0.5 — réconciliation réelle avec KSP et sasedev-games
 
@@ -96,13 +96,23 @@ Cette tranche ne réimporte pas `audit_rust_general_rules.py` en bloc et ne réi
 
 La preuve commune est confirmée : `6` applications Tauri KSP et `2` applications Tauri Games partagent Tauri 2, un host Rust/Cargo, `tauri-build`, `tauri.conf.json`, des capability files, des hooks frontend et un `frontendDist`. Les valeurs applicatives divergent suffisamment pour exclure toute copie de ports, fenêtres, CSP, bundles, plugins ou commandes frontend particulières.
 
-La tranche active `700-FRAMEWORKS.md` et `710-TAURI.md`. Le profil Tauri possède l'orchestration du build/intégration, la configuration et les capabilities, la relation de version produit et la sélection des gates Tauri. Il impose qu'une preuve d'intégration passe par le CLI Tauri lorsque la propriété dépend de ses hooks ou de son bundling ; `cargo check` et le build frontend direct restent des preuves ciblées, pas des substituts.
+La première livraison active `700-FRAMEWORKS.md` et `710-TAURI.md`, mais la gate opérateur est `FAIL` pour deux raisons : le contrôle Python ciblé du delta contient une chaîne multilignes invalide et la revue fonctionnelle exige de mieux distinguer le profil Tauri universel des conventions d'instanciation des projets contrôlés. `alpha.6.fix.1` corrige donc le gate et explicite que le host Tauri hérite intégralement des règles Rust sélectionnées, que WASM reste normalement une unité séparée et que l'ajout manuel de plugins à partir de leur documentation officielle est une stratégie valide.
 
-Vite/Web/WASM et le package manager frontend ne deviennent pas des profils implicites. La politique `gen/` n'est pas généralisée : les sorties purement reproductibles restent générées, mais les projets mobiles modifiés intentionnellement doivent être classifiés selon leur rôle réel.
+Les préférences récurrentes de l'organisation — frontend sous `frontend/`, Vite, TypeScript, Sass, Bootstrap et contrôle explicite des dépendances — sont consignées comme **candidat de skeleton**, pas comme invariants de `710-TAURI.md`. Un projet imposé de l'extérieur peut conserver une structure différente via ses règles project-specific.
 
-### alpha.7 — décision de skeleton Tauri
+La politique `gen/` n'est pas généralisée : les sorties purement reproductibles restent générées, mais les projets mobiles modifiés intentionnellement doivent être classifiés selon leur rôle réel. L'échec du POC Tauri mobile Games ne constitue pas un rejet général de Tauri Android/iOS pour les autres produits.
 
-Vérifier si le profil Tauri obtenu permet une skeleton specification utile sans créer de `tauri.conf.json` universel. Si oui, ajouter une specialization composable au-dessus de `001 + 002 + 700/710`. Sinon, consigner explicitement le report et ne pas matérialiser un skeleton décoratif.
+### alpha.7 — complétude du profil Rust strict
+
+La clarification Tauri réexpose une divergence déjà visible dans l'historique de conception : le profil Rust strict retenu pour les projets contrôlés prévoit notamment l'absence de `use` non-trait, les chemins explicites les plus courts, les réexports `use self::...`, les blocs homogènes par type/visibilité, l'ordre alphabétique des blocs monolignes et la séparation des blocs, alors que `510-RUST_CARGO.md` reste partiellement plus permissif.
+
+Cette tranche doit réconcilier les décisions historiques avec KSP/Games, attribuer chaque propriété au bon owner (`rustfmt`, Clippy, audit existant ou nouvel audit monotâche) et n'automatiser que ce qui peut être contrôlé de façon fiable. Elle ne doit pas réimporter `audit_rust_general_rules.py` en bloc.
+
+### alpha.8 — décision de skeleton Tauri pour projets contrôlés
+
+Vérifier si le profil Tauri obtenu et les owners Web disponibles permettent une skeleton specification utile pour les projets que l'organisation contrôle. Le candidat à évaluer utilise `frontend/`, Vite, TypeScript, Sass et Bootstrap, conserve WASM dans une unité séparée par défaut et privilégie l'ajout explicite des plugins à partir de leur documentation plutôt qu'une commande opaque.
+
+Si les profils Web nécessaires ne sont pas encore assez matérialisés pour posséder proprement ces choix, consigner explicitement le report au lieu de fabriquer un skeleton décoratif ou de faire de `710-TAURI.md` un owner Web de substitution.
 
 ### beta.1 — réconciliation intégrée
 
@@ -150,8 +160,9 @@ Un REPLAN est requis si :
 - le lifecycle de clôture impose des documents ou versions futures sans valeur opérationnelle ;
 - la revue d'horizon devient un quota de versions à prévoir plutôt qu'un mécanisme de décision ;
 - l'audit de façade Rust ne peut pas être séparé proprement des conventions strictes KSP/Games ;
-- le profil Tauri exige de choisir arbitrairement Vite, WASM, des plugins ou un layout d'application ;
-- le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework ;
+- le profil Tauri universel absorbe des choix de skeleton/frontend qui devraient rester project-specific ou appartenir à un owner Web ;
+- la réconciliation Rust stricte ne peut pas être séparée en owners fiables et audits monotâches ;
+- le skeleton Tauri n'apporte pas de décisions réutilisables au-delà du profil framework et des conventions explicites de projets contrôlés ;
 - une autre divergence des corpus apparaît comme un besoin commun critique non couvert par ce plan.
 
 ## Stratégie de validation