Define Typography and Spacing Design Tokens
epic-peer-mentor-detail-screen-foundation-task-003 — Extend the ThemeExtension with a full typography token set (display, headline, body, label, caption scale with font size, weight, line height, letter spacing) and a spatial scale (spacing-2 through spacing-64 covering margins, paddings, and gaps). Tokens must be accessible via the ThemeExtension from BuildContext so widgets avoid hard-coded numeric literals for layout or text styling.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
If the existing codebase already has a `ThemeExtension` from task-002, merge typography and spacing into the same extension class or create a second extension registered alongside it. Keep font families consistent with the app's existing `fontFamily` setting in `ThemeData` — do not hard-code a new family here. For the type scale, use an 8-point grid (multiples of 4 or 8) to maintain rhythm. For `lerp` on spacing doubles, use `lerpDouble`.
For `TextStyle` lerp, delegate to `TextStyle.lerp`. Mark all numeric constants as `static const` to benefit from tree-shaking and avoid re-allocation on every `build`.
Testing Requirements
Unit/widget tests with `flutter_test`. Test 1: each typography token `TextStyle` has non-null `fontSize` and `fontWeight`. Test 2: each spacing token is a positive non-zero `double`. Test 3: `lerp` on typography tokens at `t=0` returns the original instance values.
Lint enforcement: add a custom lint rule or `dart analyze` comment to flag bare numeric literals for padding/font sizes in widget files (optional but recommended).
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.