Build assignment_status_indicator badge widget
epic-contact-detail-and-edit-foundation-task-011 — Implement the assignment-status-indicator UI primitive as a stateless Flutter widget rendering a colour-coded badge for open (amber), pending (blue), and completed (green) statuses. Accept an optional orgLabel override so organisations can rename statuses without affecting the colour logic. Must meet WCAG 2.2 AA contrast on both light and dark backgrounds.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Define AssignmentStatus as an enum with a method or extension that returns the (backgroundColor, textColor) token pair — this keeps the colour logic close to the type definition and makes it easy to add new statuses later. Use the project's existing design token constants (e.g. AppColors.statusAmber, AppColors.statusBlue) rather than Theme.of(context) colour slots, because status colours are semantic and should not invert on dark mode. To achieve WCAG AA on both light and dark backgrounds, use slightly different amber/blue/green shades for each mode — pass the current Brightness from Theme.of(context).brightness into the token lookup.
Keep the widget const-constructible for performance: mark the constructor const and make orgLabel a named parameter with default null. Do not add Semantics in this task — that is handled in task-012.
Testing Requirements
Widget tests using flutter_test and WidgetTester: (1) for each of the three statuses, pump the widget and verify the correct background color token is applied, (2) verify that when orgLabel='Åpen oppfølging' is passed, the badge shows that text rather than 'Open', (3) verify colour contrast ratios programmatically by extracting background/foreground color pairs and computing the WCAG contrast ratio formula — assert ≥4.5:1 for all three statuses in both ThemeData.light() and ThemeData.dark(), (4) verify no RenderFlex overflow at textScaleFactor 2.0, (5) verify widget is pure (no provider lookup, no setState). Use goldenFileComparator for visual regression if the project has golden test infrastructure.
Blindeforbundet's encryption key retrieval mechanism may not be finalised at implementation time, or session key availability via Supabase RLS may be inconsistent, causing decryption failures that expose masked placeholders to users and degrade the experience.
Mitigation & Contingency
Mitigation: Agree with Blindeforbundet on key storage and retrieval contract before implementation starts. Prototype key retrieval in a spike against the staging Supabase instance and validate the full decrypt/verify cycle with real test data before committing to the implementation.
Contingency: Implement a fallback that shows a 'field temporarily unavailable' state with a retry affordance. Log decryption failures server-side for audit. Escalate to Blindeforbundet stakeholders to unblock key management before the service tier epic begins.
NHF contacts may belong to up to 5 chapters, each governed by separate RLS policies. A coordinator's chapter scope may not cover all affiliations, causing partial profile reads or silent data omissions that are difficult to detect in tests.
Mitigation & Contingency
Mitigation: Map all RLS policy combinations for multi-chapter contacts early. Write integration tests that create contacts with 5 affiliations and query them from coordinators with varying chapter scopes. Use Supabase's RLS test utilities to verify row visibility per role.
Contingency: Add an explicit 'affiliation partially visible' state in the repository response model so the UI can communicate scope limitations to the coordinator rather than silently showing incomplete data.
Organisation-specific validation rules (e.g., NHF chapter limit, Blindeforbundet encrypted field edit flow) may expand in scope during implementation as edge cases are discovered, causing the validator to grow beyond the planned complexity.
Mitigation & Contingency
Mitigation: Define the complete validation rule set with product and org stakeholders before coding begins. Document each rule with its source organisation and acceptance test. Use a rule registry pattern so new rules can be added without modifying core validator logic.
Contingency: Timebox validator enhancements to 2 hours per additional rule. Defer non-blocking rules to a follow-on maintenance task rather than blocking the epic delivery.