# NEX Dynamic Warmup — Frozen Player Baseline V6

## Why
Camera, runway and workout UI had started drifting while exercise-specific travel profiles were being added. V6 separates the immutable player from mutable exercise data.

## Motion baseline
- `NEXT11_V425_DYNAMIC_WARMUP_FULL_ROOT.zip`
- SHA-256 `19a91b1569dda3a0b36094b84ca42f20d4a180e6dc6a53247f3d48ee57e624f2`
- Resolved motion / Nex model are not modified by the app layer.

## Frozen presentation authority
The presentation code is restored from the accepted App V3 (through Figure Fours): front three-quarter tracking camera, approximately +0.5 m above head, endless static runway, side ticks/posts, no runway distance labels, same workout UI/tap/swipe behavior.

Exercise-specific travel code has been removed from `assets/js/app.js`. `app.js` now only asks the external registry for a profile. No camera/runway/player code may be changed when adding exercises.

## Exercise data
Canonical profile files are under:
`assets/nex/workout_profiles/dynamic_warmup/`

Exercises 1–7 are present as independent JSON files. The browser registry is generated by:
`python tools/nex_dynamic_warmup/rebuild_travel_registry.py`

For exercise 8+, add one new `exNN_*.json`, rebuild the registry, then run the guard. Do not edit old profile files.

## Mandatory guard
Before every QA/package:
`python tools/nex_dynamic_warmup/check_frozen_player.py`

The guard fails if:
1. camera/runway/UI/player core changes;
2. any accepted profile 1–7 changes;
3. any V425 resolved motion or Nex model changes;
4. generated browser registry is hand-edited / not reproducible.

## Allowed future scope
A new exercise may add only its own profile JSON, regenerate the aggregate registry, and add QA/docs. If a genuine player-system defect is discovered, it must be handled as an explicit new player-baseline revision, never silently inside an exercise patch.