Player-system overhaul execution plan

Historical working record: The details below describe decisions and source state at the time they were written, including superseded plans and verification status. For current scope use the playable-game roadmap; for implemented hook usage use the hook reference; for observed checks use the CLI report and playable-path report.

2026-10-28. This is the dependency plan for the direction in the handoff. It supplements, rather than replaces, the detailed behavior, authored-content and acceptance records in player capabilities, ability modules, combat, input, and run bootstrap. Those contracts and their inventories are the source of individual formulas, serialized routes and comparison cases. Proposed boundaries below are not claims of implemented functionality. No gameplay or platform gate is closed by this plan.

Current milestone order · 2026-10-29

See system milestones for the dependency order and future verification gates across player assembly, movement, abilities, enemies/spawning, stage, rewards and GameManager integration. Earlier progress notes below are historical where they conflict with current code. Editor import, compilation and tests remain deferred.

Discussion notes for the next cleanup task · 2026-10-29

Before migrating the remaining abilities, review and organize player scripts by responsibility while keeping ability definitions together; preserve Unity metadata when moving files. Investigate a shared ordered hook-registration helper to remove repeated storage and disposal code while keeping each gameplay stage explicit. Trace the current scene and movement-driver dash routes, decide their ownership, move dash state out of AbilityHolder, and retire obsolete paths as their callers migrate. Classify scripts and callers before deletion; input redesign remains a separate workload. These are proposals for discussion, not an implemented design or an instruction to begin work.

Current cleanup state · 2026-10-29

The planned source cleanup is complete and remains unverified. AbilityHolder no longer owns the migrated ability state listed in the later cleanup notes; serialized visual references and the unmigrated sword/orb paths still live there. Player-owned behavior, pending configuration and shared character settings replace the migrated fallback values. The runtime groups hook, cooldown and coroutine code in partial files; its ability-type identity and retained-registration policies remain unresolved. No Unity import, compilation, tests or build have been run. The older sections below are historical where their bridge or fallback descriptions disagree with these notes.

Cleanup audit · 2026-10-29

Requirement	Current evidence	Status
Remove migrated holder/modifier state and fallback bridges	Current holder and modifier source, staged diffs, and removed-member reference scans	Source cleanup made; dynamic and runtime behavior unverified
Keep creation with each ability and use contract-based hooks	Ability.CreateBehavior, AB_ overrides, and runtime hook registrations	Source architecture present; runtime registration and removal unverified
Give cooldown and work a player owner	Runtime cooldown/work partials, scene/shared dash integration, and global-worker call inventory	Source paths moved; timing, cancellation and reentry unverified
Preserve asset and callback connections	Staged prefab/scene review, metadata comparisons, asset GUID and callback-name scans	Text-level checks only; Unity import and invocation unverified
Decide whether to remove AbilityType	Serialized values, runtime keys and shared-identity inventory	Retained with migration dependencies recorded below
Preserve understood behavior and document unresolved cases	Ability/stat source comparisons and the follow-up list below	Some source rules traced; startup, co-op, lifetime and gameplay equivalence remain unverified
Deliver one commit after cleanup	Git history	The source cleanup is recorded in the commit containing this note

These findings do not establish compilation, Unity import, tests or gameplay; those checks remain deferred under the owner’s instruction. Remaining ability refactors belong to a later goal.

Outstanding cleanup and integration decisions

• Identity: AbilityType remains serialized and keys admission, behaviors and hook registrations. Shared values include the Dash assets, Concussive/Deadly Impact and Super Magnet/GKCrown. Preserve or deliberately redesign duplicate, evolution and retained-hook semantics before replacing it.
• Preparation and failures: queued changes can be consumed before a later callback or registration fails; constructor cleanup restores the original holder list but cannot undo callback side effects. Reentry, retries, cancellation from another thread and a revive during preparation need a defined policy and later verification.
• Lifetime and removal: several hook registrations and behavior objects intentionally remain after the last matching entry is removed. In-flight work, count displays, suspension, revival, surviving-host reuse and disposal ordering need a consistent policy and gameplay checks.
• Boundaries left for the next migration: holder visual references and the unmigrated Sky Yin Sword/Abyss Orb logic remain, alongside their weapon, companion and upgrade interactions. Existing scene setup still uses an actor-local run context. Player-facing identity, co-op and early acquisition need integration verification.
• Mutable ability list: AbilityHolder.abilities remains a public serialized List<Ability> and aliases the runtime's internal entries after preparation. Production panel/end-of-run readers and scene prefab overrides still use it, and old editor fixtures write it. A possible follow-up is to retain a serialized authored-definition list while exposing a read-only runtime view, migrating those readers, scene overrides and fixtures together. This would make the runtime the enforced mutation owner; its effects on serialization, preparation/reuse and identity need discussion and verification before replacing the field.
• Ability-specific follow-up: verify Proto Barrier health-change timing and pre-acquisition behavior, Ground Breaker's early guaranteed-critical configuration, Jet Propulsion's deferred start and shared visuals, and timed versus count-based cooldown displays.
• Verification and authoring: old editor fixtures do not yet construct the new ownership consistently. Compilation, Unity import, tests, gameplay and platform checks are deferred, and the practical authoring guide must be written once these boundaries settle.

Owner direction: ability-owned implementation · 2026-10-28

This direction supersedes earlier instructions below to retain legacy ability fallbacks until verification. Organize player scripts, names and folders around their responsibilities, and add concise comments where they explain purpose or a non-obvious constraint. Each ability definition/script creates its own per-player behavior; the player owner and hook consumers must not contain a central list or switch naming every ability. The existing type-switch factory is temporary work to remove, not the target architecture.

Trace each ability, move its behavior into its ability script and remove the corresponding legacy logic. If a related piece cannot be moved in the same pass, record the specific remaining work and dependencies, then continue the migration without keeping the old path as a safety fallback. An incomplete or nonworking intermediate state is acceptable. Do not run tests or builds for now. Preserve intended gameplay where understood, and document any unresolved behavior or design question without interrupting routine work. GameManager, input and enemy redesign remain separate workloads.

The ability runtime scripts have been grouped under Assets/Script/Game/Entities/Player/Abilities, retaining their Unity metadata. This historical folder move was organization only; later work replaced the central factory with ability-owned behavior creation and removed the migrated legacy routes. Existing references to historical migration bridges elsewhere in this plan describe the previous approach, not the desired final state.

Agreed naming and organization

• Keep ability scripts together under Player/Abilities/, using AB_ followed by the full ability name, for example AB_EmergencyShield.cs. The main Unity class should match its file name. These scripts contain ability behavior, not just data. One script per ability is the default; split only where actual complexity warrants it. Each player must have independent mutable ability state even when authored data is shared.
• Put ability interfaces together in Player/Abilities/Contracts/, named for participation, for example IBeforeDashAbility. Put the ability owner and genuinely shared ability helpers in Player/Abilities/Core/. A helper's name describes its purpose and does not use the AB_ prefix.
• Keep hook dispatchers with their owning gameplay system, using Hooks_ followed by the stage, for example Movement/Hooks_BeforeDash.cs or Weapons/Hooks_WeaponFire.cs. The dispatcher calls registered contracts at an explicit stage and in an explicit order; it does not identify individual abilities. Avoid adding hooks before a real consumer needs them.
• Group other scripts by their responsibility: player core and life cycle, movement, stats, combat, weapons and companions. Keep the central stat calculation easy to navigate, with ability state owned by the ability and each stat's sources visible in the calculation.
• Preserve Unity metadata when moving or renaming scripts and account for serialized field and asset references. Add comments where they explain purpose, sequencing or non-obvious behavior; avoid comments that merely repeat the code. Written hook behavior, ordering and lifecycle belong in docs/contracts/.

These names and folders are targets, not claims about the current implementation. First replace the central ability-type factory with ability-owned creation and organize the existing scripts as their behavior is migrated. Trace asset bindings, upgrades, hooks and cleanup; record unresolved dependencies before removing old logic. Per-ability work must not expand the central switch.

Interrupted ability cleanup

Meditate, Last Stand and Reload Shield clear their owned active state and views when their work is cancelled. The contract note records the resulting lifecycle policy difference and unresolved revival decisions.

Existing player ability ownership

