The STAGE Delivery Method

STAGE helps a solo director work with an autonomous engineering agent to reach trustworthy changes with less human attention. The Safety Kernel protects authority, source state, and truthful evidence. This guide is the complete ordinary delivery path; project maps and the maintainer laboratory are optional.

Start With The Requested Change

Give the agent an outcome and any meaningful boundary: the behavior to preserve, a rejected route, a diagnosis-only limit, or a product decision already made. The agent recovers relevant project instructions, uses the real project, and continues authorized work without repeated permission requests. A missing map, ticket, custom operation, handoff, or evidence package does not block progress.

The Delivery Loop

Understand → Change → Verify → Deliver
                ↑        |
                + repair +

These steps describe work. They need not appear as headings in a response or fields in a record. Small changes may combine them; diagnosis may end with a finding. A broad change may repeat them for several independently useful slices.

Understand

Recover the authorized outcome, protected state, relevant ownership, production consumer, intended environment, and necessary checks. Inspect the index and working tree before editing. Follow source cues until another observation is unlikely to change implementation, authority, evidence, or material risk. Conflicting evidence, failures, or an explicitly broad audit justify expansion.

Ask only about material unresolved decisions. Routine implementation choices, reversible repairs, and relevant checks are part of delivery. Existing human authorization remains valid; a task transition does not erase it.

Change

Implement the smallest complete result through canonical sources and established architecture. Keep unrelated work and uncertain authored state intact. A narrow authorized repair can proceed beside uncertain state when it preserves that state; permission to repair one value does not authorize regenerating its file.

Choose isolation according to actual concurrency, recovery, and repository policy. A branch or worktree is useful when those needs exist. It is not a prerequisite for every edit. If successive fixes fail, preserve their evidence, instrument the failure, and change the diagnosis before stacking more fixes. Revert only task-owned experiments from a known boundary.

Verify

Exercise the smallest route that contains each material claim's production consumer and integration boundaries. This is consumer-complete verification. A pure calculation may need only a focused deterministic test. Input handling, scene composition, middleware, frame timing, presentation, or platform behavior need the relevant real paths. Broad testing cannot compensate for an omitted boundary. Wait for current execution to finish and report its actual result. Use the project's scoped gate, including the whole task delta. Repeat expensive checks when their inputs or integration change, or policy requires it; a local commit alone does not invalidate a result. See quality guidance.

Repair relevant failures within authorization. Keep failed evidence and report checks that are unavailable, skipped, stale, or inconclusive. Do not weaken gates, suppress new findings broadly, rewrite baselines, or retry intermittent failures until a pass hides them. When an external inspection is called read-only, compare protected source before and after and disclose any change.

Static checks and tests establish their mechanical claims. Human judgment separately accepts visuals, audio, feel, balance, comprehension, and enjoyment. Use the evidence matrix when the right route is unclear.

Deliver

Review the final diff. After relevant mechanical checks pass, make a coherent local commit of only task-owned changes, using the project's conventions. Preserve unrelated index entries and working-tree changes. If safe separation cannot be established, leave the diff and explain the pending checkpoint. Source-control guidance covers that boundary. A required failed or unavailable mechanical check prevents the default verified checkpoint; it does not prevent reporting useful completed implementation.

A commit records engineering state. It does not imply human product acceptance. Subjective review may remain pending while a mechanically checked change is safely committed. Push, merge, release, and publication remain separate decisions, with existing authorization honored. Report the result, evidence, limitations, checkpoint, and precise next human action if one remains.

Conditional Work

Trigger	Additional behavior
New or materially changed gameplay premise	Recover or obtain an approved hypothesis, build one complete playable loop, and obtain human play feedback before broad expansion
Material visual, motion, or audio claim	Inspect the real production presentation using visual guidance; agent judgment remains advisory
Quality-policy changes or unfamiliar verification boundaries	Consult quality guidance; preserve gate strength
Repository switch, handoff, or lost context	Reconcile live source with decisions using continuity guidance before mutation
Sustained prioritization or several planned slices	Use the optional Director's Flow attention board
Explicit orientation, verification, or mapping request	Use the corresponding companion workflow and its narrower mutation boundary

Settled design work, ordinary fixes, and faithful implementation of approved intent do not reopen gameplay approval. Discoveries that change the hypothesis do. Systems-heavy work uses the same loop with attention to the player's information, choices, consequences, and recovery; see systems-heavy guidance.

Player-Facing Loop Expansion

Player-facing expansion follows the gameplay play boundary.

Diagnosis-Only Work

Preserve the target, inspect or reproduce the named symptom, identify the owner and production consumer, and separate observation, inference, and proposed repair. Deliver the supported diagnosis and next discriminating check. Do not repair behavior without authorization; use reversible instrumentation only when the investigation permits it.

Stop Conditions

Stop only the affected branch for unresolved intent, conflicting authority, unavailable required capability, or an operation outside authorization. A rejected implementation route stays rejected, including substitutes with the same rejected purpose. Continue useful independent work. Ask for the smallest missing decision or name the unavailable capability after preparing everything that can safely be made reviewable.

Earned Infrastructure

Start with the direct project-native path. A map, helper, abstraction, custom operation, export, or gallery earns persistence through an observed recurring cost, material ownership risk, or named present consumer. Proposed reuse is not observed demand. Retire infrastructure when its job disappears.

A gallery, codex, bestiary, model viewer, world previewer, or inspect mode is an ordinary game or authoring feature. Deliver one only for its own recurring job. Use existing engine views for one-off inspection and portable captures when a remote reviewer, comparison, CI, release, or retention decision needs them.

Optional Operation And Evidence Records

Projects adopting maps, named operations, ownership records, or durable evidence use the independent optional contracts. A documented operation is not a passed invocation. The repository's schemas, profiles, studies, and release machinery are its Maintainer Laboratory; ordinary games do not inherit them. Current release evidence belongs in the release record, not repeated test counts in operating guides.