Stabilization batch 11¶
Scope: GAME-20's MainMenu return lifecycle. Change only SceneInitializer.cs and extend the existing Editor-only menu checks. No feature, scene/asset binding, save-format, or graphics-policy change.
Repair¶
Previously every MainMenu load disabled its wired input/audio/camera components and waited for SplashUIController to activate them. That owner has already been unloaded when Tutorial or an arena loads MainMenu directly. Returning from Tutorial's pause menu also carries time scale 0 into the new scene.
SceneInitializer now distinguishes an already loaded Bootloader from re-entry after startup. Cold preload keeps the existing disabled-components/splash handoff. Re-entry restores time scale 1 and activates wired components in Awake, before UI Start methods need the EventSystem. Its Start calls the existing MainMenuManager hyperspace transition, which completes the existing menu initialization. No menu redesign or replacement startup service is introduced.
This does not make MainMenu a standalone replacement for Bootloader: persistent services/data still need the normal initial startup. Existing serialized fields, component identities, GUIDs, and CRLF are preserved.
Regression evidence¶
Run -executeMethod TinyChaos.EditorTools.StabilizationChecks.RunBatch11 through the installed Unity CLI/6000.2.8f1 Editor, following the CLI workflow.
| Actual method check | Original | Repaired |
|---|---|---|
| Cold preload keeps components disabled and preserves its current time scale | Pass | Pass |
| Explicit cold activation remains idempotent | Pass | Pass |
| Paused return enables components and restores time scale 1 | Fail | Pass |
| Unpaused return enables components without an absent splash | Fail | Pass |
| Repeated initializer instances recover paused readiness | Fail | Pass |
| Total | 2/5 | 5/5 |
Original CLI exit 6 wraps Editor exit 1; repaired CLI exit 0. The runner uses inactive wired fixtures, invokes the actual Awake/activation methods, and restores time scale in finally. A named empty Editor scene supplies the Bootloader-presence control; no real bootstrap, save, online service, or gameplay scene is run. These checks do not exercise the new Start handoff, transition animation, or complete menu navigation; player validation must cover them.
Two initial fixture attempts used unsupported scene-creation combinations (additive creation beside an unsaved Editor scene, then a Play-Mode-only runtime API). They were corrected before the valid 2/5 comparison; those setup failures are not game-defect evidence. Relevant raw logs remain temporary at /tmp/tinychaos-batch11-original.log and /tmp/tinychaos-batch11-after.log.
Player verification¶
The installed CLI built /tmp/tinychaos-batch11-linux/TinyChaos.x86_64 successfully, terminal exit 0. Provenance records Unity 6000.2.8f1, StandaloneLinux64, revision 5347e4600bb897ca1c9fa8cb80cb095f6ee0ce0a, dirty. Build UTC start/end on 2026-10-24: 07:58:47.058 / 08:09:15.109. The code change required native relinking; GameAssembly SHA-256 is 5cf2d7f7178cdb9cce7a2328dbfd08075bf76d221c48ad4e2ed6714ffd02ddae.
All launch attempts used fresh child configuration/cache roots and the temporary local-only development Steam app-ID file. No Steam authentication was available. Inputs/screenshots used the existing exact executable/PID/window/focus/dimensions guards. Raw evidence remains under /tmp/tinychaos-batch11*; sanitized aggregate /tmp/tinychaos-batch11-summary.json separates the attempts.
The first attempt (batch11) stalled after logging “Skipping logo 0.” Startup tasks completed, but no logo-complete or menu-initialized marker appeared during the remaining 88.578 seconds. All 178 focus samples in that interval were candidate-focused. The helper recorded no synthetic key or click input; the origin of the input seen by the game was not captured. Screenshots show the blank purple splash. This promotes GAME-13 to an observed startup blocker and motivates a controlled skip/coroutine check. It does not prove the root cause of the owner's Windows/Steam freeze. The process was deliberately stopped after evidence collection.
The second attempt (batch11b) was interrupted before startup evidence; its session/process later no longer existed. It supplies no player pass/failure claim. The same already-built artifact was reused for a fresh third attempt, batch11c, without another build.
| Third-attempt control / transition | Actual result |
|---|---|
| Cold boot, no intentional input until the ready screen | Logo completes in 3.267 seconds; 7/7 focus samples focused. Space at 08:17:36.557 UTC enters the initial menu; initialization at 08:17:39.415. |
| Tutorial return 1 | Yes at 08:18:17.853; re-entry activates at 08:18:21.139 with logged time scale 1; menu initializes at 08:18:23.020. Screenshot shows menu controls. |
| Input after return 1 | Clicking Tutorial again enters the scene and its pause/return confirmation, proving the returned menu accepts input. |
| Tutorial return 2 | Yes at 08:19:17.114; re-entry activates at 08:19:20.359 with logged time scale 1; menu initializes at 08:19:22.242. Screenshot shows the menu again. |
There are exactly three menu-initialization markers (initial plus two returns), two direct-entry markers, no missing-script warnings, and no recurrence of the prior TabsManager/ShopButton/MenuController NullReferenceExceptions. These results cover the new Start handoff and existing transition beyond the fixture checks.
The third attempt is not exception-free: each of its three MainMenu loads logs Discord.ResultException: InternalError from the SDK constructor called in DiscordRichPresence.Start. Menus still initialize and both returns work. NET-02 tracks graceful optional-integration failure and lifecycle handling; the earlier native-call timing does not establish SDK health. The changelog HTTP 404 remains CONTENT-09. Settings values/Apply, arena returns, retry, controllers, complete runs, Windows/Steam, and the reported freeze remain unverified.
Preservation and next work¶
After the Editor/build ended, reviewed only automatic Linux toolchain insertion, generated Addressables linker/Linux metadata, and TimeManager's serialization-format upgrade. Restore their exact pre-run state. Of 59 snapshotted paths, only SceneInitializer and the existing Editor runner differ; all 57 others, including all scene bytes, match. Normal player-profile hashes remain unchanged. Existing missing audio, Plastic corruption evidence, and the nonempty Git lock are preserved; no commit/push was attempted.
The first and third candidates were deliberately stopped after their bounded probes; the third launcher/player returned 0. A terminal probe exit is not a full gameplay pass. No Editor/candidate remains. The Unity skill records the need to verify first startup and later scene-entry ownership separately.
Next focused batch: make a controlled failing GAME-13 logo-skip/coroutine check, then fix the verified cause while preserving normal startup. Retain dependency-recovery investigation, NET-02, settings/arena acceptance, Steam provenance, and Windows freeze reproduction. No feature work was included; the full stabilization objective remains unfinished.