Current issue register¶

Entries and priorities span older snapshots; recheck current source and later evidence before treating an item as open. Current scope and order are in the roadmap.

Initially audited 2026-10-24 at 4fb9c7f1; the current priority is architecture-first gameplay rebuild planning. Findings began as a static audit, not an exhaustive runtime bug inventory. Fix/validation updates link to batch records; distinguish an isolated regression pass from a full player-build check.

Status: Reported = owner symptom, not reproduced here. Source defect = a concrete problematic code/data condition; player impact may still need reproduction. Risk = evidence warrants a check, but no failure is established. Tooling blocker = an attempted operation could not complete. Historical lead = not fully revalidated. Fixed, regression-verified = the specified defect failed a focused check before the patch and passed afterward; remaining player-build coverage is explicit.

Priority: P1 = investigate before a release candidate; P2 = validate affected paths and fix if reproduced/reachable; P3 = deferred unless profiling or production reachability justifies action. Priority orders investigation, not speculative refactoring.

Maintainability and documentation recovery¶

ARCH-01 · Active owner priority · Maintainability concern · Intertwined ownership and incomplete setup workflows¶

The owner's recollection of spaghetti code is supported by the archived system analysis and current source: large managers/ability/player/enemy scripts still mix responsibilities, and player/control/save/audio/spawn/stage setup crosses multiple scripts and serialized assets. Some refactors exist, but they do not establish that these workflows are understood, independent, or complete. This is a maintainability concern, not a single reproduced runtime bug.

The current ownership and authoring map records the actual paths and missing guides. Owner direction on 2026-10-25 explicitly authorizes broad spaghetti-code cleanup alongside gameplay completion. Reconstruct existing workflows, then clean up one responsibility boundary at a time across menu/run state, player/input, rewards/abilities, spawner/stages, persistence and audio. Track behavior, callers and serialized bindings together; record verified areas and remaining debt in batch records. A broad scope does not require one large rewrite. The owner subsequently chose an architecture-first rebuild: current work is audit/contract design, followed by dependency-ordered implementation, including Input System migration and a development test arena. On 2026-10-26 the owner added planned four-player capacity, explicit P1 keyboard-or-pad/P2–P4 pad-only assignment and persistent button remapping; see the input contract. Tutorial/menu patching is parked until shared systems are defined. See the source cleanup audit and active plan. Batch 28 adds the source-backed motor/vitals/stats contract; numerical examples and caller/binding scans are design evidence, not implemented fixes or runtime passes. Batch 31 adds the stage/enemy/encounter/event core contract, authoring recipes and static maps; the shared scene and enemy/event extraction remain unimplemented. Owner proposals live in design ideas; do not duplicate them as bugs or assume a proposed system already exists.

Batch 35 delivers the first verified R1a lifetime boundary (9/9 Editor groups) without changing existing gameplay owners or scenes. Batch 36 now verifies the shared scene/Editor entry (7/7) without changing production routing. Player/input/AbilityHolder migration and full maintainability completion remain pending; this does not close ARCH-01. Batch 37 now verifies new SDK slot/device ownership and run locking, without changing Player/AbilityHolder or production input consumers. Batch 38 adds action/session/context infrastructure (8/8 simulated SDK groups), including post-stop and held-input barriers. Batch 39 verifies in-memory binding profiles/legacy conversion (9/9 Edit Mode groups); the old config writer still discards the new section and is gated from rollout. Batch 40 verifies blocked-session application/reversible drafts (9/9 new + 8/8 prior groups), retaining the same ownership and restoring bindings on cancel or controlled SDK interruption. Batch 41 verifies device-owned capture (10/10 new + 9/9 draft groups), with held-input fencing, explicit cancel and conflict/ambiguity handling. Batch 42 verifies an independent full-config document/file adapter (10/10), preserving input/unknown data and failed-write recovery state on disposable Linux paths. Batch 43 verifies explicit legacy preset document commands and read-only loaded preset application (10/10 new + 10/10 persistence groups). Batch 44 separates loaded audio/locale application from saving (8/8 new + 7/7 settings-screen groups), retaining explicit first-run screen persistence and clearing locale busy ownership after errors. Batch 45 wires production config ownership (10/10 new + 34/34 regression groups), preserves remaps/unknown data and reports failed writes without erasing invalid files. Built-player startup/persistence acceptance, real locale readiness/rendering, Windows/recovery/retention, legacy-equivalent sampling, UI and actor/consumer migration stay pending. Batch 46 adds Linux IL2CPP build, actual scalar edit/restart and scoped protected-file startup evidence without implementation changes. It does not close ARCH-01/SAVE-05, native remap/legacy edit acceptance, recovery/UI, gameplay or Windows gates.

Launch and gameplay¶

Batch 49 begins production Player setup cleanup: explicit character/shop/ammo/audio inputs, real coroutine completion and an owned prefab weapon mount replace hidden setup reads/hierarchy assumptions. Original seven-character results are checked in; 22/22 groups and one/two-player Linux setup smoke pass. Player movement/vitals, AbilityHolder, input consumer and run-owned actor migration remain open; this does not close ARCH-01.

Batch 50 adds owned production-prefab preparation and an inert shared-scene preview: explicit components, slot/session identity, cancellation/rollback and material/object cleanup. GPU/lifecycle checks pass 13/13, prior character/scene regressions pass 29/29 and the existing two-player Linux run still starts/returns/quits. Motion, vitals/AbilityHolder/combat and full actor lifecycle remain open; rendering the prepared actor does not close ARCH-01 or gameplay/input migration.

Batch 51 measures and preserves default keyboard sampling before the motor extraction. Opposing held keys cannot be represented by raw difference alone; command pressures plus the scaled-clock filter reproduce original measurements exactly. Nine new and eight existing input groups pass. This does not switch production input, move the shared preview or close ARCH-01/physical/gameplay acceptance.

