Bring in Godot project + address review feedback (this branch had none of it)

This branch never actually had the Godot scaffold — a workspace-reuse bug
(see agp source repo) let leftover backend/**/__pycache__/*.pyc files from
an unrelated task get swept into this branch's only prior commit, which
was checkpointed under this task's title despite containing zero Godot
files. Removing that garbage and bringing over the real project from
agent/997c429bc6b4 (the original PR's branch) with the review feedback
addressed:

- Play button no longer references the nonexistent scenes/game.tscn.
- Wired PlayButton/QuitButton [connection] entries in main_menu.tscn.
- Removed the invalid uid="uid://main_menu".
- Added .gitignore for .godot/.
- Removed the non-standard [export]/[export_options] sections from
  project.godot (Godot 4 uses export_presets.cfg, not this).

.gitignore

@@ -0,0 +1,2 @@
+# Godot 4 editor cache/import directory
+.godot/

docs/architecture/avatar.md

@@ -0,0 +1,462 @@
+# Avatar Component System & glTF Attachment Spec
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** Server authority + client prediction, world chunk data format
+
+## 1. Overview
+
+This document specifies the **avatar component system** for **agp-game**, a
+Godot-based multiplayer game. It defines:
+
+- How an avatar is decomposed into **body parts** and **attachment slots**.
+- How **cosmetic attachments** (clothing, accessories, gear) mount onto the
+  base body.
+- The **glTF/GLB format requirements** that all avatar assets must satisfy so
+  they can be loaded, skinned, and networked consistently.
+
+The goal is a **modular, data-driven avatar pipeline**: a single base body rig
+plus swappable attachments, all authored in glTF and consumed by a shared Godot
+runtime. This enables player customization, cosmetic monetization, and
+server-authoritative validation of what a player is wearing.
+
+### 1.1 Design Goals
+
+- **Modularity:** Body parts and attachments are independent assets that can be
+  combined at runtime without re-exporting.
+- **Consistency:** A single, well-defined skeleton and slot convention so any
+  attachment fits any base body.
+- **Networkability:** The avatar's composition is expressed as a compact,
+  serializable **loadout** that the server can validate and replicate.
+- **Performance:** Attachments are skinned to the same skeleton and share
+  materials where possible to minimize draw calls and skinning cost.
+- **Tooling-friendly:** Assets are authored in standard glTF 2.0 and validated
+  by a build-time checker.
+
+---
+
+## 2. Avatar Decomposition
+
+### 2.1 The Base Body
+
+Every avatar is built on a **base body** — a single glTF asset containing:
+
+- A **skeleton** (the canonical rig, see §3).
+- A **base mesh** for the skin/body (head, torso, arms, legs).
+- **Attachment points** (empty nodes) that define where accessories mount.
+
+The base body is the only asset that carries the skeleton. Attachments reference
+the skeleton by **bone name** and are skinned to it; they never carry their own
+rig.
+
+### 2.2 Body Parts vs. Attachments
+
+Two distinct concepts:
+
+| Concept        | Definition                                                              | Example                          |
+|----------------|-------------------------------------------------------------------------|----------------------------------|
+| **Body part**  | A mesh that replaces part of the base body's skin (e.g., a different head, a tail, wings). | Alternate head, cybernetic arm |
+| **Attachment** | A mesh that mounts *on top of* the body without replacing it (clothing, accessories). | Shirt, hat, glasses, backpack |
+
+The distinction matters for **slot exclusivity** and **layering**:
+
+- **Body parts** are *exclusive* per slot — only one head can be equipped.
+- **Attachments** are *layered* — a hat and glasses can coexist, and both sit
+  above the head mesh.
+
+---
+
+## 3. Skeleton & Slot Convention
+
+### 3.1 Canonical Skeleton
+
+All avatars share a **canonical skeleton** with a fixed set of bone names. This
+is the contract that lets any attachment fit any body. The skeleton follows a
+humanoid convention (Godot's `Humanoid` profile / glTF VRM-style naming).
+
+Required bones (subset of the full rig):
+
+```
+Root
+├── Hips
+│   ├── Spine
+│   │   ├── Chest
+│   │   │   ├── Neck
+│   │   │   │   └── Head
+│   │   │   │       ├── HeadTop          # hat / hair mount
+│   │   │   │       ├── Jaw              # face accessories
+│   │   │   │       └── LeftEye / RightEye
+│   │   │   ├── LeftShoulder
+│   │   │   │   └── LeftUpperArm
+│   │   │   │       └── LeftLowerArm
+│   │   │   │           └── LeftHand
+│   │   │   └── RightShoulder
+│   │   │       └── RightUpperArm
+│   │   │           └── RightLowerArm
+│   │   │               └── RightHand
+│   │   └── (Chest children for torso attachments)
+│   ├── LeftUpperLeg
+│   │   └── LeftLowerLeg
+│   │       └── LeftFoot
+│   └── RightUpperLeg
+│       └── RightLowerLeg
+│           └── RightFoot
+```
+
+**Rules:**
+
+- Bone names are **case-sensitive** and must match exactly.
+- The skeleton is **T-pose** at rest for consistent skinning.
+- Attachments must be skinned to **at least** the bones they deform; static
+  accessories may be parented to a single bone (e.g., a hat parented to `Head`).
+
+### 3.2 Attachment Slots
+
+Slots are the **logical mount points** for body parts and attachments. Each slot
+maps to one or more bones and defines what can be equipped there.
+
+| Slot ID        | Category     | Mount bone(s)      | Exclusivity | Example assets                |
+|----------------|--------------|--------------------|-------------|-------------------------------|
+| `head`         | body part    | `Head`             | exclusive   | alternate head, face          |
+| `hair`         | attachment   | `HeadTop`          | exclusive   | hairstyles, hats              |
+| `face`         | attachment   | `Jaw`              | exclusive   | glasses, masks, beards        |
+| `torso`        | body part    | `Chest`            | exclusive   | alternate torso               |
+| `chest`        | attachment   | `Chest`            | exclusive   | shirts, armor, chest gear     |
+| `back`         | attachment   | `Chest` (back)     | exclusive   | backpacks, wings, capes       |
+| `left_arm`     | body part    | `LeftUpperArm`     | exclusive   | alternate arm                 |
+| `right_arm`    | body part    | `RightUpperArm`    | exclusive   | alternate arm                 |
+| `left_hand`    | attachment   | `LeftHand`         | exclusive   | gloves, weapons (held)        |
+| `right_hand`   | attachment   | `RightHand`        | exclusive   | gloves, weapons (held)        |
+| `legs`         | body part    | `Hips`             | exclusive   | alternate legs                |
+| `pants`        | attachment   | `Hips`             | exclusive   | pants, skirts                 |
+| `left_foot`    | attachment   | `LeftFoot`         | exclusive   | shoes                         |
+| `right_foot`   | attachment   | `RightFoot`        | exclusive   | shoes                         |
+| `accessory`    | attachment   | `Root` (free)      | multiple    | belts, jewelry, floating items|
+
+**Slot semantics:**
+
+- **`exclusive`** slots allow at most one equipped item at a time.
+- The **`accessory`** slot is *multi-slot* — multiple accessories may be equipped
+  simultaneously (bounded by a configurable limit, e.g., 8).
+- **Body-part slots** (`head`, `torso`, `legs`, `left_arm`, `right_arm`) replace
+  the corresponding base mesh. When a body part is equipped, the base mesh for
+  that region is hidden.
+- **Attachment slots** layer on top of the base mesh and never hide it.
+
+### 3.3 Slot → Bone Mapping
+
+Each slot declares a **primary mount bone** and an optional **secondary bone
+list** for skinning. The runtime uses this to:
+
+1. Parent static accessories to the mount bone.
+2. Skin skinned attachments to the union of the slot's bones.
+
+---
+
+## 4. glTF/GLB Format Requirements
+
+All avatar assets (base bodies, body parts, attachments) are distributed as
+**glTF 2.0** (`.gltf` + external buffers/textures) or **GLB** (`.glb`, binary
+container). GLB is the preferred distribution format for runtime loading.
+
+### 4.1 Required Conventions
+
+| Concern            | Requirement                                                                 |
+|--------------------|------------------------------------------------------------------------------|
+| **Format**         | glTF 2.0 (`.gltf` or `.glb`). GLB preferred for runtime.                     |
+| **Coordinate system** | glTF standard: **+Y up, +Z forward, right-handed**. Godot converts to its own convention on import. |
+| **Units**          | Meters. Avatar height ~1.8 m at the `Root` bone.                              |
+| **Skeleton**       | Single skeleton per asset; bone names per §3.1.                              |
+| **Skinning**       | `skins` + `nodes` with `JOINTS_0` / `WEIGHTS_0` accessors.                    |
+| **Pose**           | T-pose at rest.                                                              |
+| **Materials**      | PBR metallic-roughness. Use `KHR_materials_unlit` for emissive/UI-only items. |
+| **Textures**       | Max 2048×2048; power-of-two preferred. Use `KHR_texture_basisu` (BasisU) for runtime. |
+| **Animation**      | Optional. If present, must not rename or remove canonical bones.             |
+
+### 4.2 Asset Metadata (extras)
+
+Each asset **must** declare its slot and identity in the glTF `asset.extras`
+object. This is the machine-readable contract consumed by the build pipeline and
+runtime.
+
+```json
+{
+  "asset": {
+    "version": "2.0",
+    "extras": {
+      "agp": {
+        "type": "attachment",          // "base_body" | "body_part" | "attachment"
+        "slot": "chest",               // slot ID from §3.2
+        "id": "shirt_bandit_01",       // globally unique asset id
+        "display_name": "Bandit Shirt",
+        "version": "1.0.0",
+        "mount_bone": "Chest",         // primary mount bone
+        "skin_bones": ["Chest", "Spine", "LeftUpperArm", "RightUpperArm"],
+        "exclusive": true,             // matches slot exclusivity
+        "tags": ["cloth", "common"],
+        "author": "platform-team"
+      }
+    }
+  }
+}
+```
+
+**Validation rules for `extras.agp`:**
+
+- `type` must be one of `base_body`, `body_part`, `attachment`.
+- `slot` must be a known slot ID (§3.2).
+- `mount_bone` must exist in the canonical skeleton.
+- `skin_bones` must all exist in the canonical skeleton.
+- `exclusive` must match the slot's declared exclusivity.
+- `id` must be unique across the asset catalog.
+
+### 4.3 Node Naming Convention
+
+To make assets self-describing and mergeable, nodes follow a convention:
+
+- **Base body:** the mesh node is named `Body`; the skeleton root is `Root`.
+- **Body part:** the mesh node is named `<SlotID>_Mesh` (e.g., `head_Mesh`).
+- **Attachment:** the mesh node is named `<SlotID>_<AssetID>` (e.g.,
+  `chest_shirt_bandit_01`).
+- **Attachment points** (empty nodes) on the base body are named
+  `attach_<slot>` (e.g., `attach_head`, `attach_left_hand`).
+
+### 4.4 Material & Texture Requirements
+
+- All materials use the **metallic-roughness** PBR model.
+- Textures are embedded in the GLB or referenced as external files; external
+  references must be relative paths within the asset package.
+- **Color customization** is supported via a `baseColorFactor` tint applied at
+  runtime (multiplied over the albedo). Assets should use a neutral albedo
+  (white/gray) where tinting is intended.
+- **Masked/transparent** materials must set the correct alpha mode
+  (`MASK` or `BLEND`) and `alphaCutoff`.
+
+### 4.5 Skeleton Merging at Runtime
+
+When an attachment is loaded, the runtime **merges** it onto the base body:
+
+1. Load the base body (skeleton + base meshes).
+2. Load each equipped attachment.
+3. For each attachment, **re-target its skin** to the base body's skeleton by
+   bone name (no re-export needed).
+4. Parent static accessories to their `mount_bone`.
+5. Hide base meshes for any equipped body-part slots.
+6. Apply material tints and merge into the render tree.
+
+The merge is **name-based** — bone names must match exactly (§3.1). This is the
+core reason for the strict naming contract.
+
+---
+
+## 5. Loadout Model (Network & Persistence)
+
+The avatar's composition is serialized as a **loadout** — a compact, ordered
+list of equipped asset IDs. This is what the server validates, persists, and
+replicates.
+
+### 5.1 Loadout JSON
+
+```json
+{
+  "base_body": "base_human_male_01",
+  "slots": {
+    "head":   "head_cyber_01",
+    "hair":   "hair_mohawk_01",
+    "face":   null,
+    "torso":  null,
+    "chest":  "chest_bandit_01",
+    "back":   "backpack_01",
+    "left_arm":  null,
+    "right_arm": null,
+    "left_hand": "glove_leather_01",
+    "right_hand": "glove_leather_01",
+    "legs":   null,
+    "pants":  "pants_cargo_01",
+    "left_foot":  "shoe_boot_01",
+    "right_foot": "shoe_boot_01",
+    "accessory": ["belt_01", "necklace_01"]
+  }
+}
+```
+
+**Rules:**
+
+- `base_body` is required and must reference a valid `base_body` asset.
+- Each exclusive slot holds **at most one** asset id (or `null`).
+- `accessory` is an array (0..N, bounded).
+- The server validates that every id exists in the catalog and that slot
+  exclusivity is respected.
+
+### 5.2 Network Replication
+
+The loadout is replicated as part of the player's spawn/state data:
+
+```
+spawn_entity:
+  entity_id: uint32
+  type: player
+  transform: { x, y, rot }
+  props:
+    loadout_hash: uint32      # hash of the loadout for change detection
+    loadout: { ... }          # full loadout on spawn / on change
+```
+
+- The **full loadout** is sent on spawn and whenever it changes (reliable).
+- A **`loadout_hash`** lets clients skip re-resolving assets if unchanged.
+- The server is the **authority** on the loadout; clients send *requests* to
+  change equipment, and the server validates and broadcasts the result.
+
+### 5.3 Server-Side Validation
+
+The server rejects a loadout if:
+
+- `base_body` is missing or unknown.
+- Any slot references an unknown asset id.
+- An exclusive slot has more than one item.
+- An asset's declared `slot` does not match the slot it is placed in.
+- The accessory list exceeds the configured limit.
+- The asset is not owned/unlocked by the player (for gated cosmetics).
+
+---
+
+## 6. Godot Runtime Architecture
+
+### 6.1 Node Structure
+
+```
+Avatar (Node3D)
+├── Skeleton3D            # canonical skeleton (from base body)
+├── BodyMeshes            # base body meshes (skinned to Skeleton3D)
+│   ├── head_Mesh
+│   ├── torso_Mesh
+│   └── ...
+├── Attachments           # equipped attachments
+│   ├── chest_shirt_bandit_01
+│   ├── hair_mohawk_01
+│   └── ...
+└── AttachmentPoints      # empty nodes for dynamic mounting
+    ├── attach_head
+    ├── attach_left_hand
+    └── ...
+```
+
+### 6.2 Core Classes
+
+| Class                    | Responsibility                                              |
+|--------------------------|-------------------------------------------------------------|
+| `AvatarSystem`           | Loads base body + attachments, resolves loadouts, owns the avatar node. |
+| `AvatarLoader`           | glTF/GLB import, skeleton merge, skin re-targeting.          |
+| `AvatarSlotRegistry`     | Static registry of slot definitions (id, bones, exclusivity).|
+| `AvatarLoadout`          | Serializable loadout model + validation.                    |
+| `AvatarCatalog`          | Asset catalog (id → asset metadata + resource path).         |
+| `AvatarVisualizer`       | Builds the render tree from a loadout.                      |
+
+### 6.3 Loading Pipeline
+
+```
+loadout JSON
+   │
+   ▼
+AvatarCatalog.resolve(loadout)   # id → asset metadata + GLB path
+   │
+   ▼
+AvatarLoader.load_base_body()    # import GLB, extract skeleton + base meshes
+   │
+   ▼
+for each equipped slot:
+   AvatarLoader.load_attachment()# import GLB, re-target skin to skeleton
+   │
+   ▼
+AvatarVisualizer.assemble()      # parent, hide replaced parts, apply tints
+   │
+   ▼
+Avatar node ready for render
+```
+
+### 6.4 Performance Considerations
+
+- **Shared skeleton:** All meshes skin to one `Skeleton3D`, so skinning is
+  computed once per frame.
+- **Material batching:** Attachments that share a material are merged into a
+  single mesh where possible (static accessories).
+- **LOD:** Optional LOD variants per asset; the runtime selects based on
+  distance.
+- **Caching:** Resolved loadouts and imported GLB resources are cached by
+  `AvatarCatalog` to avoid re-importing on respawn or re-join.
+
+---
+
+## 7. Asset Pipeline & Validation
+
+### 7.1 Build-Time Validation
+
+A build-time checker validates every asset before it enters the catalog:
+
+1. **Format check:** valid glTF 2.0 / GLB.
+2. **Metadata check:** `extras.agp` present and valid (§4.2).
+3. **Skeleton check:** all `skin_bones` exist in the canonical skeleton.
+4. **Slot check:** `slot` is known and `exclusive` matches.
+5. **Mesh check:** meshes are skinned (or static accessories parented to a bone).
+6. **Texture check:** sizes, formats, and alpha modes are valid.
+7. **Uniqueness check:** `id` is unique.
+
+### 7.2 Catalog Manifest
+
+The catalog is a JSON manifest mapping asset ids to metadata and resource paths:
+
+```json
+{
+  "assets": {
+    "base_human_male_01": {
+      "type": "base_body",
+      "path": "res://assets/avatars/base_human_male_01.glb",
+      "version": "1.0.0"
+    },
+    "chest_bandit_01": {
+      "type": "attachment",
+      "slot": "chest",
+      "path": "res://assets/avatars/chest_bandit_01.glb",
+      "version": "1.0.0"
+    }
+  }
+}
+```
+
+---
+
+## 8. Security & Anti-Cheat
+
+- **Server-authoritative loadouts:** Clients only *request* equipment changes;
+  the server validates against the catalog and the player's owned items.
+- **No client asset injection:** Clients cannot send arbitrary GLB data; they
+  reference catalog ids only.
+- **Rate limiting:** Equipment-change requests are rate-limited per peer.
+- **Hash verification:** The `loadout_hash` lets the server detect tampered or
+  stale loadout state.
+
+---
+
+## 9. Open Questions / Future Work
+
+- **Morph targets / blendshapes:** Support for facial expressions and body
+  morphs (e.g., height, muscle) via glTF morph targets.
+- **Physics attachments:** Cloth simulation for capes/skirts (Godot cloth).
+- **Dynamic tinting UI:** A color-picker that writes `baseColorFactor` tints.
+- **VRM compatibility:** Consider supporting VRM (a glTF extension for
+  humanoid avatars) as an import source.
+- **Attachment LOD streaming:** Streaming high-res attachments on demand.
+
+---
+
+## 10. Summary
+
+| Concern                | Decision                                              |
+|------------------------|-------------------------------------------------------|
+| Format                 | glTF 2.0 / GLB (GLB preferred for runtime)            |
+| Skeleton               | Single canonical humanoid skeleton, name-based merge  |
+| Slots                  | Fixed slot registry; exclusive body parts + layered attachments |
+| Loadout                | Compact JSON; server-authoritative and validated      |
+| Replication            | Full loadout on spawn/change + `loadout_hash`         |
+| Runtime                | Godot `Skeleton3D` + name-based skin re-targeting     |
+| Validation             | Build-time asset checker + runtime catalog validation |

docs/architecture/networking.md

@@ -0,0 +1,286 @@
+# Multiplayer Networking Architecture
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** Server authority + client prediction
+
+## 1. Overview
+
+This document specifies the multiplayer networking architecture for **agp-game**,
+a Godot-based game built by autonomous agents. The architecture follows a
+**server-authoritative model with client-side prediction and reconciliation**,
+which is the industry standard for fast-paced, competitive multiplayer games.
+
+The goals of this architecture are:
+
+- **Fairness & anti-cheat:** The server is the single source of truth for all
+  gameplay state. Clients never directly mutate world state.
+- **Responsiveness:** Client-side prediction hides network latency so local input
+  feels immediate.
+- **Determinism:** The server runs a fixed-timestep simulation so that state is
+  reproducible and testable.
+- **Scalability:** A clear separation between transport, simulation, and
+  replication layers allows the server to be tuned independently.
+
+---
+
+## 2. Transport Choice: ENet over WebSocket
+
+### 2.1 Decision
+
+We choose **ENet** as the primary transport for gameplay traffic.
+
+### 2.2 Justification
+
+| Criterion            | ENet                                   | WebSocket (TCP)                     |
+|----------------------|----------------------------------------|-------------------------------------|
+| **Reliability model**| Reliable + unreliable channels         | Reliable only (TCP)                 |
+| **Latency**          | Low; unreliable packets skip retransmit| Head-of-line blocking on loss       |
+| **Packet ordering**  | Per-channel ordering                   | Global strict ordering              |
+| **Congestion control**| Lightweight, game-oriented            | TCP-style (slow start, backoff)     |
+| **Godot support**    | First-class (`ENetConnection`, `MultiplayerPeerENet`) | Supported but TCP-based |
+| **Use case fit**     | Real-time action game                  | Chat, lobby, HTTP-style messaging   |
+
+**Rationale:**
+
+- **Movement & state replication** are latency-sensitive and tolerate occasional
+  packet loss. ENet's *unreliable* channel lets us send position snapshots at high
+  frequency without head-of-line blocking.
+- **RPCs that must be delivered** (e.g., interactions, spawns) use ENet's
+  *reliable* channel, giving us exactly the semantics we need without TCP's
+  retransmission stalls.
+- Godot's `MultiplayerPeerENet` is mature and integrates directly with the
+  high-level multiplayer API (`MultiplayerAPI`, `rpc()`).
+
+### 2.3 WebSocket as a Secondary Transport
+
+WebSocket remains available as a **secondary transport** for:
+
+- **Lobby / matchmaking** messaging (low-frequency, must-be-reliable).
+- **Browser builds** where raw UDP/ENet is unavailable.
+- **Admin / telemetry** channels.
+
+The transport layer is abstracted behind an interface so gameplay code does not
+depend on the underlying protocol.
+
+---
+
+## 3. Server-Side Game Loop
+
+### 3.1 Tick Rate
+
+- **Simulation tick rate:** **30 Hz** (33.33 ms per tick).
+- **Replication / snapshot rate:** **30 Hz**, aligned with the simulation tick.
+
+**Justification:**
+
+- 30 Hz is sufficient for smooth movement and interaction in a top-down / 2D
+  action game while keeping CPU and bandwidth costs predictable.
+- A fixed timestep (rather than delta-time) makes the simulation deterministic
+  and testable.
+- The tick rate is a **configuration constant** so it can be raised (e.g., to
+  60 Hz) for competitive modes without architectural changes.
+
+### 3.2 Authority Model
+
+- **Server is authoritative** for:
+  - Player position, velocity, and physics state.
+  - Health, damage, and death.
+  - Item pickups, inventory, and world-object state.
+  - Spawning and despawning of entities.
+  - Game rules, scoring, and win/lose conditions.
+- **Client is authoritative** for:
+  - Its own *input* (which keys/buttons are pressed).
+  - Local camera and UI.
+  - Cosmetic / non-gameplay presentation.
+
+### 3.3 Server Loop Pseudocode
+
+```
+while server_running:
+    process_network_inbound()      # read client inputs & RPCs
+    for _ in range(ticks_to_advance):
+        simulate_tick()            # fixed 30 Hz step
+    broadcast_snapshots()          # replicate authoritative state
+    process_network_outbound()     # flush reliable/unreliable channels
+```
+
+The server accumulates real elapsed time and advances the simulation in fixed
+`TICK_DURATION` increments, decoupling simulation from frame rate.
+
+---
+
+## 4. RPC Call Patterns
+
+RPCs are grouped by direction and reliability. All gameplay RPCs are routed
+through the high-level `MultiplayerAPI` with explicit `rpc_id` targeting.
+
+### 4.1 Client → Server (Input & Requests)
+
+| RPC                          | Channel   | Payload                                   | Notes |
+|------------------------------|-----------|-------------------------------------------|-------|
+| `request_move_input`         | unreliable| `{ seq, input_state, timestamp }`         | Batched per tick; drives prediction |
+| `request_interact`           | reliable  | `{ target_id }`                           | Open door, pick up item, use object |
+| `request_attack`             | reliable  | `{ target_id, aim_dir }`                  | Combat action |
+| `request_join`               | reliable  | `{ player_name, profile }`                | Session setup |
+| `request_respawn`            | reliable  | `{}`                                      | After death |
+
+**Design notes:**
+
+- **Input is batched** per client tick and sent with a monotonically increasing
+  `seq` so the server can detect gaps and the client can reconcile.
+- **Interactions are reliable** because they are discrete, must-happen events
+  (opening a door, picking up an item). Losing them would corrupt world state.
+
+### 4.2 Server → Client (State & Events)
+
+| RPC                          | Channel   | Payload                                   | Notes |
+|------------------------------|-----------|-------------------------------------------|-------|
+| `snapshot_state`             | unreliable| `{ tick, entities[], player_states[] }`   | Periodic authoritative state |
+| `spawn_entity`               | reliable  | `{ entity_id, type, transform, props }`   | New entity enters world |
+| `despawn_entity`             | reliable  | `{ entity_id, reason }`                   | Entity removed |
+| `interact_result`            | reliable  | `{ request_seq, success, result }`        | Acknowledges interaction |
+| `damage_event`               | reliable  | `{ target_id, amount, source_id }`        | Combat feedback |
+| `game_event`                 | reliable  | `{ type, payload }`                       | Score, win, round start/end |
+
+### 4.3 Broadcast vs. Targeted
+
+- **Broadcast (all clients):** `snapshot_state`, `spawn_entity`,
+  `despawn_entity`, `game_event`.
+- **Targeted (single client):** `interact_result`, `damage_event` (to affected
+  players), and any player-private data.
+
+---
+
+## 5. Client-Side Prediction & Reconciliation
+
+### 5.1 Prediction
+
+- The client runs a **local copy of the movement simulation** using the same
+  physics constants as the server.
+- When the player provides input, the client:
+  1. Applies the input to its local player immediately.
+  2. Renders the predicted position.
+  3. Sends the input to the server (batched, with `seq`).
+
+### 5.2 Reconciliation
+
+- The server sends authoritative `snapshot_state` at 30 Hz containing the
+  server's tick number and authoritative player positions.
+- The client keeps a **ring buffer of predicted states** keyed by input `seq`.
+- On receiving a snapshot:
+  1. Find the last predicted state that matches the server's tick.
+  2. Compute the **error** between predicted and authoritative position.
+  3. If error exceeds a threshold, **snap or smoothly interpolate** the local
+     player to the authoritative position (error correction).
+  4. Re-simulate any inputs that occurred after the server's tick (rollback).
+
+### 5.3 Interpolation of Remote Entities
+
+- **Local player:** predicted + reconciled (see above).
+- **Remote players / entities:** rendered with **interpolation delay** of
+  `2 × TICK_DURATION` (≈ 66 ms) to smooth out snapshot jitter.
+- The client buffers the last N snapshots and interpolates between them.
+
+### 5.4 Prediction Buffer Sizing
+
+- Buffer size is adaptive based on measured RTT.
+- Default: hold up to `ceil(RTT / TICK_DURATION) + 2` predicted states.
+
+---
+
+## 6. Entity & World State Replication
+
+### 6.1 Entity Model
+
+Every networked entity has:
+
+- A globally unique `entity_id` (server-assigned).
+- An `EntityType` (player, enemy, item, projectile, door, ...).
+- A `Transform` (position, rotation).
+- A typed `props` dictionary of gameplay state (health, state machine, etc.).
+
+### 6.2 Snapshot Format
+
+```
+snapshot_state:
+  tick: uint32
+  entities:
+    - entity_id: uint32
+      type: uint8
+      transform: { x, y, rot }
+      props: { ... }        # delta-encoded where possible
+  player_states:
+    - peer_id: int
+      entity_id: uint32
+      health: int
+      state: uint8
+```
+
+### 6.3 Delta Compression
+
+- Only **changed** entity fields are sent per snapshot (dirty-flag per entity).
+- Static or unchanged entities are omitted from the snapshot.
+- This keeps bandwidth proportional to *activity*, not world size.
+
+---
+
+## 7. Connection & Session Lifecycle
+
+1. **Connect:** Client opens an ENet connection to the server.
+2. **Authenticate / Join:** Client sends `request_join`; server validates and
+   assigns a `peer_id` and spawns the player entity.
+3. **Spawn:** Server broadcasts `spawn_entity` for the new player to all clients.
+4. **Play:** Input → prediction → server simulation → snapshot → reconciliation.
+5. **Disconnect:** Server removes the player entity, broadcasts `despawn_entity`,
+   and cleans up session state.
+
+---
+
+## 8. Security & Anti-Cheat
+
+- **No client-authoritative gameplay values.** Clients only send *inputs* and
+  *requests*; the server computes all outcomes.
+- **Input validation:** Server clamps movement speed, rejects out-of-bounds
+  positions, and validates interaction targets.
+- **Rate limiting:** Per-peer input and RPC rate limits prevent flooding.
+- **Sequence validation:** Gaps or replays in input `seq` are detected and
+  rejected.
+
+---
+
+## 9. Testing & Determinism
+
+- The simulation is a **pure function of (state, inputs, tick)** so it can be
+  unit-tested headlessly.
+- A **replay system** records inputs and can re-simulate to verify server and
+  client produce identical results.
+- Network code is tested with a **mock transport** that can inject latency,
+  jitter, and packet loss.
+
+---
+
+## 10. Open Questions / Future Work
+
+- **Interest management / spatial partitioning:** For large worlds, restrict
+  snapshots to entities near each client (AOI culling).
+- **Server-side physics:** Decide whether to use Godot's physics server on the
+  host or a custom deterministic physics step.
+- **Dedicated server vs. listen server:** The architecture supports both; a
+  dedicated headless server is the target for production.
+- **WebSocket fallback:** Implement the transport abstraction for browser builds.
+
+---
+
+## 11. Summary
+
+| Concern                | Decision                                        |
+|------------------------|-------------------------------------------------|
+| Transport              | ENet (primary), WebSocket (secondary)           |
+| Tick rate              | 30 Hz fixed timestep                            |
+| Authority              | Server-authoritative; client sends input only   |
+| Prediction             | Client-side prediction + reconciliation         |
+| Remote interpolation   | 2-tick interpolation delay                      |
+| Replication            | Delta-compressed snapshots at 30 Hz             |
+| Interaction RPCs       | Reliable channel                                |
+| Movement input         | Unreliable channel, batched with sequence       |

docs/architecture/world.md

@@ -0,0 +1,737 @@
+# World Chunk Data Format & Persistence Architecture
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** Server authority + client prediction, avatar component system, content moderation & age verification, backend auth (JWT)
+
+## 1. Overview
+
+This document specifies the **world chunk data format** and **persistence
+schema** for **agp-game**, a Godot-based multiplayer game built by autonomous
+agents. It defines:
+
+- The **chunk data format** — both a human-readable **JSON** form (for
+  authoring, tooling, and debugging) and a compact **binary** form (for
+  runtime loading and network transfer).
+- The **SQLite schema** that persists world state on the server, including
+  chunk metadata, chunk payloads, and the world/room hierarchy.
+- The **read/write API** that the server and client use to load, save, and
+  stream chunks.
+
+The goal is a **single, versioned chunk contract** that is shared across the
+Godot client, the Python backend, and the persistence layer. A chunk is the
+atomic unit of world geometry, gameplay objects, and persistence — the server
+loads and saves whole chunks, and clients stream the chunks around them.
+
+### 1.1 Design Goals
+
+- **Versioned & forward-compatible:** Every chunk carries a format version so
+  the loader can migrate old data and reject unknown future data gracefully.
+- **Dual representation:** JSON for authoring/debugging, binary for
+  runtime/network. Both encode the *same* logical model so there is exactly one
+  source of truth for the schema.
+- **Server-authoritative persistence:** The server is the only writer to the
+  SQLite store. Clients submit *edits* (deltas) and the server applies and
+  persists them, mirroring the server-authoritative networking model.
+- **Chunk-granular persistence:** Persistence happens at chunk granularity so
+  the server can save a dirty chunk without rewriting the whole world, and can
+  stream only the chunks a client needs.
+- **Deterministic & testable:** The binary format is byte-stable for a given
+  logical payload, enabling checksums, caching, and reproducible tests.
+- **Moderation-aware:** Chunks reference content (assets, scripts) that carry
+  content flags (see `content_moderation.md`); the persistence layer stores the
+  moderation state alongside chunk data so enforcement can happen at load time.
+
+---
+
+## 2. World Model & Chunking
+
+### 2.1 World Hierarchy
+
+The world is organized as a hierarchy that matches the moderation content graph:
+
+```
+World
+ └── Room
+      └── Chunk   (the atomic persistence & streaming unit)
+           ├── Tiles / Terrain
+           ├── Static objects (props, geometry)
+           ├── Dynamic objects (spawnable entities, interactables)
+           └── Metadata (flags, version, timestamps)
+```
+
+- A **World** is the top-level container (a named, versioned space).
+- A **Room** is a bounded region within a world (a level, a building, a zone).
+- A **Chunk** is a fixed-size, axis-aligned region of a room. It is the unit of
+  load, save, and stream.
+
+### 2.2 Chunk Dimensions
+
+Chunks are **fixed-size, axis-aligned boxes** in world space. The default
+dimensions are a configuration constant so they can be tuned per world:
+
+| Constant            | Default | Description                                        |
+|---------------------|---------|----------------------------------------------------|
+| `CHUNK_SIZE_X`      | 32      | Chunk width in world units (tiles).                |
+| `CHUNK_SIZE_Y`      | 32      | Chunk height in world units (tiles).               |
+| `CHUNK_SIZE_Z`      | 1       | Chunk depth (1 = flat 2D world; >1 = volumetric).  |
+| `CHUNK_ORIGIN`      | `(0,0)` | World-space origin of chunk coordinate `(0,0)`.    |
+
+A chunk is identified by its **integer chunk coordinate** `(cx, cy, cz)`,
+computed from a world-space position `p` as:
+
+```
+cx = floor((p.x - CHUNK_ORIGIN.x) / CHUNK_SIZE_X)
+cy = floor((p.y - CHUNK_ORIGIN.y) / CHUNK_SIZE_Y)
+cz = floor((p.z - CHUNK_ORIGIN.z) / CHUNK_SIZE_Z)
+```
+
+The chunk's world-space bounding box is therefore:
+
+```
+min = (CHUNK_ORIGIN.x + cx*CHUNK_SIZE_X, ...)
+max = min + (CHUNK_SIZE_X, CHUNK_SIZE_Y, CHUNK_SIZE_Z)
+```
+
+### 2.3 Chunk Coordinate Key
+
+For storage and lookup, a chunk is addressed by a **canonical string key**:
+
+```
+"{world_id}:{room_id}:{cx}:{cy}:{cz}"
+```
+
+Example: `"w_0001:r_0001:12:-4:0"`. This key is the primary lookup key in the
+SQLite `chunks` table and is used in the read/write API.
+
+---
+
+## 3. Chunk Data Format
+
+### 3.1 Logical Model
+
+Both the JSON and binary encodings serialize the same logical chunk model. The
+logical model is defined here once; the two encodings are projections of it.
+
+```
+Chunk
+ ├── version        : uint   (format version, currently 1)
+ ├── key            : string (canonical chunk key, see §2.3)
+ ├── world_id       : string
+ ├── room_id        : string
+ ├── coord          : { cx, cy, cz }   (int)
+ ├── bounds         : { min_x, min_y, min_z, max_x, max_y, max_z } (float)
+ ├── tiles          : TileLayer[]       (terrain / tile data)
+ ├── objects        : WorldObject[]     (static + dynamic objects)
+ ├── flags          : ContentFlags      (moderation flags, see §3.5)
+ ├── meta           : { created_at, updated_at, revision, author } 
+ └── checksum       : string            (SHA-256 of canonical payload)
+```
+
+### 3.2 Tile Layer
+
+A chunk's terrain is stored as one or more **tile layers**. Each layer is a
+dense grid of tile IDs of size `CHUNK_SIZE_X × CHUNK_SIZE_Y` (× `CHUNK_SIZE_Z`
+for volumetric worlds).
+
+```
+TileLayer
+ ├── name      : string   (e.g. "ground", "walls", "decor")
+ ├── layer_id  : uint
+ ├── width     : uint     (= CHUNK_SIZE_X)
+ ├── height    : uint     (= CHUNK_SIZE_Y)
+ ├── depth     : uint     (= CHUNK_SIZE_Z)
+ ├── tiles     : uint[]   (flattened tile IDs, row-major, length = w*h*d)
+ └── palette   : TileDef[] (tile ID → tile definition, shared per layer)
+```
+
+**Tile encoding:** A tile ID is a `uint16` index into the layer's `palette`.
+`0` is reserved for "empty/air". The palette maps each tile ID to a `TileDef`:
+
+```
+TileDef
+ ├── id       : uint16
+ ├── asset_id : string   (reference to a tile/terrain asset)
+ ├── solid    : bool     (collision)
+ ├── flags    : uint32   (bitmask: walkable, climbable, liquid, ...)
+ └── variants : uint8    (number of visual variants for this tile)
+```
+
+**Rationale for palette + indices:** Storing dense `uint16` indices rather than
+full asset strings per cell keeps the binary payload small (2 bytes/cell) while
+the palette (shared across the layer) carries the rich per-tile metadata.
+
+### 3.3 World Objects
+
+Objects are the non-tile entities in a chunk: static props, interactables,
+spawn points, and dynamic-object templates.
+
+```
+WorldObject
+ ├── id          : string   (stable object id, unique within the chunk)
+ ├── type        : string   (e.g. "prop", "interactable", "spawn_point", "door")
+ ├── asset_id    : string   (reference to the object's mesh/glTF asset)
+ ├── transform   : { pos: [x,y,z], rot: [x,y,z,w], scale: [x,y,z] }
+ ├── properties  : object   (type-specific key/value map, JSON-typed)
+ ├── dynamic     : bool     (true if this is a spawnable dynamic entity)
+ └── flags       : ContentFlags (per-object moderation flags)
+```
+
+**Dynamic objects** are stored as *templates* in the chunk. Their *runtime
+state* (position, health, inventory) is **not** stored in the chunk; it lives
+in the runtime entity store and is persisted separately (see §4.4). This keeps
+chunks stable and diffable — a chunk only changes when its *static* content
+changes.
+
+### 3.4 Content Flags
+
+Each chunk (and each object) carries a **content flag set** that is the
+aggregate of the moderation flags of the assets and scripts it references. This
+mirrors the aggregation rules in `content_moderation.md`:
+
+```
+ContentFlags
+ ├── categories : { violence, sexual, language, substance, gambling, horror, hate, custom }
+ │                (each → severity: none|mild|moderate|severe)
+ ├── mature     : bool   (true if any contributing item is mature)
+ └── sources    : string[] (flag ids that contributed, for audit)
+```
+
+The server computes and persists these flags at write time so that enforcement
+(age gating, content filtering) can happen at load time without re-scanning
+assets.
+
+### 3.5 JSON Encoding
+
+The JSON encoding is the **authoring and debugging** representation. It is
+human-readable, diffable, and used by tools and tests. It is the canonical
+logical model serialized directly.
+
+```json
+{
+  "version": 1,
+  "key": "w_0001:r_0001:12:-4:0",
+  "world_id": "w_0001",
+  "room_id": "r_0001",
+  "coord": { "cx": 12, "cy": -4, "cz": 0 },
+  "bounds": { "min_x": 384.0, "min_y": -128.0, "min_z": 0.0,
+              "max_x": 416.0, "max_y": -96.0,  "max_z": 1.0 },
+  "tiles": [
+    {
+      "name": "ground",
+      "layer_id": 0,
+      "width": 32,
+      "height": 32,
+      "depth": 1,
+      "palette": [
+        { "id": 0, "asset_id": "", "solid": false, "flags": 0, "variants": 1 },
+        { "id": 1, "asset_id": "tiles/grass", "solid": false, "flags": 1, "variants": 4 }
+      ],
+      "tiles": [0, 1, 1, 1, 0, 1, 1, 0, 0, 1, 1, 1, 1, 0, 1, 1]
+    }
+  ],
+  "objects": [
+    {
+      "id": "obj_0001",
+      "type": "interactable",
+      "asset_id": "props/chest",
+      "transform": { "pos": [400.0, -110.0, 0.0],
+                     "rot": [0.0, 0.0, 0.0, 1.0],
+                     "scale": [1.0, 1.0, 1.0] },
+      "properties": { "loot_table": "chest_basic", "locked": false },
+      "dynamic": false,
+      "flags": { "categories": { "violence": "none" }, "mature": false, "sources": [] }
+    }
+  ],
+  "flags": { "categories": { "violence": "none" }, "mature": false, "sources": [] },
+  "meta": { "created_at": "2026-08-17T00:00:00Z",
+            "updated_at": "2026-08-17T00:00:00Z",
+            "revision": 3,
+            "author": "agent-bot" },
+  "checksum": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08"
+}
+```
+
+> **Note on the example checksum:** The value shown above is illustrative only.
+> In practice the `checksum` field is the SHA-256 of the canonical binary
+> payload body (see §3.6.3), not of the JSON text. The value here is a
+> placeholder for documentation purposes.
+
+### 3.6 Binary Encoding
+
+The binary encoding is the **runtime and network** representation. It is compact
+and byte-stable. It uses a simple, explicitly-specified layout (no external
+serialization library) so it can be produced and consumed identically by the
+Godot client (GDScript) and the Python backend.
+
+#### 3.6.1 Header
+
+| Offset | Size | Field        | Type / Encoding                          |
+|--------|------|--------------|------------------------------------------|
+| 0      | 4    | magic        | ASCII `"AGPC"` (0x41 0x47 0x50 0x43)     |
+| 4      | 2    | version      | `uint16` LE (currently `1`)              |
+| 6      | 2    | header_len   | `uint16` LE (bytes of header after this) |
+| 8      | 4    | flags        | `uint32` LE (bitmask, reserved)          |
+| 12     | 4    | payload_len  | `uint32` LE (bytes of payload body)      |
+| 16     | 32   | checksum     | SHA-256 of payload body (hex, 32 bytes)  |
+
+Total header size: **48 bytes**.
+
+#### 3.6.2 Payload Body
+
+The payload body is a sequence of typed sections. Each section has a small
+header:
+
+| Offset | Size | Field      | Type / Encoding            |
+|--------|------|------------|----------------------------|
+| 0      | 1    | section_id | `uint8` (see table below)  |
+| 1      | 4    | section_len| `uint32` LE (bytes of section data) |
+| 5      | ...  | data       | section-specific           |
+
+Section IDs:
+
+| section_id | Section        | Data layout                                                       |
+|------------|----------------|-------------------------------------------------------------------|
+| `0x01`     | metadata       | world_id, room_id (length-prefixed strings), coord (3×int32), bounds (6×float32) |
+| `0x02`     | tile layer     | name, layer_id, dims (3×uint16), palette, dense tile indices      |
+| `0x03`     | object         | one `WorldObject` (repeated; one section per object)              |
+| `0x04`     | content flags  | category severities (8×uint8), mature (uint8), sources (string list) |
+| `0x05`     | meta           | created_at, updated_at (int64 unix), revision (uint32), author (string) |
+
+**String encoding:** length-prefixed UTF-8 — `uint16` LE byte length followed by
+the UTF-8 bytes.
+
+**Tile layer data layout (section `0x02`):**
+
+```
+name        : string
+layer_id    : uint16 LE
+width       : uint16 LE
+height      : uint16 LE
+depth       : uint16 LE
+palette_count : uint16 LE
+palette     : palette_count × TileDef
+tile_count  : uint32 LE
+tiles       : tile_count × uint16 LE   (dense, row-major)
+```
+
+```
+TileDef:
+  id        : uint16 LE
+  asset_id  : string
+  solid     : uint8
+  flags     : uint32 LE
+  variants  : uint8
+```
+
+**Object data layout (section `0x03`):**
+
+```
+id          : string
+type        : string
+asset_id    : string
+pos         : 3 × float32
+rot         : 4 × float32
+scale       : 3 × float32
+dynamic     : uint8
+properties  : JSON string (length-prefixed)
+flags       : ContentFlags (see 0x04 layout)
+```
+
+**Content flags layout (section `0x04`):**
+
+```
+violence, sexual, language, substance, gambling, horror, hate, custom
+            : 8 × uint8   (severity enum: 0=none,1=mild,2=moderate,3=severe)
+mature      : uint8
+source_count: uint16 LE
+sources     : source_count × string
+```
+
+#### 3.6.3 Byte-Stability
+
+For a given logical payload, the binary encoding is **deterministic**:
+
+- All integers are little-endian.
+- All strings are UTF-8, length-prefixed, and never null-terminated.
+- Maps (e.g. `properties`) are serialized as a **canonical JSON string** with
+  keys sorted lexicographically.
+- The `checksum` is the SHA-256 of the payload body bytes.
+
+This guarantees that two encoders produce identical bytes, enabling content
+addressing, caching, and reproducible tests.
+
+---
+
+## 4. SQLite Persistence Schema
+
+The server persists world state in a **SQLite** database. SQLite is chosen for
+its zero-configuration, single-file, transactional, and embedded nature — ideal
+for a server that owns the world store and needs ACID guarantees without a
+separate database process.
+
+### 4.1 Database Layout
+
+The database file is `world.db` (path configurable). It contains the following
+tables:
+
+```
+worlds
+rooms
+chunks
+chunk_objects
+content_flags
+revisions
+```
+
+### 4.2 `worlds`
+
+Top-level world containers.
+
+```sql
+CREATE TABLE worlds (
+    id          TEXT PRIMARY KEY,          -- e.g. 'w_0001'
+    name        TEXT NOT NULL,
+    description TEXT,
+    chunk_size_x INTEGER NOT NULL DEFAULT 32,
+    chunk_size_y INTEGER NOT NULL DEFAULT 32,
+    chunk_size_z INTEGER NOT NULL DEFAULT 1,
+    origin_x    REAL NOT NULL DEFAULT 0,
+    origin_y    REAL NOT NULL DEFAULT 0,
+    origin_z    REAL NOT NULL DEFAULT 0,
+    created_at  TEXT NOT NULL,             -- ISO-8601 UTC
+    updated_at  TEXT NOT NULL
+);
+```
+
+### 4.3 `rooms`
+
+Rooms within a world.
+
+```sql
+CREATE TABLE rooms (
+    id          TEXT PRIMARY KEY,          -- e.g. 'r_0001'
+    world_id    TEXT NOT NULL REFERENCES worlds(id) ON DELETE CASCADE,
+    name        TEXT NOT NULL,
+    bounds_min_x REAL NOT NULL,
+    bounds_min_y REAL NOT NULL,
+    bounds_min_z REAL NOT NULL DEFAULT 0,
+    bounds_max_x REAL NOT NULL,
+    bounds_max_y REAL NOT NULL,
+    bounds_max_z REAL NOT NULL DEFAULT 1,
+    created_at  TEXT NOT NULL,
+    updated_at  TEXT NOT NULL,
+    UNIQUE (world_id, name)
+);
+CREATE INDEX idx_rooms_world ON rooms(world_id);
+```
+
+### 4.4 `chunks`
+
+The core persistence table. One row per chunk. The **payload** is stored as a
+BLOB in the **binary format** (§3.6); the JSON form is derived on demand for
+authoring/debugging and is not stored (to avoid dual-write drift).
+
+```sql
+CREATE TABLE chunks (
+    key         TEXT PRIMARY KEY,          -- canonical key 'world:room:cx:cy:cz'
+    world_id    TEXT NOT NULL REFERENCES worlds(id) ON DELETE CASCADE,
+    room_id     TEXT NOT NULL REFERENCES rooms(id) ON DELETE CASCADE,
+    cx          INTEGER NOT NULL,
+    cy          INTEGER NOT NULL,
+    cz          INTEGER NOT NULL DEFAULT 0,
+    format_version INTEGER NOT NULL DEFAULT 1,
+    payload     BLOB NOT NULL,             -- binary chunk encoding (§3.6)
+    payload_len INTEGER NOT NULL,
+    checksum    TEXT NOT NULL,             -- SHA-256 of payload
+    revision    INTEGER NOT NULL DEFAULT 0,
+    dirty       INTEGER NOT NULL DEFAULT 0, -- 1 = needs flush to disk
+    created_at  TEXT NOT NULL,
+    updated_at  TEXT NOT NULL,
+    UNIQUE (world_id, room_id, cx, cy, cz)
+);
+CREATE INDEX idx_chunks_world_room ON chunks(world_id, room_id);
+CREATE INDEX idx_chunks_coord ON chunks(cx, cy, cz);
+```
+
+**Design notes:**
+
+- The `payload` BLOB is the single source of truth for chunk content. The
+  `checksum` guards against corruption and enables content addressing.
+- `revision` increments on every write; it is used for optimistic concurrency
+  and change detection (see §5.4).
+- `dirty` marks chunks that have been modified in memory but not yet flushed,
+  enabling a write-behind persistence strategy (see §5.5).
+
+### 4.5 `chunk_objects`
+
+A denormalized, queryable index of the objects inside each chunk. This is
+**derived** from the chunk payload and kept in sync by the write path. It exists
+so the server can answer queries like "which chunks contain a door?" without
+parsing every payload BLOB.
+
+```sql
+CREATE TABLE chunk_objects (
+    id          TEXT NOT NULL,             -- object id (unique within chunk)
+    chunk_key   TEXT NOT NULL REFERENCES chunks(key) ON DELETE CASCADE,
+    type        TEXT NOT NULL,             -- 'prop', 'interactable', ...
+    asset_id    TEXT,
+    dynamic     INTEGER NOT NULL DEFAULT 0,
+    pos_x       REAL NOT NULL,
+    pos_y       REAL NOT NULL,
+    pos_z       REAL NOT NULL DEFAULT 0,
+    PRIMARY KEY (chunk_key, id)
+);
+CREATE INDEX idx_chunk_objects_type ON chunk_objects(type);
+CREATE INDEX idx_chunk_objects_asset ON chunk_objects(asset_id);
+```
+
+**Sync mechanism:** `chunk_objects` is maintained **explicitly by the write
+path** — it is not a SQL trigger. Whenever `put_chunk` (or `delete_chunk`)
+commits a chunk, the service layer performs a **delete-and-reinsert** of that
+chunk's object rows in the same transaction: it deletes all rows for
+`chunk_key`, then inserts fresh rows parsed from the new payload. This keeps the
+index transactionally consistent with the payload and avoids the complexity and
+fragility of SQL triggers over a binary BLOB. Because the index is derived, it
+can always be rebuilt from `chunks.payload` if it ever drifts (a `rebuild_index`
+utility is provided for this).
+
+### 4.6 `content_flags`
+
+Persists the aggregated moderation flags per chunk (and optionally per object).
+This lets the server enforce age/content gates at load time without parsing
+payloads.
+
+```sql
+CREATE TABLE content_flags (
+    chunk_key   TEXT NOT NULL REFERENCES chunks(key) ON DELETE CASCADE,
+    object_id   TEXT NOT NULL DEFAULT '',  -- '' = chunk-level flag (sentinel)
+    violence    INTEGER NOT NULL DEFAULT 0,
+    sexual      INTEGER NOT NULL DEFAULT 0,
+    language    INTEGER NOT NULL DEFAULT 0,
+    substance   INTEGER NOT NULL DEFAULT 0,
+    gambling    INTEGER NOT NULL DEFAULT 0,
+    horror      INTEGER NOT NULL DEFAULT 0,
+    hate        INTEGER NOT NULL DEFAULT 0,
+    custom      INTEGER NOT NULL DEFAULT 0,
+    mature      INTEGER NOT NULL DEFAULT 0,
+    sources     TEXT NOT NULL DEFAULT '[]', -- JSON array of flag ids
+    PRIMARY KEY (chunk_key, object_id)
+);
+CREATE INDEX idx_content_flags_mature ON content_flags(mature);
+```
+
+Severity is stored as `0=none, 1=mild, 2=moderate, 3=severe`.
+
+**Chunk-level vs. object-level flags:** Chunk-level flags use the **sentinel
+value `''` (empty string)** in `object_id` rather than `NULL`. This is
+deliberate: in SQLite, `NULL` values in a composite primary key are **not**
+unique-constrained, so two rows with the same `chunk_key` and `object_id = NULL`
+could be inserted accidentally. Using `''` as the sentinel means the composite
+`PRIMARY KEY (chunk_key, object_id)` enforces that there is **exactly one**
+chunk-level flag row per chunk. Object-level flags use the object's actual `id`
+(which is never empty). The application layer treats `object_id = ''` as
+"chunk-level" and any non-empty value as "object-level".
+
+### 4.7 `revisions`
+
+An append-only audit log of chunk writes. Enables rollback, auditing, and
+replication of changes.
+
+```sql
+CREATE TABLE revisions (
+    id          INTEGER PRIMARY KEY AUTOINCREMENT,
+    chunk_key   TEXT NOT NULL,             -- NOT a FK: survives chunk deletion
+    revision    INTEGER NOT NULL,
+    actor       TEXT NOT NULL,             -- user / agent id
+    action      TEXT NOT NULL,             -- 'create' | 'update' | 'delete'
+    checksum    TEXT NOT NULL,             -- SHA-256 of payload
+    payload     BLOB,                      -- full binary payload at this revision
+    created_at  TEXT NOT NULL
+);
+CREATE INDEX idx_revisions_chunk ON revisions(chunk_key);
+```
+
+**Rollback support:** The `payload` BLOB stores the **full binary chunk payload**
+at each revision. This is what makes rollback possible: to restore a chunk to a
+previous revision, the server reads the `payload` of the target revision and
+writes it back to `chunks.payload` (incrementing `revision` and appending a new
+`revisions` row). Without the payload, only the checksum would be available,
+which is insufficient to reconstruct the chunk.
+
+**Audit trail preservation:** `chunk_key` is **not** a foreign key to `chunks`.
+This means deleting a chunk does **not** cascade-delete its revision history —
+the audit trail is preserved even after a chunk is removed. (The `chunk_key`
+string is still stored so the history can be correlated to a chunk that existed
+at that time.) If a chunk is later recreated with the same key, its history is
+still intact.
+
+### 4.8 Schema Versioning & Migrations
+
+The database carries a schema version in a `meta` table:
+
+```sql
+CREATE TABLE meta (
+    key   TEXT PRIMARY KEY,
+    value TEXT NOT NULL
+);
+-- seed: INSERT INTO meta(key, value) VALUES ('schema_version', '1');
+```
+
+Migrations are applied in order at startup. Each migration is a numbered SQL
+script; the server tracks the applied version in `meta` and applies any pending
+migrations transactionally. This keeps the schema forward-compatible as the
+chunk format evolves.
+
+---
+
+## 5. Read/Write API
+
+The API is exposed as a **Python service layer** on the backend (the same
+process that owns the SQLite store) and consumed by the Godot client over the
+network transport (see `networking.md`). The service layer is the **only**
+writer to the database; clients never touch SQLite directly.
+
+### 5.1 Service Interface (Python)
+
+```python
+class WorldStore:
+    """Owns the SQLite connection and chunk read/write operations."""
+
+    def get_chunk(self, key: str) -> Chunk | None: ...
+    def get_chunk_binary(self, key: str) -> bytes | None: ...
+    def put_chunk(self, chunk: Chunk, actor: str) -> Chunk: ...
+    def delete_chunk(self, key: str, actor: str) -> None: ...
+    def list_chunks(self, world_id: str, room_id: str | None = None,
+                    bounds: Bounds | None = None) -> list[str]: ...
+    def get_chunk_flags(self, key: str) -> ContentFlags: ...
+    def flush_dirty(self) -> int: ...
+    def rollback_chunk(self, key: str, revision: int, actor: str) -> Chunk: ...
+    def rebuild_index(self, chunk_key: str | None = None) -> int: ...
+    def migrate(self) -> None: ...
+```
+
+### 5.2 Encoding Helpers
+
+The service layer provides symmetric encode/decode functions shared by the
+client and server:
+
+```python
+def encode_binary(chunk: Chunk) -> bytes: ...
+def decode_binary(data: bytes) -> Chunk: ...
+def encode_json(chunk: Chunk) -> str: ...
+def decode_json(text: str) -> Chunk: ...
+def checksum(payload: bytes) -> str: ...
+```
+
+These are the single implementation of the format spec (§3), so the Godot
+client and Python backend never drift.
+
+### 5.3 Network RPCs
+
+The chunk API is exposed to the client via RPCs (matching the networking
+architecture). All chunk traffic is **reliable** (chunks are discrete,
+must-arrive data).
+
+| RPC                        | Direction | Payload                                   | Notes |
+|----------------------------|-----------|-------------------------------------------|-------|
+| `request_chunk`            | C → S     | `{ key }`                                 | Client asks for a chunk |
+| `chunk_data`               | S → C     | `{ key, binary_payload, checksum }`       | Server streams a chunk |
+| `request_chunk_edit`       | C → S     | `{ key, base_revision, delta }`           | Client submits an edit |
+| `chunk_edit_result`        | S → C     | `{ key, success, new_revision, error? }`  | Acknowledges an edit |
+| `chunk_invalidated`        | S → C     | `{ key, new_revision }`                   | Server pushes a change |
+| `request_chunk_flags`      | C → S     | `{ key }`                                 | Age/content gate check |
+
+### 5.4 Edit & Concurrency Model
+
+- **Read:** Client requests a chunk; server returns the binary payload and its
+  `revision`.
+- **Edit:** Client submits a **delta** against a known `base_revision`. The
+  server applies the delta, increments `revision`, persists, and returns the new
+  revision.
+- **Optimistic concurrency:** If the chunk's current revision differs from the
+  client's `base_revision`, the server rejects the edit with a conflict error
+  and the client re-fetches and re-applies. This prevents lost updates when two
+  clients edit the same chunk.
+- **Deltas:** A delta is a JSON patch (RFC 6902 style) applied to the chunk's
+  logical model. The server validates the patched chunk (schema, bounds,
+  moderation) before persisting.
+
+### 5.5 Write-Behind Persistence
+
+To amortize disk I/O, the server keeps a **dirty set** of chunks modified in
+memory and flushes them to SQLite in batches:
+
+1. `put_chunk` updates the in-memory chunk and marks it `dirty`.
+2. A background flusher periodically calls `flush_dirty()`, which writes all
+   dirty chunks in a single transaction and clears the `dirty` flag.
+3. On graceful shutdown, `flush_dirty()` is called to ensure durability.
+
+This keeps the hot path (in-memory chunk access) fast while guaranteeing
+durability at shutdown and on a configurable interval.
+
+**Recovery after unclean shutdown:** The `dirty` column in the `chunks` table
+exists specifically to support recovery if the process crashes before a flush
+completes. On startup, the server scans for rows where `dirty = 1` and treats
+them as **unflushed in-memory state that was lost** — it re-reads the last
+persisted payload from `chunks.payload` (the last durable state) and clears the
+`dirty` flag. In other words, `dirty = 1` at startup means "the last write was
+not durable; discard the in-memory delta and fall back to the persisted
+payload." This guarantees that the on-disk state is always a consistent,
+previously-committed snapshot, never a partially-written chunk. (The in-memory
+dirty set is authoritative during normal operation; the `dirty` column is only a
+recovery marker.)
+
+### 5.6 Streaming & Caching
+
+- The server streams only the chunks a client needs (those within the client's
+  view radius), using `list_chunks` with a bounds query.
+- Chunks are cached in memory (LRU) keyed by `key`; the cache is invalidated on
+  write.
+- The binary payload is content-addressed by `checksum`, so unchanged chunks can
+  be served from cache without re-reading SQLite.
+
+---
+
+## 6. Format Versioning & Migration
+
+- The chunk format `version` field (currently `1`) is checked on decode. A
+  decoder that encounters a higher version than it supports **rejects** the
+  chunk with a clear error rather than misreading it.
+- The SQLite `schema_version` in `meta` drives database migrations (§4.8).
+- Chunk payloads are migrated **lazily**: when a chunk is read and its
+  `format_version` is older than the current one, the server migrates it to the
+  current version in memory and marks it dirty so it is rewritten on the next
+  flush. This avoids a costly full-world migration at startup.
+
+---
+
+## 7. Security & Integrity
+
+- **Server-authoritative writes:** Only the `WorldStore` writes to SQLite;
+  clients submit deltas that are validated before application.
+- **Checksum verification:** Every chunk payload is checksummed (SHA-256) on
+  write and verified on read. Corruption is detected and the chunk is re-fetched
+  or flagged.
+- **Bounds validation:** Chunk coordinates and object positions are validated
+  against the world's chunk dimensions and room bounds before persistence.
+- **Moderation enforcement:** `content_flags` are checked at load time; mature
+  chunks are gated behind the age-verification flow (see `content_moderation.md`).
+- **Input validation:** All string fields are length-limited and validated
+  against allowed character sets to prevent injection and oversized payloads.
+
+---
+
+## 8. Open Questions / Future Work
+
+- **Volumetric worlds:** The schema and format already support `CHUNK_SIZE_Z >
+  1`, but the tooling and streaming for 3D chunks are not yet specified.
+- **Chunk compression:** For very large worlds, the binary payload could be
+  compressed (e.g. zstd) before storage/transfer. The header reserves a `flags`
+  bitmask for a compression flag.
+- **Multi-server sharding:** If a single SQLite file becomes a bottleneck, the
+  `chunks` table could be sharded by `world_id` across multiple databases. The
+  key design already supports this (world_id is a leading key component).
+- **Delta compression for streaming:** Instead of sending full chunks, the
+  server could send only the delta between revisions to reduce bandwidth for
+  frequently-updated chunks.

project.godot

@@ -0,0 +1,24 @@
+; Engine configuration file.
+; It's best edited using the editor UI and not directly,
+; but it can also be edited by hand.
+
+config_version=5
+
+[application]
+
+config/name="AGP-Game"
+run/main_scene="res://scenes/main_menu.tscn"
+config/features=PackedStringArray("4.6.2")
+
+[autoload]
+
+[display]
+
+window/size/viewport_width=1920
+window/size/viewport_height=1080
+window/stretch/mode="canvas_items"
+
+[rendering]
+
+renderer/rendering_method="gl_compatibility"
+renderer/rendering_method.mobile="gl_compatibility"

scenes/main_menu.tscn

@@ -0,0 +1,43 @@
+[gd_scene load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://scripts/main_menu.gd" id="1_main"]
+
+[node name="MainMenu" type="Control"]
+anchors_preset = 15
+anchor_right = 1.0
+anchor_bottom = 1.0
+grow_horizontal = 2
+grow_vertical = 2
+script = ExtResource("1_main")
+
+[node name="CenterContainer" type="CenterContainer" parent="."]
+layout_mode = 3
+anchors_preset = 15
+anchor_right = 1.0
+anchor_bottom = 1.0
+grow_horizontal = 2
+grow_vertical = 2
+
+[node name="VBoxContainer" type="VBoxContainer" parent="CenterContainer"]
+layout_mode = 1
+theme_override_constants/separation = 16
+size_flags_horizontal = 4
+
+[node name="TitleLabel" type="Label" parent="CenterContainer/VBoxContainer"]
+layout_mode = 1
+text = "AGP Game"
+horizontal_alignment = 1
+theme_override_font_sizes/font_size = 72
+
+[node name="PlayButton" type="Button" parent="CenterContainer/VBoxContainer"]
+layout_mode = 1
+text = "Play"
+size_flags_horizontal = 4
+
+[node name="QuitButton" type="Button" parent="CenterContainer/VBoxContainer"]
+layout_mode = 1
+text = "Quit"
+size_flags_horizontal = 4
+
+[connection signal="pressed" from="CenterContainer/VBoxContainer/PlayButton" to="." method="_on_play_button_pressed"]
+[connection signal="pressed" from="CenterContainer/VBoxContainer/QuitButton" to="." method="_on_quit_button_pressed"]

scripts/main_menu.gd

@@ -0,0 +1,14 @@
+extends Control
+
+
+func _ready():
+	pass
+
+
+func _on_play_button_pressed():
+	# No gameplay scene exists yet — wire this to the real scene once one lands.
+	print("Play pressed — no gameplay scene yet")
+
+
+func _on_quit_button_pressed():
+	get_tree().quit()