Define MentorStatus Enum and Certification Domain Types
epic-peer-mentor-detail-screen-foundation-task-005 — Define the MentorStatus enum with four values: active, expiring_soon, expired, and paused. Define the CertificationStatusResult value object that bundles MentorStatus with the days_remaining integer. These types form the output contract of the certification status service and are consumed by all UI widgets, BLoC events, and repository interfaces in downstream epics.
Acceptance Criteria
Technical Requirements
Implementation Notes
Keep this file as pure Dart with zero package imports beyond optionally `package:equatable` or `package:meta`. Using Dart's built-in record types (`(MentorStatus, int)`) is an alternative to a named class but reduces readability at call sites — prefer the explicit named class. If `equatable` is not already a project dependency, implement `==` and `hashCode` manually using `status` and `daysRemaining`. Avoid adding helper methods (e.g., `isWarning`) to these types at this stage — such logic belongs in `CertificationStatusService` (task-006) or UI mappers, not in the domain value object.
The `daysRemaining` sign convention (positive=future, negative=past) must be documented clearly since UI countdown widgets will depend on it.
Testing Requirements
Pure Dart unit tests (no widget pump needed). Test 1: `MentorStatus.values` has exactly 4 elements. Test 2: two `CertificationStatusResult` instances with identical fields are equal (`==`) and share the same `hashCode`. Test 3: two instances with differing `daysRemaining` are not equal.
Test 4: `daysRemaining` can be negative (construct with -5 and assert field value is -5). Tests must run without Flutter test runner (`dart test`) to confirm no accidental Flutter dependency.
The design token theme extension may conflict with existing ThemeData extensions already registered in the app, causing runtime assertion errors or token resolution failures across all screens that consume the tokens.
Mitigation & Contingency
Mitigation: Audit all existing ThemeData extensions before implementation. Use a unique extension key namespace and add integration tests that instantiate the combined theme in a test app harness.
Contingency: If conflicts arise, isolate design tokens behind a dedicated provider singleton (Riverpod) rather than a ThemeData extension, updating all consuming widgets to read from the provider instead.
The 30-day warning threshold for expiring_soon status may differ between HLF's stated requirement in workshops (60 days mentioned in user stories) and the 30-day value in component documentation, causing disagreement during acceptance testing.
Mitigation & Contingency
Mitigation: Explicitly confirm the threshold value with HLF stakeholder before implementation. Make the threshold a named constant (kCertificationWarnDays) so it can be updated without logic changes.
Contingency: If stakeholder confirms 60 days post-implementation, update the constant and re-run the unit test suite — no architectural change required.