diff --git a/AUDIT_CLIENT_RENDERING.md b/AUDIT_CLIENT_RENDERING.md
new file mode 100644
index 00000000..2d654298
--- /dev/null
+++ b/AUDIT_CLIENT_RENDERING.md
@@ -0,0 +1,408 @@
+# Client Rendering & Chunk Mesh Audit
+
+Scope: `client/src/core/`, `client/src/chunks/`, `client/src/blocks/`, `client/src/workers/`, `client/src/gltf/`, `client/src/three/`
+
+Rating scale — Benefit 1-5 (higher = more impactful), Risk 1-5 (higher = riskier), Effort 1-5 (higher = more work).
+
+Findings sorted by Benefit descending, then Effort ascending.
+
+---
+
+## 1. PERFORMANCE — No greedy meshing in ChunkWorker
+
+**File:** `client/src/workers/ChunkWorker.ts` (mesh building loop ~lines 900-1200)
+
+Each visible block face emits 4 vertices and 6 indices individually. Adjacent coplanar faces with identical texture, AO, and light values are never merged. For a flat wall of 16x16 identical blocks, 256 quads are emitted instead of 1. This multiplies vertex count, index count, GPU draw bandwidth, and vertex shader invocations.
+
+Greedy meshing (Mikola Lysenko's algorithm) merges coplanar same-attribute faces into larger quads. Typical voxel engines see 5-15x vertex reduction on terrain.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 5 | 3 | 5 | No | Yes |
+
+---
+
+## 2. PERFORMANCE — ChunkWorker uses number[] arrays for geometry, then converts
+
+**File:** `client/src/workers/ChunkWorker.ts` (~lines 850-1050, 1150-1200)
+
+Vertex positions, normals, UVs, colors, and indices are pushed one-at-a-time into `number[]` arrays, then bulk-converted to `Float32Array` / `Uint32Array` at the end via `new Float32Array(arr)`. Each `.push()` may trigger V8 to resize the backing store. For a large batch (32x32x32 blocks), arrays can grow to hundreds of thousands of elements with many intermediate reallocations.
+
+Pre-allocating typed arrays at a worst-case size and using a write cursor would eliminate all intermediate allocations. Unused tail can be sliced via `.subarray()` which is zero-copy.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 5 | 2 | 3 | Yes | Yes |
+
+---
+
+## 3. PERFORMANCE — BoundaryVolume uses string-key Map for block lookups
+
+**File:** `client/src/workers/ChunkWorker.ts` (~lines 130-180)
+
+`BoundaryVolume` stores cross-chunk boundary blocks in a `Map<string, number>` with keys like `` `${x},${y},${z}` ``. Every lookup allocates a string. During mesh building, boundary lookups happen for every face of every surface block (6 directions x all surface blocks). The code already has a TODO acknowledging this issue.
+
+Replace with a flat `Int8Array` or `Uint8Array` indexed by `(x + pad) * strideYZ + (y + pad) * strideZ + (z + pad)` with a 1-block padding border. This eliminates all string allocation and GC pressure.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 5 | 2 | 3 | Yes | Yes |
+
+---
+
+## 4. PERFORMANCE — No frustum culling for chunk batch meshes
+
+**File:** `client/src/chunks/ChunkMeshManager.ts` (~lines 100-150)
+
+Batch meshes are added/removed from the scene based only on view distance (sphere check). Three.js has built-in per-object frustum culling via `mesh.frustumCulled = true`, but the current code does not leverage spatial knowledge. When the player looks in one direction, batches behind the camera within view distance still get submitted to the GPU.
+
+Since Three.js already does frustum culling on the scene graph, verify that `frustumCulled` is `true` on batch meshes (it is by default). The real win would be a spatial index (octree or grid) to skip the scene-graph traversal entirely for batches clearly outside the frustum, avoiding per-mesh matrix * frustum checks.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 4 | 2 | 2 | Yes | Yes |
+
+---
+
+## 5. BUG — DebugRenderer leaks geometries and materials
+
+**File:** `client/src/core/DebugRenderer.ts` (lines 30-76)
+
+`_onPhysicsDebugRaycastPacket` creates `new BufferGeometry()`, `new LineBasicMaterial()`, and `new ArrowHelper()` per raycast visualization. After the blink animation completes, `line.removeFromParent()` is called but `.geometry.dispose()` and `.material.dispose()` are never called. `ArrowHelper` also contains internal geometry and material that are never disposed. Over time, this leaks WebGL buffers.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 4 | 1 | 1 | Yes | Yes |
+
+---
+
+## 6. BUG — Liquid material time increment is frame-rate dependent
+
+**File:** `client/src/blocks/BlockMaterialManager.ts` (line ~320)
+
+The liquid wave animation time uniform is incremented by a fixed `0.0075` per frame rather than by the actual frame delta time. At 60 FPS the effective speed is `0.075 * 60 = 0.45/s`. At 120 FPS it doubles to `0.9/s`. At 30 FPS it halves. This means water animation speed varies with frame rate.
+
+Pass `deltaTime` (already available in the animate loop) and use `time += deltaTime * speed` instead.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 4 | 1 | 1 | Yes | Yes |
+
+---
+
+## 7. PERFORMANCE — Every-frame batch view distance check iterates all batches
+
+**File:** `client/src/chunks/ChunkManager.ts` (~lines 150-180, `applyBatchViewDistance`)
+
+Every animation frame, `applyBatchViewDistance` iterates every batch in `ChunkRegistry` and computes a distance to the player to decide add/remove from scene. With hundreds of batches, this is O(n) per frame. The code has a comment acknowledging this.
+
+A spatial hash grid (bucket size = view distance) would reduce this to checking only buckets near the view distance boundary, making the per-frame cost proportional to the number of batches that actually change visibility, not the total count.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 4 | 2 | 3 | Yes | Yes |
+
+---
+
+## 8. PERFORMANCE — LightLevelVolume._getPackedIndex allocates object per call
+
+**File:** `client/src/chunks/LightLevelVolume.ts` (~line 30)
+
+`_getPackedIndex` returns `{ byteIndex, isHighNibble }` — a new object allocation every call. During mesh building and light queries, this is called per-block. The sibling `SkyDistanceVolume.ts` avoids this by using a reusable working variable.
+
+Return the two values via a reusable static working object, or inline the calculation at call sites (the math is trivial: `index >> 1` and `index & 1`).
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 4 | 1 | 1 | Yes | Yes |
+
+---
+
+## 9. PERFORMANCE — AO cache in ChunkWorker uses linear scan of parallel arrays
+
+**File:** `client/src/workers/ChunkWorker.ts` (~lines 1380-1430)
+
+`_sampleAOOpacity` maintains a cache via four parallel arrays (`aoCacheX`, `aoCacheY`, `aoCacheZ`, `aoCacheOpacity`) and performs a linear scan up to `aoCacheSize` to find a cached entry. The cache is cleared per-batch-build. If cache utilization grows (many unique AO sample positions), the linear scan becomes expensive.
+
+Replace with a flat typed array indexed by a hash of `(x, y, z)` or by direct coordinate indexing (the coordinate range is bounded by batch size + 1 block border).
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 2 | 2 | Yes | Yes |
+
+---
+
+## 10. PERFORMANCE — Light level calculation iterates all nearby light sources per block
+
+**File:** `client/src/workers/ChunkWorker.ts` (`_calculateLightLevel`, ~lines 1300-1370)
+
+For each block position, `_calculateLightLevel` iterates every entry in the `nearbyLightSources` array (populated from all chunks within search radius) and computes distance attenuation. With many light sources (torches in a cave), this is O(lights) per block per face.
+
+A 3D grid lookup (light influence map) pre-computed per batch would reduce per-block cost to O(1). Alternatively, cull lights by maximum attenuation radius before the per-block loop.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 2 | 3 | Yes | Yes |
+
+---
+
+## 11. PERFORMANCE — _clearNearbyLightSourceCache does cubic chunk iteration
+
+**File:** `client/src/workers/ChunkWorker.ts` (`_clearNearbyLightSourceCache`, ~lines 1340-1360)
+
+When a block update arrives, `_clearNearbyLightSourceCache` loops `(2 * SEARCH_RADIUS + 1)^3` chunk lookups to rebuild the light source cache. With `SEARCH_RADIUS = 2`, that is 125 chunk lookups per blocks_update message, each involving a Map lookup and potentially iterating all 4096 blocks in `Chunk.getLightSources()`.
+
+Cache invalidation could be made incremental: only update the light sources from the specific chunks whose blocks changed, rather than rebuilding the entire cache.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 2 | 3 | Yes | Yes |
+
+---
+
+## 12. PERFORMANCE — GLTFManager copies all instance attributes every frame
+
+**File:** `client/src/gltf/GLTFManager.ts` (`_processClonedMeshes`, ~lines 1222-1386)
+
+In `update()`, every visible cloned mesh's world matrix, color, opacity, light level, emissive, and sky light are copied into the InstancedMesh attributes every frame, regardless of whether they changed. The code itself notes this: "Accessing all cloned meshes every animation frame... may be costly."
+
+A dirty-flag per clone would allow skipping unchanged instances. Only the matrix (which changes when entities move) truly needs per-frame updates; color/opacity/emissive change rarely.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 2 | 3 | Yes | Yes |
+
+---
+
+## 13. PERFORMANCE — ChunkMeshManager creates new BufferGeometry per update
+
+**File:** `client/src/chunks/ChunkMeshManager.ts` (`_createOrUpdateMesh`, ~lines 80-130)
+
+Every time a batch mesh is updated, a new `BufferGeometry` is created and the old one is disposed. This involves WebGL buffer deallocation and reallocation. If the same batch is rebuilt frequently (e.g., block placement), this causes GPU buffer churn.
+
+Reuse the existing geometry and update its attributes in-place via `setAttribute` and `setIndex`, only recreating if the buffer size changes significantly. Use `BufferAttribute.setUsage(DynamicDrawUsage)` to hint the driver.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 2 | 3 | Yes | Yes |
+
+---
+
+## 14. FEATURE — No LOD system for distant chunks
+
+**Files:** `client/src/chunks/ChunkMeshManager.ts`, `client/src/workers/ChunkWorker.ts`
+
+All chunks at any distance render at full detail. Distant chunks could use simplified geometry (e.g., skip AO, reduce face count, lower texture resolution) to reduce vertex count and draw calls. This is especially impactful at high view distances.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 3 | 5 | No | Yes |
+
+---
+
+## 15. PERFORMANCE — Outline pass 8-direction per-pixel search
+
+**File:** `client/src/three/postprocessing/SelectiveOutlinePass.ts` (~lines 480-560)
+
+The outline fragment shader samples 8 directions at configurable thickness (up to 16 pixels). Each direction does a texture fetch per step. Worst case: 8 directions * 16 steps = 128 texture samples per pixel. The pre-check optimization (checking boundary samples first) helps, but in scenes with many outlined objects the fallback loop runs on many pixels.
+
+A separable blur approach (horizontal pass then vertical pass) or a jump-flood algorithm would reduce per-pixel cost from O(8 * thickness) to O(2 * log2(thickness)).
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 3 | 4 | No | Yes |
+
+---
+
+## 16. PERFORMANCE — Camera allocates vectors per frame in update methods
+
+**File:** `client/src/core/Camera.ts` (`_updateSpectatorCamera`, `_updateGameCamera`)
+
+Methods like `_updateSpectatorCamera` and `_updateGameCamera` call `new Vector3()` during per-frame updates. These allocations trigger GC pressure. Pre-allocate as module-level or class-level working variables (as done in `client/src/three/utils.ts`).
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 1 | 1 | Yes | Yes |
+
+---
+
+## 17. PERFORMANCE — Chunk.getLightSources iterates all 4096 blocks
+
+**File:** `client/src/chunks/Chunk.ts` (`getLightSources`, ~line 160)
+
+When the light source cache is not populated, `getLightSources` iterates all 4096 blocks (`CHUNK_SIZE^3`) to find light-emitting blocks. This is called for every chunk within the light search radius during batch builds.
+
+Maintain a list of light source positions on block add/remove (already partially implemented via the cache) so the full scan is avoided.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 1 | 2 | Yes | Yes |
+
+---
+
+## 18. PERFORMANCE — CompressedTexture readback renders to screen then reads pixels
+
+**File:** `client/src/gltf/GLTFManager.ts` (`readPixelsFromCompressedTexture`, ~lines 1734-1812)
+
+When building InstancedTextures from KTX2 compressed textures, the code renders the compressed texture to a WebGLRenderTarget and reads pixels back. The code has a TODO noting this "may reduce the benefits of using CompressedTexture" and suggests `CompressedArrayTexture` instead. This readback is synchronous and stalls the GPU pipeline.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 3 | 3 | 4 | No | Yes |
+
+---
+
+## 19. PERFORMANCE — Legacy BlockTextureAtlasManager has O(n) brute-force space finding
+
+**File:** `client/src/workers/BlockTextureAtlasManager.ts` (`_drawImageToAtlas`, legacy path)
+
+In legacy mode, `_drawImageToAtlas` scans the atlas pixel-by-pixel to find empty space for new textures. For large atlases with many textures, this becomes progressively slower. The modern KTX2 path avoids this entirely.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 1 | 2 | Yes | Yes |
+
+---
+
+## 20. PERFORMANCE — ChunkRegistry.getBatchChunkIds creates new array each call
+
+**File:** `client/src/chunks/ChunkRegistry.ts` (`getBatchChunkIds`, ~line 60)
+
+`getBatchChunkIds` creates a new array from the internal `Set` each call via `Array.from()`. If called frequently (e.g., during batch building validation), this creates unnecessary garbage.
+
+Return the Set directly (as read-only) or cache the array.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 1 | 1 | Yes | Yes |
+
+---
+
+## 21. BUG — PerformanceMetricsManager has double semicolon
+
+**File:** `client/src/core/PerformanceMetricsManager.ts` (line 139)
+
+Line 139 has `;;` (double semicolon). Harmless but indicates a typo.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 1 | 1 | 1 | Yes | Yes |
+
+---
+
+## 22. PERFORMANCE — CSS2DRenderer builds transform strings every frame
+
+**File:** `client/src/three/CSS2DRenderer.ts` (~lines 100-140)
+
+For every visible CSS2D element, a new transform string is constructed each frame. The code partially mitigates this by comparing with a cached `tmpEl` before applying to the DOM. However, the string construction itself (`translate(...)`) still runs. This is minor given the viewport culling already limits visible elements.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 1 | 2 | Yes | Yes |
+
+---
+
+## 23. PERFORMANCE — Post-processing chain runs all passes unconditionally
+
+**File:** `client/src/core/Renderer.ts` (~lines 350-450)
+
+The EffectComposer runs SMAA, Bloom, Outline, and Output passes every frame even when bloom threshold means no pixels qualify or no objects are outlined. Disabling passes dynamically when they have no work would save full-screen shader invocations.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 2 | 2 | Yes | Yes |
+
+---
+
+## 24. FEATURE — Transparent instanced mesh flicker at threshold boundary
+
+**File:** `client/src/gltf/GLTFManager.ts` (~lines 1454-1482)
+
+The code notes: "When the visible transparent mesh count hovers around the threshold, rendering may flicker due to frequent switching between individual mesh rendering and InstancedMesh rendering." A hysteresis band (different thresholds for switching on vs off) would prevent this.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 1 | 1 | Yes | Yes |
+
+---
+
+## 25. FEATURE — No transparent instance sorting within InstancedMesh
+
+**File:** `client/src/gltf/GLTFManager.ts` (~lines 1471-1473)
+
+The code has a TODO: "Consider sorting instances by distance from camera before updating instance attributes." Without this, overlapping transparent instances within the same InstancedMesh may render in wrong order, causing visual artifacts.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 2 | 2 | Yes | Yes |
+
+---
+
+## 26. PERFORMANCE — GLTFManager clones geometry for each InstancedMesh resize
+
+**File:** `client/src/gltf/GLTFManager.ts` (`_applyInstancedMesh`, ~lines 792-803)
+
+When the InstancedMesh needs to grow, a new `InstancedMeshEx` is created with `sourceMesh.geometry.clone()`. The comment explains this is needed due to Three.js WebGL resource management constraints (can't release instanceOpacity buffer without disposing geometry). This means each resize allocates new GPU buffers for the base geometry.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 3 | 3 | No | Yes |
+
+---
+
+## 27. PERFORMANCE — Block data not transferred (copied) between main thread and worker
+
+**File:** `client/src/workers/ChunkWorkerConstants.ts` (ChunkWorkerChunkUpdateMessage), `client/src/chunks/ChunkManager.ts`
+
+The `chunk_update` message sends `blocks: Uint8Array` to the worker. This data is copied (not transferred via Transferable) because the main thread still needs the data. For large numbers of chunk updates, the structured clone overhead adds up. Consider using SharedArrayBuffer if the security model allows (requires COOP/COEP headers).
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 3 | 3 | No | Depends on server headers |
+
+---
+
+## 28. PERFORMANCE — View model scene rendered separately adds extra render pass
+
+**File:** `client/src/core/Renderer.ts` (~lines 500-520)
+
+First-person view model rendering uses a separate scene + camera and an additional `renderer.render()` call with depth buffer clear. This is a full additional render pass. For the typical 1-2 meshes of the held item, an alternative would be rendering with a modified projection matrix or depth range in the main pass.
+
+| Benefit | Risk | Effort | Surgical | Backwards Compatible |
+|---------|------|--------|----------|----------------------|
+| 2 | 3 | 3 | No | Yes |
+
+---
+
+## Summary
+
+| # | Type | Brief Description | Benefit | Risk | Effort |
+|---|------|-------------------|---------|------|--------|
+| 1 | PERF | No greedy meshing | 5 | 3 | 5 |
+| 2 | PERF | number[] to typed array conversion | 5 | 2 | 3 |
+| 3 | PERF | String-key BoundaryVolume | 5 | 2 | 3 |
+| 4 | PERF | No spatial frustum culling | 4 | 2 | 2 |
+| 5 | BUG | DebugRenderer geometry/material leak | 4 | 1 | 1 |
+| 6 | BUG | Liquid time not delta-based | 4 | 1 | 1 |
+| 7 | PERF | Every-frame batch distance iteration | 4 | 2 | 3 |
+| 8 | PERF | LightLevelVolume object alloc per call | 4 | 1 | 1 |
+| 9 | PERF | AO cache linear scan | 3 | 2 | 2 |
+| 10 | PERF | Light calc iterates all sources per block | 3 | 2 | 3 |
+| 11 | PERF | Cubic cache clear for light sources | 3 | 2 | 3 |
+| 12 | PERF | GLTF instance attrs copied every frame | 3 | 2 | 3 |
+| 13 | PERF | New BufferGeometry per batch update | 3 | 2 | 3 |
+| 14 | FEAT | No LOD for distant chunks | 3 | 3 | 5 |
+| 15 | PERF | Outline 8-dir per-pixel search | 3 | 3 | 4 |
+| 16 | PERF | Camera per-frame vector allocations | 3 | 1 | 1 |
+| 17 | PERF | getLightSources scans all 4096 blocks | 3 | 1 | 2 |
+| 18 | PERF | Compressed texture GPU readback | 3 | 3 | 4 |
+| 19 | PERF | Legacy atlas O(n) space finding | 2 | 1 | 2 |
+| 20 | PERF | getBatchChunkIds array alloc | 2 | 1 | 1 |
+| 21 | BUG | Double semicolon in metrics | 1 | 1 | 1 |
+| 22 | PERF | CSS2D transform string per frame | 2 | 1 | 2 |
+| 23 | PERF | Post-processing runs unconditionally | 2 | 2 | 2 |
+| 24 | FEAT | Transparent instanced mesh flicker | 2 | 1 | 1 |
+| 25 | FEAT | No transparent instance sorting | 2 | 2 | 2 |
+| 26 | PERF | Geometry clone on InstancedMesh resize | 2 | 3 | 3 |
+| 27 | PERF | Block data copied not transferred | 2 | 3 | 3 |
+| 28 | PERF | View model extra render pass | 2 | 3 | 3 |
diff --git a/AUDIT_CLIENT_SYSTEMS.md b/AUDIT_CLIENT_SYSTEMS.md
new file mode 100644
index 00000000..1ca477be
--- /dev/null
+++ b/AUDIT_CLIENT_SYSTEMS.md
@@ -0,0 +1,446 @@
+# Client Systems Audit: Network, Input, UI, Entities, Audio, Particles, and More
+
+Auditor: client-systems-auditor
+Date: 2026-03-03
+Scope: `client/src/network/`, `client/src/input/`, `client/src/mobile/`, `client/src/ui/`, `client/src/entities/`, `client/src/audio/`, `client/src/particles/`, `client/src/players/`, `client/src/settings/`, `client/src/bridge/`, `client/src/arrows/`, `client/src/services/hytopia/`, `client/src/textures/`
+
+---
+
+## Findings
+
+### [BUG] BridgeManager postMessage uses wildcard origin -- security risk
+**Benefit: 5/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/bridge/BridgeManager.ts:220`
+
+**Status (verified): partially correct / slightly mis-framed.**
+
+Using `window.parent.postMessage(message, '*')` does mean the client will send bridge data to whatever origin is hosting the parent frame. If the client can be embedded by untrusted origins, this can become a data exfiltration vector. If embedding is restricted (for example via `frame-ancestors` / X-Frame-Options on the served client), the wildcard target origin becomes much less relevant.
+
+The more direct issue is that `_onParentMessage` processes incoming `message` events without validating `event.origin` and without checking `event.source === window.parent` (`client/src/bridge/BridgeManager.ts:152`). A malicious embedding parent (or any window with a handle) could inject:
+- `SEND_CHAT_MESSAGE` to send arbitrary chat messages as the player
+- `SET_QUALITY_PRESET` to force POWER_SAVING mode (griefing)
+- `LOCK_POINTER` / `UNLOCK_POINTER` to disrupt gameplay
+- `TOGGLE_DEBUG` to expose debug info
+
+**Fix:** In `_onParentMessage`, validate both `event.source` (must be `window.parent`) and `event.origin` (allowlist) before processing. Optionally also replace `'*'` with the expected parent origin to prevent accidental embedding data leaks.
+
+---
+
+### [BUG] UIManager innerHTML injection allows XSS from server-controlled HTML
+**Benefit: 5/5 | Risk: 3/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/UIManager.ts:164`
+
+`_onUIPacket` fetches HTML from `deserializedUI.htmlUri` and sets `this._uiDiv.innerHTML = html` directly. It then executes all `<script>` tags found in that HTML via `_executeScripts`. While the HTML comes from the game server (which the SDK developer controls), this pattern means:
+
+1. Any game server can run arbitrary JS in the client iframe context, accessing `Game.instance`, `NetworkManager`, and all internal state.
+2. If a game server is compromised or a malicious SDK game is published, it can exfiltrate player data, hijack sessions, or perform actions on behalf of the player.
+3. The `{{CDN_ASSETS_URL}}` replacement at line 163 could be abused if the CDN URL contains special regex characters (unlikely but worth noting).
+
+This is partially by design (SDK developers need to provide UI), but the lack of sandboxing means a rogue SDK game gets full client access.
+
+**Fix:** Consider running game developer UI in a sandboxed iframe with a restrictive CSP, communicating via postMessage. At minimum, document the trust model clearly. For the `{{CDN_ASSETS_URL}}` replacement, use `replaceAll` with string (not regex) to avoid regex injection.
+
+---
+
+### [BUG] Monkey-patched addEventListener does not track removeEventListener
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/UIManager.ts:20-31`
+
+The global `EventTarget.prototype.addEventListener` is monkey-patched to track elements with click/pointer listeners in a `WeakSet`. However, `removeEventListener` is not patched, so once an element is added to `elementsWithClickListeners`, it stays there even if all listeners are removed. This means `eventPathHasClickListener()` may return false positives after a listener is removed, causing interact clicks to be incorrectly suppressed (players tap on areas where UI listeners were removed, but the interaction ray never fires).
+
+Since `WeakSet` only tracks presence, not count, removing the element when a listener is removed requires a reference-counted approach (e.g., a `WeakMap<EventTarget, number>`).
+
+**Fix:** Also monkey-patch `removeEventListener`. Use a `WeakMap<EventTarget, number>` to track listener counts. When count reaches 0, remove the entry.
+
+---
+
+### [PERFORMANCE] Deserializer creates many intermediate objects per packet
+**Benefit: 4/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/Deserializer.ts:274-642`
+
+Every deserialization call allocates new objects: `new THREE.Color()`, `new Uint32Array()`, `new Float32Array()`, and plain objects via spread/map. For high-frequency packets like `ENTITIES` (every server tick at 60Hz with potentially dozens of entities), this creates significant GC pressure.
+
+For example, `deserializeEntities` calls `.map()` which creates a new array, then for each entity creates a new object with potentially new `THREE.Color` instances (lines 388, 407), new vectors, etc. With 100 entities, that is hundreds of short-lived objects per tick.
+
+**Fix:** Use an object pool for `DeserializedEntity` objects and `THREE.Color`/`Vector3Like` instances. Alternatively, deserialize in-place by passing the target entity directly to the deserializer. The `Vector3Like` results (just `{x,y,z}`) could reuse a pre-allocated scratch object.
+
+---
+
+### [BUG] Input sequence numbers increment even when not sent
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/NetworkManager.ts:200-206`
+
+`sendInputPacket` increments `_lastInputSequenceNumber` unconditionally at line 206, but the sequence number `sq` is only attached to joystick packets (line 200-201). This means:
+1. Non-joystick input packets (key presses) cause sequence number gaps.
+2. The server may interpret these gaps as dropped packets and apply unnecessary compensation.
+
+**Fix:** Only increment `_lastInputSequenceNumber` when a joystick packet is actually sent (move the increment inside the `if (changedInputState.jd !== undefined)` block).
+
+---
+
+### [BUG] WebSocket connection promise never rejects on failure
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/NetworkManager.ts:325-342`
+
+`_connectWebSocket` returns a Promise that resolves on `onopen` but never rejects. If the WebSocket connection fails, `onerror` fires and closes the socket, but the promise hangs forever. The `connect()` method at line 148 does `await this._connectWebSocket()` and then checks `!this._ws`, but since `onerror` sets `_ws.close()` which triggers `onclose` -> `_reconnect()`, the await never completes and execution flow becomes unpredictable.
+
+**Fix:** Add a `reject` call in `onerror`/`onclose` handlers, or use a timeout. Store the resolve/reject pair and call reject on connection failure.
+
+---
+
+### [BUG] setInterval timers in NetworkManager leak on reconnect
+**Benefit: 4/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/NetworkManager.ts:156-157`
+
+`connect()` creates two `setInterval` timers (synchronize every 2000ms, heartbeat every 5000ms) but never stores the interval IDs. On reconnect (which reloads the iframe), this is fine since the entire context is destroyed. However, if `connect()` were ever called twice without a full page reload, the intervals would stack, sending duplicate sync/heartbeat packets. The `_killConnection` method does not clear these intervals either.
+
+**Fix:** Store the interval IDs and clear them in `_killConnection()`. Also add a guard in `connect()` to prevent re-creating them.
+
+---
+
+### [BUG] Reliable WebTransport packet queue drops silently on overflow
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/NetworkManager.ts:222-225`
+
+When the reliable packet queue exceeds 32 entries, the oldest packet is silently dropped with only a console.warn. For reliable packets (which include all non-camera/joystick input), dropping packets means player actions (jumps, button presses, interact events) can be lost without any server-side awareness.
+
+**Fix:** Instead of silently dropping, consider: (1) increasing the queue size, (2) notifying the server that packets may have been lost, or (3) implementing backpressure by pausing input acceptance when the queue is full. At minimum, increment a counter for telemetry.
+
+---
+
+### [PERFORMANCE] InputManager sends discrete input changes immediately, no batching
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/input/InputManager.ts:337-339`
+
+When a key is pressed/released, `_onInputChange` immediately calls `sendInputPacket` for each individual state change. If a player presses W+Shift simultaneously (common for sprint), two separate packets are sent within the same frame. The continuous input state (camera/joystick) is already batched on a timer, but discrete inputs are not.
+
+**Fix:** Buffer discrete input changes and batch them with the next continuous input packet tick. This would reduce packet count without meaningful latency increase (16ms at 60Hz). The server already handles batched input fields.
+
+---
+
+### [BUG] Mobile camera cleanup clears all camera positions when one finger lifts
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/mobile/MobileManager.ts:143-147`
+
+In `cleanupJoystick`, when a camera joystick is removed (finger lifted), `cameraPositions.clear()` is called, which clears ALL camera positions including the still-active finger. This means:
+1. During a pinch-to-zoom, lifting one finger causes the remaining finger's camera delta to be calculated from scratch, producing a sudden camera jump on the next move event.
+2. The `lastPinchDist` is also reset to null, so the next pinch distance calculation starts fresh.
+
+**Fix:** Only delete the specific finger's position from `cameraPositions` (`cameraPositions.delete(id)`) instead of clearing the entire map. Reset `lastPinchDist` only when pinch is truly over (both fingers lifted).
+
+---
+
+### [BUG] SceneUI viewDistance of 0 cannot be set (falsy check)
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/UIManager.ts:291-293`
+
+`if (deserializedSceneUI.viewDistance)` uses a truthy check, which means a `viewDistance` of `0` is treated as "not set" and ignored. While a view distance of 0 may seem unlikely, it could be used intentionally to hide a SceneUI at all distances, or it could be set accidentally. The same issue exists at line 279 for `offset` (a zero offset `{x:0,y:0,z:0}` is a valid value that would be skipped).
+
+**Fix:** Use explicit `!== undefined` checks: `if (deserializedSceneUI.viewDistance !== undefined)`.
+
+---
+
+### [BUG] AudioManager uses truthy checks for volume/playbackRate/offset, skipping value 0
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/audio/AudioManager.ts:87-101`
+
+Several property checks in `_updateAudio` use truthy checks:
+- `if (deserializedAudio.volume)` - skips volume 0 (mute)
+- `if (deserializedAudio.playbackRate)` - skips playback rate 0 (pause)
+- `if (deserializedAudio.offset)` - skips offset 0
+- `if (deserializedAudio.cutoffDistance)` - skips cutoff 0
+- `if (deserializedAudio.referenceDistance)` - skips reference 0
+- `if (deserializedAudio.startTick)` - skips tick 0
+
+Setting volume to 0 (muting) is a common operation that would fail silently.
+
+**Fix:** Use `!== undefined` checks for all numeric properties.
+
+---
+
+### [BUG] Nametag chat message XSS vector via innerHTML-adjacent patterns
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/templates/Nametag.ts:62`
+
+Chat messages are filtered through `profanityFilter.clean()` at line 62 and set via `nametagChat.textContent = profanityFilter.clean(chat)`, which is safe. However, `nametagUsername` at line 70 also uses `.textContent` which is safe. The profanity filter itself doesn't sanitize HTML, but since `.textContent` is used rather than `.innerHTML`, the current code is actually safe.
+
+However, this finding is a **preventive warning**: any future change from `.textContent` to `.innerHTML` for styling purposes (bold, color, etc.) would immediately create an XSS vector since profanity filter output is not HTML-escaped.
+
+**Fix:** Add a code comment noting that `.textContent` must be used (not `.innerHTML`) for user-supplied strings. Consider adding HTML entity escaping as defense-in-depth.
+
+---
+
+### [BUG] Assets.urlExists caches errors permanently (rejected promises cached forever)
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/Assets.ts:88-106`
+
+The `ErrorCache` map stores promises for URL existence checks, including rejected promises (from network errors). Once a URL check fails due to a transient network issue, the rejection is cached forever, and subsequent calls for the same URL return the same rejected promise. This means:
+- A temporary network blip during model loading permanently prevents that model from loading.
+- The `getEffectiveGLTFlUri` method iterates candidates and catches rejections, but the fundamental issue is that network failures are treated as permanent.
+
+**Fix:** On rejection, remove the entry from `ErrorCache` so the next check retries. Optionally add a TTL for negative results.
+
+---
+
+### [BUG] EntityManager._updateEntity processes updates on already-removed entities
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/entities/EntityManager.ts:316-420`
+
+When `deserializedEntity.removed` is true, the entity is released and deleted from the maps at lines 317-325. However, the method continues executing after the `if` block and processes subsequent property updates (blockTextureUri, emissiveColor, modelAnimations, position, etc.) on the now-released entity. While the entity object still exists in memory, calling setters on a released entity can cause warnings, wasted work, or unexpected behavior.
+
+**Fix:** Add a `return` after the removal block:
+```typescript
+if (deserializedEntity.removed) {
+  entity.release();
+  this._entities.delete(entity.id);
+  this._dynamicEntities.delete(entity.id);
+  this._outlines.delete(entity.id);
+  return; // <-- add this
+}
+```
+
+---
+
+### [PERFORMANCE] EntityManager.findEntityByName is O(n) linear scan
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/entities/EntityManager.ts:72-79`
+
+`findEntityByName` iterates all entities to find one by name. The TODO at line 71 acknowledges this. This is called from `hytopia.getEntityIdByName()` which SDK game UI code can call frequently.
+
+**Fix:** Maintain a secondary `Map<string, Entity>` index for name lookups. Update on entity creation, name change, and removal.
+
+---
+
+### [BUG] Modal overlay does not prevent body scrolling on mobile
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/Modal.ts:17-107`
+
+When a modal is displayed, the background body can still scroll on mobile devices (touch events pass through the overlay). This can cause the viewport to scroll while the player is trying to interact with the modal.
+
+**Fix:** Add `overflow: hidden` to `document.body.style` when showing the modal, restore on close. Alternatively, add `touch-action: none` to the overlay element.
+
+---
+
+### [BUG] PlayerManager never cleans up player data, grows unbounded
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/players/PlayerManager.ts:33-56`
+
+When `deserializedPlayer.removed` is true, the player is deleted from `_players`. However, there is no mechanism to handle the case where a player disconnect packet is lost (e.g., on unreliable transport). The `_players` map could accumulate stale entries over long sessions. This is a minor issue since the map is keyed by player ID (string) and players are typically removed by the server.
+
+More importantly, when a player is removed, their `Player` object is just deleted from the map with no cleanup. If anything else holds a reference (unlikely currently), it would leak.
+
+**Fix:** Consider a periodic sweep that reconciles the player list with the server, similar to `AudioManager._cleanupOrphanedAudio()`.
+
+---
+
+### [PERFORMANCE] AudioManager._cleanupIfNeeded creates a full array on every audio update
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/audio/AudioManager.ts:135-141`
+
+`_cleanupIfNeeded` calls `Array.from(this._audios.values()).filter(audio => audio.hasActiveNode).length` on every `_updateAudio` call, creating a temporary array of all audios just to count active nodes. With many audio instances, this is wasteful.
+
+**Fix:** Track `activeNodeCount` as a counter, incrementing when an audio node is created and decrementing when disposed.
+
+---
+
+### [PERFORMANCE] SettingsManager._levelChangeHistory grows unbounded
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/settings/SettingsManager.ts:232`
+
+`_levelChangeHistory` is an array that only grows (via `push`) and is never pruned. The comment at line 230 acknowledges this. While quality changes are infrequent, over a very long session it could grow. The `_reachedMaxBounceCount` method only checks the last N entries.
+
+**Fix:** Keep only the last `MAX_QUALITY_BOUNCE_COUNT * 2` entries by slicing or using a ring buffer.
+
+---
+
+### [BUG] Heartbeat service starts unconditionally on module load, no cleanup
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/services/hytopia/heartbeat.ts:60`
+
+`start()` is called at module load time (line 60), which means the heartbeat polling loop runs from the moment the script is imported. If the player disconnects and reconnects (via iframe reload), a new heartbeat loop starts without stopping the old one. In a single-page-app scenario, this could lead to multiple concurrent heartbeat loops.
+
+The while-true loop at line 33 has no cancellation mechanism (no AbortController, no flag check). The only exit conditions are `invalidToken` or `notInLobby` errors.
+
+**Fix:** Add an AbortController that is signaled on disconnect/cleanup. Expose a `stop()` function. Consider moving the heartbeat start to be triggered by a game lifecycle event rather than module import.
+
+---
+
+### [BUG] CustomTextureManager.load promise never resolves on texture load failure
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/textures/CustomTextureManager.ts:54-79`
+
+The `wrappedTexturePromise` created in `load()` only calls `resolve()` -- there is no `reject()`. The inner `await texturePromise` can throw (texture load failure), but this is unhandled. The TODO at line 55 acknowledges this. If the texture fails to load, the promise hangs forever, and any caller awaiting it hangs too. This could cause particle emitters, entities, and arrows to silently fail to display.
+
+**Fix:** Add a try/catch around the `await texturePromise` and resolve with a fallback texture (e.g., a magenta "missing texture" placeholder) or reject the promise so callers can handle the error.
+
+---
+
+### [FEATURE] Input does not support key rebinding
+**Benefit: 3/5 | Risk: 1/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/input/InputManager.ts:57-96`
+
+The `CODE_TO_KEY_MAP` and `SUPPORTED_INPUT_MAP` are hardcoded constants. Players cannot rebind keys. This is a common feature request for PC games and accessibility.
+
+**Fix:** Make the key maps configurable via a settings UI or bridge message. Store bindings in localStorage. Provide a default mapping that matches the current hardcoded one.
+
+---
+
+### [FEATURE] No client-side prediction or reconciliation for player movement
+**Benefit: 4/5 | Risk: 4/5 | Effort: 5/5 | Surgical: no | Backwards Compatible: yes**
+
+File: `client/src/input/InputManager.ts:287-303`
+
+The comment at line 288-290 acknowledges this: "we can change this to 30 when we have client prediction." Currently, the client sends input to the server and waits for the server to send back the entity position update. This means all movement has at least one RTT of latency, which feels sluggish especially on higher-latency connections.
+
+**Fix:** Implement client-side prediction with server reconciliation. This is a large architectural change that would require the client to simulate physics locally and reconcile with server-authoritative state.
+
+---
+
+### [BUG] Keyboard input with Shift key can double-fire due to both code and key mapping
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/input/InputManager.ts:89-143`
+
+`CODE_TO_KEY_MAP` maps `ShiftLeft` and `ShiftRight` to `'shift'`, and `SUPPORTED_INPUT_MAP` maps `'shift'` to `'sh'`. However, the `CODE_TO_KEY_MAP` has a comment on line 89 mapping to `'shift'` but `SUPPORTED_INPUT_MAP` maps the key value `'shift'` to `'sh'`. The flow is: `keydown` event -> code `'ShiftLeft'` -> `CODE_TO_KEY_MAP` maps to `'shift'` -> `_onInputChange('shift', true)` -> `SUPPORTED_INPUT_MAP['shift']` = `'sh'` -> sends `{sh: true}`.
+
+For Shift+number combos, the `SUPPORTED_INPUT_MAP` maps `'!'` to `'1'`, `'@'` to `'2'`, etc. But `_onKeyboardInputChange` uses `event.code` (not `event.key`), so these key-based mappings at lines 120-138 are dead code -- they will never be reached via the keyboard code path.
+
+**Fix:** Remove the dead shift+number mappings from `SUPPORTED_INPUT_MAP` since `_onKeyboardInputChange` uses `event.code` via `CODE_TO_KEY_MAP`. If shift+number support is needed, add `Digit1`+shift handling in `CODE_TO_KEY_MAP` or use `event.key` as a fallback.
+
+---
+
+### [BUG] Translations service initializes with hardcoded production URL
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/services/hytopia/translations.ts:4`
+
+`hytopiaTranslations.init('https://prod.translations.hytopia.com')` is hardcoded. In development or staging environments, this still hits production. Not a bug per se, but could cause issues during testing of translation changes.
+
+**Fix:** Use an environment variable or derive the URL from the current environment (local vs production).
+
+---
+
+### [PERFORMANCE] ParticleEmitter._updatePosition always updates matrix even when nothing changed
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/particles/ParticleEmitter.ts:211-226`
+
+`_updatePosition` always calls `updateMatrix()`, `matrixWorld.copy()`, and `updateAABB()` every frame, regardless of whether the position actually changed. The TODO at line 212 acknowledges this.
+
+**Fix:** Track the last applied position and skip the matrix update when the position hasn't changed (compare with epsilon). For entity-attached emitters, check if the entity's position changed since the last update.
+
+---
+
+### [BUG] Arrow constructor error messages reference wrong field names
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/arrows/Arrow.ts:70-71, 76-77`
+
+Line 70: error says "Either sourceEntityId or targetEntityId must be specified" but should say "Either sourceEntityId or sourcePosition must be specified" (validates source, not target).
+Line 76: error says "Either targetEntityId or targetEntityId must be specified" but should say "Either targetEntityId or targetPosition must be specified" (also duplicates "targetEntityId").
+
+**Fix:** Correct the error messages:
+- Line 70: `"Arrow: Exactly one of sourceEntityId or sourcePosition must be specified."`
+- Line 76: `"Arrow: Exactly one of targetEntityId or targetPosition must be specified."`
+
+---
+
+### [PERFORMANCE] Deserializer.deserializeBlocks/Chunks/etc use .map() creating intermediate arrays
+**Benefit: 2/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/network/Deserializer.ts:297-374`
+
+All batch deserialization methods (deserializeAudios, deserializeBlocks, deserializeBlockTypes, deserializeChunks, etc.) use `.map()` which creates a new array. For large chunk updates, this can create arrays with thousands of entries. Combined with the per-item object allocation, this creates considerable GC pressure.
+
+**Fix:** Pre-allocate result arrays with known length and fill them in a for loop. For very hot paths (entities, chunks), consider deserializing into a reusable buffer.
+
+---
+
+### [BUG] SceneUI removeFromScene does not clean up containerDiv or template DOM
+**Benefit: 2/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/SceneUI.ts:142-144`
+
+`removeFromScene` only calls `this._object.removeFromParent()`. The `_containerDiv` created in `_createObject` (and any DOM elements created by the template renderer) are not explicitly cleaned up. While `removeFromParent()` should detach the CSS2DObject which removes its DOM element from the CSS2DRenderer's DOM tree, any event listeners or timers set up by the template renderer (like the setTimeout in Nametag) are not cleaned up.
+
+**Fix:** Null out `_containerDiv` and `_onStateCallback` in `removeFromScene()`. Call a cleanup/dispose callback if the template renderer registered one.
+
+---
+
+### [BUG] SettingsManager quality adjustment has unreachable else branch
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/settings/SettingsManager.ts:272`
+
+At line 272, there is `} {` instead of `} else {`. This means the `resetDuration = false` block at line 273 always executes when the condition at line 269 is false, making `resetDuration` always false when inside the `stats.thresholdExceeded` block and the duration hasn't reached the threshold yet. This appears to be the intended behavior (don't reset duration while accumulating), but the missing `else` keyword means the code works by accident, not by intent.
+
+Wait -- actually re-reading: the `{ resetDuration = false; }` block at line 272-274 is NOT an else. It is a standalone block that always executes after the `if` at line 269. This means `resetDuration` is set to `false` even when `stats.duration >= stats.durationThreshold` (when quality was just changed), preventing the duration from being reset after a quality change. This could cause an immediate re-trigger.
+
+**Fix:** Add the missing `else` keyword: `} else { resetDuration = false; }`.
+
+---
+
+### [BUG] EntityStats.reset() clears frustumCulledCount twice
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/entities/EntityStats.ts:22, 27`
+
+`EntityStats.frustumCulledCount` is reset to 0 at both line 22 and line 27 in the `reset()` method. This is a harmless duplicate but indicates a copy-paste error.
+
+**Fix:** Remove the duplicate line.
+
+---
+
+### [BUG] StaticEntity.updateLightLevel recalculates globalCoordinate from position that never changes
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/entities/StaticEntity.ts:136-147`
+
+`updateLightLevel()` saves the current global coordinate, recalculates it from `entityRoot.position`, then compares to see if it changed. But since StaticEntity's position never changes (all setPosition calls are overridden to warn and return), the global coordinate will never change either. The comparison is wasted work.
+
+**Fix:** For StaticEntity, calculate the global coordinate once at construction time and skip the comparison in `updateLightLevel()`.
+
+---
+
+### [FEATURE] Mobile pinch-to-zoom should support touchpad two-finger gestures on desktop
+**Benefit: 2/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/mobile/MobileManager.ts`
+
+The pinch-to-zoom functionality is only available on mobile (gated by `MobileManager.isMobile`). Laptop users with touchpads who use two-finger pinch gestures get no zoom support. The wheel event is likely handled elsewhere (Camera.ts), but the gesture-based zoom is a nicer UX for touchpad users.
+
+**Fix:** Detect touchpad pinch gestures via the `wheel` event's `ctrlKey` property (browsers set `ctrlKey=true` for pinch gestures) and apply zoom accordingly.
+
+---
+
+### [PERFORMANCE] HytopiaUI.emitData iterates all callbacks even if data is targeted
+**Benefit: 1/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `client/src/ui/globals/hytopia.ts:138-142`
+
+`emitData` iterates all registered `_onDataCallbacks` for every data packet. If a game has many data listeners (e.g., for different UI panels), all of them receive every packet and must individually check if the data is relevant to them.
+
+**Fix:** Allow optional topic/type-based filtering when registering callbacks, so only relevant callbacks are invoked.
diff --git a/AUDIT_ENTITIES_PLAYERS.md b/AUDIT_ENTITIES_PLAYERS.md
new file mode 100644
index 00000000..a951fe76
--- /dev/null
+++ b/AUDIT_ENTITIES_PLAYERS.md
@@ -0,0 +1,349 @@
+# Entity & Player Systems Audit
+
+> Audited files: `server/src/worlds/entities/` (Entity.ts, PlayerEntity.ts, DefaultPlayerEntity.ts, EntityManager.ts, EntityModelAnimation.ts, EntityModelNodeOverride.ts), `server/src/worlds/entities/controllers/` (BaseEntityController.ts, DefaultPlayerEntityController.ts, SimpleEntityController.ts, PathfindingEntityController.ts), `server/src/players/` (Player.ts, PlayerCamera.ts, PlayerManager.ts, PlayerUI.ts)
+
+---
+
+### [BUG] ColliderMap entity entries leak on entity despawn
+**Benefit: 5/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/Entity.ts:1323 (spawn) and server/src/worlds/entities/Entity.ts:782 (despawn)
+
+**Status (verified): false positive under normal simulation stepping.**
+
+Although `Entity.spawn()` registers colliders into `ColliderMap`, collider removal goes through `Simulation.removeRawCollider()`, which queues the collider handle for cleanup and `ColliderMap.cleanup()` runs each physics step. Under normal server operation (world loop continues stepping), stale entity references are cleared and this does **not** grow unboundedly.
+
+**Edge case:** if the simulation stops stepping after removals are queued (e.g., a world is stopped/paused without a final cleanup), queued handles could linger until the next step.
+
+**Fix:** In `Entity.despawn()`, before `this.removeFromSimulation()`, iterate colliders and call `this._world!.simulation.colliderMap.removeColliderEntity(collider)` for each.
+
+---
+
+### [BUG] PlayerEntity.spawn() leaks event listener on player
+**Benefit: 5/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/PlayerEntity.ts:137
+
+`PlayerEntity.spawn()` registers an anonymous listener on `this.player` for `PlayerEvent.CHAT_MESSAGE_SEND`. However, `Entity.despawn()` never removes this listener. If a PlayerEntity is despawned and re-spawned (e.g. world switching, respawn mechanics), a new listener is added each time while old ones persist. This causes:
+1. Memory leak from accumulated closures referencing despawned entities.
+2. Stale `nametagSceneUI.setState()` calls on despawned SceneUIs.
+
+**Fix:** Store the listener reference and remove it in a `despawn()` override, or use `player.on()` with a named function and call `player.off()` in despawn.
+
+---
+
+### [BUG] DefaultPlayerEntity cosmetics applied after despawn (race condition)
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/DefaultPlayerEntity.ts:122
+
+`this.player.cosmetics.then(...)` is an async operation that resolves after network fetch. If the entity is despawned before the promise resolves, the callback at line 122 checks `if (!cosmetics || !this.modelUri) return;` but does NOT check `this.isSpawned`. The code then calls `hairEntity.spawn(world, ...)` and `cosmeticItemEntity.spawn(world, ...)` on a world reference that may have already unregistered this entity. Child entities will be spawned into the world orphaned from their despawned parent.
+
+**Fix:** Add `if (!this.isSpawned) return;` at the top of the `.then()` callback, before any cosmetic processing.
+
+---
+
+### [BUG] EntityManager._nextEntityId monotonically increases (no recycling)
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/EntityManager.ts:66
+
+`_nextEntityId` starts at 1 and increments forever. For long-running servers with high entity churn (thousands of spawns/despawns per minute for projectiles, particles, mobs), the ID will eventually exceed `Number.MAX_SAFE_INTEGER` (2^53 - 1), at which point IDs lose precision and may collide. While this would take an extremely long time in practice, the ID is also sent over the network as a serialized number, and very large numbers increase packet size.
+
+**Fix:** Consider recycling IDs from a free list, or resetting periodically. Alternatively, use a 32-bit counter with wrapping (sufficient for any practical session).
+
+---
+
+### [PERFORMANCE] PathfindingEntityController._reconstructPath uses array.unshift() in loop
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:516-525
+
+`_reconstructPath()` builds the path by calling `path.unshift(curr)` in a while loop. `Array.unshift()` is O(n) because it shifts all existing elements. For a path of length N, this gives O(N^2) total work. With `maxOpenSetIterations` of 200+, paths can be long.
+
+**Fix:** Use `path.push(curr)` and call `path.reverse()` after the loop. This is O(N) total.
+
+---
+
+### [PERFORMANCE] PathfindingEntityController._coordinateToKey creates strings per call
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:528-530
+
+`_coordinateToKey()` creates a template literal string every call: `` `${coordinate.x},${coordinate.y},${coordinate.z}` ``. This is called thousands of times per pathfind (every neighbor, every gScore/fScore lookup, every closedSet check). String creation + GC pressure is significant.
+
+**Fix:** Use a numeric hash: `(x + 1000) * 4000000 + (y + 1000) * 2000 + (z + 1000)` (assuming world bounds). Alternatively, use a 3D key encoding that avoids string allocation.
+
+---
+
+### [PERFORMANCE] PathfindingEntityController._findGroundedStart allocates spread objects in loop
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:651-666
+
+`_findGroundedStart()` creates `{ ...start, y: start.y - dy - 1 }` and `{ ...start, y: start.y - dy }` via spread in a loop. Similarly, the A* loop itself creates spread objects for neighbors (line 450-454) and horizontal offset combinations (line 407-410). Each allocation contributes to GC pressure during pathfinding.
+
+**Fix:** Reuse a mutable coordinate object for lookups instead of allocating new ones per iteration.
+
+---
+
+### [PERFORMANCE] EntityManager query methods allocate arrays every call
+**Benefit: 3/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/EntityManager.ts:97-213
+
+`getAllEntities()`, `getAllPlayerEntities()`, `getPlayerEntitiesByPlayer()`, `getEntitiesByTag()`, `getEntitiesByTagSubstring()`, and `getEntityChildren()` all allocate new arrays every call. `getEntityChildren()` is called during `Entity.despawn()` (line 787) meaning every despawn causes an O(N) scan + array allocation over all entities.
+
+**Fix:** For `getEntityChildren()`, consider maintaining a parent->children map. For the others, consider returning iterators or caching results.
+
+---
+
+### [BUG] DefaultPlayerEntityController ground contact count can go negative
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:503
+
+`this._groundContactCount += started ? 1 : -1;` can go negative if a collision-end event arrives without a corresponding collision-start (e.g., due to physics engine edge cases, entity teleportation, or collider removal while in contact). A negative count means `isGrounded` returns false forever (correct), but subsequent contact-start events would increment to 0 and isGrounded would still be false (incorrect - player would be unable to jump even when on the ground).
+
+Similarly, `_liquidContactCount` at line 443 has the same issue.
+
+**Fix:** Clamp to zero: `this._groundContactCount = Math.max(0, this._groundContactCount + (started ? 1 : -1))`. Same for `_liquidContactCount`.
+
+---
+
+### [BUG] DefaultPlayerEntityController._stepAudio not cleaned up on detach/despawn
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:414-421
+
+`_stepAudio` is created in `attach()` but there is no `detach()` or `despawn()` override to stop/dispose it. The entity's `despawn()` does call `world.audioManager.unregisterEntityAttachedAudios(this)` which handles cleanup at the manager level, but the `_stepAudio` reference itself is never cleared, and if the audio is currently playing when despawn happens, there's no explicit stop. This is a minor issue since the audio manager cleanup should handle it, but defensive cleanup would be safer.
+
+**Fix:** Override `despawn()` in the controller to call `this._stepAudio?.pause()` and clear the reference.
+
+---
+
+### [BUG] Player.joinWorld() world switch calls disconnect which triggers LEFT_WORLD twice
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/players/Player.ts:295-321
+
+When switching worlds, `joinWorld()` calls `this.disconnect()` which calls `this._leaveWorld()` then `this.connection.disconnect()`. `_leaveWorld()` emits `PlayerEvent.LEFT_WORLD` and sets `this._world = undefined`. Then `this._world = world` is set on line 318. However, the `disconnect()` call at line 316 triggers the connection close flow, which eventually calls `PlayerManager._onConnectionClosed()` (line 195-213) which calls `player.disconnect()` **again**. Since `_world` is already set to the new world by line 318, `_leaveWorld()` will emit `LEFT_WORLD` for the **new** world, not the old one.
+
+The timing depends on whether connection.disconnect() is synchronous. If it is, the second `disconnect()` call in `_onConnectionClosed` would cause a double LEFT_WORLD emission with the wrong world reference.
+
+**Fix:** Restructure world-switching to not use the disconnect/reconnect path, or guard `_leaveWorld()` against being called when world is already cleared.
+
+---
+
+### [BUG] SimpleEntityController.tick() face yaw extraction is approximate
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/SimpleEntityController.ts:487-489
+
+The yaw extraction formula `Math.atan2(2 * (w * y), 1 - 2 * (y * y))` assumes the quaternion has zero pitch and roll (only yaw). This is correct for Y-axis-only rotations, but if the entity somehow gets pitched or rolled (e.g. from physics before lockAllRotations, or manual setRotation with non-Y components), the extracted yaw will be incorrect, causing the entity to face the wrong direction.
+
+**Fix:** This is acceptable for the current use case since `SimpleEntityController` only sets Y-axis rotation, but document the assumption clearly.
+
+---
+
+### [PERFORMANCE] DefaultPlayerEntityController.tickWithPlayerInput allocates objects per tick
+**Benefit: 3/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:565-789
+
+The controller already uses reusable vectors (`_reusableImpulse`, `_reusableTargetVelocities`, etc.) which is good. However, the rotation quaternion at line 782-787 `{ x: 0, y: Math.sin(halfFinalYaw), z: 0, w: Math.cos(halfFinalYaw) }` creates a new object every tick. At 60Hz per player entity, this adds up.
+
+**Fix:** Add a `private readonly _reusableRotation = { x: 0, y: 0, z: 0, w: 1 }` and mutate it in-place.
+
+---
+
+### [BUG] Entity.setModelScale division by zero when current scale component is 0
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/Entity.ts:1041-1045
+
+```typescript
+const scalar: Vector3Like = {
+  x: modelScale.x / this._modelScale.x,
+  y: modelScale.y / this._modelScale.y,
+  z: modelScale.z / this._modelScale.z,
+};
+```
+
+If any current scale component is 0 (which could happen if a developer sets `modelScale: { x: 0, y: 1, z: 1 }` to flatten an entity), dividing by zero produces `Infinity` or `NaN`, which propagates to all collider scales. Rapier may crash or produce undefined behavior.
+
+**Fix:** Guard against zero division: `x: this._modelScale.x === 0 ? 1 : modelScale.x / this._modelScale.x`.
+
+---
+
+### [BUG] PathfindingEntityController setTimeout leaks if entity despawns during jump delay
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:571-601
+
+`_moveToNextWaypoint()` uses `setTimeout()` with a `jumpTimeout` delay. If the entity is despawned before the timeout fires, the callback at line 571 checks `if (!this._entity)` but `this._entity` is only cleared in `detach()`. If the entity is despawned without the controller being properly detached first, or if the entity reference is not nulled, the callback proceeds to call `this.face()` and `this.move()` on a despawned entity.
+
+The `detach` does set `_entity = undefined`, and `Entity.despawn()` does call `controller.detach()`, so the guard works in the normal path. But the setTimeout is never cancelled, meaning it fires wastefully after despawn.
+
+**Fix:** Store the timeout ID and clear it in `detach()`: `clearTimeout(this._jumpTimeoutId)`.
+
+---
+
+### [PERFORMANCE] EntityManager.getEntityChildren scans all entities O(N)
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/EntityManager.ts:203-213
+
+`getEntityChildren()` iterates over ALL entities to find children of a given entity. This is called during every `Entity.despawn()` (line 787). In a world with 1000+ entities, despawning an entity incurs an O(N) scan. Games with heavy entity churn (spawning/despawning hundreds of projectiles or mobs) will feel this.
+
+**Fix:** Maintain a `Map<Entity, Set<Entity>>` children index. Update it in `registerEntity/unregisterEntity` and when `setParent()` is called.
+
+---
+
+### [BUG] Player._onInputPacket sequence number check allows replay on wrap
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/players/Player.ts:522-525
+
+```typescript
+if (input.sq !== undefined) {
+  if (input.sq < this._lastUnreliableInputSequenceNumber) return;
+  this._lastUnreliableInputSequenceNumber = input.sq;
+}
+```
+
+If `input.sq` wraps around (e.g. from a large number back to 0), all subsequent packets would be rejected because they're less than the last seen number. The code has no wrap-around handling. On reconnection, `_lastUnreliableInputSequenceNumber` is reset to 0 (line 381), which helps for reconnects but not for long sessions where the client-side counter might wrap.
+
+**Fix:** Use modular arithmetic for comparison, or accept packets within a reasonable window of the last seen sequence number.
+
+---
+
+### [BUG] PlayerEntity.tick has unnecessary semicolon after return guard
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/PlayerEntity.ts:146
+
+```typescript
+if (!this.isSpawned || !this.world) {
+  return;
+};
+```
+
+The semicolon after the closing brace is a no-op statement. Not a runtime bug, but indicates a potential copy-paste error.
+
+---
+
+### [FEATURE] Entity despawn should clear all event listeners to prevent leaks
+**Benefit: 4/5 | Risk: 3/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: no**
+
+File: server/src/worlds/entities/Entity.ts:782-809
+
+Entity extends EventRouter (via RigidBody), but `despawn()` never calls any listener cleanup. External code can register listeners on entities (`entity.on(EntityEvent.TICK, ...)`), and these listeners + their closures will persist after despawn, keeping the entity and its references alive in memory. Since `Entity` is intended to be disposable (despawn = done), all listeners should be cleared on despawn.
+
+**Fix:** Call `this.removeAllListeners()` (from eventemitter3) at the end of `despawn()`. This is backwards-incompatible for any code that registers listeners before spawn and expects them to survive a despawn/respawn cycle, but such usage is unusual.
+
+---
+
+### [FEATURE] PlayerUI.sendData and PlayerUI.load lack input validation
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/players/PlayerUI.ts:97-210
+
+`PlayerUI.load(htmlUri)` and `PlayerUI.append(htmlUri)` accept arbitrary `htmlUri` strings from the server-side SDK developer. If the URI points to a file with unescaped content, or if a developer constructs HTML dynamically, this could lead to XSS in the client iframe. While this is primarily an SDK developer responsibility, there's no validation that the URI is a valid path/URL format, and no documentation warning about injection risks.
+
+`PlayerUI.sendData(data)` accepts arbitrary objects. On the client side, if this data is rendered into DOM without sanitization, it creates an XSS vector. The server doesn't validate or sanitize the data.
+
+**Fix:** Add a warning in documentation about sanitization requirements. Optionally validate that `htmlUri` matches an expected pattern (e.g. starts with `ui/` or is a valid URL).
+
+---
+
+### [FEATURE] PathfindingEntityController path caching for repeated destinations
+**Benefit: 3/5 | Risk: 3/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:284-308
+
+`pathfind()` runs the full A* algorithm synchronously every time. If multiple entities pathfind to similar destinations (e.g. 20 zombies targeting the same player), each one runs independent A*. There is no path caching or shared pathfinding.
+
+**Fix:** Implement a path cache keyed by (start_region, end_region) with a short TTL. Or use a flow-field approach for many-to-one pathfinding scenarios.
+
+---
+
+### [PERFORMANCE] PathfindingEntityController A* pushes duplicate entries to open set
+**Benefit: 3/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/PathfindingEntityController.ts:495
+
+When a better path to a neighbor is found, the code pushes a new entry to the heap: `openSet.push([neighborKey, neighbor])`. But the OLD entry for the same neighbor key is still in the heap (there's no decrease-key or removal). When the old entry is popped later, it's caught by the `closedSet.has(neighborKey)` check (line 464), but the heap still processes it. This means the heap can contain many duplicate entries, increasing memory and iteration count.
+
+**Fix:** This is a known pattern (lazy deletion) and is acceptable for small heaps, but for large pathfinding operations it can waste iterations. Consider using a proper decrease-key heap or checking `closedSet` after pop.
+
+---
+
+### [FEATURE] Entity re-spawn support
+**Benefit: 3/5 | Risk: 4/5 | Effort: 3/5 | Surgical: no | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/Entity.ts:1323-1388
+
+Once despawned, an entity cannot be re-spawned because:
+1. `_id` is set to undefined, but `spawn()` checks `if (this.isSpawned)` which only checks `_world`.
+2. `removeFromSimulation()` clears `_simulation` and `_rigidBody`, and there's no mechanism to re-add.
+3. Colliders are removed and cannot be re-created.
+
+Games frequently want respawn mechanics (e.g. respawning collectibles, mobs). Currently, developers must create an entirely new Entity instance.
+
+**Fix:** This is a larger architectural change. Consider adding a `respawn()` method or making `spawn()` handle re-initialization cleanly.
+
+---
+
+### [BUG] DefaultPlayerEntityController.attach monkey-patches entity.applyImpulse permanently
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:405-412
+
+`attach()` replaces `entity.applyImpulse` with a wrapper that accumulates impulses into `_externalVelocity`. The original is saved in `_internalApplyImpulse`. However, `detach()` (inherited from base) never restores the original `applyImpulse`. If a different controller is attached after this one detaches, the entity's `applyImpulse` still points to the wrapper from the old controller, which writes to a `_externalVelocity` that's no longer being read.
+
+**Fix:** Override `detach()` to restore the original `applyImpulse`: `entity.applyImpulse = this._internalApplyImpulse`.
+
+---
+
+### [BUG] Entity.spawn registers colliders in colliderMap but child-added colliders from controllers are not
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/Entity.ts:1383-1385 and controllers/DefaultPlayerEntityController.ts:478-535
+
+`Entity.spawn()` iterates existing colliders and registers them in the colliderMap (line 1383-1385). But `DefaultPlayerEntityController.spawn()` creates two new child colliders AFTER the entity's spawn completes (called at line 1376 `this._controller.spawn(this)`). These controller-created colliders (groundSensor, wallCollider) are never registered in the colliderMap because the registration loop already ran.
+
+This means raycasts and collision queries that use the colliderMap won't resolve these colliders to their parent entity. For the ground sensor (which is a sensor), this is acceptable since sensors don't participate in normal raycasting. But the wall collider is not a sensor and could be hit by raycasts without being attributed to the entity.
+
+**Fix:** Register colliders in colliderMap inside `createAndAddChildCollider()` if the entity is already spawned, not just in the spawn loop.
+
+---
+
+### [PERFORMANCE] Entity.modelAnimations and Entity.modelNodeOverrides return new arrays every access
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/entities/Entity.ts:593 and 604
+
+```typescript
+public get modelAnimations(): ... { return Array.from(this._modelAnimations.values()); }
+public get modelNodeOverrides(): ... { return Array.from(this._modelNodeOverrides.values()); }
+```
+
+Every property access allocates a new array. If game code accesses these frequently (e.g. in tick callbacks), this creates unnecessary GC pressure.
+
+**Fix:** Cache the array and invalidate on add/remove, or return a `ReadonlyMap` instead.
+
+---
+
+### [BUG] Player.interact only raycasts against the first player entity
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/players/Player.ts:542
+
+```typescript
+const playerEntity = this.world.entityManager.getPlayerEntitiesByPlayer(this)[0];
+```
+
+The raycast excludes only the first player entity's rigid body. If a player has multiple player entities (which the API allows - `getPlayerEntitiesByPlayer` returns an array), the raycast would hit the player's other entities. This is an edge case but could cause self-interaction bugs for games using multiple player entities.
+
+**Fix:** Exclude all player entities' rigid bodies from the raycast, or document that only one player entity per player is expected.
diff --git a/AUDIT_FINAL_REPORT.md b/AUDIT_FINAL_REPORT.md
new file mode 100644
index 00000000..6e5f8554
--- /dev/null
+++ b/AUDIT_FINAL_REPORT.md
@@ -0,0 +1,255 @@
+# HYTOPIA Engine — Final Audit Report (Consolidated)
+
+Date: 2026-03-02
+Source branch: `analysis/codebase-audit`
+Source commit: `4dbc73535c163f69e40225c3d50605aaae770d87`
+
+This file consolidates the six audit reports into a single index and captures post-review corrections.
+To avoid false statements, every item is labeled with a verification status.
+
+## Reports
+
+- `AUDIT_NETWORKING.md`
+- `AUDIT_SERVER_CORE.md`
+- `AUDIT_ENTITIES_PLAYERS.md`
+- `AUDIT_PHYSICS_WORLDS.md`
+- `AUDIT_CLIENT_SYSTEMS.md`
+- `AUDIT_CLIENT_RENDERING.md`
+
+## Finding Counts
+
+Total findings indexed: **179**
+
+- AUDIT_NETWORKING.md: 26
+- AUDIT_SERVER_CORE.md: 31
+- AUDIT_ENTITIES_PLAYERS.md: 27
+- AUDIT_PHYSICS_WORLDS.md: 32
+- AUDIT_CLIENT_SYSTEMS.md: 35
+- AUDIT_CLIENT_RENDERING.md: 28
+
+## Verification Legend
+
+- `[VERIFIED-TRUE]`: manually checked in code at commit `4dbc73535c163f69e40225c3d50605aaae770d87`
+- `[VERIFIED-NUANCE]`: sink/pattern is real, but risk depends on threat model or inputs
+- `[CORRECTED-FALSE]`: reviewed and corrected as a false positive (or materially misleading)
+- `[UNVERIFIED]`: not yet manually confirmed; treat as a hypothesis to validate
+
+## Corrections / Clarifications Applied After Review
+
+These items were updated in-place in their respective audit reports to remove false or overstated claims:
+
+- `AUDIT_SERVER_CORE.md`: `PersistenceManager.setPlayerData Never Persists to Storage` → corrected (SaveStates proxy auto-flush; caveat on load-failure fallback)
+- `AUDIT_SERVER_CORE.md`: `PersistenceManager.getGlobalData Crashes on Network Error (null deref)` → reframed (likely throw/reject handling issue, not deterministic null deref)
+- `AUDIT_ENTITIES_PLAYERS.md`: `ColliderMap entity entries leak on entity despawn` → corrected (cleanup is queued and drained each physics tick)
+- `AUDIT_CLIENT_SYSTEMS.md`: `BridgeManager postMessage uses wildcard origin` → clarified (read-side origin/source validation is the primary issue)
+- `AUDIT_NETWORKING.md`: `GraphQL Injection in getPlayerCosmetics` → clarified (string interpolation sink exists; exploitability depends on trust boundary)
+
+## Verified High-Risk Items (Shortlist)
+
+The following are confirmed and worth prioritizing:
+
+- [VERIFIED-TRUE] `SSL_KEY` committed in-repo (publicly trusted cert; wildcard SAN)
+- [VERIFIED-TRUE] Client UI pipeline executes fetched HTML + scripts (XSS/trust-model risk)
+- [VERIFIED-NUANCE] Bridge message handler accepts commands without origin/source validation
+- [VERIFIED-TRUE] PlayerEntity adds chat listener on spawn without removing it on despawn
+- [VERIFIED-TRUE] DefaultPlayerEntity cosmetics promise can resolve after despawn and spawn child entities
+
+## Full Findings Index (All Reports)
+
+### AUDIT_NETWORKING.md
+
+- 01. [SECURITY] SSL Private Key Shipped in Source Code — `server/src/networking/ssl/certs.ts:100-127` — [VERIFIED-TRUE]
+- 02. [BUG] Asset Cache Serves Stale Data After File Changes — `server/src/networking/WebServer.ts:242-257` — [VERIFIED-TRUE]
+- 03. [BUG] WebSocket Reconnection: OPEN Event Race Condition — `server/src/networking/Socket.ts:113-119` — [UNVERIFIED]
+- 04. [BUG] Reconnect Window Timer Not Cleared on killDuplicateConnection — `server/src/networking/Connection.ts:346-351` — [UNVERIFIED]
+- 05. [PERFORMANCE] Synchronous gzipSync Blocks Event Loop — `server/src/networking/Connection.ts:183` — [UNVERIFIED]
+- 06. [PERFORMANCE] Per-Packet Validation in serializePackets is Redundant — `server/src/networking/Connection.ts:156-159` — [UNVERIFIED]
+- 07. [BUG] GraphQL Injection in getPlayerCosmetics — `server/src/networking/PlatformGateway.ts:200-201` — [VERIFIED-NUANCE]
+- 08. [BUG] WebTransport Writer Not Closed on Cleanup — `server/src/networking/Connection.ts:470-500` — [UNVERIFIED]
+- 09. [BUG] WebTransport Session Stream Iterator Never Terminates on Shutdown — `server/src/networking/Socket.ts:198-211` — [UNVERIFIED]
+- 10. [PERFORMANCE] Entity Sync Reliable/Unreliable Classification is Fragile — `server/src/networking/NetworkSynchronizer.ts:163-187` — [UNVERIFIED]
+- 11. [PERFORMANCE] onPacket Registers a New Listener Per Packet Type Without Filtering — `server/src/networking/Connection.ts:361-367` — [UNVERIFIED]
+- 12. [BUG] _onClose Fires Multiple Times for Dual-Transport Connections — `server/src/networking/Connection.ts:456-461` — [UNVERIFIED]
+- 13. [PERFORMANCE] Stale Asset Cache Grows Unbounded — `server/src/networking/WebServer.ts:121` — [UNVERIFIED]
+- 14. [BUG] WebSocket send() Can Throw on Closed Connection — `server/src/networking/Connection.ts:421` — [UNVERIFIED]
+- 15. [PERFORMANCE] Unframer Allocates 512KB Buffer Per WebTransport Connection — `protocol/packets/PacketCore.ts:108` — [UNVERIFIED]
+- 16. [BUG] _handleReconnect Returns True for New Transport Bindings (Not Just Reconnections) — `server/src/networking/Connection.ts:521-530` — [UNVERIFIED]
+- 17. [PERFORMANCE] Heartbeat Creates a New Packet Array on Every Beat — `server/src/networking/Connection.ts:434-439` — [UNVERIFIED]
+- 18. [FEATURE] No Rate Limiting on Inbound Packets — `server/src/networking/Connection.ts:441-454` — [UNVERIFIED]
+- 19. [FEATURE] No Maximum Message Size Enforcement for WebSocket — `server/src/networking/Socket.ts:66` — [UNVERIFIED]
+- 20. [BUG] PlatformGateway GraphQL WebSocket Connection Never Closes — `server/src/networking/PlatformGateway.ts:108-111` — [UNVERIFIED]
+- 21. [PERFORMANCE] NetworkSynchronizer Player Join Sends Full World State Without Chunking — `server/src/networking/NetworkSynchronizer.ts:1084-1148` — [UNVERIFIED]
+- 22. [BUG] CORS Allows All Origins — `server/src/networking/WebServer.ts:84` — [UNVERIFIED]
+- 23. [PERFORMANCE] serializePackets Cache Keyed by Array Identity, Not Content — `server/src/networking/Connection.ts:167` — [UNVERIFIED]
+- 24. [BUG] WebServer.stop() Does Not Clean Up _server Reference — `server/src/networking/WebServer.ts:176-186` — [VERIFIED-TRUE]
+- 25. [FEATURE] No Backpressure Handling for WebTransport Writes — `server/src/networking/Connection.ts:412-418` — [UNVERIFIED]
+- 26. [PERFORMANCE] msgpackr Float32 Quantization Reduces Precision — `server/src/shared/helpers/msgpackr.ts:7` — [UNVERIFIED]
+
+### AUDIT_SERVER_CORE.md
+
+- 01. [BUG] PersistenceManager.setPlayerData Never Persists to Storage — server/src/persistence/PersistenceManager.ts:115-121 — [CORRECTED-FALSE]
+- 02. [BUG] PersistenceManager.getGlobalData Crashes on Network Error (null deref) — server/src/persistence/PersistenceManager.ts:56-71 — [VERIFIED-NUANCE]
+- 03. [BUG] ErrorHandler.enableCrashProtection Registers Duplicate Handlers on Multiple Calls — server/src/errors/ErrorHandler.ts:108-122 — [UNVERIFIED]
+- 04. [BUG] Ticker._tick Swallows Non-Error Exceptions Silently — server/src/shared/classes/Ticker.ts:172-181 — [UNVERIFIED]
+- 05. [BUG] EventRouter.emit Returns True Even When Final Listener Throws — server/src/events/EventRouter.ts:46-57 — [UNVERIFIED]
+- 06. [BUG] SceneUI Constructor Rejects Valid Configurations (Neither Entity Nor Position) — server/src/worlds/ui/SceneUI.ts:140 — [UNVERIFIED]
+- 07. [PERFORMANCE] ModelRegistry.preloadModels Loads Models Sequentially — server/src/models/ModelRegistry.ts:181-187 — [UNVERIFIED]
+- 08. [PERFORMANCE] ModelRegistry._calculateChecksum Reads Entire File + Base64 Encodes — server/src/models/ModelRegistry.ts:545-553 — [UNVERIFIED]
+- 09. [PERFORMANCE] AudioManager/SceneUIManager/ParticleEmitterManager Entity Lookups Use Linear Scan — server/src/worlds/audios/AudioManager.ts:74-76 — [UNVERIFIED]
+- 10. [PERFORMANCE] BlockTextureRegistry._createPaddedTexture Iterates All Pixels Including Interior — server/src/textures/BlockTextureRegistry.ts:329-337 — [UNVERIFIED]
+- 11. [PERFORMANCE] Telemetry.getProcessStats Called Twice for Slow Ticks — server/src/metrics/Telemetry.ts:163-167 — [UNVERIFIED]
+- 12. [BUG] ModelRegistry._preprocessOptimizableModel Temp Files Can Collide — server/src/models/ModelRegistry.ts:778-781 — [UNVERIFIED]
+- 13. [BUG] ModelRegistry._optimizeModel Returns inputPath on First Run Failure, Skipping Remaining Runs — server/src/models/ModelRegistry.ts:678-681 — [UNVERIFIED]
+- 14. [BUG] Audio.setPosition Shallow-Compares Object References — server/src/worlds/audios/Audio.ts:423 — [UNVERIFIED]
+- 15. [FEATURE] EventRouter Has No Way to Remove All Listeners for a Specific Instance — server/src/events/EventRouter.ts — [UNVERIFIED]
+- 16. [FEATURE] ChatManager Command Registration Has No Duplicate Protection — server/src/worlds/chat/ChatManager.ts:114-116 — [UNVERIFIED]
+- 17. [FEATURE] ChatManager Has No Command Validation or Sanitization — server/src/worlds/chat/ChatManager.ts:164-175 — [UNVERIFIED]
+- 18. [PERFORMANCE] ModelRegistry Reads Source File Twice During Data Regeneration — server/src/models/ModelRegistry.ts:427-456 — [UNVERIFIED]
+- 19. [BUG] startServer Uses init.length for Arity Detection (Unreliable with Default Parameters) — server/src/GameServer.ts:74 — [UNVERIFIED]
+- 20. [BUG] Ticker Accumulator Can Cause Dropped Ticks When TICK_SLOW_UPDATE_CAP < MAX_ACCUMULATOR_TICK_MULTIPLE — server/src/shared/classes/Ticker.ts:4-5, 125-137 — [UNVERIFIED]
+- 21. [BUG] ErrorHandler Crash Protection Calls process.exit After 1 Second Regardless of Recovery — server/src/errors/ErrorHandler.ts:117-118 — [UNVERIFIED]
+- 22. [PERFORMANCE] Vector3/Quaternion Extend Float32Array (Allocation Cost) — server/src/shared/classes/Vector3.ts, Quaternion.ts — [UNVERIFIED]
+- 23. [BUG] ModelRegistry._optimizeModel Writes Checksum Even When UASTC Compression Fails — server/src/models/ModelRegistry.ts:695-703 — [UNVERIFIED]
+- 24. [FEATURE] AudioManager Never Cleans Up Non-Looping Audio That Finishes Playing — server/src/worlds/audios/AudioManager.ts — [UNVERIFIED]
+- 25. [BUG] Ajv Singleton Inconsistency: Class and Static Instance Are Different — server/src/shared/classes/Ajv.ts:12-16 — [UNVERIFIED]
+- 26. [FEATURE] PersistenceManager.setGlobalData Has No Retry Logic Unlike getGlobalData — server/src/persistence/PersistenceManager.ts:104-112 — [UNVERIFIED]
+- 27. [FEATURE] SceneUI State Merge Is Shallow Only — server/src/worlds/ui/SceneUI.ts:273-274 — [UNVERIFIED]
+- 28. [BUG] EventRouter.emit listenerCount Check Disagrees with Actual Emission — server/src/events/EventRouter.ts:47 — [UNVERIFIED]
+- 29. [PERFORMANCE] BlockTextureRegistry.preloadAtlas Loads All Textures Into Memory At Once — server/src/textures/BlockTextureRegistry.ts:168-179 — [UNVERIFIED]
+- 30. [FEATURE] ModelRegistry Has No Way to Register Models at Runtime — server/src/models/ModelRegistry.ts — [UNVERIFIED]
+- 31. [BUG] AssetsLibrary.syncAsset Uses Relative Path Without CWD Context — server/src/assets/AssetsLibrary.ts:72-73 — [UNVERIFIED]
+
+### AUDIT_ENTITIES_PLAYERS.md
+
+- 01. [BUG] ColliderMap entity entries leak on entity despawn — server/src/worlds/entities/Entity.ts:1323 (spawn) and server/src/worlds/entities/Entity.ts:782 (despawn) — [CORRECTED-FALSE]
+- 02. [BUG] PlayerEntity.spawn() leaks event listener on player — server/src/worlds/entities/PlayerEntity.ts:137 — [VERIFIED-TRUE]
+- 03. [BUG] DefaultPlayerEntity cosmetics applied after despawn (race condition) — server/src/worlds/entities/DefaultPlayerEntity.ts:122 — [VERIFIED-TRUE]
+- 04. [BUG] EntityManager._nextEntityId monotonically increases (no recycling) — server/src/worlds/entities/EntityManager.ts:66 — [UNVERIFIED]
+- 05. [PERFORMANCE] PathfindingEntityController._reconstructPath uses array.unshift() in loop — server/src/worlds/entities/controllers/PathfindingEntityController.ts:516-525 — [VERIFIED-TRUE]
+- 06. [PERFORMANCE] PathfindingEntityController._coordinateToKey creates strings per call — server/src/worlds/entities/controllers/PathfindingEntityController.ts:528-530 — [VERIFIED-TRUE]
+- 07. [PERFORMANCE] PathfindingEntityController._findGroundedStart allocates spread objects in loop — server/src/worlds/entities/controllers/PathfindingEntityController.ts:651-666 — [UNVERIFIED]
+- 08. [PERFORMANCE] EntityManager query methods allocate arrays every call — server/src/worlds/entities/EntityManager.ts:97-213 — [UNVERIFIED]
+- 09. [BUG] DefaultPlayerEntityController ground contact count can go negative — server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:503 — [UNVERIFIED]
+- 10. [BUG] DefaultPlayerEntityController._stepAudio not cleaned up on detach/despawn — server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:414-421 — [UNVERIFIED]
+- 11. [BUG] Player.joinWorld() world switch calls disconnect which triggers LEFT_WORLD twice — server/src/players/Player.ts:295-321 — [UNVERIFIED]
+- 12. [BUG] SimpleEntityController.tick() face yaw extraction is approximate — server/src/worlds/entities/controllers/SimpleEntityController.ts:487-489 — [UNVERIFIED]
+- 13. [PERFORMANCE] DefaultPlayerEntityController.tickWithPlayerInput allocates objects per tick — server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:565-789 — [UNVERIFIED]
+- 14. [BUG] Entity.setModelScale division by zero when current scale component is 0 — server/src/worlds/entities/Entity.ts:1041-1045 — [UNVERIFIED]
+- 15. [BUG] PathfindingEntityController setTimeout leaks if entity despawns during jump delay — server/src/worlds/entities/controllers/PathfindingEntityController.ts:571-601 — [UNVERIFIED]
+- 16. [PERFORMANCE] EntityManager.getEntityChildren scans all entities O(N) — server/src/worlds/entities/EntityManager.ts:203-213 — [UNVERIFIED]
+- 17. [BUG] Player._onInputPacket sequence number check allows replay on wrap — server/src/players/Player.ts:522-525 — [UNVERIFIED]
+- 18. [BUG] PlayerEntity.tick has unnecessary semicolon after return guard — server/src/worlds/entities/PlayerEntity.ts:146 — [UNVERIFIED]
+- 19. [FEATURE] Entity despawn should clear all event listeners to prevent leaks — server/src/worlds/entities/Entity.ts:782-809 — [UNVERIFIED]
+- 20. [FEATURE] PlayerUI.sendData and PlayerUI.load lack input validation — server/src/players/PlayerUI.ts:97-210 — [UNVERIFIED]
+- 21. [FEATURE] PathfindingEntityController path caching for repeated destinations — server/src/worlds/entities/controllers/PathfindingEntityController.ts:284-308 — [UNVERIFIED]
+- 22. [PERFORMANCE] PathfindingEntityController A* pushes duplicate entries to open set — server/src/worlds/entities/controllers/PathfindingEntityController.ts:495 — [UNVERIFIED]
+- 23. [FEATURE] Entity re-spawn support — server/src/worlds/entities/Entity.ts:1323-1388 — [UNVERIFIED]
+- 24. [BUG] DefaultPlayerEntityController.attach monkey-patches entity.applyImpulse permanently — server/src/worlds/entities/controllers/DefaultPlayerEntityController.ts:405-412 — [UNVERIFIED]
+- 25. [BUG] Entity.spawn registers colliders in colliderMap but child-added colliders from controllers are not — server/src/worlds/entities/Entity.ts:1383-1385 and controllers/DefaultPlayerEntityController.ts:478-535 — [UNVERIFIED]
+- 26. [PERFORMANCE] Entity.modelAnimations and Entity.modelNodeOverrides return new arrays every access — server/src/worlds/entities/Entity.ts:593 and 604 — [UNVERIFIED]
+- 27. [BUG] Player.interact only raycasts against the first player entity — server/src/players/Player.ts:542 — [UNVERIFIED]
+
+### AUDIT_PHYSICS_WORLDS.md
+
+- 01. [PERFORMANCE] Ticker uses setTimeout for 60 Hz loop - inherent jitter — `server/src/shared/classes/Ticker.ts:147` — [UNVERIFIED]
+- 02. [PERFORMANCE] Trimesh collider fully recreated on every single block edit — `server/src/worlds/blocks/ChunkLattice.ts:457-461` and `server/src/worlds/blocks/ChunkLattice.ts:485-487` — [UNVERIFIED]
+- 03. [PERFORMANCE] `_combineVoxelStates` is O(N^2) in number of block types — `server/src/worlds/blocks/ChunkLattice.ts:507-514` — [UNVERIFIED]
+- 04. [BUG] `Chunk.globalCoordinateToOriginCoordinate` fails for negative coordinates — `server/src/worlds/blocks/Chunk.ts:132-138` — [UNVERIFIED]
+- 05. [BUG] `globalCoordinateToLocalCoordinate` silently produces wrong results for non-integer inputs — `server/src/worlds/blocks/Chunk.ts:116-122` — [UNVERIFIED]
+- 06. [PERFORMANCE] `_propagateVoxelChange` iterates ALL block type colliders for every single block edit — `server/src/worlds/blocks/ChunkLattice.ts:517-524` — [UNVERIFIED]
+- 07. [PERFORMANCE] `getAllChunks()` and `getAllWorlds()` create new arrays every call — `server/src/worlds/blocks/ChunkLattice.ts:268` and `server/src/worlds/WorldManager.ts:116` — [UNVERIFIED]
+- 08. [BUG] `RigidBody.removeFromSimulation` nullifies `_rigidBodyDesc`, making body non-reusable — `server/src/worlds/physics/RigidBody.ts:1490-1505` — [UNVERIFIED]
+- 09. [BUG] World.stop() does not clean up entities, physics, or sub-managers — `server/src/worlds/World.ts:787-796` — [UNVERIFIED]
+- 10. [PERFORMANCE] Telemetry spans created every single tick even when telemetry is disabled — `server/src/worlds/WorldLoop.ts:157-187` — [UNVERIFIED]
+- 11. [PERFORMANCE] Simulation event emission on every step even without listeners — `server/src/worlds/physics/Simulation.ts:516-544` — [UNVERIFIED]
+- 12. [PERFORMANCE] `getWorldsByTag` does linear scan of all worlds — `server/src/worlds/WorldManager.ts:151-161` — [UNVERIFIED]
+- 13. [BUG] `ColliderMap` double-buffered cleanup may miss rapid add-remove-add sequences — `server/src/worlds/physics/ColliderMap.ts:134-211` — [UNVERIFIED]
+- 14. [BUG] `setBlock` early-return skips rotation-only changes when same blockTypeId — `server/src/worlds/blocks/ChunkLattice.ts:430` — [UNVERIFIED]
+- 15. [FEATURE] No way to remove/destroy a world from WorldManager — `server/src/worlds/WorldManager.ts` — [UNVERIFIED]
+- 16. [PERFORMANCE] BigInt chunk keys have overhead vs integer keys — `server/src/worlds/blocks/ChunkLattice.ts:615-621` — [UNVERIFIED]
+- 17. [PERFORMANCE] `_getBlockTypePlacements` iterates all chunk masks with bit scanning — `server/src/worlds/blocks/ChunkLattice.ts:556-601` — [UNVERIFIED]
+- 18. [BUG] `MAX_BLOCK_TYPE_ID = 255` limits world to 255 block types — `server/src/worlds/blocks/Chunk.ts:21` — [UNVERIFIED]
+- 19. [PERFORMANCE] BLOCK_ROTATIONS_BY_INDEX sorted on every loadMap call — `server/src/worlds/World.ts:514` — [UNVERIFIED]
+- 20. [BUG] Raycast epsilon adjustment assumes axis-aligned ray directions — `server/src/worlds/physics/Simulation.ts:455-464` — [UNVERIFIED]
+- 21. [PERFORMANCE] `_applyRigidBodyOptions` and `_applyColliderOptions` create arrays of bound functions — `server/src/worlds/physics/RigidBody.ts:1601-1627` and `server/src/worlds/physics/Collider.ts:1572-1593` — [UNVERIFIED]
+- 22. [BUG] No validation of collision group values in `CollisionGroupsBuilder` — `server/src/worlds/physics/CollisionGroupsBuilder.ts:97-100` — [UNVERIFIED]
+- 23. [PERFORMANCE] `intersectionsWithRawShape` deduplicates using a Set but creates objects for every result — `server/src/worlds/physics/Simulation.ts:372-407` — [UNVERIFIED]
+- 24. [FEATURE] No world-level entity spatial query (nearest entity, entities in radius) — `server/src/worlds/World.ts` — [UNVERIFIED]
+- 25. [PERFORMANCE] Ticker accumulator clamp may lose time under sustained load — `server/src/shared/classes/Ticker.ts:125-127` — [UNVERIFIED]
+- 26. [BUG] `_requireNotRemoved` in RigidBody uses `ErrorHandler.error` (non-fatal) but returns boolean — `server/src/worlds/physics/RigidBody.ts:1733-1738` — [UNVERIFIED]
+- 27. [BUG] `World.loadMap` entities spawn during construction before world starts — `server/src/worlds/World.ts:327-329` and `server/src/worlds/World.ts:557-573` — [UNVERIFIED]
+- 28. [FEATURE] No block-level metadata or per-block events — `server/src/worlds/blocks/Chunk.ts` and `server/src/worlds/blocks/BlockType.ts` — [UNVERIFIED]
+- 29. [PERFORMANCE] `_onCollisionEvent` and `_onContactForceEvent` do redundant lookups — `server/src/worlds/physics/Simulation.ts:548-567` and `server/src/worlds/physics/Simulation.ts:570-593` — [UNVERIFIED]
+- 30. [PERFORMANCE] ChunkLattice rigid body created lazily but never removed — `server/src/worlds/blocks/ChunkLattice.ts:340-343` and `server/src/worlds/blocks/ChunkLattice.ts:434-437` — [UNVERIFIED]
+- 31. [BUG] `newCount` calculation in `setBlock` removal path has off-by-one potential — `server/src/worlds/blocks/ChunkLattice.ts:441` — [UNVERIFIED]
+- 32. [FEATURE] No chunk unloading for distant/empty chunks — `server/src/worlds/blocks/ChunkLattice.ts` — [UNVERIFIED]
+
+### AUDIT_CLIENT_SYSTEMS.md
+
+- 01. [BUG] BridgeManager postMessage uses wildcard origin -- security risk — `client/src/bridge/BridgeManager.ts:220` — [VERIFIED-NUANCE]
+- 02. [BUG] UIManager innerHTML injection allows XSS from server-controlled HTML — `client/src/ui/UIManager.ts:164` — [VERIFIED-TRUE]
+- 03. [BUG] Monkey-patched addEventListener does not track removeEventListener — `client/src/ui/UIManager.ts:20-31` — [UNVERIFIED]
+- 04. [PERFORMANCE] Deserializer creates many intermediate objects per packet — `client/src/network/Deserializer.ts:274-642` — [UNVERIFIED]
+- 05. [BUG] Input sequence numbers increment even when not sent — `client/src/network/NetworkManager.ts:200-206` — [UNVERIFIED]
+- 06. [BUG] WebSocket connection promise never rejects on failure — `client/src/network/NetworkManager.ts:325-342` — [UNVERIFIED]
+- 07. [BUG] setInterval timers in NetworkManager leak on reconnect — `client/src/network/NetworkManager.ts:156-157` — [UNVERIFIED]
+- 08. [BUG] Reliable WebTransport packet queue drops silently on overflow — `client/src/network/NetworkManager.ts:222-225` — [UNVERIFIED]
+- 09. [PERFORMANCE] InputManager sends discrete input changes immediately, no batching — `client/src/input/InputManager.ts:337-339` — [UNVERIFIED]
+- 10. [BUG] Mobile camera cleanup clears all camera positions when one finger lifts — `client/src/mobile/MobileManager.ts:143-147` — [UNVERIFIED]
+- 11. [BUG] SceneUI viewDistance of 0 cannot be set (falsy check) — `client/src/ui/UIManager.ts:291-293` — [UNVERIFIED]
+- 12. [BUG] AudioManager uses truthy checks for volume/playbackRate/offset, skipping value 0 — `client/src/audio/AudioManager.ts:87-101` — [UNVERIFIED]
+- 13. [BUG] Nametag chat message XSS vector via innerHTML-adjacent patterns — `client/src/ui/templates/Nametag.ts:62` — [UNVERIFIED]
+- 14. [BUG] Assets.urlExists caches errors permanently (rejected promises cached forever) — `client/src/network/Assets.ts:88-106` — [UNVERIFIED]
+- 15. [BUG] EntityManager._updateEntity processes updates on already-removed entities — `client/src/entities/EntityManager.ts:316-420` — [UNVERIFIED]
+- 16. [PERFORMANCE] EntityManager.findEntityByName is O(n) linear scan — `client/src/entities/EntityManager.ts:72-79` — [UNVERIFIED]
+- 17. [BUG] Modal overlay does not prevent body scrolling on mobile — `client/src/ui/Modal.ts:17-107` — [UNVERIFIED]
+- 18. [BUG] PlayerManager never cleans up player data, grows unbounded — `client/src/players/PlayerManager.ts:33-56` — [UNVERIFIED]
+- 19. [PERFORMANCE] AudioManager._cleanupIfNeeded creates a full array on every audio update — `client/src/audio/AudioManager.ts:135-141` — [UNVERIFIED]
+- 20. [PERFORMANCE] SettingsManager._levelChangeHistory grows unbounded — `client/src/settings/SettingsManager.ts:232` — [UNVERIFIED]
+- 21. [BUG] Heartbeat service starts unconditionally on module load, no cleanup — `client/src/services/hytopia/heartbeat.ts:60` — [UNVERIFIED]
+- 22. [BUG] CustomTextureManager.load promise never resolves on texture load failure — `client/src/textures/CustomTextureManager.ts:54-79` — [UNVERIFIED]
+- 23. [FEATURE] Input does not support key rebinding — `client/src/input/InputManager.ts:57-96` — [UNVERIFIED]
+- 24. [FEATURE] No client-side prediction or reconciliation for player movement — `client/src/input/InputManager.ts:287-303` — [UNVERIFIED]
+- 25. [BUG] Keyboard input with Shift key can double-fire due to both code and key mapping — `client/src/input/InputManager.ts:89-143` — [UNVERIFIED]
+- 26. [BUG] Translations service initializes with hardcoded production URL — `client/src/services/hytopia/translations.ts:4` — [UNVERIFIED]
+- 27. [PERFORMANCE] ParticleEmitter._updatePosition always updates matrix even when nothing changed — `client/src/particles/ParticleEmitter.ts:211-226` — [UNVERIFIED]
+- 28. [BUG] Arrow constructor error messages reference wrong field names — `client/src/arrows/Arrow.ts:70-71, 76-77` — [UNVERIFIED]
+- 29. [PERFORMANCE] Deserializer.deserializeBlocks/Chunks/etc use .map() creating intermediate arrays — `client/src/network/Deserializer.ts:297-374` — [UNVERIFIED]
+- 30. [BUG] SceneUI removeFromScene does not clean up containerDiv or template DOM — `client/src/ui/SceneUI.ts:142-144` — [UNVERIFIED]
+- 31. [BUG] SettingsManager quality adjustment has unreachable else branch — `client/src/settings/SettingsManager.ts:272` — [UNVERIFIED]
+- 32. [BUG] EntityStats.reset() clears frustumCulledCount twice — `client/src/entities/EntityStats.ts:22, 27` — [UNVERIFIED]
+- 33. [BUG] StaticEntity.updateLightLevel recalculates globalCoordinate from position that never changes — `client/src/entities/StaticEntity.ts:136-147` — [UNVERIFIED]
+- 34. [FEATURE] Mobile pinch-to-zoom should support touchpad two-finger gestures on desktop — `client/src/mobile/MobileManager.ts` — [UNVERIFIED]
+- 35. [PERFORMANCE] HytopiaUI.emitData iterates all callbacks even if data is targeted — `client/src/ui/globals/hytopia.ts:138-142` — [UNVERIFIED]
+
+### AUDIT_CLIENT_RENDERING.md
+
+- 01. PERFORMANCE — No greedy meshing in ChunkWorker — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 02. PERFORMANCE — ChunkWorker uses number[] arrays for geometry, then converts — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 03. PERFORMANCE — BoundaryVolume uses string-key Map for block lookups — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 04. PERFORMANCE — No frustum culling for chunk batch meshes — client/src/chunks/ChunkMeshManager.ts — [UNVERIFIED]
+- 05. BUG — DebugRenderer leaks geometries and materials — client/src/core/DebugRenderer.ts — [VERIFIED-TRUE]
+- 06. BUG — Liquid material time increment is frame-rate dependent — client/src/blocks/BlockMaterialManager.ts — [VERIFIED-TRUE]
+- 07. PERFORMANCE — Every-frame batch view distance check iterates all batches — client/src/chunks/ChunkManager.ts — [UNVERIFIED]
+- 08. PERFORMANCE — LightLevelVolume._getPackedIndex allocates object per call — client/src/chunks/LightLevelVolume.ts — [VERIFIED-TRUE]
+- 09. PERFORMANCE — AO cache in ChunkWorker uses linear scan of parallel arrays — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 10. PERFORMANCE — Light level calculation iterates all nearby light sources per block — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 11. PERFORMANCE — _clearNearbyLightSourceCache does cubic chunk iteration — client/src/workers/ChunkWorker.ts — [UNVERIFIED]
+- 12. PERFORMANCE — GLTFManager copies all instance attributes every frame — client/src/gltf/GLTFManager.ts — [UNVERIFIED]
+- 13. PERFORMANCE — ChunkMeshManager creates new BufferGeometry per update — client/src/chunks/ChunkMeshManager.ts — [UNVERIFIED]
+- 14. FEATURE — No LOD system for distant chunks — client/src/three/postprocessing/SelectiveOutlinePass.ts — [UNVERIFIED]
+- 15. PERFORMANCE — Outline pass 8-direction per-pixel search — client/src/three/postprocessing/SelectiveOutlinePass.ts — [UNVERIFIED]
+- 16. PERFORMANCE — Camera allocates vectors per frame in update methods — client/src/core/Camera.ts — [UNVERIFIED]
+- 17. PERFORMANCE — Chunk.getLightSources iterates all 4096 blocks — client/src/chunks/Chunk.ts — [UNVERIFIED]
+- 18. PERFORMANCE — CompressedTexture readback renders to screen then reads pixels — client/src/gltf/GLTFManager.ts — [UNVERIFIED]
+- 19. PERFORMANCE — Legacy BlockTextureAtlasManager has O(n) brute-force space finding — client/src/workers/BlockTextureAtlasManager.ts — [UNVERIFIED]
+- 20. PERFORMANCE — ChunkRegistry.getBatchChunkIds creates new array each call — client/src/chunks/ChunkRegistry.ts — [UNVERIFIED]
+- 21. BUG — PerformanceMetricsManager has double semicolon — client/src/core/PerformanceMetricsManager.ts — [UNVERIFIED]
+- 22. PERFORMANCE — CSS2DRenderer builds transform strings every frame — client/src/three/CSS2DRenderer.ts — [UNVERIFIED]
+- 23. PERFORMANCE — Post-processing chain runs all passes unconditionally — client/src/core/Renderer.ts — [UNVERIFIED]
+- 24. FEATURE — Transparent instanced mesh flicker at threshold boundary — client/src/gltf/GLTFManager.ts — [UNVERIFIED]
+- 25. FEATURE — No transparent instance sorting within InstancedMesh — client/src/gltf/GLTFManager.ts — [UNVERIFIED]
+- 26. PERFORMANCE — GLTFManager clones geometry for each InstancedMesh resize — client/src/gltf/GLTFManager.ts — [UNVERIFIED]
+- 27. PERFORMANCE — Block data not transferred (copied) between main thread and worker — client/src/workers/ChunkWorkerConstants.ts — [UNVERIFIED]
+- 28. PERFORMANCE — View model scene rendered separately adds extra render pass — client/src/core/Renderer.ts — [UNVERIFIED]
+
diff --git a/AUDIT_NETWORKING.md b/AUDIT_NETWORKING.md
new file mode 100644
index 00000000..d27b3c9e
--- /dev/null
+++ b/AUDIT_NETWORKING.md
@@ -0,0 +1,435 @@
+# Networking Layer Audit
+
+Audited files:
+- `server/src/networking/WebServer.ts`
+- `server/src/networking/Socket.ts`
+- `server/src/networking/Connection.ts`
+- `server/src/networking/PlatformGateway.ts`
+- `server/src/networking/NetworkSynchronizer.ts`
+- `server/src/networking/Serializer.ts`
+- `server/src/networking/ssl/certs.ts`
+- `protocol/packets/PacketCore.ts`
+- `protocol/packets/PacketDefinitions.ts`
+
+---
+
+### [SECURITY] SSL Private Key Shipped in Source Code
+**Benefit: 5/5 | Risk: 5/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/ssl/certs.ts:100-127`
+
+The SSL private key is committed directly into the source code repository. This is explicitly documented as intentional for local development (resolving `local.hytopiahosting.com` to `127.0.0.1`) and for WebTransport support. However, the same certificate covers `*.dns-is-boring-we-do-ip-addresses.hytopiahosting.com` (a wildcard). Anyone with access to this repo (it appears to be an SDK) can impersonate any subdomain of that wildcard. If this cert is used in production infrastructure beyond localhost, it constitutes a critical TLS vulnerability. The certificate expires `2026-12-19` so the window is limited but still open.
+
+**Recommendation:** Confirm this cert is ONLY used for local dev. In production, inject certs via environment variables or mounted secrets. Consider whether the wildcard SAN is truly needed for the shipped dev cert. If the repo is public, any user can MITM connections to `*.dns-is-boring-we-do-ip-addresses.hytopiahosting.com`.
+
+---
+
+### [BUG] Asset Cache Serves Stale Data After File Changes
+**Benefit: 4/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/WebServer.ts:242-257`
+
+The `_assetCache` Map caches `{ size, etag }` based on the file's mtime and size at the time of first access. Once cached, the metadata is never invalidated. If a file is modified on disk (common during development with hot-reload workflows), the server will continue serving the old etag/size, leading to:
+1. Incorrect `content-length` headers (truncated or padded responses).
+2. False 304 Not Modified responses when the file has actually changed.
+
+**Recommendation:** Either disable caching in dev mode, or re-stat the file periodically / on every request and compare mtime to invalidate the cache entry. A simple approach: always re-stat but keep the cached etag to avoid recomputing if mtime hasn't changed.
+
+---
+
+### [BUG] WebSocket Reconnection: OPEN Event Race Condition
+**Benefit: 4/5 | Risk: 3/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Socket.ts:113-119`
+
+```typescript
+this._wss.handleUpgrade(req, socket, head, ws => {
+  if (ws.readyState !== WebSocket.OPEN) {
+    ws.once('open', () => this._wss.emit('connection', ws, req));
+  } else {
+    this._wss.emit('connection', ws, req);
+  }
+});
+```
+
+The `ws` library's `handleUpgrade` callback delivers the WebSocket after the upgrade is complete; `readyState` should already be `OPEN`. The `once('open')` branch exists as a safety net but creates a subtle issue: if the WebSocket transitions to `CLOSING` or `CLOSED` before 'open' fires (e.g., client disconnects immediately), the 'open' event will never fire, and the connection will leak -- no Connection object is created, no cleanup occurs, and the `socket` reference from the upgrade is already detached. The `_connectionIdConnections` / `_userIdConnections` maps will not have an entry, but auth state (session lookup) was already performed and wasted.
+
+**Recommendation:** Remove the `readyState` branch since `handleUpgrade` guarantees OPEN state. If kept for safety, add a `ws.once('close')` handler in the non-OPEN branch to clean up.
+
+---
+
+### [BUG] Reconnect Window Timer Not Cleared on killDuplicateConnection
+**Benefit: 4/5 | Risk: 3/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:346-351`
+
+```typescript
+public killDuplicateConnection(): void {
+  this._isDuplicate = true;
+  this._cleanupConnections();
+  this.emitWithGlobal(ConnectionEvent.DISCONNECTED, { connection: this });
+  this._finalizeClose();
+}
+```
+
+`killDuplicateConnection` calls `_finalizeClose()` directly but does NOT clear `_closeTimeout`. If a previous disconnection already started the 30-second reconnect timer, `_finalizeClose()` will be called twice: once by `killDuplicateConnection` and once when the timeout fires. The second call emits `ConnectionEvent.CLOSED` again and calls `offAll()` on an already-cleaned-up EventRouter, which is harmless but wasteful. More importantly, the timeout callback holds a reference to the Connection, preventing GC for up to 30 seconds.
+
+**Recommendation:** Add `if (this._closeTimeout) { clearTimeout(this._closeTimeout); this._closeTimeout = null; }` at the start of `killDuplicateConnection`.
+
+---
+
+### [PERFORMANCE] Synchronous gzipSync Blocks Event Loop
+**Benefit: 4/5 | Risk: 3/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:183`
+
+```typescript
+outputBuffer = gzipSync(outputBuffer, { level: 1 });
+```
+
+`gzipSync` is called on the main thread during packet serialization. For chunk data that exceeds 64KB (which chunk packets commonly do), this blocks the event loop. With multiple players receiving chunk data simultaneously, this creates visible stutter. Level 1 is fast but still measurable for 100KB+ buffers.
+
+**Recommendation:** Consider pre-compressing chunk data when the chunk is generated (since chunk block data changes infrequently), or use a worker thread for compression. Alternatively, since the compressed result is cached by packet array identity, the cost is amortized per unique packet batch -- but the first serialization still blocks.
+
+---
+
+### [PERFORMANCE] Per-Packet Validation in serializePackets is Redundant
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:156-159`
+
+```typescript
+for (const packet of packets) {
+  if (!protocol.isValidPacket(packet)) {
+    return ErrorHandler.error(...);
+  }
+}
+```
+
+Every call to `serializePackets` validates each packet against its AJV schema before serializing. The packets were already constructed via `protocol.createPacket()` in `NetworkSynchronizer`, which also validates via `packetDef.validate(data)` (see `PacketCore.ts:94`). This means every outbound packet is validated twice. AJV schema validation is not free -- for complex schemas with nested objects (entities, chunks), this adds up.
+
+**Recommendation:** Remove the validation in `serializePackets` and rely on the `createPacket` validation. If paranoia is desired, gate this behind a debug flag.
+
+---
+
+### [BUG] GraphQL Injection in getPlayerCosmetics
+**Benefit: 4/5 | Risk: 4/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/PlatformGateway.ts:200-201`
+
+```typescript
+query: `{
+  userById(id: "${userId}") {
+```
+
+**Status (verified): sink is real; exploitability depends on trust boundary.**
+
+The `userId` parameter is interpolated directly into a GraphQL query string without sanitization. In the current code path, `userId` originates from platform session data (`session.user.id`) and is expected to be a platform-controlled identifier. That makes practical injection less likely today, but the pattern is still a footgun if this ever becomes user-controllable or if IDs stop being strictly validated.
+
+**Recommendation:** Use GraphQL variables instead of string interpolation:
+```typescript
+query: `query($id: String!) { userById(id: $id) { ... } }`,
+variables: { id: userId }
+```
+
+---
+
+### [BUG] WebTransport Writer Not Closed on Cleanup
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:470-500`
+
+`_cleanupConnections()` sets `_wtReliableWriter` and `_wtUnreliableWriter` to `undefined` without calling `.close()` on them first. The `WritableStreamDefaultWriter` holds a lock on the underlying stream. While the parent `WebTransportSession.close()` (called via the 50ms `setTimeout`) should eventually tear everything down, not explicitly releasing the writer lock means that if any async `.write()` is still in-flight, it may fail with a confusing "writer is locked" error rather than a clean shutdown.
+
+**Recommendation:** Call `this._wtReliableWriter?.close().catch(() => {})` and `this._wtUnreliableWriter?.close().catch(() => {})` before nulling them.
+
+---
+
+### [BUG] WebTransport Session Stream Iterator Never Terminates on Shutdown
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Socket.ts:198-211`
+
+```typescript
+private async _startWebTransport() {
+  this._wts.startServer();
+  for await (const wt of this._wts.sessionStream('/')) {
+    // ...
+  }
+}
+```
+
+The `for await` loop on `sessionStream('/')` will run indefinitely. There is no mechanism to break out of this loop on server shutdown. When `WebServer.stop()` is called, the HTTP/2 server closes, but the WebTransport (HTTP/3) server has no corresponding `stop()` call. This means the process may hang on shutdown, waiting for the session stream iterator to complete.
+
+**Recommendation:** Store the `_wts` server reference and call `_wts.stopServer()` (or equivalent) during shutdown. Add an `AbortController` to break the `for await` loop.
+
+---
+
+### [PERFORMANCE] Entity Sync Reliable/Unreliable Classification is Fragile
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/NetworkSynchronizer.ts:163-187`
+
+```typescript
+for (const key in entitySync) {
+  isReliableUpdate = key !== 'i' && key !== 'p' && key !== 'r';
+  if (isReliableUpdate) { break; }
+}
+```
+
+The reliable/unreliable classification iterates over entity sync object keys and checks if any key is NOT `i`, `p`, or `r`. This has two issues:
+1. **Fragile:** If new position/rotation-related keys are added to the entity schema (like interpolation hints), they will accidentally force reliable mode.
+2. **Incorrect classification:** The `for...in` loop breaks on the FIRST non-i/p/r key, but the final value of `isReliableUpdate` is always from the LAST iteration of the `for...in` loop body before the `break`. Actually, re-reading: it sets `isReliableUpdate` on every key and breaks when it finds a reliable key. But `for...in` order is not guaranteed by spec (though V8 does insertion order for string keys). If `r` (rotation as `[x,y,z,w]`) comes before `p` in the object, and there's also a property like `ri` (rotation interpolation), the logic works but is hard to reason about.
+
+**Recommendation:** Use an explicit allowlist Set: `const UNRELIABLE_KEYS = new Set(['i', 'p', 'r']); const isReliable = Object.keys(entitySync).some(k => !UNRELIABLE_KEYS.has(k));`
+
+---
+
+### [PERFORMANCE] onPacket Registers a New Listener Per Packet Type Without Filtering
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:361-367`
+
+```typescript
+public onPacket<T extends AnyPacket>(id: T[0], callback: (packet: T) => void): void {
+  this.on(ConnectionEvent.PACKET_RECEIVED, ({ packet }) => {
+    if (packet[0] === id) {
+      callback(packet as T);
+    }
+  });
+}
+```
+
+Every call to `onPacket` adds a new listener to `PACKET_RECEIVED`. Each incoming packet fires ALL registered `PACKET_RECEIVED` listeners, and each one checks `packet[0] === id`. For N registered packet types, every incoming packet triggers N comparisons. Currently only HEARTBEAT is registered via `onPacket` in the constructor, so this is not a real issue today. But if more packet types are registered (e.g., for plugins or custom handlers), this becomes O(N) per received packet.
+
+**Recommendation:** Consider a `Map<PacketId, callback[]>` dispatch table instead of N event listeners.
+
+---
+
+### [BUG] _onClose Fires Multiple Times for Dual-Transport Connections
+**Benefit: 3/5 | Risk: 3/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:456-461`
+
+A Connection can have both a WebSocket and a WebTransport bound simultaneously (during transport upgrades). Both transports wire `_onClose`:
+- WebSocket: `this._ws.onclose = this._onClose`
+- WebTransport: `wt.closed.finally(() => wt.userData.onclose?.())`
+
+If the connection has both transports active and the server calls `disconnect()` (which closes both), `_onClose` will fire twice. The first invocation starts the 30-second reconnect timer. The second invocation starts ANOTHER 30-second timer (overwriting `_closeTimeout` -- but the first `setTimeout` reference is lost and cannot be cleared). This means `_finalizeClose` will be called twice: once from the leaked first timeout, and once from the second.
+
+**Recommendation:** Guard `_onClose` to only fire once: `if (this._closeTimeout) return;` at the top of `_onClose`.
+
+---
+
+### [PERFORMANCE] Stale Asset Cache Grows Unbounded
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/WebServer.ts:121`
+
+`_assetCache` is a `Map<string, { size, etag }>` that is populated on first access and never evicted. For servers hosting many assets or dynamically generated content, this map grows without bound. Each entry is small (~100 bytes), but over long server lifetimes with many unique asset paths, this could become meaningful.
+
+**Recommendation:** Add a simple LRU eviction or periodic cache clear (e.g., clear every N minutes). For most game servers with a fixed asset set, this is low priority.
+
+---
+
+### [BUG] WebSocket send() Can Throw on Closed Connection
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:421`
+
+```typescript
+this._ws!.send(serializedBuffer);
+```
+
+The `readyState` is checked earlier (`this._ws && this._ws.readyState === WebSocket.OPEN`), but between the check and the `send()` call, the WebSocket could transition to CLOSING/CLOSED (e.g., if `_onClose` fires from a network event between these lines). The `ws` library's `send()` on a non-OPEN socket will throw synchronously. This throw IS caught by the outer `try/catch`, but it emits an `ErrorHandler.error` log for every packet sent to a recently-disconnected player, which could be noisy.
+
+**Recommendation:** Wrap the `ws.send()` in its own try/catch or check `readyState` again immediately before send.
+
+---
+
+### [PERFORMANCE] Unframer Allocates 512KB Buffer Per WebTransport Connection
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `protocol/packets/PacketCore.ts:108`
+
+```typescript
+let buffer = new Uint8Array(512 * 1024); // 512KB initial buffer
+```
+
+Each WebTransport reliable stream creates a 512KB buffer for the unframer. With 100 concurrent WebTransport connections, this is 50MB of pre-allocated memory that may mostly go unused (typical game packets are a few KB). The buffer grows via doubling up to 32MB.
+
+**Recommendation:** Start with a smaller initial buffer (e.g., 16KB or 64KB) and let the doubling growth handle the rare large-packet case. Most packets are well under 64KB (the compression threshold).
+
+---
+
+### [BUG] _handleReconnect Returns True for New Transport Bindings (Not Just Reconnections)
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:521-530`
+
+```typescript
+private _handleReconnect(): boolean {
+  const reconnected = !!this._ws || !!this._wt;
+  // ...
+  return reconnected;
+}
+```
+
+`_handleReconnect` returns `true` if either `_ws` or `_wt` existed before the new binding. This is called from both `bindWs` and `bindWt`. But when a client first connects via WebSocket and then upgrades to WebTransport (adding a second transport to the same Connection), `_handleReconnect` will return `true` even though this is a transport upgrade, not a reconnection. This causes `ConnectionEvent.RECONNECTED` to be emitted, triggering a full world re-sync for the player, which is wasteful.
+
+**Recommendation:** Distinguish between "transport upgrade on an active connection" (neither transport was closed) vs "reconnection after disconnection" (the reconnect timer was running). Only emit RECONNECTED when `_closeTimeout !== null`.
+
+---
+
+### [PERFORMANCE] Heartbeat Creates a New Packet Array on Every Beat
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:434-439`
+
+```typescript
+private _onHeartbeatPacket = () => {
+  this.send([ protocol.createPacket(protocol.bidirectionalPackets.heartbeatPacketDefinition, null) ], true);
+};
+```
+
+Every heartbeat response creates a new single-element array and a new packet object. Heartbeats are sent frequently (likely every ~30 seconds to prevent NGINX timeouts). While individually cheap, this creates unnecessary GC pressure. The heartbeat response packet is always identical.
+
+**Recommendation:** Create the heartbeat response packet once as a module-level constant and reuse it.
+
+---
+
+### [FEATURE] No Rate Limiting on Inbound Packets
+**Benefit: 3/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:441-454`
+
+There is no rate limiting on inbound packet processing. A malicious client could flood the server with packets (heartbeats, inputs, chat messages) at an extremely high rate. Each packet is deserialized (msgpack unpack) and validated (AJV schema check), consuming CPU. While `isValidPacket` rejects malformed data, the deserialization and validation cost is paid regardless.
+
+**Recommendation:** Add a simple per-connection packet rate limiter (e.g., max N packets per second). Disconnect clients that exceed the threshold.
+
+---
+
+### [FEATURE] No Maximum Message Size Enforcement for WebSocket
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Socket.ts:66`
+
+```typescript
+this._wss = new WebSocketServer({ noServer: true });
+```
+
+The `ws` WebSocketServer is created with `noServer: true` but no `maxPayload` option. The default `maxPayload` in `ws` is 100MB. A malicious client could send a single 100MB WebSocket message, causing the server to allocate 100MB for deserialization before any validation occurs.
+
+The WebTransport path has a 32MB `MAX_FRAME_BUFFER_SIZE` cap in the unframer, but WebSocket has no equivalent protection.
+
+**Recommendation:** Set `maxPayload` to a reasonable limit (e.g., 1MB or 2MB) when creating the WebSocketServer.
+
+---
+
+### [BUG] PlatformGateway GraphQL WebSocket Connection Never Closes
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/PlatformGateway.ts:108-111`
+
+```typescript
+this._gqlWs = graphQLWS.createClient({
+  url: 'wss://prod.gql.hytopia.com/graphql',
+  webSocketImpl: WebSocket,
+});
+```
+
+The `graphql-ws` client is created in the constructor and maintained as a singleton for the lifetime of the process. There is no `dispose()` call on server shutdown. The WebSocket connection to the GraphQL server will remain open until the process exits. This is generally fine for long-running servers, but during graceful shutdown sequences, this orphaned connection may prevent clean process exit.
+
+**Recommendation:** Add a `dispose()` method to PlatformGateway that calls `this._gqlWs.dispose()` and invoke it during server shutdown.
+
+---
+
+### [PERFORMANCE] NetworkSynchronizer Player Join Sends Full World State Without Chunking
+**Benefit: 2/5 | Risk: 3/5 | Effort: 4/5 | Surgical: no | Backwards Compatible: yes**
+
+File: `server/src/networking/NetworkSynchronizer.ts:1084-1148`
+
+When a player joins (`_onPlayerJoinedWorld`), the synchronizer queues the ENTIRE world state -- all audios, block types, chunks, entities, particle emitters, players, scene UIs, and world config -- into the per-player sync queue. This is all flushed in a single synchronize() tick. For worlds with hundreds of chunks and thousands of entities, this creates a massive spike in outbound bandwidth and serialization CPU. The resulting packet can exceed the 64KB gzip threshold, triggering synchronous compression.
+
+**Recommendation:** Implement a streaming join protocol that sends world state in phases (block types first, then chunks in batches, then entities). This requires client-side changes to handle partial initial state, so it is not backwards compatible with existing clients without protocol versioning.
+
+---
+
+### [BUG] CORS Allows All Origins
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/WebServer.ts:84`
+
+```typescript
+const CORS = { 'access-control-allow-origin': '*' };
+```
+
+The server sets `Access-Control-Allow-Origin: *` on all responses. Since this is a game asset server (not an API with cookies/auth), this is generally acceptable. However, if the server ever serves authenticated endpoints or sensitive data, this would need to be restricted.
+
+**Recommendation:** Low priority. Document the intentional `*` policy. If authenticated endpoints are ever added, scope CORS appropriately.
+
+---
+
+### [PERFORMANCE] serializePackets Cache Keyed by Array Identity, Not Content
+**Benefit: 2/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:167`
+
+```typescript
+const cachedSerializedBuffer = Connection._cachedPacketsSerializedBuffer.get(packets);
+```
+
+The cache uses the `packets` array reference as the Map key. This means two different array instances containing identical packets will NOT hit the cache. The cache only works because `NetworkSynchronizer.synchronize()` reuses the same array reference for shared broadcast packets (sent to all players). Per-player packets that happen to be identical will each be serialized separately.
+
+**Recommendation:** This is a design choice, not a bug. The identity-based caching is fast (O(1) lookup) and works well for the broadcast case which is the hot path. Content-based caching would require hashing the packet content, which could be more expensive than the serialization itself.
+
+---
+
+### [BUG] WebServer.stop() Does Not Clean Up _server Reference
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/WebServer.ts:176-186`
+
+```typescript
+public stop(): Promise<boolean> {
+  if (!this._server) { ... }
+  return new Promise((resolve, reject) => {
+    this._server!.close(err => (err ? reject(err) : resolve(true)));
+  });
+}
+```
+
+After `stop()` resolves, `this._server` still holds a reference to the closed server. A subsequent call to `start()` will return early with a warning ("already started") because `this._server` is truthy, even though the server is closed. The server cannot be restarted after stopping.
+
+**Recommendation:** Set `this._server = undefined` after successful close. The `_onStopped` callback is already wired to `close` event, so this could be done there.
+
+---
+
+### [FEATURE] No Backpressure Handling for WebTransport Writes
+**Benefit: 2/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/networking/Connection.ts:412-418`
+
+```typescript
+this._wtReliableWriter?.write(protocol.framePacketBuffer(serializedBuffer)).catch(() => { ... });
+this._wtUnreliableWriter?.write(serializedBuffer).catch(() => { ... });
+```
+
+WebTransport write operations return promises that are fire-and-forget (only catching errors). There is no backpressure mechanism -- if the client is slow to consume data, writes will queue up in the WebTransport layer. Unlike WebSocket (which has `bufferedAmount` and emits `drain`), the current implementation has no way to detect or respond to a slow consumer.
+
+**Recommendation:** Monitor `desiredSize` on the writable stream and skip/throttle unreliable packets when the buffer is filling up. For reliable packets, consider a per-connection write queue with a maximum depth.
+
+---
+
+### [PERFORMANCE] msgpackr Float32 Quantization Reduces Precision
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: no**
+
+File: `server/src/shared/helpers/msgpackr.ts:7`
+
+```typescript
+export default new Packr({ useFloat32: FLOAT32_OPTIONS.ALWAYS });
+```
+
+All floats are serialized as 32-bit (4 bytes) instead of 64-bit (8 bytes). This halves the space for float values but reduces precision from ~15 significant digits to ~7. For positions, rotations, and colors this is perfectly adequate. For accumulated timestamps or large coordinate values, precision loss could theoretically cause jitter. This is a deliberate trade-off for bandwidth savings and is flagged here only for documentation.
+
+**Recommendation:** No change needed. The precision is sufficient for game state. If sub-millimeter precision is ever needed at large world coordinates, consider selective Float64 for specific fields.
diff --git a/AUDIT_PERFORMANCE_VERIFIED.md b/AUDIT_PERFORMANCE_VERIFIED.md
new file mode 100644
index 00000000..78991f66
--- /dev/null
+++ b/AUDIT_PERFORMANCE_VERIFIED.md
@@ -0,0 +1,1034 @@
+# HYTOPIA Engine — Performance Findings (Verified)
+
+Date: 2026-03-03
+Branch: `analysis/codebase-audit`
+Method: Every claim read against actual source code, quoted, and independently assessed.
+
+## Verification Legend
+
+- **CONFIRMED** — Code does exactly what the claim says
+- **PARTIALLY CONFIRMED** — Pattern exists but impact overstated or mitigating factors present
+- **REJECTED** — Claim is wrong or materially misleading
+
+## Impact Scale
+
+- **Significant** — Measurable frame/tick time impact in normal gameplay
+- **Moderate** — Real cost, but bounded or infrequent
+- **Low** — Correct observation, negligible runtime cost
+- **Trivial** — Technically true but irrelevant in practice
+
+---
+
+## Summary Table — All 40 Claims
+
+### Server (20 claims)
+
+| # | Claim | Verdict | Impact |
+|---|-------|---------|--------|
+| S1 | Trimesh collider fully recreated per block edit | CONFIRMED | Moderate |
+| S2 | `gzipSync` blocks event loop | CONFIRMED | Moderate |
+| S3 | Sequential model loading at startup | CONFIRMED | Moderate (startup only) |
+| S4 | Full world state queued on player join | PARTIALLY CONFIRMED | Moderate |
+| S5 | BigInt chunk keys overhead | CONFIRMED | Low (necessary tradeoff) |
+| S6 | `_propagateVoxelChange` iterates all colliders | CONFIRMED | Low |
+| S7 | `_combineVoxelStates` O(K²) | PARTIALLY CONFIRMED | Trivial (init only) |
+| S8 | Per-packet AJV validation redundant | PARTIALLY CONFIRMED | Trivial |
+| S9 | Vector3/Quaternion extend Float32Array | CONFIRMED | Trivial (gl-matrix interop) |
+| S10 | `getAllChunks()`/`getAllWorlds()` create arrays | CONFIRMED | Trivial |
+| S11 | Heartbeat creates packet array per beat | CONFIRMED | Trivial |
+| S12 | Bound function arrays in options apply | CONFIRMED | Trivial |
+| S13 | Checksum reads + base64 encodes file | CONFIRMED | Trivial (startup only) |
+| S14 | Linear scan for entity-attached lookups | CONFIRMED | Trivial |
+| S15 | Padded texture iterates interior pixels | CONFIRMED | Trivial (startup only) |
+| S16 | Fragile reliable/unreliable classification | CONFIRMED | Low (maintainability) |
+| S17 | Telemetry spans when disabled | **REJECTED** | N/A |
+| S18 | `getProcessStats` called twice | **REJECTED** | N/A |
+| S19 | setTimeout makes 60Hz unreliable | PARTIALLY CONFIRMED | Trivial (correct pattern) |
+| S20 | Events emitted without listeners | PARTIALLY CONFIRMED | Trivial |
+
+### Client (20 claims)
+
+| # | Claim | Verdict | Impact |
+|---|-------|---------|--------|
+| C1 | No greedy meshing | CONFIRMED | **Significant** |
+| C2 | Light iterates all sources per block | CONFIRMED | **Significant** |
+| C3 | number[] then convert to typed arrays | CONFIRMED | Moderate |
+| C4 | BoundaryVolume string-key Map | CONFIRMED | Moderate |
+| C5 | Every-frame batch view distance iteration | CONFIRMED | Moderate |
+| C6 | Instance attributes copied every frame | PARTIALLY CONFIRMED | Moderate |
+| C7 | New BufferGeometry per chunk update | CONFIRMED | Moderate |
+| C8 | Camera allocates vectors per frame | CONFIRMED | Moderate |
+| C9 | Outline pass 8-direction search | PARTIALLY CONFIRMED | Moderate |
+| C10 | `getLightSources` scans 4096 blocks | PARTIALLY CONFIRMED | Low (cached) |
+| C11 | CSS2D transform strings per frame | PARTIALLY CONFIRMED | Low |
+| C12 | Geometry cloned on InstancedMesh resize | CONFIRMED | Low |
+| C13 | Block data copied not transferred | CONFIRMED | Low (intentional) |
+| C14 | Deserializer intermediate objects | CONFIRMED | Low |
+| C15 | AO cache linear scan | CONFIRMED | Trivial |
+| C16 | `getBatchChunkIds` creates array | CONFIRMED | Trivial |
+| C17 | Legacy atlas O(n) space finding | CONFIRMED | Trivial |
+| C18 | No frustum culling for batches | **REJECTED** | N/A |
+| C19 | Post-processing all passes unconditional | **REJECTED** | N/A |
+| C20 | Outline pass 8-dir search (duplicate of C9) | PARTIALLY CONFIRMED | Moderate |
+
+---
+
+## Full Evidence — Server Performance
+
+---
+
+### S1: Trimesh collider fully recreated on every block edit
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`server/src/worlds/blocks/ChunkLattice.ts:457-461`:
+```typescript
+if (collider.isTrimesh) {
+  this._recreateTrimeshCollider(previousBlockTypeId);
+}
+```
+
+`server/src/worlds/blocks/ChunkLattice.ts:485-487`:
+```typescript
+if (collider.isTrimesh) {
+  this._recreateTrimeshCollider(blockTypeId);
+}
+```
+
+`server/src/worlds/blocks/ChunkLattice.ts:527-541` — the recreate method:
+```typescript
+private _recreateTrimeshCollider(blockTypeId: number): void {
+    const existingCollider = this._blockTypeColliders.get(blockTypeId);
+    if (existingCollider) {
+      existingCollider.removeFromSimulation();
+      this._blockTypeColliders.delete(blockTypeId);
+    }
+    const blockType = this._world.blockTypeRegistry.getBlockType(blockTypeId);
+    const blockPlacements = this._getBlockTypePlacements(blockTypeId);
+    const collider = this.getOrCreateBlockTypeCollider(blockTypeId, blockPlacements);
+    collider.addToSimulation(this._world.simulation, this._rigidBody);
+    this._world.simulation.colliderMap.setColliderBlockType(collider, blockType);
+}
+```
+
+**Analysis:** Every `setBlock` call on a trimesh block type removes the old collider from simulation, gathers ALL block placements for that type, and creates a brand-new collider. Both the removal path (line 457) and the addition path (line 485) trigger full rebuilds. However, standard voxel colliders (the common case) use incremental `setVoxel()` — only custom-mesh (trimesh) block types suffer this. Impact scales with how frequently trimesh blocks are edited at runtime.
+
+---
+
+### S2: Synchronous gzipSync blocks event loop
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`server/src/networking/Connection.ts:183`:
+```typescript
+if (outputBuffer.byteLength > 64 * 1024) {
+  outputBuffer = gzipSync(outputBuffer, { level: 1 });
+}
+```
+
+**Analysis:** `gzipSync` from the `zlib` module is called synchronously on the main thread. The compression level is 1 (fastest), and it only triggers for payloads >64KB (primarily chunk data on player join). The result is cached (`Connection._cachedPacketsSerializedBuffer`), so repeated sends of the same data don't re-compress. During normal gameplay, few packets exceed 64KB. Estimated 0.5-2ms per call for typical chunk sizes. The fix is a 1-line change to async `gzip`.
+
+---
+
+### S3: Sequential model loading at startup
+
+**Verdict: CONFIRMED | Impact: Moderate (startup only)**
+
+`server/src/models/ModelRegistry.ts:181-187`:
+```typescript
+for (const absoluteModelPath of absoluteModelPaths) {
+    if (this.optimize) {
+      await this._resolveOptimizedModelPath(absoluteModelPath);
+    }
+    await this._loadModelData(absoluteModelPath);
+}
+```
+
+**Analysis:** Models are loaded sequentially with `await` in a `for` loop. Each model must finish loading (and potentially optimizing) before the next starts. `Promise.all` with a concurrency limit could parallelize I/O. Note: the optimization step (`_resolveOptimizedModelPath`) runs shell commands (`npx @gltf-transform/cli`), which might contend for CPU if parallelized aggressively. Zero runtime impact — startup-only cost.
+
+---
+
+### S4: Full world state queued on player join
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Moderate**
+
+`server/src/networking/NetworkSynchronizer.ts:1084-1149`:
+```typescript
+private _onPlayerJoinedWorld = (payload: EventPayloads[PlayerEvent.JOINED_WORLD]) => {
+    const { player } = payload;
+    // Sync Audio
+    for (const audio of this._world.audioManager.getAllAudios()) { ... }
+    // Sync Block Types
+    for (const blockType of this._world.blockTypeRegistry.getAllBlockTypes()) { ... }
+    // Sync Camera ...
+    // Sync Chunks
+    for (const chunk of this._world.chunkLattice.getAllChunks()) { ... }
+    // Sync Entities
+    for (const entity of this._world.entityManager.getAllEntities()) { ... }
+    // Sync Particle Emitters, Players, Scene UIs, World ...
+};
+```
+
+**Analysis:** All world state is queued for the joining player — all chunks, entities, audio, particles, UI. However, it does NOT send them all at once. It queues them into the per-player sync queue (`_createOrGetQueuedChunkSync(chunk, player)`), and the actual sending happens in `synchronize()` on the next network sync tick, which batches into packets. The state IS sent in one synchronization cycle (not streamed over multiple ticks), which produces a burst. The original claim that there's "no chunking" is misleading — data is organized per-chunk/entity, just flushed in one go.
+
+---
+
+### S5: BigInt chunk keys have overhead vs integer keys
+
+**Verdict: CONFIRMED | Impact: Low (necessary tradeoff)**
+
+`server/src/worlds/blocks/ChunkLattice.ts:615-621`:
+```typescript
+private _packCoordinate(coordinate: Vector3Like): bigint {
+    const x = BigInt.asUintN(CHUNK_KEY_COORD_BITS, BigInt(Math.trunc(coordinate.x)));
+    const y = BigInt.asUintN(CHUNK_KEY_COORD_BITS, BigInt(Math.trunc(coordinate.y)));
+    const z = BigInt.asUintN(CHUNK_KEY_COORD_BITS, BigInt(Math.trunc(coordinate.z)));
+    return (x << CHUNK_KEY_X_SHIFT) | (y << CHUNK_KEY_Y_SHIFT) | z;
+}
+```
+
+Where `CHUNK_KEY_COORD_BITS = 54` (3 × 54 = 162 bits total).
+
+**Analysis:** BigInt operations are slower than Number operations in V8 — Map lookups with BigInt keys can't use SMI (Small Integer) optimizations. However, the reason is clear: they need to pack three 54-bit coordinates into a single key, which exceeds JavaScript's 53-bit safe integer range. A 32-bit packing (10-11 bits per axis) would severely limit world size. This is a deliberate tradeoff. String keys like `"x,y,z"` would likely be similar or worse performance. Microsecond-level overhead per lookup.
+
+---
+
+### S6: `_propagateVoxelChange` iterates ALL block type colliders per block edit
+
+**Verdict: CONFIRMED | Impact: Low**
+
+`server/src/worlds/blocks/ChunkLattice.ts:517-524`:
+```typescript
+private _propagateVoxelChange(collider: Collider, coordinate: Vector3Like): void {
+    if (collider.isSensor) { return; }
+    for (const otherCollider of this._blockTypeColliders.values()) {
+      if (otherCollider === collider || otherCollider.isSensor || !otherCollider.isVoxel) { continue; }
+      collider.propagateVoxelChange(otherCollider, coordinate);
+    }
+}
+```
+
+Called from `setBlock` at lines 454 and 482.
+
+**Analysis:** Every voxel block edit iterates all block type colliders — O(K) per edit where K = number of distinct block type colliders. `propagateVoxelChange` is a lightweight coordinate-specific update on each neighboring collider. K is typically small (10-50), and the per-iteration work is minimal.
+
+---
+
+### S7: `_combineVoxelStates` is O(K²) in number of block types
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Trivial**
+
+`server/src/worlds/blocks/ChunkLattice.ts:507-514`:
+```typescript
+private _combineVoxelStates(collider: Collider): void {
+    if (collider.isSensor || !collider.isVoxel) { return; }
+    for (const otherCollider of this._blockTypeColliders.values()) {
+      if (otherCollider === collider || otherCollider.isSensor || !otherCollider.isVoxel) { continue; }
+      collider.combineVoxelStates(otherCollider);
+    }
+}
+```
+
+**Analysis:** Called from `initializeBlockEntries` (line 393) inside a loop over all block types (line 379), making total initialization cost O(K²). But during `setBlock` (incremental edits), `_combineVoxelStates` is only called for new colliders (line 477, when `newCount === 1`), making that path O(K). The K² cost only applies to bulk initialization. K (distinct block types with active voxel colliders) is typically 10-50, so K² is negligible.
+
+---
+
+### S8: Per-packet validation in serializePackets is redundant
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Trivial**
+
+`server/src/networking/Connection.ts:155-159`:
+```typescript
+public static serializePackets(packets: AnyPacket[]): Buffer | void {
+    for (const packet of packets) {
+      if (!protocol.isValidPacket(packet)) {
+        return ErrorHandler.error(`Connection.serializePackets(): Invalid packet payload: ${JSON.stringify(packet)}`);
+      }
+    }
+```
+
+**Analysis:** Validation happens before serialization as a defensive check. Whether it's "redundant" depends on whether packets are already validated at creation. AJV compiled validators are fast, and the caching mechanism that follows (line 167 — cache keyed by array identity) means re-validation only happens once per unique packet array. Trivial overhead.
+
+---
+
+### S9: Vector3/Quaternion extend Float32Array (allocation cost)
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/shared/classes/Vector3.ts:24`:
+```typescript
+export default class Vector3 extends Float32Array implements Vector3Like {
+  public constructor(x: number, y: number, z: number) {
+    super([ x, y, z ]);
+  }
+```
+
+`server/src/shared/classes/Quaternion.ts:22`:
+```typescript
+export default class Quaternion extends Float32Array implements QuaternionLike {
+  public constructor(x: number, y: number, z: number, w: number) {
+    super([ x, y, z, w ]);
+  }
+```
+
+**Analysis:** TypedArrays have higher allocation overhead than plain objects due to backing ArrayBuffer allocation. This is intentional: enables zero-copy interop with gl-matrix and potentially WebAssembly/Rapier. The `Vector3Like` and `QuaternionLike` interfaces (plain `{x, y, z}` objects) are used throughout hot paths. The gl-matrix interop benefit outweighs the allocation overhead.
+
+---
+
+### S10: `getAllChunks()` and `getAllWorlds()` create new arrays every call
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/worlds/blocks/ChunkLattice.ts:268`:
+```typescript
+public getAllChunks(): Chunk[] {
+    return Array.from(this._chunks.values());
+}
+```
+
+`server/src/worlds/WorldManager.ts:116`:
+```typescript
+public getAllWorlds(): World[] {
+    return Array.from(this._worlds.values());
+}
+```
+
+**Analysis:** Both create new arrays via `Array.from()` on each call. `getAllWorlds` is trivial (1-3 worlds). `getAllChunks` creates arrays of hundreds of elements but is only called during player join sync and world initialization — NOT per-tick.
+
+---
+
+### S11: Heartbeat creates new packet array on every beat
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/networking/Connection.ts:434-439`:
+```typescript
+private _onHeartbeatPacket = () => {
+    this.send([ protocol.createPacket(protocol.bidirectionalPackets.heartbeatPacketDefinition, null) ], true);
+};
+```
+
+**Analysis:** Each heartbeat response creates a new single-element array and packet object. Heartbeats are infrequent (keepalive interval). V8's generational GC handles this efficiently.
+
+---
+
+### S12: `_applyRigidBodyOptions` and `_applyColliderOptions` create arrays of bound functions
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/worlds/physics/RigidBody.ts:1601-1627`:
+```typescript
+private _applyRigidBodyOptions(options: RigidBodyOptions) {
+    const setters: Array<[string, (value: any) => void]> = [
+      [ 'additionalMass', this.setAdditionalMass.bind(this) ],
+      [ 'additionalMassProperties', this.setAdditionalMassProperties.bind(this) ],
+      ...17 entries total...
+    ];
+    setters.forEach(([ key, setter ]) => {
+      if (key in options) {
+        setter(options[key as keyof typeof options]);
+      }
+    });
+}
+```
+
+Same pattern in `Collider.ts:1572-1593` with ~12 entries.
+
+**Analysis:** Each call creates ~12-17 `[string, function]` tuples with `.bind(this)` closures, discarded after the loop. Only called during entity/collider construction, not per-tick. Microseconds of work.
+
+---
+
+### S13: `_calculateChecksum` reads entire file + base64 encodes
+
+**Verdict: CONFIRMED | Impact: Trivial (startup only)**
+
+`server/src/models/ModelRegistry.ts:545-553`:
+```typescript
+private _calculateChecksum(filePath: string): string {
+    if (!fs.existsSync(filePath)) return '';
+    const fileContent = fs.readFileSync(filePath);
+    return crypto.createHash('sha256')
+      .update(fileContent.toString('base64'))
+      .update(MODEL_REGISTRY_CONFIG.VERSION.toString())
+      .digest('hex');
+}
+```
+
+**Analysis:** `.toString('base64')` allocates a string ~33% larger than the binary data. `crypto.createHash().update()` accepts Buffers directly — the base64 step is unnecessary. Only runs at startup during model preloading/cache validation. For a 5MB model, it allocates an extra ~6.7MB of string temporarily.
+
+---
+
+### S14: Linear scan for entity-attached lookups
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/worlds/audios/AudioManager.ts:74-76`:
+```typescript
+public getAllEntityAttachedAudios(entity: Entity): Audio[] {
+    return this.getAllAudios().filter(audio => audio.attachedToEntity === entity);
+}
+```
+
+Same pattern in `SceneUIManager.ts:65-66` and `ParticleEmitterManager.ts:72-73`.
+
+**Analysis:** `getAllX().filter(...)` creates a full array then scans linearly. O(N) where N = total items in the manager. Only called during entity despawn (infrequent). Typical world has 10-100 items. A reverse index would be premature optimization.
+
+---
+
+### S15: `_createPaddedTexture` iterates all pixels including interior
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`server/src/textures/BlockTextureRegistry.ts:329-337`:
+```typescript
+for (let y = 0; y < width; y++) {
+    for (let x = 0; x < width; x++) {
+      if (y < pad || y >= pad + size || x < pad || x >= pad + size) {
+        const srcX = Math.max(pad, Math.min(pad + size - 1, x));
+        const srcY = Math.max(pad, Math.min(pad + size - 1, y));
+        copy(srcX, srcY, x, y);
+      }
+    }
+}
+```
+
+**Analysis:** Loop runs over ALL pixels (64×64 = 4096 with default config). The `if` skips interior pixels but the check runs for every pixel. Only ~1440 of 4096 are actually padding. This is startup-only during atlas generation — ~576 wasted branch checks per texture is nanoseconds.
+
+---
+
+### S16: Entity sync reliable/unreliable classification is fragile
+
+**Verdict: CONFIRMED | Impact: Low (maintainability concern)**
+
+`server/src/networking/NetworkSynchronizer.ts:163-176`:
+```typescript
+if (this._queuedEntitySyncs.broadcast.size > 0) {
+    const reliableUpdates: protocol.EntitySchema[] = [];
+    const unreliableUpdates: protocol.EntitySchema[] = [];
+    for (const entitySync of this._queuedEntitySyncs.broadcast.valuesArray) {
+      let isReliableUpdate = false;
+      for (const key in entitySync) {
+        isReliableUpdate = key !== 'i' && key !== 'p' && key !== 'r';
+        if (isReliableUpdate) { break; }
+      }
+      (isReliableUpdate ? reliableUpdates : unreliableUpdates).push(entitySync);
+    }
+```
+
+**Analysis:** Uses `for...in` to iterate object keys and checks if any key is NOT `i` (id), `p` (position), or `r` (rotation). Adding new unreliable-safe fields requires modifying this check. Functionally works for the current protocol schema. The concern is maintainability, not runtime performance.
+
+---
+
+### S17: Telemetry spans created every tick even when disabled
+
+**Verdict: REJECTED**
+
+`server/src/metrics/Telemetry.ts:224-234`:
+```typescript
+public static startSpan<T>(options: TelemetrySpanOptions, callback: (span?: Sentry.Span) => T): T {
+    if (Sentry.isInitialized()) {
+      return Sentry.startSpan({ ... }, callback);
+    } else {
+      return callback();
+    }
+}
+```
+
+**Analysis:** When Sentry is NOT initialized, `startSpan` calls `callback()` directly — no span objects created. The options object literal at call sites is still allocated, but that's a trivial V8-optimized short-lived object. The claim is **wrong**.
+
+---
+
+### S18: `getProcessStats` called twice for slow ticks
+
+**Verdict: REJECTED**
+
+`server/src/metrics/Telemetry.ts:163-186`:
+```typescript
+beforeSend: event => {                          // handles ERROR events
+    event.extra = Telemetry.getProcessStats();
+    return event;
+},
+beforeSendTransaction: event => {               // handles TRANSACTION events
+    const spanOp = event.contexts?.trace?.op;
+    if (spanOp === TelemetrySpanOperation.TICKER_TICK) {
+      ...
+      if (tickTimeMs > tickTimeMsThreshold) {
+        event.measurements = Telemetry.getProcessStats(true);
+        return event;
+      }
+    }
+    return null;
+},
+```
+
+**Analysis:** These are two different Sentry callbacks: `beforeSend` for errors, `beforeSendTransaction` for performance spans. They do NOT fire for the same event. The claim is **factually wrong**.
+
+---
+
+### S19: Ticker uses setTimeout for 60 Hz loop — inherent jitter
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Trivial (correct pattern)**
+
+`server/src/shared/classes/Ticker.ts:147`:
+```typescript
+this._tickHandle = setTimeout(tick, this._nextTickMs);
+```
+
+With fixed-timestep accumulator at lines 123-136:
+```typescript
+// Accumulates elapsed time and processes multiple updates in a while loop
+// TICK_SLOW_UPDATE_CAP = 2, MAX_ACCUMULATOR_TICK_MULTIPLE = 3
+```
+
+**Analysis:** `setTimeout` does have scheduling jitter (1-4ms), but the Ticker implements a standard fixed-timestep accumulator pattern that compensates. Physics steps are always the same fixed delta regardless of scheduling variance. The `setTimeout` delay is dynamically calculated based on remaining accumulator time. This is the correct approach used by virtually all game engines. The "jitter" is in scheduling, not in simulation correctness.
+
+---
+
+### S20: Simulation event emission on every step even without listeners
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Trivial**
+
+`server/src/worlds/physics/Simulation.ts:516-544`:
+```typescript
+public step = (tickDeltaMs: number): void => {
+    this.emitWithWorld(this._world, SimulationEvent.STEP_START, {
+      simulation: this,
+      tickDeltaMs,
+    });
+    // ... physics step ...
+    this.emitWithWorld(this._world, SimulationEvent.STEP_END, {
+      simulation: this,
+      stepDurationMs: performance.now() - stepStart,
+    });
+};
+```
+
+`server/src/events/EventRouter.ts:46-47`:
+```typescript
+public emit(eventType: string, payload: any): boolean {
+    if (this.listenerCount(eventType) === 0) return false;
+```
+
+**Analysis:** Payload object literals (`{ simulation: this, tickDeltaMs }`) are allocated every step regardless. But `EventRouter.emit()` bails out at `listenerCount === 0` — no actual listener dispatch occurs. The payload objects are small, short-lived, and V8 GCs them efficiently.
+
+---
+
+## Full Evidence — Client Performance
+
+---
+
+### C1: No greedy meshing in ChunkWorker
+
+**Verdict: CONFIRMED | Impact: Significant**
+
+`client/src/workers/ChunkWorker.ts:950-1182`:
+```typescript
+for (const blockFace of blockType.faces) {
+  const { normal: faceDir, vertices } = blockType.faceGeometries[blockFace];
+  // ... neighbor culling ...
+  for (const { pos, uv, ao } of vertices) {
+    meshPositions.push(vertexX, vertexY, vertexZ);
+    // ... push normals, UVs, colors per vertex
+  }
+  meshIndices.push(ndx, ndx + 1, ndx + 2, ndx + 2, ndx + 1, ndx + 3);
+}
+```
+
+**Analysis:** The code iterates block by block, face by face, emitting a quad (4 vertices, 6 indices) per visible face. There is no merging of coplanar adjacent faces into larger quads. Greedy meshing can reduce vertex count by 10-50x on large flat surfaces (walls, floors, ceilings). Face culling IS present (hidden faces between opaque blocks are skipped), and the engine uses batch meshing (multiple 16³ chunks per batch), which mitigates vs absolute worst case. Still the single biggest rendering optimization opportunity in the engine.
+
+---
+
+### C2: Light calculation iterates all nearby light sources per block
+
+**Verdict: CONFIRMED | Impact: Significant**
+
+`client/src/workers/ChunkWorker.ts:1228-1265`:
+```typescript
+private _calculateLightLevel(x: number, y: number, z: number, lightSources: LightSource[]): number {
+  let maxLightLevel = 0;
+  for (let i = 0, len = lightSources.length; i < len; i++) {
+    const source = lightSources[i];
+    const level = source.level;
+    const dx = x - source.position.x + 0.5;
+    const dy = y - source.position.y + 0.5;
+    const dz = z - source.position.z + 0.5;
+    // Quick rejection using absolute values (avoid sqrt)
+    if (dx > level || dx < -level || dy > level || dy < -level || dz > level || dz < -level) {
+      continue;
+    }
+    // ...
+  }
+}
+```
+
+Called per-block at line 779:
+```typescript
+const lightLevel = this._calculateLightLevel(globalX, globalY, globalZ, nearbyLightSources) & 0xF;
+```
+
+Light sources are collected from batch chunks plus neighbors (lines 700-724), and the function is called for every block in every chunk of the batch.
+
+**Analysis:** O(blocks_in_batch × nearby_light_sources). For a batch of 8 chunks (2×2×2), that's up to 32,768 blocks, each iterating all nearby light sources. The AABB quick-rejection (`dx > level || dx < -level ...`) efficiently skips distant sources. For worlds with few light sources, the cost is manageable. For worlds with many light-emitting blocks, this becomes the dominant bottleneck. A flood-fill/BFS propagation approach would be O(blocks + sources × range) instead of O(blocks × sources).
+
+---
+
+### C3: ChunkWorker uses number[] arrays for geometry, then converts to typed arrays
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`client/src/workers/ChunkWorker.ts:731-755` (allocation):
+```typescript
+const liquidMeshColors: number[] = [];
+const liquidMeshIndices: number[] = [];
+const liquidMeshNormals: number[] = [];
+const liquidMeshPositions: number[] = [];
+const liquidMeshUvs: number[] = [];
+// ... same for opaque and transparent
+```
+
+`client/src/workers/ChunkWorker.ts:1192-1217` (conversion):
+```typescript
+return {
+  liquidGeometry: liquidMeshPositions.length > 0 ? {
+    colors: new Float32Array(liquidMeshColors),
+    indices: this._createIndicesTypedArray(liquidMeshIndices, ...),
+    normals: new Float32Array(liquidMeshNormals),
+    positions: new Float32Array(liquidMeshPositions),
+    uvs: new Float32Array(liquidMeshUvs),
+  } : undefined,
+```
+
+**Analysis:** Geometry is built into regular JS `number[]` arrays via `.push()`, then converted to `Float32Array`/`Uint16Array`/`Uint32Array` at the end. Double memory during build — JS arrays exist alongside newly created typed arrays until GC collects the JS arrays. For a large batch with tens of thousands of faces, this can be several MB of transient memory. Runs in a Web Worker (no main-thread jank). Pre-sizing typed arrays would require knowing final size after culling, which is non-trivial.
+
+---
+
+### C4: BoundaryVolume uses string-key Map for block lookups
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`client/src/workers/ChunkWorker.ts:131-152`:
+```typescript
+class BoundaryVolume {
+  private _data = new Map<`${number},${number},${number}`, number>();
+
+  // TODO: Avoid string creation every time to mitigate GC pressure
+  private _key(x: number, y: number, z: number): `${number},${number},${number}` {
+    return `${x},${y},${z}`;
+  }
+
+  public set(x: number, y: number, z: number, value: number): void {
+    this._data.set(this._key(x, y, z), value);
+  }
+
+  public get(x: number, y: number, z: number): number {
+    const key = this._key(x, y, z);
+    if (!this._data.has(key)) { ... }
+    return this._data.get(key)!;
+  }
+}
+```
+
+**Analysis:** String-key `"x,y,z"` format in a Map. The developers themselves flagged this with a TODO. Scope is limited to boundary data (coordinates outside the chunk's [0,15] range) — main chunk block storage uses `Uint8Array` with integer indexing (`Chunk._getIndex`). String key creation causes GC pressure during sky distance calculation and skylight sampling near chunk edges, not for every block in every chunk.
+
+---
+
+### C5: Every-frame batch view distance check iterates all batches
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`client/src/chunks/ChunkManager.ts:68-89`:
+```typescript
+private _onAnimate = (_payload: RendererEventPayload.IAnimate): void => {
+  ChunkStats.reset();
+  // Optimization hints for future improvements: Calculating the distance between all
+  // batches and the camera every frame might be costly.
+  if (!this._game.settingsManager.qualityPerfTradeoff.viewDistance.enabled) {
+    this._game.chunkMeshManager.addAllBatchMeshesToScene();
+    return;
+  }
+  const viewDistance = this._game.renderer.viewDistance;
+  const viewDistanceSquared = viewDistance * viewDistance;
+  const cameraPos = this._game.camera.activeCamera.position;
+  this._game.chunkMeshManager.applyBatchViewDistance(
+    fromVec2.set(cameraPos.x, cameraPos.z), viewDistanceSquared
+  );
+}
+```
+
+**Analysis:** Iterates all batches every frame for a squared-distance check. The developers acknowledge this in a comment: "Calculating the distance between all batches and the camera every frame might be costly." Simple squared-distance check (no sqrt), only adds/removes from scene graph when state changes. For a typical world with a few hundred batches, sub-millisecond. Scales linearly with batch count.
+
+---
+
+### C6: GLTFManager copies all instance attributes every frame
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Moderate**
+
+`client/src/gltf/GLTFManager.ts:1255-1377`:
+```typescript
+for (const clonedMesh of clonedMeshes) {
+  // Accessing all cloned meshes every animation frame, copying necessary data,
+  // and transferring it to the WebGL buffer may be costly for both the CPU and GPU.
+  // However, since the rendering cost reduction currently provides a much greater
+  // performance benefit, this is not a concern for now.
+  instancedMesh.setMatrixAt(index, clonedMesh.matrixWorld);
+  instancedMesh.geometry.getAttribute(INSTANCE_SKY_LIGHT_ATTRIBUTE)!.setX(index, ...);
+}
+
+if (needsColorAttribute) { /* copy all colors */ }
+if (needsOpacityAttribute) { /* copy all opacities */ }
+if (needsLightLevelAttribute) { /* copy all light levels */ }
+if (needsEmissiveAttribute) { /* copy all emissives */ }
+```
+
+**Analysis:** Matrix data IS copied every frame unconditionally (entities can move/rotate at any time). However, color, opacity, light level, and emissive attributes are **conditional** — tracked by counters that increment/decrement when entities have non-default values. If all entities use default color/opacity/emissive, those attributes are skipped. The developers explicitly acknowledge the tradeoff in comments (lines 1256-1262) and note that instanced rendering benefit outweighs the copy cost.
+
+---
+
+### C7: ChunkMeshManager creates new BufferGeometry per update
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`client/src/chunks/ChunkMeshManager.ts:36-108`:
+```typescript
+private _createOrUpdateMesh(id: BatchId, data: BlocksBufferGeometryData, ...): Mesh {
+  const geometry = new BufferGeometry();
+  geometry.setAttribute('position', new BufferAttribute(positions, ...));
+  geometry.setAttribute('normal', new BufferAttribute(normals, ...));
+  // ... more attributes ...
+  geometry.setIndex(new BufferAttribute(indices, 1));
+  geometry.computeBoundingSphere();
+
+  let mesh = cache.get(id);
+  if (mesh) {
+    mesh.geometry.dispose();
+    mesh.geometry = geometry;
+  } else {
+    mesh = new Mesh(geometry, material);
+  }
+}
+```
+
+**Analysis:** New `BufferGeometry` created every time, old disposed. Triggers GPU resource allocation/deallocation. However, geometry data arrives from the worker as new typed arrays (transferred, not copied), so new GPU buffer uploads are fundamentally necessary. Reusing the geometry object and updating buffer data could avoid some Three.js overhead, but the primary cost (GPU upload) would remain. Only happens on chunk batch rebuilds, not every frame.
+
+---
+
+### C8: Camera allocates vectors per frame in update methods
+
+**Verdict: CONFIRMED | Impact: Moderate**
+
+`client/src/core/Camera.ts:511`:
+```typescript
+lookAtDirection = new Vector3().subVectors(attachedPosition, lookAtPosition).normalize();
+```
+
+`client/src/core/Camera.ts:582`:
+```typescript
+const lookAtTarget = (lookAtPosition || attachedPosition).clone();
+```
+
+`client/src/core/Camera.ts:603`:
+```typescript
+const positionOffset = this._gameCamera.position.clone().sub(lookAtTarget);
+```
+
+`client/src/core/Camera.ts:765-766`:
+```typescript
+const forward = new Vector3(0, 0, -1).applyEuler(this._spectatorCamera.rotation);
+const right = new Vector3(1, 0, 0).applyEuler(this._spectatorCamera.rotation);
+```
+
+**Analysis:** 2-3 `Vector3` objects per frame in update methods. Module-level working variables (`vec3`, `vec3b`, `vec3c`) exist and are used elsewhere in the file, but these specific per-frame paths allocate new objects instead of reusing them. The fix is straightforward: use the existing module-level vectors. Minor but real GC pressure every frame.
+
+---
+
+### C9: Outline pass 8-direction per-pixel search
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Moderate**
+
+`client/src/three/postprocessing/SelectiveOutlinePass.ts:264-316`:
+```glsl
+// Pre-check at max thickness (early-out for most pixels)
+bool needsSearch = false;
+for (int i = 0; i < 8; i++) {
+  vec2 sampleUv = vUv + offsets[i] * texel * maxThickness;
+  float s1 = texture2D(tMask, sampleUv).r * 255.0;
+  float s2 = texture2D(tMask2, sampleUv).r * 255.0;
+  if (abs(s1 - occCenterId) > 0.5 || abs(s2 - nonOccCenterId) > 0.5) {
+    needsSearch = true;
+    break;
+  }
+}
+
+// Full search only if pre-check found a boundary
+if (needsSearch) {
+  for (int t = 1; t <= MAX_THICKNESS; t++) {
+    float thickness = float(t);
+    if (thickness > maxThickness) { break; }
+    for (int i = 0; i < 8; i++) {
+      vec2 sampleUv = vUv + offsets[i] * texel * thickness;
+      // ... sample mask textures ...
+    }
+  }
+}
+```
+
+**Analysis:** Up to 8 × 16 × 2 = 256 texture samples per pixel in the worst case (MAX_THICKNESS = 16). BUT the pre-check samples 8 boundary points at max thickness first — if all match, the expensive loop is skipped entirely. The vast majority of pixels (far from outline edges) only do ~12 total samples. The pass is also disabled entirely when no outline targets exist. Standard GPU outline technique.
+
+---
+
+### C10: `getLightSources` scans all 4096 blocks
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Low**
+
+`client/src/chunks/Chunk.ts:186-217`:
+```typescript
+public getLightSources(blockTypeRegistry: BlockTypeRegistry): LightSource[] {
+  if (this._lightSources === undefined) {
+    this._lightSources = [];
+    // TODO: Optimize if possible
+    for (let y = 0; y < CHUNK_SIZE; y++) {
+      for (let z = 0; z < CHUNK_SIZE; z++) {
+        for (let x = 0; x < CHUNK_SIZE; x++) {
+          const blockId = this.getBlockType({ x, y, z });
+          if (blockId !== 0) {
+            const blockType = blockTypeRegistry.getBlockType(blockId);
+            if (blockType?.lightLevel) {
+              this._lightSources.push({ position: { ... }, level: blockType.lightLevel });
+            }
+          }
+        }
+      }
+    }
+  }
+  return this._lightSources;
+}
+```
+
+**Analysis:** DOES iterate all 4096 blocks, but result is **cached** (`this._lightSources`). The full scan only runs once per chunk until cache invalidation (`this._lightSources = undefined` on `setBlock` or `clearLightSourceCache`). Subsequent calls return the cached array immediately. TODO comment shows developers acknowledge this. One-time cost per chunk lifetime.
+
+---
+
+### C11: CSS2DRenderer builds transform strings every frame
+
+**Verdict: PARTIALLY CONFIRMED | Impact: Low**
+
+`client/src/three/CSS2DRenderer.ts:160-170`:
+```typescript
+private _renderObject(object: CSS2DObject, camera: Camera): void {
+  // ...
+  tmpEl.style.transform = 'translate3d(' + (-100 * object.center.x) + '%,' + ...;
+  if (element.style.transform !== tmpEl.style.transform) {
+    element.style.transform = tmpEl.style.transform;
+  }
+```
+
+**Analysis:** Builds transform strings every frame for every visible CSS2D object. But important optimizations exist: (1) only sets actual element's transform if it CHANGED (the `if` check), (2) has frustum culling to skip offscreen objects, (3) `willChange: 'transform'` hint for GPU compositing. The file header says this is an explicitly optimized fork of Three.js's CSS2DRenderer. String building is cheap; the expensive part (style recalc/reflow) is avoided by change-detection.
+
+---
+
+### C12: Geometry cloned on InstancedMesh resize
+
+**Verdict: CONFIRMED | Impact: Low**
+
+`client/src/gltf/GLTFManager.ts:798-803`:
+```typescript
+const newSize = threshold * INSTANCED_MESH_RESIZE_INCREASE_FACTOR;
+const newPair: InstancedMeshPair = {
+  opaque: new InstancedMeshEx(sourceMesh.geometry.clone(), opaqueMaterial, newSize),
+  transparent: new InstancedMeshEx(sourceMesh.geometry.clone(), transparentMaterial, newSize)
+};
+instancedMeshPairs.push(newPair);
+```
+
+**Analysis:** Geometry IS cloned when creating a new InstancedMesh tier. But this doesn't happen on every resize — the system uses a tiered approach with `INSTANCED_MESH_RESIZE_INCREASE_FACTOR`. New pairs are only created when count exceeds the current tier's capacity. Previous tier's InstancedMesh remains as a smaller option. One-time cost per tier threshold crossing. Some geometry creation is unavoidable since InstancedMesh needs its own geometry for instance-specific attributes.
+
+---
+
+### C13: Block data copied (not transferred) between main thread and worker
+
+**Verdict: CONFIRMED | Impact: Low (intentional)**
+
+`client/src/chunks/ChunkManager.ts:150-160`:
+```typescript
+// Since blocks are also managed on the main thread, they are not transferred.
+// However, if copying blocks becomes a performance or memory issue, this
+// approach may need to be reconsidered.
+const message: ChunkWorkerChunkUpdateMessage = {
+  type: 'chunk_update',
+  originCoordinate,
+  blocks,
+  blockRotations,
+};
+this._game.chunkWorkerClient.postMessage(message);
+```
+
+**Analysis:** `blocks` is a `Uint8Array` (4096 bytes per 16³ chunk). `postMessage` without transferables causes structured clone (copy). This is **intentional** and **documented** — the main thread also needs the data for block type lookups, liquid detection, etc. The comment explicitly acknowledges the tradeoff. 4KB per chunk is small. Geometry output from worker to main IS properly transferred (not copied), which is the much larger payload.
+
+---
+
+### C14: Deserializer creates many intermediate objects per packet
+
+**Verdict: CONFIRMED | Impact: Low**
+
+`client/src/network/Deserializer.ts:274-642`:
+```typescript
+public static deserializeEntity(entity: protocol.EntitySchema): DeserializedEntity {
+  return {
+    id: entity.i,
+    emissiveColor: 'ec' in entity ? (entity.ec ? new THREE.Color(...) : null) : undefined,
+    position: entity.p ? this.deserializeVector(entity.p) : undefined,
+    rotation: entity.r ? this.deserializeQuaternion(entity.r) : undefined,
+    tintColor: 't' in entity ? (entity.t ? new THREE.Color(...) : null) : undefined,
+    // ... many more fields
+  };
+}
+
+public static deserializeVector(vector: protocol.VectorSchema): THREE.Vector3Like {
+  return { x: vector[0], y: vector[1], z: vector[2] };
+}
+```
+
+**Analysis:** Standard deserialization practice. Plain objects (`{ x, y, z }`) are extremely cheap in modern JS engines. `THREE.Color` constructors are lightweight. Runs at 30 Hz network rate, not 60 Hz render rate. Object pools would add complexity for minimal gain.
+
+---
+
+### C15: AO cache linear scan of parallel arrays
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`client/src/workers/ChunkWorker.ts:1615-1638`:
+```typescript
+private _sampleAOOpacity(x: number, y: number, z: number): number {
+  for (let i = 0; i < aoCacheOpacity.length; i++) {
+    if (aoCacheX[i] === x && aoCacheY[i] === y && aoCacheZ[i] === z) {
+      return aoCacheOpacity[i];
+    }
+  }
+  // ... compute and push to cache
+  aoCacheX.push(x);
+  aoCacheY.push(y);
+  aoCacheZ.push(z);
+  aoCacheOpacity.push(opacity);
+  return opacity;
+}
+```
+
+Cache cleared per-face at lines 991-994.
+
+**Analysis:** Cache is cleared per-face (every 4 vertices). Linear scan is over at most ~3-4 entries per lookup. Linear scan over 3 items is actually **faster** than a hash map or any other data structure. This is an appropriate micro-optimization for the cache size involved.
+
+---
+
+### C16: `getBatchChunkIds` creates new array each call
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`client/src/chunks/ChunkRegistry.ts:92-95`:
+```typescript
+public getBatchChunkIds(batchId: BatchId): ChunkId[] {
+  const batch = this._batches.get(batchId);
+  return batch ? Array.from(batch.chunkIds) : [];
+}
+```
+
+**Analysis:** `Array.from()` on a `Set<ChunkId>`. Called on chunk packet arrival (batch rebuilds), NOT per-frame. A batch has at most 8 chunks (2×2×2). Tiny array, negligible allocation.
+
+---
+
+### C17: Legacy BlockTextureAtlasManager has O(n) brute-force space finding
+
+**Verdict: CONFIRMED | Impact: Trivial**
+
+`client/src/workers/BlockTextureAtlasManager.ts:192-215`:
+```typescript
+const existingTextures = Array.from(this._metadata.values());
+for (let y = 0; y <= canvasHeight - tileHeight && !foundSpace; y++) {
+  for (let x = 0; x <= canvasWidth - tileWidth; x++) {
+    const hasOverlap = existingTextures.some(existing =>
+      x < existing.x + existing.width &&
+      x + tileWidth > existing.x &&
+      y < existing.invertedY + existing.height &&
+      y + tileHeight > existing.invertedY
+    );
+    if (!hasOverlap) { ... foundSpace = true; break; }
+  }
+}
+```
+
+**Analysis:** O(canvas_width × canvas_height × num_existing_textures). This is in the **legacy** atlas manager. The modern `BlockTextureAtlasManager` (line 399+) uses pre-generated atlas metadata and does NOT do runtime packing. Legacy code only runs for old SDK versions. Even in legacy mode, this runs once per unique texture during initialization.
+
+---
+
+### C18: No frustum culling for chunk batch meshes
+
+**Verdict: REJECTED**
+
+`client/src/chunks/ChunkMeshManager.ts:83, 95-97`:
+```typescript
+geometry.computeBoundingSphere();
+// ...
+mesh.matrixAutoUpdate = false;
+mesh.matrixWorldAutoUpdate = false;
+```
+
+Three.js default `frustumCulled = true` is NOT overridden. `computeBoundingSphere()` is called. Additionally, the view distance system in `applyBatchViewDistance` removes distant batches from the scene graph entirely.
+
+**Analysis:** The claim is **wrong**. Meshes ARE frustum culled by Three.js's built-in mechanism, and additionally culled by distance.
+
+---
+
+### C19: Post-processing chain runs all passes unconditionally
+
+**Verdict: REJECTED**
+
+`client/src/core/Renderer.ts:297-317`:
+```typescript
+const pp = this._game.settingsManager.qualityPerfTradeoff.postProcessing;
+if (pp?.outline || pp?.bloom || pp?.smaa) {
+  this._renderPass.camera = this._game.camera.activeCamera;
+  this._viewModelRenderPass.enabled = this._firstPersonViewModelEntity !== undefined;
+  this._outlinePass.enabled = !!pp.outline;
+  this._bloomPass.enabled = !!pp.bloom;
+  this._smaaPass.enabled = !!pp.smaa;
+  this._effectComposer.render();
+} else {
+  this._renderer.render(this._scene, this._game.camera.activeCamera);
+}
+```
+
+**Analysis:** Each pass is individually enabled/disabled based on settings. If NO post-processing is enabled, falls through to simple `renderer.render()`. The claim is **wrong**.
+
+---
+
+## Top Actionable Items (Ranked by Impact)
+
+### Tier 1 — Significant Performance Gains
+
+1. **Greedy meshing** (C1) — Single biggest rendering optimization. 10-50x vertex reduction on flat surfaces. Complex to implement but enormous payoff.
+2. **Light propagation algorithm** (C2) — Replace per-block × per-source iteration with flood-fill/BFS. Especially important for worlds with many light-emitting blocks.
+
+### Tier 2 — Moderate Gains, Reasonable Effort
+
+3. **Async gzip** (S2) — Replace `gzipSync` with async `gzip` for >64KB payloads. 1-line change, removes main thread blocking during player join.
+4. **Parallel model loading** (S3) — Replace sequential `await` loop with `Promise.all` (with concurrency limit). Startup-time improvement only.
+5. **Pre-allocated typed arrays in ChunkWorker** (C3) — Estimate final sizes or use growable typed array pools. Reduces GC pressure in worker.
+6. **BoundaryVolume integer keys** (C4) — Replace string `"x,y,z"` keys with packed integers. Developers already flagged with TODO.
+7. **Camera reuse working vectors** (C8) — Use module-level vectors instead of `new Vector3()` in per-frame update paths. 3-line fix.
+
+### Tier 3 — Low Priority / Deliberate Tradeoffs
+
+8. Trimesh collider batching (S1) — Only matters for games using many custom-mesh block types that are frequently edited.
+9. Instance attribute conditional copying (C6) — Already optimized with counters; matrix copy is necessary.
+10. Batch view distance octree/spatial structure (C5) — Developers acknowledge, squared-distance is fast enough for now.
+
+---
+
+## False Positives Identified
+
+These claims from the original audit are **wrong** and should not be acted on:
+
+1. ~~Telemetry spans created every tick when disabled~~ — Early return, no spans created
+2. ~~`getProcessStats` called twice for slow ticks~~ — Different Sentry callbacks
+3. ~~No frustum culling for chunk batch meshes~~ — Three.js default frustum culling is active
+4. ~~Post-processing runs all passes unconditionally~~ — Each pass individually toggled
+5. ~~Ticker setTimeout makes 60Hz unreliable~~ — Standard fixed-timestep accumulator pattern, correct approach
diff --git a/AUDIT_PHYSICS_WORLDS.md b/AUDIT_PHYSICS_WORLDS.md
new file mode 100644
index 00000000..fdad282a
--- /dev/null
+++ b/AUDIT_PHYSICS_WORLDS.md
@@ -0,0 +1,400 @@
+# Physics & Worlds Audit
+
+## Summary
+
+Comprehensive audit of `server/src/worlds/`, `server/src/worlds/physics/`, and `server/src/worlds/blocks/` in the HYTOPIA engine. Findings sorted by benefit (descending), then effort (ascending).
+
+---
+
+### [PERFORMANCE] Ticker uses setTimeout for 60 Hz loop - inherent jitter
+**Benefit: 5/5 | Risk: 3/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/shared/classes/Ticker.ts:147`
+
+The Ticker drives the 60 Hz world loop using `setTimeout(tick, this._nextTickMs)`. On Node.js/Bun, `setTimeout` has minimum resolution of ~1ms and jitter of 1-4ms depending on OS scheduler load. At 60 Hz the target interval is 16.67ms, so 1-4ms of jitter represents 6-24% timing variance per tick. The accumulator pattern partially compensates (allowing catch-up ticks up to `TICK_SLOW_UPDATE_CAP = 2`), but it still means the physics step frequency is not smooth.
+
+**Recommended fix:** Consider using `setImmediate` with a busy-wait spin for the remaining sub-millisecond fraction, or Bun's `Bun.sleep()` which has microsecond resolution. A hybrid approach: `setTimeout` for the bulk delay (nextTickMs - 2), then `setImmediate` spin-check for the final 2ms, would dramatically reduce jitter with minimal CPU cost. The code comment at line 144-146 says "Use setTimeout instead of setImmediate to avoid memory pressure" -- this is valid but the trade-off should be configurable.
+
+---
+
+### [PERFORMANCE] Trimesh collider fully recreated on every single block edit
+**Benefit: 5/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:457-461` and `server/src/worlds/blocks/ChunkLattice.ts:485-487`
+
+When `setBlock()` modifies a block that uses a trimesh collider type, `_recreateTrimeshCollider()` is called which removes the entire collider from simulation, rebuilds the combined trimesh from ALL placements of that block type, and re-adds it. For a world with thousands of trimesh blocks of the same type, editing a single one rebuilds the entire mesh. `_buildTrimeshFromBlockPlacements` (BlockType.ts:286-345) allocates new Float32Array and Uint32Array for ALL vertices/indices every time.
+
+**Recommended fix:** Batch trimesh collider rebuilds per tick instead of per-block-edit. Queue dirty block types during a tick, then rebuild all at once at end-of-tick. This turns N individual rebuilds into 1. For even more optimization, consider incremental trimesh updates (add/remove individual block triangles) rather than full rebuild.
+
+---
+
+### [PERFORMANCE] `_combineVoxelStates` is O(N^2) in number of block types
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:507-514`
+
+During `initializeBlockEntries`, after all blocks are placed, a loop from blockTypeId 1..255 calls `_combineVoxelStates(collider)` for each block type that has blocks. Inside `_combineVoxelStates`, it iterates ALL `_blockTypeColliders` to find other voxel colliders to combine with. If there are K voxel block types, this is O(K^2) calls to `combineVoxelStates()`. Each call to Rapier's `combineVoxelStates` is itself non-trivial. With many block types (20+), this becomes quadratic.
+
+**Recommended fix:** Maintain a separate list/set of voxel-type colliders. When combining, only iterate that subset. Also, `combineVoxelStates` is symmetric -- track which pairs have already been combined to avoid redundant work (currently the code says "only once" in comments but there's no deduplication guard).
+
+---
+
+### [BUG] `Chunk.globalCoordinateToOriginCoordinate` fails for negative coordinates
+**Benefit: 5/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/Chunk.ts:132-138`
+
+The bitwise `&` with `CHUNK_AXES_RANGE (15)` on negative numbers produces incorrect results. For example, `globalCoordinate.x = -1`:
+- `(-1 | 0)` = `-1`
+- `(-1 & 15)` = `15` (bitwise AND on two's complement)
+- Result: `-1 - 15 = -16` (correct!)
+
+Actually wait -- for `-1`, this produces `-16` which IS the correct origin for chunk containing block -1. Let me check `-17`:
+- `(-17 | 0)` = `-17`
+- `(-17 & 15)` = `15`
+- Result: `-17 - 15 = -32` (correct, chunk [-32, -17])
+
+And for `-16`:
+- `(-16 | 0)` = `-16`
+- `(-16 & 15)` = `0`
+- Result: `-16 - 0 = -16` (correct)
+
+After careful analysis, the bitwise operations actually work correctly for negative values in JavaScript (two's complement). **Downgrading this from BUG to PERFORMANCE NOTE** -- the `(globalCoordinate.x | 0)` coercion is necessary for float->int truncation but could be replaced with a right-shift: `x >> 4 << 4` for clarity and potentially marginally better perf. No actual bug here.
+
+---
+
+### [BUG] `globalCoordinateToLocalCoordinate` silently produces wrong results for non-integer inputs
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/Chunk.ts:116-122`
+
+The bitwise `& CHUNK_AXES_RANGE` truncates to integer implicitly (like `| 0`), but for negative fractional values like `-0.5`, it produces `(-0.5 & 15)` = `(0 & 15)` = `0` -- when the expected behavior might be the block at position `-1` (local coord 15 within chunk -16...-1). The entire coordinate chain (`globalToLocal`, `globalToOrigin`, `getBlockId`, etc.) assumes integer inputs but nothing validates this at the API boundary.
+
+**Recommended fix:** Add `Math.floor()` before the bitwise operations, or document clearly that all global coordinates must be pre-floored integers. The `setBlock` path does validate via `_isValidBlockTypeId` but never validates the coordinate itself.
+
+---
+
+### [PERFORMANCE] `_propagateVoxelChange` iterates ALL block type colliders for every single block edit
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:517-524`
+
+Every call to `setBlock` that modifies a voxel collider calls `_propagateVoxelChange`, which iterates ALL `_blockTypeColliders`. With 50 block types, every single block placement/removal does 50 iterations. For batch operations like building a structure, this is O(blocks * blockTypes).
+
+**Recommended fix:** Same as above -- maintain a separate set of voxel-only colliders. Also consider whether propagation could be deferred and batched per-tick.
+
+---
+
+### [PERFORMANCE] `getAllChunks()` and `getAllWorlds()` create new arrays every call
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:268` and `server/src/worlds/WorldManager.ts:116`
+
+`Array.from(this._chunks.values())` and `Array.from(this._worlds.values())` allocate a new array each call. If these are called frequently (e.g., per-tick for spatial queries), this creates GC pressure.
+
+**Recommended fix:** Return the Map's `values()` iterator directly, or cache the array and invalidate on add/remove. For the `ChunkLattice`, this matters more since chunk count can be in the hundreds.
+
+---
+
+### [BUG] `RigidBody.removeFromSimulation` nullifies `_rigidBodyDesc`, making body non-reusable
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/RigidBody.ts:1490-1505`
+
+After `removeFromSimulation()`, both `_simulation` and `_rigidBody` are set to `undefined`. The `_rigidBodyDesc` was already set to `undefined` implicitly since it's not reassigned after `addToSimulation()` created the actual body from it (line 1315). This means `isRemoved` returns `true` (line 619-621: `!this._rigidBody && !this._rigidBodyDesc`), and the body can never be re-added to a simulation. This is not necessarily a bug if the design intent is one-shot, but the class doesn't document this limitation.
+
+**Recommended fix:** Either (a) reconstruct the `_rigidBodyDesc` from the current body state before removing, allowing re-addition, or (b) document clearly that removed bodies cannot be re-used and must be reconstructed.
+
+---
+
+### [BUG] World.stop() does not clean up entities, physics, or sub-managers
+**Benefit: 4/5 | Risk: 3/5 | Effort: 3/5 | Surgical: no | Backwards Compatible: no**
+
+File: `server/src/worlds/World.ts:787-796`
+
+`World.stop()` only stops the loop. It does not:
+- Remove entities from the physics simulation
+- Destroy the Rapier world
+- Clear the collider map
+- Disconnect players from the world
+- Clean up audio/particle/sceneUI managers
+
+If a world is stopped and then garbage collected, all Rapier resources (rigid bodies, colliders, the RAPIER.World itself) leak WASM memory. Rapier3D uses a Rust-backed WASM allocator -- JS garbage collection does NOT free these resources.
+
+**Recommended fix:** Add a `destroy()` method that properly tears down all sub-systems. At minimum, call `this._simulation._rapierSimulation.free()` and clear all manager state. The current `stop()` is fine for "pause", but there's no way to properly dispose a world.
+
+---
+
+### [PERFORMANCE] Telemetry spans created every single tick even when telemetry is disabled
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/WorldLoop.ts:157-187`
+
+Every tick creates multiple `Telemetry.startSpan()` calls with object allocations for attributes. At 60 Hz, this is 240+ object allocations per second per world just for telemetry metadata. If telemetry is disabled (likely in production), these are pure overhead.
+
+**Recommended fix:** Guard span creation behind a `Telemetry.isEnabled` check, or make `startSpan` a true no-op that doesn't allocate the attributes object when disabled (lazy evaluation / callback pattern for attributes).
+
+---
+
+### [PERFORMANCE] Simulation event emission on every step even without listeners
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/Simulation.ts:516-544`
+
+`STEP_START` and `STEP_END` events are emitted every tick (60 Hz) regardless of whether anyone is listening. Each `emitWithWorld` call involves the EventRouter dispatch chain. The debug rendering check (line 539) is correctly guarded, but the step events are not.
+
+**Recommended fix:** Guard with `if (this.hasListeners(SimulationEvent.STEP_START))` before emitting. Same for `STEP_END`.
+
+---
+
+### [PERFORMANCE] `getWorldsByTag` does linear scan of all worlds
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/WorldManager.ts:151-161`
+
+`getWorldsByTag()` iterates all worlds and allocates a new array. For servers with many worlds (e.g., instanced dungeons), a `Map<string, Set<World>>` tag index would be O(1).
+
+**Recommended fix:** Maintain a `_worldsByTag: Map<string, Set<World>>` alongside `_worlds`, updated on create/destroy/tag-change.
+
+---
+
+### [BUG] `ColliderMap` double-buffered cleanup may miss rapid add-remove-add sequences
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/ColliderMap.ts:134-211`
+
+The cleanup uses a two-phase system: pending -> cleanup -> deleted. When `queueColliderHandleForCleanup` is called, the handle goes to `_pending`. On next `cleanup()`, it moves to `_cleanup`. On the NEXT `cleanup()`, it's actually deleted. However, if a handle is queued for cleanup (added to pending) and then immediately re-registered (via `setColliderHandleBlockType` which clears it from both pending and cleanup at lines 118-119), it works correctly. But consider: if handle H is queued for cleanup, moves to `_cleanup` set, and then on the SAME tick a new collider reuses handle H (Rapier can reuse handles), `setColliderHandleBlockType` clears it from cleanup. This seems correct.
+
+However, there's a subtle issue: the cleanup comment (line 176-183) explains the spider/bullet scenario, but the two-tick delay means that for TWO full ticks after removal, the collider handle still maps to the old BlockType/Entity. During these two ticks, any collision events involving that handle will incorrectly route to the old (now-invalid) object.
+
+**Recommended fix:** Consider whether one tick of delay is sufficient instead of two, or verify that the stale mapping during the delay window doesn't cause issues for game logic that reads the mapped object.
+
+---
+
+### [BUG] `setBlock` early-return skips rotation-only changes when same blockTypeId
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:430`
+
+```typescript
+if (previousBlockTypeId === blockTypeId && !blockRotation) return;
+```
+
+This returns early if the block type hasn't changed AND no rotation is specified. But what if the user wants to clear a rotation (reset to default) by calling `setBlock(coord, sameId)` without a rotation? The early return prevents this. Also, if the previous block HAD a rotation and the user sets the same block type with a DIFFERENT rotation, this doesn't early-return (correct). But setting the same type with `undefined` rotation when the block already has a rotation will early-return instead of clearing the rotation.
+
+**Recommended fix:** Compare the full state including rotation:
+```typescript
+const previousRotation = chunk.getBlockRotation(localCoordinate);
+if (previousBlockTypeId === blockTypeId && (blockRotation ?? BLOCK_ROTATIONS.Y_0) === previousRotation) return;
+```
+
+---
+
+### [FEATURE] No way to remove/destroy a world from WorldManager
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/WorldManager.ts`
+
+`WorldManager` has `createWorld()` but no `removeWorld()` or `destroyWorld()`. Once created, worlds live forever in `_worlds`. For games with instanced dungeons, arenas, or temporary worlds, this is a memory leak. Combined with the `World.stop()` issue above (no WASM cleanup), there's no way to properly dispose of a world.
+
+**Recommended fix:** Add `removeWorld(id: number)` that calls `world.stop()`, removes from `_worlds`, emits a `WORLD_REMOVED` event, and invokes a new `world.destroy()` method for proper resource cleanup.
+
+---
+
+### [PERFORMANCE] BigInt chunk keys have overhead vs integer keys
+**Benefit: 3/5 | Risk: 3/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:615-621`
+
+Chunk coordinates are packed into a BigInt via `_packCoordinate()`. BigInt operations are significantly slower than regular number operations in V8 (10-100x depending on operation). Every `getChunk`, `hasChunk`, `getBlockId`, `setBlock` etc. calls `_getChunkKey` which calls `_packCoordinate` with BigInt arithmetic.
+
+The coordinate range uses 54-bit segments for x/y/z, which is needed for very large worlds but overkill for typical game worlds. With 16-block chunks, a 32-bit signed range per axis would cover +/- 34 billion blocks.
+
+**Recommended fix:** For typical world sizes, a string key (`${ox},${oy},${oz}`) or a 53-bit safe integer key (if coordinates fit in ~17 bits each) would be faster. Alternatively, precompute and cache chunk keys to avoid repeated BigInt allocation.
+
+---
+
+### [PERFORMANCE] `_getBlockTypePlacements` iterates all chunk masks with bit scanning
+**Benefit: 3/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:556-601`
+
+This method reconstructs ALL block placements for a block type by scanning bitmasks. It allocates a new `BlockPlacement` object per block, a new `globalCoordinate` object per block, and a new array. For trimesh block types with thousands of blocks, this is called on every `_recreateTrimeshCollider` which is called on every `setBlock`. This is the hot path for trimesh editing.
+
+**Recommended fix:** For trimesh types, maintain a direct placement list alongside the bitmask. The bitmask is great for voxel operations but expensive to iterate for trimesh rebuilds.
+
+---
+
+### [BUG] `MAX_BLOCK_TYPE_ID = 255` limits world to 255 block types
+**Benefit: 2/5 | Risk: 3/5 | Effort: 4/5 | Surgical: no | Backwards Compatible: no**
+
+File: `server/src/worlds/blocks/Chunk.ts:21`
+
+`Chunk._blocks` is a `Uint8Array`, limiting block type IDs to 0-255 (with 0 = air, so 255 usable types). For voxel games with many biomes, decorative blocks, and user-created blocks, 255 may be insufficient.
+
+**Recommended fix:** This is a deep architectural change (Uint8Array -> Uint16Array doubles chunk memory from 4KB to 8KB per chunk, affects serialization, protocol, client). Only worth pursuing if the limit is actually being hit by SDK games.
+
+---
+
+### [PERFORMANCE] BLOCK_ROTATIONS_BY_INDEX sorted on every loadMap call
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/World.ts:514`
+
+```typescript
+const BLOCK_ROTATIONS_BY_INDEX = Object.values(BLOCK_ROTATIONS).sort((a, b) => a.enumIndex - b.enumIndex);
+```
+
+This creates and sorts a 24-element array every time `loadMap()` is called. Since `BLOCK_ROTATIONS` is a `const`, this should be computed once at module level.
+
+**Recommended fix:** Move to a module-level constant:
+```typescript
+const BLOCK_ROTATIONS_BY_INDEX = Object.values(BLOCK_ROTATIONS).sort((a, b) => a.enumIndex - b.enumIndex);
+```
+
+---
+
+### [BUG] Raycast epsilon adjustment assumes axis-aligned ray directions
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/Simulation.ts:455-464`
+
+The block-hit calculation uses `ray.dir.x < 0 ? epsilon : -epsilon` to nudge the hit point into the correct block. This works perfectly for axis-aligned rays but may produce wrong results for diagonal rays that hit exactly on a block edge. For a ray traveling at 45 degrees hitting the exact corner of a block, the epsilon nudge may push the point into the wrong neighbor block.
+
+**Recommended fix:** Instead of per-axis epsilon based on ray direction, use the surface normal of the hit (available from Rapier's `featureId`) to determine which side of the boundary the block is on. Alternatively, the current approach is "good enough" for most practical cases since exact-corner hits are exceedingly rare.
+
+---
+
+### [PERFORMANCE] `_applyRigidBodyOptions` and `_applyColliderOptions` create arrays of bound functions
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/RigidBody.ts:1601-1627` and `server/src/worlds/physics/Collider.ts:1572-1593`
+
+Every rigid body and collider construction allocates an array of `[string, Function]` tuples with `.bind(this)` calls, then iterates them. With hundreds of entities, this is many small allocations.
+
+**Recommended fix:** Use a direct if/switch chain or a static lookup table with method names (avoid `.bind()` per construction). This is micro-optimization but applies to every entity spawn.
+
+---
+
+### [BUG] No validation of collision group values in `CollisionGroupsBuilder`
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/CollisionGroupsBuilder.ts:97-100`
+
+`buildRawCollisionGroups` uses bitwise OR to combine groups without validating that the input values are valid `CollisionGroup` enum values. Passing arbitrary numbers could produce unexpected collision behavior with no error.
+
+**Recommended fix:** Validate that each group in `belongsTo` and `collidesWith` is a valid `CollisionGroup` value, or at least that the combined result fits in 16 bits.
+
+---
+
+### [PERFORMANCE] `intersectionsWithRawShape` deduplicates using a Set but creates objects for every result
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/Simulation.ts:372-407`
+
+`intersectionsWithRawShape` creates a `Set` and `IntersectionResult[]` per call, plus individual result objects. For frequent overlap queries (e.g., area-of-effect abilities), this causes GC churn.
+
+**Recommended fix:** Accept a pre-allocated results array and a callback pattern, allowing callers to reuse buffers.
+
+---
+
+### [FEATURE] No world-level entity spatial query (nearest entity, entities in radius)
+**Benefit: 3/5 | Risk: 1/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/World.ts`
+
+The only spatial queries available are raycast and shape intersection. There's no high-level API for "find entities within radius" or "find nearest entity of type X". Games commonly need these for AI, targeting, and area effects. Currently game developers must iterate all entities and compute distances manually.
+
+**Recommended fix:** Add `simulation.entitiesInRadius(center, radius)` and `simulation.nearestEntity(center, filter?)` as convenience methods wrapping `intersectionsWithRawShape` with a ball shape.
+
+---
+
+### [PERFORMANCE] Ticker accumulator clamp may lose time under sustained load
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/shared/classes/Ticker.ts:125-127`
+
+When `_accumulatorMs > _maxAccumulatorMs` (3 tick intervals), excess time is silently dropped. Combined with `TICK_SLOW_UPDATE_CAP = 2`, if the server consistently takes >2 tick intervals to process, it will perpetually lose time and run slower than 60 Hz without any warning or metric. The world appears to run in slow motion.
+
+**Recommended fix:** Log a warning or emit a metric when accumulator clamping occurs. This helps developers diagnose "why is my game running slow" issues. Also consider making `TICK_SLOW_UPDATE_CAP` configurable per world.
+
+---
+
+### [BUG] `_requireNotRemoved` in RigidBody uses `ErrorHandler.error` (non-fatal) but returns boolean
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/RigidBody.ts:1733-1738`
+
+`_requireNotRemoved` calls `ErrorHandler.error()` (which logs but doesn't throw) and returns `false`. The callers check the return value and early-return. This means operating on a removed rigid body is silently swallowed after a log message. The same pattern exists for `_requireDynamic`, `_requireKinematic`, etc. While this prevents crashes, it can mask bugs in game code where developers accidentally operate on removed bodies and never see the error.
+
+**Recommended fix:** Consider at minimum making these errors more visible (e.g., development-mode assertions that throw). The current behavior is defensively safe but can hide logic bugs.
+
+---
+
+### [BUG] `World.loadMap` entities spawn during construction before world starts
+**Benefit: 2/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/World.ts:327-329` and `server/src/worlds/World.ts:557-573`
+
+If `options.map` is provided in the World constructor, `loadMap()` is called immediately (line 328). Inside `loadMap`, entities are spawned via `entity.spawn(this, ...)` (line 571). But the world loop hasn't started yet -- it starts later in `WorldManager.createWorld()` after construction (line 99). This means entities are spawned into a world that isn't ticking yet. If entity spawn logic relies on the world loop running (e.g., queuing work for next tick), it may not execute as expected.
+
+**Recommended fix:** Defer entity spawning until after `world.start()`, or document that entities spawned during map load will exist in a pre-tick state.
+
+---
+
+### [FEATURE] No block-level metadata or per-block events
+**Benefit: 2/5 | Risk: 2/5 | Effort: 4/5 | Surgical: no | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/Chunk.ts` and `server/src/worlds/blocks/BlockType.ts`
+
+Blocks are stored as plain uint8 IDs with optional rotation. There's no per-block metadata (health, ownership, custom data). Events like `ENTITY_COLLISION` fire on the `BlockType` level, not the individual block instance. A game can't distinguish which specific block was collided with beyond the BlockType. The raycast does return a `Block` with coordinates, but there's no event-based mechanism for individual block interaction.
+
+**Recommended fix:** This is a deep architectural choice. Adding per-block metadata would significantly increase memory usage. A lightweight approach: allow `BlockType.ENTITY_COLLISION` payload to include the block coordinate (it currently only includes `blockType` and `entity`). This would let game logic react to specific block positions without per-block storage.
+
+---
+
+### [PERFORMANCE] `_onCollisionEvent` and `_onContactForceEvent` do redundant lookups
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/physics/Simulation.ts:548-567` and `server/src/worlds/physics/Simulation.ts:570-593`
+
+Both collision handlers call `handleCollision(objectA, objectB)` then `handleCollision(objectB, objectA)`. Inside `handleCollision`, the `instanceof` checks and `hasListeners` checks are done again for the swapped order. For BlockType-Entity collisions, this means 4 instanceof checks + 2 hasListeners calls when only 2 + 1 are needed.
+
+**Recommended fix:** Refactor to determine the types once, then dispatch directly. Minor optimization but this runs on every collision event at 60 Hz.
+
+---
+
+### [PERFORMANCE] ChunkLattice rigid body created lazily but never removed
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:340-343` and `server/src/worlds/blocks/ChunkLattice.ts:434-437`
+
+The `_rigidBody` for the chunk lattice is created lazily when the first block is placed but is never removed or cleaned up. After `clear()`, the colliders are removed but the empty fixed rigid body persists in the simulation. This is a minor leak -- one empty rigid body per world per clear cycle.
+
+**Recommended fix:** Remove `_rigidBody` from simulation in `clear()` and set to undefined.
+
+---
+
+### [BUG] `newCount` calculation in `setBlock` removal path has off-by-one potential
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts:441`
+
+```typescript
+const newCount = Math.max(0, this.getBlockTypeCount(previousBlockTypeId) - 1);
+```
+
+This reads the count BEFORE `_removeBlockTypePlacement` is called (line 444). But `_removeBlockTypePlacement` also decrements the count internally (line 682-684). So after line 444 executes, the actual count is already `newCount`. However, the `newCount` variable is only used for the `if (newCount === 0)` check (line 447), which compares against the pre-removal expected count. This is actually correct because `_removeBlockTypePlacement` hasn't been called yet when newCount is computed. But it's fragile -- if the order changes, the logic breaks silently.
+
+**Recommended fix:** Compute `newCount` after `_removeBlockTypePlacement`, reading the actual count: `const newCount = this.getBlockTypeCount(previousBlockTypeId);`
+
+---
+
+### [FEATURE] No chunk unloading for distant/empty chunks
+**Benefit: 3/5 | Risk: 3/5 | Effort: 4/5 | Surgical: no | Backwards Compatible: yes**
+
+File: `server/src/worlds/blocks/ChunkLattice.ts`
+
+Once a chunk is created, it exists forever in the `_chunks` map. There's no distance-based unloading relative to players. For large worlds where players explore and move on, empty or distant chunks consume memory indefinitely. Each chunk is 4KB (Uint8Array of 4096) plus the Map entry and rotation map overhead.
+
+**Recommended fix:** Implement chunk lifecycle: track which chunks have active blocks, remove empty chunks after all blocks are cleared (currently chunks persist even when all blocks are set to air). For distance-based unloading, this would need integration with the player system.
diff --git a/AUDIT_SERVER_CORE.md b/AUDIT_SERVER_CORE.md
new file mode 100644
index 00000000..101a173d
--- /dev/null
+++ b/AUDIT_SERVER_CORE.md
@@ -0,0 +1,403 @@
+# Server Core, Persistence, Events & Shared Utilities Audit
+
+## Findings
+
+### [BUG] PersistenceManager.setPlayerData Never Persists to Storage
+**Benefit: 5/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/persistence/PersistenceManager.ts:115-121
+
+**Status (verified): false positive (with a caveat).**
+
+`SaveStatesClient.load()` returns a proxied object that tracks mutations and is periodically flushed by the SaveStates client itself (and on `unload()`). In that model, mutating the returned object is the intended way to persist changes; an explicit `save()` call is not required.
+
+**Caveat:** `PersistenceManager.getPlayerData()` currently returns `{}` when the persistence load fails. Mutating that fallback object will not persist anything. That is a real behavior gap, but it is different from “writes never persist”.
+
+```typescript
+public async setPlayerData(player: Player, data: Record<string, unknown>): Promise<void> {
+    const playerData = await this.getPlayerData(player);
+    for (const [ key, value ] of Object.entries(data)) {
+      playerData[key] = value;
+    }
+    // BUG: Missing this._saveStatesClient.save(this._getPlayerKey(player), playerData);
+}
+```
+
+**Recommended fix:** Add `await this._saveStatesClient.save(this._getPlayerKey(player), playerData);` after the merge loop, or if SaveStatesClient returns a mutable cached reference that auto-flushes, verify that contract and document it.
+
+---
+
+### [BUG] PersistenceManager.getGlobalData Crashes on Network Error (null deref)
+**Benefit: 4/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/persistence/PersistenceManager.ts:56-71
+
+**Status (verified): likely incorrect as written.**
+
+`PlatformGateway.getGlobalData()` returns a `ServiceResponseDto`-shaped object (success variant has `error: undefined`, error variant has `error: { code, message }`). It should not return `undefined`/`null` unless it throws/rejects.
+
+The real risk here is **uncaught exceptions / rejected promises** from the gateway call causing `getGlobalData()` itself to reject (no retry), rather than a deterministic “null deref” at `dataResult.error.code`.
+
+```typescript
+if (dataResult && !dataResult.error) {  // dataResult=undefined -> false
+    return dataResult;
+}
+if (dataResult.error.code === 'keyNotFound') {  // TypeError: Cannot read property 'error' of undefined
+```
+
+**Recommended fix:** Add a null guard: `if (!dataResult) { ... continue to retry ... }` before accessing `dataResult.error`.
+
+---
+
+### [BUG] ErrorHandler.enableCrashProtection Registers Duplicate Handlers on Multiple Calls
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/errors/ErrorHandler.ts:108-122
+
+`enableCrashProtection` has no guard against being called multiple times. While currently called once from `GameServer.start()`, if it were ever called again (e.g., after a restart attempt), each call adds new `process.on` handlers that stack. The `uncaughtException` handler calls `process.exit(1)` after 1 second, and multiple handlers would log duplicate messages.
+
+**Recommended fix:** Add a static `_crashProtectionEnabled` flag and early-return if already set.
+
+---
+
+### [BUG] Ticker._tick Swallows Non-Error Exceptions Silently
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/shared/classes/Ticker.ts:172-181
+
+When the tick callback throws something that is not an `Error` instance and there IS a `_tickErrorCallback`, the error is silently swallowed. The `else` branch only fires when `error` is NOT an Error OR there's no callback. But if `error` is NOT an Error AND there IS a callback, neither branch handles it.
+
+```typescript
+if (error instanceof Error && this._tickErrorCallback) {
+    this._tickErrorCallback(error);  // only if Error AND callback exists
+} else {
+    ErrorHandler.warning(...);       // fires for: (not Error) || (no callback)
+}
+```
+
+Actually this logic is correct -- if it's not an Error, it falls to `else` which logs a warning. But the warning message coerces `error` as `Error` which is misleading. The real issue is that if `error` IS an Error but there's no callback, the warning uses the wrong template (it says "not an instance of Error" when it actually is). Consider splitting the conditions.
+
+---
+
+### [BUG] EventRouter.emit Returns True Even When Final Listener Throws
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/events/EventRouter.ts:46-57
+
+The `emit` method catches exceptions from both `_emitter.emit` and `_finalListeners` invocation in a single try/catch. If the normal emitter succeeds but the final listener throws, the error is logged but `true` is still returned, misleading callers into thinking emission was fully successful. More critically, if `_emitter.emit` throws, the final listener is skipped entirely.
+
+**Recommended fix:** Either invoke the final listener in its own try/catch block, or document that emit's return value only indicates listener presence, not success.
+
+---
+
+### [BUG] SceneUI Constructor Rejects Valid Configurations (Neither Entity Nor Position)
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: no**
+
+File: server/src/worlds/ui/SceneUI.ts:140
+
+The constructor uses `!!options.attachedToEntity === !!options.position` to require exactly one of entity or position. However, this also throws a fatal error when BOTH are undefined (both are falsy, so `false === false` is true). A SceneUI that starts with neither and has entity/position set later via `setAttachedToEntity`/`setPosition` is impossible to create. This forces SDK users to always provide one up front.
+
+**Recommended fix:** Change condition to explicitly check for both being set: `if (options.attachedToEntity && options.position)` and allow neither.
+
+---
+
+### [PERFORMANCE] ModelRegistry.preloadModels Loads Models Sequentially
+**Benefit: 4/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:181-187
+
+Models are loaded one-by-one in a `for...of` loop with `await`. For games with dozens of models, this serializes all I/O and optimization work. The optimization step spawns `npx` subprocesses, which could easily run in parallel (bounded by CPU cores).
+
+```typescript
+for (const absoluteModelPath of absoluteModelPaths) {
+    if (this.optimize) {
+        await this._resolveOptimizedModelPath(absoluteModelPath);
+    }
+    await this._loadModelData(absoluteModelPath);
+}
+```
+
+**Recommended fix:** Use `Promise.all` with a concurrency limiter (e.g., `p-limit`) to parallelize model loading, especially the optimization step. Even just parallelizing data loading (after optimization) would help.
+
+---
+
+### [PERFORMANCE] ModelRegistry._calculateChecksum Reads Entire File + Base64 Encodes
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:545-553
+
+The checksum calculation reads the entire file into memory synchronously (`fs.readFileSync`), then converts to base64 before hashing. The base64 conversion is unnecessary overhead -- hashing the raw buffer is both faster and produces an equally valid checksum. For large model files (10+ MB), this doubles memory usage unnecessarily.
+
+```typescript
+return crypto.createHash('sha256')
+    .update(fileContent.toString('base64'))  // unnecessary base64 conversion
+    .update(MODEL_REGISTRY_CONFIG.VERSION.toString())
+    .digest('hex');
+```
+
+**Recommended fix:** Pass `fileContent` (Buffer) directly to `.update()` without the `.toString('base64')` conversion.
+
+---
+
+### [PERFORMANCE] AudioManager/SceneUIManager/ParticleEmitterManager Entity Lookups Use Linear Scan
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/audios/AudioManager.ts:74-76
+File: server/src/worlds/ui/SceneUIManager.ts:65-67
+File: server/src/worlds/particles/ParticleEmitterManager.ts:72-73
+
+All three managers find entity-attached items via `getAllX().filter(x => x.attachedToEntity === entity)`, which iterates the entire collection, allocates intermediate arrays, and is O(n). When despawning entities with many audio/particle/UI items in a world with hundreds of such items, this becomes expensive.
+
+**Recommended fix:** Maintain a secondary `Map<Entity, Set<T>>` index for entity-attached lookups. This would make cleanup O(1) per entity instead of O(n) over all items.
+
+---
+
+### [PERFORMANCE] BlockTextureRegistry._createPaddedTexture Iterates All Pixels Including Interior
+**Benefit: 2/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/textures/BlockTextureRegistry.ts:329-337
+
+The padding loop iterates over every pixel in the padded texture (including the interior where the original texture already exists), checking if each pixel is in the padding region. For a 24px texture with 20px padding, the padded size is 64x64 = 4096 pixels, but only the ~3520 padding pixels need to be visited. The interior 576 pixels are checked and skipped.
+
+**Recommended fix:** Split into 4 loops that iterate only the padding regions (top/bottom strips, left/right strips, corners). This is a startup-only cost so the benefit is minor.
+
+---
+
+### [PERFORMANCE] Telemetry.getProcessStats Called Twice for Slow Ticks
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/metrics/Telemetry.ts:163-167
+
+In `beforeSend`, `getProcessStats()` (no arg, returns values) is called for every error event. In `beforeSendTransaction`, `getProcessStats(true)` (returns measurements) is called for slow ticks. Both call `process.memoryUsage()` which is not free. If an error occurs during a slow tick, the stats are gathered twice.
+
+This is minor since it only happens on error/slow-tick events, not per-tick.
+
+---
+
+### [BUG] ModelRegistry._preprocessOptimizableModel Temp Files Can Collide
+**Benefit: 3/5 | Risk: 3/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:778-781
+
+Preprocessed models are written to `os.tmpdir()/hytopia-models-temp/<basename>`. If two models in different directories share the same filename (e.g., `assets/weapons/sword.glb` and `assets/armor/sword.glb`), the second write overwrites the first. If optimization ever becomes parallel, this would cause corrupted output.
+
+```typescript
+const tempPath = path.join(tempDir, path.basename(inputPath));
+```
+
+**Recommended fix:** Include a hash of the full path or the source directory in the temp filename to avoid collisions.
+
+---
+
+### [BUG] ModelRegistry._optimizeModel Returns inputPath on First Run Failure, Skipping Remaining Runs
+**Benefit: 3/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:678-681
+
+When optimization fails for one run variant (e.g., the default variant), the method returns `inputPath` immediately, skipping all remaining optimizer runs AND the checksum write. This means subsequent runs (named-nodes, no-animations) are never generated, and the next startup will try to optimize again since no checksum was saved.
+
+**Recommended fix:** Continue to the next run on failure rather than returning early, and only skip the checksum write if ALL runs failed.
+
+---
+
+### [BUG] Audio.setPosition Shallow-Compares Object References
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/audios/Audio.ts:423
+
+`setPosition` uses `this._position === position` which compares object references, not values. If a caller creates a new `{x:1, y:2, z:3}` object with identical values, the check fails and an unnecessary event is emitted. Conversely, if the caller mutates the same object reference, the check passes and no update is sent.
+
+The same pattern exists in `SceneUI.setPosition` (line 255) and `SceneUI.setOffset` (line 234).
+
+**Recommended fix:** Compare x/y/z values individually, or accept that reference comparison is intentional (document it).
+
+---
+
+### [FEATURE] EventRouter Has No Way to Remove All Listeners for a Specific Instance
+**Benefit: 3/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/events/EventRouter.ts
+
+When entities/audio/UI are destroyed, their EventRouter listeners on external routers (world, global) may linger. There is `offAll(eventType?)` but no `removeAllListenersOf(targetRouter)` pattern. Individual `off()` calls are needed for each registered listener, which is error-prone and relies on callers tracking their own listener references.
+
+**Recommended fix:** This is somewhat mitigated by the per-instance EventRouter pattern (each object IS its own router). But for cross-router subscriptions (e.g., ChatManager subscribing to world events), provide a `dispose()` method that auto-removes all subscriptions.
+
+---
+
+### [FEATURE] ChatManager Command Registration Has No Duplicate Protection
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/chat/ChatManager.ts:114-116
+
+`registerCommand` silently overwrites existing commands with the same name. If two game systems independently register `/help`, the second silently replaces the first with no warning.
+
+**Recommended fix:** Log a warning when overwriting an existing command, or provide a `forceRegister` option.
+
+---
+
+### [FEATURE] ChatManager Has No Command Validation or Sanitization
+**Benefit: 2/5 | Risk: 1/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/chat/ChatManager.ts:164-175
+
+`handleCommand` does not validate or sanitize the message before splitting and dispatching. While the command callbacks receive raw `args`, there is no built-in length limiting, rate limiting, or character filtering. Long messages could produce very large `args` arrays.
+
+The chat system itself does not appear vulnerable to injection since messages are dispatched through the event system and serialized via protocol buffers, but command callbacks written by SDK users may be vulnerable if they concatenate args into shell commands or database queries.
+
+**Recommended fix:** Document security considerations for command callbacks. Optionally add a max message length check.
+
+---
+
+### [PERFORMANCE] ModelRegistry Reads Source File Twice During Data Regeneration
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:427-456
+
+`_loadModelData` first calls `_calculateChecksum(absoluteModelPath)` which reads the entire file via `fs.readFileSync`, then if data needs regeneration, creates a `NodeIO().read(absoluteModelPath)` which reads the file again. For large model files, this doubles I/O.
+
+**Recommended fix:** Cache the file buffer from the checksum calculation and pass it to `NodeIO` if available, or restructure to avoid the double-read.
+
+---
+
+### [BUG] startServer Uses init.length for Arity Detection (Unreliable with Default Parameters)
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/GameServer.ts:74
+
+`init.length > 0` checks the function's `length` property to determine if it expects a `world` parameter. JavaScript's `Function.length` only counts parameters before the first one with a default value. So `(world = defaultWorld) => {...}` would have `length === 0` and wouldn't receive the world, which is surprising.
+
+**Recommended fix:** Document this behavior, or provide separate `startServer` overloads / a config object rather than relying on arity detection.
+
+---
+
+### [BUG] Ticker Accumulator Can Cause Dropped Ticks When TICK_SLOW_UPDATE_CAP < MAX_ACCUMULATOR_TICK_MULTIPLE
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/shared/classes/Ticker.ts:4-5, 125-137
+
+`TICK_SLOW_UPDATE_CAP = 2` limits updates per loop iteration, while `MAX_ACCUMULATOR_TICK_MULTIPLE = 3` allows the accumulator to hold up to 3 ticks worth of time. If the accumulator reaches 3x and only 2 ticks are processed, 1 tick worth of time remains. On the next iteration, if it stays behind, the accumulator is clamped again and the deficit grows. This means the game permanently runs slower than real time under sustained load instead of catching up.
+
+This is actually the intended behavior (graceful degradation under load), but the constants should be aligned or the relationship documented.
+
+---
+
+### [BUG] ErrorHandler Crash Protection Calls process.exit After 1 Second Regardless of Recovery
+**Benefit: 2/5 | Risk: 3/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/errors/ErrorHandler.ts:117-118
+
+The `uncaughtException` handler logs the error and then unconditionally schedules `process.exit(1)` after 1 second. The comment and log message say "[FATAL]" but the method called is `this.error()` (non-fatal). The 1-second delay allows some I/O to flush but the process always exits regardless of whether the exception was actually fatal. Meanwhile `unhandledRejection` does NOT exit, creating inconsistent behavior between sync and async errors.
+
+**Recommended fix:** This is debatable -- Node.js docs recommend exiting after uncaughtException. But the inconsistency with unhandledRejection should be documented or aligned.
+
+---
+
+### [PERFORMANCE] Vector3/Quaternion Extend Float32Array (Allocation Cost)
+**Benefit: 2/5 | Risk: 5/5 | Effort: 5/5 | Surgical: no | Backwards Compatible: no**
+
+File: server/src/shared/classes/Vector3.ts, Quaternion.ts
+
+`Vector3` and `Quaternion` extend `Float32Array`, which means each `new Vector3(...)` allocates a typed array (involving ArrayBuffer backing store). In V8, typed arrays have higher allocation overhead than plain objects. For a game engine creating many temporary vectors per tick, this adds GC pressure.
+
+However, this design enables direct passing to gl-matrix functions without conversion, which is a significant benefit. Changing this would break the entire SDK API surface.
+
+**Not recommended for change** -- the tradeoff is reasonable. Noted for awareness.
+
+---
+
+### [BUG] ModelRegistry._optimizeModel Writes Checksum Even When UASTC Compression Fails
+**Benefit: 2/5 | Risk: 2/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts:695-703
+
+When the `uastc` compression step fails, a warning is logged but the loop continues. The checksum is then saved at line 701, marking the model as "optimized." On next startup, the checksum matches and the uncompressed model is served. The user may not notice the warning and silently serve larger uncompressed textures.
+
+**Recommended fix:** Either don't save the checksum when compression fails (so optimization is retried), or log a more prominent error.
+
+---
+
+### [FEATURE] AudioManager Never Cleans Up Non-Looping Audio That Finishes Playing
+**Benefit: 3/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/worlds/audios/AudioManager.ts
+
+One-shot audio instances are registered in the manager but never automatically unregistered after playback completes. The `_audios` map grows indefinitely if many one-shot sounds are played. While the audio plays client-side and naturally stops, the server-side tracking remains, consuming memory.
+
+**Recommended fix:** Add a TTL-based cleanup that periodically removes non-looping audio instances whose expected duration (based on `startTick` + `duration`) has elapsed. Or require explicit `unregisterAudio` calls from game code (but document this requirement).
+
+---
+
+### [BUG] Ajv Singleton Inconsistency: Class and Static Instance Are Different
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/shared/classes/Ajv.ts:12-16
+
+The class extends `Ajv` but the static `instance` creates a plain `new Ajv()`, not a `new` of the subclass. This means `AjvWrapper.instance instanceof AjvWrapper` is false. While functionally harmless (the wrapper adds nothing), it's confusing.
+
+```typescript
+export default class extends Ajv {
+    public static readonly instance = new Ajv();  // not new (this class)
+}
+```
+
+---
+
+### [FEATURE] PersistenceManager.setGlobalData Has No Retry Logic Unlike getGlobalData
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/persistence/PersistenceManager.ts:104-112
+
+`getGlobalData` retries up to `maxRetries` times on failure, but `setGlobalData` attempts only once. A transient network error during a write loses data silently with only a warning.
+
+**Recommended fix:** Add retry logic to `setGlobalData` consistent with `getGlobalData`, or document that writes are fire-and-forget.
+
+---
+
+### [FEATURE] SceneUI State Merge Is Shallow Only
+**Benefit: 2/5 | Risk: 2/5 | Effort: 2/5 | Surgical: yes | Backwards Compatible: no**
+
+File: server/src/worlds/ui/SceneUI.ts:273-274
+
+`setState` does a shallow merge (`{ ...this._state, ...state }`). Nested object properties are replaced entirely rather than merged. This is a common footgun for SDK users who expect deep merge behavior.
+
+**Recommended fix:** Document clearly that setState is a shallow merge, or provide a `setStateDeep` alternative.
+
+---
+
+### [BUG] EventRouter.emit listenerCount Check Disagrees with Actual Emission
+**Benefit: 2/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/events/EventRouter.ts:47
+
+`emit` returns false if `listenerCount === 0`, skipping both normal and final listeners. However, `listenerCount` includes both the emitter's listeners and the final listener. The check is actually correct, but if a `once` listener was the only listener and it fires during the same `emit` call, the count could be stale. This is a theoretical edge case since eventemitter3 handles this correctly.
+
+---
+
+### [PERFORMANCE] BlockTextureRegistry.preloadAtlas Loads All Textures Into Memory At Once
+**Benefit: 2/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/textures/BlockTextureRegistry.ts:168-179
+
+All block textures are loaded simultaneously via `Promise.all`. For games with hundreds of block textures, this creates a memory spike. Each Jimp image allocates a bitmap buffer.
+
+Since block textures are small (24x24), this is unlikely to be a practical issue. Noted for completeness.
+
+---
+
+### [FEATURE] ModelRegistry Has No Way to Register Models at Runtime
+**Benefit: 2/5 | Risk: 2/5 | Effort: 3/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/models/ModelRegistry.ts
+
+All models are discovered and loaded at startup. There is no public API to register a model at runtime (e.g., for user-uploaded content or dynamically generated assets). Adding a `registerModel(uri, path)` method would enable dynamic content loading.
+
+---
+
+### [BUG] AssetsLibrary.syncAsset Uses Relative Path Without CWD Context
+**Benefit: 1/5 | Risk: 1/5 | Effort: 1/5 | Surgical: yes | Backwards Compatible: yes**
+
+File: server/src/assets/AssetsLibrary.ts:72-73
+
+`path.join('assets', relativePath)` creates a relative path, meaning it depends on `process.cwd()` being the project root. This is typically true in HYTOPIA's runtime, but if the server is started from a different directory, assets would be written to the wrong location.
+
+**Recommended fix:** Use `path.resolve(process.cwd(), 'assets', relativePath)` for explicit CWD resolution.
diff --git a/AUDIT_VERIFIED_ONLY.md b/AUDIT_VERIFIED_ONLY.md
new file mode 100644
index 00000000..e8e52801
--- /dev/null
+++ b/AUDIT_VERIFIED_ONLY.md
@@ -0,0 +1,125 @@
+# HYTOPIA Engine — Verified Findings Only
+
+Date: 2026-03-02  
+Branch: `analysis/codebase-audit`
+
+This document lists **only findings that were manually verified in code** (not “likely”, not “possible”, not “depends” without stating what is strictly verified).
+
+If a risk depends on deployment / embedding policy, the *code-level fact* is still listed, and the dependency is called out explicitly.
+
+---
+
+## Security / Trust Boundaries
+
+### 1) TLS private key committed in-repo (publicly trusted cert, wildcard SAN)
+
+- Evidence: `server/src/networking/ssl/certs.ts:100`
+- Verified facts:
+  - `SSL_KEY` is a real private key committed directly in source.
+  - The corresponding `SSL_CERT` is issued by Amazon and includes SANs for `local.hytopiahosting.com` and `*.dns-is-boring-we-do-ip-addresses.hytopiahosting.com`.
+  - Certificate validity window is `2025-11-20` through `2026-12-19`.
+- Why it matters:
+  - Anyone with this repo contents can impersonate endpoints covered by the wildcard SAN in any context that trusts public CAs.
+
+### 2) Client UI executes fetched HTML and scripts (no sandbox)
+
+- Evidence: `client/src/ui/UIManager.ts:149` and `client/src/ui/UIManager.ts:164`
+- Verified facts:
+  - The client fetches HTML (`deserializedUI.htmlUri`) and assigns it into the DOM via `innerHTML`.
+  - It then executes `<script>` tags via `_executeScripts(...)`.
+- Why it matters:
+  - This allows arbitrary JS execution in the game iframe context from any server-controlled UI payload (by design/trust model, but it is an execution sink).
+
+### 3) BridgeManager accepts `message` events without origin/source validation
+
+- Evidence: `client/src/bridge/BridgeManager.ts:94` and `client/src/bridge/BridgeManager.ts:152`
+- Verified facts:
+  - The client subscribes to `window.addEventListener('message', ...)`.
+  - `_onParentMessage` does not check `event.origin` and does not check `event.source === window.parent` before handling commands.
+- Why it matters:
+  - Impact depends on embedding policy (who can iframe the client / who can send messages). The missing validation is a concrete gap regardless.
+
+### 4) GraphQL query builds request by interpolating `userId` into a query string
+
+- Evidence: `server/src/networking/PlatformGateway.ts:198` and `server/src/networking/PlatformGateway.ts:201`
+- Verified facts:
+  - `getPlayerCosmetics(userId)` interpolates `userId` directly into the GraphQL query string.
+- Why it matters:
+  - Whether this is exploitable depends on whether `userId` can be attacker-controlled. The interpolation pattern is still a footgun.
+
+---
+
+## Server Bugs
+
+### 5) WebServer asset cache metadata never revalidated after first stat
+
+- Evidence: `server/src/networking/WebServer.ts:241`
+- Verified facts:
+  - `_assetCache` caches `{ size, etag }` on first access and does not re-stat / invalidate entries when the file changes.
+- Why it matters:
+  - During dev or when assets change on disk, the server can serve stale `etag` / `content-length` behavior until restarted.
+
+---
+
+## Entity / Gameplay Bugs
+
+### 6) PlayerEntity adds a chat listener on spawn without any removal path
+
+- Evidence: `server/src/worlds/entities/PlayerEntity.ts:132` and `server/src/worlds/entities/PlayerEntity.ts:137`
+- Verified facts:
+  - `PlayerEntity.spawn()` registers an anonymous `player.on(PlayerEvent.CHAT_MESSAGE_SEND, ...)` handler.
+  - There is no corresponding `off(...)` in `PlayerEntity` for despawn/unload.
+- Why it matters:
+  - Respawn/world-switch patterns can accumulate listeners and stale callbacks.
+
+### 7) DefaultPlayerEntity cosmetics can apply after despawn (async race)
+
+- Evidence: `server/src/worlds/entities/DefaultPlayerEntity.ts:119` and `server/src/worlds/entities/DefaultPlayerEntity.ts:122`
+- Verified facts:
+  - `DefaultPlayerEntity.spawn()` attaches a `.then(...)` handler to `this.player.cosmetics`.
+  - The callback does not check `this.isSpawned` / `this.world` before spawning cosmetic child entities into `world`.
+- Why it matters:
+  - If the promise resolves after despawn, cosmetic entities can be spawned unexpectedly.
+
+---
+
+## Client Resource Leaks / Performance
+
+### 8) DebugRenderer raycast visualization allocates GPU resources without disposal
+
+- Evidence: `client/src/core/DebugRenderer.ts:48` and `client/src/core/DebugRenderer.ts:63`
+- Verified facts:
+  - For each debug raycast, the client allocates new `BufferGeometry()` and `LineBasicMaterial()`.
+  - It later removes the group from the scene but does not dispose geometry/material resources.
+- Why it matters:
+  - Over time this can leak WebGL resources in sessions where debug raycasts are emitted frequently.
+
+### 9) Liquid material animation time is frame-rate dependent
+
+- Evidence: `client/src/blocks/BlockMaterialManager.ts:271`
+- Verified facts:
+  - Liquid shader time uses a fixed per-frame increment (`+= 0.0075`) instead of delta time.
+- Why it matters:
+  - Animation speed varies with FPS.
+
+### 10) LightLevelVolume packed index helper allocates an object on each call
+
+- Evidence: `client/src/chunks/LightLevelVolume.ts:25`
+- Verified facts:
+  - `_getPackedIndex()` returns a fresh `{ byteIndex, isHighNibble }` object for each call.
+- Why it matters:
+  - This adds avoidable allocation churn in tight loops.
+
+---
+
+## Server Performance
+
+### 11) Path reconstruction uses `unshift()` and coordinate keys allocate strings
+
+- Evidence: `server/src/worlds/entities/controllers/PathfindingEntityController.ts:515`
+- Verified facts:
+  - `_reconstructPath()` calls `path.unshift(...)` inside a loop.
+  - `_coordinateToKey()` uses template-string concatenation to build string keys.
+- Why it matters:
+  - `unshift()` in a loop is O(N²) behavior, and string keys add GC churn in pathfinding hot paths.
+