The existing player setup now attaches and initializes PlayerAbilityHost after its character ability and initial cooldown setup are collected. This creates the same player-owned ability runtime for that active actor without rerunning holder initialization. The host enables owned work, suspends it on disable, resumes on enable and disposes it on destruction. This supersedes earlier notes that the existing setup never creates a runtime; it is an unverified integration step, not a claim that the production loop works.

Existing scenes do not yet provide the shared run context or stable player identity at this setup point. The host currently creates an actor-local context and identity with no shared run cancellation; replace this with the real run lifetime and roster identities when those deferred interfaces are connected. Legacy global work, character setup ordering, acquisition/UI identity, death/revive, scene teardown, co-op, pre-initialization effects, Unity asset bindings and all gameplay require integration and verification.

Contract and hook organization progress

The existing tick, attack construction, critical, damage reaction, damage reflection, dash cost, health damage, pre-immunity, shield, thorn retaliation and weapon fire interfaces are now separate files in Abilities/Contracts. Their dispatchers use Hooks_ names and reside under the relevant ability core, movement, combat or weapons folder. This reorganizes existing stages without creating new behavior; Unity script metadata moved with the dispatchers. Further player, weapon and legacy code still needs migration. No compilation, Unity import, tests or build was run.

Jet Propulsion upgrade route

The existing upgrade now starts Jet Propulsion through its owned ability, and the old holder activator and coroutines are removed. See the contract note for timing and owner-composition limitations.

Retired damage ability methods

The unused legacy holder methods for ten migrated damage abilities were removed. The contract note records the remaining lifecycle dependencies; the Jet Propulsion upgrade route was subsequently migrated.

Super Magnet ownership

Super Magnet now owns its coin-progress event through a pickup hook. Its contract note records the shared serialized type with GKCrown.asset and remaining upgrade integration.

Potion ability ownership

Alchemist Touch, Stalwart Body and Invigorate now participate in distinct pickup stages, with Stalwart Body's count owned by its ability. The contract note records ordering, capacity handling and remaining pickup work.

Passive stat ability definitions

Ten stat-only abilities now use their own acquired definitions as passive identity while their formulas stay in the central calculation. The contract note records affected abilities and remaining verification.

Survival Instinct ownership

Survival Instinct now owns its sampled health state, while movement and regeneration formulas remain in the central stat calculation. The contract note records the initial-sample and runtime integration limits.

Transcend Eclipse ownership

Transcend Eclipse now owns its automatic health-dependent attack selection. The contract note records the remaining impact and pooling work.

Heaven Yang Sword ownership

The Heaven Yang Sword ability now owns its automatic summon request and maximum count; the contract note records the remaining sword and paired-character path work.

Rocket Barrage ownership

Rocket Barrage now owns its automatic missile volley and upgrade modifiers. The contract note records target, pooling and cooldown dependencies.

Artemis Burst ownership

Artemis Burst now owns its automatic arrow volley; its contract note records pooling, upgrade and cancellation follow-up.

Meditate ownership

Meditate now owns its readiness and stacking state and uses the existing central stat calculation. Its contract note records admission and interruption follow-up.

War Cry ownership

War Cry now owns its automatic cycle and active state while the central stat projection retains its damage and damage-reduction formulas. Its contract note records impact, pooling and lifecycle follow-up.

Ultra Magnet ownership

Ultra Magnet now owns its timed pickup-radius contribution and automatic tick. Its contract note records the cancellation difference and remaining pickup integration.

Automatic ability legacy execution removal

Frenzy, Proto Barrier and Light Blessing no longer execute their legacy holder update, activators or coroutine bodies. Their owned tick hooks are the execution path; see the contract note for the pre-acquisition and missing-runtime gaps.

Ability state lookup and projectile impact follow-up

The player ability owner no longer contains a separate lookup method for each named ability. Existing holder and stat bridges use the shared generic module lookup instead, including the three timed dash buffs. The owner still stores modules by AbilityType, and the generic lookup returns the first matching module class, including retained modules; distinct definitions sharing one behavior class need an explicit identity policy. The remaining named holder bridges and legacy state are not yet retired. This change is uncompiled and untested.

Projectile impact migration must account for effect state belonging to the attack, not simply the player's current loadout. Existing explosions and bounces copy only selected flags, may not receive a player reference, and can outlive ability removal; pooled attacks can retain values. A possible direction is an attack-owned effect payload with explicit child inheritance and reset policies, so impact handlers do not need ability-name checks. Trace and preserve each spawn route, attribution and current fresh/reused differences before adopting this; the approach and any intentional behavior changes are recorded for discussion, not yet implemented.

Lucky Find ownership

Lucky Find now owns its gem-spawn work and participates in a generic excavation stage triggered by Ground Breaker. The contract note records the remaining pickup and lifecycle dependencies.

Ground Breaker attack damage

The Ground Breaker damage override is now owned by the ability at its existing construction position. Its contract note records removal and pooling considerations.

Star Burst ownership

Star Burst now owns its movement-sensitive weapon charge, projectile selection and damage stage. The contract note records ordering and remaining character-weapon dependencies.

Multishoot weapon ownership

Multishoot now owns its extra-shot and damage-scaling stages; Proto Barrier supplies the existing spread override through a contract. The contract note records the remaining character interactions and spread-provider policy.

Companion attack interval

The drone's Proto Barrier interval adjustment now uses an owned companion hook rather than a named ability check. The contract note records its current drone-only scope.

Proto Barrier weapon ownership

Proto Barrier now owns its default weapon projectile roll and attack payload flag. A generic acquired projectile-override contract preserves its Neo Sword interaction; the contract note records remaining multishoot, drone and impact work.

Neo Sword ownership

Neo Sword now owns its combo state, weapon-fire transition and attack color stage. The contract note records the remaining Proto Sword, initialization and character weapon work.

Luster Burst ownership

Luster Burst now owns its shot counter, projectile selection and attack-construction effect. The contract note records its interaction with Artemis Burst, upgrades and the remaining weapon work.

Ground Breaker ownership

Ground Breaker now owns its fire and critical counters, burst state and cooldown. Its contract note records remaining damage, projectile and lifecycle work.

Weapon lifecycle and ability state

Weapon start and destruction now notify retained ability lifecycle handlers. Soul Wager uses those notifications to reset or release its per-weapon counter; the contract note records remaining reuse and teardown cases.

Soul Wager and Double Edge ownership

Soul Wager and Double Edge now participate in an ordered post-critical weapon-damage stage. The contract note records per-weapon state and remaining lifetime dependencies.

Critical ability ownership

Fatal Flow Knowledge and Piercing Bullet now own their critical-hit participation; the contract note records ordering and remaining verification.

Projectile ability construction

Six projectile effects now have ability scripts and weapon-construction hooks. Their contract note records the required impact follow-up; companion application was subsequently restored through owned companion hooks.

Weapon ability fallback removal

Migrated weapon-fire, attack-construction and critical abilities now run through their owned hooks without duplicate legacy branches. The contract note records affected abilities and remaining dependencies. The wider weapon and companion overhaul remains open.

Dash ability admission

Dash admission now belongs to the Dash ability and player-owned runtime on both input routes. See the contract note for lifecycle, cooldown and remaining movement integration.

Dash buff stat ownership

The central stat calculation now reads Tactical Fire and Run and Gun's player-owned active state without legacy multiplier fallbacks; Focus Dodge's holder flag also reads owned state only. See the stat ownership note for remaining serialized data and integration work.

Dash ability fallback removal

The duplicate dash ability checks and migrated holder coroutines have been removed. Both dash routes now dispatch owned hooks where the runtime exists; the contract note records remaining composition, state and lifecycle work. No runtime equivalence is claimed.

First ability-owned creation migration

The central PlayerAbilityModules type switch has been removed. The 35 existing migrated behavior scripts now use the AB_ naming convention, and 36 matching authored ability assets reference those scripts. Their definitions create the existing player-specific behavior from within the same file; the player ability owner registers supported hooks. The before-dash contract now lives in Abilities/Contracts/IBeforeDashAbility.cs, and its dispatcher is Movement/Hooks_BeforeDash.cs. Existing script metadata moved with the renamed scripts; asset identities were not changed.

This is an intermediate step, not a finished ability system. Other ability assets still use the generic Ability definition, whose default currently supplies no owned behavior. Existing legacy branches and holder properties remain and must be migrated or documented and removed as requested; they are not intended as the final fallback. Registration and state lookup still use ability types, so duplicate definitions of the same type and their eventual identity need review when ownership is revised. Other legacy hooks and callers still need review. No compilation, tests, build, Unity asset import or gameplay verification has been performed; in particular the changed asset script bindings and serialization need later verification.

