high priority low complexity frontend pending frontend specialist Tier 2

Acceptance Criteria

When the active org is Blindeforbundet (detected via OrgLabelsProvider.isBlindeForbundet flag or equivalent), a badge is rendered in each contact row showing the open assignment count
When the active org is NOT Blindeforbundet, no badge is rendered — the row layout is identical to the base task-009 output
When open assignment count equals 3, the badge uses the 'milestone-3' design token color (e.g., amber) and displays the count and deadline date
When open assignment count equals 15, the badge uses the 'milestone-15' design token color (e.g., deep orange or a distinct second color) and displays the count and deadline date
For counts that are not 3 or 15 (approaching thresholds), the badge may be shown in a neutral color or hidden — behavior matches the design spec; if spec is silent, hide for non-threshold counts
Badge deadline date is formatted as DD.MM.YYYY in the Norwegian locale convention
Badge is accessible: it has a Semantics label that reads 'Assignment milestone: [count] assignments, deadline [date]'
Widget tests cover: non-Blindeforbundet org (no badge), Blindeforbundet org at count 3 (amber badge), Blindeforbundet org at count 15 (distinct color badge)

Technical Requirements

frameworks
Flutter
flutter_test
data models
AssignedContact (extend with: openAssignmentCount, assignmentDeadline)
OrgLabelsProvider (isBlindeForbundet flag or org type enum)
performance requirements
Badge rendering must not add any async operations — all data passed via props
ui components
AssignmentCountBadge (new private widget or small StatelessWidget)
Container with BoxDecoration for colored badge pill
Text for count + date
Semantics wrapper for badge

Execution Context

Execution Tier
Tier 2

Tier 2 - 518 tasks

Can start after Tier 1 completes

Implementation Notes

Extend the AssignedContact model from task-009 with two nullable fields: int? openAssignmentCount and DateTime? assignmentDeadline. The badge should only render if: (1) OrgLabelsProvider indicates Blindeforbundet AND (2) the count is exactly 3 or 15.

Implement a private _AssignmentMilestoneBadge(int count, DateTime deadline) widget. Use a switch/if on count to select the badge color from design tokens — introduce two new tokens if they don't exist: colorMilestone3 (amber-ish) and colorMilestone15 (a distinct warm color, e.g., deep orange). Do NOT use hardcoded hex values. For OrgLabelsProvider integration, use context.watch() or equivalent — the org flag check must be reactive so the badge appears/disappears if the active org changes without widget reconstruction.

Format the deadline date using intl package's DateFormat('dd.MM.yyyy') — verify intl is already a project dependency before adding it. The Blindeforbundet office-fee trigger at 3rd and 15th assignments is a business rule described in the source documentation — add a code comment referencing this context for future maintainers.

Testing Requirements

Write widget tests using flutter_test with a mock OrgLabelsProvider injected via the widget tree (use ProviderScope overrides if using Riverpod, or InheritedWidget mock). Test 1: inject non-Blindeforbundet org — assert no badge widget in tree. Test 2: inject Blindeforbundet org, contact with openAssignmentCount=3 — assert badge is present and its decoration color matches the milestone-3 token. Test 3: inject Blindeforbundet org, contact with openAssignmentCount=15 — assert badge color matches milestone-15 token and color differs from milestone-3.

Test 4: inject Blindeforbundet org, contact with openAssignmentCount=7 — assert badge is absent (or present in neutral, per spec). Test 5: assert badge Semantics label contains the count and deadline string.

Component
Assigned Contacts List
ui low
Epic Risks (2)
medium impact medium prob dependency

The org labels system may not yet have label keys defined for peer mentor detail screen terminology (role labels, section headings), requiring additions to the label key registry that must be coordinated with the admin configuration team.

Mitigation & Contingency

Mitigation: Audit existing label keys in the terminology system before starting OrgLabelsProvider integration. Submit required new label keys for admin configuration in parallel with component implementation.

Contingency: If label keys are not available at integration time, use hardcoded English fallbacks with a clear TODO for admin configuration, ensuring the widget renders correctly while keys are being provisioned.

high impact low prob technical

The design token semantic colors (warning, error surface) may not meet WCAG 2.2 AA 4.5:1 contrast ratio when rendered on the app's background surface tokens, requiring design system changes that affect the entire app.

Mitigation & Contingency

Mitigation: Run contrast ratio validation on the token palette during Epic 1 design token implementation. Flag any failing pairs to the design system owner before building UI components that depend on them.

Contingency: If tokens fail contrast requirements, define supplementary high-contrast override tokens specific to alert and badge contexts that meet AA without modifying the global palette.