Batch 52 extracts one motor from Player and connects session-owned keyboard/gamepad movement to the real shared-scene actor. Original state/output comparisons, scoped scene/SDK regressions, actual Linux virtual-input equality and the native two-player movement/reward/return/quit path pass. Player's resource/damage/status code, full dash/AbilityHolder/targeting and other motion consumers are still pending. This is partial cleanup, not closure of ARCH-01 or full gameplay/physical/Windows acceptance.

Batch 56 separates dash/status execution and guards retired callbacks. A controlled pre-reset freeze iterator changed the reset multiplier to 0.5; generation checking now preserves 1 while matching normal status traces. Dash completion is similarly retired across death/revive/release. Legacy effect services, shared cooldown state and full capability integration remain open under ARCH-01/PC-03; this does not close the rebuild or the deferred main-menu freeze.

GAME-01 · P1 · Reported, owner-deferred · Approximately 60-second freeze¶

Current scheduling, 2026-10-25: the owner has halted dedicated investigation and fixes for this reported freeze to prioritize gameplay completion and broad code cleanup. Preserve existing evidence and diagnostics; resume only on owner direction. This is an unresolved issue, not a verified fix or accepted release limitation. The investigation notes below are retained historical guidance, not the current next action.

Owner clarification: an intermittent delay of roughly one minute happens when reaching the main menu, across devices; some launches proceed normally. Earlier save-file and save/graphics-sizing experiments did not resolve it. Graphics/display behavior remains a conjecture, not a proven cause; unsuccessful experiments do not conclusively eliminate saves either. Exact affected build, timing boundaries, rendering/input responsiveness, and a captured reproduction/log/profile are still missing.

Focus reproduction/instrumentation on boot-to-menu transition, display/settings application, save/platform readiness, and menu initialization/dependencies. The in-run 60-second miniboss suppression remains a separate gameplay risk (GAME-06), not the primary explanation for this clarified menu symptom. Establish whether frames stop, input is blocked, or a loading dependency waits. The local validation target is Linux; production remains Windows IL2CPP built on another PC. Archived probes are observation suggestions only; this issue is not fixed by the batch-01 offline path correction.

Owner follow-up: the symptom may have started around 0d56ec2c364af2f7abc05be5b3b6aeceba3376c9, but the owner is unsure. Git verifies that this 2025-11-05 commit changes Unity 6000.2.4f1 to 6000.2.8f1, along with package and ShaderGraph settings updates; it contains no C# changes. Treat it as a possible comparison boundary, not a verified affected Steam revision or proof of an engine defect. Batch 05 built and launched a Linux IL2CPP candidate: startup async markers were 0.744 seconds apart, but character initialization and menu wiring failed (GAME-16/17). The later input-gated splash wait is not a measured frame stall. This run neither reproduces nor resolves the reported freeze.

Batch 06 fixes those menu blockers and records positive character/menu initialization markers with no logged runtime exceptions. Its logo-start/complete markers are 61.867 wall-clock seconds apart, before the press-key transition. This is a stronger timing lead than the earlier input-gated wait, but focus/background and time scale were not sampled. PlayerSettings has runInBackground: 0, so suspension while unfocused remains a confounder. Do not label this a reproduced frame freeze or blame the coincident changelog response without a controlled foreground/frame/stack trace. Investigate that interval next.

Batch 07 establishes that confounder using the identical batch-06 binary. A foreground logo sequence took 3.363 seconds; temporarily minimizing the candidate for eight seconds extended it to 11.552 seconds, an 8.189-second increase. This supports background suspension as an explanation for stretched local wall-clock measurements, but cannot retrospectively prove the cause of batch 06 or the owner's Steam symptom. DiscordCreate returned in 0.000724/0.002298 seconds in those two runs; that specific call was fast there, not a blanket clearance of Discord or other startup paths. The reported freeze remains unresolved and needs a controlled affected-build reproduction, especially on Windows.

Batch 12 confirms and repairs a current-candidate early-logo-skip deadlock under GAME-13, including a controlled Linux input probe. The owner's reported approximately one-minute symptom still lacks a verified Steam source/build mapping and affected Windows reproduction; do not close this report solely from that local fix.

GAME-02 · P1 · Reward state repaired; one-player level-up verified · Reward pause and selection¶

The owner reproduces gameplay continuing behind level-up cards and rejected reward selection. Batch 18 traces this to missing time-scale updates on reward transitions and legacy gameplay/selection gates reading only menu pause. SetRewarding now applies time scale on entry/completion, the legacy gameplay pause getter includes rewards, reroll checks menu pause separately, and queued rewards wait behind menu pause. Actual coroutine/state checks improve 9/17 → 17/17; existing pause checks remain 7/7. The rebuilt Linux player naturally reaches level 1, holds game time/health/enemy positions while cards show, moves the P1 marker with D, and confirms with Space. Cards close, damage changes 10 → 17, and time advances 00:35 → 00:37. Batch 20 additionally confirms an ordinary level-up in each of two runs separated by a real game-over retry. Real reroll/chest/boss rewards, consecutive queued rewards, broader repeated-run cases, physical controllers, co-op, and Windows remain acceptance checks; do not infer all reward-content behavior from empty-pool fixtures or these limited real level-ups.

GAME-03 · P1 · Source defect · Missing audio still has live asset references¶

The pre-existing workspace deletion is one WAV plus its .meta, not two distinct audio clips. Its GUID e384f977e4a494144821f791a9780cbf remains in MainMenu as lightningStrike and Judgement Sword as an audio clip/resource. Recovery scenes reference it too. Missing-reference condition is verified; playback impact needs testing. The owner is unsure whether deletion was intentional and explicitly requested investigation before changing it. Preserve the deletion pending that investigation.

GAME-04 · P1 · Fixed, regression-verified · Best level and best score separated¶

