medium priority low complexity documentation pending documentor Tier 7

Acceptance Criteria

MentorStatusRepository public interface is fully documented with method signatures, parameter types, return types, and Dart doc comments
CoordinatorNotificationService public interface is documented with all public methods, dispatch contracts, and expected side effects
All expected error states (network failures, RLS policy violations, constraint errors) are enumerated per method
Supabase RLS policy constraints relevant to each repository method are listed with brief rationale
At least one usage example per public method is provided in code form (Dart snippet)
peer_mentor_status_history schema columns, types, nullable constraints, and audit guarantees are documented
Documentation is placed in the project wiki and/or as Dart doc comments above each class/method so IDE tooling surfaces it
Dependent epic teams (automated expiry, manual pause management) can locate and consume the docs without asking the original author
Document is reviewed and accepted by at least one downstream task owner before this task is closed

Technical Requirements

frameworks
Dart (dartdoc-compatible doc comment syntax)
Flutter
apis
MentorStatusRepository internal API
CoordinatorNotificationService internal API
Supabase RLS policy layer
data models
peer_mentor_status_history
MentorStatus enum
CoordinatorNotification
performance requirements
Documentation must not introduce any runtime overhead — pure static docs only
security requirements
Do not include real mentor IDs, personal data, or production Supabase URLs in usage examples — use placeholder values
Clearly document which RLS policies restrict row visibility and which roles have write access

Execution Context

Execution Tier
Tier 7

Tier 7 - 84 tasks

Can start after Tier 6 completes

Implementation Notes

Use Dart's triple-slash `///` doc comment format for all public symbols so `dart doc` can generate HTML. For the wiki portion, use Markdown tables to map each repository method to its RLS constraint and error states — this is the most scannable format for downstream developers. The peer_mentor_status_history audit guarantee section should explicitly state whether the table is append-only, which DB role writes to it, and whether application code can delete rows. Keep usage examples minimal (3–5 lines each) and focused on the happy path; document error handling as a separate subsection.

Reference the Supabase policy names by their actual SQL policy name strings so developers can cross-check in the Supabase dashboard.

Testing Requirements

No automated tests required for documentation tasks. Manual review checklist: (1) verify all public methods have Dart doc comments parseable by `dart doc`, (2) confirm usage examples compile without errors in a scratch Dart file, (3) have one developer from a dependent epic team read the docs cold and confirm they can integrate without clarification questions.

Component
Coordinator Notification Service
service medium
Epic Risks (3)
high impact medium prob security

Supabase RLS policies for status reads and writes must correctly distinguish between a mentor editing their own status and a coordinator editing another mentor's status within the same chapter. Incorrect policies could allow cross-chapter data leakage or silently block legitimate status updates, causing hard-to-diagnose runtime failures.

Mitigation & Contingency

Mitigation: Write RLS policies with explicit role checks (auth.uid() = mentor_id OR chapter_coordinator_check()) and verify with integration tests that cover same-chapter coordinator access, cross-chapter denial, and self-access. Review policies with a second developer before merging.

Contingency: If policy errors surface after merge, temporarily widen policy to coordinator role globally while a targeted fix is authored; use Supabase audit logs to trace any unauthorised access during the interim.

medium impact medium prob integration

CoordinatorNotificationService must correctly resolve which coordinator(s) are responsible for a given mentor's chapter. If the chapter-coordinator mapping is incomplete or a mentor belongs to multiple chapters (as with NHF multi-chapter memberships), the service could fail to notify or duplicate notifications to the wrong coordinators.

Mitigation & Contingency

Mitigation: Use the existing chapter membership data model and query all active coordinator roles for each of the mentor's chapters. Add a de-duplication step before dispatch. Write integration tests with fixtures covering single-chapter, multi-chapter, and no-coordinator edge cases.

Contingency: If resolution logic proves too complex at this stage, fall back to notifying all coordinators in the organisation until a proper chapter-scoped resolver can be delivered in a follow-up task.

high impact low prob technical

Adding new columns to peer_mentors in production could conflict with existing application code that does SELECT * queries if new non-nullable columns without defaults are introduced, causing unexpected failures in unrelated screens.

Mitigation & Contingency

Mitigation: Make all new columns nullable or provide safe defaults. Use additive migration strategy with no column renames or drops. Run migration against a staging copy of production data before applying to live.

Contingency: Prepare a rollback migration script that drops only the new columns; coordinate with the team to deploy the rollback and hotfix immediately if production issues are detected.