05 — Screen Inventory (Results Module)

• Screen purposes
  • S1 — Marks Entry Grid
  • S2 — Exam-Subject Detail
  • S3 — Student Results List
  • S4 — Report Card View
  • S5 — Grade Summary (completion & distribution overview)
• Gaps vs. screens

Every screen maps 1:1 to a real endpoint or DTO. No screen is invented; five screens cover the module. (forward-looking) = client screens against the implemented API.

Screen purposes

S1 — Marks Entry Grid

• Data: all ExaminationResult rows for one exam-subject (examination-result.repository.ts:20-24), one editable row per student: marksObtained, grade (client-supplied string), remarks (optional).
• Writes: per-row POST /api/v1/results/exam-subject/:examSubjectId/marks (idempotent upsert, examination.service.ts:147-175).
• Context header: subject date, startTime/endTime, maximumMarks, passingMarks (examination-subject.schema.ts:18-31).

S2 — Exam-Subject Detail

• Data: one ExaminationSubject row; entry coverage (entered/total students — computed client-side from S1 data).
• Actions: navigate to S1; shows subject schedule info.

S3 — Student Results List

• Data: all ExaminationResult rows for a student (examination-result.repository.ts:26-28) — flat rows, not grouped by exam (no grouping endpoint exists; client groups by examinationSubjectId or via exam lookup).
• Action: open S4 for any exam with a report card.

S4 — Report Card View

• Data: ReportCard object (result.service.ts:8-26): subject rows, totals, percentage, overallGrade, generatedAt.
• Read-only. Errors: 404 when exam has no subjects (result.service.ts:51-52).

S5 — Grade Summary (completion & distribution overview)

• Data: subjects of exam (S2 endpoint) + results per subject (S1 endpoint).
• Shows per-class/per-subject: entries entered vs students, marks distribution; publish readiness.
• No dedicated backend endpoint — (proposed) for a server-side aggregation (blueprint GET /api/v1/results/analytics, Results.md:28); today client-side aggregation only.

Gaps vs. screens