Build Phase 4 Contribution Data Structure
epic-coordinator-statistics-dashboard-core-logic-task-012 — Finalise and document the ContributionData model in PersonalStatsService to be forward-compatible with the Phase 4 Spotify Wrapped gamification feature. The structure must include: monthly activity counts by type (suitable for Wrapped timeline rendering), cumulative totals, streak calculation fields, and a milestone flags map. Add JSON serialisation and a toWrappedInput() adapter method so Phase 4 can consume the data without a schema migration.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Place ContributionData in lib/features/stats/domain/models/contribution_data.dart to keep it in the domain layer, independent of Supabase or BLoC. Use a sealed ActivityType enum (or import the existing one from the activity domain) so the map keys are type-safe. For the toWrappedInput() stub, define a WrappedInputDto class in the same file or a sibling file with a TODO linking to Phase 4 epic, to prevent schema drift when Phase 4 is implemented. Prefer explicit Map.fromEntries() or map() transforms over imperative loops in toJson()/fromJson() for readability.
The milestoneFlags map should be String-keyed to allow Phase 4 to add new flags without a Dart model change — document this extensibility decision explicitly.
Testing Requirements
Unit tests using flutter_test. Test fromJson(toJson(model)) round-trip for fully populated, partially populated, and empty models. Test toWrappedInput() returns expected keys and values. Test copyWith() changes only the targeted field.
Test == returns true for identical instances and false for differing instances. Test streak fields handle null lastActivityDate gracefully. Minimum 95% line coverage on ContributionData model file.
fl_chart's default colour palette may not meet WCAG 2.2 AA contrast requirements when rendered on the app's dark or light backgrounds. If segment colours are insufficient, the donut chart will fail accessibility audits, which is a compliance blocker for all three organisations.
Mitigation & Contingency
Mitigation: Define all chart colours in the design token system with pre-validated contrast ratios. Run the contrast-ratio-validator against every chart colour during the adapter's unit tests. Use the contrast-safe-color-palette as the source palette.
Contingency: If a colour fails validation, replace with the nearest compliant token. If activity types exceed the available token set, implement a deterministic hashing algorithm that maps activity type IDs to compliant colours.
StatsBloc subscribing to the activity registration stream creates a long-lived subscription. If the subscription is not disposed correctly when the dashboard is closed, it will cause a stream leak and potentially trigger re-fetches on a disposed BLoC, resulting in uncaught errors in production.
Mitigation & Contingency
Mitigation: Implement subscription disposal in the BLoC's close() override. Write a widget test that navigates away from the dashboard and asserts no BLoC events are emitted after disposal.
Contingency: If leaks are detected in QA, add a mounted check guard before emitting states from async callbacks, and audit all other BLoC stream subscriptions in the codebase for the same pattern.
PersonalStatsService's Phase 4 gamification data structure is designed against an assumed future schema. If the Phase 4 Spotify Wrapped feature defines a different data contract when it is developed, the structure built now will require a breaking change and migration.
Mitigation & Contingency
Mitigation: Document the contribution data structure with explicit field semantics and versioning comments. Keep the Phase 4 fields as optional/nullable so they do not break existing consumers if the schema evolves.
Contingency: If the Phase 4 schema diverges significantly, the personal stats data can be re-mapped in a thin adapter layer without changing PersonalStatsService's core implementation.