GameDataCount.GameEndValueToSaveData now writes the run level to DataCountType.BestLevel, leaving BestScore for score. Batch 01 failed on the old destination and passed after correction across three improving/regressing level/score runs; accumulated total score remained independent. This corrects future record updates and does not reconstruct potentially corrupted historical records. A full game-over/save/reload check remains part of candidate acceptance.

GAME-05 · P2 · Resolved by Unity binding check · Filename mismatch is not a broken import¶

GameInitializer.cs declares GameInitialization; ServiceRoot.cs declares ServicesRoot. Batch 02 resolved each original GUID to its MonoScript and verified GetClass() returns the intended runtime type in Unity 6000.2.8f1. Both checks pass without renaming anything; the original files and metadata are byte-for-byte unchanged. The naming oddity is not evidence of a broken imported class here, so no rename is needed for this finding. Complete scene/startup behavior remains in player acceptance.

GAME-06 · P2 · Risk · Special-enemy suppression depends on death identity¶

SpawnerEventManager.MiniBossDeath/CheckSpecialKillId matches killId against any entry in SpecialSpawnData; it does not check that entry's isActive flag or a live enemy instance. A match clears creep suppression and resets all creep event flags. Batch 31 records the 60-second Miniboss/10-second Special fallback, overlapping-instance and pending-spawn risks, and the off-screen path that unregisters/pools without normal EnemyDeath. These are source behavior/risks requiring scoped runtime checks before a change. They do not establish the main-menu freeze's cause. See SE-03 in the stage/enemy contract.

GAME-07 · P2 · Fixed, regression-verified · Enemy reward null guard ordered safely¶

Enemy.Rewarding now checks null before array length. Batch 01 reproduced the original null exception and then passed direct null/empty-array calls after correction. Existing nonempty drop behavior is unchanged by this guard fix; actual drop/pool behavior still belongs to gameplay acceptance.

GAME-08 · P2 · Risk · Pool activation order and null handling¶

PoolManager activates reused objects before setting their requested position/rotation. OnEnable logic can therefore observe the previous transform. DeactivateObject uses the object/name before its null check, and the pool dictionary initializes in Start. Check consumers that spawn during initialization, on-enable behavior, null returns, and repeated pool returns before changing policy. The combat contract also traces incomplete projectile/carrier payload resets and child-owner assignments. Characterize fresh/recycled attacks, full payload preparation and owned cancellation with the lifecycle slice; no pool-policy implementation was made in batch 29.

GAME-09 · P2 · Risk · Single-player still traverses player slots¶

RewardRoller checks special/boss reward behavior across Players.Length; historical analysis flags more two-slot assumptions. Validate inactive/absent second-player slots, player-two-only perks, and one/two-player reward counts. Array length is not necessarily the active player count. The batch-28 source review also finds REVIVE traversing all inactive array slots, while actor death checks slots 0/1. Test joined/unused-slot reachability and repeated revive under the same active-roster contract; this is not yet a confirmed player-visible failure. Batch 32 also traces ConfirmSelect applying P1 before a later P2 activeSelf check: Revive can activate P2 between those steps and cause an unconfirmed selection application. Reproduce that actual reward path before correcting it; the reward contract specifies a frozen-recipient/offer boundary.

GAME-10 · P2 · Risk · Runtime data lives on shared assets¶

Ability, Upgrade, and spawn data carry runtime state. Serialized production upgrades already include nonzero upgradeTaken: weapon evolution has 7. Other examples include FFKnowledge, Meditate, and ETArmor. GameInitialization resets imported reward-table counts, so nonzero serialization alone does not prove cross-run leakage. Batch 20 observes first-run damage 13 returning to base damage 10 after a real retry, followed by another working level-up; this is limited reset evidence, not validation of every mutable asset. Test remaining reset order, consecutive-run cases, and co-op sharing before deciding a fix. Batch 29 traces AbilityFunction timer/coroutine keys and potion cleanup keyed only by ItemType, without player identity; shared asset cooldown writes and cross-player cancellation are source risks. The combat contract requires independent per-slot execution state and explicit refresh/reset comparisons, not changed effect strength.

GAME-11 · P2 · Source placeholders · Some effects have no implementation¶

AbilityHolder.StarBurstShield (historical script) only yields once. UpgradeFunction has an empty GKARMOR case and no DRONEMK2 case. Batch 29 finds no authored Upgrade array currently resolving to either effect and no caller outside the StarBurstShield activator or matching persistent call. The old GKArmor/GKCrown/GKStaff upgrade assets are absent from direct boot catalogs, have zero incoming serialized GUID references in the 1,256-file scan and serialize obsolete effect ordinals 59/57/58. This narrows the concern toward prototype retirement; external/reflection loading and runtime reachability remain unverified. StarBurst's working charge/projectile path is separate and must be retained. See the combat contract; no new placeholder effects are authorized.

JoystickRefreshPanel.AutoHide now uses WaitForSecondsRealtime, retaining its configured delay while allowing auto-hide when game time scale is zero. Batch 02 ran the real coroutine in an empty Play Mode scene: normal timing passed before and after; paused timing failed before and passed afterward. The test used a short configured delay and did not run controller detection, full settings wiring, or reconnect UX; those remain player-acceptance checks.

GAME-13 · P1 · Skip deadlock fixed/player verified; recovery risks remain · Startup completion¶

Batch 11 observes a Linux player logging “Skipping logo 0” followed by all startup tasks complete, yet no logo-complete/menu marker for another 88.578 seconds with 178/178 focused samples. The helper sent no startup key/click; the input origin is unknown. A later launch of the same artifact without a logged skip completes its logo in 3.267 seconds and reaches the menu. Batch 12 confirms that stopping the child coroutine strands its parent: normal Play Mode sequence passes, while all five skip cases fail. Cooperative cancellation and direct iterator yielding improve the same six checks from 1/6 to 6/6. Normal and deliberately early-input Linux players both reach visible menus; the skipped logo finishes 0.228 seconds after its skip marker. Timings remain scaled and task readiness is still required. This fixes the confirmed candidate deadlock, not yet the owner's unidentified Windows/Steam freeze. Separately, AppInitiator uses async void Awake and awaits dependencies without surrounding recovery; those failure paths still require checks. Preserve normal logo/task/scene coordination while fixing verified behavior.

