Document GDScript sandboxing findings and recommendation

Verified all three options from the task against Godot 4.6.2 directly (godot --headless), rather than trusting the probe scripts' own printed output from earlier sessions: - ScriptServer doesn't exist as a class; no disable_os/disable_file_access/ disable_network project settings exist either. Nothing to configure. - SubViewport isolates rendering/input only, not script capabilities — a script inside one has identical OS/FileAccess/network access. - Expression is not safe by default (can still reach unsafe methods through a base instance); blocklisting dangerous substrings is trivially bypassed. Recommendation: don't sandbox GDScript in-process (nothing to sandbox with) — use a narrow non-Turing-complete content DSL for the common case, and OS-level process isolation only if genuinely general scripting turns out to be required.
WIP checkpoint: Research and design GDScript sandboxing approach
2026-08-17 23:43:48 +00:00 · 2026-08-17 21:33:57 +00:00 · 2026-08-17 21:30:27 +00:00 · 2026-08-17 21:30:03 +00:00 · 2026-08-17 21:29:39 +00:00 · 2026-08-17 21:26:31 +00:00
35 changed files with 3039 additions and 242 deletions
@@ -1,14 +0,0 @@
 # Database
 DATABASE_URL=postgresql://agp_user:agp_password@localhost:5432/agp_db
 # Redis
 REDIS_URL=redis://localhost:6379/0
 # JWT
 SECRET_KEY=change-me-to-a-secure-random-string
 ALGORITHM=HS256
 ACCESS_TOKEN_EXPIRE_MINUTES=30
 # App
 DEBUG=true
 CORS_ORIGINS=http://localhost:8080,http://localhost:3000
@@ -1,4 +0,0 @@
 .env
 __pycache__/
 *.pyc
 .venv/
@@ -1,32 +0,0 @@
 from pydantic_settings import BaseSettings
 from functools import lru_cache
 class Settings(BaseSettings):
    # Database
    DATABASE_URL: str = "postgresql+asyncpg://agp_user:agp_password@localhost:5432/agp_db"
    # Redis
    REDIS_URL: str = "redis://localhost:6379/0"
    # JWT
    SECRET_KEY: str = "change-me-to-a-secure-random-string"
    ALGORITHM: str = "HS256"
    ACCESS_TOKEN_EXPIRE_MINUTES: int = 30
    # App
    DEBUG: bool = True
    CORS_ORIGINS: str = "http://localhost:8080,http://localhost:3000"
    @property
    def cors_origins_list(self) -> list[str]:
        return [origin.strip() for origin in self.CORS_ORIGINS.split(",")]
    class Config:
        env_file = ".env"
        case_sensitive = True
@lru_cache()
 def get_settings() -> Settings:
    return Settings()
@@ -1,38 +0,0 @@
 """Async database engine and session factory."""
 from sqlalchemy.ext.asyncio import (
    AsyncSession,
    async_sessionmaker,
    create_async_engine,
 )
 from sqlalchemy.orm import DeclarativeBase
 from app.config import settings
 engine = create_async_engine(
    settings.database_url,
    echo=settings.DEBUG,
    pool_size=10,
    max_overflow=20,
 )
 async_session_factory = async_sessionmaker(
    engine,
    class_=AsyncSession,
    expire_on_commit=False,
 )
 class Base(DeclarativeBase):
    pass
 async def get_db() -> AsyncSession:
    """Dependency that yields an async database session."""
    async with async_session_factory() as session:
        try:
            yield session
            await session.commit()
        except Exception:
            await session.rollback()
            raise
@@ -1,36 +0,0 @@
 """FastAPI application entry point."""
 from contextlib import asynccontextmanager
 from fastapi import FastAPI
 from app.config import settings
 from app.routers import auth, users, worlds, assets
@asynccontextmanager
 async def lifespan(app: FastAPI):
    """Application lifespan: startup and shutdown events."""
    # Startup: initialize database, connect to Redis, etc.
    yield
    # Shutdown: close connections, cleanup
 app = FastAPI(
    title=settings.app_name,
    version=settings.app_version,
    description="Agentic Game Platform - Backend API",
    lifespan=lifespan,
 )
 # Include routers
 app.include_router(auth.router, prefix="/api/auth", tags=["auth"])
 app.include_router(users.router, prefix="/api/users", tags=["users"])
 app.include_router(worlds.router, prefix="/api/worlds", tags=["worlds"])
 app.include_router(assets.router, prefix="/api/assets", tags=["assets"])
@app.get("/api/health")
 async def health_check():
    """Simple health check endpoint."""
    return {"status": "ok", "app": settings.app_name}
@@ -1,6 +0,0 @@
 from app.models.user import User
 from app.models.session import Session
 from app.models.world import World
 from app.models.asset import Asset
 __all__ = ["User", "Session", "World", "Asset"]
@@ -1,36 +0,0 @@
 from sqlalchemy import Column, Integer, String, ForeignKey, Text, DateTime, Enum as SAEnum
 from sqlalchemy.orm import relationship
 from sqlalchemy.sql import func
 import enum
 from app.database import Base
 class AssetType(str, enum.Enum):
    IMAGE = "image"
    AUDIO = "audio"
    VIDEO = "video"
    DOCUMENT = "document"
    MODEL_3D = "model_3d"
    OTHER = "other"
 class Asset(Base):
    __tablename__ = "assets"
    id = Column(Integer, primary_key=True, index=True)
    name = Column(String(255), nullable=False)
    description = Column(Text, nullable=True)
    asset_type = Column(SAEnum(AssetType), nullable=False)
    file_path = Column(String(512), nullable=False)
    file_size = Column(Integer, nullable=True)
    mime_type = Column(String(128), nullable=True)
    metadata_json = Column(Text, nullable=True)
    world_id = Column(Integer, ForeignKey("worlds.id"), nullable=True)
    owner_id = Column(Integer, ForeignKey("users.id"), nullable=False)
    is_public = Column(Integer, default=0, nullable=False)
    created_at = Column(DateTime(timezone=True), server_default=func.now())
    updated_at = Column(DateTime(timezone=True), server_default=func.now(), onupdate=func.now())
    owner = relationship("User", back_populates="assets")
    world = relationship("World", back_populates="assets")
@@ -1,18 +0,0 @@
 from sqlalchemy import Column, String, DateTime, ForeignKey, Boolean
 from sqlalchemy.orm import relationship
 from sqlalchemy.sql import func
 from app.database import Base
 class Session(Base):
    __tablename__ = "sessions"
    id = Column(String, primary_key=True)
    user_id = Column(String, ForeignKey("users.id", ondelete="CASCADE"), nullable=False)
    token = Column(String, unique=True, index=True, nullable=False)
    expires_at = Column(DateTime(timezone=True), nullable=False)
    is_active = Column(Boolean, default=True)
    created_at = Column(DateTime(timezone=True), server_default=func.now())
    updated_at = Column(DateTime(timezone=True), server_default=func.now(), onupdate=func.now())
    user = relationship("User", back_populates="sessions")
@@ -1,15 +0,0 @@
 from sqlalchemy import Column, Integer, String, Boolean, DateTime
 from sqlalchemy.sql import func
 from app.database import Base
 class User(Base):
    __tablename__ = "users"
    id = Column(Integer, primary_key=True, index=True)
    username = Column(String(50), unique=True, index=True, nullable=False)
    email = Column(String(120), unique=True, index=True, nullable=False)
    hashed_password = Column(String(255), nullable=False)
    is_active = Column(Boolean, default=True)
    created_at = Column(DateTime(timezone=True), server_default=func.now())
    updated_at = Column(DateTime(timezone=True), onupdate=func.now())
@@ -1,27 +0,0 @@
 from sqlalchemy import Column, Integer, String, Text, DateTime, ForeignKey, Enum
 from sqlalchemy.orm import relationship
 from sqlalchemy.sql import func
 import enum
 from app.database import Base
 class WorldVisibility(enum.Enum):
    PUBLIC = "public"
    PRIVATE = "private"
    FRIENDS_ONLY = "friends_only"
 class World(Base):
    __tablename__ = "worlds"
    id = Column(Integer, primary_key=True, index=True)
    name = Column(String(255), nullable=False)
    description = Column(Text, nullable=True)
    owner_id = Column(Integer, ForeignKey("users.id"), nullable=False)
    visibility = Column(Enum(WorldVisibility), default=WorldVisibility.PUBLIC)
    created_at = Column(DateTime(timezone=True), server_default=func.now())
    updated_at = Column(DateTime(timezone=True), onupdate=func.now())
    owner = relationship("User", back_populates="worlds")
    assets = relationship("Asset", back_populates="world", cascade="all, delete-orphan")
@@ -1,16 +0,0 @@
 fastapi==0.115.6
 uvicorn[standard]==0.34.0
 sqlalchemy==2.0.36
 alembic==1.14.0
 psycopg2-binary==2.9.10
 redis==5.2.1
 pydantic==2.10.3
 pydantic-settings==2.7.0
 python-jose[cryptography]==3.3.0
 passlib[bcrypt]==1.7.4
 python-multipart==0.0.20
 email-validator==2.2.0
 httpx==0.28.1
 pytest==8.3.4
 pytest-asyncio==0.25.0
 pytest-cov==6.0.0
