Big changes

_Design/glossary.md

@@ -12,16 +12,15 @@ pool in a thin class instead:
 
 ```
 ResourceRegistry
- ├── meshes        Pool<Mesh, MeshHandle>
- ├── renderTargets RenderTargetPool → RenderTargetHandle
- │                 (wraps Pool; waits for the GPU on release, applies resizes)
- ├── scenes        Pool<Scene, SceneHandle>
- ├── textures      (planned)
- └── materials     (planned)
+ ├── meshPool          Pool<Mesh, MeshHandle>
+ ├── renderTargetPool  RenderTargetPool → RenderTargetHandle
+ │                     (wraps Pool; waits for the GPU on release, applies resizes)
+ ├── texturePool       (planned)
+ └── materialPool      (planned)
 ```
 
 Engine code (`Application`, `ImGuiRenderer`, `SceneRenderer`) uses the pools
-directly, e.g. `resources.renderTargets.get(handle)`.
+directly, e.g. `resources.renderTargetPool.get(handle)`.
 
 A Handle is a small (index, generation) pair. The index locates the slot in
 the pool; the generation is bumped when that slot is released, so a Handle
@@ -277,12 +276,14 @@ This is primarily a UI concept, rather than a GPU concept.
 A PanelRegistry owns Panels on the caller's behalf and hands out lightweight
 PanelHandles instead of pointers or ownership.
 
-Internally it's a generation-checked slot pool, the same shape ResourceRegistry's
-`Pool<T, Handle>` uses:
+Internally it wraps a `Pool<Panel, PanelHandle>` (the same generation-checked
+slot pool ResourceRegistry uses, in `sophia/util/pool.hpp`) and adds the
+Panel-specific parts: lookup by type or name, and the default dock layout:
 
 ```
 PanelRegistry
- └── Slot { Panel, generation }  →  PanelHandle
+ └── Pool<Panel, PanelHandle>
+      └── Slot { Panel, generation }  →  PanelHandle
 ```
 
 Typical lifecycle:
@@ -300,6 +301,34 @@ Each frame, update(frameInfo) calls onUpdate on every visible Panel it holds.
 Think: "Where do I register or look up a UI panel by handle, without owning
 its lifetime directly?"
 
+## SceneRegistry
+
+A SceneRegistry owns Scenes on the caller's behalf and hands out lightweight
+SceneHandles instead of pointers or ownership. Like PanelRegistry, it is owned
+by Application and reached from frontend code directly (`scenes()`), rather than
+through ResourceRegistryRef: scenes are CPU-side entity data, not GPU resources.
+
+Internally it wraps a `Pool<Scene, SceneHandle>`:
+
+```
+SceneRegistry
+ └── Pool<Scene, SceneHandle>
+      └── Slot { Scene, generation }  →  SceneHandle
+```
+
+Typical lifecycle:
+
+```
+create()  →  SceneHandle
+                  │
+        get(handle)  →  Scene&
+                  │
+        release(handle)
+```
+
+Think: "Where do I create or look up a Scene by handle, without owning its
+lifetime directly?"
+
 ## Sprite
 
 A Sprite is a 2D renderable representation of an image, usually a rectangular region of a texture.