GAME-14 · P2 · Fixed, method regression-verified · Basic upgrades respect the selected stage flag¶

GameInitialization.ImportRewardTable now checks appearsInStages[stageIndex - 1] before importing a basic upgrade, matching its existing stage flags. Batch 03 reproduced disabled entries entering the basic table before the one-line guard, then passed first/second-stage eligibility, empty/short-array exclusions, table clearing, and unchanged special/boss/Mythic routing afterward. Checks call the actual import method with temporary in-memory catalogs; selectable-stage catalog reachability and a complete player reward flow remain unverified. No stage IDs, upgrade assets, weights, or rarity policies changed. GAME-15 remains open. The dilution/loadout proposal is separately recorded as IDEA-18 in design ideas.

GAME-15 · P2 · Fixed, content/method regression-verified · Stage scenes and progression identity separated¶

Batch 04 traced the actual three-stage boot catalog, menu references, enabled scene list, and persistent difficulty IDs. The former stageIndex values 2/3/3 mixed scene build positions with progression ordinals: Snowdrift Vale resolved to Crystal Mine's scene; Medium clears targeted the wrong stage or returned early; later difficulty unlocks also failed. The corrected assets use progression ordinals 1/2/3 and explicit sceneName destinations. Both initial play and retry use the destination. GameManager.UnlockStage now locates the current stage by catalog identity, permits final-stage difficulty/character rewards, and treats unassigned character/next-stage rewards as absent. All seven content/method check groups pass after the changes (1/7 before), using cloned stage/character data with save IO suppressed. Stable difficulty IDs, names, GUIDs, and saved-data keys are unchanged. Batch 13 now renders Meadow after default Soldier/Normal selection; active gameplay blocks under GAME-22. Other rendered transitions, progression clears, complete runs, and save/reload remain candidate-acceptance checks. See the stage identity reference.

GAME-16 · P1 · Fixed, regression/player-startup verified · Character selection waits for its catalog¶

CharacterManager now uses a cancellable enable-time routine that waits for the ready catalog before populating its UI. It pairs one selected-locale subscription with disable cleanup, so cleanup no longer indexes whichever character is currently selected. UI actions wait for initialization; later locale refreshes use current active selections. Batch 06 reproduces the original early-enable/selection-cleanup exceptions, passes the corrected method checks, and records successful character initialization with no exceptions in the graphical Linux IL2CPP player. Default player mode/content are retained. Full one/two-player selection, language changes, and UI disable/re-enable interactions remain acceptance checks; the targeted startup fault is resolved.

MainMenu.unity now connects MainMenuManager.menuController and charManager to the existing scene components. Batch 06 verifies both references through Unity's imported scene, then records the actual player reaching [MainMenuManager] Menu initialized after the splash/hyperspace transition. The former missing-controller error does not recur. Batch 13 exercises Play/character/stage navigation and transfers the default Soldier into Meadow. Full page navigation, alternate selection/co-op, and active gameplay remain acceptance checks.

GAME-18 · P1 · Fixed, checks/player-entry verified · Tutorial entry¶

MainMenu.unity previously configured TutorialButton (GameObject 865741372, Button 865741375) to call MenuController.PushPage with object argument {fileID: 0}. PushPage immediately calls page.Enter(true), so this binding cannot navigate successfully. Batch 07 also records a mouse-release-driven NullReferenceException in PushPage after menu initialization; the exact clicked button was not captured, so that attribution is a supported lead rather than a recorded click identity. Batch 08 replaces that binding with the existing MainMenuManager.StartTutorial no-argument handler. The same imported-scene checks improve from 1/4 to 4/4, including actual persistent-event invocation with scene loading guarded; all nine remaining PushPage arguments resolve. Batch 09 rebuilds the Linux IL2CPP candidate and verifies the real Tutorial button loads the scene; opening dialogue and movement work. Tutorial pause/settings then fails under GAME-19, so a full tutorial or gameplay pass is not claimed. Tutorial redesign remains IDEA-14.

Batch 09 records three explicitly timed Escape/P actions in the Linux player, each producing a NullReferenceException in TutorialManager.ShowSettings → InputManagement; no usable pause menu appears. Tutorial entry, opening dialogue, and movement work before that failure. The player's missing-script warnings name four panel objects and TabsManager.

All four Tutorial panel references previously pointed to components with absent script GUID 893f1b2a15fc1f149926ef26a7c07594 and GamePanel-shaped fields. GamePanel exists with metadata GUID 490c4f1e9d0dd0548a97d9ebba30ab4c. The absent GUID previously occurred on 44 components across Tutorial (4), Arena Stage 1 (8), Arena Stage 2 (12), Arena Stage 3 (12), and Experimental (8). Batch 10 uses Git history to restore all 44 bindings and migrate four old TabsManagers, their saved data, 12 tab-button calls, and three Tutorial panel argument types. Imported/method/event checks improve from 0/11 to 11/11. The rebuilt Linux player opens Tutorial pause/settings, switches tabs, navigates Back, resumes, and reopens pause without the old exception or missing-script warnings. Return then exposes GAME-20. The co-located HorizontalLayoutGroup GUID resolves in UGUI and was not changed. Arena navigation, retry, settings values/Apply, and full playthrough remain acceptance work; some settings controls look like serialized defaults, so visible tabs alone do not establish loaded-value correctness. No tutorial redesign or new menu feature is authorized by this defect.

GAME-20 · P1 · Fixed, method/repeated-player-return verified · MainMenu re-entry activates¶