@@ -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 |
@@ -0,0 +1,426 @@
 # Content Moderation & Age Verification Architecture
 > **Status:** Proposed
 > **Owner:** Platform team
 > **Related:** Server authority + client prediction, avatar component system, backend auth (JWT)
 ## 1. Overview
 This document specifies the **content moderation** and **age verification**
 architecture for **agp-game**, a Godot-based multiplayer game built by
 autonomous agents. It defines:
 - How **content flags** propagate through the system across the three primary
  content types: **assets**, **rooms**, and **scripts**.
 - How flags are **evaluated, aggregated, and enforced** at load time, at
  runtime, and at the network boundary.
 - The **age verification flow**, combining a lightweight **self-declaration**
  with an optional **ID check hook** for higher-assurance verification.
 The goal is a **single, consistent moderation pipeline** that applies the same
 rules to user-generated content (UGC) regardless of whether it is a 3D asset, a
 room definition, or a script, and that gates access to mature content behind a
 verifiable age gate.
 ### 1.1 Design Goals
 - **Uniformity:** One flag vocabulary and one propagation mechanism across
  assets, rooms, and scripts.
 - **Composability:** Flags on a room aggregate the flags of the assets and
  scripts it contains; flags on a world aggregate the flags of its rooms.
 - **Enforcement at the boundary:** The server is authoritative for what content
  a client may load or receive, mirroring the server-authoritative networking
  model.
 - **Privacy-preserving age checks:** Self-declaration requires no PII; the ID
  check hook is optional, pluggable, and never stores raw identity documents.
 - **Auditability:** Every flag decision is logged with a reason, an actor, and
  a timestamp so moderation actions are reviewable.
 ---
 ## 2. Content Flag Vocabulary
 All content carries a set of **content flags**. A flag is a typed, immutable
 label with a **severity** and a **scope**. Flags are the atomic unit of
 moderation; everything else (aggregation, enforcement, gating) operates on
 flags.
 ### 2.1 Flag Definition
 A flag is a structured record:
 | Field      | Type      | Description                                                              |
 |------------|-----------|--------------------------------------------------------------------------|
 | `id`       | `string`  | Stable machine-readable identifier, e.g. `violence.gore`.                |
 | `label`    | `string`  | Human-readable name, e.g. "Graphic Gore".                                |
 | `category` | `enum`    | One of `violence`, `sexual`, `language`, `substance`, `gambling`, `horror`, `hate`, `custom`. |
 | `severity` | `enum`    | One of `none`, `mild`, `moderate`, `severe`.                             |
 | `scope`    | `enum`    | One of `visual`, `audio`, `text`, `behavior`, `interaction`.             |
 | `mature`   | `bool`    | Whether this flag triggers the age gate (see §5).                        |
 | `reason`   | `string`  | Free-text justification supplied by the flagger.                         |
 | `source`   | `enum`    | One of `author`, `moderator`, `automated`, `community`.                  |
 ### 2.2 Canonical Flag Set
 The platform defines a **canonical registry** of flags so that different
 content types and different flaggers use the same vocabulary. Examples:
 | id                          | category   | severity  | scope        | mature |
 |-----------------------------|------------|-----------|--------------|--------|
 | `violence.none`             | violence   | none      | visual       | false  |
 | `violence.mild`             | violence   | mild      | visual       | false  |
 | `violence.gore`             | violence   | severe    | visual       | true   |
 | `sexual.suggestive`         | sexual     | mild      | visual       | true   |
 | `sexual.explicit`           | sexual     | severe    | visual       | true   |
 | `language.mild`             | language   | mild      | text         | false  |
 | `language.profanity`        | language   | moderate  | text         | false  |
 | `substance.references`      | substance  | mild      | text         | false  |
 | `gambling.simulated`        | gambling   | moderate  | behavior     | true   |
 | `horror.jumpscare`          | horror     | mild      | audio/visual | false  |
 | `hate.hateful`              | hate       | severe    | text         | true   |
 The registry is **data-driven** (a JSON/YAML manifest shipped with the server)
 so new flags can be added without code changes.
 ---
 ## 3. Flag Propagation Model
 Flags propagate through the system along the **content dependency graph**. The
 three content types form a hierarchy:
 ```
 World
 └── Room
      ├── Asset  (mesh, texture, audio, animation, material)
      └── Script (behavior, dialogue, event logic)
 ```
 ### 3.1 Propagation Rules
 1. **Explicit flags** are set directly on a content item by its author or a
   moderator.
 2. **Inherited flags** flow upward: a room's effective flag set is the **union**
   of its own explicit flags and the flags of every asset and script it
   references.
 3. **Aggregation** uses the **maximum severity** per category across all
   contributing items. A room containing one `violence.gore` asset and one
   `violence.none` asset is `violence.severe`.
 4. **Maturity is monotonic:** if any contributing item is `mature`, the
   containing room and world are `mature`.
 5. **Cycles are impossible** by construction: content references form a DAG
   (an asset cannot contain a room; a room cannot contain itself).
 ### 3.2 Propagation Through the Pipeline
 Flags are attached at **authoring time** and carried through every stage:
 ```
 Authoring ──► Upload ──► Validation ──► Storage ──► Distribution ──► Runtime
   │            │            │             │             │              │
   │ flag       │ flag       │ automated   │ flag        │ flag         │ flag
   │ declared   │ preserved  │ scan adds   │ indexed     │ re-checked   │ enforced
   │            │            │ flags       │             │              │
 ```
 | Stage        | Responsibility                                                          |
 |--------------|-------------------------------------------------------------------------|
 | **Authoring**| Author declares flags in the editor/upload UI.                          |
 | **Upload**   | Flags are validated against the canonical registry; unknown flags rejected. |
 | **Validation**| Automated scanner (hash-based + heuristic) adds flags for detected content. |
 | **Storage**  | Flags are stored alongside the content record and indexed for queries.  |
 | **Distribution**| Flags are re-checked against the current registry before serving.     |
 | **Runtime**  | The client enforces flags before loading content (see §4).              |
 ### 3.3 Data Model
 Flags are stored as a **normalized join table** so they can be queried and
 aggregated efficiently:
 ```
 content_item (id, type, owner_id, ...)
 content_flag  (content_id, flag_id, source, reason, created_at, actor_id)
 flag_registry (id, category, severity, scope, mature, ...)
 ```
 Aggregation is computed by a SQL view / query that joins a content item's
 transitive dependencies. Because the graph is a DAG, this is a bounded
 recursive query (PostgreSQL `WITH RECURSIVE`).
 ---
 ## 4. Enforcement
 Enforcement happens at three layers, in order:
 ### 4.1 Load-Time Enforcement (Server)
 Before a client is allowed to **request** content, the server evaluates the
 content's effective flag set against the requesting account's **content
 preferences** and **age verification status**:
 - If the content is `mature` and the account is **not age-verified**, the
  request is **rejected** with a `403 MATURE_CONTENT_REQUIRES_VERIFICATION`.
 - If the content's flags exceed the account's **content filter** (a per-account
  severity threshold per category), the request is rejected or the offending
  content is **stripped** (e.g., audio muted, mesh hidden, script not loaded).
 ### 4.2 Runtime Enforcement (Client)
 The client receives a **manifest** of allowed content from the server. It never
 loads content that is not in the manifest. This prevents a malicious or buggy
 client from bypassing the server's filter by loading content directly.
 - Assets not in the manifest are **not instantiated**.
 - Scripts not in the manifest are **not executed**.
 - Rooms not in the manifest are **not entered**.
 ### 4.3 Network Boundary Enforcement
 The server **filters replication** based on flags:
 - Mature or filtered content is **not replicated** to clients that cannot
  receive it.
 - A room's flag set is broadcast in the room metadata so clients can show a
  warning before entry.
 ### 4.4 Enforcement Decision Flow
 ```
 Client requests content C for account A
        │
        ▼
 Compute effective flags F(C)   [union + max-severity aggregation]
        │
        ▼
 Is A age-verified?  ──no──►  Is F(C).mature? ──yes──► REJECT (403)
        │ yes                     │ no
        ▼                         ▼
 Does F(C) exceed A's filter? ──► yes ──► REJECT or STRIP
        │ no
        ▼
 Serve content + manifest
 ```
 ---
 ## 5. Age Verification Flow
 Age verification is a **two-tier** system:
 - **Tier 1 — Self-declaration:** The user asserts their date of birth. This is
  fast, requires no PII beyond a birthdate, and is sufficient for most content.
 - **Tier 2 — ID check (optional hook):** A pluggable identity-verification
  provider confirms the user is an adult. This raises the account's assurance
  level and unlocks the highest maturity tier.
 ### 5.1 Verification States
 An account has an **age verification status**:
 | Status            | Meaning                                                              |
 |-------------------|----------------------------------------------------------------------|
 | `unverified`      | No declaration on file.                                              |
 | `self_declared`   | User declared a birthdate; **not** independently confirmed.          |
 | `id_verified`     | User passed the ID check hook; independently confirmed adult.        |
 | `rejected`        | ID check failed or declaration was inconsistent.                     |
 ### 5.2 Tier 1 — Self-Declaration Flow
 ```
 User submits { date_of_birth }
        │
        ▼
 Server validates format & plausibility (age 13–120, not in future)
        │
        ▼
 Compute age from DOB
        │
        ▼
 age >= 18 ──► status = self_declared (adult)
 age >= 13 ──► status = self_declared (minor, restricted)
 age <  13 ──► status = rejected (below minimum platform age)
 ```
 - The DOB is stored **encrypted at rest** and is **never exposed** to other
  players.
 - A user may **upgrade** from `self_declared` to `id_verified` at any time via
  Tier 2.
 ### 5.3 Tier 2 — ID Check Hook
 The ID check is an **optional, pluggable hook**. The platform defines an
 interface; concrete providers (e.g., a third-party KYC service) implement it.
 ```
 User requests ID verification
        │
        ▼
 Server creates a verification session (idempotent, expiring)
        │
        ▼
 Server calls provider hook:  verify(identity_token) -> { adult: bool, ref: string }
        │
        ▼
 adult == true ──► status = id_verified, store provider ref (not raw doc)
 adult == false ─► status = rejected
 provider error ──► status unchanged, retry allowed
 ```
 **Privacy guarantees:**
 - The platform **never stores** the raw identity document or image.
 - Only the provider's **opaque reference** and the boolean `adult` result are
  persisted.
 - The hook is **asynchronous and idempotent**; a session can be retried without
  double-charging or double-verifying.
 ### 5.4 Hook Interface
 The ID check hook is defined as a backend interface (FastAPI dependency /
 abstract service):
 ```python
 class IdentityVerificationProvider(Protocol):
    def create_session(self, user_id: str) -> VerificationSession: ...
    def verify(self, session_id: str, identity_token: str) -> VerificationResult: ...
 class VerificationResult:
    adult: bool
    provider_ref: str | None
    error: str | None
 ```
 A default **no-op provider** returns `adult=False` with a clear error, so the
 system runs without any third-party integration until one is configured.
 ### 5.5 Age Gate Enforcement
 The age gate is enforced at **load time** (see §4.1):
 | Verification status | Can access `mature` content? |
 |---------------------|------------------------------|
 | `unverified`        | No                           |
 | `self_declared`     | Yes (adult) / No (minor)     |
 | `id_verified`       | Yes                          |
 | `rejected`          | No                           |
 ---
 ## 6. Moderation Workflow
 ### 6.1 Flagging Sources
 Content can be flagged by:
 - **Author** (self-declared at upload).
 - **Automated scanner** (hash-based detection, heuristic analysis).
 - **Community** (players report content; reports become flags after review).
 - **Moderator** (manual review and override).
 ### 6.2 Review Queue
 Community and automated flags enter a **review queue**. A moderator either:
 - **Approves** the flag (it becomes authoritative), or
 - **Rejects** the flag (it is discarded), or
 - **Escalates** to a senior moderator for severe/hate flags.
 ### 6.3 Actions
 Once a flag is authoritative, a moderator can take actions:
 | Action          | Effect                                                        |
 |-----------------|---------------------------------------------------------------|
 | `warn`          | Notify the author; content remains.                           |
 | `restrict`      | Content hidden from users below a filter threshold.           |
 | `age_gate`      | Content marked `mature`; requires age verification.           |
 | `remove`        | Content taken down; not served.                               |
 | `ban_author`    | Author's upload privileges suspended.                         |
 ### 6.4 Audit Log
 Every flag and action is written to an **audit log**:
 ```
 audit_event (id, content_id, actor_id, action, flag_id, reason, created_at)
 ```
 This log is append-only and used for transparency and dispute resolution.
 ---
 ## 7. Client-Side Integration (Godot)
 ### 7.1 Content Manifest
 The server sends each client a **content manifest** — the set of content the
 client is permitted to load, derived from the account's verification status and
 filter. The Godot client:
 - Loads only manifest-listed assets.
 - Executes only manifest-listed scripts.
 - Shows a **maturity warning** dialog before entering a room whose effective
  flags include `mature` content.
 ### 7.2 Flag Metadata on Content
 Each content resource carries a `content_flags` metadata field (a Godot
 `Dictionary` or custom `Resource`). The client uses this for local UI decisions
 (e.g., showing a warning icon) but **never** as the authority for whether to
 load — the server manifest is authoritative.
 ### 7.3 Age Verification UI
 The client exposes an **age verification screen**:
 - Tier 1: a date-of-birth picker.
 - Tier 2: a button that opens the ID check provider flow (deep link / webview).
 The client calls the backend endpoints (§8) and reflects the resulting status.
 ---
 ## 8. Backend API Surface
 | Method | Path                              | Description                                    |
 |--------|-----------------------------------|------------------------------------------------|
 | `POST` | `/v1/age/declare`                 | Submit self-declared DOB (Tier 1).             |
 | `POST` | `/v1/age/verify/session`          | Create an ID-check session (Tier 2).           |
 | `POST` | `/v1/age/verify/confirm`          | Confirm an ID-check session with a token.      |
 | `GET`  | `/v1/age/status`                  | Return the account's verification status.      |
 | `GET`  | `/v1/content/{id}/flags`          | Return a content item's effective flags.       |
 | `POST` | `/v1/content/{id}/flags`          | Add a flag (author/community).                 |
 | `POST` | `/v1/moderation/review/{flag_id}` | Moderator approve/reject/escalate.             |
 | `POST` | `/v1/moderation/action`           | Apply a moderation action.                     |
 | `GET`  | `/v1/manifest`                    | Return the client's permitted content manifest.|
 All endpoints require a valid **JWT** (matching the existing auth stack). The
 age endpoints additionally require the account to be in a non-`rejected` state.
 ---
 ## 9. Security & Privacy Considerations
 - **DOB encryption:** Self-declared birthdates are encrypted at rest; only the
  derived age and verification status are used in authorization decisions.
 - **No raw identity storage:** The ID check hook persists only a provider
  reference and a boolean result.
 - **Server authority:** The client manifest prevents bypass; the client never
  trusts its own flag metadata for access decisions.
 - **Rate limiting:** Age-declaration and ID-check endpoints are rate-limited to
  prevent abuse and enumeration.
 - **Auditability:** All flag and verification events are logged append-only.
 ---
 ## 10. Open Questions / Future Work
 - **Regional age thresholds:** Different jurisdictions may require different
  minimum ages; the threshold should be configurable per region.
 - **Parental controls:** A future feature may let a parent set a content filter
  on a minor's account.
 - **Automated scanner accuracy:** The heuristic scanner may produce false
  positives; a confidence score should be attached to automated flags.
 - **Offline / local content:** How flags apply to locally-authored content that
  is never uploaded remains to be defined.