Migrated damage ability fallback branches have been removed, including the Electrical Thorn Armor-to-Judgement fallback. The damage-stage note lists the remaining legacy effects and the intentional gap for players without an active ability runtime. Other legacy callers, holder methods and property bridges remain to be traced and retired.

Last Stand now has an ability-owned lethal stage, replacing its old damage branch and holder coroutine. Its remaining holder accessors, lifecycle and runtime composition remain unverified.

Stellar Shield and Reload Shield now have owned activation and shield stages; Reload Shield also registers a weapon reload hook. Their asset binding, timing, interruption and runtime integration remain unverified.

Owner priority: workload categories · 2026-10-28

Focus implementation now on the player domain: character/player assembly and state, movement/dash, stats/resources/life, abilities and their owned behavior, weapons/attacks and companions. AbilityHolder is one part of that overhaul. Use the dependency plan below as the full architecture map, but execute player-domain slices first rather than waiting for the other domains to be overhauled.

The game flow and input domain covers GameManager, menus, scenes, input assignment and their integration. The enemy domain covers enemies, targeting, spawning and enemy abilities. Their redesign and integration work is deferred for now. Rewards, UI and other cross-domain consumers retain their existing ownership and are integrated in their respective later work. Record affected dependencies when legacy ability routes are removed, and do not claim an end-to-end player loop. Tests and builds are paused; compilation, if performed, is a separate check and must be reported.

The acquisition and evolution removal bridge now connects these callers to the player-owned runtime while retaining existing legacy routes and callback signatures; it is uncompiled and untested. Definition-aware reward and GameManager consumers remain deferred. Follow with real player-owned ability modules and ordered capability hooks, player stats/life and weapon/character paths as their dependencies permit. Owner update: continue implementation without pausing for routine choices or approval for each ability. Record potentially better approaches, their tradeoffs and gameplay/design effects for later discussion; leave preference-dependent or gameplay-changing alternatives on hold while continuing independent work. Record accepted changes in the relevant contracts and plan.

Ownership and integration sequence

The rows below record the original dependency map. Their legacy bridge and removal conditions are historical and are superseded by the owner direction above: move or document related ability work and remove its legacy logic without retaining a fallback. Preserve the established one/two-player production baseline and the owner's two-part stat design where understood. Record each implementation and its unverified boundaries in its owning contract. Do not run tests or builds for now; report compilation separately if performed.

Order	Owner and integration work	Bridge and removal condition
1. Assembly and identity	Extend the existing run participant's inactive preparation, slot/character selection and input ownership into real production entry. Prepare character, weapon, ability definitions, stat inputs, resources, views and feedback before activation. Keep roster/input identity across death and retry; actor state belongs to one run. Integrate camera, HUD and run registration at their existing readiness points.	Keep legacy scene setup while production composition is incomplete. Remove a setup route only after its serialized scene/prefab callers and character initialization have moved and exactly one route owns each actor. Existing shared-scene movement/dash is partial, not a full player loop.
2. Motor, resources and life	Use one assigned command frame for motor and dash; keep the current cost/admission/launch order and character parameters. Compose health/stamina regeneration, status duration, ordered damage, death/revive and run participation around their existing extracted owners. Preserve direct resource costs versus damage and all early exits.	The Player/Entity facade and legacy damage/dash adapters remain until each caller, callback and effect has an equivalent owned path. Do not enable the entire legacy update chain in the shared scene. Death, revive, suspend and run retirement need separate cancellation/reset policies.
3. Stat ownership	Keep base inputs and final values together in the player stat state; keep named source calculations centrally navigable in PlayerStatProjection (split by stat only if the source index stays navigable). Move ability state to its module and read that state in the central calculation. Migrate PlayerModifier mutation methods, upgrade/evolution writers and consumers together. Preserve interval units, operation order, previous-frame dependencies, casts, live reads and current calculation frequency.	Retain serialized/public PlayerModifier fields and facade while direct readers/writers migrate; remove each only after source and serialized references are accounted for. Do not calculate an effect in both the module and projection.
4. Ability ownership and identity	Evolve PlayerAbilityRuntime/Host into the per-player acquisition, first-match admission, work and registration owner. Keep authored definition identity separate from private mutable copies, including duplicate alias/reset behavior and distinct definitions of the same type. Connect existing character and Upgrade metadata to HUD through that identity; migrate EQUIPABILITY and evolution callbacks through acquisition/parameter operations.	Legacy AbilityFunction and serialized callback signatures remain for unmigrated production routes. Route each acquisition/execution through exactly one owner; retire the bridge only after callers and UnityEvents are accounted for. Time admission, display time, effect duration and count/charge meters remain distinct.
5. Ordered hooks and first real modules	Add each narrow hook at its real owner with its first migrated consumer. Begin with the ordered pre-dash stage, preserving the position of each legacy effect and cooldown/bypass behavior, then apply the same discipline to fire, construction, crit, damage, pickup and lifecycle stages. Module state and work are player-owned; central stats read module state.	An explicit mixed sequence replaces a migrated legacy slot; acquisition order must not reorder effects and no slot may execute twice. Document signature, context, phase/order, reentrancy, registration/removal, exception and cooldown semantics in the hook catalog. Do not claim IPlayerDashHooks or the named legacy list is the registration API.
6. Targets, attack execution and leases	Move target queries with their distinct weapon, companion, bounce and carrier policies. Introduce production receiver and prepared inactive attack/carrier leases alongside actual callers; reset payload, owner, target, transform, collision, motion and delayed work before activation. Preserve hit-budget/feedback ordering, attribution and route-specific child inheritance.	Existing Enemy/PoolManager and projectile adapters remain until all affected spawn/return routes have explicit payload and lifetime ownership. Fresh/recycled differences and omitted fields remain CA-02 investigations, not assumed balance corrections.
7. Weapons and character paths	Move target/range/charge admission, reload and fire stages, each projectile's construction/crit and ordered impact into their actual owners. Preserve original random calls and captured/live reads. Migrate Wu Ran swords, Tiamra orbs and Zenova charge/missiles with their weapon data, summon/contact/return timing, hooks and attribution; inspect every other catalog character before changing shared assumptions.	Preserve the held weapon even when it is ornamental as an attack origin. Companion attacks continue to reach the appropriate weapon hooks until equivalent owners replace them; never run the old ordinary shot in parallel with the special path.
8. Remaining ability families	Migrate automatic and timed buffs; count/charge effects; defenses and lethal hooks; dash/resource effects; delayed volleys; persistent summons; attack/impact and secondary effects; pickup/stat/evolution participants. For each, follow the definition and upgrade inventories through actual execution, state, visual bindings and cleanup. Implement no placeholder/new content.	Move a complete behavior and its real callers as one slice; remove its legacy slot only when all execution, evolution, UI and serialized paths have a single authority. Preserve same-player refresh and cross-player isolation while recording any intended correction explicitly.
9. Player-facing and connected integration	Bind HUD/status/feedback to owned state and existing character/Upgrade metadata; preserve visual prefabs, audio, indicators and existing menu rules. Connect players to existing enemy, stage, pickup, reward and run/result contracts as needed for the actual loop, keeping deferred stage and UI work in their owning phases.	Keep compatibility adapters until all production scenes and authored callbacks are migrated. Do not create a new loadout, balance, four-player layout, or unrelated feature.
10. Retirement and acceptance	Inventory remaining legacy calls, direct field writers, serialized references and run participation; retire only paths with equivalent owners. Resume focused comparisons and the full integration/platform campaign when the owner requests verification.	Compilation alone does not prove gameplay. Existing checks qualify only their recorded versions; fresh/reused objects, co-op, physical controllers and Windows/Steam remain open.

Migration rules and evidence

For each behavior, trace authored definition and acquisition → owner/state → trigger and precise stage → stat/resource and random operations → attack/target/credit and child policies → views/UI → death, revive, suspend and run teardown. Capture live versus saved values, duplicate and cooldown rules, serialized callbacks, and all consumers before retiring the old implementation. Use the 101-type index for discovery, not proof of reachability; use the existing definition, upgrade, binding and equivalence inventories for coverage. A module is not complete merely because its body moved.

