Gameplay code cleanup audit · 2026-10-25¶
Historical audit: Source, migration direction and acceptance status below reflect the audit period. Current decisions, including code-owned abilities, the shared scene and replacement input, are in the roadmap and handoff; check live source before applying an older recommendation.
Scope, authority and limits¶
Owner direction: plan a dependency-led rebuild of the Unity gameplay code before more implementation. Rebuild player assignment and migrate to the Input System, then movement/combat/abilities and reusable content setup; adapt the hard-coded Tutorial afterward. One keyboard is one player, additional players use gamepads. Subsequent owner clarification on 2026-10-26 adds planned four-player support, P1-only keyboard eligibility and persistent button remapping; unrelated features remain deferred. This source snapshot still describes the current one/two-player implementation. The gameplay rebuild plan owns sequencing and gates. ARCH-01 in the issue register owns the overall maintainability concern; existing issue IDs below retain their evidence/status.
Snapshot: branch dev-0.9.0-bootloader, committed HEAD 5347e460 plus existing uncommitted changes through incomplete batch 25. There are 227 C# files / 35,643 physical lines in Assets/Script, including 15 Editor tools/check files and third-party integration wrappers. The complete file inventory assigns every file a workstream, review depth and disposition. Also scanned GUID references in 1,256 scene/prefab/asset files under Assets, including recovery/prototype content.
Review depth is 41 files with focused source review and 186 with inventory/lexical review. This is a whole-tree inventory with focused source review of the core paths below, not a full semantic review of every method, proven production reachability, a compiled dependency graph or a performance profile. Counts of type references and legacy-input mentions are lexical indicators; zero references do not prove a script unused (serialized calls, inheritance, reflection and external consumers matter). Serialized reference counts include recovery scenes and are not shipped-use counts. Vendor SDK sources/packages outside Assets/Script are boundary dependencies, not a request to rewrite third-party code. Inspect them when an actual integration requires it.
No runtime/gameplay changes, package installation or Unity run is part of this audit. Proposed target responsibilities are designs to finish in R0, not systems that already exist or final class names.
Current coverage update, batch 35: four new, source-reviewed and Editor-verified R1a files bring Assets/Script coverage to 231 scripts. Their rows are appended to the existing CSV. The original 227 rows and their lexical metrics/review-depth claims remain the dated snapshot above; new-row metrics describe batch 35, not a full-tree rescan or production reachability proof. The verified lifecycle is not yet integrated into a scene or existing gameplay.
Current coverage update, batch 36: another four reviewed/import- and PlayMode-verified scripts bring inventory path coverage to 235. Earlier 231 rows and their original metrics remain intact. The shared scene now uses the lifetime core, with an Editor-only launcher; old production gameplay is still unmodified. The scene's two runtime bindings appear only in the new scene, with no shipped-build reachability inferred.
Current coverage update, batch 37: four more reviewed/SDK-tested scripts bring path coverage to 239, preserving the earlier 235 rows. Pairing and slot identity now use one InputUser per session member, explicitly retained across reassignment/retry. This is a coherent input ownership boundary, not a Player/AbilityHolder cleanup or migrated legacy control path. Input System 1.17.0 is pinned; only its two package files intentionally change among prior project files. Physical input, actions/context/remap/profile/actor work remains gated.
Source findings and target responsibility boundaries¶
| Area | Observed implementation | Rebuild direction / why upstream | Related findings |
|---|---|---|---|
| Player identity and creation | GameSession carries a Character list and player count. GameInitialization.PreparePlayer activates players already wired into GameManager arrays, then applies characters and registers camera/HUD references. Player.ApplyCharacter indexes GameManager.Character by playerNumber, instantiates its weapon and starts modifier setup. | Separate a stable roster entry from device, character definition and spawned instance. A run request must explicitly describe active players/characters; one assembler owns initialization and registration. Scene array position is not player identity. This is a dependency for every input, ability, reward and UI consumer. | ARCH-01, GAME-09/16/22 |
| Input | InputManager polls legacy axes/KeyCodes, generates joystick-numbered keys and exposes a global detection/layout flag. Player chooses gamepad or keyboard per axis, rather than consuming one owned action source. TutorialPlayer merges slots 0 and 1. Legacy references occur in 21 files including one Editor fixture. Package manifest/lock contain no com.unity.inputsystem entry, no .inputactions assets were found under Assets, and activeInputHandler is 2. That setting alone is not a completed migration. | Pair devices explicitly; use per-player Input System actions and a narrow gameplay input boundary. Keep shared-menu navigation and per-player reward selection contexts explicit. Replace global any-controller glyph/layout state with the owning player's binding/device context. Persist bindings through the save/config boundary. | ARCH-01, GAME-24 |
| Player behavior | Player, 960 lines, combines input, Rigidbody velocity, dash direction, targeting/search/sort, health/regeneration, crowd control and presentation. PlayerModifier reads selected characters through GameManager and recalculates in Update once ready. | Motor, vitals/damage, stats, targeting and presentation need explicit owners. Decide motor/physics update timing and preserve gameplay feel with characterization cases. Abilities consume these capabilities instead of owning their state. Full stat/target performance claims require measurements. | ARCH-01, PERF-02 |
| Abilities | The former AbilityHolder, 1,512 lines at the audit, held dash, character-specific counters/flags, passive/active effects, spawn references and execution logic. The former ScriptableObject-based Ability stored authored costs/cooldowns and runtime cooldown fields. Both descriptions are historical; the new system is described in the current roadmap. |
Separate definitions from a per-player ability instance/state; isolate execution of distinct abilities and expose effect hooks. Dash belongs to the movement/capability contract. Migrate one real ability first, then catalog the remaining behaviors. Avoid a giant replacement switch or a generic effect framework larger than the needs. | ARCH-01, GAME-10/11, CONTENT-05 |
| Weapons/projectiles | PlayerWeapon, 816 lines, mixes aiming, fire/reload timing, damage calculation, UI and many perk flags/modifiers. PlayerAttack transfers damage/ownership and numerous effect flags while resetting pooled state on enable. | Separate weapon state, attack execution, damage context, targeting and feedback. Supply owner/transform/state before activation. Character/upgrade behavior should use defined effect hooks, not arbitrary writes into every attack field. Preserve current damage attribution and interactions. | ARCH-01, GAME-08/10 |
| Run orchestration | GameManager, 775 lines, still contains reward data/UI, score/currency, timers/HUD, game-over presentation, unlocks, leaderboard preparation and legacy proxies. GameStateService and RewardRoller are real extractions but still use some manager-owned data. | Keep composition/run coordination thin; assign authoritative state, run statistics, reward ownership, results/progression and presentation separately. Define those contracts early, migrate each responsibility with its workstream rather than doing a giant GameManager rewrite first. | ARCH-01, GAME-02/22/24 |
| Pool/spawn lifecycle | PoolManager initializes its dictionary in Start, keys pools by stripped object name, and activates reused objects before setting their requested transform. Enemy.OnEnable reads difficulty/player state and publishes spawn events. Items.OnEnable publishes before Reset; PlayerAttack resets on enable. | Establish prepare/configure/activate and deactivate/reset/return order, stable prefab/pool identity and idempotent cleanup. The minimal lifecycle boundary precedes combat/dummy spawns; broad pooling policies come with measured use, not arbitrary caps. | GAME-08, PERF-01/03 |
| Encounters and stage data | SpawnerEventManager mixes schedule evaluation, coroutines, special/boss state and UI. SpawnEvent in SpawnerData contains runtime isActive/isSpawning flags and is mutated by the director. LevelData connects IDs, scene, boss and difficulty schedules; array/catalog conventions remain part of setup. | Author schedules as definitions and keep their execution state in the run. Separate encounter scheduling, enemy lifecycle, stage completion and boss/timer presentation. A scene supplies anchors/bounds/services; data supplies the intended stage. The same contract must support the dummy stage. | GAME-06/10/14/15, CONTENT-01/02 |
| Enemy behaviors | Enemy, 748 lines, spans difficulty stats, targeting, state setup, contact damage, rewards, status/presentation and pool/death paths. Existing EnemyCore/EnemyState/Mechanic/Boss scripts already provide reusable seams. | Retain useful behavior/state components; define spawn context, damage/target access and a single death/despawn policy. Boss-specific behavior remains local rather than pushing it into a central switch. Do not replace the existing state hierarchy merely to rename it. | ARCH-01, GAME-06/08, PERF-02 |
| Rewards and stats | RewardRoller, 493 lines, owns queue/phase plus cards/tweens/effects through GameManager references. Special/boss paths iterate Players.Length. UpgradeSelection hard-codes two selection slots. UpgradeFunction switches effects and writes player/ability/modifier state; Upgrade stores upgradeTaken/modifiedWeight. RewardUIController is a placeholder. | Eligibility/roll, run inventory/counts, per-player decision, upgrade application and reward presentation need separate boundaries. Use active roster IDs; definitions remain reusable. The reward UI rewrite follows those contracts. Existing level-up fixes are regression requirements. | GAME-02/09/10, CONTENT-07 |
| Persistence and content identity | SaveManager, SaveService, static Save, GameDataLoader and resource managers divide persistence/loading/state. Character id, Upgrade.idname and LevelData/StageMap identity already exist; display-name and ID load/save symmetry remains a concern. PlayerDataBinder exists for old types. | Define persistent identity and legacy/input migration at R0/R1; adapt each new owner without deleting old compatibility early. Complete save implementation after the runtime model is coherent. Normal saves are never test fixtures. | SAVE-02/03/04/05/06 |
| Audio/presentation and optional services | AudioService directly saves volume settings. Gameplay code reaches AudioResources, UI and static services. Discord/leaderboard have independent external failure cases. | Audio/presentation consume gameplay events/context; configuration persistence has one owner. Keep unavailable optional services outside core player/combat boot requirements. Full backend work does not block dummy-stage development. | GAME-03, CONTENT-03/04/09, NET-01/02 |
| Tutorial | TutorialManager, TutorialPlayer, TutorialPlayerAttack, TutorialEnemy and TutorialSpawner implement a parallel lesson-specific gameplay path. Incomplete batch 25 extracts menu ownership but does not unify player/combat behavior. | Migrate Tutorial after the shared player/input/motor/combat/stage contracts. Keep objectives, hints and step sequencing; use the same actors and gameplay capabilities. Do not port the tutorial duplication into the dummy arena. | ARCH-01, GAME-18/19/24 |
| Dead/stub code and tools | ControllerItem.cs, JoystickDetectionPage.cs and JoystickDetectionView.cs contain only commented code and have no GUID-reference hits in the scanned serialized files. RewardUIController is an empty runtime class. Existing Editor checks/SpawnDataEditor/UpgradeEditor and TrackerStat may be useful. | Retire comment-only candidates only after final reference/reflection checks; do not delete vendor/tooling because it has no direct gameplay caller. Either implement a real owner for an intended stub or retire it when its system migrates. Adapt existing validators/editors to the new data contracts. | ARCH-01, TOOL-03 |
Line counts identify reading scope, not quality rankings. For example, the lexical scan finds 44 project-type consumers for Player and 27 for GameManager, which makes their boundary changes consequential; those are approximate code-reference counts, not proof of runtime coupling severity.
Initial retain, replace and retire decisions¶
- Retain existing authored content, stable IDs/GUIDs, verified gameplay rules, usable services/state components and meaningful regression cases. Reassess implementation behind those contracts.
- Replace index-driven authoritative player assignment, device polling inside gameplay consumers, runtime state on shared definitions, and mixed player/ability/reward ownership as their workstreams mature.
- Finish migration of remaining scene/prefab/caller bindings with each owner. Recent patches and new classes receive the same review as old code; an extraction that still controls everything through GameManager is not the endpoint.
- Retire old input polling/preset consumers only when all consumers and preference migration are accounted for. A temporary legacy adapter must name its remaining callers and removal gate.
- Defer Tutorial-specific repair, cosmetic UI changes, public content/features, backend redesign and final workload optimization until their prerequisites exist. Keep the old findings and evidence; this changes scheduling, not their verification status.
These are area-level directions. Per-script API/retirement decisions for inventory-only files remain required before those files migrate; the inventory does not imply all 227 files were deeply reviewed. Batch 34 admits only a new isolated lifetime boundary, with no existing caller or asset change, while the phase gate register preserves later investigations.
Input contract direction¶
A roster entry has a stable local player ID, selected Character ID and assigned input context; device IDs and spawned object references are session/runtime details rather than progression keys. Keep roster membership/character selection independent from the scene instance. An assembler validates the request, initializes player capabilities, then registers the player with camera/HUD/targeting. Retrying a stage recreates/reset runtime state without changing the selected character or adopting another player's device by accident.
Use Unity's PlayerInput/device-pairing facilities as the implementation baseline, with a narrow player command/input adapter for gameplay code. Unity documents per-player action copies and device pairing; do not read singleton InputSystem.actions for the local players' gameplay. The selected package version must be checked against this Editor/project at implementation time and pinned; reviewing the 1.14 documentation here is not selecting or installing that version. See official PlayerInput documentation.
Specify Gameplay actions (Move, Dash, ability/stat actions already present), shared-menu navigation and per-player reward commands separately. Define Pause/Back/Submit/Reroll ownership so one button press has one intended recipient. Under the clarified target, keyboard may pair only to P1, P1 may instead use a pad, and each active P2–P4 slot requires a distinct pad. Assignment and per-profile button remapping are explicit. Shared menu navigation may have a designated owner while reward choice remains per-player. Do not blindly create multiple EventSystems for the existing shared-card UI: choose between routed per-player commands and separate UI roots from its actual interaction design. Unity's UI support documentation describes InputSystemUIInputModule and isolated multiplayer UI roots.
R0 still needs exact join/leave/reconnect policy, menu navigation ownership, valid binding overrides and migration from SavedKeybindPreset, gameplay-vs-UI context rules, and every legacy caller/serialized input module disposition. Owner-confirmed: stop supporting split keyboard in the new assignment model. Do not reset currencies/unlocks to migrate controls.
Dummy stage and content authoring contracts¶
Development arena¶
Following the owner's batch-30 direction, the fixture is a development stage/configuration of the shared gameplay runtime scene, with optional development-only entry adapters. Stage definitions and environment bindings are designed first; full encounter composition waits for the enemy/combat dependencies. Do not create parallel production/test manager hierarchies.
Proposed fixture: a small flat arena with visible spawn anchors/bounds, one selectable production character, one passive damageable target and a simple debug readout of roster/device ownership, run state, health and damage attribution. Add a chasing/contact enemy and a short encounter only after the corresponding behavior exists. Use a dedicated development bootstrap and explicit test session/configuration, not a copy of TutorialManager or a requirement to navigate production menus first. The normal character/stage selection should later produce the same request consumed by the fixture/production bootstrap.
Do not create a new "dummy player" gameplay implementation. Initially use the relevant existing component behind an explicit temporary adapter if needed, then migrate that adapter out. Dummy enemy behavior can be minimal, but it must use the real damage/spawn/lifecycle interfaces. No Steam identity, achievements, leaderboard requests or normal save writes are prerequisites. Store disposable profiles outside the project and keep the dummy data and any development-only launcher out of production catalogs/build dependencies. The shared runtime scene may ship after content migration, without references that pull development assets into the build.
| Scenario | Pass/fail condition |
|---|---|
| Bootstrap/reset | Loads directly with an explicit test config; missing required references fail clearly; reset returns to the same clean state without opening MainMenu. |
| Player ownership | One through four players, with P1 keyboard-or-pad and P2–P4 pad-only, each control their own actor; verify explicit pad reassignment between slots and independent persistent remaps; disconnect cannot silently drive another actor or change character. |
| Movement/vitals | Movement/dash/stun/damage/death behave through shared capabilities; paused/UI-owned input produces no gameplay command; reset clears movement/coroutines/status. |
| Combat | Existing weapon and one existing ability hit the target with correct owner/damage/cost/cooldown; interruption, death and reuse leave no stale attack/effect state. |
| Spawn lifecycle | All required owner/transform/runtime values are present before activation; death/despawn/return occurs once; reuse has no stale targets or subscriptions. |
| Stage flow | A tiny authored schedule starts/ends, pauses/resumes and resets without manager duplication or edits to an unrelated gameplay script. |
| Rewards | A development trigger can grant an existing reward; each active player's choice applies once, queues behave, and a new run starts with clean runtime counts. |
| Authoring | A second test character variant/enemy variant/short stage configuration can be wired through documented assets/prefabs and validation, without modifying a central player or stage switch. This is a development recipe test, not a new released feature. |
| Isolation | No production progression/config/score submission changes and no accidental shipped stage/catalog inclusion. |
Add scenario controls gradually with the owning phase. The initial fixture does not require every reward/boss system, a new test-tool framework or a polished UI.
Character recipe¶
One stable content ID; authored stats, presentation/localization, default weapon and ability references; reusable player prefab with required motor/vitals/stats/input/weapon capability references; an explicit initialize/reset/dispose sequence. Resolve the selected definition through the roster/assembler rather than GameManager.Character[playerNumber] or transform.GetChild(0). Find content by stable ID and validate duplicates/missing references. Character data must not contain live player HP/cooldown counters or device assignment.
Before calling this standardized, demonstrate the recipe with a real existing character and a small development-only variant. Existing custom abilities can have dedicated execution components; the standard does not require every possible ability to be expressed through an over-generalized data language.
Enemy recipe¶
An authored prefab/definition with stats, hit points, damageability, behavior/state references, drops and presentation; an explicit spawn context and reset/return policy. A prefab can remain the authoring unit; introduce a separate enemy ScriptableObject only when shared data/validation needs justify it. Avoid configuring the same behavior in two places. Validate required states/components, positive timing values and references before starting a run. Death/despawn/pool-return policies must be clear to the encounter system.
Stage recipe¶
An authored stable identity, scene/composition reference, supported difficulty/schedule data, duration/clear rule, optional boss and progression links. The scene supplies spawn anchors, bounds, camera/environment and required presentation references. The bootstrap assembles services/players/encounters from those inputs. Keep active spawn flags, elapsed timers, current difficulty execution and unlock cache out of shared authoring definitions. Preserve the current persistent StageMap/character/upgrade identity mappings during migration.
Validate missing scene/data references, duplicate IDs, difficulty coverage, invalid schedule timing, absent spawns, incompatible prefabs and unavailable content. Establish whether editor validation or an existing Editor tool should own each check. The goal is to author a stage by wiring known data and anchors, without copying a manager hierarchy or editing a central stage index switch.
Definition / runtime / persistent / presentation rule¶
Definitions contain authored defaults and references. A player/run owns mutable health, cooldowns, stats/modifiers, acquired upgrade counts and encounter flags. Persistence owns unlocks/currency/settings via stable identities and compatibility rules. Views own visuals and focus, and consume state/events; they do not mutate other players' gameplay fields. The composition root supplies required references and lifetime. Record which of these owns each field before moving it.
Optimization candidates, not performance verdicts¶
| Candidate observed in source | When to investigate | Evidence needed |
|---|---|---|
| Player.UpdateEnemyLocations recalculates distances/GetComponent and sorts the list each update; Enemy also searches/updates player targeting. | R3/R4 targeting design, then R9 under real counts. | Target-correctness cases plus CPU/allocation cost at defined enemy/player counts; choose caching/selection frequency from those results. |
| PlayerModifier.Calculate runs from Update. | R3 stat ownership; consider invalidation on actual stat changes. | Verify every temporary/conditional modifier trigger and old/new numerical results; measure before changing update frequency. |
| Pool creation/name keys, duplicate lifecycle work and item coroutines/merging. | Minimal lifecycle in R1, consumers in R4/R5/R6, size/load policy in R9. | Activation/reset/return correctness, retained objects/coroutines, allocations and exhaustion behavior under representative loads. |
| GameManager damage-popup limit runs after popup creation. | Feedback boundary in R7, measured load in R9. | Spawn/allocation/frame costs at current display settings and a specified feedback policy; do not silently remove gameplay feedback. |
| Repeated startup config writes and synchronous save IO. | Persistence boundary design early, actual write-policy work in R7. | Call-site/operation counts, byte-preservation and durability/failure requirements; no claim that these explain GAME-01. |
| UI/stat polling and repeated searches/allocations across helpers. | Owning workstream as discovered, profile afterward. | Real invocation/allocation measurements; do not convert every small Update into event plumbing by rule. |
Architectural improvements can proceed on ownership evidence. A claim that a change is faster still needs measurements. Do not spend the first batches micro-optimizing code already scheduled for replacement.
Outstanding design work and continuation¶
The complete CSV covers all 227 files; its inventory-only rows still require source review when their workstream's API/disposition is finalized. Initial boundaries and fixture standards above are a starting specification. The player/input contract now records the actual legacy source and scene-module migration maps, ownership and behavior constraints. The run/bootstrap contract now specifies that lifecycle and fixture staging. The motor/vitals/stats contract now records its owners, formulas, source maps and comparison cases. The combat contract, completed in batch 29, adds weapon/ability/attack/target ownership, exact ordering/timing constraints, definition/routes and caller/binding/event maps with 26 source-derived comparison cases. Its 96 bindings and 428 event candidates include recovery/prototype content; they are not released-content or runtime proof. It narrows GAME-11 reachability and records CA-01–CA-05 isolation/payload/timing/content/target follow-ups. The original inventory review-depth counts above describe the initial audit; later contract reviews extend that evidence without retroactively certifying all rows. Batch 30 adds shared gameplay-scene composition and scoped-event requirements, with a dependency hierarchy that separates ability state from concrete effects. Batch 31 records the stage/enemy/encounter/event core contract, raw authored/scene/state/event maps, 24 source-derived cases and SE-01–SE-06 follow-ups; these do not certify every imported override, variant behavior or runtime route. Batch 32 records the reward/pickup/progression core contract, extends the existing Upgrade inventory, maps item/effect/binding/caller evidence and records the owner-confirmed shared distinct picks/N+1 offer rule. RP-01–RP-05 retain application/payout/participation/scarcity/import follow-ups; GAME-25 is the separate source mastery truncation finding. Batch 33 records the persistence/input preferences/UI/service integration contract, including source schema/preset/readiness/adapter maps and 24 comparison cases. PS-01–PS-05 retain import, concrete package schema, failure recovery, per-slice imported wiring and external validation gates. Batch 34 reconciles the core checklist and defines the exact first R1a files/compatibility/rollback/verification. Concrete package schemas, imported scenes and secondary APIs remain explicit pre-migration gates; the isolated lifetime core does not clear those later requirements.
Batch 25 remains incomplete and parked by the owner-directed dependency change. Preserve its code/evidence (now saved in local checkpoint 93d92282) and decide retain/rework during R8 integration. Do not build it merely to keep the old queue moving. The audit itself does not authorize unrelated features, a public demo, Tutorial redesign or dedicated freeze work. The later 2026-10-26 owner direction explicitly adds planned four-player capacity and remapping; the input contract owns those requirements.
Batch 34 reconciles the seven core contracts and records the exact first R1a slice. The gate register retains all 27 PC/CA/SE/RP/PS follow-ups and nine unexecuted lifecycle check groups. This admits the isolated lifetime core; it does not certify deep review of every script or waive imported wiring, input schema, participation/payout or external evidence gates. Existing gameplay remains unmodified.
Coverage update, batch 38: four reviewed/SDK-tested scripts bring path coverage to 243, with the earlier 239 rows unchanged. A single authored action definition feeds per-slot InputUser-owned copies and a raw command/context boundary. Eight simulated-device groups pass, including actual shared-scene retry/reload. No old input consumer or Player/AbilityHolder owner has moved; legacy-feel comparison, persistent profiles/remapping/recovery UI and actor migration remain required. No performance improvement is claimed.
Coverage update, batch 39: three reviewed/Editor-tested scripts bring inventory path coverage to 246, preserving the earlier 243 rows. Versioned input preferences and audited legacy preset conversion now have a narrow in-memory owner; 9/9 Edit Mode groups pass. No production save/write path or input consumer is migrated. Live drafts, interactive remapping/recovery, persistence and legacy-feel/physical evidence remain required; no measured performance claim.
Coverage update, batch 40: two new reviewed/Play Mode-tested scripts bring path coverage to 248; two edited input-owner rows now carry current metrics/evidence, while the other 244 earlier rows remain unchanged. Profile application and reversible drafts share the existing session/user owner. New 9/9 and prior 8/8 groups pass. Capture/UI, safe persistence and physical/legacy-feel/actor migration remain gated; no measured optimization claim.
Coverage update, batch 41: two new reviewed/Play Mode-tested scripts bring path coverage to 250; three amended input-owner rows carry current metrics/evidence, and 245 earlier rows remain byte-preserved. Device-owned capture composes with the existing draft/session rather than replacing pairing. New 10/10 and prior draft 9/9 groups pass. Production UI, writer/normal persistence, physical/legacy-feel and actor migration remain gated; no measured optimization claim.
Coverage update, batch 42: four new reviewed/Editor-tested scripts bring coverage to 254, preserving all earlier 250 rows. Full config data, explicit patching and verified file publication now have separate narrow owners; stale/reentrant edits cannot silently replace pending work. Ten Edit Mode groups pass with disposable Linux files and injected errors. Existing runtime source is unchanged; compatibility/caller rollout, Windows/recovery/retention and UI/actor migration remain gated. No measured optimization claim.
Coverage update, batch 43: 255 scripts, with a new Editor compatibility fixture and updated focused GameSettings/ConfigDocument rows. Shared validated role copying replaces duplicate preset setters; loaded preset application no longer saves. This is scoped control-method review, not a full graphics/settings semantic review or measured optimization. One legacy consumer row is updated and one Editor-only fixture is added; production polling consumers remain unchanged.
Coverage update, batch 44: 256 scripts; focused GameSettings/AudioService/LocalizationManager rows updated, 252 other prior rows retained, one Editor fixture appended. Loaded application no longer saves audio/language; first-run screen initialization has explicit conditional persistence, and locale request/subscription ownership is bounded. Eight focused and seven existing settings-screen groups pass. The 23-row legacy input consumer map is unchanged. Broader audio lifetime/playback, locale scheduler/catalog, production writer and actor work remain open; no measured optimization claim.
Coverage update, batch 45: 258 scripts, eight focused inventory rows updated, 248 earlier rows preserved and two scripts appended. Production config ownership replaces whole-view typed serialization at the common boundary and rejects bypass writes, without rewriting player/progression methods. Nine existing paths change and four are added, including one Bootloader reference. Ten new plus 34 regression groups pass. Input consumer membership stays 23 with one updated migration note. Full player/startup acceptance, recovery/retention/stale-lock policy, Windows and actor work remain open; no measured optimization claim.
Coverage update, batch 48: 259 scripts. One existing AnimFunc row is updated from focused canvas-coordinate review and Linux verification; the other 257 prior rows stay byte-preserved and one Editor runner is appended. Pixel/anchored-unit mixing left completed page slides visible; bounds-derived endpoints fix the existing behavior. This is a shared presentation defect repair, not Player/AbilityHolder extraction, a new layout or a performance claim. Core player assembly/development arena resumes next.
Coverage update, batch 49: 260 scripts. Three focused rows (Player, PlayerModifier, GameInitialization) update, 256 prior rows remain byte-preserved and one Editor runner is added. Production setup now receives dependencies and awaits the same coroutine when a caller needs completion; the prefab owns an explicit mount. Stat calculation and later Player methods are unchanged. Original-output comparison and one/two-player Linux smoke provide bounded evidence; the shared arena, input/motor/ability and complete lifecycle migration remain open. No measured optimization claim.
Coverage update, batch 50: 263 scripts. Five focused rows update (Entity, Player, input session, modifier data and development window), 255 prior rows remain byte-preserved and three scripts are added. A run-owned actor participant now drives actual production preparation and owns cleanup; a conditional development bootstrap makes its preview inspectable without copying gameplay managers or shipping fixture data. Existing Player motion/resource/damage/status and Entity damage/status methods retain their code. The preview is intentionally inert until the input/motor/capability migration. No measured optimization or complete gameplay claim.
Coverage update, batch 51: 266 scripts. Two input rows update, 261 prior rows remain byte-preserved and three scripts are added. The new keyboard adapter reproduces actual original axis measurements; separate pressure metadata fixes information loss at the planned consumer boundary without switching production movement. Original Player/Entity/AbilityHolder code remains unchanged. The new capture/check runners are Editor-only; physical analog/input and motor integration remain open. No measured optimization claim.
Coverage update, batch 52: 270 scripts. Eight focused rows update, 258 prior rows remain byte-preserved and four scripts are added. Player now delegates motion state/calculation to one motor; the production facade and real development actor use it. Session-owned clocked keyboard history and measured per-axis gamepad filtering supply the new actor. The old Player vitals/damage/status suffix is unchanged. Source/SDK/scene/native evidence is scoped; complete motion consumers, ability/resource/combat and physical/Windows acceptance remain open. No measured optimization claim.
Coverage update, batch 53: 272 scripts. Shared motion constraints preserve the old calculation; explicit camera/callback ownership now serves the prepared actor. Five focused inventory rows update and two scripts are added; other rows remain unchanged. Ten boundary and ten motor groups pass headlessly. Full integration and the remaining R3 capabilities stay open. Subsequent work follows the owner's grouped lightweight-verification workflow in the active plan.
Coverage update, batch 54: 276 scripts. Two focused inventory rows update, 270 remain unchanged and four scripts are added. Stat calculation now accepts explicit primitive inputs/effects and returns outputs; resource rules use a separate clock/transaction owner over existing state. Compatibility fields and direct callers remain migration work. Original stat/setup and focused resource checks pass headlessly; ordered damage/status, death/revive/dash, shared-scene activation and full integration remain open.
Coverage update, batch 55: 281 scripts. Two focused inventory rows update, 274 remain unchanged and five scripts are added. Player delegates ordered damage and death/revive sequencing; the revive upgrade no longer edits actor internals. Legacy character effect bodies remain isolated in a named compatibility adapter. Original damage/status/revive and focused pipeline/callback checks pass headlessly. Live activation/cancellation, status/dash ownership, joined-slot/run registry and full integration remain open.
Coverage update, batch 56: 285 scripts. Five focused rows update, 276 remain unchanged and four scripts are added. Player-owned dash admission/completion and shared Entity status rules replace their former method bodies, retaining legacy state/perk/service adapters. Scoped generation guards prevent retired dash/freeze completion after lifecycle changes. Original dash/status and focused ownership/regression checks pass headlessly; explicit shared-scene composition, ability/cooldown services, remaining caller migration and full integration stay open.
Coverage update, batch 57: 289 scripts. Four focused rows update, 281 remain unchanged and four scripts are added. Opted-in actors own private ability copies and coroutine work; shared cooldown arithmetic preserves original traces. Legacy production ownership and concrete effects/services remain adapters. Ownership, original-clock, scene release/failure, seven-character definition/weapon handoff and launcher regression checks pass headlessly. Actual dash input and combat integration remain open; no measured optimization claim.
Coverage update, batch 58: 293 scripts. Eight focused rows update, 281 remain unchanged and four scripts are added. Shared dash rules now accept explicit dependencies; development actors consume assigned dash from the movement driver's existing frame and own required stamina/immunity ticks and work cleanup. Fifteen focused groups plus original dash/status and ability/scene/launcher regressions pass headlessly. Full vitals/life/stat caller integration, concrete effects and combat remain open. No measured optimization or complete gameplay qualification claim.
Design review, batch 59: source/inventory remain 293 scripts. The ability-module contract reviews cross-system mechanisms rather than declaring all files deeply audited: views/defense authority, automatic/conditional and count-based skills, projectile/carrier/summon routes, damage phases, stat sampling, child effects, pickups/evolution and HUD identity. The new 101-type literal reference index supplements the authored catalogs; 92 types name runtime candidates in 17 files, with indirect/serialized routes explicitly excluded from absence claims. Eight selected prefab/object bindings resolve by GUID/fileID; no Unity/import/runtime acceptance is added.