02 — User Personas (Rooms Module)

• 1. Persona map
• 2. Org Admin — "Meera"
• 3. Office / Timetable Coordinator — "Ravi"
• 4. Teacher — "Ananya"
• 5. Platform Super Admin — "DevOps Dan"
• 6. Student / parent — "Kabir & mother" (planned) surface
• 7. Persona → feature priorities

Who uses the Rooms module, what they need, what permissions map to them, and where the current backend constrains them. Personas derive from the module's API surface (src/modules/rooms/**) and the declared RBAC permissions (permissions.constants.ts:50-53).

1. Persona map

2. Org Admin — "Meera"

• Goals: keep the room catalog accurate: add new labs at term start, rename/merge rooms, retire rooms no longer used. Codes must be unique and sensible (LAB-02, A-101).
• Friction today: duplicate-code guard exists at create (409, rooms.service.ts:19-21) but not on update (OQ-1 — changing a code onto an existing one 500s); no delete in-use guard (OQ-4); no status/floor fields to model an out-of-service room (OQ-5).
• Screens: Room Editor (/rooms/new, /rooms/:id/edit), Room List (/rooms).
• Out of scope guardrails: client must gate create/update/delete UI to rooms.create/update/delete until the server RBAC guard lands (OQ-2).

3. Office / Timetable Coordinator — "Ravi"

• Goals: during timetable planning ((planned) — IMPLEMENTATION_PLAN.md:227) assign classes to rooms that fit: right type, enough capacity, right building.
• Needs from Rooms: filterable list (type, building, capacity) — filter/sort not yet on the API (OQ-3, rooms.controller.ts:32); client-side filtering (proposed) until then; capacity shown on every card.
• Friction today: pagination only (page/limit); list is Mongo _id order, no -createdAt default sort; no search (q).

4. Teacher — "Ananya"

• Goals: quickly confirm "where is the lab and does it have a projector?" before class.
• Needs: room detail with building + facilities; room card on schedule entries (timetable (planned)).
• Friction today: read-only surface is fine; facility tags are free text, so data hygiene depends on the admin.

5. Platform Super Admin — "DevOps Dan"

• Goals: support tickets ("room missing"), verify tenant isolation, audit deletions.
• Needs: soft-delete audit trail (deletedAt/deletedBy — base.schema.ts:23-27), structural impossibility of cross-tenant reads (base.repository.ts:24-29).
• Friction today: no audit-log module surface for rooms (audit (planned) in IMPLEMENTATION_PLAN.md Phase 5 §"Permissions audit"); the platform admin bypasses tenant scope intentionally (base.repository.ts:21-23).

6. Student / parent — "Kabir & mother" (planned) surface

• Goal (forward-looking): check-in via QR at the venue, see room info on the booking receipt.
• Today: no student-facing room surface; bookings module (planned), QR (forward-looking).

7. Persona → feature priorities