Skip to main content

STAGE 0.4.0

Released: 2026-07-21

STAGE 0.4 makes its simplest successful workflow normative: deliver one real game change through the project's own architecture and toolchain, verify each material claim through its production consumer, leave experiential judgment to the human, and checkpoint only an accepted result.

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

Why This Release Exists​

STAGE 0.3 required project maps and encouraged durable evidence as part of core conformance. Subsequent dogfood repeatedly showed that those artifacts can invert the work: agents build maps, receipts, galleries, and audit machinery while the actual game still needs direct inspection and human judgment.

The strongest counterexample was The Circussy One's detached visual pipeline. It generated valid contact sheets and motion artifacts but mostly rendered substitute subjects outside the production game. The useful result was the one coherent Enemy Arrival sequence. Direct Unity inspection and project-native runtime surfaces answered the real questions more cheaply and truthfully.

The Solo Unity profile produced the same lesson in non-visual form. Its useful parts inspect, apply, launch, or verify real dependency and player state. Its assessment, attestation, slice-charter, normalized-test, and duplicate provenance layers only described checks that Unity, Git, or the owner still had to perform.

Normative Changes​

  • Define the Practitioner Kernel as the artifact-free minimum for one material change.
  • Make STAGE.md and .stage/project.yaml requirements conditional on an explicit mapped-project conformance claim.
  • Require the smallest consumer-complete verification route for each material claim. Focused tests remain complete for focused claims; input, middleware, lifecycle, loading, visual, and platform claims must include the material production path.
  • Make Earned Infrastructure normative. Persistent tools, abstractions, operations, evidence artifacts, and product surfaces require recurring cost, ownership risk, or a named consumer.
  • Keep visual runtime truth in the production renderer and relevant engine or player context. Captures and exports are optional transport; identified human judgment remains authoritative for visual and experiential quality.
  • Separate method release versions from artifact schema versions.

See ADR 0032.

Practitioner Interface​

The plugin now leads with stage-deliver-change. It does not require setup artifacts. The optional skills remain:

  • stage-map-project when repeated orientation, ownership, or operation cost earns durable guidance;
  • stage-visual-review for one bounded visual question through the smallest consumer-complete native route. That release-era skill was later retired by ADR 0048.

The repository documents a separate Maintainer Laboratory for schema compatibility, studies, migrations, the personal Solo Unity profile, and release verification. Games do not adopt that laboratory by default.

Retired Experiments​

The following pre-1.0 experiment families are no longer supported public interfaces:

  • detached visual request, capture, contact-sheet, comparison, and receipt packages;
  • Visual Almanac capability manifests and the separate Almanac skill;
  • Solo Unity assessment and attestation records;
  • Solo Unity slice charters;
  • generic normalized Unity test receipts;
  • redundant clean post-commit dependency-provenance receipts.

ADRs 0025 through 0031 preserve the reasons, consequences, and narrower surviving operations. Git history preserves the removed implementations.

Compatibility​

STAGE 0.4 does not introduce a new project-map or case-study schema. Tooling continues to accept exact artifact versions 0.1 and 0.3. Existing mapped projects do not need migration, and projects using only the Practitioner Kernel need no STAGE artifact at all.

The plugin package version is 0.4.0; SPEC.md is method version 0.4. Manifest field stage_version remains the artifact schema selector.

Evidence And Limits​

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

This supports owner-operational use, project-native mapping, consumer-boundary reasoning, fail-closed ownership, and the proportionality correction. It does not establish independent maintenance adoption, long-term productivity gains, team-scale governance, or universal fit.

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 the plugin manifest;
  • the optional Solo Unity catalog, bundles, recipes, bootstrap, transfer, checkpoint, player-build, and player-launch contracts.

Exact test counts and the protected Circussy source invariant are recorded in the release commit and verification output rather than promoted into empirical quality claims.

Last updated on