Batch 10 records Tutorial → pause → Main Menu → Yes. The initial menu works, but the returned MainMenu logs components disabled at 06:34:17.799 UTC and does not activate/initialize again before the final 06:35:23.597 sample. Screenshots show only the background. Return produces one TabsManager.OpenTab, one ShopButton.Start, and 18 MenuController.SetSelectedCoroutine NullReferenceExceptions. Tutorial pause/settings worked before this transition; GAME-19's missing components are repaired.

SceneInitializer disables the camera/audio listener/EventSystem in Awake and relies on SplashUIController to activate them. That startup scene has already been unloaded when TutorialManager loads MainMenu directly. Tutorial's quit path also does not explicitly resume the paused time scale; actual return-time scale was not sampled in this probe. Batch 11 makes SceneInitializer preserve the loaded-Bootloader handoff while direct re-entry activates components/restores time scale 1 in Awake and starts the existing transition in Start. Method checks improve from 2/5 to 5/5; the Linux player reaches the initial menu and successfully returns from paused Tutorial twice, with three initialization markers and no prior UI NullReferenceExceptions. The first returned menu accepts input to enter Tutorial again. This verifies that route, not arena returns, retry, settings-value correctness, or complete runs. A separate logo-skip stall and Discord initialization errors are tracked under GAME-13 and NET-02. The reported Steam freeze remains unresolved.

Batch 24 exposes a separate cold-start cycle after graphics initialization becomes asynchronous: SplashUIController holds scene activation false while waiting for isDone. Repair the affected handoff by waiting for preload progress 0.9, caching one load task, and allowing/awaiting activation before looking up scene components or starting the menu transition. Entry controls remain 5/5 and logo controls 6/6; five completed Linux players reach usable cold menus, and a paused-fullscreen Meadow return succeeds. This is a controlled candidate repair; it does not establish the cause of the owner's reported Steam freeze.

GAME-21 · P1 · Fixed, binding/launch-to-arena verified · Difficulty buttons had empty launch targets¶

Batch 13 records Easy and Normal clicks silently leaving the stage screen. All five MainMenu difficulty buttons had target fileID 0 and stale MenuController type despite the existing MainMenuManager.PlayGame(int) handler. Five target/type pairs now point to the existing manager; values 0–4, integer mode, RuntimeOnly state, IDs, and other scene bytes are retained. Imported/guarded-dispatch checks improve from 1/3 to 3/3. The rebuilt Linux player routes default Soldier → Meadow → Normal (enum Medium), logs Play, and renders the arena/player. Gameplay then blocks under GAME-22. Other difficulties/stages/co-op and complete runs are not certified by the guarded preview.

GAME-22 · P1 · Fixed, Meadow early-player verified · Prepared arena never started¶

After GAME-21's repair, batch 13 loads Meadow and spawns the Soldier but shows no HUD, enemies, or progression for 208.910 seconds with 418/418 candidate-focused samples. A 0.7-second D hold produces pixel-identical before/after images; Escape opens no visible pause menu. No new gameplay exception accompanies the stall.

Batch 14 samples the actual player: all four preparation flags are true, paused is true, all three timer-active flags are false, and all timer values are zero. GameInitialization now awaits reward reset/spawn/player setup and yields the existing run-start handoff. GameManager pauses before preparation, then configures its menu, resumes, starts timers, opens the entry gate, and shows HUD. A separate opening transition restores historical sound/music/panel motion without the closing transition's scene-exit callback. The prepared arena begins after stage/difficulty selection; the removed legacy ready-key interstitial is not recreated.

The rebuilt Linux IL2CPP player starts Meadow in two fresh probes. HUD, timer progress, enemies, shots/damage/drops, score, and left/right movement work; an early sample has paused false and all timers active at 7.840611 seconds. This repairs the run-start blocker, not the whole game. Remaining menu routes and later-stage scene migration are GAME-24; death exposes CONTENT-04's Steam-unavailable result failure. Other stages/characters/difficulties, co-op, complete runs, rewards/save/retry/return, and Windows remain unverified. GAME-23's closing transition is repaired/player-verified in batch 16; full-run acceptance remains separate.

GAME-23 · P2 · Fixed, transition/player-verified · Closing gate timeline and ownership¶

Batch 13 and the actual batch-16 baseline record two locked-sequence warnings during launch. MenuController.GateAnimation appended panels after an autoplay sequence had started and used scaled delays, also preventing paused exits. Batch 16 constructs the full staged timeline before playback, gives the sequence/overlay independent time, and awaits actual completion. Replacing an opening/closing transition kills its old sequence and prevents an older coroutine from hiding the new overlay or invoking its stale callback.

Corrected original checks are 1/6, repaired 6/6, covering actual imported route dispatch and normal/paused/overlapping transitions. The normal Editor control passes before and after; it does not reproduce the real-player warning. In the rebuilt Linux player, the warning count is zero through launch, a working Meadow retry, and two arena returns, with one scene action per requested Yes. Windows, game-over exits, and other stages remain acceptance work; no visual redesign is made.

GAME-24 · P1 · Pause/result/core Settings verified; migration incomplete · Gameplay menus and later-stage bindings¶

Batch 14 reproduces alive-player Escape doing nothing and identifies empty-stack Back dispatch and root-close redispatch in MenuController/GameMenuManager. The old root close unpaused, redispatched Back, and left its page open; an infinite stack overflow is not claimed. Batch 15 repairs empty-stack dispatch, explicit owner-driven page removal, last-page safety, and UI tweens/delay using game-independent time. Checks improve from 4/7 to 7/7, including repeated cycles, child ownership, normal-menu delegation, state gates, and six normal/paused animation methods.

The batch-15 Linux player shows pause and completes two pause/resume cycles, with exact timer-value freeze and later progress. Batch 16 connects the existing pause confirmation Pages, fixes five open/cancel event bindings, and restores the legacy void Yes handlers with a transition guard. The player verifies both No buttons, Escape cancellation, an active Meadow retry, two usable arena returns, and MainMenu exit-confirmation Cancel after those returns. GAME-23's required transition repair is verified alongside these routes.

