ProxyRegistrationService: dual-identity payload construction
epic-bulk-and-proxy-registration-services-task-008 — Implement the payload builder in ProxyRegistrationService that assembles a ProxyActivityRecord from the coordinator's session identity and the selected mentor's ID. The recorded_by_user_id must be sourced from the authenticated session (never from UI input), and the peer_mentor_id from the confirmed mentor selection. Include activity_type, date, duration, and notes fields. Validate completeness before handing off to the repository.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 3 - 413 tasks
Can start after Tier 2 completes
Implementation Notes
Implement as a synchronous factory method `ProxyActivityRecord.fromCoordinatorSession({required String mentorId, required String activityTypeId, required DateTime date, required int durationMinutes, String? notes, required String sessionUserId})` where `sessionUserId` is injected by the service (read from `supabase.auth.currentUser?.id`). This makes the record class independently testable without needing a Supabase instance. Validation rules should be expressed as a `validate()` method returning `Either
Keep the record a simple `@immutable` Dart class — no BLoC or Riverpod inside the model layer. Notes sanitization: `notes?.trim().isEmpty == true ? null : notes?.trim()`.
Testing Requirements
Unit tests with flutter_test: (1) valid inputs produce a correctly populated ProxyActivityRecord, (2) recorded_by_user_id matches mock session user ID not any input parameter, (3) missing activityTypeId returns ValidationFailure, (4) future date returns ValidationFailure, (5) zero duration returns ValidationFailure, (6) null notes produces null in record (not empty string), (7) session unavailable returns SessionExpiredFailure, (8) peer_mentor_id equals recorded_by_user_id returns ValidationFailure, (9) notes whitespace is trimmed before storage, (10) assembled record is equal-by-value to an expected fixture.
The Proxy Registration Service must verify that the coordinator has a legitimate assignment relationship with the target peer mentor before creating a record. If this check is implemented only in application code and not enforced at the DB/RLS level, a compromised or buggy client could bypass it by calling the Supabase endpoint directly, creating fraudulent proxy records for arbitrary peer mentors.
Mitigation & Contingency
Mitigation: Implement permission validation at two levels: (1) application-layer check in Proxy Registration Service that queries the assignments table before constructing the payload, and (2) RLS policy on the activities table that restricts INSERT to rows where recorded_by_user_id matches the authenticated user AND peer_mentor_id is in the set of peer mentors assigned to that coordinator. The RLS policy is the authoritative guard; the service-layer check provides early user-facing feedback.
Contingency: If RLS policy implementation is blocked by Supabase plan constraints, implement a Supabase Edge Function as a proxy endpoint that enforces the permission check server-side before forwarding to the DB. Disable direct client inserts entirely for proxy activities.
For a bulk session with 30 selected peer mentors, the Proxy Duplicate Detector must query existing activities for each mentor. If implemented as 30 sequential Supabase queries, round-trip latency could make the bulk confirmation screen feel slow (>3s), degrading coordinator experience and potentially causing timeouts.
Mitigation & Contingency
Mitigation: Implement the duplicate check as a single Supabase query using an IN clause on peer_mentor_id combined with the activity_type and date filters, returning all potential duplicates for the entire batch in one network round-trip. Group results client-side by mentor ID to produce the per-mentor warning structure.
Contingency: If the single-query approach returns too much data for very large chapters, add a database index on (peer_mentor_id, activity_type, date) and profile query time. If still insufficient, accept a short loading state on the confirmation screen with a progress indicator rather than pre-loading duplicates before navigation.