# Body Dimensions Transition Plan (Stakeholder Draft)

## Goal

Prevent edit-form failures for existing bookings while we transition from legacy body-dimension values to a better long-term field model.

This plan introduces a temporary compatibility phase and keeps sunsetting manual and straightforward.

## Current Problem

- Existing bookings may contain legacy values such as `-148`, `149-157`, or `195+`.
- Integer-only form fields can fail when these legacy strings are loaded.
- Result: participant edit forms can crash before submit.

## Proposed Transition Strategy

Use **text input fields** for body dimensions during transition, with explicit server-side format validation.

### Key Decisions

- No gating by booking create date.
- One unified behavior for all bookings.
- Accept both legacy and numeric formats during transition.
- Keep manual sunsetting later (no automated migration switch).

## Functional Scope

Affected fields:

- `height`
- `weight`
- `shoeSize`

Affected components:

- `src/Form/BodyDimensionsType.php`
- `src/Validator/Constraints/ParticipantValidator.php`
- `src/Form/BookingParticipantType.php` (option passthrough already in place)
- `config/services.yaml` (ranges remain as validation/config source)

## Validation Rules During Transition

### Accepted formats

- Numeric value: `^\d+$` (e.g. `176`)
- Legacy lower/open/range tokens:
  - `^-\d+$` (e.g. `-148`)
  - `^\d+\+$` (e.g. `195+`)
  - `^\d+\s*-\s*\d+$` (e.g. `149-157`)

### Requiredness

- Keep existing rule: body dimensions required when rentals are selected.

### Range checks

- Keep current numeric range checks based on `body_dimension_ranges`.
- Apply range checks only to plain numeric values in transition phase.

## UX/Behavior Expectations

- Existing legacy values render without form initialization errors.
- New numeric entries are accepted and validated.
- Invalid free text (e.g. `abc`, `17x`) shows clear validation errors.
- HTMX refresh behavior remains unchanged.

## Implementation Steps

1. **Form type change**
   - In `BodyDimensionsType`, replace integer fields with text fields for all three body dimensions.
   - Keep labels/help text; keep placeholders based on configured ranges.

2. **Validator extension**
   - Add format validation for all three fields in `ParticipantValidator`.
   - Keep existing required-when-rentals logic.
   - Keep existing range validation for numeric values.

3. **Message tuning**
   - Add one clear message for invalid format.
   - Retain existing range message for numeric out-of-range values.

4. **Testing and QA**
   - Validate old bookings with legacy values open/edit successfully.
   - Validate numeric path (valid and invalid range).
   - Validate invalid format handling.
   - Validate rental-required behavior.

## Acceptance Criteria

- No 500 error when editing participants with legacy body-dimension values.
- Legacy values can be loaded and submitted in transition phase.
- Numeric values are accepted and range-validated.
- Invalid text is rejected with a user-facing validation message.
- Existing participant edit/refresh flows continue to work.

## Risks and Mitigations

- **Risk:** Free-text field semantics are less strict than integer fields.
  - **Mitigation:** strict server-side regex + range checks.

- **Risk:** Inconsistent data representations during transition.
  - **Mitigation:** explicit acceptance policy and manual sunset plan.

## Effort Estimate

- Implementation: 0.5 day
- Validation/message tuning: 0.25 day
- QA/manual testing: 0.5 day
- **Total:** ~1 to 1.5 days

## Manual Sunset Plan (Later)

When stakeholders approve end of transition:

1. Replace text fields with final semantic field type(s).
2. Remove legacy format acceptance from validator.
3. Keep only final numeric/range validation behavior.
4. Remove transition-specific tests and copy.

Expected cleanup effort: ~0.25 to 0.5 day.