spec OKF pour doc

docs/PLAN.md

@@ -1,6 +1,15 @@
+---
+type: Plan
+title: Implementation Plan for wsg_lib Engine Consolidation and Finalization
+description: Implementation plan defining priority steps to finalize the current architecture, making the API intuitive for standard users while maintaining power for advanced users
+tags: [plan, implementation, roadmap, development, wsg-lib]
+status: stable
+generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
+---
+
 # Plan d'Implémentation : Consolidation et Finalisation du Moteur wsg_lib
 
-Ce plan définit les étapes prioritaires pour stabiliser l'architecture actuelle. L'objectif est de rendre l'API intuitive pour l'utilisateur standard tout en conservant la puissance de contrôle pour l'utilisateur avancé.
+Ce plan définit les étapes prioritaires pour finaliser l'architecture actuelle. L'objectif est de rendre l'API intuitive pour l'utilisateur standard tout en conservant la puissance de contrôle pour l'utilisateur avancé.
 
 ## Phase 1 : Finalisation et Nettoyage de l'Existant (Priorité Absolue)
 
@@ -8,20 +17,20 @@ Cette phase vise à supprimer la dette technique et à unifier les accès.
 
 ### Uniformisation des Modules
 
-- Vérifier que tous les traits (`AppHandler`) et structures (`App`, `Context`) sont explicitement marqués `pub` dans leurs fichiers sources.
-- Ré-exporter l'API dans `lib.rs` pour permettre des imports simplifiés (ex : `use wsg_lib::{App, AppHandler}`).
-- Nettoyer les accès internes pour que l'utilisateur n'ait pas à importer les modules système (`core`, `pipeline`) sauf besoin spécifique.
+- [X] Vérifier que tous les traits (`AppHandler`) et structures (`App`, `Context`) sont explicitement marqués `pub` dans leurs fichiers sources.
+- [X] Ré-exporter l'API dans `lib.rs` pour permettre des imports simplifiés (ex : `use wsg_lib::{App, AppHandler}`).
+- [X] Nettoyer les accès internes pour que l'utilisateur n'ait pas à importer les modules système (`core`, `pipeline`) sauf besoin spécifique.
 
 ### Abstraction de la Boucle (`App::run`)
 
-- Déplacer la gestion de `winit::event_loop` et des `Frame` à l'intérieur de la méthode `run()` de `App`.
-- Garantir que le trait `AppHandler` reçoit une référence à `App` permettant d'appeler `app.renderer` ou `app.scene`.
-- Supprimer toute gestion de `Frame` ou `EventLoop` manuelle des exemples utilisateurs (`simple.rs`).
+- [X] Déplacer la gestion de `winit::event_loop` et des `Frame` à l'intérieur de la méthode `run()` de `App`.
+- [X] Garantir que le trait `AppHandler` reçoit une référence à `App` permettant d'appeler `app.renderer` ou `app.scene`.
+- [X] Supprimer toute gestion de `Frame` ou `EventLoop` manuelle des exemples utilisateurs (`simple.rs`).
 
 ### Correction du Builder et Initialisation
 
-- Standardiser la création de `App` via un `AppBuilder` robuste.
-- Gérer les `dev-dependencies` dans `lib/Cargo.toml` (notamment `pollster` avec la feature `macro`) pour permettre la compilation des exemples sans polluer les dépendances finales de la librairie.
+- [X] Standardiser la création de `App` via un `AppBuilder` robuste.
+- [X] Gérer les `dev-dependencies` dans `lib/Cargo.toml` (notamment `pollster` avec la feature `macro`) pour permettre la compilation des exemples sans polluer les dépendances finales de la librairie.
 
 ## Phase 2 : Structure de Rendu et Scène
 
@@ -29,39 +38,39 @@ Une fois la plomberie encapsulée, nous devons rendre l'assemblage des objets co
 
 ### Intégration de la Scene
 
