# Handover · V389 sagittal High Knee Tuck

## Result

V389 corrects the High Knee Tuck peak so the lifted knee travels upward and straight forward instead of sweeping laterally or across the body. The packaged source film, exercise timing, alternating-side loop and mobile resolved-playback route remain intact.

- exercise: `high-knee-tuck`
- profile: `warmup_high_knee_tuck_ik_v1`
- source clip: `assets/media/exercises/high-knee-tuck/source/NEXT11_dynamic_warmup_ijj7TD0DA6Q_high-knee-tuck.mov`
- local playback film: `assets/media/exercises/high-knee-tuck/high-knee-tuck.mp4`
- resolved asset: `assets/nexprod/resolved/high-knee-tuck-v389-sagittal.resolved.json`
- player: `assets/nexprod/nexprod01-resolved-player-v389.html`
- production mode: `resolvedPlayback`
- live solver calls during playback: `0`

## Anatomical correction

The old source-normalized peak contained a large lateral hip-to-knee component:

- left: `+0.459010 m`
- right: `-0.499755 m`

V389 reconstructs each lifted thigh in the canonical sagittal plane. The knee has zero lateral displacement from its hip, rises above the hip and continues in canonical `+Z`:

- left: lateral `0`, rise `0.283634 m`, forward `0.378178 m`
- right: lateral `0`, rise `0.290000 m`, forward `0.417376 m`

The original anatomical thigh length is preserved on both sides. The source shin/toe bend is translated with the knee, and a small film-consistent forward rib-cage inclination keeps the bilateral upper-shin grip inside the physical arm span. No global tolerance, collision or solver limit was loosened.

## Motion and contact

Timing is unchanged from the user-provided film authority:

- one filmed side: `4.421680 s`
- complete alternating resolved loop: `8.843360 s`
- resolved samples: `720`

Both hands wrap the lifted upper shin below the knee at each peak using the existing generic grip capability. All four peak hand solves pass. Neutral hand quaternions still come from the actual FBX rest pose; the app only interpolates baked transforms.

## Application mapping

The normal Dynamic Warm Up route now points to the V389 player and resolved asset in the JSON and JS profile/sequence mirrors. The exercise video registry still resolves the packaged MP4 before the external YouTube fallback. Mobile limits remain 24 FPS, 24 FPS animation sampling and pixel ratio `1.15`.

## Verified QA

- build gate: PASS
- sagittal direction gate: PASS on both sides
- bilateral grip gate: PASS, two hands per side
- maximum authored frame step: `6.807518°` (`R_Calf`)
- full integration gate: PASS
- actual Nex FBX + Three.js CPU-skinned two-loop render: PASS
- rendered frames: `425` at 24 FPS, `17.708333 s`
- decoded frame-difference samples: `424`
- non-static temporal average: `1.096689`
- front/right-side contact sheets inspected for both repetitions

Primary evidence:

- `diagnostics/v389/V389_HIGH_KNEE_TUCK_BUILD_REPORT.json`
- `diagnostics/v389/V389_HIGH_KNEE_TUCK_INTEGRATION_CHECK.json`
- `diagnostics/v389/5_6_local_render/V389_HIGH_KNEE_TUCK_5_6_LOCAL_RENDER_GATE.json`
- `diagnostics/v389/5_6_local_render/V389_HIGH_KNEE_TUCK_CPU_SKINNED_MESH_TWO_LOOP_QA.mp4`
- four 8 FPS entry/hold/release contact sheets in `diagnostics/v389/5_6_local_render/`

## Approval boundary

V389 is mechanically solved, integrated and rendered. It remains `pending_user_acceptance`: the deterministic CPU renderer proves actual skinned-mesh motion and continuity, but does not claim Chromium/WebGL pixel parity or replace human approval of the exercise form.

## Re-run

From package root:

```bash
node tools/nexprod/build_v389_sagittal_high_knee_tuck.mjs .
node tools/nexprod/run_v389_high_knee_5_6_local_render_gate.mjs .
node tools/nexprod/check_v389_high_knee_tuck.mjs .
```

Use `--reuse-render` on the render gate only when the exact V389 two-loop MP4 already exists in its output directory.