STAGE 0.5.9

Released: 2026-07-22

STAGE 0.5.9 makes route rejection a pre-orientation control boundary and separates preservation from implementation authority. It keeps the 0.5 Practitioner Kernel and every supported artifact schema compatible.

Why This Patch Exists

STAGE 0.5.8 required an agent to stop optimizing a route after the human rejected its utility. Its first installed-plugin probe showed that stopping the named route was not enough. The agent refused to keep polishing a detached contact-sheet exporter, then searched another project broadly for a way to continue. It could not find the accepted Enemy Arrival fragment and mapped that phrase onto an unrelated Route Flow Motion scenario.

The first 0.5.9 candidate prevented that analogy in its answer but still ran a status check and three repository searches. Those operations did not protect state or answer a product question. They only reopened the rejected branch and consumed context.

Changes

• Classify route utility rejection before detailed project orientation, repository inspection, or tool operation.
• Define an accepted observation, artifact, behavior, or implementation fragment as a preservation constraint, not authority to extend, port, recreate, substitute, or analogize it.
• Treat generic instructions such as "continue" or "keep working" as momentum, not replacement scope.
• Require a zero-inspection rejection response when no cleanup, retirement, reversion, or damage-prevention action is authorized.
• Apply the rule to all three self-contained plugin skills and their ingestion prompts.
• Record the failed 0.5.8 and intermediate 0.5.9 probes in the Failure Atlas, evaluation record, and ADR 0044.

Practitioner Impact

When the human rejects a route's utility:

1. classify the correction before inspecting the project;
2. stop that route;
3. preserve explicitly accepted results without treating them as new scope;
4. run a tool only when an authorized cleanup or state-protection action actually requires it; and
5. otherwise ask at most one concrete outcome question and end the branch.

This prevents a technically successful but unwanted workflow from returning as a smaller package, a nearby feature, or a semantic analogue.

Compatibility

The plugin package version is 0.5.9; 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;
• focused regression checks for pre-orientation rejection and preservation-without-authorization; and
• a fresh installed-plugin read-only probe whose trace contains four events, zero commands or tools, no repository inspection, and one concrete native outcome question.

The probe left Lanternworks clean at revision 541b2747096bb358daeff31b5d21994421582498.

Limitations

The motivating history and behavior probes come from one owner using one model across two same-owner projects. The result demonstrates executable behavior for the tested prompt. It does not prove reliable classification of ambiguous feedback, independent adoption, or broad productivity improvement.