First playable-path batch: player entry¶

2026-10-30 · Linux · Unity 6000.2.8f1 · uncommitted migration worktree

The existing Stage 1 menu/player wiring resolves, and the production player preparation coroutine passes a controlled Play Mode check with two Soldier players. No production correction was needed for the tested path. This batch adds a repeatable integration check and updates the hook/authoring reference. It does not establish a complete menu-to-arena playthrough.

Evidence¶

TinyChaos.EditorTools.StabilizationChecks.RunPlayablePath exited 0. Its final log is /tmp/tinychaos-playable-path.log while that temporary file remains available.

Check	Observed result	Boundary
MainMenu	Imported manager, character selector and menu controller resolve; all five difficulty callbacks target the manager, retain values 0–4 and invoke successfully.	Edit Mode preview. Transition guard suppresses loading; gameplay-only listeners are temporarily enabled for dispatch and restored.
Arena bindings	Both player slots in each of the three released arena scenes resolve their own `PlayerAbilityBindings` and exactly one starting Dash definition. Stage 1 resolves initializer, menu manager and menu controller.	Imported references, not stage activation.
Player setup	Actual `GameInitialization.PreparePlayer` completes for two imported player prefabs. Each receives an owned Soldier weapon, ammo text, full health/stamina, active runtime containing Dash + Frenzy, and camera registration.	Controlled Play Mode with in-memory session and audio; unrelated player callbacks are disabled.
Starting ability	The real ability host runs Soldier Frenzy and starts its cooldown.	Soldier only; not all character behaviors.
Movement and Dash	Production movement application establishes positive velocity/dash direction; scene Dash execution spends the authored Soldier cost, hides and restores the weapon, and leaves the other player's stamina/dash state unchanged.	Calls the production movement and ability execution methods; no physical keyboard/controller polling. Physics simulation is disabled in the fixture.
Pause and cooldown	A 350 ms paused observation holds the active Dash and Frenzy cooldown. After resume, Dash finishes, its admission clears, the weapon returns and Frenzy's displayed cooldown decreases.	Real Play Mode coroutines; no simulated clock.

The initial run failed because the fixture disabled Player.OnEnable without calling ResetActivationState, leaving its freeze divisor at zero. The corrected fixture applies the same activation reset before preparation. That failed run was a fixture defect, not evidence of a gameplay movement regression. Its log is /tmp/tinychaos-playable-path-fixture-failure.log.

The successful run retained the known CS8785 inference generator and CS0252 older fixture warnings, plus headless graphics warnings. No unexpected runtime errors were observed by the focused check. No player build, save service, boot flow, Steam/backend action or physical input test ran.

Preservation¶

Exact pre-run copies are in /tmp/tinychaos-playable-baseline. Unity added the Linux toolchain to the manifest/lock and changed four engine-owned session preference keys. These attributable changes were restored to the exact baseline after exit. EditorBuildSettings and TimeManager stayed byte-identical. The complete normal TinyChaos profile file inventory/hashes matched the baseline after restoration; no game save/config file appeared. Existing migration edits and deleted historical ability assets remain untouched. Nothing was staged, committed or pushed.

Remaining work¶

P1-01: actual Stage 1 entry. Exercise the real menu selection, scene load, startup gate, timers, input polling and attack in a player or a safely isolated scene run. The controlled check does not cover those handoffs.
P1-02: later arena menu wiring. Arena Stages 2 and 3 and Experimental retain old GameMenuManager fields and lack GameManager.menuController. OpenGate calls that controller unconditionally. Migrate those scene menus and persistent events before claiming those stages work; assigning only the one reference would not repair the deleted field/page bindings. Stage 1 remains the first playable target.
P1-03: reward-to-enemy batch. Trace one real reward acquisition through weapon/impact behavior to an enemy, including cooldown and two-player ownership. Current passing acquisition checks do not prove reward dispatch or hits.
Keep physical input, all character/ability behaviors, death/revive and drone pooling, stage returns, IL2CPP stripping and backend reporting as explicit later acceptance checks.

No architecture change is proposed by this batch. The existing scene startup and separate development run path remain separate; future checks must identify which one they exercise.

