STAGE 0.3.0

Released: 2026-07-13

STAGE 0.3 is an operationally evaluated practitioner proposal for making game projects legible, operable, and credibly verifiable by humans and coding agents. It is not a claim of scientific proof, universal architecture, or autonomous game development.

Historical policy note: this release originally coupled version numbers to empirical adoption gates. ADR 0016 supersedes that policy for future releases. The evidence limits below remain valid; they no longer determine release-version compatibility.

Evidence Behind The Release

The release combines one origin study and four independent external studies:

Project	Project style	Strongest operation	Important boundary
The Circussy One	Systems-heavy Unity	Adopted map, full historical Unity gate, stable read-only refresh	Same director; runtime evidence predates the map-only 0.3 upgrade
Copperfall	Custom browser/canvas	Repeated browser lifecycle probe	No maintainer review or controlled change
Blopsqwash	Compact Unity/MonoBehaviour	Static package and serialized-binding audit	Exact Unity editor unavailable
Godot Open RPG	Godot Nodes/Resources	Exact-editor import and bounded headless runtime	One editor diagnostic; no controlled change
Fish Folk: Jumpy	Bones Sessions/worlds and Bevy renderer	Exact-toolchain formatting/metadata plus pinned CI	Local tests unavailable; hosted web observation inconclusive

These studies support project-native mapping, proportional map profiles, fail-closed ownership, scoped evidence, formal-source/rehearsal separation, and versioned artifact compatibility. They also challenged the original tendency to describe a systems-heavy Unity architecture as if it were a general target.

See Cross-Project Case-Study Synthesis and Evaluation, Readiness, And Transferability for the full evidence and limitations.

Normative Changes

• Make project-native vocabulary and architecture authoritative.
• Add compact, standard, and extended map profiles selected by coordination and change risk rather than repository size.
• Define operation state separately from operation documentation.
• Define evidence coordinates: class, provenance, scope, outcome, source revision, and effective toolchain.
• Define human, project-generated, external-generated, external-vendored, runtime, legacy, and unresolved ownership authorities.
• Require unresolved destructive authority to fail closed.
• Separate formal source from disposable rehearsal copies for mutation-prone external inspection.
• Require versioned manifests and explicit, reviewable migration.

Artifact And Tooling Changes

• Add frozen 0.1 and current 0.3 project-map and case-study schemas.
• Keep exact-version validation for both supported artifact generations.
• Add conservative 0.1-to-0.3 migration without silent in-place replacement.
• Add repository snapshots, external-trial refresh, semantic artifact hashing, Markdown-link validation, and a portable repository gate.
• Add cross-engine study records with revision, provenance, scope, toolchain, outcome, and limitation metadata.
• Update the stage-map-project skill for project-native inspection, proportional profiles, operational depth, read-only rehearsal, and accepted trial promotion.

Compatibility

Existing 0.1 manifests remain supported by exact-version validators. Their schemas are frozen and fingerprint-tested. Unversioned schema aliases point to 0.3 for new artifacts. Migration is opt-in and emits conservative review questions rather than inventing authority.

See Compatibility.

Evidence Limits At Release

STAGE 0.3 has external mapping breadth and repeatable operational evidence, but it does not have:

• an independently authorized STAGE-controlled change in two projects;
• correction and maintenance costs measured over repeated project changes;
• independent maintainer adoption;
• three materially different maintained projects using STAGE in practice;
• evidence that long-term benefit exceeds map and tooling maintenance cost.

Creating disposable experiments solely to inflate a claim would not answer those questions. Independent use remains necessary before making independent maintenance or longitudinal-productivity claims.

Release Verification

The release gate includes:

• all Python unit tests;
• JSON and YAML parsing;
• exact-version project and case-study schema validation;
• STAGE self-map validation;
• target-aware validation of all available external maps;
• repository-local Markdown links;
• Codex skill and plugin package validators;
• semantic stability across two Circussy refreshes;
• pre/post proof that the Circussy source repository remained unchanged;
• git diff --check, clean release state, tag verification, and remote revision verification.