The STAGE Delivery Method

STAGE optimizes for trustworthy change throughput per unit of human attention. It does not try to maximize agent activity, documentation, test count, or autonomy.

The Safety Kernel is the only universal requirement set. This document explains a practical default for applying it. Projects may use a different safe sequence.

Start With The Requested Change

An ordinary game change does not require a STAGE map, manifest, custom tool, review host, or evidence package. Begin in the real project and use its existing architecture, authoring surfaces, engine, runtime, tests, and source control.

Read existing project guidance when it is relevant. Do not interrupt a bounded change to manufacture guidance that has no recurring owner or consumer.

The Delivery Loop

Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint
  ^                                               |
  +---------------- tune or revert ---------------+

1. Frame

Establish:

• the player, author, or maintainer outcome;
• behavior and state that must remain unchanged;
• the authority boundary, including diagnosis-only or destructive limits;
• concrete mechanical acceptance checks; and
• which subjective decisions remain human-owned.

Use the newest human direction. If the human rejects the current route, stop that route instead of polishing or renaming it. Accepted fragments are things to preserve, not automatic permission to invent a nearby replacement.

2. Inspect

Inspect the smallest real path that can change the next decision:

• source-control state and pre-existing work;
• canonical authored data or source;
• the runtime owner and lifecycle;
• the production consumer;
• the relevant engine, middleware, or platform state; and
• the strongest available evidence for the current question.

Search from the named subject and strongest source cues. Continue while another observation can plausibly change ownership, implementation, evidence, authority, diagnosis, or material risk. Stop when the next engineering decision is supported.

Broaden when evidence conflicts, ownership or blast radius is unclear, verification fails, the production consumer is missing, or broad coverage is the requested result. Do not gather adjacent evidence merely for reassurance.

Tool readiness matters when the operation depends on it. In editor-driven projects, wait for import, compilation, domain reload, scene composition, or middleware generation before claiming that source edits are active.

Diagnosis-Only Work

When the request is only to investigate:

1. preserve the target;
2. find the authoritative owner and production consumer;
3. reproduce or inspect the named symptom;
4. separate observation, inference, and proposal; and
5. stop at the diagnosis and next discriminating check.

Do not silently cross from diagnosis into repair. Reversible instrumentation is appropriate only when authorized and needed to distinguish hypotheses.

3. Plan

Choose the smallest complete vertical result. Name:

• the ownership boundary and protected state;
• likely files or authored assets;
• material production consumers;
• claim-matched mechanical evidence;
• human visual, audio, feel, balance, pacing, or fun judgments; and
• rollback or checkpoint needs.

Use a written plan when risk or cross-system coordination makes it useful, not because STAGE requires a planning artifact.

Player-Facing Loop Expansion

When a task originates a game or materially expands its player-facing loop, begin with a human-led gameplay design dialogue. Recover accepted intent, surface assumptions, discuss the highest-leverage unknowns, and obtain the accountable human designer's approval of a testable player-experience hypothesis before multiplying the design:

• player fantasy and core verbs;
• intended experience and first-minute comprehension;
• the smallest repeatable loop, including success and failure; and
• observations that should stop expansion.

The agent may research theory, model mechanics, critique risks, and present alternatives. It does not silently choose the intended experience. If invention is explicitly delegated, the agent can draft a bounded hypothesis but still obtains human approval before broad implementation.

For strategy, management, builder, automation, simulation, economy, roguelite, deckbuilding, progression, or other decision-dense work, use the Systems-Heavy Gameplay Evidence guide after intent is approved. Trace perceive -> decide -> act -> read consequence -> learn -> adapt, and test the smallest complete decision. UI, feedback, onboarding, pacing, progression, balance, accessibility, and ethical player control are parts of that decision loop, not evidence that can be postponed behind a mechanically complete system.

Build one thin but complete loop through the real player surface. It needs the production input, presentation, feedback, objective, continuation, and UI or onboarding required to understand it. A mechanically reachable debug path or architecture skeleton is not enough.

The accountable human then plays that loop and separately judges comprehension, usability, engagement, and desire to continue. If the result is blocked or not tested, diagnose and iterate within the slice; do not spread the unaccepted premise through broad architecture, modes, content, or polish. Acceptance is project-local direction, not proof of objective fun or market fit. Claims about a broader audience require representative target players. Automated play can establish encoded behavior and mechanical reachability, not human comprehension, feeling, or fun. Reopen the gate after a material design change.

No artifact is required. When a durable brief is useful, start from the Gameplay Design Brief and Player Experience Brief. Formal research studies use the structured record in templates/case-study.yaml.

4. Build

