# Exercise Library Video Status — RC93

## Decision
The current row-based `DATA` is good enough for this step. It should not be restructured before we have a stable video catalog and admin workflow.

## Why
The current data already contains the important fields needed for the first video library pass:

- exercise name
- stage / phase / week / day
- section
- prescription
- `videoUrl`
- `videoType`

RC93 derives a normalized exercise catalog from the existing rows instead of changing the source data.

## New derived model
RC93 introduces a derived catalog in runtime:

```text
DATA rows → NEXTExerciseLibraryService.build() → exercise catalog
```

Each catalog item gets:

- `exerciseId`
- title
- category
- equipment
- stages/phases/sections
- prescriptions
- usages count
- primary video source
- video status

## Video status model
The video service resolves status in this order:

1. server video
2. YouTube direct
3. OTA page
4. timer/own exercise
5. missing
6. unknown / needs check

## Why no source-data rewrite yet
A full source-data restructure should wait until we know the admin/editor model.

Future canonical model can be:

```text
exercise library
  → exerciseId
  → tags/focus/equipment
  → video asset

program model
  → session
  → block
  → exerciseId + prescription
```

But doing that now would risk the known-good pass/player behavior.

## RC93 scope
- New exercise library surface.
- New video status service.
- New server video registry placeholder.
- No player refactor.
- No upload/record feature.
- No source-data migration.