Dart model: ProxyActivityRecord
epic-proxy-activity-registration-foundation-task-004 — Implement the `ProxyActivityRecord` Dart class with fields: id, registeredBy (coordinator user id), attributedTo (peer mentor user id), activityTypeId, date, durationMinutes, notes, createdAt. Include `fromJson`/`toJson`, `copyWith`, and Equatable. Annotate fields as immutable. Add unit tests covering serialisation round-trips.
Acceptance Criteria
Technical Requirements
Implementation Notes
Use the equatable package (already in pubspec if BLoC is used). Declare the class as `final class ProxyActivityRecord extends Equatable`. For DateTime serialisation use `DateTime.parse(json['date'] as String)` and `.toIso8601String()` in toJson — do not use int epoch. For Supabase snake_case alignment: registeredBy → registered_by, attributedTo → attributed_to, activityTypeId → activity_type_id, durationMinutes → duration_minutes, createdAt → created_at.
Keep the model in the proxy_activity feature folder to maintain feature-first architecture. Do not add json_annotation/build_runner code generation unless the team already uses it — hand-written fromJson/toJson is simpler and sufficient for this model size.
Testing Requirements
Write flutter_test unit tests in test/features/proxy_activity/models/proxy_activity_record_test.dart. Cover: (1) full round-trip serialisation with all fields populated, (2) round-trip with notes=null, (3) round-trip with createdAt=null, (4) Equatable equality for identical instances, (5) Equatable inequality when any single field differs, (6) copyWith preserves unchanged fields, (7) copyWith changes target field. Minimum 7 test cases. No integration or widget tests required for this model.
The activities table migration adding registered_by and attributed_to columns may conflict with existing RLS policies or FK constraints if the user profile table structure differs from assumptions, blocking all subsequent epics.
Mitigation & Contingency
Mitigation: Review existing activities table schema and RLS policies before writing the migration. Run the migration against a staging database clone first. Write rollback scripts alongside the migration.
Contingency: If migration fails in staging, isolate the conflict with a targeted schema audit, adjust FK references or RLS policy scope, and re-run before touching production.
The RLS policy must filter proxy inserts to the coordinator's chapter scope. If the chapter-scope resolver pattern differs between organisations (multi-chapter coordinators in NHF vs single-chapter in HLF), the policy may be too broad or too restrictive.
Mitigation & Contingency
Mitigation: Design the RLS policy to accept a coordinator's full set of assigned chapter IDs (array) rather than a single chapter_id. Validate the policy against NHF multi-chapter test fixtures during the integration test phase.
Contingency: If the policy is found to be incorrect after deployment, introduce a server-side validation edge function as a safety net while the RLS policy is corrected.
The bulk_register_activities RPC function may time out or cause lock contention when inserting large participant batches (e.g. 40+ peer mentors in a single group session), degrading the user experience.
Mitigation & Contingency
Mitigation: Benchmark the RPC function with 50-participant batches during development. Use unnest-based bulk insert rather than row-by-row PL/pgSQL loops. Set a reasonable statement_timeout.
Contingency: If performance is insufficient, split the client-side submission into chunks of 20 participants with progress feedback, rather than a single RPC call.