# Refactor: status / point-type enums + acceptance_criteria.md RT2 update

**Task**: AZ-370_refactor_status_pointtype_enums
**Name**: Introduce RegionStatus + RoutePointType enums; sync AC RT2
**Description**: Replace bare-string status / point-type values with enums; persist via Dapper type handler. Update AC RT2 wording to match the 4-value point-type reality.
**Complexity**: 3 points
**Dependencies**: None
**Component**: Common + Services.RegionProcessing + Services.RouteManagement + Documentation
**Tracker**: AZ-370
**Epic**: AZ-350

## Problem

Status and point-type values are bare strings written to and compared from multiple sites: `RegionService.cs:49,90,140,209` ("queued"/"processing"/"completed"/"failed"), `RouteService.cs:66,100` and `RouteProcessingService.cs:138-140` ("start"/"end"/"action"/"intermediate"). Typos at compile time become runtime bugs. Acceptance criterion RT2 in `_docs/00_problem/acceptance_criteria.md` is also out of sync: it says point types are `original` / `intermediate`, but the lived code uses 4 values (`start` / `end` / `action` / `intermediate`).

## Outcome

- Two enums in `SatelliteProvider.Common/Enums/`: `RegionStatus { Queued, Processing, Completed, Failed }` and `RoutePointType { Start, End, Action, Intermediate }`.
- All status / point-type compare and write sites use the enums.
- Dapper persists them as the existing lowercase strings via a registered `EnumStringTypeHandler<T>`.
- AC RT2 in `_docs/00_problem/acceptance_criteria.md` lists all 4 point types.
- DB column types and stored values are identical; no migration needed.
- 37 unit + 5 smoke tests stay green.

## Scope

### Included
- Add the two enums.
- Add a generic `EnumStringTypeHandler<T> : SqlMapper.TypeHandler<T>` and register both instantiations at startup.
- Replace string-literal compare/write sites with enum values.
- Update AC RT2 wording in `_docs/00_problem/acceptance_criteria.md`.
- Add unit tests for the type handler (round-trip).

### Excluded
- Migrating existing rows (values are identical strings).
- Renaming any column.
- Adding any new status or point-type value.

## Acceptance Criteria

**AC-1: All compare/write sites use enums**
Given the post-refactor source
When grepped for `"queued"` / `"processing"` / `"completed"` / `"failed"` / `"start"` / `"end"` / `"action"` / `"intermediate"` as string literals in service code
Then matches are confined to enum-value definitions and the type handler.

**AC-2: DB round-trip preserves values**
Given a row with `status = 'completed'` written by the new code
When read back via Dapper
Then it round-trips to `RegionStatus.Completed`.

**AC-3: AC RT2 matches the code**
Given the post-refactor `_docs/00_problem/acceptance_criteria.md`
When RT2 is inspected
Then it lists all 4 point types: `start`, `end`, `action`, `intermediate`.

**AC-4: Tests stay green**
Given the post-refactor build
When `scripts/run-tests.sh --smoke` runs
Then all 37 unit + 5 smoke scenarios pass.

## Constraints

- DB stored values unchanged (lowercase strings).
- No migration.
- Enum names match user-confirmed canonical option (α): `Start, End, Action, Intermediate`.

## Risks & Mitigation

**Risk 1: a third-party tool reads the DB column directly**
- *Risk*: external SQL queries comparing to literal strings still work because we kept the lowercase format.
- *Mitigation*: type handler emits exactly the same lowercase strings.

Full change entry: `_docs/04_refactoring/03-code-quality-refactoring/list-of-changes.md` (C17).
