Batch 28 · R0 player motor, vitals and stats contract

2026-10-26. Bounded design/source-audit goal; no runtime, scene, prefab, package, save or gameplay changes, no Unity run, no commit/push. Preserve existing dirty work and authored mechanics; approved assignment/remapping/four-slot scope remains a target rather than implemented capacity. Tutorial and GAME-01 work stay parked.

Delivered evidence

Player capability contract defines authoritative owners, inputs/outputs, initialization/update ordering, reset/lifetime, retain/extract/retire decisions and migration dependencies. It records normalized motion/dash and timing constraints; ordered invulnerability/shields/mitigation/reactions/lethal handling; resource spending/regen; complete current stat projections and mutation units; shared status, death/revive, targeting and presentation boundaries.

• Authored baseline: all seven Bootloader catalog characters and their actual Character/weapon component values and referenced content.
• Reference map: 88 lexical category rows across 49 scripts, including damage wrappers, direct HP/stamina writers, modifier reads/mutations and enemy/Tutorial/test/view consumers. It is not a compiled call graph; receiver/inheritance limits are explicit.
• Binding map: 46 component records from player prefabs/scenes (22 direct and 24 prefab-inherited references) with stable IDs, selected dependencies and base Rigidbody data. Inherited/override fields require later import validation. A separate persistent-event scan across 1,256 serialized files finds no exact reviewed capability-entry-point name hits, without proving absence of other callbacks.
• Comparison cases: 28 source-derived expectations for motion, formula units/casts, damage/reflection/immunity, resource ticks, dash, revive and status ordering. Arithmetic examples were spot-checked; production methods/coroutines were not executed.

Review covers Player/Entity/PlayerModifier, dash and relevant AbilityHolder hooks, AbilityFunction admission, pickup/level/weapon/projectile health writers, UpgradeFunction revive/PSkin and modifier operations, target/presentation and initialization callers. Source pins and CSV identity/value checks support the documentation; they do not establish a Steam baseline, live character stats or unchanged movement feel after a future implementation.

Unresolved behavior and next dependency

The contract names PC-01–PC-06 follow-ups: prior-frame stat dependencies and Update order; negative adjusted damage/immunity timing; cap/regen/status-loop quirks; joined-slot/repeated-revive behavior; remaining ability/defense/stat hooks; and three/four-player participation. They remain risks/design dispositions, not silently fixed bugs. Existing GAME-09 now notes the inactive-slot revive traversal as a source lead needing reachability/runtime evidence.

This completes the bounded contract batch only. R0 remains open, and gameplay implementation remains gated. Next: combat, weapon, targeting and per-player ability/cooldown/effect-state contract, reconciling the ordered player damage/resource/stat boundary before stage/reward/persistence design.

Verification record

Final checks pass: unchanged source/data/settings/packages and all 608 prior baseline pins; seven authored rows with matching Character/weapon component identities and values; 88 reference-category rows across 49 scripts with valid source lines; 46 serialized identities (22 direct and 24 prefab-inherited references, with component-specific overrides recorded); 28 unique clearly labelled source-derived cases; 471 local documentation links; new-file whitespace; and all 52 existing findings routed once. The normal player profile matches the retained preservation snapshot. Existing audio/Plastic deletions and nonempty index lock remain untouched. No runtime test result is claimed.