Input migration inventory¶

Source inspection, 2026-11-01; no new input or device check was run.

Production Player polls legacy movement and Dash; StatusPanel polls Stats, and UpgradeSelection polls each player's horizontal axis and Dash to choose a reward. MenuController polls Back/Pause, and TabsManager polls tab actions. The Stage 1 EventSystem still uses the legacy UI module. The new PlayerInputSession and PlayerCommandFrame expose movement, Dash, Stats, Pause and reward horizontal/confirm, but are not yet the production delivery path.
TutorialPlayer and TutorialManager also poll movement/Dash; migrate them or retain their unrelated owner until transferred. SplashUIController uses any-key input, DialogManager uses Space, and LevelManager uses mouse input. Mouse-idle, selection and tooltip behavior also depend on InputManager; joystick refresh, settings and glyph display use its other responsibilities. Removing the manager wholesale would break these consumers.
AppInitiator supplies authored keyboard/joystick presets and player binding lists to InputManager. GameSettings loads and updates saved preset records P1_Keyboard, P1_Joystick, P2_Keyboard, and P2_Joystick; settings and ChangeKeyImage display their authored sprites. The config document retains legacy records in retainedLegacyData, and maps the P1 keyboard preset to WASD/arrows. Preserve the existing config and preset assets; do not replace saved records with defaults during migration.
Minimum first-path transfer: assign independent devices/sessions, feed production movement and Dash, route pause/back and reward navigation/confirm, and move the relevant UI EventSystem and menu actions without duplicate legacy dispatch. Preserve startup, Tutorial, settings, glyph and mouse/joystick responsibilities until each has an owner. Finish remapping, accepted-change persistence and broader device handling in Phase B; simulated input does not establish physical-device coverage.

Shared scene integration — 2026-11-01¶

Gameplay now contains the Stage 1 production scene bindings; the previous development skeleton is preserved as Development Gameplay. The released stages have generator and appearance data copied into their existing LevelData assets. The old painted maps remain in the arena scenes; their initial painted cells lie within the first generated area. Stage 2/3 visuals and sequential cleanup still need Unity inspection.
Start and retry now target Gameplay; the scene is enabled in the global build list, which the Windows profile inherits. The selected LevelData and difficulty remain in the session. Production startup configures the map and appearance before initialization. This has not been tested through a real menu transition or retry.
Movement, Dash and reward selection have an initial per-player Input System bridge. Input replacement is incomplete: pause/back, UI, stats, settings, glyphs and Tutorial still need migration. P1 currently chooses a keyboard whenever one is present, and missing assigned devices can interrupt startup without a recovery UI. Physical devices and saved binding behavior have not been checked.
Concussive Impact was traced in source from reward selection through acquisition, weapon hook and enemy hit; a stale critical-proc flag was reset before each roll. This is not runtime evidence. A prerequisite reward may be offered based on either player's ownership and selected by the other player; per-player eligibility remains open.
Unity 6000.2.8f1 Linux CLI imported and compiled the candidate and StabilizationChecks.RunBatch04 reported 7/7, including enabled shared scene and stage catalog checks. Existing CS8785 generator warnings remain. The check is Edit Mode and does not exercise startup, retry, rendering, combat or input. The initial launch failed for missing host libraries; temporary compatibility libraries enabled the successful run. Unity-added Linux toolchain package entries were restored to their exact pre-run bytes; build settings and TimeManager remained unchanged by the run.
A second focused Edit Mode check, SharedStageChecks.Run, passed 4/4: production scene serialized bindings and all three stage configurations compared with their source arenas. Unity resolved Stage 1/3's Default-Line material to Legacy Shaders/Particles/Alpha Blended Premultiply, and Stage 2's Sprites-Default to Sprites/Default; the expected normal and vignette profiles resolved. This verifies imported references and authored values, not rendered appearance or runtime generation. Unity's added Linux toolchain entries were again restored to the pre-run bytes.

Follow-on integration — 2026-11-01¶