The actual hook catalog must accompany each implementation. Until a stage is migrated, its current adapter is authoritative. During a mixed migration the dispatcher and adapter must have one explicit ordered sequence, and the migrated behavior must be removed from its old position. Preserve synchronous early returns and random ordering. Avoid a speculative universal event bus or unconsumed hooks.

The existing shared scene deliberately quarantines legacy gameplay components. It proves only the recorded movement/dash slices and must not be described as a combat loop. Production still uses legacy paths; integration proceeds by capability and real consumers, not by turning all old updates on. The audio deletion and untracked Linux metadata are pre-existing and excluded from this work. The main-menu freeze remains parked.

Progress

Plan recorded from existing contracts and current source inspection. The authored identity/HUD bridge is implemented as described in ability modules; acquisition and evolution now have player-aware bridges; reward and GameManager consumers remain legacy. It has not been compiled or runtime-tested. The owned actor now also prepares the existing AbilityHolder initial defaults without enabling its legacy Start/update chain; this is unverified. C Combo, Assassination, Berserker Blood, Sure Fire, Unsteady Hand, Blood Thirst and Rebuke now have owned weapon-fire modules, including companion fire calls; see their hook contracts. Proto Barrier now has an owned recharge, reflection and shield module; its contract records the remaining comparisons. The owned dash path now registers Band Aid Roll, Unyielding Malice, Curse of Malice, Tactical Fire, Run and Gun, Focus Dodge, Bomb Roll, Vacuum Dodge, Airstrike, Tidal Veil and Frenzy dash reload at their original ordered stages; Frenzy also has an owned automatic cycle; the hook entry records its limits. The remaining steps are implementation targets; per-ability body-level traces, serialized Unity resolution and runtime equivalence must continue with each slice. No tests or full build were run for this planning work, and no acceptance gate is closed.

Deferred design observations

• Tactical Fire, Run and Gun and Focus Dodge have owned state bridges, while their duration still reads the existing run level. Their cancellation, overlap, death/revive and compatibility cases require verification; other timed effects retain legacy ownership. Their live/captured timing, overlapping activation and cancellation require a coherent player-owned state and centralized-stat migration. Do not silently normalize their refresh/stack or cleanup behavior; carry those cases into the module slice and later verification.

• Bomb Roll and Vacuum Dodge retain the existing activate-before-payload pool path. An inactive preparation/lease boundary is planned, but changing pool behavior here could affect spawned attack timing and inheritance; migrate it with the attack and pool consumers rather than silently changing these abilities in isolation.

• Tidal Veil now has an owned dash/shield module and compatibility bridges, documented in the shield hook. The two cooldown starts are retained; tracked timed admission flags are released on owned suspension, but display, count-state and death/revive behavior still require integration and later verification; production remains on the legacy path.

• Proto Barrier's original holder updates its capacity and color even before acquisition, while the owned module updates them after acquisition. Compare pre-acquisition health-modifier and first-frame behavior when verification resumes before retiring the compatibility path.

• VampireBE and Concussive Impact have owned construction/critical participation. Their shared hit execution and child-effect inheritance remain in the legacy attack system until the planned impact and pool migration.

• Survival Fitness, First Aid, Adrenaline Rush, Flee Boots, Final Form, Panic Frenzy, Enrage and Jet Propulsion now have owned damage-reaction modules; Survival Fitness also supplies the owned dash-cost hook. Light Blessing has an owned automatic cycle. Their contracts record the unverified timing and lifecycle cases.

• Thorn Armor, Electrical Thorn Armor and the existing Judgement retaliation now have owned reaction modules. Their pooling, reentry, timing and lifecycle remain unverified.

• Emergency Shield now has an owned shield, lethal-adjustment and reaction module; its serialization, cooldown and damage ordering remain unverified.

• Unique Constitution now has an owned stamina-to-damage conversion ahead of Emergency Shield; its boundary and interaction behavior remains unverified.

Remaining work inventory · 2026-10-29

These are ten open work areas, not a count of individual abilities or a claim that every area has had no work. Several have partial implementations and depend on further source and serialized-asset inventory:

1. Player assembly, identity, production setup and run lifecycle.
2. Movement, resources, damage, status, death and revive ownership.
3. Base/final stat ownership, central source calculations and upgrade writers.
4. Ability acquisition, identity, cooldowns, registration, removal and HUD bindings.
5. Remaining ability behaviors and their upgrade, pickup, timing and visual paths.
6. Targets, attack execution, projectile impacts, secondary effects and pooled-object state.
7. Weapon fire and character-specific sword, orb and charge paths.
8. Player-owned companions, summoning, attacks, cleanup and weapon/ability interactions.
9. Player-facing feedback and necessary connections to existing rewards, scenes and other services.
10. Remaining legacy and serialized-reference inventory, retirement and eventual verification.

GameManager, menu, scene and input redesign and enemy-system redesign are separate deferred workloads. Tests, builds, Unity import and gameplay/platform verification remain deferred; none of the above is certified complete. The plan's earlier sequence is a dependency map, not ten independently finished milestones.

Opportunist's chest reroll effect now belongs to its ability and is called through a chest pickup stage before reward enqueue. Its existing GameManager dependency and unverified boundaries are recorded in the ability contract.

Ability authoring guide

Create a practical, easy-to-understand guide for future ability authors after the ability architecture has settled. Explain the purpose and relationship of ability definitions/assets, per-player behavior and state, contracts, hook registration and execution order, activation and cooldowns, count-based progress, stat calculations, upgrades, visuals and cleanup. Include a concrete end-to-end example, a checklist for adding an ability, and references to the actual scripts. Distinguish supported patterns from temporary migration bridges, and update the guide when the architecture changes. Do not present the unverified intermediate implementation as the final authoring API.

Ability identity and holder cleanup · 2026-10-29

AbilityType is still used by acquired-entry admission, module and hook-registration keys, legacy callers, and serialized asset values. It is therefore not removed yet. As cleanup proceeds, trace each use and replace it with an appropriate authored-definition or behavior identity; account for shared type values, duplicate acquisition, retained modules, existing upgrade/scene references and serialized data before retiring the enum. Do not equate deleting the enum with deleting asset configuration.

Neo Sword's long-slash active state and combo count now live only in its behavior; the central stat input reads the owned behavior directly. Their holder properties and initial-value fields were removed. The long-slash chance remains a separate unresolved shared input: the current upgrade callback and Proto Barrier also use it, including before Neo Sword is acquired. Move that shared input and its callers together in a later cleanup. Preparation/reset after an existing module, retained module behavior, stat timing and Unity serialization remain unverified. No compilation, Unity import, tests or build were run.

Runtime and Luster Burst cleanup · 2026-10-29

Cooldown admission and owned coroutine work are grouped in PlayerAbilityRuntime.Work.cs, a partial file of the existing runtime, not a separate service or a behavioral rewrite. Hook registration and lifecycle coordination still need further cleanup. Luster Burst now initializes its existing ten-shot count and inactive state inside its own behavior; the holder's corresponding count and active-state bridges were removed. Its threshold, upgrade parameters and other bridges still need migration. Reset after an existing module is created and Unity asset/lifecycle behavior remain unverified; no compilation, Unity import, tests or build were run.

Holder and runtime cleanup in progress · 2026-10-29

Removed holder-only initialization bridges for Panic Frenzy and Electrical Thorn Armor cooldown flags; Assassination, Light Blessing and Rebuke counters; Enrage's hit counter; Ground Breaker's critical counter; Star Burst's charge time; and Stalwart Body's potion count. These values now start in their behaviors, and the central stat snapshot reads Stalwart Body's owned count. Existing setup defaults were carried over where specified; initialization before player preparation and reset after a retained module exists require later review. Remaining holder fields include real upgrade, shared-character, UI and lifecycle callers and must be migrated with those callers.

The runtime now shares small registration and unregistration helpers while still listing hook contracts explicitly and retaining its existing per-type keys and special hook retention rules. This reduces repetition; it does not finish ability identity or hook lifecycle cleanup. None of these changes has been compiled, imported or tested.

Removed duplicate holder fallback flags for C Combo, Panic Frenzy, Final Form, Berserker Blood, Assassination, Jet Propulsion, Enrage, Blood Thirst, Adrenaline Rush and Rebuke. Their remaining holder properties now forward only to an owned module and return inactive without one; constructors start inactive. Those properties are still integration accessors for stat, UI and other callers, not the final ownership boundary. Pre-acquisition writes no longer seed a later module, and reinitialization, retained-module state, UI and lifecycle behavior require review. The associated old editor fixtures have not been run.

