Implement multi_chapter_affiliation_chip read-only display
epic-contact-detail-and-edit-foundation-task-013 — Build the read-only mode of multi-chapter-affiliation-chip: a horizontal wrap of chip widgets each showing a chapter name. Chips are non-interactive in view mode, styled with the design token system, and include a Semantics label listing all affiliated chapters for screen reader users. Support empty state with a neutral placeholder.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 2 - 518 tasks
Can start after Tier 1 completes
Implementation Notes
Use Chip with onDeleted: null and onPressed: null to render a non-interactive display chip — Flutter's Chip widget is interactive by default, so null callbacks are required to suppress tap behaviour and the delete icon. Do not use InputChip or ActionChip as they imply interactivity. Construct the Semantics label by joining chapter names with a comma separator: 'Affiliated chapters: ${chapters.map((c) => c.name).join(', ')}'. Use MergeSemantics or a top-level Semantics with a computed label string and excludeSemantics: true on the Wrap children.
Design token alignment: use AppSpacing.chipHorizontalGap and AppSpacing.chipRunSpacing constants for the Wrap spacing values — do not hardcode 8.0. The empty state placeholder should use the same text style as other 'not set' placeholders in the contact detail screen for visual consistency. This task covers read-only mode only; the editable chip picker (add/remove chapters) is a separate task scoped out of this epic.
Testing Requirements
Widget tests: (1) pump with a list of 3 ChapterAffiliation items and verify 3 Chip widgets are rendered with correct names, (2) pump with an empty list and verify the placeholder text is shown and no Chip widgets are present, (3) verify the Semantics label contains all chapter names when 3 chapters are provided (e.g. 'Affiliated chapters: Oslo, Bergen, Trondheim'), (4) verify Semantics label for empty state is 'No chapter affiliations', (5) verify no individual Chip exposes its own Semantics node (use tester.getSemantics() and assert only one leaf Semantics node), (6) verify no RenderFlex overflow at 12 chips and textScaleFactor=2.0, (7) verify Chip onPressed/onDeleted are null (non-interactive). Golden test recommended for the 3-chip layout if project uses golden testing.
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.