The Great Registry Refactoring 🛡️
Im Laufe der Zeit sammelt Software technische Schulden an. In KnotenCore war die Datei registry.rs zu einem 1.600 Zeilen starken Monolithen herangewachsen, der von der WGPU-Mesh-Generierung bis zur AABB-Kollisionserkennung alles steuerte. Sprint 184 und 185 haben das geändert. Willkommen zum Great Registry Refactoring.
🔪 Den Monolithen zerteilen
Die zentrale FFI (Foreign Function Interface) Registry wurde chirurgisch in vier fokussierte Module mit exakt einer Verantwortung zerlegt:
geometry.rs: Kümmert sich um das VRAM-Caching (`CachedMesh`) und dynamische Geometrie (Würfel, Sphären, Zylinder).physics.rs: Übernimmt diePHYSICS_WORLD, das Spatial-Partitioning, AABB-Kollisionen und Screen-to-World Raycasting.scene.rs: Verwaltet den Retained-Mode Scene Graph (`SceneEntity`, `SceneLight`), Kamera-UBO-Updates und den Spawn-Lifecycle.registry.rs: Fungiert jetzt nur noch als High-Level Orchestrator für Window-Proxies, OS-Input und das streng limitierte File/Network I/O.
🧹 FFI Konsolidierung
Neben der strukturellen Modularität gab es eine kompromisslose API-Bereinigung. Redundante FFI-Funktionen wie registry_read_file und registry_write_file wurden restlos eliminiert. Alle Dateizugriffe laufen jetzt ausschließlich über das extrem sichere fs-Modul (file_read und file_write), welches strikte Pfad-Validierungen und Berechtigungs-Checks (--allow-read, --allow-write) erzwingt. Der globale Geometrie-Cache (SENT_MESHES) wurde komplett aus dem Kernel entfernt und sicher in scene.rs isoliert.
🔒 Eine gehärtete Sandbox
Das Refactoring hat den Code nicht nur organisiert, es hat ihn auch fundamental gesichert. Das Laden von Texturen (registry_load_texture) nutzt nun unser einheitliches ffi_safety::validate_fs_path Framework, bevor auch nur ein einziges Byte die Festplatte berührt. Jede OS-Interaktion eines `.nod`-Skripts ist mathematisch eingegrenzt und wird sicher geroutet – ein weiterer Meilenstein für KnotenCore als Zero-Trust, deterministische KI-Laufzeitumgebung.