dream-godot-delegation

name

dream-godot-delegation

description

Use when Dream of One work would require a long or high-volume Godot AI MCP session, repeated runtime inspection or captures, or any hands-on game playtest. Keeps the lead session in place, spawns one native in-session high-capability subagent with exclusive run ownership, and returns compact evidence. NOT for code-only Godot edits, a bounded session preflight, backend-only work, or generic parallelization.

Dream of One — Godot Delegation

Keep high-volume Godot AI traffic and live-run context in a native in-session subagent. The lead owns scope, integration, and the final claim; the worker owns one bounded editor/game run from preflight through stop.

Read docs/tech/verification.md, docs/tech/godot-ai-playtest.md, and the repository dream-godot-playtest skill before delegating. Use references/worker-packet.md to specify the job and references/native-subagent-routing.md before spawning it.

Decide Whether To Delegate

Keep work in the lead session when it needs only a bounded preflight such as listing sessions, checking readiness, or reading one diagnostic result. Code, bulk data, imports, and deterministic smokes remain file/CLI work unless live state genuinely changes the next decision.

Delegate when any of these is true:

• the task requires a run lifecycle plus repeated scene-tree, property, log, or capture calls;
• reproducing a runtime issue needs an iterative observe/act/observe loop;
• a visual or player-facing claim needs several state transitions;
• any player input or hands-on gameplay is required.

Do not run two Godot workers against the same editor. While a worker owns the run, the lead and other workers make no Godot AI calls and do not stop, restart, or mutate that run.

Use the current harness's native subagent/thread/task capability. In Codex, follow the in-session collaboration adapter in references/native-subagent-routing.md; the worker remains a child of the current conversation. Do not shell out to another agent process, CLI, or harness as an automatic fallback. A different process is allowed only when the user explicitly asks for that execution surface.

Route The Worker

Keep the main/lead session on its current planning and integration model. Do not ask the user to switch the parent merely to route a worker.

• Use the high-capability worker route named by the current owner and docs/tech/verification.md. The current Codex default is GPT-5.6 Sol ultra for diagnosis, implementation-time inspection, and hands-on play.
• Use the harness's native child directly. If it exposes a model or effort selector, apply the current owner policy there. A missing selector is a blocker only when the owner explicitly required an exact independently pinned child runtime; it is not a reason to switch the parent or launch an external CLI.
• When a change needs implementation and fresh play evidence, finish and mechanically verify the implementation first, stop that run, then give one fresh native child a closed play packet. Do not change runtime policy midway through one run.
• Never apply lower-capability-executor-prompt unless the owner explicitly requests it.

Model and effort are runtime settings, not prose requests. Naming a model in a worker prompt does not change it and must never be reported as proof of an explicit pin.

Worker Authority And Ownership

The packet declares exactly one authority mode:

• inspect: read files and native Godot AI state; no player input or edits;
• play: send bounded player input through the normal game path; no source edits or direct backend/world mutation;
• implement: edit only the listed files, then perform non-play inspection; fresh acceptance play remains a separate run.

Delegation never broadens user authority. Workers must preserve user changes, never stage the untracked transfer documents, never expose secrets, and never use curl or a hand-rolled HTTP client in place of native Godot AI MCP.

The worker selects the editor by canonical repository path and verifies the pinned Godot/plugin/server versions. It may stop only the game run it started. It may not quit or restart a user-owned editor, reinstall the integration, change MCP client configuration, or use runtime mutation to manufacture a state the test is meant to reach.

Evidence Returned To The Lead

Return a compact packet containing:

• requested native worker route, any runtime-selection evidence actually exposed by the harness, authority mode, selected project/session, and version preflight;
• the observed state transitions relevant to the objective, with semantic values and capture paths when required;
• new editor/game errors, fixture or live-provider provenance, and any provider interruption;
• files changed and checks run, when the packet allowed implementation;
• whether the worker-owned run stopped cleanly;
• a direct result: pass, fail, inconclusive, or blocked, plus the smallest next action.

Fixture inspection is engineering evidence only. It never proves live model behavior, gameplay quality, or the fun gate. The lead inspects the worker artifact or diff before integrating the claim.

Stop And Recovery

Use one bounded recovery pass for session/helper connection failures, following dream-godot-playtest. Stop rather than switching to curl, Computer Use, an external agent process, or a restarted editor. If the worker edits outside its owned scope, loses exact session identity, observes another process taking run ownership, or cannot establish a runtime pin that the owner explicitly required, terminate the lane and report the conflict.

Gotchas

• A high number of calls alone does not justify parallel workers; one isolated Godot worker is the safe topology because editor/run state is shared.
• Native spawn surfaces differ in whether they expose model and effort selectors. Always verify Godot AI visibility; verify a runtime pin only when the owner made that exact pin part of acceptance.
• Native Godot AI calls can perturb timing. Prefer semantic checks at meaningful transitions over frame-by-frame polling, but do not reduce required evidence.
• A child session may discover the repo skills but not inherit the lead's loaded context. The packet must repeat its objective, authority, evidence, and stop rules.
• Worker output belongs in an ignored build/ path or the harness result, not a tracked ledger or standing report.