Batch 49 · Explicit character setup

2026-10-27. R2 production character-assembly seam; starting HEAD 798c1c3d. This changes the existing production setup path and prefab binding, without adding a new actor implementation, menu, stage or gameplay rule. Implementation be81418a precedes this separate documentation/evidence commit.

Change and boundary

GameInitialization.PreparePlayer resolves the selected character, shop values, ammo view and audio service at its existing compatibility boundary and passes them to Player. Player.ApplyCharacter's explicit overload creates the existing weapon, retains footstep/animator/setup ordering and returns the actual setup coroutine. A future run participant can await that handle; no new readiness flag or artificial delay is introduced. The parameterless public adapter remains available.

PlayerModifier.SetupPlayer's explicit overload copies its inputs before its existing waits and binds the supplied ammo view afterward, without querying GameManager/GameSession. Its old public adapter remains. Calculate and all later modifier methods, plus Player.Update and all following movement/resource/damage/status methods, retain their exact prior bytes. Initial setup still has two null yields; the actual legacy initializer does not acquire a new wait in this batch.

The canonical Player prefab gains one explicitly assigned weaponMount reference to its original child. The new path tolerates changing that mount's name/sibling order and rejects missing/foreign bindings before spawning a weapon. It no longer selects the mount by child index. The unused Player.CenterPoint property/lookup is removed: the player prefab has no matching direct child and no project consumer was found; CameraController's separate center calculation is unchanged. Only this prefab record changes; scene instances inherit the binding without scene reserialization.

This is a setup dependency for the shared development arena, not a completed arena or input/Player/AbilityHolder migration. Gameplay.unity remains a lifecycle shell. Existing input sampling, Player/Entity/AbilityHolder Update/OnEnable ownership, actual actor spawn/activation/teardown and the global services used elsewhere remain later work. No claim of fully independent Player runtime or measured performance improvement is made.

Original-code comparison

Before editing runtime code, an empty-scene Play Mode harness runs the original production SetupPlayer iterator against all seven released Character/weapon definitions, at shop variants zero and every float 1.25 / weapon-level 2, with legacy slots 0/1. It records each MoveNext result and one settled Calculate: 14 cases × four observations × 92 fields. Component Update is disabled and abilities are empty, so this is controlled setup evidence, not a full simulation or execution-order characterization.

The committed Editor-only PlayerSetupReference.json contains those original outputs and source provenance, with a shared field-name list and exact round-trip numeric strings. NaN observations are deliberately retained. The comparison reads this fixed artifact instead of generating expectations from the modified code or requiring the old temporary file. New public numeric stat fields or changed values/order fail comparison. Original output export and raw logs remain private.

Original capture: 15/15 groups, exit0. Initial comparison and completion-handle iteration each pass 22/22. Final standalone comparison, after archiving the old /tmp reference export, passes 22/22 and exits0. It includes the canonical prefab plus all eight inherited actor mounts, all 14 exact setup sequences, real awaited coroutine completion with globals absent, the old caller adapter, renamed/reordered mounts, changed shop inputs after setup begins, delayed ammo-view binding, and missing/foreign mount rejection before an extra spawn. This does not test every invalid content combination or repeat/death/revive lifetime.

Linux IL2CPP was built before the final Editor fixture-storage change. All four runtime/prefab path hashes remain identical to the built candidate; only Editor-only tests/data changed afterward and were reverified. No second native build was run merely for an Editor fixture.

Native verification and preservation

Linux x64 IL2CPP build exit0, 739.517 seconds, from dirty reviewed source at 798c1c3d; required Editor 6000.2.8f1, Standalone backend1. A guarded 1280×720 native process uses a temporary XDG profile, starts Meadow/Normal twice and returns twice (two Arena-start and three MainMenu-initialized markers), then quits through the actual menu Yes action, exit0. Its 426.416-second lifetime includes inspection/background time and is not freeze/performance evidence.

One-player Soldier: visible health/stamina100, damage10, attack1.50/s, movement2.80, working 10-round ammo/reload, shots/enemies/drops, score1→5 and timer00:05→00:10. A brief held D input shows movement/animation; this is not a movement-feel comparison. Two-player selection chooses Soldier and Knight: separate avatars, gun/sword, HUDs, health100/150, stamina100/100, damage10/16 and movement2.80/2.60. Timer00:05→00:11 and score2→5 progress before pause/return. No physical gamepad or new Input System actor routing is exercised. No full stage, reward, death/revive, all-character-native or Windows qualification is claimed.

The exact executable/PID/window, active-window/input focus and client geometry are checked before sending input. An initial geometry guard refused input during display settlement; the later normalization passed. Client-buffer screenshots and raw diagnostics remain under private /tmp/tinychaos-batch49-*. Both completed runs use the real released scene, not Gameplay.unity. The profile's config remains byte-identical with zero traced config-write begins; no exception heading appears in native or accepted Editor logs. Optional-service warnings retain their existing scope.

Private capture /tmp/tinychaos-batch49-preserve-1628493919/ preserves 7,745 pre-existing project files and 8,178 profile hashes with recoverable preferences. All 7,741 captured project files outside the four intended runtime/prefab edits match exactly; four new Editor test/data paths match their final manifest. The prefab is byte-identical except for its single new binding. All 81 prior rebuild implementation paths remain unchanged. The selected 608-pin baseline file stays immutable: 600 match, with four new intended Player/prefab/initializer exceptions in addition to the four previously documented ones. Do not repin it.

Reviewed generated Linux-toolchain package additions were archived and exact captured package bytes restored. No new Addressables linker files remain or required manual removal at this checkpoint; TimeManager, other settings, build lists and all scenes match capture. Shared Editor prefs changed only two session keys; normal game prefs changed only four Unity session/connection keys. Generated copies were archived and exact preferences restored after all owned processes exited. The normal game's one prefs file is byte-identical and no normal game data files were added. Outside that boundary, Unity bookkeeping retains 5 changed, 0 added and 6 removed files; the whole profile tree is not claimed unchanged. Audio deletions and the untracked Linux.meta remain untouched. No owned Editor/player remains running.

Inventory now covers 260 scripts, preserving 256 prior rows, updating three focused rows and adding one runner. Five AS gates append to 143 earlier rows (148 total); all 27 workstream follow-ups remain open. Input-consumer rows and authored/source baseline CSVs are unchanged. Raw logs, source/profile manifests, old reference export, build provenance and artifact hashes are excluded from Git; the committed golden fixture contains only controlled source-derived setup data.

Continue toward shared-system actor composition and legacy-equivalent input/motor behavior, then vitals/stats and AbilityHolder in dependency order. New setup/rebind/four-player layouts remain deferred; dedicated GAME-01, full gameplay, physical-device and Windows acceptance remain open.

Documentation validation preserves all 53 issue routes, resolves 864 local links and retains all prior 143 gate rows. Implementation and evidence are staged/committed separately; raw diagnostic/profile files are excluded.