-- Formaliser la structure `Scene` : un conteneur qui liste les Entities.
-- Associer le `PipelineCache` à la Scene pour que le rendu des matériaux soit automatique.
-- Implémenter la logique `app.render(scene)` : cette méthode doit parcourir la scène, récupérer les matériaux, gérer les pipelines via le cache, et soumettre les draw calls.
+- [X] Formaliser la structure `Scene` : un conteneur qui liste les Entities.
+- [X] Associer le `PipelineCache` à la Scene pour que le rendu des matériaux soit automatique.
+- [X] Implémenter la logique `app.render(scene)` : cette méthode doit parcourir la scène, récupérer les matériaux, gérer les pipelines via le cache, et soumettre les draw calls.
 
 ### Gestion des Matériaux et Shaders
 
-- S'assurer que chaque Mesh possède une référence vers un Material.
-- Implémenter le comportement par défaut : si aucun matériau n'est assigné, le moteur injecte automatiquement le `basic_shader`.
+- [X] S'assurer que chaque Mesh possède une référence vers un Material.
+- [X] Implémenter le comportement par défaut : si aucun matériau n'est assigné, le moteur injecte automatiquement le `basic_shader`.
 
 ## Phase 3 : Documentation et Interface (API "User-Friendly")
 
 ### Refonte des Exemples
 
-- `simple.rs` doit devenir le modèle : **15 lignes** de code, pas de manipulation WGPU explicite.
-- `manual.rs` doit rester disponible en tant que tutoriel pour ceux qui veulent contourner l'abstraction App.
+- [X] `simple.rs` doit devenir le modèle : **15 lignes** de code, pas de manipulation WGPU explicite.
+- [X] `manual.rs` doit rester disponible en tant que tutoriel pour ceux qui veulent contourner l'abstraction App.
 
 ### Nettoyage du Code Interne
 
-- Vérifier les durées de vie (lifetimes) et les Arc pour s'assurer qu'aucune fuite mémoire ou accès concurrentiel invalide ne survient lors des changements de frame.
+- [X] Vérifier les durées de vie (lifetimes) et les Arc pour s'assurer qu'aucune fuite mémoire ou accès concurrentiel invalide ne survient lors des changements de frame.
 
 ## Phase 4 : Nouvelles Fonctionnalités (Planification Future)
 
 Une fois les phases 1 à 3 validées, nous pourrons introduire :
 
-- **Système de Lumières** : Ajout de buffers d'uniformes dans le PipelineCache.
-- **Textures** : Intégration d'un module de chargement d'images et de BindGroups.
-- **Caméras** : Gestion des matrices de projection/vue dans la Scene.
+- [ ] **Système de Lumières** : Ajout de buffers d'uniformes dans le PipelineCache.
+- [ ] **Textures** : Intégration d'un module de chargement d'images et de BindGroups.
+- [ ] **Caméras** : Gestion des matrices de projection/vue dans la Scene.
 
 ## Check-list de Vérification pour le LLM d'Assistance
 
-- [ ] Est-ce que `simple.rs` compile sans importer `winit` ou `wgpu` ?
-- [ ] Est-ce que `App::run` gère bien le cycle update → render → present ?
-- [ ] Les modules sont-ils bien exposés via `lib.rs` ?
-- [ ] `pollster` est-il uniquement en dev-dependencies ?
+- [X] Est-ce que `simple.rs` compile sans importer `winit` ou `wgpu` ?
+- [X] Est-ce que `App::run` gère bien le cycle update → render → present ?
+- [X] Les modules sont-ils bien exposés via `lib.rs` ?
+- [X] `pollster` est-il uniquement en dev-dependencies ?
 
 Ce plan garantit que les fondations sont saines. Une fois la Scene rendue automatiquement par `app.render()`, l'ajout de toute nouvelle fonctionnalité (lumières, textures) deviendra une simple question d'ajout de données dans la structure de scène, sans modification de la boucle de rendu.