02 — User Personas (Teachers Module)

• 1. Organization Admin
• 2. HR Admin (staff/people operations)
• 3. Teacher (self)
• 4. Academic Coordinator (teaching-pattern oversight)
• 5. Persona → surface map

Derived from blueprint/01-Product/USER_PERSONAS.md (tenant-level actors) and the implemented RBAC role seed (src/modules/rbac/schemas/role.schema.ts:8-65). The blueprint defines Organization Admin, Teacher, and Staff (Non-Teaching) personas; HR Admin and Academic Coordinator are role-level specializations of Staff/Teacher inferred from blueprint descriptions and module access patterns — flagged as derived, not literal blueprint personas.

1. Organization Admin

• Blueprint anchor: "Manages a single institution (tenant). Goals: Configure branches, invite staff, oversee operations. Pain: Wants one dashboard for everything. Access: Full tenant admin, configurable permissions." (USER_PERSONAS.md:20-25)
• System role: org_admin — permissions: ALL_PERMISSIONS (role.schema.ts:17-24). Note: there are no teacher.* perms in the system (permissions.constants.ts:1-97) — the admin's access to teachers is inherited as everything, not by explicit permission.
• Goals: onboard teachers fast (create → assign → ready to teach), keep the staff roster accurate, deactivate leavers safely, see teacher counts on dashboard (dashboard.service.ts:32,52).
• Pain points: duplicate employee numbers cause 409 on create (teacher.service.ts:32-38); no server-side assignment conflict check (subject-assignment.service.ts:13-17) means errors surface late; sort/q query params are ignored (teacher.service.ts:66-78) so large rosters are hard to scan.
• Context: desktop-first, but reviews notifications on phone (in-app teacher-created notifications, event-queue-map.ts:31).
• Success: roster complete within one session; every new teacher has subjects + classes before their first class.

2. HR Admin (staff/people operations)

• Blueprint anchor: Staff persona — "Operations, reception, coordinators. Goals: Manage profiles, support admins. Pain: Needs read access across modules. Access: Role-scoped, often read-heavy." (USER_PERSONAS.md:34-39) — HR is the profile-lifecycle operator within that persona. (derived)
• System role: custom staff role — permissions: ['student.read'] (role.schema.ts:34-36); or a custom role with staff.read/update per permissions.constants.ts:19-22 (client-side gating only, see 01 §5).
• Goals: create teacher profiles from onboarding paperwork (employee number, department, designation, joining date), update qualifications/experience, mark status changes, deactivate leavers.
• Pain points: teacher form requires a pre-existing User (userId is the only required identity field, create-teacher.dto.ts:5-7) — HR must create the user in Users module first (cross-module flow, OQ-1).
• Context: mostly desktop web; repeated entry; values consistency (employeeNumber format like TCH001, create-teacher.dto.ts:9).

3. Teacher (self)

• Blueprint anchor: "Delivers instruction. Goals: Mark attendance, assign homework, enter exam marks. Pain: Wants minimal clicks; mobile-friendly. Access: Own classes, own students." (USER_PERSONAS.md:27-32); module map: "Teacher | Attendance, Homework, Exams, Results" (USER_PERSONAS.md:85).
• System role: teacher — permissions: ['student.read','attendance.mark','attendance.edit'] (role.schema.ts:26-32). No teacher. permission, no self-profile endpoint* (OQ-2) — "My schedule" is reachable via GET /timetable?teacherId=<me> (timetable.controller.ts:21-27) and GET /subject-assignments/by-teacher/<me> (subject-assignment.controller.ts:30-35) using their own teacher id.
• Goals: see today's/this term's teaching load (subject-assignment matrix), check which classes they're class-teacher for, confirm profile basics are right, minimal clicks, mobile.
• Pain points: no self-service screen exists in the backend — the client must compose one from assignments + timetable; status on_leave should suppress schedule emphasis but nothing server-side does that.
• Context: phone-first during school hours; check "what do I teach / where do I go" in < 10 s.

4. Academic Coordinator (teaching-pattern oversight)

• Blueprint anchor: derived from Staff persona ("coordinators… read access across modules", USER_PERSONAS.md:34-39) + the Academics module being the assignment owner (subject-assignment.controller.ts:16-17). (derived — not a literal blueprint persona)
• System role: custom role holding read perms (student.read, timetable.read, settings.read where granted) — again client-gated.
• Goals: review the per-year teaching matrix: who teaches what in which class; balance workload; spot missing subject coverage; assign a teacher to a class-subject for the new academic year.
• Pain points: duplicate assignments are storable (no unique index, subject-assignment.schema.ts:24-25), so a coordinator can double-assign; two assignment stores (teacher.subjects[] vs subject_assignments) can disagree.
• Context: desktop, term-start bursts (August–September), report-style views.

5. Persona → surface map