verify-godot-change

Verify a Godot change

Translate the requested change into observable criteria, then report what the evidence proves. Verification alone authorizes observation and bounded test interaction, not corrective persistent mutation. Fail a criterion unless the user separately requested a fix. Support begins at Godot 4.7.

Control contract

• Validate projectPath against effective MCP roots and allowed directories before any runtime or project access. Snapshot persistent files so verification can prove it did not edit them.
• Record watched or unattended mode. For watched work, call editor_session with ensure and launch enabled; stop if no usable editor can be established. Include projectPath for status reads too. For unattended verification, do not launch an editor: direct saved-state, compound verification, and runtime tools are sufficient and must not rewrite project metadata merely to establish a bridge.
• Treat reads as observation, injected input as bounded runtime-ephemeral test state, and any scene/resource/script/settings change as unauthorized unless the user also requested repair.
• Use canonical core tools directly (compact is only the compatibility alias). Resolve hidden analyze_project_integrity, game_get_property, and game_eval through godot_catalog detail, then invoke them with godot_call; never call a hidden tool directly.
• Respect Pause Agent without retry or bypass. While paused, use only safe observation, input release, stop, and cleanup; report the blocked effective tool.
• Use privileged reflection or evaluation only when already enabled, necessary for a criterion, and independently corroborated. Never enable it for convenience.

Workflow

1. Define applicable saved-state, runtime, rendered, timing, log/error, regression, and subjective/manual-review criteria. Mark non-applicable and unobservable criteria explicitly.
2. Check saved state first with run_project_tests discovery, headless checks, and host file reads of .tscn, .gd, and project.godot; use hidden integrity analysis only through the declared discovery flow.
3. Prefer verify_project and run_project_tests; use realtime run_project only for behavior the compound tools cannot prove.
4. Observe a baseline with capped game_get_scene_tree, subtree-filtered game_get_ui, logs, and game_screenshot where rendering is material. Read the tree before using a node path; keep runtime reads serial because the bridge handles one command at a time. Use game_get_node_info with compact detail and exact property names.
5. Prefer bounded game_wait_until and game_scenario. Drive held movement with a game_key_hold step inside one scenario paired with a bounded wait and release; do not hand-assemble repeated game_key_press taps. Never leave input held while making a separate observation call or while reasoning. Use game_click only when coordinate interaction is part of the criterion. In a scenario, put input fields under arguments; wait and assert steps put condition directly on the step, not tool game_wait_until plus arguments. game_key_hold has no duration field; use a bounded wait, then release it.
6. Repeat the same observation and compare the intended state. A successful tool response or screenshot alone does not prove behavior, audio quality, feel, or aesthetics.
7. Check negative evidence: game_get_errors, game_get_logs, warnings, fallbacks, ObjectDB/orphan/resource diagnostics, leaks, cleanup, and adjacent regressions. Re-hash persistent files to prove verification made no edit.
8. Release held input, call stop_project, and independently confirm teardown.