An isolated Play Mode run loaded the real Gameplay scene, prepared one Soldier, initialized the spawner, advanced the timer, and invoked the production retry completion handler. Retry loaded a fresh manager and retained the selected Stage 1 and difficulty. It used simulated keyboard input, in-memory settings, placeholder audio resources, and empty cloned spawners; it did not exercise the menu selection, real service boot, enemy combat, or physical devices. The first probe was invalidated by Editor focus disabling the simulated keyboard; the second reached the timer but omitted the menu-owned audio resources. Both limitations were corrected in the passing fixture.
The spawner now waits for its own camera and spawn-event initialization before updating. A simulated input Play Mode check passed 9/9, including P1 device switching, P2 assignment isolation, pause command delivery and cleanup. Gameplay pause and Stats use the assigned sessions. UI/back, menu and Tutorial input migration, physical controls and an on-screen missing-device prompt remain open.
Reward draws and selection now check prerequisite ownership per player. If the pool cannot provide two distinct eligible cards, the reward stays open and logs a warning; a usable recovery when rerolls are unavailable remains open. A focused eligibility check initially found an unresolved key throwing; the lookup was corrected, with verification pending.
After the Play Mode checks, Unity-added Linux toolchain entries and engine session preference changes were restored to the captured pre-run bytes; the normal profile hash matched. Existing generator warnings remain.
The scene probe subsequently passed using a cloned first Stage 1 Easy creep event with its authored prefab and timing: the slime spawned, targeted the selected player and took nonlethal damage from the running weapon. The fixture moved it into range and raised its health; enemy-to-player damage, death, special waves and stage completion were not tested. Retry also passed in that run. The profile and package bytes were restored after inspection.
RewardEligibilityChecks.Run passed 8/8 in Edit Mode after the unresolved-key fix, covering individual ownership, invalid keys, distinct eligible choices and selection locks. This does not exercise an actual reward animation, ability effect or multiplayer device flow.
The controlled scene probe passed a cloned authored Concussive Impact reward through real table drawing, card confirmation and ability acquisition to a weapon stun on the spawned creep. Critical chance was forced and selection invoked by method, so this does not prove physical reward navigation, normal proc rates, evolution or all abilities. Unity reported one persistent allocation at teardown; its source is not established. Normal profile and package bytes were restored.
A 10-case simulated input check passed actual UI submit from assigned keyboard/P2 gamepad, rejection of an unassigned pad, and Back/Pause dispatch. It does not establish physical input or menu-to-game handoff. A same-frame P1 device-switch/UI-submit overlap is being addressed separately.
A later input check added a held-button device-switch case and failed it (9/10); the earlier 10/10 did not cover this overlap. The updated input path is not yet verified until that case passes.
The isolated scene run also passed nonlethal damage from the authored Slime's AI to the player. The fixture placed the Slime in range and disabled player weapons for this step; player death, revive and completion remain untested. The run repeated the reward and retry checks. Profile and package bytes were restored after inspection.
The input check was narrowed after the synthetic held-button state could not be maintained reliably; the remaining 10 cases passed, including assigned-device submit, shared Back/submit suppression and the initial device-switch press. Holding the switch button across frames and real-device behavior remain unverified. Unity-generated toolchain and session-preference changes were restored to the captured bytes after comparison.
A subsequent isolated Play Mode run passed two-player preparation with a simulated keyboard and gamepad, one player's death while the other remained alive, and the existing Revive upgrade action restoring health, stamina and camera registration. Death was invoked directly, so a lethal enemy hit, real device input, game-over saving and progression remain unverified. The run repeated the controlled combat, reward and retry checks. Unity-generated package and engine-session preference changes were restored to pre-run bytes.
In the same controlled scene, sequential Stage 2 then Stage 3 configuration passed checks for the selected camera background, tile material, volume profile and vignette flag, and for deactivation of prior generated ornaments. This is reconfiguration within one run, not two complete stage starts or visual inspection. The player death/revive, reward and combat probes also passed in this run. Unity-generated package and session-preference changes were restored to the captured bytes.
The controlled run now enters Gameplay through the production MainMenuManager.StartGame method with an in-memory character selection and shop, and verified selected stage, difficulty and character. It also repeated combat, reward, retry, two-player revive and stage reconfiguration checks successfully. It does not exercise the actual MainMenu scene, gate/selection UI or normal boot/services. Unity-generated package and engine-session preference changes were restored to the pre-run bytes.
The controlled run subsequently loaded Stage 2 and Stage 3 sequentially into fresh Gameplay scenes and reached player/timer readiness with each selected camera background, tile material, volume and vignette setting. It used cloned level records with isolated spawn data, so stage-specific waves, bosses, completion, real selection UI and rendered appearance remain unverified. Unity-added package and engine-session preference changes were restored to the pre-run bytes.
Unity's imported Stage 3 asset resolves charToUnlock to null, and its serialized GUID 0ef73c46323b1cb43a849a10df165af9 has no AssetDatabase path. Medium completion therefore cannot unlock that character through the existing guarded progression path. The authored reference remains intact; the intended character must be identified before repair. The check did not modify saves. Unity-added package entries were restored.

