Skip to main content

STAGE 0.5.0

Released: 2026-07-22

STAGE 0.5 tightens the practitioner interface around the work that survived dogfood: change the real game through its canonical sources, exercise the production consumer that owns each material claim, let the human judge product quality, and checkpoint the accepted result. Mapping, dedicated visual diagnosis, galleries, automation, and evidence packages are capabilities to add for a demonstrated need, not setup stages to complete in order.

It remains an operationally evaluated practitioner proposal. This release does not claim scientific proof, independent adoption, autonomous game development, or general productivity gains.

Why This Release Exists​

The 0.4 Practitioner Kernel removed mandatory artifacts, but the surrounding skills and guidance could still pull ordinary work back toward project maps, custom review surfaces, contact sheets, or capability ladders. Dogfood made the remaining inversion visible:

  • The Circussy One's detached visual rehearsal rendered mechanically valid substitutes that were less useful than the existing game and Unity views.
  • Its one useful motion example succeeded because it composed a coherent native state sequence, not because it lived in a separate evidence package.
  • Lanternworks exposed a different gap: a command could be mechanically wired yet remain undiscoverable to the player. Reachability alone did not prove affordance or comprehension.
  • Codex could continue loading a cached plugin package after repository guidance changed, so repository correctness did not guarantee task-level behavior.

STAGE 0.5 turns those observations into a smaller and more explicit public workflow.

Normative Changes​

  • Canonical project sources and ordinary engine tools satisfy human-facing authoring requirements; a custom GUI is not required.
  • Runtime and authoring state material to a claim must be inspected when it is available. When it is unavailable, narrow the claim instead of manufacturing a persistent inspection surface.
  • Machine-readable project metadata is need-triggered rather than a universal project requirement.
  • Practitioner Kernel, mapped-project, operational, and evaluated-reference claims are independent capability descriptions, not maturity grades.
  • A player-facing action separates mechanical reachability, affordance on the production surface, and human acceptance of comprehension or feel.

See SPEC.md and ADR 0033.

Practitioner Interface​

stage-deliver-change remains the ordinary route for features, fixes, refactors, tuning, content, UI, audio, VFX, worlds, diagnostics, and tooling.

The companion skills are explicit-only:

  • stage-map-project is for a deliberate adoption, onboarding, audit, or map-maintenance request.
  • stage-visual-review was the release-era route for a deliberately bounded visual question or diagnosis through the native engine. It was later retired by ADR 0048.

One-off visual acceptance stays in the co-located editor or game. Screenshots and videos are optional transport for a named consumer. When recurring visual inspection genuinely deserves persistence, first improve a useful in-game gallery, codex, bestiary, model viewer, world previewer, or editor inspection mode that operates on real project content.

Compatibility And Upgrade​

STAGE 0.5 does not introduce a project-map or case-study schema. Exact artifact versions 0.1 and 0.3 remain supported, so mapped projects need no migration.

The plugin package version is 0.5.0; SPEC.md is method version 0.5. Manifest field stage_version remains an artifact schema selector and is not a method-release number.

Codex caches installed plugin packages by version. After pulling this release, reinstall from the configured local marketplace and open a new task:

codex plugin add stage-game-engineering@stage-local
codex plugin list --marketplace stage-local

The list output must report 0.5.0. An already-open task retains the skill snapshot with which it started.

Evidence And Limits​

Evidence through this release includes the longitudinal Circussy origin case, four cross-engine mapping studies, same-owner Lanternworks changes, the Solo Unity dependency and player operations, and repeated deletion of infrastructure that did not shorten the project-native workflow.

This supports the owner's operational use, proportional project mapping, consumer-boundary reasoning, fail-closed ownership, and correction of infrastructure-first and evidence-first inversions. It does not establish independent maintenance outcomes, long-term productivity, team-scale governance, universal fit, or visual-quality automation.

Release Verification​

The release gate validates:

  • all Python unit suites and frozen-schema fingerprints;
  • every supported project map and case study;
  • the STAGE self-map and its declared target paths;
  • repository-local Markdown links and diff hygiene;
  • all Codex skill packages and plugin metadata;
  • alignment between method, package, changelog, and release-note versions; and
  • the optional Solo Unity catalog, bundles, recipes, bootstrap, transfer, checkpoint, player-build, and player-launch contracts.

The installed Codex package is verified separately because an open task cannot replace its own loaded skill snapshot.

Last updated on