docs: record completed scene auto-render step in plan, roadmap, README

README.md

@@ -9,8 +9,8 @@ WSG is a Rust library that wraps [wgpu](https://github.com/gfx-rs/wgpu) and [win
 | Area | State |
 |------|-------|
 | Manual workflow (`Context` + `Renderer` + `PipelineCache`) | ✅ Working |
-| `App` / `AppBuilder` / `AppHandler` event-loop facade | 🚧 Scaffold — window, events and frame presentation work, but the `render()` callback cannot draw yet (the per-frame view is not exposed to it) |
-| `Scene` resource/entity registry | 🚧 Registration API works; the engine does not render the scene yet |
+| `App` / `AppBuilder` / `AppHandler` event-loop facade | ✅ Working — window, events, frame presentation, and **automatic scene rendering** (the per-frame view is exposed via `Frame::view()`) |
+| `Scene` resource/entity registry | ✅ Working — the engine renders every registered entity automatically in one batched render pass (`App::render_scene`) |
 | GPU-driven two-pass pipeline (Compute → indirect draw) | 📋 Roadmap — spec in [docs/tech/ARCHI_CPU_GPU.md](docs/tech/ARCHI_CPU_GPU.md) |
 | 3D transforms (MVP uniforms, camera in the pipeline) | 📋 Roadmap — the bundled shader draws positions straight to NDC today |
 
@@ -83,21 +83,19 @@ struct MyGame;
 
 impl AppHandler for MyGame {
     // update() has an empty default — implement it to mutate scene state each frame.
-    fn render(&mut self, _app: &mut App) {
-        // The engine acquires and presents the frame around this callback,
-        // but scene rendering is not automated yet — see Roadmap.
-    }
+    // render(app, frame) has a default that draws the whole scene automatically via
+    // app.render_scene(frame.view()). You don't need to implement it for the common case.
 }
 
 #[pollster::main]
 async fn main() -> Result<(), wsg_lib::utils::WsgError> {
     let app = AppBuilder::new().build().await?;
 
-    // Scene registration is available (string IDs):
+    // Register your scene once (string IDs), then App renders it automatically each frame:
+    //   app.cache.register_shader("basic", wsg_lib::utils::BASIC_SHADER_PATH)?;
     //   app.scene.add_mesh("quad", Arc::new(mesh))?;
-    //   app.scene.add_material("mat", Arc::new(material))?;
+    //   app.scene.add_material("mat", Arc::new(Material::new(app.renderer.format(), "basic", &mut app.cache)))?;
     //   app.scene.add_entity("my_quad", "quad", "mat")?;
-    // ...but the engine will not draw them until the declarative pipeline lands.
 
     app.run(MyGame)
 }

docs/PLAN.md

@@ -11,11 +11,11 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
 
 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é.
 
-> **Statut réel (à jour au 2026-09-14).** Ce plan couvre la phase de *consolidation* passée ; la source
-> de vérité sur l'état actuel est **README.md** et le code. Plusieurs cases `[X]` ci-dessous ont été
-> re-corrigées car elles ne reflétaient plus la réalité : notamment le rendu de la `Scene` n'est
-> **pas automatisé** (items Phase 2 et Check-list concernés). Depuis, `simple.rs` a été mis en
-> conformité (API `AppBuilder`, ~15 lignes, compilation sans importer `winit`/`wgpu`).
+> **Statut réel (à jour au 2026-09-16).** Ce plan couvre la phase de *consolidation* passée ; la source
+> de vérité sur l'état actuel est **README.md** et le code. Depuis la révision du 2026-09-14, l'étape
+> **« Scene auto-render »** a été réalisée : le rendu de la `Scene` est **automatisé** en une seule
+> passe groupée via `App::render_scene(frame.view())` (appelée par défaut dans `AppHandler::render`),
+> et `simple.rs` (API `AppBuilder`, sans `winit`/`wgpu`) déclare un quad rendu automatiquement.
 
 ## Phase 1 : Finalisation et Nettoyage de l'Existant (Priorité Absolue)
 
@@ -46,7 +46,11 @@ Une fois la plomberie encapsulée, nous devons rendre l'assemblage des objets co
 
 - [X] Formaliser la structure `Scene` : un conteneur qui liste les Entities.
 - [ ] Associer le `PipelineCache` à la Scene pour que le rendu des matériaux soit automatique (actuellement le cache est porté par `App`, indépendant de la Scene ; le rendu n'est pas automatisé).
-- [ ] 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 (non implémenté — cf. README, étape 1 du Roadmap : scene auto-rendering).
+- [X] Implémenter la logique de rendu de la scène : `App::render_scene(view)` parcourt la scène,
+  récupère les matériaux et soumet tous les draw calls en **une seule passe groupée**
+  (`Renderer::render_scene`), appelée automatiquement chaque frame par l'implémentation par défaut
+  de `AppHandler::render` (Scene auto-render — réalisé 2026-09-16). Reste à brancher : associé au
+  `PipelineCache` porté par la `Scene` (cf. ligne précédente).
 
 ### Gestion des Matériaux et Shaders
 
@@ -75,7 +79,9 @@ Une fois les phases 1 à 3 validées, nous pourrons introduire :
 ## Check-list de Vérification pour le LLM d'Assistance
 
 - [X] Est-ce que `simple.rs` compile sans importer `winit` ou `wgpu` ? (oui — modèle 15 lignes, API `AppBuilder`)
-- [ ] Est-ce que `App::run` gère bien le cycle update → render → present ? (boucle + présentation OK, mais `render()` ne peut pas encore dessiner — vue de frame non exposée)
+- [X] Est-ce que `App::run` gère bien le cycle update → render → present ? (oui — la vue de frame est
+  exposée via `Frame::view()`, `render()` dessine la scène automatiquement en une passe via
+  `App::render_scene(frame.view())`, la présentation est faite par `App::run`)
 - [X] Les modules sont-ils bien exposés via `lib.rs` ?
 - [X] `pollster` est-il uniquement en dev-dependencies ?
 

docs/ROADMAP.md

@@ -12,14 +12,25 @@ generated: { by: human:jerome, at: 2026-07-31T00:00:00Z }
 > Basé sur l'architecture existante (ARCHI_APP, ARCHI_ARENES, ARCHI_CPU_GPU, ARCHI_RENDU).
 > Objectif : prototype fonctionnel d'abord, enrichissement progressif ensuite.
 >
-> **Point de départ (état réel au 2026-09-14 — la source de vérité est README.md).**
+> **Point de départ (état réel au 2026-09-16 — la source de vérité est README.md).**
 > Les fondations suivantes existent et fonctionnent déjà ; cette roadmap décrit la **trajectoire à
 > venir** à partir de cet état (elle reprend les étapes 1-4 du README avant la montée GPU-driven) :
 > - Workflow manuel (`Context` + `Renderer` + `PipelineCache`) : ✅ fonctionnel (exemple `manual`).
-> - Façade `App` / `AppBuilder` / `AppHandler` : 🚧 scaffold — boucle et présentation OK, mais `render()` ne peut pas encore dessiner (vue de frame non exposée) et le rendu de la scène n'est pas automatisé.
+> - Façade `App` / `AppBuilder` / `AppHandler` : ✅ **Scene auto-render** (2026-09-16) — la vue de frame
+>   est exposée (`Frame::view()`), `render()` dessine la scène en une passe groupée
+>   (`App::render_scene`) et la présentation est automatique dans `App::run` (exemple `simple`).
 > - `Scene` avec identifiants **String** (décision prise — voir tableau Notes de Décision) : 🚧 enregistrement seul.
 > - `Camera` / `Transform` et `glam` : types et mathématiques présents (`math/`, `resources/camera.rs`), non branchés au pipeline.
 
+> **Étape suivante (prochaine itération) — « 3D + éclairage Phong » (ROADMAP 1.3 + 1.5).**
+> Le rendu automatique est aujourd'hui **plat** : le `basic_shader.wgsl` interprète les positions comme
+> déjà en NDC, sans matrice monde/vue/projection ni lumière. L'étape suivante rend la scène réellement
+> 3D et éclairée : créer `standard_shader.wgsl` (Phong : matrice `projection * view * world` + lumière
+> directionnelle), ajouter les uniform buffers (frame : view/proj/light ; par mesh : world matrix dérivée
+> du `Transform`) et les brancher dans `Renderer::render_scene` et `Material`, puis exposer `Camera`/
+> `Transform` à la `Scene` (caméra active) et ajouter un mesh de test (cube) à l'exemple. Objectif MVP :
+> **un mesh 3D éclairé à l'écran**.
+
 ---
 
 ## Phase 1️⃣ — Prototype MVP : Un Mesh 3D éclairé à l'écran