Built-game Stage 1 pass — 2026-11-01¶

A local Linux IL2CPP build completed from the current uncommitted work. It ran with a separate XDG_CONFIG_HOME, a temporary development Steam app ID and network connections blocked; Steam/online and audio-device errors in this environment are expected limitations. The regular profile hash matched its pre-run snapshot. Unity-added Linux toolchain entries were restored after each build.
The original build reached the real main menu, but keyboard focus did not transfer to the character-selection page. MainMenu.unity now gives character selection an initial Select Stage focus and stage selection an initial Easy focus. A focused Editor check passed 4/4 for the earlier stage-card target; the final Easy target was then verified in the rebuilt player by navigating from the real main menu into Stage 1.
In the rebuilt player, simulated keyboard input moved and dashed the Soldier, enemies spawned and were damaged, and pause/resume stopped and restarted the simulation. One unattended run ended on the actual game-over screen and wrote only to the isolated profile. A subsequent run reached level-up rewards; keyboard navigation selected Damage Bonus and the displayed damage increased from 10 to 17 after confirmation. The user then took control of the isolated test window and continued playing. One initial confirm press was not observed to complete the reward, but the cause was not isolated and the following press worked; do not treat this as a reproduced code defect without another controlled check.
These checks use a Linux test build with simulated inputs and an offline fresh profile; they do not establish Windows/Steam behavior, physical input reliability, normal online integration, complete-stage progression or all abilities. Stage 3's missing character unlock remains unresolved. Logs are temporary and may not persist.
During the user's live play of the isolated Linux build, several level and special rewards were confirmed, the player died, and the real result-screen Main Menu action returned to MainMenu. The log shows no new game-code exceptions; Steam, leaderboard, update-check and audio failures were expected from the network/audio isolation. Normal profile hashes still matched. The user-controlled run used the temporary profile; it is not a Windows/Steam, completion or full-ability check.
In the same built-game session, a second Stage 1 run reached game over. Using the result screen's Play Again and confirmation reloaded Gameplay; the timer, health and score restarted and combat resumed. The pause screen's Main Menu action then returned to the actual menu. This was checked through the real UI with simulated keyboard input, after the user finished playing. The initial reward-confirm observation above is inconclusive: later investigation showed the test window could lose operating-system focus between inputs. No normal profile changes were detected.
The built-game log reported an evolution request with a null target. All six active evolution sources had stale target GUIDs; each had exactly one existing evolved Upgrade whose prerequisite matched the source ability. Their references were repaired without changing asset IDs or values. Unity resolved all six links (6/6), and a controlled Play Mode run granted Concussive Impact, set its counter to the threshold, then observed Deadly Impact acquired and the original removed. This does not establish natural counter progression, the other five evolution behaviors or a new player-build run. Profile and package bytes were restored after the checks.
The final character and stage keyboard-focus bindings passed the focused Unity menu check (4/4) and the built game reached Stage 1 through the actual menu. The user played the isolated build; after they finished, the real result-screen Play Again path reloaded a fresh run, and its pause menu returned to MainMenu. The test used offline services and a separate profile, and did not complete a stage.

