STAGE 0.5.8

Released: 2026-07-22

STAGE 0.5.8 makes explicit human rejection of a route's utility executable control flow. It keeps the 0.5 Practitioner Kernel and every supported artifact schema compatible.

Why This Patch Exists

The Circussy visual-rehearsal experiment eventually produced working native captures, motion, and a detached contact sheet. The owner then made a stronger judgment than "improve this result": the detached route itself was not useful. The native game or editor was a better place to inspect the work, and an Almanac would be justified only as an ordinary project feature with its own player, author, or developer value.

STAGE already allowed rejection and made blocked workflow branches terminal. It did not state clearly enough that a technically functional route can be rejected for lacking utility. Without that distinction, sunk cost can turn "this workflow is not worth continuing" into another polish pass, a smaller package, or a renamed version of the same system.

Changes

• Define route utility rejection as explicit human judgment that a workflow, evidence surface, artifact, or supporting system is not useful for its intended decision.
• Require optimization of that route to stop even when its implementation is mechanically functional.
• Permit only explicitly accepted parts to move into a materially different project-native route.
• Require one concise discriminating question when feedback is genuinely ambiguous between implementation tuning and route utility rejection.
• Record the visual-rehearsal sunk-cost failure in the Failure Atlas and ADR 0043.
• Apply the executable rule to all three self-contained Codex skills and their ingestion prompts.
• Record a positive 0.5.7 routing probe showing that an independently useful player Almanac remains ordinary project work rather than forbidden review infrastructure.

Practitioner Impact

Use ordinary tuning when the human still wants the selected route and asks for a better implementation. When the human rejects the route's usefulness:

1. stop optimizing it;
2. preserve project state;
3. carry forward only explicitly accepted parts;
4. retire, revert, or materially reframe the remainder; and
5. require new explicit direction before reviving a narrower or repackaged version of the same route.

This rule applies to code, tools, review surfaces, evidence workflows, authoring systems, maps, and other supporting infrastructure. It does not turn ordinary negative feedback into route rejection.

Compatibility

The plugin package version is 0.5.8; 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.

Verification

The release is checked through:

• the complete STAGE release gate;
• direct Codex plugin and all skill-package validators;
• repository-local project-map, case-study, schema, and Markdown-link validation;
• cross-skill regression checks for the terminal utility-rejection wording; and
• a fresh installed-plugin behavior probe in which a technically working supporting workflow is explicitly rejected as useless and must not return as another tuning pass or smaller substitute.

Limitations

The motivating failure comes from one long-running owner workflow. The rule protects human product authority and makes sunk-cost behavior observable; it does not prove that models will always classify ambiguous feedback correctly. The one-question ambiguity branch remains necessary.