0020: Make Change Delivery The Primary Agent Workflow

Status: Accepted

Detached-export consequences are superseded by ADR 0025.

Context

STAGE began as a method for improving real game changes, but its first packaged agent workflow focused on project mapping. Later work added extensive visual review, Almanac, operation, regression, and Evidence Export guidance. Those capabilities address real risks, yet the repository did not expose the core delivery loop as a callable skill. The easiest visible way to use STAGE was to create artifacts around the project instead of changing the project well.

The Circussy visual experiment made the inversion concrete. A detached capture pipeline and contact sheet were reproducible and validated, but they staged substitute content outside Unity and imposed a second review product. The useful result was the runtime Enemy Arrival preview: real content, animation, lighting, camera, and lifecycle were inspectable where the game already owned them. Even the in-engine Almanac is justified only while it shortens a recurring review loop.

This agrees with established human-computer interaction work. Mixed-initiative systems couple automation with direct manipulation; human-AI guidance values efficient correction and control; incremental formalization adds structure as use becomes concrete; coactive design emphasizes observability, predictability, and directability; and automation can increase supervisory and recovery burdens instead of removing them. STAGE should therefore begin with joint work on the actual game, not mandatory formalization around it.

Decision

• Add stage-deliver-change as the primary STAGE skill for features, fixes, refactors, tuning, content, feedback, tooling, and diagnostics.
• Make the plugin's default action delivery of one project-native accepted change through Frame -> Inspect -> Plan -> Build -> Rehearse -> Judge -> Checkpoint.
• Require no STAGE map, manifest, brief, receipt, dashboard, custom review surface, or export before ordinary delivery can begin.
• Read and preserve existing project maps and guidance when present. Create or deepen them only when repeated orientation, ownership, operation, or coordination cost earns persistence.
• Keep mapping, visual review, Visual Almanac construction, regression capture, and Evidence Export as explicit specializations with separate triggers.
• Prefer direct engine and game routes for rehearsal. If recurring visual review earns a persistent surface, prefer a project-owned in-engine development gallery or Almanac. Export only for a named consumer.
• Add no schema or mandatory completion artifact for ordinary change delivery. The conversation, project diff, native evidence, and authorized source-control checkpoint are sufficient unless a durable project need says otherwise.

Consequences

• STAGE can be used immediately on an existing game without first adopting STAGE files.
• The plugin now routes toward product work instead of documentation work by default.
• Formalization remains available but grows from observed pressure rather than preceding benefit.
• Existing visual and mapping contracts remain compatible, but they no longer define the main path through the method.
• A successful STAGE task is measured by an accepted, claim-matched change, not by the number of generated artifacts or tools.
• This correction is a design decision supported by one primary longitudinal case and established research lineage. It is not independent empirical proof that the workflow improves every team or project.