Define BulkRegistration domain types and batch result contracts
epic-proxy-activity-registration-orchestration-task-006 — Define all Dart types for BulkRegistrationRequest (list of participant entries with shared activity data), BulkRegistrationResult, BulkParticipantConflict (per-participant duplicate detail), BulkConflictSummary (aggregated reviewable list), and BulkRegistrationSuccess (count of committed records). These types allow the BLoC to render a conflict review UI from the result without additional queries.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 7 - 84 tasks
Can start after Tier 6 completes
Implementation Notes
Use the freezed package for all domain types to get immutability, equality, copyWith, and JSON serialization for free. Define BulkRegistrationResult as a sealed class with three variants. Place all type definitions in a single file (e.g. bulk_registration_types.dart) under the domain layer — this makes the contract easy to discover and review.
Ensure BulkConflictSummary is designed so the UI can render a 'review' screen showing: (a) how many will be submitted, (b) a list of conflicts with peer mentor name lookup by ID. Keep the types decoupled from Supabase-specific types — no SupabaseResponse or PostgresException should appear in domain types. These types should be stable contracts between the service layer and the BLoC; avoid adding convenience methods that belong in the service.
Testing Requirements
Write unit tests using flutter_test verifying: (1) BulkRegistrationRequest serializes and deserializes correctly; (2) BulkConflictSummary correctly separates clean participants from conflicted ones; (3) BulkRegistrationResult sealed variants are exhaustively matchable; (4) freezed equality works correctly for all types (two instances with same data are equal); (5) copyWith on BulkParticipantEntry produces correct partial updates. No mocking required — these are pure data type tests.
If the Supabase batch RPC partial-inserts some records before encountering an error and does not roll back cleanly, the bulk service may report failure while orphaned records exist in the database, corrupting reporting data.
Mitigation & Contingency
Mitigation: Wrap the bulk insert in an explicit Supabase transaction via the RPC function. Write an integration test that simulates a mid-batch constraint violation and asserts zero records were written.
Contingency: If a partial-write incident occurs, the registered_by audit field allows identification and deletion of the orphaned records. Implement a coordinator-facing bulk submission status screen to surface any such anomalies.
When a bulk submission of 15 participants has 4 duplicates, the aggregated conflict summary may be too complex for coordinators to process quickly, leading to blanket override decisions that defeat the purpose of duplicate detection.
Mitigation & Contingency
Mitigation: Design the conflict result type to support per-participant override flags, so the UI can present a clear list of conflicting participants with individual cancel/override toggles rather than a single global decision.
Contingency: If coordinator usability testing reveals the conflict review screen is too complex, simplify to a 'skip all conflicts and submit the rest' mode as an immediate fallback while a more granular UI is designed.
If the coordinator role check inside proxy-registration-service is inconsistent with the route-level guard, a regression in the guard could allow peer mentors to call the service directly via deep links, submitting records with incorrect attribution.
Mitigation & Contingency
Mitigation: Enforce role authorization at both the route guard level (coordinator-role-guard) and inside each service method independently. Write a security test that calls the service directly with a peer mentor session token and asserts rejection.
Contingency: If a bypass is discovered, immediately enable the server-side RLS policy as the final enforcement layer and audit any records written during the exposure window using the registered_by field.