editor-status-docs-clarity: Clarify editor status response fields #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "task/editor-status-docs-clarity"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Assigned idea
Benchmark authoring specification.
Summary: Add a deterministic README clarification for the Godot MCP editor status JSON-RPC response shown in the documentation, explaining the meaning of null current_scene, unknown main_screen, false is_playing, and empty open_scenes when the editor has no active scene.
Task intent: Ordinary upstream-facing documentation work: improve README.md so users understand the documented editor status response from godot-mcp before they assume the server or addon is broken.
Benchmark plan: Construct a task package that asks the solver to update README.md near the existing JSON-RPC editor status example. The requested change should add a concise explanatory note for the exact idle-editor response shape shown in the repo evidence, without changing package behavior or broad documentation structure.
Environment plan: Use the upstream repository at commit 510d32b0e5ffccef94e731ef93caafeec572c5f0 as the environment/repo. The task/environment should provide only the normal checkout plus the authoring prompt; no Godot editor runtime is required because the work is a README-only clarification derived from existing documented output.
Verifier plan: test_outputs.py should read README.md and assert that a new explanatory section or note exists near the status example. It should require the literals current_scene, main_screen, is_playing, and open_scenes; require explanations for null current_scene, unknown main_screen, false is_playing, and empty open_scenes; and fail if the documented JSON example is removed or materially changed.
Oracle plan: The oracle solution edits README.md only, adding a short note after the existing status JSON example that explains the idle/no-open-scene editor state represented by the response and tells users this is a valid connected state, not an addon failure.
Difficulty plan: Current coding systems may overreach by modifying source code, adding tests that require Godot, or rewriting large README sections. They may also miss the exact semantic distinction between a connected idle editor and a failed connection, which the verifier should check through concrete field explanations.
Repo patch scope: Expected upstream edit scope is README.md only.
Anti-leakage notes: Do not expose solver-facing benchmark, harness, Snorkel, Harbor, std-ts, agent, stage, attempt, retry, generated task, or evaluation context. Present the work as a normal documentation improvement request for godot-mcp users.
Approach: Locate the documented JSON-RPC editor status response in README.md and add a concise explanatory note immediately after it. Preserve the existing example and surrounding Quick Start/documentation flow.
Verification: Run python test_outputs.py from the repository root; it must inspect README.md for the preserved status example and the required field-specific idle-state explanations.
Risk: Low implementation risk because the intended change is documentation-only; the main risk is an overly broad README rewrite or wording that does not explicitly cover all four status fields.
Path rules: task package is tasks/; mutable upstream checkout is tasks//environment/repo; benchmark package files are under tasks//task; verifier/container environment belongs under tasks//task/environment; regular and UI verifier logic belongs in task/tests/test_outputs.py and test.sh only runs that file through pytest.
Agent context
Task slug: editor-status-docs-clarity
Branch: task/editor-status-docs-clarity
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.Merge
Merge the changes and update on Forgejo.Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.