The ten active-state holder properties listed above have now also been removed: stat projection, status feedback, weapon critical handling and Frenzy's shared-view cleanup read the per-player behavior through PlayerAbilityAccess. This lookup intentionally retains TryGetModule's existing retained-module semantics. Frenzy, Flee Boots, Proto Barrier and Emergency Shield no longer seed their active flags from holder fallback values. Emergency Shield initializes its five blocks itself; obsolete zero-valued emergency-shield and Flee Boots prefab fields were removed. Proto Barrier's health-modifier adjustment now reads and updates the owned module directly; when no module exists, there is no holder-based pre-acquisition adjustment. The older editor fixtures that manipulate removed holder fallback data need adaptation before verification. These changes are not compiled or gameplay-verified.

Frenzy's upgrade callbacks now set its owned cooldown, attack-speed and dash-reload values directly; its cooldown modifier initializes to one in the behavior. Until acquisition integration handles early callbacks, an upgrade received before the runtime or Frenzy behavior exists is not retained and must be reconciled. The serialized callback method names remain unchanged. One dash-reload holder accessor remains for an old editor fixture and forwards only to owned state.

Frenzy, Flee Boots, Focus Dodge, Tactical Fire, Run and Gun and War Cry status/stat readers now query their ability behavior directly; their holder indicator accessors were removed. Reload Shield no longer initializes from a holder active-state accessor. Stellar Shield and Reload Shield now start with their behavior's zero state rather than copying serialized zero-value holder fields; those fields were removed from the player prefab. Final Form's one-use default now belongs to its behavior. Shield and Final Form holder accessors remain solely for old editor callers and return defaults if no module exists. No tests, compilation or Unity import were run; existing editor fixtures still need revision for owned initialization, and pre-acquisition writes and reset behavior need review.

PlayerModifier's Flee Boots, Jet Propulsion, Sure Fire and Unsteady Hand accessors now forward only to owned behavior state with inactive defaults; their duplicate serialized fallback fields were removed from the player prefab. Flee Boots, Jet Propulsion and Sure Fire start at zero in their behaviors; Unsteady Hand starts with multiplier one, matching the normal modifier setup. The accessors remain for existing stat, weapon, upgrade and editor callers. Pre-acquisition writes no longer seed later abilities, and initialization order, prefab import, reset and editor fixtures remain unverified.

Ground Breaker, Star Burst and Rocket Barrage upgrade callbacks now reach their owned behaviors, with their normal defaults initialized in the corresponding ability. Ground Breaker's status and cooldown holder accessors remain only for UI/lifecycle and old editor consumers, without fallback state. As with Frenzy, an upgrade callback arriving before its behavior exists currently loses the update. A possible common solution is for the per-player ability owner to retain typed pending configuration until the relevant behavior is acquired, without naming abilities in the owner; this needs design and lifecycle review, especially multiple definitions, removal/reacquisition and calls before a host exists. No compilation, tests, build or Unity import were run.

Tidal Veil's initial maximum, stack count and readiness now originate in its ability, and its existing upgrade callback writes to that behavior. Its amount and readiness holder properties remain for old editor fixtures but no longer store fallback state. Ground Breaker's UI reads its owned active state directly. Proto Barrier's capacity-bonus and stamina-cost upgrade values now live in its behavior, with the cost modifier initially one. These upgrade callbacks share the unresolved early-acquisition limitation described above; cancellation, revive and serialized/editor routes remain unverified.

Luster Burst now owns its shot threshold and pierce configuration, and Heaven Yang Sword owns its maximum count; their upgrade callbacks target those behaviors directly. Their standard values remain 10 shots, zero pierce chance, one pierce amount and two swords. These callbacks also have the unresolved pre-acquisition limitation. Luster Burst's skill-amplification setting remains in the holder bridge because Artemis Burst shares it, including when Luster Burst has not yet been acquired; that shared value requires a player-owned configuration boundary before the bridge can be retired without losing behavior. No Unity import, compilation, tests or build were run.

The long-slash chance shared by Neo Sword/Proto Barrier and the skill-amplification percentage shared by Luster Burst/Artemis Burst now live in one PlayerCharacterAbilitySettings object per player. Their existing upgrade callbacks write the shared settings; both abilities read the same live value without an AbilityHolder bridge or dependence on which ability is acquired first. Preparation resets them to the prior defaults (zero and 50). This is a small player-owned shared-configuration object, not an ability factory; it does not solve early upgrades for ability-specific settings. Player reuse, setup ordering and Unity lifecycle remain unverified.

The migrated ability-specific upgrade callbacks now use ConfigureAbility<T>: when the player's behavior exists, the change is applied immediately; otherwise the player's PlayerAbilityConfiguration keeps changes in order for that concrete behavior type, and acquisition applies them before hook registration. This supersedes the earlier notes that these callbacks simply lose updates before acquisition. Preparation clears pending changes, and lookups retain the current behavior after ability removal. Multiple authored definitions sharing a type, callbacks before preparation, player reuse, ordering on reacquisition, errors while applying changes, and teardown require review; this is uncompiled and untested.

Pending ability configuration now survives PrepareInitialState and is cleared when the ability host is disposed, including when disposal throws. This supersedes the preceding note about clearing it during preparation. The player-owned shared character settings still reset during preparation. Retained modules, reentry and cancellation remain unverified.

Remaining holder accessors were simplified to use the shared generic behavior lookup. Stellar Shield's production stat and status readers and Ground Breaker's revive reset now access owned behavior directly; forwarding properties for the older editor fixtures remain until those fixtures are redesigned. No tests or compilation were run.

Last Stand's production consumers now read the owned behavior directly in the player, damage, health-restoration and player-manager paths; the holder accessors remain for existing editor and setup callers. Ground Breaker's revive reset and Stellar Shield's production stat/status reads also no longer use the holder. No editor fixtures, compilation or gameplay checks were run.

Proto Barrier now initializes its runtime copy's cooldown from reload speed when its behavior is created. AbilityHolder no longer checks for Proto Barrier by name or changes abilities[1]; it also no longer resets cooldown flags on shared authored assets before runtime acquisition, which already resets the player copies. This changes the old fixed-slot side effect when Proto Barrier is not at index one and may also initialize a later acquisition, so ordering and the character cooldown display require review. Sky Ying Sword and Abyss Orb startup remain in the holder because those behaviors belong to the separately deferred remaining-ability migration. No compilation or gameplay verification was performed.

Runtime cooldown organization and identity inventory

Timed cooldown tracking now resides in PlayerAbilityRuntime.Cooldowns.cs; coroutine work and activation admission remain in PlayerAbilityRuntime.Work.cs. These partial files are still one runtime and retain the existing cooldown and display timing. The runtime has not yet been redesigned into separate services.

AbilityType currently identifies first-match activation in UseAbility, keys behavior and hook registrations, determines last-entry unregistration, and is still read by legacy ability, upgrade, reward and player callers. The authored ability folder has 21 assets with NoRefereces (ordinal 0); Super Magnet and GKCrown both use ordinal 42. An identity migration must account for these aliases and existing serialized values, duplicate acquisition, retained modules, callbacks and UI identity before the enum and its serialized field can be retired. Replacing the key with a class or definition reference without deciding those rules would change current behavior. No compilation, Unity import, tests or build were run.

The global AbilityFunction no longer contains its unused ability-activation overloads, cooldown coroutines or coroutine-worker list. Source and serialized UnityEvent searches found no production callers; the editor clock fixture now calls AbilityCooldownCycle directly, and four scene components' empty serialized worker lists were removed. Potion and effect routines still use AbilityFunction and are outside this removal. The changed fixture and scene serialization have not been compiled, imported or run; dynamic or external callers were not proven absent.

AbilityFunction no longer adds/removes abilities directly from a holder list or resets shared authored assets when the player runtime is absent. Early player add/remove requests are queued in order on PlayerAbilityConfiguration and replayed through the player runtime after the initial definitions are acquired; the runtime is then the sole owner of copies and ability registration. Unlike the old immediate list mutation, queued operations are not visible to legacy CheckAbility callers before runtime preparation and replay after initial definitions, so the relative order with character acquisition and the immediate Multishoot sword/orb callbacks need further migration. Dynamic or external callers of the removed list overloads, queue failure/reentry, disposal and co-op are unverified. No compilation, Unity import, tests or build were run.

