AEROSIM-TS-9
Render the governed learning path from lesson and pilot state
The player sees each configured lesson exactly once in governed order with an available, current, or completed state determined from lesson prerequisites and the active pilot's progress snapshot.
- Verified flow state
- Unverified
- Owner
- AeroSim Architecture and Delivery
- Feature
- AEROSIM-FT-8
- Component
- API Service — learning-path projection and Web Application — training path view
- Repository
- corp-v1-aerosim/corp-v1-aerosim
Delivery scope
Define a LearningPathProjection boundary shared by the API and training view. Join the versioned LessonCatalogue to the active pilot's ProgressSnapshot supplied by AEROSIM-FT-28, calculate one state per lesson, and preserve catalogue order. A lesson is completed only when its identifier appears in completedLessonIds; current is the first incomplete lesson whose lesson prerequisites are satisfied; later incomplete lessons are available only when their prerequisites are satisfied. Before a lesson can launch, compare its required logical actions with a read-only InputProfileSnapshot: each required action must have one supported binding, and every bound continuous axis must carry finite calibration values for deadZone, sensitivity, inversion, and smoothing. This Task validates and reports mapping or calibration defects but does not capture device signals, edit bindings, run calibration, author lessons, or implement AEROSIM-FT-28.
Implementation contract
Implementation artifacts
- applications/api/src/training/learning-path-projection.ts
- applications/web/src/training/learning-path-view.tsx
- packages/contracts/src/training/learning-path.ts
- tests/integration/training/learning-path-projection.spec.ts
Inputs
- LessonCatalogue { catalogueVersion, lessons[] }, where each lesson has lessonId, order, objective, prerequisiteLessonIds[], and requiredLogicalActions[].
- ProgressSnapshot { pilotId, snapshotVersion, completedLessonIds[] } supplied by the AEROSIM-FT-28 Feature contract for the authenticated pilot.
- InputProfileSnapshot { pilotId, profileVersion, deviceId, bindings[], axisCalibration[] }, where a binding maps one required logical action to a supported control and continuous-axis calibration provides finite deadZone, sensitivity, inversion, and smoothing values.
Outputs
- LearningPathProjection { catalogueVersion, progressSnapshotVersion, inputProfileVersion, lessons[] }, with one ordered row per catalogue lesson containing lessonId, objective, state, and launchBlockReasons[].
- A launch decision that identifies missing-action-binding or invalid-axis-calibration with the affected logical action; it never substitutes defaults silently.
Failure boundaries
- Reject the projection when catalogue lesson IDs or order values are duplicated, a prerequisite lesson is unknown, prerequisite relationships contain a cycle, or the progress snapshot names an unknown lesson.
- Reject a progress or input-profile snapshot whose pilotId differs from the authenticated pilot or whose version is absent.
- Keep the lesson visible but prevent launch when a required logical action has no binding, has more than one active binding, or its continuous-axis calibration is missing, non-finite, or outside the contract ranges deadZone 0..0.5, sensitivity 0.1..3.0, and smoothing 0..1.
Excluded scope
- Lesson catalogue authoring and prerequisite-Feature implementation.
- Raw device sampling, binding persistence, calibration capture, flight-control application, lesson evaluation, and pilot-progress mutation.
Verification steps
- Run tests/integration/training/learning-path-projection.spec.ts and retain the exact candidate-revision result.
- Project a fixture with three ordered lessons and two completed IDs; assert one row per lesson, stable catalogue order, and exactly one current lesson.
- Exercise duplicate order, unknown prerequisite, prerequisite cycle, unknown completed lesson, cross-pilot snapshot, missing binding, duplicate binding, and each invalid calibration field; assert the specified rejection or launch-block result.
- Render the projection in learning-path-view.tsx and confirm that objective, state, and launch-block reason match the API projection without client-side state recomputation.
Traceability
Acceptance evidence
Required future evidence: a reviewed candidate revision must contain the contract, projection, view, and integration-test artifacts; passing test output must demonstrate deterministic ordering and state derivation plus every declared mapping, calibration, identity, and catalogue failure case.
Current evidence boundary
No current implementation, acceptance, release, or deployment evidence is claimed for this planned Task. Any prior implementation may be used only as prototype and discovery evidence.