WIP checkpoint: Research Godot editor plugin vs in-game editor approach

docs/architecture/editor.md

@@ -0,0 +1,369 @@
+# Editor Architecture: Godot Editor Plugin vs. In-Game Editor
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** World chunk data format & persistence, server authority + client
+> prediction, content moderation & age verification, avatar component system
+> **Godot version:** 4.6.2 stable
+
+## 1. Overview
+
+This document evaluates the two primary ways to build the **world/level
+authoring tool** for **agp-game**:
+
+- **(a) Godot editor plugin** — extend the Godot editor itself with custom
+  panels, dock widgets, and tools that operate on the project's scenes and
+  resources.
+- **(b) In-game editor** — a fully custom editor built as game UI (Godot
+  `Control` nodes) that runs inside the running game, editing the game's own
+  world data.
+
+The goal is to pick the approach that best fits the platform's constraints:
+a **server-authoritative** multiplayer game where the **world is stored as
+versioned chunks** (see `world.md`), content is **moderation-flagged** (see
+`content_moderation.md`), and the client is a **shipped binary** that players
+run (not a dev tool).
+
+This document is a **decision record**: it lays out the trade-offs, gives a
+clear recommendation, and defines the resulting architecture boundaries.
+
+---
+
+## 2. Context & Constraints
+
+Before comparing the two approaches, we must fix the constraints that drive the
+decision. These come from the existing architecture docs.
+
+### 2.1 The World Is Data, Not Scenes
+
+`world.md` defines the world as **chunk data** (JSON for authoring, binary for
+runtime/network), persisted in SQLite on the server. A chunk is the atomic unit
+of load, save, and stream. The **server is the only writer** to the store;
+clients submit **deltas** against a `base_revision` and the server validates and
+applies them.
+
+**Implication:** The editor's output is **chunk payloads**, not `.tscn` scene
+files. Whatever editor we build must serialize to the chunk contract, not to
+Godot scene resources.
+
+### 2.2 Server-Authoritative & Moderation-Aware
+
+- The server validates every edit (schema, bounds, moderation) before
+  persisting (`world.md` §5.4).
+- Content carries **content flags** aggregated from referenced assets/scripts
+  (`content_moderation.md` §3). Mature content is gated behind age verification.
+- The client receives a **content manifest** and never loads content not in it.
+
+**Implication:** An editor that runs on a **player's machine** cannot be the
+authority on what gets published. Editing must go through the server's
+validation pipeline, and the editor must surface moderation flags.
+
+### 2.3 The Client Is a Shipped Binary
+
+The game is a multiplayer product. Players run a **release build**. The Godot
+editor is a **development tool** that players do not have.
+
+**Implication:** If authoring is a first-class *player* feature (user-generated
+content), the editor must ship inside the game binary. If authoring is a
+*developer/platform* feature, it can live in the editor.
+
+### 2.4 Two Distinct Audiences
+
+The evaluation must separate two audiences, because they have opposite needs:
+
+| Audience | Who | Where they run | What they build |
+|----------|-----|----------------|-----------------|
+| **Platform/dev** | The team building the game | Godot editor (dev machines) | Base worlds, rooms, templates, test levels |
+| **Players (UGC)** | End users | The shipped game | Their own rooms/worlds, published to the server |
+
+The two approaches map cleanly onto these audiences, and the right answer is
+likely **both** — but with a clear primary recommendation.
+
+---
+
+## 3. Approach (a): Godot Editor Plugin
+
+### 3.1 What It Is
+
+A Godot editor plugin is a set of scripts (and optionally scenes) that extend
+the editor via the `EditorPlugin` API. It can add:
+
+- **Dock panels** (`add_control_to_dock`) — e.g., a chunk/tile palette panel.
+- **Toolbar buttons** (`add_control_to_container`).
+- **Inspector plugins** (`EditorInspectorPlugin`) — custom property editors.
+- **Import plugins** (`EditorImportPlugin`) — custom asset importers.
+- **Scene/Node plugins** (`EditorNode3DGizmoPlugin`) — custom gizmos.
+- **Menu entries** (`add_tool_menu_item`).
+
+Plugins are enabled per-project via `project.godot` (`[editor_plugins]`).
+
+### 3.2 Pros
+
+- **Full editor power for free:** You get the scene tree, inspector, viewport
+  navigation, undo/redo, gizmos, and asset pipeline — all battle-tested.
+- **Native Godot editing:** Editing `.tscn` scenes, materials, and nodes is
+  exactly what the editor is built for. Great for authoring **base content**
+  (rooms, templates, avatar base bodies).
+- **Fast iteration for devs:** The platform team can build and test levels
+  directly in the tool they already use.
+- **Undo/redo, selection, snapping** come from the editor's `EditorUndoRedoManager`.
+- **No runtime footprint:** Editor-only code is stripped from export builds
+  (`@tool` scripts and editor plugins are not shipped to players).
+
+### 3.3 Cons
+
+- **Not available to players.** Players don't run the Godot editor. Any
+  player-facing UGC authoring cannot use this approach.
+- **Tied to the editor's UX.** You inherit the editor's look and interaction
+  model; deep customization is limited by what the editor API exposes.
+- **Editor API churn.** `EditorPlugin` APIs change between Godot versions;
+  plugins are more brittle across upgrades than game code.
+- **Scene-centric, not data-centric.** The editor is optimized for scenes and
+  resources. Our world is **chunk data** (`world.md`). We'd have to build a
+  translation layer (scene ↔ chunk) and keep it in sync — a real source of
+  drift.
+- **Single-user, local.** The editor edits local files. It does not natively
+  talk to our server-authoritative chunk store or the moderation pipeline.
+- **Headless/CI friction.** Validating plugin behavior in CI requires running
+  the editor headless, which is heavier than testing game code.
+
+### 3.4 Fit for Our Constraints
+
+- **Platform/dev authoring:** Excellent. This is the natural home for building
+  base worlds, rooms, and templates.
+- **Player UGC:** Not applicable. Players cannot run the editor.
+- **Server-authoritative chunk store:** Poor fit natively. The editor edits
+  local scenes; we'd bolt on a chunk export/import and a server sync layer.
+
+---
+
+## 4. Approach (b): In-Game Editor
+
+### 4.1 What It Is
+
+A fully custom editor built as **game UI** — Godot `Control` nodes (panels,
+buttons, toolbars) that run inside the running game. It edits the game's own
+world data model (chunks) and submits edits through the normal server pipeline.
+
+### 4.2 Pros
+
+- **Ships to players.** The editor is part of the game binary, so **player UGC
+  authoring is possible** — the core requirement for a user-generated-content
+  platform.
+- **Data-native.** The editor operates directly on the **chunk model**
+  (`world.md`), so there is no scene↔chunk translation layer and no drift.
+- **Server-authoritative by construction.** Edits go through the same
+  `request_chunk_edit` RPCs as gameplay, so validation, revisioning, and
+  moderation apply uniformly. The editor cannot bypass the server.
+- **Moderation-aware.** Because edits flow through the server, content flags are
+  computed and enforced at the boundary (`content_moderation.md` §4). The editor
+  can surface flags and gate mature content.
+- **One codebase, one UX.** The editor uses the same UI toolkit and art style as
+  the game; no separate editor theme to maintain.
+- **Testable in CI.** The editor is ordinary game code; it can be exercised
+  headlessly and unit-tested like any other system.
+
+### 4.3 Cons
+
+- **We build everything.** No free scene tree, inspector, gizmos, or undo/redo.
+  We must implement selection, snapping, undo/redo, viewport navigation, and
+  property editing ourselves.
+- **Runtime footprint.** Editor UI ships in the binary (though it can be gated
+  behind a feature flag / separate scene that is only instantiated on demand).
+- **More upfront work.** A usable in-game editor is a large feature; it needs
+  its own architecture (tool modes, gizmos, palette, inspector).
+- **Not ideal for deep asset authoring.** Modeling a mesh or authoring a
+  material is better done in the Godot editor / DCC tools. The in-game editor
+  should focus on **world composition** (placing tiles and objects), not asset
+  creation.
+
+### 4.4 Fit for Our Constraints
+
+- **Platform/dev authoring:** Workable but not ideal for deep asset work.
+- **Player UGC:** The **only** viable approach. Players can only author through
+  the shipped game.
+- **Server-authoritative chunk store:** Excellent fit. The editor is a client
+  that submits validated deltas.
+
+---
+
+## 5. Comparison Matrix
+
+| Criterion | (a) Editor plugin | (b) In-game editor |
+|-----------|-------------------|--------------------|
+| Ships to players | ❌ No | ✅ Yes |
+| Player UGC authoring | ❌ Impossible | ✅ Core capability |
+| World data model fit | ⚠️ Scene-centric; needs translation layer | ✅ Chunk-native |
+| Server-authoritative edits | ⚠️ Bolted on | ✅ Native (same RPCs) |
+| Moderation enforcement | ⚠️ Manual | ✅ At the boundary |
+| Free editor features (undo, gizmos, inspector) | ✅ Rich | ❌ Build ourselves |
+| Runtime footprint | ✅ None (stripped from export) | ⚠️ Ships in binary (gated) |
+| Dev iteration speed | ✅ Fast | ⚠️ Slower to build |
+| Deep asset authoring (mesh/material) | ✅ Native | ❌ Out of scope |
+| CI testability | ⚠️ Heavier (headless editor) | ✅ Ordinary game code |
+| Editor API churn risk | ⚠️ Higher | ✅ None (game code) |
+
+---
+
+## 6. Recommendation
+
+**Primary recommendation: build the in-game editor (b) as the platform's
+authoring surface, and use a lightweight Godot editor plugin (a) only as an
+internal dev convenience.**
+
+### 6.1 Rationale
+
+1. **Player UGC is the deciding factor.** The platform's value proposition is
+   user-generated content (rooms, worlds, avatars). Players cannot run the Godot
+   editor, so **only an in-game editor can deliver player authoring**. This is a
+   hard requirement that the editor-plugin approach cannot meet.
+
+2. **The world is data, and the in-game editor is data-native.** `world.md`
+   defines chunks as the atomic unit. An in-game editor edits chunks directly
+   and submits them through the server pipeline. An editor plugin would force a
+   scene↔chunk translation layer that is a constant source of drift and bugs.
+
+3. **Server authority and moderation fall out naturally.** Because in-game
+   edits use the same `request_chunk_edit` RPCs as gameplay, validation,
+   revisioning, optimistic concurrency, and content-flag enforcement
+   (`content_moderation.md`) apply uniformly. The editor cannot bypass the
+   server — which is exactly what a moderation-aware UGC platform needs.
+
+4. **The editor-plugin's strengths are not what we need.** Its free features
+   (scene tree, inspector, gizmos) are for editing Godot scenes and resources.
+   Our authoring is world composition against a chunk contract, not scene
+   editing. The plugin's main win — deep asset authoring — is better served by
+   DCC tools and the Godot editor for the *platform team*, not by a plugin we
+   must maintain.
+
+### 6.2 The Role of the Editor Plugin (Dev Convenience Only)
+
+We still recommend a **small, optional** editor plugin for the **platform team**
+to author **base content** (base rooms, templates, avatar base bodies, test
+levels) directly in the Godot editor. This is a dev-time convenience, not a
+product feature:
+
+- It can export a scene/resource as a **chunk** (reusing the same encoder as the
+  in-game editor) so dev-authored content flows into the same pipeline.
+- It is **not shipped** to players and is **not** the authoring surface for UGC.
+- It should be kept thin to minimize editor-API churn risk.
+
+### 6.3 Scope Boundary
+
+To keep the in-game editor tractable, define its scope clearly:
+
+- **In scope (world composition):** placing tiles, placing static/dynamic
+  objects, setting transforms, editing object properties, saving/loading chunks,
+  submitting edits to the server, showing moderation flags.
+- **Out of scope (asset creation):** modeling meshes, authoring materials,
+  rigging avatars. These are done in DCC tools / the Godot editor and imported
+  as catalog assets (see `avatar.md` §7). The in-game editor **references**
+  catalog assets by id; it does not create them.
+
+---
+
+## 7. Resulting Architecture
+
+### 7.1 Shared Editor Core
+
+Both the in-game editor and the (optional) dev plugin should share a single
+**editor core** that operates on the chunk model. This avoids two divergent
+implementations.
+
+```
+EditorCore (shared, data-native)
+├── ChunkEditorModel      # in-memory chunk being edited (tiles, objects, flags)
+├── ChunkEncoder          # JSON/binary encode/decode (world.md §3)
+├── EditSession           # base_revision tracking, delta generation
+├── EditSubmitter         # request_chunk_edit RPC wrapper + conflict handling
+├── UndoRedoStack         # command pattern over chunk mutations
+├── SelectionManager      # selected tiles/objects
+├── ToolRegistry          # brush, object-place, select, erase, etc.
+└── ModerationView        # surfaces content flags; gates mature content
+```
+
+### 7.2 In-Game Editor (Primary)
+
+```
+InGameEditor (Control-based UI, shipped in binary, gated by feature flag)
+├── EditorViewport        # custom 2D/3D viewport with camera navigation
+├── Toolbar               # tool mode switcher
+├── PalettePanel          # tile/object palette (from catalog)
+├── InspectorPanel        # property editor for selected object
+├── ChunkBrowser          # load/save chunks, list rooms
+└── EditorCore            # shared core (above)
+```
+
+- Instantiated only when the player enters "build mode" (a separate scene /
+  feature flag), so the runtime footprint is negligible during normal play.
+- Submits edits via `request_chunk_edit`; handles `chunk_edit_result` conflicts
+  by re-fetching and re-applying (`world.md` §5.4).
+
+### 7.3 Dev Editor Plugin (Optional, Thin)
+
+```
+DevChunkPlugin (EditorPlugin, dev-only, not shipped)
+├── Dock panel: "Chunk Export"
+├── Reads the current scene / selected nodes
+├── Maps scene content → chunk model (via EditorCore.ChunkEncoder)
+└── Exports a .chunk.json / submits to a dev server
+```
+
+Kept thin to minimize editor-API churn. Its only job is to let the platform team
+author base content in the editor and push it into the same chunk pipeline.
+
+### 7.4 Data Flow
+
+```
+[In-game editor]  --request_chunk_edit(delta, base_revision)-->  [Server]
+        ^                                                          | validate
+        |                                                          | apply
+        +--chunk_edit_result(ok/new_revision | conflict)-----------| persist
+                                                                   v
+                                                              SQLite (world.db)
+
+[Dev plugin]  --export chunk JSON-->  [EditorCore.ChunkEncoder]  -->  [Server]
+```
+
+Both paths converge on the **same server validation pipeline**, so moderation
+and revisioning are uniform regardless of authoring surface.
+
+---
+
+## 8. Risks & Mitigations
+
+| Risk | Mitigation |
+|------|------------|
+| In-game editor is a large build | Scope it to world composition (§6.3); reuse EditorCore; ship behind a feature flag |
+| Custom viewport/gizmos are hard | Start with a 2D tile editor (matches `CHUNK_SIZE_Z=1` default); add 3D later |
+| Undo/redo complexity | Use a command pattern over chunk mutations; test headlessly |
+| Editor-plugin API churn | Keep the plugin thin; treat it as dev-only convenience, not a product surface |
+| Drift between dev plugin and in-game editor | Both use the same `EditorCore`/`ChunkEncoder` |
+| Players bypass moderation | Impossible by construction: edits go through server validation |
+
+---
+
+## 9. Open Questions / Future Work
+
+- **3D editing:** The default world is flat (`CHUNK_SIZE_Z=1`). A 3D in-game
+  editor (volumetric chunks) is future work (`world.md` §8).
+- **Collaborative editing:** Multiple players editing the same chunk concurrently
+  — the optimistic-concurrency model already supports it, but the UX (live
+  cursors, conflict resolution) is unspecified.
+- **Template library:** A curated set of room templates players can start from.
+- **Publish/review flow:** How a player's authored room enters the moderation
+  review queue (`content_moderation.md` §6) and becomes publicly joinable.
+
+---
+
+## 10. Summary
+
+| Concern | Decision |
+|---------|----------|
+| Primary authoring surface | **In-game editor** (ships to players, enables UGC) |
+| Dev authoring convenience | Thin, optional **editor plugin** (not shipped) |
+| World data model | Both operate on the **chunk model** via a shared `EditorCore` |
+| Server authority | Edits go through `request_chunk_edit`; server validates |
+| Moderation | Enforced at the server boundary for both paths |
+| In-game editor scope | World composition only; asset creation is out of scope |
+| Runtime footprint | Editor gated behind a feature flag / separate scene |

docs/architecture/scripting_sandbox.md

@@ -1,159 +0,0 @@
-# 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.

project.godot

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

sandbox_probe/.godot/.gdignore

@@ -1 +0,0 @@
-

sandbox_probe/probe6.gd

@@ -1,174 +0,0 @@
-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)

sandbox_probe/probe6.tscn

@@ -1,6 +0,0 @@
-[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")

sandbox_probe/project.godot

@@ -1,8 +0,0 @@
-; Engine configuration file.
-config_version=5
-
-[application]
-
-config/name="sandbox_probe"
-run/main_scene="res://probe6.tscn"
-config/features=PackedStringArray("4.6")

sandbox_probe/test_script.gd

@@ -1,4 +0,0 @@
-extends RefCounted
-
-func hello():
-	return "from test_script.gd"