Production character setup now acquires the selected character ability through the runtime after it prepares the holder's initial definitions and replays queued early add/remove operations. This restores their earlier position before the character ability, rather than appending them after it, while avoiding a direct write into the runtime's exposed entry list. Legacy presence checks made before preparation still cannot see queued requests; immediate Multishoot sword/orb interactions and the shared-scene path need further review. No compilation, Unity import, tests or build were run.

Before runtime preparation, player and holder CheckAbility calls now evaluate the initial definitions together with queued additions/removals without mutating authored data. The Multishoot sword/orb checks in the upgrade route use the player-aware lookup. Queued acquisition replay drains requests in order and can accept additional requests while draining. List-only availability calls cannot identify a player's pending changes and still require review. Error recovery, shared-scene setup, summon timing and runtime behavior are unverified.

Player revive now asks the player ability runtime to clear its owned cooldown flags rather than writing through AbilityHolder.abilities. Without a runtime it no longer resets shared authored assets. The upgrade and player-manager presence checks now pass a player to the pending-aware lookup. Shared-scene preparation also replays queued operations before acquiring the character ability. The timing and lifecycle of revive and both setup paths are uncompiled and untested.

Identity follow-up: RewardRoller checks required upgrades using authored asset references against AbilityHolder.abilities, and GameManager end-of-run UI/reporting compares those entries directly to authored upgrades. Player-owned entries are runtime copies, so these connected consumers need the authored-definition mapping rather than reference equality. Their redesign remains in the deferred reward/GameManager workload; do not assume these paths currently resolve acquired definitions correctly.

During runtime construction, the player configuration now exposes the runtime being prepared to generic behavior lookups. Pending-aware presence checks use its current entries and map private copies back to authored definitions before applying queued additions/removals, avoiding reference mismatches while replay is in progress. The preparation reference clears in a finally block. This is an initialization bridge, not proof of safe reentrant acquisition or exception recovery; the path remains uncompiled and untested. A missing System import in the extracted cooldown file was also corrected by source inspection.

Removed unused AbilityHolder state for the old potion-damage, Jet Propulsion iterator, Hydra Barrage counter and Airstrike counter, along with an unreferenced SoldierAbility data class and empty legacy regions. Source and serialized asset searches found no consumers for those members; dynamic callers and Unity import remain unverified.

Pending configuration is now drained one change at a time, so changes after a throwing callback are not discarded with the whole list; the failing change itself is removed before invocation. A failed ability-host construction also clears its initialization guard, allowing a later retry rather than permanently marking the host initialized. Construction cleanup, partial side effects, reentry, retry timing and ordering remain untested.

If runtime construction fails after replacing the holder's list, the constructor now restores the original definition list even if runtime cleanup throws. This keeps a retry from reading the cleared runtime list; it does not undo already-executed queued operations or other side effects. Failure recovery remains untested.

Removed unused PlayerModifier and stat-snapshot copies of Tactical Fire, Run and Gun and Survival Instinct values, plus their zero-valued player-prefab fields. Their calculations already read owned ability state instead. Berserker Blood's old multiplier input was only initialized to one and copied into the snapshot, so its projection now starts from one directly and still applies the owned sample when available; that serialized field was also removed. Editor capability fixture references were updated. External direct writes, previous-frame behavior, prefab import and gameplay remain unverified; no tests, compilation or build were run.

Blood Thirst's duplicate modifier fields and stat inputs were removed: the projection now uses inactive defaults and the owned active/fire samples. Flee Boots, Jet Propulsion and Sure Fire stat inputs and Unsteady Hand's weapon multiplier now read their owned behaviors directly, and their old PlayerModifier accessors were removed. The Jet Propulsion upgrade resets the owned bonus after requesting its crash. The editor fixture and zero-valued prefab fields were updated. Runtime ordering, retained-state behavior and old external writes remain unverified; no tests, build or compilation were run.

Meditate's stat, regeneration and status consumers now read its behavior directly; the PlayerModifier forwarding property and initialization write were removed. Survival Instinct's sample lookup now uses acquired behavior rather than a separate AbilityType check and retained-module lookup. Setup timing, reset after a retained module, status and gameplay effects remain unverified.

Ground Breaker's guaranteed-critical count and threshold now live in its ability. Weapon critical checks and Soul Wager use a shared guaranteed-critical contract; the reset remains between the existing Sure Fire and Ground Breaker critical stages. The hook's retention policy and early-upgrade limitation are recorded in the ability contract. No compilation or gameplay checks were run.

Player-owned shared character ability settings now start with their defaults when the player object is created and reset when its ability host is disposed, rather than being reset by holder preparation. This lets shared-value upgrades applied before runtime preparation survive setup; it changes the old preparation-reset timing. Last Stand's inactive/unused defaults now come from its behavior instead of no-op holder preparation writes. Player reuse, teardown order, upgrades before preparation and revival remain unverified.

Shared character ability settings now reset at ability-host disposal instead of during holder preparation, so early writes are not erased during setup; this changes the old reset timing and remains unverified. Player stat presence and Survival Instinct sampling now use a shared player runtime lookup that also sees the runtime during construction. No tests, Unity import, compilation or build were run.

Hook fields and their registration/removal bookkeeping now reside in PlayerAbilityRuntime.Hooks.cs, a partial part of the same runtime. Acquire and Remove delegate to named hook-registration methods; ordering, type-keyed identity and retained registrations are unchanged by this organization. This is not a new ability-name factory or a separate service. The runtime still needs its later identity and lifecycle review; no compilation or tests were run.

Hook-registration disposal is now grouped with hook registration/removal in PlayerAbilityRuntime.Hooks.cs; it preserves the existing registration disposal order and then clears the groups. The main runtime delegates teardown to that method. Exceptions during an individual registration's disposal can still interrupt the remaining teardown; this existing lifecycle limitation is not resolved or tested by this organization change.

Runtime disposal now attempts cancellation, suspension, all hook registrations and owned ability-copy destruction even when a cleanup step throws, then reports collected failures as an aggregate. Hook groups likewise attempt each registration before clearing. This supersedes the immediately preceding note that a hook failure interrupts teardown; exception shape and reentrant/destroy behavior have changed and remain untested.

A source scan found no remaining serialized propertyPath overrides for the removed modifier and shield fields. This does not validate Unity deserialization, dynamically generated references or the old editor fixtures. No Unity import or tests were run.

The specific reward requirement and end-of-run icon/report comparisons identified above now map private ability copies back to authored definitions. Before runtime preparation, reward requirements also account for queued additions/removals. This is a connected identity fix, not a reward or GameManager redesign. Other direct asset/reference consumers still require inventory, and one/two-player, pre-preparation, evolution and reporting behavior have not been compiled or tested.

Meditate's health-regeneration admission now checks for its acquired behavior instead of a named AbilityType lookup; the stat calculation continues to hold its formula. A source-level field scan found no missing PlayerStatInputs or PlayerStatEffects members referenced by the projection after the cleanup. This scan does not compile the code or verify gameplay.

Ability-host disposal now clears its initialization guard as well as the pending configuration and shared settings, allowing a surviving host to be prepared again through its normal initialization path. This does not by itself rebuild a retired player's authored ability list; actor reuse, error recovery and teardown order remain unverified. No compilation or tests were run.

Special-upgrade database buttons now resolve player-owned ability copies back to their authored definitions, and the ability panel uses the same lookup. A source search of game scripts found no other direct holder-entry to upgrade-ability equality comparisons. UI behavior, player setup and asset bindings remain unverified; no tests, compilation or Unity import were run.

Removed the remaining migrated-ability forwarding properties from AbilityHolder. Older editor fixtures now reference behavior state through an editor-only reflection helper, preserving their previous no-op/default behavior when no ability host exists; their setup still needs a proper owned-ability rewrite before those fixtures can validate this system. The capability fixture no longer randomizes the removed holder property. No editor checks, compilation or Unity import were run.

Removed the list-only CheckAbility overload and the holder-without-player fallback: a player is needed to account for queued ability changes. The player, modifier and holder overloads remain for existing callers; holder callers must have their player assigned. A source inventory found no list-only call sites, but dynamic or external callers and setup ordering remain unverified. No tests, compilation or Unity import were run.