Batch 20 migrates the two existing game-over confirmation components/events to Page and removes the unused result-root GamePanel. GameMenuManager owns result confirmation input/focus and cancel/Back without resuming the finished run; Page owns hidden/visible keyboard interaction as well as raycasts. Result checks improve 1/4 → 4/4, legacy bindings/Tutorial checks pass 11/11, and pause/animation checks pass 7/7. The final Linux player verifies both result No/Back routes, safe No focus and focus restoration, one actual game-over retry, a second death, and a working game-over MainMenu return. Two ordinary level-ups also confirm successfully in those runs. Windows/controllers/co-op and full stage clears remain unverified.

Batch 21 repairs MainMenu's No/Yes/corner Exit event targets, makes MainMenuManager own safe No focus and cancellation/quit, and replaces configured root/gate callbacks without accumulating owners or losing other observers. MenuController notifies page removal after parent input restoration instead of calling an empty MenuView stub. Five final check groups pass, including existing pause/result controls; fresh and post-arena Linux players verify repeated mouse/keyboard cancellation, focus restoration, and actual confirmed quits with one request and exit 0 each. It also restores six original Meadow navigation modes unintentionally changed by the earlier event migration, with actual A/D result navigation verified.

Batch 22 verifies six imported scenes: Meadow has no settings view/controls after the January deletion; eight arena Settings actions use removed OpenPanel; Tutorial has two competing SettingsInterface components and an unassigned Apply reference; Experimental also lacks that reference. Shared view startup is empty, while only MainMenu rebinds values/listeners, adding listeners on each call. Retained Apply method bindings resolve correctly. Those findings are repaired in batch 23: scene-owned initialization/listeners and non-notifying refresh, persistent applied-graphics state, explicit custom-switch presentation, recovered Meadow controls/current Page callers, and core value/Apply/Back/focus behavior. Final checks pass 7/7, legacy/Tutorial checks 11/11, and quit checks 5/5. Linux players verify volume edits/persistence, pending graphics across scenes and paused Apply, Tutorial, keymaps/credits, clean resume, returns and actual quits. The inactive MainMenu P2 destination caught during player checks is corrected and final-player verified.

Remaining Settings/menu work: MainMenu controller refresh still has a removed OpenPanel caller, duplicate Player 2 label and absent popup binding; AskTutorial No retains an obsolete caller (reachability still needs checking). Tutorial return confirmation initially focuses Yes. Startup synchronizes graphics from the current system, so a saved VSync false choice becomes true in the next tested process; batch 23 preserves that existing policy and does not clear cross-process graphics restoration. Batch 24 repairs that startup policy: existing preferences drive normal launch, explicit size/mode switches retain their session state without rewriting preferences, fresh defaults use the window, and a shared asynchronous Apply records actual dimensions/mode/VSync. Nine graphics and seven Settings checks pass. Five completed Linux players verify saved 640×360, fullscreen and VSync off across processes, paused fullscreen Apply, temporary window overrides with byte-identical config, restoration afterward, return and actual quits. The affected cold preload/activation ownership is repaired alongside GAME-20. Remaining callers/focus, Database and later-stage migration are next; Windows/exclusive mode and broader display/save acceptance remain open. These observations do not identify GAME-01's freeze cause. Physical controllers, broader menu flows, Windows, and full stage clears remain unverified. These focused passes do not establish complete menu functionality.

Meadow has the current MenuController and GameMenuManager bindings. Arena Stage 2, Arena Stage 3, and Experimental have no current MenuController component and retain obsolete GameMenuManager panel/gate fields instead of menuController/settingsPage. Compilation does not migrate these serialized references. Restore the existing scene UI/events using identity/data evidence; do not add a new menu design or silently certify the later stages from a Meadow pass. These scenes were source-audited, not played in this batch. Experimental is not automatically promoted into released content.

Owner report 2026-10-27, repaired in batch 48: closing Achievements at 1280×720 left its panel covering the lower main menu and subsequently opened Settings. Settings itself zooms; the obstruction is the other page's completed downward slide. AnimFunc used screen pixels as anchored canvas units. It now derives offscreen positions from viewport/panel bounds in parent coordinates. Original bounds checks 3/6 → corrected 6/6; 7/7 normal/paused/delayed animation checks pass; rebuilt Linux IL2CPP player verifies repeated transitions at 1280×720 and 960×540 and natural quit. The scoped symptom is closed; broader GAME-24 migration, Windows and deferred UI redesign/four-player/rebinding work remain open.

GAME-25 · P2 · Source defect · Mastery difficulty multiplier is truncated¶

GameManager.GameOver computes mastery as ((score / 1000) + level) * (int)Difficulty.GetValue("MASTERY_BONUS"). The difficulty table supplies 0.5/0.8/1/1.2/1.5, so the early cast yields 0/0/1/1/1. Easy/Medium therefore compute zero mastery, and fractional Insane/Chaos bonuses are discarded, before the separate exactly-two-player division. Batch 32 records source-derived numerical cases, not a runtime/save reproduction or fix. A correction must specify casts/rounding separately from integer score division and added-player participation; do not silently change all progression math during extraction. Existing records are not automatically repaired. Route through the reward/progression contract.

Saves and progression¶

SAVE-01 · P1 · Fixed, regression-verified · Null Steam identity accepted by legacy resolver¶

AppInitiator can supply null identity when Steam is unavailable. SavePathResolver now coalesces null to an empty legacy path component, preserving legacy no-ID and existing identified paths. Batch 01 reproduced the constructor exception before the patch and passed null/empty/normal-ID path checks afterward, including modern Main/Beta suffixes. Checks ran on Linux without save IO; the Windows branch and complete Steam-unavailable player startup remain pending. This is not evidence that GAME-01's menu delay is resolved.

SAVE-02 · P1 · Source defect · Legacy discovery is gated by a narrower existence check¶

