Skip to content

Ability migration audit

The inventory below records direct references from the 2026-10-29 asset snapshot, before removal of individual Ability assets. The roadmap and handoff describe current work; the CLI report describes observed checks. Asset presence or an AB_ file alone does not prove complete or playable behavior.

Historical mapping

  • Ability mapping: 121 inventoried assets, old GUIDs, cooldown/stamina, linked upgrades and character assets, and direct references.
  • Serialized references: matching GUID references in asset, prefab and scene text.
  • Upgrade links: direct ability/prerequisite links, upgrade IDs and readable operations.
  • Data-only review: the 27 former base-script entries, linked upgrades and recorded operations.

The original scan found 191 direct references: 137 in assets, 53 in scenes and one in a prefab; 112 upgrade ability links and 17 requiredUpgrade links were found. Eight linked upgrades had an empty serialized operation list. The snapshot had 28 base-script Ability assets, including Revive, which remains an action. It did not resolve dynamic references, backend records, Unity deserialization or gameplay. Assets/Resources contains active gameplay upgrades; BossUpgrade is development content, while SpecialUpgrade subfolders indicate other statuses. A location or direct link alone does not prove an upgrade appears in a run.

The 121 old Ability assets and metadata were byte-verified, archived in ability-assets-2026-10-30.zip, and removed from active Assets. Historical recovery scenes retain old references and need those archived assets restored to resolve them. The CSV script paths and references describe the earlier snapshot, not current bindings.

Current identity and behavior

AB_ classes declare code-owned ability data; AbilityDefinitionLookup resolves internal keys without a named factory. PlayerAbilityState stores player-specific values. Character, starting-player, upgrade, prerequisite and weapon-evolution bindings now store keys. Internal keys are separate from permanent four-character reporting codes. Dash's two former assets map to one definition with independent player state; character abilities and Dash do not need invented backend codes. Revive remains an upgrade action with its existing REVIVE ID.

Concussive/Deadly Impact and Super Magnet/GK Crown retain distinct definition identities; their intended interactions and evolution still require tracing. Boss upgrades are development content: the scanned assets lack idname and contain operation values outside the current enum, so do not invent IDs or reinterpret them without tracing their use.

Twenty-seven former base-script entries became data-only AB_ definitions; that does not prove their behavior is complete. Archmage, Armored, Potion Bag, Skillful Endurance, Karmayana, Drone, Mechanic Enchantment, True Stamina and Petrified Skin handle their former specific upgrade operations in definitions. Twelve data-only definitions link to generic stat operations whose gameplay/removal semantics need checking. Athlete is marked merged with no enabled stages; Mechanical Arm uses a weapon-evolution callback. Five other untraced definitions link only to development content. Consult the review CSV for individual entries.

Drone uses the player's prefab binding, a player-owned revive reference and pool-generation checks for removal. A controlled Edit Mode fixture checked isolation and simulated reuse; real Play Mode activation, death/revive and master switching remain unverified. Dynamic cooldown/cost changes, evolution counters, effect ownership, individual ability behavior, UI/reporting and reflection/IL2CPP behavior also need the focused work in the roadmap.

AbilityPanel, the special-upgrade display and GameManager compare the player state's reporting code with Upgrade.idname for existing icon/leaderboard matching. Preserve transmitted values and distinguish upgrade identity from ability reporting identity. Older editor fixtures may use compatibility data and do not validate the production starting list. See playable-path batch 1 for the successful controlled two-player setup and its limits.