During initial behavior construction, pending-aware presence checks now project the complete initial definition list plus queued changes, instead of only definitions processed so far. After the initial list is acquired, they switch to the runtime entries while queued changes are replayed. This preserves visibility of later initial definitions for construction-time callbacks; acquisition reentry, failure recovery and callback side effects still need verification. No tests, compilation, build or Unity import were run.

Renamed the player damage adapter to PlayerDamageHooks and retained the existing stage boundaries: shield and reaction dispatches take snapshots independently, so combining them could change callback and reentry behavior. The adapter still owns shared health handling while ability effects run through contracts. This is a naming change, not a runtime verification; no tests, compilation or Unity import were run.

If ability preparation and its cleanup both fail, the runtime now reports both errors instead of replacing the original preparation failure with the cleanup failure; the holder list is still restored. This does not roll back callback side effects or consumed queued changes. Failure paths remain unverified; no tests, compilation or Unity import were run.

A failed hook-registration pass now removes the registrations created by that pass in reverse order and reports rollback errors alongside the registration error. Registrations that already existed for the type are left alone. This is not a full acquisition transaction: an entry, behavior, consumed pending configuration or external side effect may still remain after a later acquisition fails. Reentry, error paths and gameplay are unverified; no tests, compilation or Unity import were run.

Jet Propulsion now owns its crash indicator state, and the status panel reads it directly. This removes the holder flag, which had no source writes. The display also now keeps its green speed-bonus color unless a crash takes priority; previously a separate else overwrote green with white. This intentionally changes status feedback, not the movement formula. Crash replacement, suspension and display timing remain unverified; no tests, compilation or Unity import were run.

The ability contract now explicitly marks older migration sections as historical and gives a brief current-source orientation, including the remaining type-keyed identity and holder visual/sword-orb boundaries. The damage-adapter links were updated after its rename. A complete ability-authoring guide remains planned after the architecture settles.

When disposing a runtime that still owns the holder list, the holder now receives the authored definitions corresponding to the remaining entries before runtime copies are destroyed. Duplicate entries retain their order, and an externally replaced holder list is not overwritten. This supports rebuilding a surviving host, but does not restore consumed queued changes or callback side effects after a failed construction. Actor reuse and teardown remain unverified. A source scan found no direct references under common holder/modifier variable names to 71 removed holder members or 15 removed modifier members; this is not a complete call graph or serialization check. No tests, compilation or Unity import were run.

After initialization, type-based presence checks now read the runtime-owned entry view rather than the holder list. The pre-initialization projection remains responsible for pending changes. This removes a second source of truth if another caller replaces the holder list; initialization and runtime behavior are unverified. No tests, compilation or Unity import were run.

A text scan of prefab, scene and asset files for the 20 field names removed from the player prefab found no matching prefab override paths. The only same-name serialized fields found were AudioResources.stellarShieldBlock in MainMenu and recovery scenes, confirmed by their script GUID; those audio fields remain intact. This scan cannot validate Unity import or non-text/dynamic references.

Moved the player ability host and runtime partials into Abilities/Core, alongside their configuration and lookup support. Their Unity metadata moved with them, and documentation links to the host and runtime were updated. This is a folder change only; Unity import and references are unverified.

Source comparison of the former holder preparation with the migrated constructors found corresponding initial values for Frenzy, Proto Barrier, Ground Breaker, Luster Burst, Rocket Barrage, Heaven Yang Sword, Tidal Veil and Emergency Shield, including their shared character settings. Default zero-valued fields rely on C# initialization. This comparison does not prove upgrade timing, reset, serialized behavior or gameplay.

Moved AbilityCooldownCycle and its Unity metadata into Abilities/Core with the runtime that owns its work, and updated its documentation link. Its existing admission and display timing were not changed. Unity import and runtime behavior remain unverified.

Added a current cooldown/progress explanation to the ability contract: timed admission and display are separate, while Luster Burst and Ground Breaker use the displayed fields for event counts. This describes the source, not verified gameplay or a finalized authoring API.

Moved Proto Barrier’s health-change threshold adjustment into its own behavior. PlayerModifier now notifies the available behavior rather than calculating its internal damage state; the shared lookup also sees a runtime being prepared. With no behavior there is still no deferred adjustment. Health upgrade timing and zero-capacity behavior remain unverified; no tests, compilation or Unity import were run.

Ground Breaker now clears its ability-specific cooldown through IPlayerAbilityRevive after the runtime clears generic cooldown flags. The player life cycle no longer names that ability, and the notification uses retained behavior modules as the previous lookup did. Multiple-participant order and revival timing remain unverified. No tests, compilation or Unity import were run.

The revive notification now uses the shared runtime lookup, which can see a runtime being prepared before the host publishes it. It clears currently acquired entries and notifies behaviors created so far; reentrant preparation and any later acquisitions remain unverified.

A source inventory of cooldown-field writes found the migrated production ability work uses the runtime copy passed into its iterator. PlayerDashExecutor also changes its supplied ability’s stamina cost and cooldown flag; production reaches it through AB_Dash with a runtime copy, while the older public Player.ExecuteDash(Ability) still accepts arbitrary assets and is used by editor fixtures. Remove or constrain that entry point when those fixtures and dash API are migrated; external/dynamic callers have not been ruled out. No tests, compilation or Unity import were run.

Removed the unused public Player.ExecuteDash route and its scoped-work toggle after source and serialized UnityEvent searches found only editor fixture callers. Production already uses ExecuteOwnedDash with a runtime copy; the older fixtures now invoke that internal path via reflection and still require a proper owned-ability rewrite. This supersedes the preceding note proposing later removal. Dynamic callers and changed fixture cancellation behavior are unverified; no tests, compilation or Unity import were run.

The player prefab’s initial ability reference resolves by GUID to Dash 2.asset; both authored dash assets point to AB_Dash and retain type ordinal 1. The owned dash route therefore has the expected source-level prefab/asset/script chain. Scene overrides, import and actual dash behavior remain unverified.

A source-level GUID scan found at least one authored ability asset referencing each of the 30 modified AB_ scripts in this cleanup, among 121 ability assets. This does not establish that every asset or scene binding is correct, nor does it validate Unity import. The runtime core source contains no references to these specific ability class names; it registers contracts rather than selecting named abilities.

JETPROP upgrade requests now reach Jet Propulsion through pending configuration and, when applied before runtime activation, wait on the owned behavior until its first active tick. Active requests retain their previous immediate sequence. Multiple early requests coalesce; removal, activation ordering and gameplay remain unverified. No tests, compilation or Unity import were run.

Further authored-identity inventory: Dash 1/Dash 2 share type 1 and AB_Dash; Concussive Impact/Deadly Impact share type 33 and AB_ConcussiveImpact; Super Magnet/GKCrown share type 42 and AB_SuperMagnet. Deadly Impact is an evolution: its upgrade acquires the new definition before the old definition is removed, so current type-keyed registration keeps the shared behavior throughout that transition. Any future identity replacement must explicitly preserve or intentionally redesign this behavior as well as first-match selection, duplicate entries and authored-asset identity. The 21 type-zero assets also remain; these observations are source-level and unverified in Unity.

A text inventory found 28 distinct serialized WeaponEvoData callback names across scenes, prefabs and assets; all 28 still have a public three-argument (Player, float, Ability) method. This confirms names and source signatures only, not UnityEvent targets, import, invocation order or behavior.

Recorded the actual hook-removal exceptions in the ability contract and added a reminder at the removal method: shield, weapon-lifecycle and critical override registrations persist until owner disposal; critical and attack-construction participants declare their existing retention choice. Future lifecycle design remains open.

Staged serialization review: the player prefab changes remove 20 obsolete zero-valued modifier/holder fields and two unassigned holder references, and each of the four changed scenes removes one empty AbilityFunction.coroutineWorkers list. The existing visual prefab references are unchanged in those diffs. Player ability panel, special-upgrade database, reward requirement and end-of-run comparisons now use authored-definition matching. This is a text diff review, not Unity import or runtime verification.

The health modifier now notifies IPlayerHealthModifierAbility rather than naming Proto Barrier. Proto Barrier owns the adjustment and remains the first consumer. Notification uses retained modules and the previous projected maximum as before; handler ordering, pre-acquisition changes and runtime behavior remain unverified.

