Implement contact-form-validator for edit screen fields
epic-contact-detail-and-edit-supporting-ui-task-012 — Build the contact-form-validator infrastructure module. Implement field-level validators for all editable contact fields: required name, valid email format, valid Norwegian phone number, valid birth date range, and chapter affiliation non-empty. Each validator returns a typed ValidationResult with a user-facing error message keyed to the org-labels system for terminology overrides.
Acceptance Criteria
Technical Requirements
Implementation Notes
Define a sealed class ValidationResult with two subclasses: ValidationSuccess and ValidationFailure(String errorLabelKey). Place the file at `lib/infrastructure/validators/contact_form_validator.dart`. Norwegian phone regex: `^(\+47|47)?[2-9]\d{7}$` — validate this against real Norwegian mobile and landline patterns. For email, use a standard RFC 5322 simplified regex rather than a package dependency to keep the module lightweight.
Birth date range should be configurable via constants (e.g. `kMinAge = 0`, `kMaxAge = 120`) to allow future adjustment. Error label keys must match exactly the keys defined in the org-labels system — coordinate with the labels file before finalising key names to avoid a mismatch at integration time.
Testing Requirements
Unit tests only (flutter_test, no widget binding needed). Cover: each validator's happy path (valid input returns ValidationResult.valid), each validator's failure path (invalid input returns ValidationResult.invalid with the correct errorLabelKey), boundary values for birth date (exactly at min/max age), phone number edge cases (8-digit, +47 prefix, no prefix, non-numeric characters). Aim for 100% branch coverage on the validator module. Tests must not depend on any Flutter widget infrastructure.
The encrypted-field-display confirmation dialog adds interaction steps that may frustrate coordinators who access sensitive fields frequently, leading to requests to bypass the flow or skip read-receipt logging, which would violate Blindeforbundet's compliance requirements.
Mitigation & Contingency
Mitigation: Design the confirmation dialog to be as minimal as possible (one clear sentence, single confirm action) and ensure it does not reappear for the same field within a single screen session. Validate the UX with Blindeforbundet coordinators during the TestFlight pilot before finalising.
Contingency: If coordinators raise strong objections, escalate to Blindeforbundet's data protection officer to determine whether a lighter confirmation pattern (e.g., biometric confirmation instead of dialog) satisfies their compliance obligation.
The activity-history-list infinite scroll requires paginated Supabase queries. Contacts with hundreds of activities (e.g., an HLF peer mentor with 380 annual registrations) could cause slow page loads or memory pressure on older devices if pagination boundaries are set too large.
Mitigation & Contingency
Mitigation: Use a page size of 20 records with cursor-based pagination. Implement list item recycling using Flutter's ListView.builder. Benchmark memory usage with 400+ item simulation on a low-end test device before TestFlight release.
Contingency: If performance degrades on older devices, reduce page size to 10 and add a time-window filter (last 30 days, last 6 months, all) so the default view loads a manageable record count for most coordinators.
The cognitive load rule engine (from the Cognitive Accessibility feature) mandates no more than 7 fields per screen section. If a contact model has more than 7 editable fields, the edit-contact-screen layout must be split into sections, adding complexity not accounted for in the initial scope.
Mitigation & Contingency
Mitigation: Audit the full contact field list from all four organisations before implementation. Group fields into logical sections (personal info, contact details, affiliation) so no single section exceeds 7 fields. Use the cognitive-load-rule-engine component if it is already delivered by the Cognitive Accessibility feature.
Contingency: If the rule-engine component is not yet available, implement a simple manual section layout with accordion-style expansion for less-frequently edited fields to stay within the 7-field guideline without blocking delivery.