Class Hierarchies

Per the engineering policy, every behavior hierarchy gets a contract page here before or with its implementation: what the base owns, where subclasses may diverge, and the invariants any leaf must preserve. A PR adding a leaf class links the contract it extends and states why the behavior can't live in the base.

The shared rule across all of them: data variation is not behavior. Stats, models, tables, and tuning live in resources; a subclass exists only when the logic diverges.

• Enemy — the EnemyBase contract: AI state machine, status intake, death/drops; where boss FSMs and movement-divergent enemies subclass.
• Weapon — WeaponData + archetype behavior: what's a data row vs. an archetype class, and the CombatResolver interface (#157).
• Weapon Library — the curated in-game roster: which basic PSO type models + ein- test weapons actually ship, their texture state, and the VRAM texture-import contract.
• Shop / list screens — the composition contract (ShopNav / ShopUI hooks): grouping without inheritance, because inheritance breaks the Android export here.

The player state machine page serves the same role for the player avatar and predates this section.