Rebuke now supplies weapon-only forced criticals through IWeaponForcedCriticalAbility, removing its named check from PlayerWeapon. This is separate from Ground Breaker’s guarantee because Soul Wager did not include Rebuke in its own condition. The retained registration and ordering need verification.

A broader dotted-member source scan of the 71 removed holder names and 15 removed modifier names found only same-named stat input/effect members and the unrelated AudioResources.stellarShieldBlock; no remaining dotted holder/modifier access was identified. Reflection, serialized data beyond the earlier text scans, and compilation remain outside this evidence.

Renamed the production scene dash adapter to ScenePlayerDashHooks, retaining its Unity metadata and its existing GameManager/service connections. It still delegates ability stages to the player runtime; this does not redesign input or scene ownership. Unity import and gameplay remain unverified.

A source inventory found 28 declared hook-registration groups, all 28 used by registration and included in owner disposal. A metadata scan of 54 scripts in the ability contracts/core and weapons folders found no missing or duplicate GUIDs. These checks do not establish removal semantics, Unity import or runtime behavior.

Moved the existing-scene dash weapon-hide coroutine from AbilityHolder to the player ability runtime. The shared-actor wrapper and scene adapter now use the same weapon coroutine, which restores visibility on cancellation. A scene adapter without a runtime no longer starts hide work; overlapping dashes, suspension and presentation remain unverified. No tests, compilation or Unity import were run.

Passive stat and health/stamina modifier presence checks now project initial definitions and queued changes before the ability host is published, then read acquired runtime entries after initialization. During construction they use the full initial definition list and later the replay state, as the existing type-based check does. This changes early setup visibility; aliases, reentry, setup ordering and stat timing remain unverified. No tests, compilation or Unity import were run.

Reviewed the staged constructor/state changes for the character abilities and their connected stat and evolution writers. The reviewed constructors initialize the former holder defaults or use C# zero/false defaults; their migrated upgrade callbacks use pending behavior configuration or the two shared character settings. Berserker Blood retains its previous sample when its health condition does not match, including an exact 20% or NaN sample. This is source review only and does not verify startup order, timing or gameplay.

Shortened the runtime hook declarations by importing their player-system namespace; the hook types and registration behavior are unchanged.

Compared with the cleanup base commit, no public AbilityHolder methods were removed by this cleanup; the removed holder surface consists of state and forwarding properties. Serialized same-name AddAbility calls in the inspected main-menu/recovery data target WeaponEvoData, whose callback remains present. Dynamic callers and UnityEvent resolution remain unverified.

Reformatted the runtime-owned work lifecycle to make construction, replacement, iterator completion and cancellation easier to follow. No work or cooldown policy was intentionally changed. No tests, compilation or Unity import were run.

Consolidated the three pre-publication ability-definition selections into PlayerAbilityConfiguration.DefinitionsBeforePublication; generic stat, enum and authored-definition checks now share the same initial/preparing/holder selection. The pending projection and active-runtime lookup are unchanged. Setup and reentry remain unverified.

A source-name scan found no calls to the removed PlayerModifier helper methods or removed Player.ExecuteDash. Remaining UseAbility calls in the scan resolve to PlayerAbilityRuntime rather than the removed global worker overloads. The scan does not resolve reflection or dynamic calls and is not compilation.

A literal-order source inventory found no duplicate numeric order values among 27 named order properties in AB_ scripts; this includes Jet Propulsion tick order 950. The scan excludes dynamically computed orders, inherited hooks, other files and runtime acquisition combinations, and does not prove dispatch behavior.

Ability runtime preparation now checks cancellation again after registering its suspension callback, so cancellation already observed by that point enters constructor cleanup instead of publishing a cancelled runtime. A cancellation racing after that check and callbacks invoked off the Unity thread still need lifecycle design and verification. No tests, compilation or Unity import were run.

The final staged-file inventory currently includes no audio files or unstaged tracked edits. The 11 newly added staged script metadata files each have a corresponding script and a unique GUID in the Assets tree. This is a file inventory, not a Unity import check.

If acquisition fails and callbacks have not changed the entry list, the runtime now removes the entry appended by that failed acquisition. If the list changed, it leaves the list alone rather than guessing which duplicate to remove. This is not a full transaction: created behavior, cooldown resets, consumed configuration, hook cleanup failures and external side effects can remain. Failure and reentry paths remain unverified; no tests, compilation or Unity import were run.

Renamed the pending configuration collections to distinguish behavior changes from queued ability additions/removals, with comments explaining early upgrade and construction-time lookups. This is a readability change; queued ordering and failure behavior are unchanged.

The 11 literal before-dash Order values, including inherited timed dash abilities, are distinct in the current ability scripts. This extends the earlier literal-order scan; it does not cover dynamic registration or gameplay.

A source declaration scan found no duplicate declarations for the renamed adapters or newly added contracts/hooks; the four PlayerAbilityRuntime declarations are its intended partial files. A Markdown search found no links to the former moved script paths. This is not a C# compilation or Unity import check.

A source inventory of the ability folder found no calls to the removed global ability worker: its remaining AbilityFunction calls are Sudden Death presence checks in four abilities, while coroutine startup is in the player ability runtime. Sudden Death belongs to the remaining ability migration; its interactions must be preserved when that work resumes. This does not cover effects outside the ability folder or dynamic calls.

The six moved or renamed pre-existing script metadata files are byte-identical to the cleanup base. The two shared character values have source consumers in Proto Barrier/Neo Sword and Artemis Burst/Luster Burst respectively, and their upgrade callbacks no longer write holder properties. This is source-level evidence; lifetime and gameplay remain unverified.

Documented at the generic behavior lookup that it can return retained behaviors after removal. The current policy and the separate acquired-module lookup remain unchanged; later lifecycle work should resolve their long-term use.

Cancellation source review: the shared RunLifetime.RequestStop checks its owning thread before calling its private cancellation source, and the existing-scene adapter uses CancellationToken.None. Those two current paths therefore do not expose an arbitrary external cancellation source, and the RunContext constructor is internal; these are the only source construction sites found. The runtime’s suspension callback still requires the owner thread, so future internal token sources and async continuation behavior remain open; no runtime verification was performed.

A whole-Assets text scan found no C# calls through AbilityFunction to the removed global activation/cooldown/worker methods and no serialized method-name matches for those methods or the removed Proto Barrier adjustment helper. The scan cannot find reflection, dynamically constructed names or non-text assets.

Moved IPlayerAbilitySuspension into the agreed ability contracts folder with its existing Unity metadata. The current suspension participant, Jet Propulsion, assigns inactive/zero values and is safe to invoke repeatedly at source level. The runtime can invoke suspension on cancellation, disable and disposal; a general repeated-notification policy and runtime verification remain open.

Moved the shared TimedDashAbility base into Abilities/Core with its existing Unity metadata and updated its documentation link. The ability definitions remain flat in Abilities; timing and behavior are unchanged. Unity import and gameplay remain unverified.

Removed the unused zenovaStarBurstChargeIndicatorEffect and spawnChakram holder fields and their empty player-prefab entries. A whole-Assets text search found no other references or prefab overrides for either name; future Star Burst feedback or Chakram behavior will need explicit bindings if implemented. Dynamic access and Unity import remain unverified.

Removed an unused utilities import and an obsolete holder region label that grouped the remaining dash input and sword/orb methods under “ability update.” The remaining implementation paths were not changed.

Unsteady Hand now supplies its base-damage multiplier through IWeaponBaseDamageAbility; PlayerWeapon no longer names it. The calculation retains the multiplier’s position before the weapon’s fixed multiplier, and the hook is retained after removal like the earlier behavior lookup. Construction-time damage, multiple modifiers and gameplay remain unverified.

Unsteady Hand’s multiplier is now private to its behavior; the weapon reads its effect through the base-damage contract. Source search found no remaining callers of the old behavior property. No tests, compilation or Unity import were run.

Frenzy now supplies its reload-bar multiplier through IWeaponReloadDisplayAbility; PlayerWeapon no longer names Frenzy. This changes display selection only, not actual reload timing. The lookup retains previous first-match/retained-behavior semantics; multiple providers and gameplay remain unverified.

Player core still reads Last Stand’s active state directly for damage and regeneration, and Meditate’s owned value for health regeneration. These are not holder fallbacks; the current reads preserve distinct existing conditions, including the level-up healing exception. A future health-effect contract should model those conditions separately instead of treating every health change as the same event. No gameplay verification was performed.