09 — User Behaviour (Exams Module)

• 1. Planning cadence (Coordinator)
• 2. Slot overlap avoidance (designed behaviour; server lacks it — OQ-2)
• 3. Marks entry — the efficiency loop (Teacher)
• 4. Error recovery behaviour
• 5. Publish behaviour (Principal / Coordinator)
• 6. Read-only consumption (Student / Parent)
• 7. Session & permission behaviour
• 8. Cross-session & multi-device
• 9. Accessibility behaviour (00-shared/09)
• 10. Instrumentation (proposed)

Behavioural patterns observed, designed-for, and tested — derived from the server contract (examination.service.ts, result.service.ts) and the shared behavioural baseline 00-shared/10_QA_Baseline.md / 09_Accessibility_Baseline.md.

1. Planning cadence (Coordinator)

• Burst creation: coordinators plan an entire term in one sitting — the form must support rapid sequential creation (after submit, "Create another" ghost action; the list FAB is always reachable). Each subject slot is one POST (examination.controller.ts:45-50); a 5-slot exam = 5 requests — the client sequences them with per-request error isolation (one failure doesn't abort the rest, unlike the server's sequential addSubject — each call is independent).
• Window discipline: coordinators set startDate/endDate first; the slot date picker clamps to the window (mirrors CreateExaminationDto, examination.dto.ts:19-25).

2. Slot overlap avoidance (designed behaviour; server lacks it — OQ-2)

• Before submitting a slot, the client compares date + startTime/endTime (examination-subject.schema.ts:18-25) against already-loaded slots. Overlap → inline warning + confirm dialog. Users may still proceed (server won't reject), but the warning makes the coordinator's mental model explicit.
• Duplicate subject in the same exam → "already scheduled (date …)" warning (no server dedupe — OQ-3).

3. Marks entry — the efficiency loop (Teacher)

• Numeric-first: the marks field is the only always-editable element per row; Enter saves the current row and focuses the next (08_Form_Specifications.md §4).
• Correct-in-place: re-tap a saved cell → edit → save → same upsert endpoint (examination.service.ts:147-175); no edit-mode toggle (server is idempotent).
• Coverage awareness: the MarksSummaryBar is the "done" signal; teachers leave at 100% and return to the detail Coverage tab later for stragglers.
• Offline resilience: classroom Wi-Fi drops are expected; queued rows persist and flush on reconnect with idempotency keys (13_State_Management.md §4) — re-sent upserts converge safely.

4. Error recovery behaviour

5. Publish behaviour (Principal / Coordinator)

• Publish is deliberate: confirm dialog shows slot coverage recap (marked/total per slot). Server publishes whatever exists (examination.service.ts:203-220) — the recap is the client's guard, not the server's.
• Never optimistic: the published badge flips only from the server response.
• Post-publish: client enforces immutability (publish/edit/delete hidden) even though the server permits re-publish and PATCH (OQ-5) — users trust the UI's "published = locked" semantics.

6. Read-only consumption (Student / Parent)

• Results are checked after a "results published" notification (planned) — the only routed job today is in-app/results-published (event-queue-map.ts:27); polling falls back to GET /results/student/:id.
• Report card shares: screenshot share (proposed) — no PDF endpoint exists (report-card is a JSON aggregate, result.service.ts:46-98).
• A subject with no mark renders as 0 with "not marked" (payload ambiguity, result.service.ts:70) — explicitly explained, never presented as a score of 0.

7. Session & permission behaviour

• Session expiry mid-marks-entry: preserved rows stay in the offline queue; after re-login, flush resumes (00-shared/06 §3.6).
• Permission drops (403): feature gating by role claim today (RBAC (planned), OQ-4); on 403 the screen shows a read-only state with a "Contact admin" note — never a crash.

8. Cross-session & multi-device

• Exam list and detail are server-truth on pull-to-refresh; coverage numbers can change when another teacher enters marks (multi-teacher same exam) — the marks screen re-fetches on focus and on WS results.published-style events (planned), 00-shared/07 §8.
• Last-write-wins for marks (upsert) — two teachers editing the same row converge silently; no conflict UI today (unique index only, examination-result.schema.ts:31-33).

9. Accessibility behaviour (00-shared/09)

• Statuses/state conveyed by icon + label + text (never color-only): badges, coverage bar, save states, grade chips.
• Numeric fields announce "{marks} of {max}"; failed rows announce the error.
• Minimum touch targets 48 dp; focus order stable per screen (§06); reduced motion honors Mo duration halving.

10. Instrumentation (proposed)

Listed per screen in 05_Screen_Inventory.md: exam.list_view, exam.row_tap, exam.create_start, exam.detail_view, exam.publish_tap/success/failure, marks_entry_open, marks_saved, marks_row_failed, marks_coverage, exam_slot_add_*, results_view, report_card_view, report_card_share.