Short test and save checks — 2026-11-02¶

Unity 6000.2.8f1 Linux Editor, SharedGameplayRunChecks.RunShortTest: passed with an in-memory test stage and enemy, simulated input and a temporary profile. The cloned configuration uses production gameplay and a borrowed appearance; it is not a real-stage run or an interactive test-stage menu. The test covered enemy spawn and two-way damage, one reward and stun, one evolution, forced boss spawn/defeat, a clear result and temporary player save, retry, and each of the seven character assets' spawn, assigned weapon, starting ability, movement and stamina-consuming dash. A critical hit, evolution counter, boss timing/defeat and end timer were forced. Other abilities, natural stage timing, real input and gameplay feel remain open.
The same run checked that the closed gate and existing ready prompt were visible to the scene while paused and the timer did not advance before input. A simulated keyboard started the first run; a simulated gamepad started retry. This is not a rendered first-frame or physical-device check. Easy clear now uses the configured end time; offline leaderboard unavailability no longer prevents a local result save.
LegacySaveMigrationChecks.Run passed with disposable Linux Editor files: fresh encrypted save, legacy migration with example currency, character/stage unlocks, shop and counter data, new-save priority and corrupt-old-file rejection without a replacement save. Path selection for both Windows legacy locations was simulated with temporary files; real Windows migration and genuine historical files remain unverified.
The short run also passed a forced player-death result and checked that its isolated save accumulated a second play. It checked freeze expiry and poison/burn damage on the live test enemy; this does not prove movement slowdown or every crowd-control effect.
Later short runs also observed Soldier's Frenzy effect, Knight's barrier after its normal recharge, Star Wanderer creating rockets against a harmless test enemy, two Priestess orbs owned by that player, and a Celestial sword owned by that player. These checks do not establish all behavior of those abilities or the other characters' unique abilities. The first Knight check timed out at 15 seconds, shorter than its normal recharge plus delay; it passed with a longer limit.
A subsequent run checked Archer's burst projectile preparation after 11 scripted fire events, and Miner's special projectile preparation with its critical counter forced to the threshold. All seven characters now have one observed starting-effect check, but natural Archer/Miner attack sequences, damage, upgrades and many other ability interactions remain unverified.
The runner accepts TINY_CHAOS_TEST_CHARACTER as a character ID and TINY_CHAOS_TEST_APPEARANCE as 1, 2 or 3. An isolated run with ARCHER and appearance 2 passed the short combat/result path, appearance bindings and Archer's checks. The initial shared combat scenario still uses Soldier. This copies appearance settings into the test configuration; it does not run a real stage or prove rendered visual quality.
StatusEffectChecks.Run reproduced four failures before the fix and passed five checks afterward: simultaneous poison, simultaneous burn, burning reset on reuse, and removed poison/burn sources. The status-only Play Mode check passed the 11 unchanged reference cases and focused checks for the three corrected cases. The older combined dash/status runner failed its dash snapshot comparison before reaching status. Its old fixture reads stamina cost from an Ability object, whereas the current dash executor updates a separate PlayerAbilityState; it also supplies legacy fixture abilities. It needs migration, and the mismatch alone does not prove a live dash failure.
During an earlier failed result fixture, an offline Steam stub was unloaded with the test scene and Steam initialization was attempted. The stub was made persistent; the passing run used the offline stub and logged no Steam initialization attempt. No real profile changes were detected. Unity-added Linux toolchain package entries were restored to their exact pre-run bytes; build settings and TimeManager were unchanged. The existing CS8785 generator warning remains.
A dash diagnostic wrote to its fixed /tmp/tinychaos-batch56-original.json path without first checking for an existing file. The committed reference remains intact, but any prior temporary file contents were not captured. The diagnostic now uses a unique temporary file for future captures.

Owner-reported ability checks¶

The owner has tried Multishot and adding ammo. Multishot combinations have not yet been tested.
The owner reports that the Soldier evolution that reloads ammo when dashing works in their play test. The report does not specify the test conditions.
The owner prefers to test further abilities manually. Do not schedule more automated ability checks for now.