🏠 Overview › ✅ Implementation Tasks ›✅ epic-peer-mentor-pause-management-foundation-task-011

Build Pause Status Indicator UI widget

epic-peer-mentor-pause-management-foundation-task-011 — Implement the PauseStatusIndicator Flutter widget that visually represents a peer mentor's current pause state (active, paused, suspended). Use design token color coding, include an icon and label, and expose an onTap callback for navigation to detail. Ensure the widget is accessible with proper semantics labels.

high priority low complexity frontend pending frontend specialist Tier 0

Acceptance Criteria

PauseStatusIndicator renders correctly for all three states: active, paused, and suspended
Each state uses the correct design token color (e.g., active = green token, paused = amber token, suspended = red token) — no hardcoded hex values
Each state displays a distinct icon (e.g., play_arrow for active, pause for paused, block for suspended) alongside a localized label string
The widget exposes an onTap callback of type VoidCallback? that is invoked when the user taps the indicator
When onTap is null, the widget is non-interactive and does not show ripple/ink splash
Semantics widget wraps the indicator with a meaningful label combining state name and role (e.g., 'Pause status: Paused. Tap for details.')
semanticsLabel updates correctly when state changes without requiring widget rebuild from parent
Widget passes flutter_test golden snapshot tests for all three states in both light and dark theme contexts
Minimum touch target is 48×48 dp per WCAG 2.2 AA and Material guidelines
Widget is a stateless widget with no internal BLoC or Riverpod dependency — state is passed in via constructor parameter

Technical Requirements

frameworks
Flutter
flutter_test
data models
PeerMentorStatus (enum: active, paused, suspended)
performance requirements
Widget must render in a single frame with no async operations
No unnecessary rebuilds — const constructor where possible
security requirements
No PII exposed in widget semantics label beyond pause state
ui components
Row or Container with Icon + Text
Semantics wrapper
InkWell or GestureDetector for onTap
Design token color references (AppColors / ThemeData extension)
Design token typography references

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Create the widget in lib/features/peer_mentor/widgets/pause_status_indicator.dart. Define a PeerMentorStatus enum (or reuse existing) in a shared types file. Use a switch expression or Map to map each enum value to an icon, label string, and color token — avoid if/else chains. Reference design tokens through the app ThemeData extension (e.g., Theme.of(context).appColors.pauseAmber) rather than hardcoding.

Wrap the entire widget in a Semantics widget with label built from a localized string. Use ExcludeSemantics on the Icon to prevent double-announcement. For the touch target, wrap in a SizedBox with minHeight: 48 if the visual size is smaller. Keep the widget a pure StatelessWidget to make it trivially testable and reusable across coordinator and mentor views.

Testing Requirements

Write Flutter widget tests using flutter_test covering: (1) rendering for each of the three PeerMentorStatus enum values; (2) correct design token color and icon per state; (3) onTap callback fires exactly once on tap when provided; (4) onTap is not invoked when null; (5) Semantics node has correct label for each state; (6) minimum touch target size assertion (>=48dp). Golden image tests for each state snapshot. No integration tests required for this widget alone.

Component
Pause Status Indicator
ui low
Epic Risks (3)
high impact medium prob security

Supabase RLS policies for coordinator-scoped status queries may be difficult to express correctly, especially for peer mentors assigned to multiple coordinators or chapters, leading to data leakage or overly restrictive access blocking valid queries.

Mitigation & Contingency

Mitigation: Design RLS policies using security-definer RPCs rather than table-level policies for complex multi-coordinator scenarios. Write a comprehensive RLS test matrix covering all role and assignment permutations before marking complete.

Contingency: Fall back to application-level filtering in the repository layer with explicit coordinator_id parameter checks if RLS proves intractable, and document the trade-off for security review.

high impact medium prob dependency

The HLF Dynamics portal API contract may be undocumented or subject to change, causing the DynamicsPortalClient to break during development or production rollout.

Mitigation & Contingency

Mitigation: Obtain the full Dynamics portal API specification and credentials early in the sprint. Build the client behind a well-defined interface so the HLF-specific implementation can be swapped without affecting upstream services.

Contingency: If the Dynamics API is unavailable or unstable, stub the client with a feature-flag-guarded no-op implementation so all other epics can proceed to completion independently.

medium impact low prob technical

Supabase Edge Functions used as the nightly scheduler host may have cold-start latency or execution time limits that prevent reliable nightly certification checks on large mentor rosters.

Mitigation & Contingency

Mitigation: Benchmark Edge Function execution time against the expected roster size. Design the expiry check to process in paginated batches to stay within execution limits. Use pg_cron with a direct database function as an alternative trigger if Edge Functions prove unreliable.

Contingency: Migrate the scheduler trigger to pg_cron invoking a Postgres function directly, removing the Edge Function dependency entirely for the scheduling layer.

Quick Links
All Tasks Execution Plan