medium priority low complexity documentation pending documentor Tier 6

Acceptance Criteria

A single Markdown documentation file (e.g. docs/annual_impact_summary_widgets.md) or equivalent Dart doc comments covers all five components
Each component section includes: purpose, constructor signature with parameter types and descriptions, required vs optional parameters clearly marked, and at least one code snippet showing minimal correct usage
Design token requirements are documented per widget: which token classes/ThemeExtension fields are consumed and what happens if they are absent
Reduced-motion behaviour is documented: what changes when SummaryAccessibilityProvider.reducedMotionEnabled is true (list of suppressed animations per widget)
Semantics contract is documented per widget: list of all Semantics labels emitted, which are static vs dynamic, and what data they interpolate
A step-by-step guide explains how to add a new organisation's announcement strings to SummaryAccessibilityProvider without modifying existing widget code
Integration example shows all five components composed together in a realistic screen tree
Documentation is reviewed and approved by at least one other team member (peer review comment on the PR)
No broken Dart code snippets — all snippets compile against the current widget API (verified with flutter analyze on the doc snippets if using a examples/ directory)

Technical Requirements

frameworks
Flutter
Dart doc comments (///) for in-code documentation
Markdown for standalone documentation file
apis
SummaryAccessibilityProvider public API
StatCardWidget constructor
MilestoneBadgeWidget constructor
ActivityTypeBreakdownWidget constructor
SummaryShareOverlay constructor
data models
SummaryStatCardData
MilestoneBadgeData
ActivityTypeBreakdownData
AccessibilityLabels
security requirements
Documentation must not include real API keys, Supabase URLs, or user data in code snippets — use placeholder values
ui components
StatCardWidget
MilestoneBadgeWidget
ActivityTypeBreakdownWidget
SummaryShareOverlay
SummaryAccessibilityProvider

Execution Context

Execution Tier
Tier 6

Tier 6 - 158 tasks

Can start after Tier 5 completes

Implementation Notes

Prefer Dart doc comments (///) directly in the source files over a separate Markdown file — this keeps docs co-located with code and generates API docs via dart doc. For the organisation extension guide, describe the pattern: implement or extend the AccessibilityLabels class, override the relevant announcement getters, and inject the custom instance via the SummaryAccessibilityProvider constructor. Keep code snippets minimal but complete — import paths should be relative to the project root. For the reduced-motion section, create a simple table: Widget | Animation | Reduced-motion behaviour.

This makes the contract scannable. Reference the WCAG 2.2 AA success criterion (2.3.3 Animation from Interactions) when documenting reduced-motion support to give the requirement its proper context.

Testing Requirements

No automated tests required for documentation itself. However, ensure all Dart code snippets in the documentation are syntactically valid by copying them into a standalone example file and running flutter analyze.

If the project has a docs-lint CI step, ensure the new documentation file passes it. Request a peer review specifically checking: accuracy of parameter descriptions, completeness of the Semantics contract section, and clarity of the organisation extension guide.

Component
Summary Accessibility Provider
infrastructure medium
Epic Risks (2)
medium impact medium prob technical

Simultaneous count-up animations across multiple stat cards and chart draw-in animations on lower-end Android devices may cause frame drops below 60fps, degrading the premium Wrapped experience and making the feature feel unpolished.

Mitigation & Contingency

Mitigation: Stagger animation starts using AnimationController with staggered intervals rather than starting all animations simultaneously. Use RepaintBoundary around each animated widget to isolate rasterisation. Profile on a mid-range Android device (e.g., equivalent to Pixel 4a) during development, not just at QA.

Contingency: If frame rate targets cannot be met on low-end devices, implement a device-capability check at startup and substitute simpler fade-in animations for the count-up and chart draw-in on devices below a CPU performance threshold.

medium impact low prob integration

The activity-type-breakdown-widget must render organisation-specific activity type labels sourced from the terminology system. If the terminology provider is not yet integrated at the time this widget is built, the widget will display hardcoded system labels, which is a regression risk for multi-org support.

Mitigation & Contingency

Mitigation: Accept activity type labels as a typed parameter in the widget constructor rather than reading from the terminology provider directly inside the widget. The BLoC or repository layer resolves labels before passing them to the widget, maintaining clean separation and testability.

Contingency: If terminology resolution is unavailable at widget integration time, display internal activity type keys as a temporary fallback with a localised suffix '(label pending)' visible only in non-production builds so QA can identify unresolved labels.