Build ProxyConfirmationScreen UI widget
epic-coordinator-proxy-registration-foundation-task-007 — Build the ProxyConfirmationScreen Flutter widget that displays a summary of the proxy registration before final submission. Show attributed mentor name, activity type, date, duration, coordinator name (as registering party), and a clear visual distinction between who performed the activity vs. who is registering it. Include confirm and back action buttons. Use design token theme and ensure WCAG 2.2 AA contrast. This screen is reused in both single and bulk proxy flows.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Design this as a pure presentational widget (StatelessWidget) with all data passed via constructor. Use a sealed class or two named constructors (ProxyConfirmationScreen.single / ProxyConfirmationScreen.bulk) to handle the two modes cleanly rather than a bool flag. The visual distinction between 'performed by' and 'registered by' is critical for NHF/HLF audit compliance — use a two-section layout with a subtle divider and different label styles from the design token system (e.g., bodyMedium for data, labelSmall for role labels). Do not use Expanded in a Column without a Flexible parent if bulk mentor list is present — use a constrained SizedBox or shrinkWrap ListView to avoid unbounded height errors.
Ensure the confirm button is the primary action (full-width, primary color token) and back is secondary (outlined or text button).
Testing Requirements
Widget tests must cover: (1) single-mentor mode renders all 5 required fields, (2) bulk mode renders mentor count and list, (3) confirm button triggers onConfirm callback exactly once, (4) back button triggers onBack callback, (5) null mentor name shows fallback text without exception, (6) accessibility semantics tree contains labels for all interactive elements. Use flutter_test with WidgetTester. No network calls needed — pass mock data directly to the widget constructor.
Supabase RLS policies for org-scoped proxy access may be difficult to express correctly, especially for coordinators with multi-chapter access. An overly permissive policy could allow cross-org proxy registrations, corrupting Bufdir reporting; an overly restrictive policy could block legitimate coordinators from registering.
Mitigation & Contingency
Mitigation: Write integration tests covering all access boundary cases (same org, cross-org, multi-chapter coordinator) before merging any RLS migration. Use parameterised RLS test helpers already established by the auth feature.
Contingency: If RLS proves insufficient, add a server-side Edge Function validation layer that re-checks org membership before persisting any proxy record, providing defence in depth.
Adding new tables and foreign key constraints to an existing production Supabase database risks migration failures or locking issues if the database already contains active sessions during deployment.
Mitigation & Contingency
Mitigation: Use additive-only migrations (no DROP or ALTER on existing tables). Test full migration sequence in a staging Supabase project before production deployment. Schedule during low-traffic window.
Contingency: Maintain a rollback migration script. If the migration fails, the feature remains unreachable behind a feature flag while the schema issue is resolved.
Audit log entries must be immutable for compliance, but Supabase RLS by default allows row owners to update their own rows. If audit records are accidentally mutable, dispute resolution and accountability guarantees are invalidated.
Mitigation & Contingency
Mitigation: Configure the proxy_audit_log table with an RLS policy that allows INSERT for coordinators but denies UPDATE and DELETE for all roles including service_role, enforced at the database level.
Contingency: If RLS cannot fully prevent updates, create a database trigger that reverts any UPDATE to the audit table and logs the attempt as a security event.