high priority medium complexity frontend pending frontend specialist Tier 0

Acceptance Criteria

ScenarioConfigurationScreen is a full-page Flutter screen registered in the app's router under a coordinator-only route guard
Screen uses Design System v3 layout conventions: page header with title and subtitle, section headers, card-style list items — no inline styles
Each scenario template list item displays: scenario name (bold), description (truncated to 2 lines with ellipsis), last modified date (formatted dd.MM.yyyy), and a Toggle Switch
Toggle switch uses Flutter's Switch widget styled with design token colors (active: primary accent, inactive: surface token)
Toggle switches are rendered as interactive but wired to no-op callbacks in this task — state persistence is handled in task-013
Screen includes a page header with title 'Scenario Configuration' and subtitle indicating the current chapter/organization context
An empty state illustration/message is shown when the scenario templates list is empty
Screen is accessible: all toggle switches have semantic labels read by VoiceOver/TalkBack announcing 'Enable [scenario name]'
Non-coordinator users cannot navigate to this screen — route guard redirects them to home with an appropriate access denied message
Screen renders correctly in both portrait and landscape orientations without overflow
Screen uses a ListView.builder for the template list to ensure it is virtualized for large lists
Last modified metadata uses relative time (e.g., '3 days ago') for dates within the last 7 days, absolute date for older entries

Technical Requirements

frameworks
Flutter
Riverpod
data models
activity_type
performance requirements
ListView.builder used — only visible items built in the widget tree
Screen initial render (with placeholder data) under 16ms frame budget
No expensive computations in build() — pre-compute any derived display values in the provider layer
security requirements
Route guard must verify coordinator role from the auth provider before rendering — reject at navigation layer, not just by hiding UI
Screen must not expose scenario template IDs or internal configuration keys in the UI
ui components
PageHeader widget with title and subtitle from Design System v3
SectionHeader widget for template category grouping
ScenarioTemplateListItem custom widget (name, description, last modified, toggle)
Switch widget styled with design tokens
EmptyStateWidget for no templates
ListView.builder for template list

Execution Context

Execution Tier
Tier 0

Tier 0 - 440 tasks

Implementation Notes

Define ScenarioConfigurationScreen as a ConsumerWidget. Create a ScenarioTemplateListItem as a separate widget file — do not inline it in the screen file. For the route guard, use the existing role-based route protection pattern already in the router (check go_router or equivalent). For relative/absolute time display, create a pure helper formatLastModified(DateTime dt) -> String to keep the widget clean and testable.

The Toggle Switch should accept an enabled bool and an onChanged VoidCallback — set onChanged to (_) {} placeholder. Use ListView.builder with itemCount and itemBuilder. Category grouping (used in task-012) should be anticipated in the list item data model now: define a ScenarioTemplateViewModel with fields: id, name, description, category, isEnabled, lastModified. Keep this task strictly to layout scaffolding — resist the urge to wire data here.

Testing Requirements

Write widget tests using flutter_test. Widget test 1: Screen renders page header with correct title and subtitle. Widget test 2: ListView renders one ScenarioTemplateListItem per template in the input list. Widget test 3: Each list item shows name, truncated description (2 lines), formatted last modified date, and a Switch.

Widget test 4: Empty state widget shown when template list is empty. Widget test 5: Coordinator role renders screen normally; non-coordinator role triggers route guard redirect. Widget test 6: Toggle switches are visible and interactive (tappable) but do not change any state yet (no-op). Golden test for list item layout at 1.0x and 1.3x font scale.

Aim for 80%+ widget coverage.

Component
Scenario Configuration Screen
ui medium
Epic Risks (2)
high impact medium prob technical

If the scheduler runs concurrently (e.g., two overlapping cron invocations due to edge function retry), duplicate prompts could be dispatched before the first run's history records are committed, breaking the deduplication guarantee.

Mitigation & Contingency

Mitigation: Use a Postgres advisory lock or unique constraint on (user_id, scenario_id, activity_ref) in the prompt history table to make concurrent writes idempotent; design the scheduler to check history inside a transaction.

Contingency: If concurrency issues persist in production, add a distributed lock via Supabase Edge Function concurrency limit (max_instances=1) for the evaluation function as a hard guard.

medium impact medium prob scope

Coordinators may find scenario configuration unclear if trigger conditions are expressed as raw JSON or technical terminology, leading to misconfiguration and irrelevant prompts being sent to peer mentors.

Mitigation & Contingency

Mitigation: Design the ScenarioConfigurationScreen to display human-readable descriptions of each template's trigger condition (e.g., 'Send 3 days after first contact if wellbeing concern was flagged') rather than raw rule properties; validate with an HLF coordinator in a design review before implementation.

Contingency: If coordinators still misconfigure rules after launch, add a preview mode that shows a simulated prompt based on a test activity before the rule is enabled.