ProxyActivityRepository: extend base activity repository
epic-bulk-and-proxy-registration-services-task-002 — Implement the ProxyActivityRepository Dart class that extends or wraps the existing ActivityRepository. Override the insert and query methods to carry the recorded_by_user_id field through every Supabase call. Ensure all existing activity repository tests still pass and that the dual-identity contract is enforced at the type level via a ProxyActivityRecord model distinct from the base ActivityRecord.
Acceptance Criteria
Technical Requirements
Execution Context
Tier 1 - 540 tasks
Can start after Tier 0 completes
Implementation Notes
Use composition over inheritance if ActivityRepository has private members that cannot be cleanly overridden: class ProxyActivityRepository { final ActivityRepository _base; final SupabaseClient _client; ... }. Define ProxyActivityRecord as a standalone class (not extending ActivityRecord) to avoid Liskov substitution issues — both classes share a common interface or use a mixin for shared fields. In insertBatch, build the payload as List
Supabase Flutter client handles list payloads natively. Enforce coordinator identity by reading the current user ID from _client.auth.currentUser?.id inside the repository method and throwing an AuthenticationException if null — this makes the contract explicit and fails fast if called in an unauthenticated state. For fromJson/toJson serialization, use explicit field name constants (e.g., static const String kRecordedByUserId = 'recorded_by_user_id') to avoid typos that would silently produce null values in the database. Document the dual-identity semantics with a Dart doc comment on the class explaining peerMentorId vs recordedByUserId.
Testing Requirements
Unit tests using flutter_test with a MockSupabaseClient (mockito-generated or manual fake): (1) insert() — assert the Supabase mock receives a payload containing both peer_mentor_id and recorded_by_user_id with correct values; assert returned ProxyActivityRecord matches server response. (2) insertBatch() — assert a single Supabase insert call is made with a list of N records; assert all N records in the payload carry recorded_by_user_id. (3) queryByCoordinator() — assert .eq('recorded_by_user_id', coordinatorId) is called; assert returned list maps correctly to List
(5) Error propagation — mock a PostgrestException from Supabase insert, assert ProxyActivityRepository wraps and rethrows as a domain-level RepositoryException. (6) Regression: run existing ActivityRepository test file and assert all tests pass. Aim for 90%+ coverage on ProxyActivityRepository methods.
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.