@@ -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       |
@@ -0,0 +1,159 @@
 # GDScript Sandboxing for User-Written Scripts
 > **Status:** Proposed
 > **Owner:** Platform team
 > **Related:** Content moderation & age verification (scripts are one of the
 > three moderated content types), avatar component system
 ## 1. Overview
 This document evaluates how to safely run **user-written scripts** as part of
 UGC (user-generated content) in **agp-game**, and recommends an approach.
 **Bottom line: Godot 4 has no built-in security sandbox for GDScript, and
 none of the three options named in the original task hold up under testing.**
 A script running anywhere inside the Godot process — however it's loaded,
 parented, or wrapped — runs with full engine privileges: arbitrary process
 execution, full filesystem read/write, and raw network access. Sandboxing
 has to happen *outside* the scripting language, not through an in-engine
 restriction mechanism, because no such mechanism exists.
 This was verified directly against Godot 4.6.2 (`godot --headless`, evidence
 in `sandbox_probe/` on this branch) rather than assumed from documentation,
 some of which (see §2.1) describes APIs that don't actually exist in this
 version.
 ## 2. Options Evaluated
 ### 2.1 Godot's built-in "ScriptServer" restrictions — does not exist
 There is no `ScriptServer` class in Godot 4.6.2:
 ```
 ClassDB.class_exists("ScriptServer")  →  false
 ```
 There's also no project setting to disable engine subsystems for scripts —
 none of `application/run/disable_os`, `disable_file_access`, or
 `disable_network` exist as settings, and `ProjectSettings.get_property_list()`
 returns nothing matching "sandbox", "restrict", or "security". Any plan that
 assumes a flag like this exists needs to be dropped; it was likely conflated
 with sandboxing features from a different engine/scripting ecosystem, or
 with **export template stripping** (which controls what ships in a build,
 not what a script can call at runtime).
 Directly probed capabilities of an ordinary GDScript running as a normal
 node script, no special setup:
 | Capability | Available to any script? |
 |---|---|
 | `OS.execute(...)` — run arbitrary processes | ✅ Yes |
 | `FileAccess.open(...)` — read/write any path the OS user can reach | ✅ Yes (read `/etc/hostname`, write `/tmp/...` both succeeded) |
 | `TCPServer` / `HTTPClient` / `HTTPRequest` / `PacketPeerUDP` / `WebSocketPeer` | ✅ All instantiate and work |
 | `ClassDB.instantiate(...)` — construct any engine class by name | ✅ Yes |
 | Loading and running a second script from source text at runtime (`GDScript.new()` + `.reload()`) | ✅ Yes |
 **Verdict: rejected.** There is nothing to configure here — the restriction
 surface this option assumed doesn't exist in the engine.
 ### 2.2 Isolated SubViewport with a limited API — doesn't isolate scripts
 `SubViewport` is a **rendering and input isolation** primitive (it gives a
 scene subtree its own render target and can gate input propagation) — it is
 not a security or scripting boundary. A script attached to any node inside a
 `SubViewport` still runs in the same process, on the same GDScript VM, with
 the exact same access to `OS`, `FileAccess`, networking classes, and
 `ClassDB` as a script anywhere else in the tree. Nothing about being
 "inside" a SubViewport changes what API calls are reachable from a script.
 **Verdict: rejected.** This solves a rendering/UI-composition problem, not
 the security problem the task is asking about. Worth keeping in mind for
 other purposes (e.g. isolated preview rendering of user avatars), but it
 provides zero script sandboxing.
 ### 2.3 Custom GDScript interpreter with an allowlist — right idea, wrong layer for "custom interpreter"
 Two ways to read this option, tested separately:
 **(a) Write/embed a separate GDScript parser+interpreter.** Not
 practical — this means re-implementing (and then indefinitely maintaining,
 in lockstep with every Godot release) a full language interpreter outside
 the engine. Far more engineering than the problem justifies.
 **(b) Use Godot's built-in `Expression` class as a restricted subset.**
 `Expression` *looks* like a natural allowlist mechanism — it only evaluates
 a single expression, no control flow, no arbitrary statements. But it isn't
 safe by default: it can still reach through to unsafe engine methods if you
 aren't careful about what object you hand it as a base instance:
 ```gdscript
 var expr = Expression.new()
 expr.parse("get_environment('HOME')", ["OS"])
 expr.execute([], OS)   # → "/home/daddy"  (successfully called OS.get_environment)
 ```
 So `Expression` is a viable building block only if the host **never passes
 a base instance (or arguments) that exposes anything sensitive** — i.e. the
 allowlisting work still has to happen at the call site, `Expression` itself
 enforces none of it.
 **Static text pattern-matching (blocklisting dangerous substrings like
 `"OS.execute"` before parsing) was also probed and is not a real
 defense** — it's trivially defeated by string concatenation, `call()`,
 `Callable`, or any other indirection, and produces false confidence.
 **Verdict: partially viable, but only as a foundation, not a solution on
 its own.** A hand-built, narrow, data-driven DSL (not full GDScript, not
 raw `Expression`) with an explicit allowlist of safe operations and *no
 ability to reference engine singletons or arbitrary objects* is the only
 version of "custom interpreter" that's actually safe. This is real
 engineering effort, not a config flag.
 ## 3. Recommendation
 **Don't run untrusted GDScript in-process at all.** Given none of the three
 in-engine options provide a real boundary, the two approaches actually worth
 building are, in order of recommended priority:
 1. **Primary: a narrow, non-Turing-complete content DSL**, not general
   scripting. Most UGC scripting needs in a game like this (custom
   interactions, simple triggers, item behaviors) don't need a general
   programming language — they need a small set of declarative
   verbs/conditions (e.g. `on_interact: give_item("torch")`,
   `on_enter: play_sound("chime")`). Expressed as data (JSON/Resource, not
   code) and interpreted by trusted, hand-written GDScript on the engine
   side. This has *zero* attack surface by construction — there's no
   interpreter to escape because there's no general execution, just a
   fixed, reviewed set of verbs. This is almost certainly sufficient for
   the actual UGC use cases in this game and should be scoped against real
   feature requirements before assuming more is needed.
 2. **If genuinely general scripting becomes a hard requirement**, isolate it
   at the OS level, not the engine level: run untrusted scripts in a
   **separate process** (a stripped-down Godot instance or a dedicated
   interpreter) under OS sandboxing (a restricted user account, a
   container, or `firejail`/`bwrap`/seccomp), communicating with the main
   game over a narrow IPC/RPC boundary that only exposes intentionally-safe
   operations. This is the only approach that provides a real security
   boundary for arbitrary code, because it doesn't depend on the scripting
   language cooperating — the OS enforces it. Substantially more
   infrastructure than option 1; only worth it if option 1's DSL genuinely
   can't express what's needed.
 **Do not** attempt in-process GDScript sandboxing via SubViewport,
 ScriptServer, or ad hoc blocklisting — all three were directly tested and
 none provide a real boundary (§2).
 ## 4. Open Questions
 - What do actual planned UGC scripts need to *do*? (Trigger conditions,
  simple item/state effects, dialogue branching?) This determines whether
  the DSL in §3.1 is sufficient or whether §3.2's process isolation is
  needed. Needs a concrete feature list before implementation starts.
 - If §3.2 is needed later, does it run per-user-session or shared/pooled?
  Affects resource cost and isolation guarantees.
 - Interaction with the content moderation pipeline (`content_moderation.md`):
  scripts as a moderated content type still need a moderation flag path
  regardless of which execution model is chosen — a DSL makes static
  analysis of *what a script can possibly do* far easier than it would be
  for general code, which is an additional point in its favor.
