02 — User Personas (Reports Module)

• P1 — Org Admin (school/coaching owner)
• P2 — Principal / Head of Academics
• P3 — Teacher / Class Teacher
• P4 — Accountant / Finance staff
• P5 — Super Admin (platform)
• Permission → screen map (client-side enforcement)

Who uses Reports, with what permissions, for which report types. Permissions from permissions.constants.ts:39-40 (report.generate, report.read). Roles from 00-shared/01 §3. All three report types (report-job.schema.ts:7-11) map to read-only consumers.

P1 — Org Admin (school/coaching owner)

• Goals: institution-wide visibility; run fee summaries at month end; verify report cards before publishing; delegate.
• Permissions: report.generate + report.read (permissions.constants.ts:39-40).
• Reports used: fee_summary (primary), attendance_summary (school-wide or per class), report_card (spot checks).
• Pain points: spreadsheets and manual counting; long wait times with no feedback.
• Key jobs-to-be-done: "Show me what's uncollected", "Is attendance healthy this term?", "Sanity-check a report card before results go out".
• Devices: tablet/desktop mostly; mobile for status checks.
• Behavior: requests reports from dashboard quick actions; checks job list periodically; downloads for archival.

P2 — Principal / Head of Academics

• Goals: academic quality monitoring; term-end report cards; attendance trends.
• Permissions: report.read (view) — report.generate optional (forward-looking) until RBAC roles are seeded per permission set.
• Reports used: report_card (term-end batches), attendance_summary.
• Key jobs-to-be-done: "Verify marks/grades before parent communication", "Spot classes with deteriorating attendance".
• Behavior: reviews job list daily at term end; views results in-app rather than downloading.

P3 — Teacher / Class Teacher

• Goals: per-class attendance summaries and individual report cards; quick pull for parents' meetings.
• Permissions: report.generate + report.read per role grants (forward-looking) — today the API is JWT-gated only (reports.controller.ts:9), so the client must enforce menu visibility by permission list until RBAC guards land.
• Reports used: attendance_summary (with classId), report_card (studentId + examId).
• Pain points: queueing time for term-end batch cards; wants progress, not a spinner.
• Key jobs-to-be-done: "Attendance for my class this month", "This student's report card for the mid-term exam".
• Devices: mobile-first.

P4 — Accountant / Finance staff

• Goals: collections visibility; overdue tracking; monthly reconciliation input.
• Permissions: report.read minimum; report.generate where granted.
• Reports used: fee_summary — totalInvoices, totalCollected, totalPending, totalOverdue (reports.service.ts:154-158).
• Key jobs-to-be-done: "How much is outstanding?", "Track monthly collection".
• Behavior: schedules weekly fee summaries (scheduler (planned) for admin UI; today AttendanceReportJob is daily/weekly attendance only, attendance-report.job.ts:6).

P5 — Super Admin (platform)

• Goals: platform health; never touch tenant data (00-shared/01 §3).
• Permission: platform bypass of tenant scope (base.repository.ts:21-23 via isPlatformAdmin) — out of product scope; no report screens.

Permission → screen map (client-side enforcement)