ADR 0048: Fold Visual Diagnosis Into Change Delivery

Status

Accepted.

Context

STAGE originally separated ordinary change delivery from a dedicated Visual Review skill. That separation was intended to protect production rendering, continuous motion, human visual authority, and consumer-complete inspection. In practice, those safeguards are not a separate job. They are claim-matched verification rules inside the same change loop used for input, audio, lifecycle, loading, and every other engine-bound concern.

The separate route also carried a recurring failure mode. The Circussy One visual-rehearsal experiment produced deterministic captures, videos, contact sheets, controls, and an external review page, but most of the output used placeholder or decontextualized content and did not help the owner improve the game. The useful result was a production motion preview. The owner's final assessment was stronger than a tuning request: an in-game or editor Almanac, gallery, or direct production route would have been easier and more useful than a parallel rehearsal product.

Later corrections retired the detached pipeline, moved persistent galleries back into ordinary project ownership, and made the Visual Review skill explicit-only. That reduced accidental routing but left two procedures for the same project-native loop. It also encouraged method work around deciding which skill owned a visible change.

A positive delivery probe against Lanternworks showed that the primary skill could already inspect a bounded player-facing request through the production UI, read model, and simulation boundary without inventing review artifacts. The remaining separate skill therefore did not own an independently recurring operation.

Decision

• Remove the packaged stage-visual-review skill.
• Keep stage-deliver-change as the single route for visual implementation, diagnosis, audits, and polish.
• Fold the minimum visual safeguards into that route: truthful project content, consumer-complete native context, continuous playback for motion, explicit human authority over taste, and capture only for a named portability or retention consumer.
• Keep docs/visual-review.md and engine-profile guidance as explanatory references, not as a second workflow or plugin route.
• Treat a concrete whole-project art audit, polish pass, or release review as legitimate ordinary work. Scope only outcome-free requests for standing coverage or generic review infrastructure before inventory.
• Treat an Almanac, codex, bestiary, gallery, model viewer, world previewer, or inspect mode as a normal game or editor feature when a player, author, or recurring developer independently needs it.
• Preserve historical Visual Review ADRs and trials as the evidence trail for this correction.

Consequences

• The installable Practitioner Kernel has one ordinary delivery skill and one explicit mapping skill.
• Agents no longer need to classify a visible task before entering the normal project workflow.
• Visual rules remain available where they affect implementation and evidence, while method-specific UI, galleries, and export surfaces remain unearned.
• Broad art work is not incorrectly rejected merely because it spans many assets; it still needs a concrete product or release outcome and protected ownership.
• Historical explicit-invocation advice for stage-visual-review applies only to releases that packaged that skill.

Evidence Boundary

This decision is supported by one same-owner failed workflow, repeated owner corrections, static overlap between the two packaged skills, and one positive read-only delivery probe. It establishes a simpler owner workflow for STAGE; it does not prove that specialized visual-review tooling is never useful in other teams or products.