@@ -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.
@@ -0,0 +1,8 @@
 ; Engine configuration file.
 config_version=5
 [application]
 config/name="sandbox_probe"
 run/main_scene="res://probe5.tscn"
 config/features=PackedStringArray("4.6")
@@ -0,0 +1 @@
@@ -0,0 +1,76 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE START ===")
 	probe_script_loading()
 	probe_os_apis()
 	probe_file_access()
 	probe_network()
 	probe_engine_apis()
 	print("=== SANDBOX PROBE END ===")
 	get_tree().quit()
 func probe_script_loading():
 	print("--- Script loading ---")
 	# Can we load a GDScript from a string at runtime?
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
 	var err = gd.reload()
 	print("GDScript.reload() from source_code err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  instantiated, hello()=", inst.call("hello"))
 	# Can we load a script resource from a path?
 	var res = load("res://test_script.gd")
 	print("load('res://test_script.gd') = ", res)
 func probe_os_apis():
 	print("--- OS APIs ---")
 	# Can we execute shell commands?
 	var out = []
 	var exit_code = OS.execute("echo", ["hello"], out)
 	print("OS.execute('echo') exit=", exit_code, " out=", out)
 	# Environment access
 	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
 	# Process spawning
 	print("OS.create_process available: ", OS.has_method("create_process"))
 func probe_file_access():
 	print("--- File access ---")
 	# Can we read arbitrary files?
 	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
 	print("FileAccess.open('/etc/hostname') = ", f)
 	if f:
 		print("  content: ", f.get_as_text())
 		f.close()
 	# Can we write outside the project?
 	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
 	print("FileAccess.open('/tmp/...', WRITE) = ", w)
 	if w:
 		w.store_string("probe")
 		w.close()
 		print("  wrote to /tmp OK")
 func probe_network():
 	print("--- Network ---")
 	# Can we open raw sockets?
 	var tcp = TCPServer.new()
 	var bind_err = tcp.listen(0)
 	print("TCPServer.listen(0) err=", bind_err)
 	# HTTP client
 	var http = HTTPClient.new()
 	print("HTTPClient instantiated: ", http != null)
 func probe_engine_apis():
 	print("--- Engine APIs ---")
 	# Can we access the scene tree / add nodes?
 	var node = Node.new()
 	print("Node.new() = ", node)
 	# Can we access ProjectSettings?
 	print("ProjectSettings.get_setting('application/config/name') = ", ProjectSettings.get_setting("application/config/name"))
 	# Can we access the filesystem directory listing?
 	var dir = DirAccess.open("/")
 	print("DirAccess.open('/') = ", dir)
 	if dir:
 		var names = dir.get_files()
 		print("  root files count: ", names.size())
@@ -0,0 +1,6 @@
 [gd_scene load_steps=2 format=3]
 [ext_resource type="Script" path="res://probe.gd" id="1"]
 [node name="Probe" type="Node"]
 script = ExtResource("1")
@@ -0,0 +1,83 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE 2: Sandboxing Mechanisms ===")
 	probe_scriptserver()
 	probe_script_restrictions()
 	probe_subviewport_isolation()
 	probe_engine_restrictions()
 	probe_allowlist_approach()
 	print("=== SANDBOX PROBE 2 END ===")
 	get_tree().quit()
 func probe_scriptserver():
 	print("--- ScriptServer ---")
 	# Does ScriptServer exist and what can it do?
 	print("ScriptServer has_method('get_language_count'): ", ScriptServer.has_method("get_language_count"))
 	print("ScriptServer has_method('get_language'): ", ScriptServer.has_method("get_language"))
 	# Can we enumerate registered script languages?
 	if ScriptServer.has_method("get_language_count"):
 		var count = ScriptServer.get_language_count()
 		print("  language count: ", count)
 		for i in range(count):
 			var lang = ScriptServer.get_language(i)
 			print("  language[", i, "] = ", lang)
 func probe_script_restrictions():
 	print("--- Script restrictions ---")
 	# Can we restrict which classes/globals a script can access?
 	# Test: does GDScript have any built-in allowlist mechanism?
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc evil():\n\treturn OS.get_environment('HOME')\n"
 	var err = gd.reload()
 	print("  GDScript with OS access reload err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  evil() result: ", inst.call("evil"))
 	# Can we block specific global classes?
 	print("  GDScript has method to restrict globals: ", gd.has_method("set_global_scope"))
 func probe_subviewport_isolation():
 	print("--- SubViewport isolation ---")
 	# SubViewports isolate rendering, but do they isolate script execution?
 	var vp = SubViewport.new()
 	print("  SubViewport.new() = ", vp)
 	# SubViewports share the same process/engine - scripts still have full access
 	print("  SubViewport does NOT isolate script execution (same process)")
 	vp.free()
 func probe_engine_restrictions():
 	print("--- Engine restrictions ---")
 	# Is there a way to disable OS/File/Network access globally?
 	print("  Engine.has_singleton('OS'): ", Engine.has_singleton("OS"))
 	print("  Engine.has_singleton('FileAccess'): ", Engine.has_singleton("FileAccess"))
 	# Check if there's a '--disable-*' flag or project setting
 	print("  ProjectSettings has 'application/run/disable_*': ", ProjectSettings.has_setting("application/run/disable_os"))
 	# Check for any sandbox-related project settings
 	var settings = ProjectSettings.get_property_list()
 	var sandbox_settings = []
 	for s in settings:
 		if "sandbox" in String(s.name).to_lower() or "restrict" in String(s.name).to_lower():
 			sandbox_settings.append(s.name)
 	print("  Sandbox-related project settings: ", sandbox_settings)
 func probe_allowlist_approach():
 	print("--- Allowlist approach ---")
 	# The allowlist approach: parse GDScript source and reject disallowed patterns
 	# Test: can we detect dangerous API calls via string analysis?
 	var dangerous_patterns = [
 		"OS.execute", "OS.create_process", "OS.get_environment",
 		"FileAccess.open", "DirAccess.open", "TCPServer", "HTTPClient",
 		"load(", "preload(", "ClassDB", "Engine.get_main_loop",
 		"get_tree().quit", "ProjectSettings"
 	]
 	var test_script = """
 extends Node
 func _ready():
 	var f = FileAccess.open("/etc/passwd", FileAccess.READ)
 	OS.execute("rm", ["-rf", "/"])
 	"""
 	print("  Test script contains dangerous patterns:")
 	for p in dangerous_patterns:
 		if p in test_script:
 			print("    DETECTED: ", p)
