Agent instructions: restore playable gameplay

Read this page, then the handoff and roadmap. The roadmap owns the milestone order; this page defines working rules and the first batch. Check the live source, Git status and current user instructions: earlier plans and dated reports may describe an older implementation.

Working rules

1. Continue the existing work. Use this working tree. Do not reset, clean, overwrite or stage unrelated changes. The latest commit may not include every current change. Preserve Assets/_Recovery, the archived Ability assets and normal player data.
2. Follow the selected scope. Build one common gameplay scene and finish the player/ability integration. Reuse existing enemy, spawner, reward, stage, menu and GameManager behavior; fix connections or actual defects. Do not redesign those systems to make the new scene.
3. Replace deliberately. For a system the owner has chosen to replace, first preserve its data, identifiers, serialized bindings and required behavior; then remove the old implementation and implement the new path without a legacy fallback. Note unfinished transfers and continue in connected batches. Intermediate breakage is acceptable. Systems that only need wiring fixes are not candidates for deletion.
4. Protect identity and authored data. Keep permanent backend ability codes, Upgrade IDs, stage/difficulty IDs, save and progression behavior, authored values and Unity asset references. Dash and character abilities need no new backend codes. Revive is an upgrade action. Upgrade stage eligibility remains configured on Upgrade assets.
5. Keep abilities independent. Ability metadata and specific behavior belong in AB_ code; behavior registers relevant hooks. Keep player state separate. Do not recreate AbilityHolder or a central per-ability factory. The owner wants final stat formulas visible in the central calculation.
6. Preserve stage differences. Use the stage comparison to carry generator tiles, ornament prefabs/weights and destructibles, camera background, tilemap material, volume profile and Stage 2 vignette, music, boss, spawners and progression. Do not copy old player sorting-layer differences merely to match the arenas; the owner said those can be ignored. Do not delete old scenes before their needed content is accounted for.
7. Work autonomously. Do not pause for each ability or ordinary implementation choice. Record a potentially better design or gameplay-changing decision for discussion, and continue independent work. Ask only when a missing decision prevents meaningful progress.
8. Verify honestly. Use the installed Unity Editor CLI for focused checks at coherent boundaries. Record what ran and its limits; compilation, Edit Mode fixtures and Play Mode/full gameplay are different. Do not claim an untested ability or stage is complete. Avoid repetitive checks when nothing relevant changed.
9. Preserve the environment. Before Unity CLI runs, capture package/settings bytes and protect normal profile/saves; after exit restore only changes Unity actually caused. See the CLI report and applicable Unity skill. Do not contact backend services or write to normal saves during isolated checks.
10. Keep communication and documentation short. Update the roadmap, handoff or existing evidence page when findings change. Do not commit, push or publish without an applicable user instruction. Do not create a second plan duplicating the roadmap.

First batch: common scene and one stage

Objective: connect production startup to the common Gameplay scene and prepare one selected stage. This batch alone does not establish a playable run.

1. Inspect git status, the current check report, Assets/Scenes/Gameplay.unity, Assets/Scenes/Arena Stage 1.unity, Assets/Script/Shared/ScriptableObjects/LevelData.cs, Assets/Script/Game/Stage/MapGenerator.cs, Assets/Script/Game/Stage/CameraController.cs, Assets/Script/Game/GameSystem/Bootstrap/GameInitializer.cs, and the menu start/retry callers. Inspect Unity serialization and prefab overrides where necessary.
2. Use the common scene for one production setup: camera, tilemap, ornament parent, player slots, existing managers, pool, spawner, timer, HUD and the Stage 1 menu/controller/gate bindings. Choose one startup owner; do not run both development and production initializers independently.
3. Add the selected stage's map and appearance settings to LevelData or a serialized structure owned by it. Initialize the existing camera-following generator before it produces tiles. Preserve exact old generator settings, weights and destructibles. Resolve whether the old painted tiles are needed instead of assuming they are disposable. Do not invent a separate stage asset system.
4. Apply camera background, tilemap material and the appropriate volume profile; Stage 2's vignette must be configurable and Stage 1/3's normal bloom/color effects retained. Check actual Unity material/shader and volume bindings. Reset map objects and appearance across retry or stage changes.
5. Route selection and retry to the common scene while preserving the selected LevelData, difficulty and existing progression/reward IDs. Make minimal changes to existing callers. Preserve the saved input data and implement the minimum new-input connections required for the first playable path; complete remapping/persistence later in the roadmap.
6. Run an appropriate bounded Unity CLI import and focused integration check when the batch is coherent. Fix errors attributable to this batch, and document exactly what was observed. If a real scene start or a required part is not yet possible, identify the concrete blocker and continue the next useful part; do not present a partial fixture as a full playthrough.

Details that must not be missed

• Gameplay.unity is not currently in ProjectSettings/EditorBuildSettings.asset. Add it to the applicable build scene list when routing production entry to it, preserving the other entries and settings; inspect relevant build-profile overrides. A project import alone does not prove LoadScene can load it in a player build.
• MainMenuManager and GameMenuManager currently load LevelData.sceneName on start and retry. Change both paths consistently and retain the selected stage and difficulty. Preserve the existing Experimental and Tutorial routes. Do not route a selectable stage to incomplete or missing stage configuration without recording and addressing that gap.
• MapGenerator.Start currently calls GenerateMap immediately and calculates ornament weights afterward. Ensure selected configuration, references and weights are ready before the first generation. Its transform.position is the generation center, so preserve its camera-follow behavior. Inspect authored tile contents before removing them; clear generated tiles, ornaments and caches when reusing the generator.
• The shared scene's existing run host is a development foundation, not an automatic production startup: it owns activation of an initially disabled camera and environment. Trace its activation and the existing GameInitialization/GameManager startup together; establish exactly one owner, correct readiness and stop/reset order, and keep required serialized references intact.
• Existing RunSceneChecks and StageProgressionChecks contain assumptions about the development-only scene or separate arena paths. Re-scope affected checks to the new intended behavior, preserving meaningful assertions; a previous passing fixture does not verify the production scene.
• Before removing legacy input routing, inventory its player, UI, settings and Tutorial consumers and preserve binding data. Move the required consumers into the new system and remove their old delivery without duplicate actions or a permanent fallback. Retain any unrelated responsibilities until they have an owner.
• Do not assume /tmp logs or compatibility libraries persist across chats or computers. The project-local Git and Unity skills are portable copies; the original machine's canonical sources remain in the owner's personal skill workspace. See other-PC setup.

First-batch acceptance: the selected stage's configuration and common scene are connected, the scene can be selected for a build, and a bounded check reports whether the real start and retry paths work. If these checks are not possible, record the missing connection or error and continue the next independent integration task; do not label the game playable.

After this batch, follow the roadmap: connect combat and spawning, trace a reward through an ability to an enemy, then expand stage, input and ability coverage. Work in groups without restarting the audit.