SaveManager.HandlePlayerDataAsync enters migration only if LegacySaveExists(player.dat) succeeds at the single legacy resolver path. SaveService.FindLegacyBinaryFiles also supports the Windows legacy location without a Steam-ID directory, but only runs after that gate. A player who has only that alternate file can be treated as new. On non-Windows platforms the discovery iterator has no paths, even though the legacy existence check can find a file in persistentDataPath. Validate copies of supported legacy layouts on each supported platform and check the intended migration contract.

SAVE-03 · P1 · Risk · Malformed saves/config can interrupt startup¶

SaveManager reads/decrypts/deserializes existing player/config files without an encompassing fallback in those load methods. A present file is not necessarily valid. Verify malformed/truncated encrypted data, invalid or empty JSON, old missing fields, and recovery behavior with disposable save copies. Do not overwrite real player data to perform these checks.

SAVE-04 · P2 · Risk · Display-name keys versus stable upgrade IDs¶

GameDataLoader.SaveResources persists special-upgrade unlocks keyed by upgradeName, while initialization indexes upgrades by idname. Audit load/save symmetry and duplicate/renamed names before changing either key; preserving existing progression may require compatibility handling. A rename can be a save change even if the UI text change looks harmless. Batch 33 confirms defaults, ResourceInitializer load and SaveResources save all use upgradeName; the difference is against idname-based catalog lookup, not a proven mismatch among those three persistence paths. The contract requires explicit ambiguity-checked key migration before changing saved identity.

SAVE-05 · P2 · Source-audited risk · Achievement/save event lifetime and readiness¶

Batch 33 maps save readiness and its direct locale/achievement neighbours: AchievementManager, ShopManager and LocalizationManager Initialize methods add static handlers without matching teardown found in those managers; ResourceInitializer and LocalizedTextHandler pair enable/disable subscriptions. Save readiness is a synchronous edge, while locale application starts a coroutine, and late subscribers have no automatic readiness replay. These are source risks, not reproduced duplicate callbacks. Verify repeated initialization/menu entry, late binding and valid dictionary projection before declaring a runtime failure. The persistence/UI/service contract specifies snapshot/readiness and owned lifetime boundaries.

SAVE-06 · P3 · Risk · Synchronous IO and legacy serialization¶

SaveService performs synchronous file operations and retains BinaryFormatter for legacy migration. These are compatibility/performance concerns, not proof of a stall. Profile save/game-over timing if implicated and preserve supported old-save import behavior when fixing defects.

Batch 19 adds opt-in diagnostic traces and observes 13 config writes during a fresh Linux startup and 12 during reload, before interacting with Settings. All instrumented operations complete in those probes. Repeated writes are now runtime-observed; their necessity and performance impact still need a focused call-site/timing investigation. No IO scheduling, save format, migration policy, or write-coalescing change is made, and these observations do not identify the reported menu freeze's cause.

Network eligibility and trust¶

NET-01 · P1 · Validation gap · Server-side Steam admission is unverified¶

The owner wants only eligible Steam players to submit ranked scores. LeaderboardManager.PostData sends a JSON run record without a Steam authentication ticket/session credential in the inspected request code. Submitted display name and client-assembled statistics are not independently verified identity evidence. The server source/configuration was not found in this repository and the endpoint was not tested, so this does not establish that unauthorized requests are accepted. Inspect the real backend's authentication/ownership checks, value validation, and demo eligibility contract. IDEA-12 in design ideas holds the proposed changes; verifying an eligible Steam account and validating the score itself are separate requirements.

Batch 11 records three ResultException/InternalError failures in Discord.Discord..ctor called by DiscordRichPresence.Start, one per MainMenu load in its third Linux/offline probe. All three menus still initialize and both Tutorial returns work; these exceptions are not evidence of the minute-long freeze. Start leaves construction outside its later catch paths; Update catches callback failures by destroying the object, and a later scene can instantiate it again. Verify SDK/client availability, safe initialization failure, native resource cleanup, and repeat scene entry; preserve existing optional presence behavior. Batch 07's fast DiscordCreate timing did not certify successful construction or every integration path. No upgrade/removal was made, and Steam score admission remains separate under NET-01.

Performance and content checks¶

