Stabilization batch 22¶
Scope: GAME-24 Settings investigation before changing the existing flow. Batch 21's quit repair is already complete; the app goal's older batch-20 checkpoint does not reopen it. This batch changes no runtime code or scene data and claims no Settings repair.
Why the planned binding repair is insufficient¶
The actual Meadow scene has no SettingsInterface, Slider, Toggle, or settings TabsManager. Its two Settings actions call removed GameMenuManager.OpenPanel with null arguments. Rebinding them alone cannot open a settings destination.
History identifies the deletion in 8ef1d91a319d6b022937ed0de9963e7d6a91a461 (2026-01-20). That commit changes Meadow by 896 inserted and 10,840 deleted lines and describes the game scene as in progress. Its parent 5939579cf1800e908c1f5f9526f62a8121a78569 contains the existing SettingsPanel, SettingsInterface references, and Apply reference. The former panel contains 101 GameObjects and 396 object/component IDs; none of those IDs survives in the current Meadow scene. These are recovery data, not proof that the old scripts or complete old scene should be restored. The shipped Steam source remains unidentified.
Imported-scene evidence¶
New Editor-only SettingsAudit.cs provides TinyChaos.EditorTools.StabilizationChecks.RunBatch22Audit. It opens six disposable preview scenes, inspects imported component/reference types and persistent Settings button methods/arguments, writes a report outside Git, and closes each scene without saving. It does not invoke game startup, save initialization, graphics changes, or actual controls.
| Scene | SettingsInterface count | Sliders / toggles / settings tabs | Missing required view references | Invalid Settings routes |
|---|---|---|---|---|
| MainMenu | 1 | 5 / 3 / 1 | 0 | 0 |
| Meadow (Arena Stage 1) | 0 | 0 / 0 / 0 | No view exists | 2 |
| Tutorial | 2 | 5 / 3 / 1 | 12 | 0 |
| Arena Stage 2 | 1 | 5 / 3 / 1 | 0 | 2 |
| Arena Stage 3 | 1 | 5 / 3 / 1 | 0 | 2 |
| Experimental | 1 | 5 / 3 / 1 | 1 | 2 |
Tutorial has an extra SettingsInterface attached to VolumeSlider with all 11 inspected references empty, plus the intended interface missing applyButton. Both Awake methods assign the same static Instance without an ownership guard; initialization order can therefore choose the incomplete component. Experimental's missing reference is also applyButton. The other arenas retain their view data but have obsolete Settings callers and the previously recorded incomplete menu-controller migration.
All retained Apply button method bindings resolve to SettingsInterface.ApplyGraphic, which delegates to GameSettings.ApplyGraphicSettings. An initial inspection suspicion that this method name was obsolete was incorrect. No Apply event rename is warranted by this audit. A valid method does not prove that Apply works in a player or that its view references are complete.
Initialization and ownership evidence¶
SettingsInterface.Start calls two empty methods, LoadUIValue and BindUIListener. The only source caller of GameSettings.RebindSettings is MainMenu's MenuView.Start. Tutorial and the retained arena views have no corresponding settings initialization caller. GameSettings.RebindSettings adds new anonymous slider listeners on every call without removing its previous listeners. Its LoadSettingsUI assigns notifying slider/toggle properties; after a view has listeners, refreshing can invoke changes and config writes. Those observations are source evidence, not measurements of duplicated writes in a running settings screen; SAVE-06 retains the separate startup-write investigation.
TabsManager starts and reads tab input independently of page ownership. The next repair must check hidden-page focus/input and returning from subpages rather than certifying settings from reference counts alone. This audit covers required common view references, Apply method resolution, and buttons named Settings/SettingButton. It does not cover every child event, keymap/credits/reset/refresh action, navigation link, actual value, graphics transition, or physical controller.
Verification and preservation¶
Matching Unity 6000.2.8f1 (c9992ac36c34) imports/compiles the project for Linux64 and finishes the synchronous audit with terminal exit 0. Six report records match the table. Exit 0 explicitly means evidence collection completed, not six passing settings flows. Evidence stays at /tmp/tinychaos-batch22-audit.log and /tmp/tinychaos-batch22-settings-audit.json; historical scene extraction and exact snapshots also remain outside Git.
No IL2CPP player rebuild or runtime playthrough is performed because no runtime source or scene is changed. Batch 21 remains the latest player artifact/evidence. All 5,687 snapshotted existing source/settings paths remain byte-identical after restoring only the verified generated Linux toolchain dependency additions in manifest/lock. Normal player-profile paths and bytes are unchanged. Unresolved audio deletion, Plastic evidence, and the nonempty 655,360-byte Git index lock remain preserved. No commit/push is attempted. Final audits verify 381 local documentation links, all 52 findings scheduled once, tracked/new-file whitespace and metadata, and no remaining Unity Editor/player process.
Next repair¶
Repair the existing Settings system coherently under GAME-24: give scene views explicit initialization/listener lifetimes, load values without firing edits, eliminate Tutorial's competing component and complete retained Apply references, then recover Meadow's existing controls into the current Page/controller flow. Use current MainMenu controls and the historical panel as data references; preserve supported options and avoid restoring obsolete manager scripts or replacing the whole scene. Establish intended Apply/Back behavior from existing code; do not introduce new options or redesign the UI.
Include actual loaded values, edits/Apply, repeated initialization, hidden-page focus/input, pause child Back and eventual resume. Verify affected MainMenu/Tutorial/common callers as well as Meadow, with isolated config copies and Linux IL2CPP player evidence. Keep later-stage controller migrations and Database explicitly open. This investigation changes the next repair from a button-target patch to a scoped settings lifecycle/data migration; it does not clear GAME-24 or any release gate.