@@ -0,0 +1,126 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE 3: Deep Sandboxing Mechanisms ===")
 	probe_global_scope_restriction()
 	probe_classdb_restriction()
 	probe_engine_singletons()
 	probe_script_validation()
 	probe_expression_engine()
 	probe_worker_threads()
 	probe_os_restriction_flags()
 	print("=== SANDBOX PROBE 3 END ===")
 	get_tree().quit()
 func probe_global_scope_restriction():
 	print("--- Global scope restriction ---")
 	# Can we enumerate what's in the global scope?
 	var globals = []
 	for g in GDScript.get_global_class_list():
 		globals.append(g)
 	print("  GDScript.get_global_class_list() count: ", globals.size())
 	# Can we check if a global is available before using it?
 	print("  GDScript has 'get_global_class_list': ", GDScript.has_method("get_global_class_list"))
 	# Is there any way to restrict which globals a script sees?
 	print("  GDScript has 'set_global_scope': ", GDScript.has_method("set_global_scope"))
 	print("  GDScript has 'restrict_globals': ", GDScript.has_method("restrict_globals"))
 	# Check the GDScript class methods
 	var methods = GDScript.get_method_list()
 	var method_names = []
 	for m in methods:
 		method_names.append(m.name)
 	print("  GDScript methods: ", method_names)
 func probe_classdb_restriction():
 	print("--- ClassDB restriction ---")
 	# ClassDB is the registry of all engine classes. Can we restrict it?
 	print("  ClassDB has 'get_class_list': ", ClassDB.has_method("get_class_list"))
 	print("  ClassDB has 'class_exists': ", ClassDB.has_method("class_exists"))
 	# Can we check if a specific class is available?
 	print("  ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
 	print("  ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
 	print("  ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
 	# Is there a way to hide classes from scripts?
 	print("  ClassDB has 'set_class_enabled': ", ClassDB.has_method("set_class_enabled"))
 	print("  ClassDB has 'disable_class': ", ClassDB.has_method("disable_class"))
 func probe_engine_singletons():
 	print("--- Engine singletons ---")
 	# Engine singletons are the global objects like OS, Engine, etc.
 	# Can we enumerate them?
 	var singletons = Engine.get_singletons()
 	print("  Engine.get_singletons() count: ", singletons.size())
 	for s in singletons:
 		print("    singleton: ", s)
 	# Can we remove a singleton?
 	print("  Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
 	print("  Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
 func probe_script_validation():
 	print("--- Script validation ---")
 	# Can we validate a script before running it?
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc evil():\n\treturn OS.get_environment('HOME')\n"
 	var err = gd.reload()
 	print("  GDScript.reload() err=", err)
 	# Can we get the list of identifiers used in a script?
 	print("  GDScript has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
 	# Can we get the source code back?
 	print("  GDScript has 'get_source_code': ", gd.has_method("get_source_code"))
 	# Can we check what identifiers a script references?
 	print("  GDScript has 'get_script_constant_map': ", gd.has_method("get_script_constant_map"))
 	# Check if there's a way to get the AST
 	print("  GDScript has 'get_ast': ", gd.has_method("get_ast"))
 	print("  GDScript has 'get_parser': ", gd.has_method("get_parser"))
 func probe_expression_engine():
 	print("--- Expression engine ---")
 	# Godot has an Expression class for evaluating expressions safely
 	var expr = Expression.new()
 	var err = expr.parse("1 + 2")
 	print("  Expression.parse('1 + 2') err=", err)
 	if err == OK:
 		var result = expr.execute()
 		print("  Expression.execute() = ", result)
 	# Can Expression access OS?
 	var expr2 = Expression.new()
 	err = expr2.parse("OS.get_environment('HOME')")
 	print("  Expression.parse('OS.get_environment') err=", err)
 	if err == OK:
 		var result2 = expr2.execute()
 		print("  Expression.execute() = ", result2)
 	# Expression with base_instance
 	var expr3 = Expression.new()
 	err = expr3.parse("get_environment('HOME')", ["OS"])
 	print("  Expression.parse with base_instance err=", err)
 	if err == OK:
 		var result3 = expr3.execute([], OS)
 		print("  Expression.execute with OS base = ", result3)
 func probe_worker_threads():
 	print("--- Worker threads ---")
 	# Can we run scripts in worker threads?
 	print("  Thread has 'new': ", Thread.has_method("new"))
 	# WorkerThreadPool
 	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
 	# Can we isolate a script in a thread?
 	print("  Thread available: ", Thread != null)
 func probe_os_restriction_flags():
 	print("--- OS restriction flags ---")
 	# Check if there are any OS-level sandbox flags
 	print("  OS has 'get_environment': ", OS.has_method("get_environment"))
 	print("  OS has 'execute': ", OS.has_method("execute"))
 	print("  OS has 'create_process': ", OS.has_method("create_process"))
 	# Check project settings for sandbox-related options
 	var settings = ProjectSettings.get_property_list()
 	var relevant = []
 	for s in settings:
 		var name = String(s.name)
 		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
 			relevant.append(name)
 	print("  Sandbox/security project settings: ", relevant)
 	# Check if there's a way to disable specific features
 	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
 	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
 	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
@@ -0,0 +1,6 @@
 [gd_scene load_steps=2 format=3]
 [ext_resource type="Script" path="res://probe3.gd" id="1"]
 [node name="Probe3" type="Node"]
 script = ExtResource("1")
@@ -0,0 +1,232 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE 4: Godot 4.6.2 Sandboxing Mechanisms ===")
 	probe_script_loading()
 	probe_os_apis()
 	probe_file_access()
 	probe_network()
 	probe_classdb()
 	probe_expression_engine()
 	probe_engine_singletons()
 	probe_global_scope()
 	probe_worker_threads()
 	probe_project_settings()
 	print("=== SANDBOX PROBE 4 END ===")
 	get_tree().quit()
 func probe_script_loading():
 	print("--- Script loading ---")
 	# Can we load a GDScript from a string at runtime?
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
 	var err = gd.reload()
 	print("GDScript.reload() from source_code err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  instantiated, hello()=", inst.call("hello"))
 	# Can we load a script resource from a path?
 	var res = load("res://test_script.gd")
 	print("load('res://test_script.gd') = ", res)
 	# Can we get the source code back from a loaded script?
 	if res:
 		print("  get_source_code() available: ", res.has_method("get_source_code"))
 	# Can we get the AST / parse tree?
 	print("  GDScript instance has 'get_ast': ", gd.has_method("get_ast"))
 	print("  GDScript instance has 'get_parser': ", gd.has_method("get_parser"))
 	# Can we get the list of methods?
 	print("  GDScript instance has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
 	# Can we get the list of member variables?
 	print("  GDScript instance has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
 func probe_os_apis():
 	print("--- OS APIs ---")
 	# Can we execute shell commands?
 	var out = []
 	var exit_code = OS.execute("echo", ["hello"], out)
 	print("OS.execute('echo') exit=", exit_code, " out=", out)
 	# Environment access
 	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
 	# Process spawning
 	print("OS has 'create_process': ", OS.has_method("create_process"))
 	# Can we get the command line?
 	print("OS.get_cmdline_args() = ", OS.get_cmdline_args())
 	# Can we get user data dir?
 	print("OS.get_user_data_dir() = ", OS.get_user_data_dir())
 	# Can we get executable path?
 	print("OS.get_executable_path() = ", OS.get_executable_path())
 func probe_file_access():
 	print("--- File access ---")
 	# Can we read arbitrary files?
 	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
 	print("FileAccess.open('/etc/hostname') = ", f)
 	if f:
 		print("  content: ", f.get_as_text())
 		f.close()
 	# Can we write outside the project?
 	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
 	print("FileAccess.open('/tmp/...', WRITE) = ", w)
 	if w:
 		w.store_string("probe")
 		w.close()
 		print("  wrote to /tmp OK")
 	# Can we list directories?
 	var dir = DirAccess.open("/")
 	print("DirAccess.open('/') = ", dir)
 	if dir:
 		var names = dir.get_files()
 		print("  root files count: ", names.size())
 	# Can we access res:// and user:// ?
 	var res_dir = DirAccess.open("res://")
 	print("DirAccess.open('res://') = ", res_dir)
 	var user_dir = DirAccess.open("user://")
 	print("DirAccess.open('user://') = ", user_dir)
 func probe_network():
 	print("--- Network ---")
 	# Can we open raw sockets?
 	var tcp = TCPServer.new()
 	var bind_err = tcp.listen(0)
 	print("TCPServer.listen(0) err=", bind_err)
 	# HTTP client
 	var http = HTTPClient.new()
 	print("HTTPClient instantiated: ", http != null)
 	# Can we make HTTP requests?
 	var http_req = HTTPRequest.new()
 	print("HTTPRequest instantiated: ", http_req != null)
 	# PacketPeerUDP
 	var udp = PacketPeerUDP.new()
 	print("PacketPeerUDP instantiated: ", udp != null)
 	# WebSocket
 	var ws = WebSocketPeer.new()
 	print("WebSocketPeer instantiated: ", ws != null)
 func probe_classdb():
 	print("--- ClassDB ---")
 	# ClassDB is the registry of all engine classes
 	print("ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
 	print("ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
 	print("ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
 	print("ClassDB.class_exists('HTTPClient'): ", ClassDB.class_exists("HTTPClient"))
 	# Can we enumerate all classes?
 	var class_list = ClassDB.get_class_list()
 	print("ClassDB.get_class_list() count: ", class_list.size())
 	# Can we get methods of a class?
 	var os_methods = ClassDB.class_get_method_list("OS")
 	print("OS method count: ", os_methods.size())
 	# Can we get properties of a class?
 	var os_props = ClassDB.class_get_property_list("OS")
 	print("OS property count: ", os_props.size())
 	# Can we instantiate a class by name?
 	var inst = ClassDB.instantiate("Node")
 	print("ClassDB.instantiate('Node') = ", inst)
 	# Can we check if a class is a singleton?
 	print("ClassDB has 'class_get_singleton': ", ClassDB.has_method("class_get_singleton"))
 	# Can we get the singleton instance of OS?
 	var os_singleton = ClassDB.class_get_singleton("OS")
 	print("ClassDB.class_get_singleton('OS') = ", os_singleton)
 	# Can we check what methods are available on the singleton?
 	if os_singleton:
 		print("  OS singleton has 'execute': ", os_singleton.has_method("execute"))
 		print("  OS singleton has 'get_environment': ", os_singleton.has_method("get_environment"))
 func probe_expression_engine():
 	print("--- Expression engine ---")
 	# Godot has an Expression class for evaluating expressions safely
 	var expr = Expression.new()
 	var err = expr.parse("1 + 2")
 	print("Expression.parse('1 + 2') err=", err)
 	if err == OK:
 		var result = expr.execute()
 		print("  Expression.execute() = ", result)
 	# Can Expression access OS?
 	var expr2 = Expression.new()
 	err = expr2.parse("OS.get_environment('HOME')")
 	print("Expression.parse('OS.get_environment') err=", err)
 	if err == OK:
 		var result2 = expr2.execute()
 		print("  Expression.execute() = ", result2)
 	# Expression with base_instance
 	var expr3 = Expression.new()
 	err = expr3.parse("get_environment('HOME')", ["OS"])
 	print("Expression.parse with base_instance err=", err)
 	if err == OK:
 		var result3 = expr3.execute([], OS)
 		print("  Expression.execute with OS base = ", result3)
 	# Can Expression call arbitrary methods?
 	var expr4 = Expression.new()
 	err = expr4.parse("FileAccess.open('/etc/hostname', 1)")
 	print("Expression.parse('FileAccess.open') err=", err)
 	if err == OK:
 		var result4 = expr4.execute()
 		print("  Expression.execute() = ", result4)
 	# Can Expression access the scene tree?
 	var expr5 = Expression.new()
 	err = expr5.parse("get_tree().quit()")
 	print("Expression.parse('get_tree().quit()') err=", err)
 	if err == OK:
 		var result5 = expr5.execute()
 		print("  Expression.execute() = ", result5)
 func probe_engine_singletons():
 	print("--- Engine singletons ---")
 	# Engine singletons are the global objects like OS, Engine, etc.
 	var singletons = Engine.get_singletons()
 	print("Engine.get_singletons() count: ", singletons.size())
 	for s in singletons:
 		print("    singleton: ", s)
 	# Can we remove a singleton?
 	print("Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
 	print("Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
 	# Can we get the main loop?
 	print("Engine.get_main_loop() = ", Engine.get_main_loop())
 	# Can we get the physics server?
 	print("Engine.get_physics_server() = ", Engine.get_physics_server())
 func probe_global_scope():
 	print("--- Global scope ---")
 	# Can we enumerate what's in the global scope?
 	var globals = []
 	for g in GDScript.get_global_class_list():
 		globals.append(g)
 	print("GDScript.get_global_class_list() count: ", globals.size())
 	# Can we check if a global is available before using it?
 	print("GDScript has 'get_global_class_list': ", GDScript.has_method("get_global_class_list"))
 	# Is there any way to restrict which globals a script sees?
 	print("GDScript has 'set_global_scope': ", GDScript.has_method("set_global_scope"))
 	print("GDScript has 'restrict_globals': ", GDScript.has_method("restrict_globals"))
 	# Check the GDScript class methods
 	var methods = GDScript.get_method_list()
 	var method_names = []
 	for m in methods:
 		method_names.append(m.name)
 	print("  GDScript methods: ", method_names)
 func probe_worker_threads():
 	print("--- Worker threads ---")
 	# Can we run scripts in worker threads?
 	var thread = Thread.new()
 	print("  Thread.new() = ", thread)
 	# WorkerThreadPool
 	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
 	# Can we isolate a script in a thread?
 	print("  Thread available: ", Thread != null)
 func probe_project_settings():
 	print("--- Project settings ---")
 	# Check for any sandbox-related project settings
 	var settings = ProjectSettings.get_property_list()
 	var relevant = []
 	for s in settings:
 		var name = String(s.name)
 		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
 			relevant.append(name)
 	print("  Sandbox/security project settings: ", relevant)
 	# Check if there's a way to disable specific features
 	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
 	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
 	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
 	# Can we set project settings at runtime?
 	print("  ProjectSettings has 'set_setting': ", ProjectSettings.has_method("set_setting"))
 	print("  ProjectSettings has 'save': ", ProjectSettings.has_method("save"))
@@ -0,0 +1,6 @@
 [gd_scene load_steps=2 format=3]
 [ext_resource type="Script" path="res://probe4.gd" id="1"]
 [node name="Probe4" type="Node"]
 script = ExtResource("1")
@@ -0,0 +1,221 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE 5b: Corrected Sandboxing Mechanisms (Godot 4.6.2) ===")
 	probe_script_loading()
 	probe_os_apis()
 	probe_file_access()
 	probe_network()
 	probe_classdb()
 	probe_expression_engine()
 	probe_engine_singletons()
 	probe_worker_threads()
 	probe_project_settings()
 	probe_script_restrictions()
 	probe_allowlist()
 	print("=== SANDBOX PROBE 5b END ===")
 	get_tree().quit()
 func probe_script_loading():
 	print("--- Script loading ---")
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
 	var err = gd.reload()
 	print("GDScript.reload() from source_code err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  instantiated, hello()=", inst.call("hello"))
 	var res = load("res://test_script.gd")
 	print("load('res://test_script.gd') = ", res)
 	if res:
 		print("  get_source_code() available: ", res.has_method("get_source_code"))
 	print("  GDScript instance has 'get_ast': ", gd.has_method("get_ast"))
 	print("  GDScript instance has 'get_parser': ", gd.has_method("get_parser"))
 	print("  GDScript instance has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
 	print("  GDScript instance has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
 	print("  GDScript instance has 'get_instance_base_type': ", gd.has_method("get_instance_base_type"))
 	# Can we get the list of static methods on GDScript class?
 	var gd_methods = GDScript.get_method_list()
 	var gd_method_names = []
 	for m in gd_methods:
 		gd_method_names.append(String(m.name))
 	print("  GDScript static methods: ", gd_method_names)
 func probe_os_apis():
 	print("--- OS APIs ---")
 	var out = []
 	var exit_code = OS.execute("echo", ["hello"], out)
 	print("OS.execute('echo') exit=", exit_code, " out=", out)
 	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
 	print("OS has 'create_process': ", OS.has_method("create_process"))
 	print("OS.get_cmdline_args() = ", OS.get_cmdline_args())
 	print("OS.get_user_data_dir() = ", OS.get_user_data_dir())
 	print("OS.get_executable_path() = ", OS.get_executable_path())
 func probe_file_access():
 	print("--- File access ---")
 	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
 	print("FileAccess.open('/etc/hostname') = ", f)
 	if f:
 		print("  content: ", f.get_as_text())
 		f.close()
 	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
 	print("FileAccess.open('/tmp/...', WRITE) = ", w)
 	if w:
 		w.store_string("probe")
 		w.close()
 		print("  wrote to /tmp OK")
 	var dir = DirAccess.open("/")
 	print("DirAccess.open('/') = ", dir)
 	if dir:
 		var names = dir.get_files()
 		print("  root files count: ", names.size())
 	var res_dir = DirAccess.open("res://")
 	print("DirAccess.open('res://') = ", res_dir)
 	var user_dir = DirAccess.open("user://")
 	print("DirAccess.open('user://') = ", user_dir)
 func probe_network():
 	print("--- Network ---")
 	var tcp = TCPServer.new()
 	var bind_err = tcp.listen(0)
 	print("TCPServer.listen(0) err=", bind_err)
 	var http = HTTPClient.new()
 	print("HTTPClient instantiated: ", http != null)
 	var http_req = HTTPRequest.new()
 	print("HTTPRequest instantiated: ", http_req != null)
 	var udp = PacketPeerUDP.new()
 	print("PacketPeerUDP instantiated: ", udp != null)
 	var ws = WebSocketPeer.new()
 	print("WebSocketPeer instantiated: ", ws != null)
 func probe_classdb():
 	print("--- ClassDB ---")
 	print("ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
 	print("ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
 	print("ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
 	print("ClassDB.class_exists('HTTPClient'): ", ClassDB.class_exists("HTTPClient"))
 	var class_list = ClassDB.get_class_list()
 	print("ClassDB.get_class_list() count: ", class_list.size())
 	var os_methods = ClassDB.class_get_method_list("OS")
 	print("OS method count: ", os_methods.size())
 	var inst = ClassDB.instantiate("Node")
 	print("ClassDB.instantiate('Node') = ", inst)
 	# Can we enumerate ClassDB methods to see what's available?
 	var classdb_methods = ClassDB.get_method_list()
 	var classdb_method_names = []
 	for m in classdb_methods:
 		classdb_method_names.append(String(m.name))
 	print("  ClassDB methods: ", classdb_method_names)
 func probe_expression_engine():
 	print("--- Expression engine ---")
 	var expr = Expression.new()
 	var err = expr.parse("1 + 2")
 	print("Expression.parse('1 + 2') err=", err)
 	if err == OK:
 		var result = expr.execute()
 		print("  Expression.execute() = ", result)
 	var expr2 = Expression.new()
 	err = expr2.parse("OS.get_environment('HOME')")
 	print("Expression.parse('OS.get_environment') err=", err)
 	if err == OK:
 		var result2 = expr2.execute()
 		print("  Expression.execute() = ", result2)
 	var expr3 = Expression.new()
 	err = expr3.parse("get_environment('HOME')", ["OS"])
 	print("Expression.parse with base_instance err=", err)
 	if err == OK:
 		var result3 = expr3.execute([], OS)
 		print("  Expression.execute with OS base = ", result3)
 	var expr4 = Expression.new()
 	err = expr4.parse("FileAccess.open('/etc/hostname', 1)")
 	print("Expression.parse('FileAccess.open') err=", err)
 	if err == OK:
 		var result4 = expr4.execute()
 		print("  Expression.execute() = ", result4)
 	var expr5 = Expression.new()
 	err = expr5.parse("get_tree().quit()")
 	print("Expression.parse('get_tree().quit()') err=", err)
 	if err == OK:
 		var result5 = expr5.execute()
 		print("  Expression.execute() = ", result5)
 func probe_engine_singletons():
 	print("--- Engine singletons ---")
 	print("Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
 	print("Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
 	print("Engine.get_main_loop() = ", Engine.get_main_loop())
 	# Can we enumerate singletons via Engine instance methods?
 	var engine_methods = Engine.get_method_list()
 	var engine_method_names = []
 	for m in engine_methods:
 		engine_method_names.append(String(m.name))
 	print("  Engine instance methods: ", engine_method_names)
 func probe_worker_threads():
 	print("--- Worker threads ---")
 	var thread = Thread.new()
 	print("  Thread.new() = ", thread)
 	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
 func probe_project_settings():
 	print("--- Project settings ---")
 	var settings = ProjectSettings.get_property_list()
 	var relevant = []
 	for s in settings:
 		var name = String(s.name)
 		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
 			relevant.append(name)
 	print("  Sandbox/security project settings: ", relevant)
 	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
 	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
 	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
 	print("  ProjectSettings has 'set_setting': ", ProjectSettings.has_method("set_setting"))
 	print("  ProjectSettings has 'save': ", ProjectSettings.has_method("save"))
 func probe_script_restrictions():
 	print("--- Script restrictions ---")
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc evil():\n\treturn OS.get_environment('HOME')\n"
 	var err = gd.reload()
 	print("  GDScript with OS access reload err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  evil() result: ", inst.call("evil"))
 	print("  GDScript has method to restrict globals: ", gd.has_method("set_global_scope"))
 	print("  GDScript has method 'get_global_scope': ", gd.has_method("get_global_scope"))
 	# Can we check what identifiers a script references via the analyzer?
 	print("  GDScript has 'get_script_constant_map': ", gd.has_method("get_script_constant_map"))
 	# Can we get the list of member variables?
 	print("  GDScript has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
 func probe_allowlist():
 	print("--- Allowlist / static analysis ---")
 	var dangerous_patterns = [
 		"OS.execute", "OS.create_process", "OS.get_environment",
 		"FileAccess.open", "DirAccess.open", "TCPServer", "HTTPClient",
 		"load(", "preload(", "ClassDB", "Engine.get_main_loop",
 		"get_tree().quit", "ProjectSettings"
 	]
 	var test_script = """extends Node
 func _ready():
 	var f = FileAccess.open("/etc/passwd", FileAccess.READ)
 	OS.execute("rm", ["-rf", "/"])
 """
 	print("  Test script contains dangerous patterns:")
 	for p in dangerous_patterns:
 		if p in test_script:
 			print("    DETECTED: ", p)
 	# Can we use a tokenizer/lexer to parse GDScript?
 	# GDScriptLanguage is NOT exposed to GDScript (confirmed by parse error)
 	print("  GDScriptLanguage NOT exposed to GDScript (parse error confirmed)")
 	# Can we use the Expression engine to validate syntax?
 	var expr = Expression.new()
 	var err = expr.parse("var x = 1 + 2")
 	print("  Expression.parse('var x = 1 + 2') err=", err)
 	err = expr.parse("OS.execute('rm', ['-rf', '/'])")
 	print("  Expression.parse('OS.execute...') err=", err)
 	if err == OK:
 		var result = expr.execute()
 		print("  Expression.execute() = ", result)
@@ -0,0 +1,6 @@
 [gd_scene load_steps=2 format=3]
 [ext_resource type="Script" path="res://probe5.gd" id="1"]
 [node name="Probe5" type="Node"]
 script = ExtResource("1")
@@ -0,0 +1,174 @@
 extends Node
 func _ready():
 	print("=== SANDBOX PROBE 6: Corrected Evidence Gathering (Godot 4.6.2) ===")
 	probe_script_loading()
 	probe_os_apis()
 	probe_file_access()
 	probe_network()
 	probe_classdb()
 	probe_expression_engine()
 	probe_engine_singletons()
 	probe_worker_threads()
 	probe_project_settings()
 	probe_allowlist()
 	print("=== SANDBOX PROBE 6 END ===")
 	get_tree().quit()
 func probe_script_loading():
 	print("--- Script loading ---")
 	var gd = GDScript.new()
 	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
 	var err = gd.reload()
 	print("GDScript.reload() from source_code err=", err)
 	if err == OK:
 		var inst = gd.new()
 		print("  instantiated, hello()=", inst.call("hello"))
 	var res = load("res://test_script.gd")
 	print("load('res://test_script.gd') = ", res)
 	if res:
 		print("  get_source_code() available: ", res.has_method("get_source_code"))
 	print("  GDScript instance has 'get_ast': ", gd.has_method("get_ast"))
 	print("  GDScript instance has 'get_parser': ", gd.has_method("get_parser"))
 	print("  GDScript instance has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
 	print("  GDScript instance has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
 func probe_os_apis():
 	print("--- OS APIs ---")
 	var out = []
 	var exit_code = OS.execute("echo", ["hello"], out)
 	print("OS.execute('echo') exit=", exit_code, " out=", out)
 	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
 	print("OS has 'create_process': ", OS.has_method("create_process"))
 	print("OS.get_cmdline_args() = ", OS.get_cmdline_args())
 	print("OS.get_user_data_dir() = ", OS.get_user_data_dir())
 	print("OS.get_executable_path() = ", OS.get_executable_path())
 func probe_file_access():
 	print("--- File access ---")
 	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
 	print("FileAccess.open('/etc/hostname') = ", f)
 	if f:
 		print("  content: ", f.get_as_text())
 		f.close()
 	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
 	print("FileAccess.open('/tmp/...', WRITE) = ", w)
 	if w:
 		w.store_string("probe")
 		w.close()
 		print("  wrote to /tmp OK")
 	var dir = DirAccess.open("/")
 	print("DirAccess.open('/') = ", dir)
 	if dir:
 		var names = dir.get_files()
 		print("  root files count: ", names.size())
 	var res_dir = DirAccess.open("res://")
 	print("DirAccess.open('res://') = ", res_dir)
 	var user_dir = DirAccess.open("user://")
 	print("DirAccess.open('user://') = ", user_dir)
 func probe_network():
 	print("--- Network ---")
 	var tcp = TCPServer.new()
 	var bind_err = tcp.listen(0)
 	print("TCPServer.listen(0) err=", bind_err)
 	var http = HTTPClient.new()
 	print("HTTPClient instantiated: ", http != null)
 	var http_req = HTTPRequest.new()
 	print("HTTPRequest instantiated: ", http_req != null)
 	var udp = PacketPeerUDP.new()
 	print("PacketPeerUDP instantiated: ", udp != null)
 	var ws = WebSocketPeer.new()
 	print("WebSocketPeer instantiated: ", ws != null)
 func probe_classdb():
 	print("--- ClassDB ---")
 	print("ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
 	print("ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
 	print("ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
 	print("ClassDB.class_exists('HTTPClient'): ", ClassDB.class_exists("HTTPClient"))
 	var class_list = ClassDB.get_class_list()
 	print("ClassDB.get_class_list() count: ", class_list.size())
 	var os_methods = ClassDB.class_get_method_list("OS")
 	print("OS method count: ", os_methods.size())
 	var inst = ClassDB.instantiate("Node")
 	print("ClassDB.instantiate('Node') = ", inst)
 	print("ClassDB has 'class_get_singleton': ", ClassDB.has_method("class_get_singleton"))
 func probe_expression_engine():
 	print("--- Expression engine ---")
 	var expr = Expression.new()
 	var err = expr.parse("1 + 2")
 	print("Expression.parse('1 + 2') err=", err)
 	if err == OK:
 		var result = expr.execute()
 		print("  Expression.execute() = ", result)
 	var expr2 = Expression.new()
 	err = expr2.parse("OS.get_environment('HOME')")
 	print("Expression.parse('OS.get_environment') err=", err)
 	if err == OK:
 		var result2 = expr2.execute()
 		print("  Expression.execute() = ", result2)
 	var expr3 = Expression.new()
 	err = expr3.parse("get_environment('HOME')", ["OS"])
 	print("Expression.parse with base_instance err=", err)
 	if err == OK:
 		var result3 = expr3.execute([], OS)
 		print("  Expression.execute with OS base = ", result3)
 	var expr4 = Expression.new()
 	err = expr4.parse("FileAccess.open('/etc/hostname', 1)")
 	print("Expression.parse('FileAccess.open') err=", err)
 	if err == OK:
 		var result4 = expr4.execute()
 		print("  Expression.execute() = ", result4)
 	var expr5 = Expression.new()
 	err = expr5.parse("get_tree().quit()")
 	print("Expression.parse('get_tree().quit()') err=", err)
 	if err == OK:
 		var result5 = expr5.execute()
 		print("  Expression.execute() = ", result5)
 func probe_engine_singletons():
 	print("--- Engine singletons ---")
 	print("Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
 	print("Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
 	print("Engine.get_main_loop() = ", Engine.get_main_loop())
 func probe_worker_threads():
 	print("--- Worker threads ---")
 	var thread = Thread.new()
 	print("  Thread.new() = ", thread)
 	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
 func probe_project_settings():
 	print("--- Project settings ---")
 	var settings = ProjectSettings.get_property_list()
 	var relevant = []
 	for s in settings:
 		var name = String(s.name)
 		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
 			relevant.append(name)
 	print("  Sandbox/security project settings: ", relevant)
 	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
 	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
 	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
 	print("  ProjectSettings has 'set_setting': ", ProjectSettings.has_method("set_setting"))
 	print("  ProjectSettings has 'save': ", ProjectSettings.has_method("save"))
 func probe_allowlist():
 	print("--- Allowlist / static analysis ---")
 	var dangerous_patterns = [
 		"OS.execute", "OS.create_process", "OS.get_environment",
 		"FileAccess.open", "DirAccess.open", "TCPServer", "HTTPClient",
 		"load(", "preload(", "ClassDB", "Engine.get_main_loop",
 		"get_tree().quit", "ProjectSettings"
 	]
 	var test_script = """extends Node
 func _ready():
 	var f = FileAccess.open("/etc/passwd", FileAccess.READ)
 	OS.execute("rm", ["-rf", "/"])
 """
 	print("  Test script contains dangerous patterns:")
 	for p in dangerous_patterns:
 		if p in test_script:
 			print("    DETECTED: ", p)
@@ -0,0 +1,6 @@
 [gd_scene load_steps=2 format=3]
 [ext_resource type="Script" path="res://probe6.gd" id="1"]
 [node name="Probe6" type="Node"]
 script = ExtResource("1")
@@ -0,0 +1,6 @@
 extends SceneTree
 func _init():
 	print("ScriptServer class exists: ", ClassDB.class_exists("ScriptServer"))
 	var sv = SubViewport.new()
 	print("SubViewport instantiated: ", sv != null)
 	quit()
@@ -0,0 +1,8 @@
 ; Engine configuration file.
 config_version=5
 [application]
 config/name="sandbox_probe"
 run/main_scene="res://probe5.tscn"
 config/features=PackedStringArray("4.6")
@@ -0,0 +1,4 @@
 extends RefCounted
 func hello():
 	return "from test_script.gd"
Author	SHA1	Message	Date
architect-bot	4da8687f2c	Document GDScript sandboxing findings and recommendation Verified all three options from the task against Godot 4.6.2 directly (godot --headless), rather than trusting the probe scripts' own printed output from earlier sessions: - ScriptServer doesn't exist as a class; no disable_os/disable_file_access/ disable_network project settings exist either. Nothing to configure. - SubViewport isolates rendering/input only, not script capabilities — a script inside one has identical OS/FileAccess/network access. - Expression is not safe by default (can still reach unsafe methods through a base instance); blocklisting dangerous substrings is trivially bypassed. Recommendation: don't sandbox GDScript in-process (nothing to sandbox with) — use a narrow non-Turing-complete content DSL for the common case, and OS-level process isolation only if genuinely general scripting turns out to be required.	2026-08-17 23:43:48 +00:00
architect-bot	119cd9400a	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:33:57 +00:00
architect-bot	a576c25124	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:30:27 +00:00
architect-bot	0b00b01502	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:30:03 +00:00
architect-bot	8d50de075d	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:29:39 +00:00
architect-bot	2df195734b	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:26:31 +00:00
architect-bot	20be724115	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 21:00:02 +00:00
architect-bot	bd8f311a96	Recovered orphaned WIP before switching to a new task	2026-08-17 20:52:21 +00:00
architect-bot	d422eff912	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:41:48 +00:00
architect-bot	ae6ccc3e5f	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:39:05 +00:00
architect-bot	fed16f1f1d	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:37:49 +00:00
architect-bot	9450fb86d0	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:36:34 +00:00
architect-bot	a863bb2ab4	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:35:29 +00:00
architect-bot	a1846f34b5	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:33:56 +00:00
architect-bot	62447258b2	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:33:28 +00:00
architect-bot	c931670e9d	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:25:30 +00:00
architect-bot	68b783909d	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:25:15 +00:00
architect-bot	0b5034759c	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:24:53 +00:00
architect-bot	19a63bda11	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:24:28 +00:00
architect-bot	a3cdb18a5c	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:18:59 +00:00
architect-bot	a3fc36db19	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:18:40 +00:00
architect-bot	42914aec85	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:17:55 +00:00
architect-bot	8b17cc3ddd	WIP checkpoint: Research and design GDScript sandboxing approach	2026-08-17 20:17:28 +00:00
architect-bot	9e2e0ed921	Recovered orphaned WIP before switching to a new task	2026-08-17 20:09:27 +00:00
reviewer-bot	a632f2d8a6	Merge pull request 'Address review feedback: Design world chunk data format and persistence schema' (#11 ) from agent/c92c939b819c into main	2026-08-17 19:02:34 +00:00
architect-bot	0b973b73ab	WIP checkpoint: Address review feedback: Design world chunk data format and persistence schema	2026-08-17 18:29:14 +00:00
daddy	f0d10fc4ae	chore: remove test artifact from git-identity verification	2026-08-17 17:59:01 +00:00
reviewer-bot	1295b6a389	Merge pull request 'Identity test' (#10 ) from agent/identitytest111 into main	2026-08-17 17:58:44 +00:00
coder-bot	2ddcd58902	test commit as coder-bot	2026-08-17 17:58:14 +00:00
agent-bot	1ba334e983	Merge pull request 'Design content flagging and age verification architecture' (#8 ) from agent/4f174a207618 into main	2026-08-17 17:50:51 +00:00
agent-bot	80bc27426e	Merge pull request 'Design avatar component system and glTF attachment spec' (#7 ) from agent/fa0834ec1ba7 into main	2026-08-17 17:50:05 +00:00
agent-bot	a82ab52919	Merge pull request 'Design multiplayer architecture: server authority + client prediction' (#6 ) from agent/1cfe9ef94f55 into main	2026-08-17 17:49:26 +00:00
agent-bot	092ba57977	chore: remove test artifact from auto-merge verification	2026-08-17 17:10:19 +00:00
agent-bot	af847ddf78	Merge pull request 'Test feature for review flow' (#4 ) from agent/144e7c28535c into main	2026-08-17 17:06:53 +00:00
agent-bot	2b068cce15	implement thing	2026-08-17 17:06:28 +00:00
agent-bot	41fcbe746e	docs(moderation): add content moderation and age verification architecture	2026-08-17 15:46:04 +00:00
agent-bot	5eaeed80b4	docs(avatar): add avatar component system and glTF attachment spec	2026-08-17 15:27:27 +00:00
agent-bot	24d2029955	Add multiplayer networking architecture document	2026-08-17 15:22:15 +00:00