# Integration Test: Flight Lifecycle Manager (F02.1)

## Summary
Validate the Flight Lifecycle Manager component responsible for flight CRUD operations, system initialization, and API request routing.

## Component Under Test
**Component**: Flight Lifecycle Manager (F02.1)
**Interface**: `IFlightLifecycleManager`
**Dependencies**:
- F03 Flight Database (persistence)
- F04 Satellite Data Manager (prefetching)
- F05 Image Input Pipeline (image queuing)
- F13 Coordinate Transformer (ENU origin)
- F15 SSE Event Streamer (stream creation)
- F16 Model Manager (model loading)
- F17 Configuration Manager (config loading)
- F02.2 Flight Processing Engine (managed child)

## Detailed Description
This test validates that the Flight Lifecycle Manager can:
1. Create and initialize new flight sessions
2. Manage flight lifecycle (created → active → completed)
3. Validate waypoints and geofences
4. Queue images for processing (delegates to F05, triggers F02.2)
5. Handle user fix requests (delegates to F02.2)
6. Create SSE client streams (delegates to F15)
7. Initialize system components on startup
8. Manage F02.2 Processing Engine instances per flight

The Lifecycle Manager is the external-facing component handling API requests and delegating to internal processing.

## Input Data

### Test Case 1: Create New Flight
- **Input**:
  - Flight name: "Test_Baseline_Flight"
  - Start GPS: 48.275292, 37.385220
  - Altitude: 400m
  - Camera params: focal_length=25mm, sensor_width=23.5mm, resolution=6252x4168
- **Expected**: 
  - Flight created with unique ID
  - F13.set_enu_origin() called with start_gps
  - F04.prefetch_route_corridor() triggered
  - Flight persisted to F03

### Test Case 2: Get Flight
- **Input**: Existing flight_id
- **Expected**: Flight data returned with current state

### Test Case 3: Get Flight State
- **Input**: Existing flight_id
- **Expected**: FlightState returned (processing status, current frame, etc.)

### Test Case 4: Delete Flight
- **Input**: Existing flight_id
- **Expected**: 
  - Flight marked deleted in F03
  - Associated F02.2 engine stopped
  - Resources cleaned up

### Test Case 5: Update Flight Status
- **Input**: flight_id, status update (e.g., pause, resume)
- **Expected**: Status updated, F02.2 notified if needed

### Test Case 6: Update Single Waypoint
- **Input**: flight_id, waypoint_id, new Waypoint data
- **Expected**: Waypoint updated in F03

### Test Case 7: Batch Update Waypoints
- **Input**: flight_id, List of updated Waypoints
- **Expected**: All waypoints updated atomically

### Test Case 8: Validate Waypoint
- **Input**: Waypoint with GPS coordinates
- **Expected**: ValidationResult with valid/invalid and reason

### Test Case 9: Validate Geofence
- **Input**: Geofence polygon
- **Expected**: ValidationResult (valid polygon, within limits)

### Test Case 10: Queue Images (Delegation)
- **Input**: flight_id, ImageBatch (10 images)
- **Expected**: 
  - F05.queue_batch() called
  - F02.2 engine started/triggered
  - BatchQueueResult returned

### Test Case 11: Handle User Fix (Delegation)
- **Input**: flight_id, UserFixRequest (frame_id, GPS anchor)
- **Expected**: 
  - Active F02.2 engine retrieved
  - engine.apply_user_fix() called
  - UserFixResult returned

### Test Case 12: Create Client Stream (Delegation)
- **Input**: flight_id, client_id
- **Expected**: 
  - F15.create_stream() called
  - StreamConnection returned

### Test Case 13: Convert Object to GPS (Delegation)
- **Input**: flight_id, frame_id, pixel coordinates
- **Expected**: 
  - F13.image_object_to_gps() called
  - GPSPoint returned

### Test Case 14: System Initialization
- **Input**: Call initialize_system()
- **Expected**: 
  - F17.load_config() called
  - F16.load_model() called for all models
  - F03 database initialized
  - F04 cache initialized
  - F08 index loaded
  - Returns True on success

### Test Case 15: Get Flight Metadata
- **Input**: flight_id
- **Expected**: FlightMetadata (camera params, altitude, waypoint count, etc.)

### Test Case 16: Validate Flight Continuity
- **Input**: List of Waypoints
- **Expected**: ValidationResult (continuous path, no gaps > threshold)

## Expected Output

For each test case:
```json
{
  "flight_id": "unique_flight_identifier",
  "flight_name": "string",
  "state": "created|active|completed|paused|deleted",
  "created_at": "timestamp",
  "updated_at": "timestamp",
  "enu_origin": {
    "latitude": <float>,
    "longitude": <float>
  },
  "waypoint_count": <integer>,
  "has_active_engine": <boolean>
}
```

## Success Criteria

**Test Cases 1-5 (Flight CRUD)**:
- Flight created/retrieved/updated/deleted correctly
- State transitions valid
- Database persistence verified

**Test Cases 6-9 (Validation)**:
- Waypoint/geofence validation correct
- Invalid inputs rejected with reason
- Edge cases handled

**Test Cases 10-13 (Delegation)**:
- Correct components called
- Parameters passed correctly
- Results returned correctly

**Test Case 14 (Initialization)**:
- All components initialized in correct order
- Failures handled gracefully
- Startup time < 30 seconds

**Test Cases 15-16 (Metadata/Continuity)**:
- Metadata accurate
- Continuity validation correct

## Maximum Expected Time
- Create flight: < 500ms (excluding prefetch)
- Get/Update flight: < 100ms
- Delete flight: < 500ms
- Queue images: < 2 seconds (10 images)
- User fix delegation: < 100ms
- System initialization: < 30 seconds
- Total test suite: < 120 seconds

## Pass/Fail Criteria

**Overall Test Passes If**:
- All 16 test cases pass
- CRUD operations work correctly
- Delegation to child components works
- System initialization completes
- No resource leaks

**Test Fails If**:
- Flight CRUD fails
- Delegation fails to reach correct component
- System initialization fails
- Invalid state transitions allowed
- Resource cleanup fails on delete