ID / priority / status	Evidence and practical check
PERF-01 · P3 · Risk	PoolManager grows on demand without prewarm/cap and keys pools by object name. Profile instantiate/allocation spikes; verify duplicate-named prefab behavior. Do not impose a cap without defining what happens when exhausted.
PERF-02 · P3 · Risk	Player, Enemy, and the spawn director use broad searches/target work. Historical analysis also flags per-frame targeting sorts, stat recalculation, collectible scans, and status UI polling. Profile dense supported gameplay before optimizing.
PERF-03 · P3 · Historical lead	Items and item-merger work were flagged for repeating coroutines in the old analysis. Confirm actual coroutine counts/reset behavior under pooling before calling this a leak.
PERF-04 · P3 · Risk	Damage popup limiting occurs through GameManager.HardLimitPopUpDamage after popup creation. Measure the spawn/throttle cost with the current limit before redesigning feedback.
CONTENT-01 · P2 · Risk	`Experimental` is enabled in the global build scene list. The Windows profile inherits that list. Confirm intended release inclusion; an enabled scene is not proof that menu navigation exposes it.
CONTENT-02 · P3 · Historical lead	Stage mapping records unavailable Stage 4/5 placeholders and alternate Stage 1/3 variants. Verify actual catalog/selection reachability; do not implement new stages for stabilization.
CONTENT-03 · P3 · Risk	AudioService starts muted until settings reapply volume; startup failure can prevent that step. Paused sounds reuse the effect source. Test startup audio/settings and rapid UI sounds before treating either behavior as a bug.
CONTENT-04 · P1 · Local result/save failure fixed; service checks remain	Batch 17 guards Save.Nickname with existing Steam readiness and uses the existing empty-name/NewPlayer fallback. Explicit score admission excludes an unavailable Steam API, preventing the fallback from enabling anonymous submissions; this is not backend authentication (NET-01). Checks improve 1/3 → 3/3. The Linux player reaches visible results after a 53-second Meadow death and writes matching kills/score/currency/counters; another process logs loading that profile. A second completed run/accumulation, online Steam, offline-client mode, external achievement/leaderboard behavior, and Windows remain unverified. Game-over button migration remains GAME-24.
CONTENT-05 · P2 · Historical lead	Soldier Frenzy handoff flags cooldown UI reset, a possible reload-bar/gameplay multiplier disagreement, reload timing through Frenzy transitions, and cleanup on death/pool reuse. Batch 29 now confirms that PlayerWeapon reload wait and UI fill use different formulas, while mid-reload stat changes do not recompute the captured wait. Transition/death/reuse outcomes remain unverified. Preserve gameplay rates and decide any display correction explicitly; see the combat contract.
CONTENT-06 · Resolved by audit · False missing-material lead	The Soldier handoff called GUID `a97c105638bdf8b4a8650670310a4cd3` unresolved. It resolves to URP's `Runtime/Materials/Sprite-Lit-Default.mat.meta` in the installed package cache. The Player prefab references are not evidence of a missing material. No asset replacement is needed for this claim.
CONTENT-07 · P2 · Historical lead	XP/reward handoff flags multiple-level XP grants, rewards arriving during open settings, and simultaneous two-player magnet entry when the chosen target dies/deactivates. Validate these scenarios together with GAME-02 and GAME-09.
CONTENT-08 · P2 · Source placeholder	CollectionView.UpdateEnemyPreview has an empty body, despite an enemy catalog in CollectionManager and a selection handler in CollectionUIController. Confirm scene/menu reachability and intended preview before fixing it. Existing character preview does not establish a complete enemy/character database; the design direction is IDEA-16.
CONTENT-09 · P2 · Reproduced network/content failure	ChangeLogReader received HTTP 404 in the batch-05 Linux player. MainMenu configures a GitHub `blob/main/info.json` webpage URL for a JSON request. Verify the intended existing feed/source, its raw JSON address/schema, and failure handling before changing the URL; do not invent a replacement feed. This is separate from leaderboard/Steam trust, which was not verified by this request.

Release and tooling¶

ID / priority / status	Evidence and next check
REL-01 · P1 · Unverified baseline	No tags and no verified Steam-build-to-commit mapping. `main` is not automatically the shipped version. Record the public depot/build identity and provenance before certifying a candidate.
REL-02 · P1 · Source metadata mismatch	Global settings use `bundleVersion: 0.8.2`; Windows LZ4HC profile overrides `0.9.0`; latest code commit subject says `1.9.1`. Establish the intended candidate version and inspect the built player's version rather than guessing from branch/commit names.
REL-03 · P2 · Partial regression coverage	The initial audit found no project-owned checks. Editor-only runners now verify batches 01–04, 06, 08, and 10–13; batches 05–07 and 09–13 add Linux build/startup/player evidence. Full candidate acceptance and Windows results remain missing. Package tests and archived checklists do not establish game coverage. See the stabilization plan.
TOOL-01 · P1 · Partial verification, player acceptance incomplete	Batches 05/06/09/10/11/12/13/14/15/16 built Linux IL2CPP successfully and launched isolated graphical players. Batch 06 records successful character/menu initialization after correcting GAME-16/17, but no complete playthrough passed. Batch 07 measures background suspension as a local timing confounder; the reported Steam freeze remains unresolved. Windows IL2CPP requires the other PC. Batch 15 repairs and player-verifies Meadow pause/resume; its Editor Play Mode checks still report Version Control configuration/shutdown errors and a Localization Editor GameViewLanguageMenu exception. These remain tooling limitations, separate from passing assertions/player behavior; a standalone build pass does not resolve them. Batch 12's empty Play Mode fixtures changed the normal engine-prefs hash; no gameplay save/config files were present there, and actual player probes used isolated profiles. The hash-only preference baseline cannot restore previous values; future checks capture bytes. CLI reference records capability/limits.
TOOL-02 · P2 · Unavailable live connection	`unity list --project-path ...` returned `No Pipeline instance found`. Live Editor command/control is not currently established; headless execution and source-file work are separate capabilities. No package was installed to add a bridge.
TOOL-03 · P2 · Verified compiler warning	The successful CLI import emitted `CS8785` for `AttributeBasedFieldGenerator` on the firstpass, game, and Editor assemblies: generator `IndexOutOfRangeException`. The matching generator class is in the installed `com.unity.ai.inference` 2.4.1 package's `OperatorGenerator.cs`. Compilation exited successfully, but generator output is missing. Its exact failure trigger and practical effect remain unverified. See the CLI record.

Documentation problems addressed in this pass¶

DOC-01: Cancelled rewrite instructions still overrode Unity work. Archived all migration plans/analysis with withdrawal banners; current scope now leads the index.
DOC-02: The docs index and plan.md duplicated a broad refactor proposal. Replaced the index and archived the unique plan/task history. That historical proposal remains archived; the owner subsequently authorized gameplay completion and broad cleanup under the current stabilization plan.
DOC-03: Speculative trees/folder rules and obsolete paths were presented as current architecture. Removed four speculative documents, archived the stale snapshot, and created a source-checked architecture page.
DOC-04: Three controller guides conflicted. Active guidance now describes JoystickRefreshPanel; the list/layout-override components are commented out. Old alternatives are archived, not listed as available features.
DOC-05: Save debugging guides advertised methods absent from the current source, including SavePlayerDataWithoutEncryption and LoadPlayerDataWithoutEncryption. Replaced active instructions with the current save/debug APIs and paths.
DOC-06: Localization, UI, menu, save, and refactor summaries overlapped and included unverified completion/performance claims. Consolidated current operating guidance in one maintenance reference; historical records are marked unverified.

See the audit inventory for all moves/deletions. Maintain this register in place; do not copy its findings into another backlog.