Implement through canonical project sources and established local patterns. Keep unrelated changes intact. Prefer a focused rule, adapter, factory, authoring value, or engine component already used by the project over a new architecture.

When several plausible fixes fail against the same symptom, stop stacking patches. Return to a known checkpoint, instrument the failure, and revise the hypothesis.

5. Rehearse

For each material claim, choose the smallest route that includes its production consumer and every boundary material to the claim. This is consumer-complete verification.

Examples:

Claim	Useful route
Pure rule or calculation	Focused deterministic test
Runtime composition	Startup or composed runtime smoke
Input reaches gameplay	Real input path to observable outcome
Generated layout is valid	Invariants plus representative fixed and exploratory seeds
UI is readable	Production UI at relevant viewports plus human judgment
Animation feels correct	Continuous production playback plus human judgment
Performance improved	Comparable profiler measurement in the intended scope
Middleware integration works	Real middleware output through the consuming runtime

Focused tests remain valuable for speed and diagnosis. They simply do not prove boundaries they omit. A full end-to-end run is unnecessary when a narrower route already contains every material boundary.

Visual And Experiential Claims

Use real project content through the production renderer and relevant game or editor context. Prefer the live engine when the human can inspect it directly. Use screenshots, video, or comparison artifacts when a remote, CI, audit, release, or retention consumer actually needs portable evidence.

Do not build a detached review product to answer a one-off visual question. If the game independently needs a codex, gallery, bestiary, model viewer, world previewer, or inspect mode, deliver it as an ordinary product or authoring feature with its own user and acceptance criteria.

See Visual Work for details.

6. Judge

Separate four outcomes:

1. implementation exists;
2. mechanical checks support their declared claims;
3. human experiential judgment accepts or rejects the result; and
4. the work is checkpointed.

These outcomes often occur together, but none implies the others. Report failed, inconclusive, unavailable, and not-attempted checks plainly.

7. Checkpoint

Checkpoint accepted work coherently. If the result is rejected, tune from a known state or revert the experiment without disturbing unrelated work.

A checkpoint can be a commit, branch, shelved change, disposable copy, or another project-appropriate recovery boundary. The stronger the blast radius or irreversibility, the stronger the checkpoint should be.

Oversight Is Continuous

Human control is not a single approval dialog. Useful oversight can happen:

• before work, through goals, non-goals, and authority;
• during work, through corrections and visible progress;
• at risky boundaries, through explicit decisions; and
• after rehearsal, through acceptance, rejection, tuning, or rollback.

Agents can challenge assumptions and propose alternatives. Product intent, taste, destructive actions, publishing, and acceptance remain human-owned.

Risk Classes

Use project-specific language if it is better. A simple lens is:

Risk	Typical examples	Default handling
Low	focused code edit, reversible config change	proceed and verify
Medium	shared behavior, authored data, scene wiring	plan, inspect ownership, checkpoint
High	destructive migration, generated assets, middleware banks, release operation	explicit authority and strong recovery boundary

Risk depends on blast radius, reversibility, ownership certainty, and evidence availability, not just file count.

Stop Conditions

Stop the affected branch when:

• authority for the proposed operation, destructive scope, or credentials is unresolved;
• the user asks for diagnosis without repair;
• the human rejects the route's utility;
• a required production check is unavailable; or
• continued inspection cannot change the next material decision.

After stopping, preserve state and identify one missing decision or one truly discriminating check. Do not continue the blocked work under a narrower label.

Evaluate authority at the operation actually proposed. A complete artifact may contain unresolved or mixed-provenance state while still permitting an exact, separately authorized repair that preserves unresolved adjacent state. That narrow authority does not permit replacement, normalization, or regeneration of the containing artifact. Broad work requires authority and a canonical source for all state it can overwrite.

Earned Infrastructure

Add persistent structure in response to evidence:

Repeated problem	Possible response
Ownership or lifecycle is repeatedly rediscovered	Project map or focused architecture note
A fragile operation recurs	Named operation with readiness and completion signal
Important failures are invisible	Focused diagnostics or deterministic scenario
Authored/generated boundaries are unsafe	Ownership record and regeneration contract
A remote or release decision needs durable proof	Small evidence adapter or retained artifact

These are options, not a progression. Remove infrastructure whose job has disappeared.

Optional Operation And Evidence Records

When a project adopts structured operations or evidence, use the states and semantics in the optional contracts. An operation being documented is not evidence that it is available or passed. One evidence class does not automatically satisfy another.

The STAGE repository's schemas, migrations, external studies, release gates, and Solo Unity profile are its Maintainer Laboratory. They preserve optional public contracts and research history. Ordinary games do not inherit that laboratory by using the delivery loop.