Full-game compatibility report

CMAPI 0.5.0 was mapped against the supplied complete-game Assembly-CSharp build with module version ID:

520dcd8f-2c13-4a99-b871-44c7ad40bcc1

The prior Prologue proof build used:

a399dfb2-f885-444e-96d5-b40b68059b1b

Verified seam

The complete PlayersManager.cs implementation differs from the Prologue copy only in decompiler header metadata. The player controller and gauge handler contain substantial full-game additions and a newer Unity Netcode RPC model, but those changes are outside CMAPI's read-only adapter seam.

CMAPI 0.9.0 trainer capability seam

The optional trainer is probed separately from the public player API. CMAPI requires the native gauge AddOxygen, AddWater, AddHealth, RemoveToxic, and full-gauge checks; GetPlayerMovable; native fly get/set; public walk/run speed fields; and the fall-damage reset method. If any member is absent, gameinfo lists it and trainer commands/menu controls are not registered. The read-only player API and unrelated mods continue to run.

Infinite Power has an additional fail-closed adapter for the tested RequireEnergyHandler requester and current-energy fields. That one option can report unavailable even when the rest of the trainer is compatible.

CMAPI 0.10.0 content and lifecycle seam

CMAPI separately probes the local backpack/equipment getters, inventory slot and native modification members, live group/recipe/unlock methods, and the game's completed-save event. If any required member is absent, recipes/unlocks return empty snapshots, player inventories report unavailable, lifecycle binding stays disabled, and gameinfo lists the exact missing content member. Older player/environment APIs and the loader remain available when their own capability seams still pass.

Runtime policy

CMAPI checks the exact seam above before enabling player synchronization:

• The known full-game MVID receives a normal compatibility success message.
• The known Prologue MVID is allowed with a legacy-target warning.
• An unknown MVID with every required member is allowed in compatibility mode with a warning, which lets small game patches continue without pretending they were tested.
• A build missing any member keeps CMAPI's console and mod loader running but disables the player API and prints the complete missing-member list.
• Missing optional trainer members disable only trainer actions and produce a health_check caution, not a core API failure.
• Missing content/lifecycle members disable the 0.10 surfaces and produce a core compatibility failure without invoking an guessed replacement path.

This is intentionally capability-based. The MVID identifies what was tested; the member probe determines whether a newer build is structurally usable.

Public API impact

No public 0.4.0 player or command member needed to change. CMAPI 0.9.0 added the Unity-free IModHelper.PlayerPlacement surface, whose value models and structured outcomes remain in CMAPI.API.dll. Mods continue to reference only that assembly; the complete game's Assembly-CSharp, Unity, and Netcode types remain runtime implementation details.

CMAPI 0.10.0 adds only CMAPI-owned immutable recipe, unlock, inventory, and lifecycle types. Ordinary mods still do not reference Assembly-CSharp, Unity, or Netcode.

Every Windows/in-game compatibility pass must still prove standalone bootstrap, manager discovery, local lifecycle ordering, live state, world exit/re-entry, and multiplayer join/leave. Source compatibility is strong evidence, not a replacement for that runtime gate.