STAGE 0.5.12

Released: 2026-07-22

STAGE 0.5.12 removes the redundant dedicated visual-diagnosis route. Visual implementation, diagnosis, audits, and polish now use the same project-native delivery workflow as every other game change. The useful visual safeguards remain; the parallel workflow does not.

Why This Patch Exists

The Circussy One visual-rehearsal experiment produced deterministic captures, videos, contact sheets, controls, and an external review page. Most of that output was decontextualized, placeholder-driven, or less useful than inspecting and improving the real game. The useful result was a production motion preview, which belonged in the ordinary engine-native change loop.

Making the visual skill explicit-only reduced accidental routing, but retained two procedures for one operation. A later delivery probe against Lanternworks also showed that the primary skill could already inspect a bounded player-facing request through its production UI, read model, and simulation boundary without inventing review infrastructure.

Changes

• Remove the packaged stage-visual-review skill.
• Keep stage-deliver-change as the single route for visual implementation, diagnosis, audits, and polish.
• Preserve truthful project content, consumer-complete native context, continuous playback for motion, human visual authority, and consumer-gated capture as delivery evidence rules.
• Keep concrete whole-project art audits, polish passes, and release reviews as valid ordinary work.
• Scope only outcome-free requests for standing review coverage before broad inventory.
• Keep an Almanac, codex, gallery, bestiary, model viewer, world previewer, or inspect mode in the normal project backlog when it serves an independent player, author, or recurring developer need.

Practitioner Impact

The installable Practitioner Kernel now exposes two skills: implicit ordinary change delivery and explicit project mapping. A visible task no longer needs a route classification before work begins. The agent still has to use real project-owned content and the smallest native route that contains the production consumer and every material presentation dependency.

Screenshots and video are not default proof. Leave the correct live engine view or playback ready for a co-located owner, and export only when a named remote, comparison, CI, audit, release, or retention consumer requires an artifact.

Compatibility

The plugin package version is 0.5.12; SPEC.md is method version 0.5. Project-map and case-study artifact versions 0.1 and 0.3 remain supported. No game-project migration is required. Existing explicit invocations of stage-visual-review must be removed; the equivalent work now enters through ordinary change delivery.

Verification

The release is checked through:

• the complete STAGE release gate;
• direct Codex plugin and both skill-package validators;
• repository-local project-map, case-study, schema, and Markdown-link validation;
• focused routing and packaging regression tests; and
• fresh installed-plugin behavior probes recorded after candidate installation.

The pre-release positive-routing probe used the installed 0.5.11 package with gpt-5.5 against clean Lanternworks revision 541b2747096bb358daeff31b5d21994421582498. It treated a player-facing HUD question as ordinary delivery, inspected the production UXML, presenter, read model, and simulation rule, and declined to invent a fuel-cost display when no fuel-cost rule existed. The target repository remained unchanged. The trace was semantically useful but laborious: 32 action calls across 77 events. It is evidence that the primary route can own bounded visual diagnosis, not a latency or token-efficiency benchmark.

The installed 0.5.12 candidate was then invoked explicitly through stage-game-engineering:stage-deliver-change against the same clean Lanternworks revision using gpt-5.5 and Codex CLI 0.142.5. Given a bounded gameplay-distance route-flow readability question, it traced the production Almanac composition, projection, world view, animation, materials, and camera; identified the small same-color moving marker as the likely risk; and ended at one concrete Unity Game-view observation. It did not edit the project, export captures, or create detached review infrastructure. The trace contained 161 events, 72 action calls, and 1,198,667 aggregate input tokens. This is a semantic routing and evidence-scope pass, not an efficiency result, and live Unity visual judgment was not performed by the read-only probe.

The 0.5.12 rejection probe explicitly rejected the detached rehearsal and contact sheet without authorizing cleanup or a replacement. The installed delivery skill stopped the route, proposed no analogue, inspected no target files, and asked one outcome question. Its trace contained seven events, one action call used only to read the selected installed skill, and 40,609 aggregate input tokens. It therefore passes the semantic rejection boundary but not a literal zero-action ceiling. Lanternworks remained clean and unchanged after both probes.

An earlier ambient positive probe was excluded from candidate evidence because the host injected the generic diagnose skill rather than the installed STAGE skill. Its useful answer does not establish behavior of the 0.5.12 package.

Limitations

This correction is based on one owner's failed workflow, repeated owner feedback, static procedure overlap, and model-bound behavior probes. It does not prove that specialized visual-review tooling is never useful. Teams with a named remote-review, comparison, CI, release, or retention consumer may still need project-owned capture or review systems. STAGE simply no longer treats that infrastructure as a universal companion workflow.