Batch 30 · Shared gameplay scene, events and dependency order

2026-10-26. Owner-requested planning update, following clarification that Player, AbilityHolder and the input rebuild are not implemented. No gameplay/source/scene/prefab/package changes, Unity run, commit or push in this batch. Preserve mechanics, earlier stabilization evidence and pending unrelated files.

Recorded decisions

IDEA-20 records the owner's shared-scene proposal. The recommended target is one gameplay runtime scene plus stage ScriptableObject configuration and environment/behavior composition. Current LevelData already contains part of that data; the three arenas repeat the main run owners but have different migration/wiring state. Stage SOs must not become shared mutable run state or hold live scene-object references. Actual scene differences, existing save/progression identity, stage timing and authored appearance must be accounted for before old scenes retire.

IDEA-21 records the earlier event-bus intention and current source evidence: GameEvents already has five static event declarations, and GameStateService has an instance state event. The plan calls for typed facts, explicit application/run scopes, owned subscriptions and identity/order/reset rules, with compatibility adapters. Direct input/movement/damage/upgrade commands retain an authoritative owner. This is a design direction, not a new messaging implementation or evidence that every current subscriber is faulty.

Dependency correction

The sole work-order plan now separates ability runtime (R4a), weapon/attack execution (R4b), concrete skills/companions (R4c), enemy behavior (R5a) and stage composition/encounters (R5b). Stable run/data/lifetime and minimum events/shared scene come first, then player setup/input and movement/vitals/stats. AbilityHolder's state API comes before concrete skill migration. Player/AbilityHolder responsibilities move together where dash/resource ownership would otherwise become cyclic; a minimal admission boundary is enough before the complete ability runtime.

Stage schema/event lifetime rules are designed early, while full environment/schedule migration and per-system event consumers follow their dependencies. A dummy-stage request uses the shared gameplay runtime; there is no second gameplay-manager implementation for tests. Development-only launchers/data remain excluded from production dependencies even when the shared runtime scene ships. Minimal remap persistence, assignment UI, feedback and capability adapters ship with their owning slice; final UI/service integration does not postpone those prerequisites.

The run/bootstrap contract was reconciled with those requirements and its stale next-combat instruction updated. The combat contract's incorrect R3 combat phase labels now agree with R4a–R4c and F3 in the main plan. Initial audit counts/historical batch evidence are not retroactively relabelled as runtime verification.

Remaining work

R0 stays open. Next is the detailed stage/enemy/encounter and content-authoring contract: actual scene/prefab overrides, shared stage/environment binding recipe, enemy/state/spawn/death/drop flow, and event producer/subscriber/payload/order/lifetime maps. Then complete reward/progression, persistence/input schema and production UI/service contracts and the exact first implementation slice. Tutorial and GAME-01 remain parked. This update does not authorize implementing the architecture before the design gate closes.

Verification

Validate the existing 608 gameplay pins, unchanged runtime/settings/package workspace status, local documentation links and new anchors, seven updated/new documentation files, phase/fixture consistency, whitespace and all 52 issue IDs routed once. Source inspection covers the named event declarations, current scene wiring map, LevelData/GameSession/SpawnerData, stage loading/retry consumers and representative event subscribers. This is static/source-backed planning evidence, not a Unity test or a complete per-stage migration audit.

Validation passed: all 608 gameplay pins match; runtime/settings/package workspace status and HEAD are unchanged; all seven documentation paths exist and pass whitespace checks; 517 local links and seven references to the new idea anchors resolve; 21 unique idea entries and all 52 existing issue IDs remain consistent. The R0–R9 order and R4/R5 subdivisions agree across the updated contracts. Existing GameEvents declares five static events, and the three arena maps each contain the seven shared run-owner types cited above. No Unity/build result is claimed.