0015: Require Fresh-Launch Parity

Status: Fresh-launch principle accepted; capability-manifest decision superseded by ADR 0026

Context

The Circussy One moved its visual review from a detached contact sheet into a generated Unity runtime scene. The first runtime host was still misleading: opening the subject through the editor catalog injected the authored Performer and enemy definitions, while playing the generated scene directly resolved no content profile and displayed fallback capsules. The host was engine-native, but its correctness depended on undeclared state left by another entry point.

This is distinct from Native Shell Substitution. The runtime host exercised the right engine systems; it simply did not own or explicitly receive everything needed to reproduce the same subject and presentation from a fresh session.

Decision

• Treat every declared available Almanac entry point as an independent launch contract.
• From a fresh engine or player session, the entry point must resolve the declared canonical subject, Scenario, Presentation Profile, and readiness state without hidden setup from another entry point.
• Persist required human-authored identity in project-owned configuration, or pass it through an explicit launch request. Do not rely on an editor window, static cache, prior preview, selection history, or retained runtime object to inject correctness.
• When several entry points address the same Scenario, compare subject identity, presentation identity, truth mode, temporal mode, and readiness. Mark a route partial or deferred when parity is not implemented.
• Make unresolved content and fallback geometry visible readiness failures.
• For every human or agent entry point claimed available, record and verify the applicable open, readiness, reset, and teardown lifecycle from a fresh session.

No visual-specific declaration is required. The ordinary project map and operating docs separate entry points, inspection modes, readiness signals, limitations, and lifecycle. The missing control was execution discipline, not another metadata interface.

Consequences

• Direct scene Play, development-player launch, editor launch, and agent launch can no longer be treated as interchangeable without fresh-session evidence.
• Runtime hosts must resolve canonical content during their own initialization or through an explicit request.
• Editor orchestration may remain useful for browsing and configuration, but it cannot be the invisible authority behind a separately declared runtime host.
• Capability declarations become slightly stricter without invalidating 0.1 through 0.3 compatibility manifests.
• A successful fresh-launch parity check remains mechanical evidence. Human visual acceptance is still required.