Student portal

Document: SDD-05
Status: Working draft
Date: 18 September 2026
Milestones: Auth/mobile on M2; learning/records/fees on M3; remainder on M5

1. Purpose

Give an enrolled student a single web surface for identity, academic life, fees, and support. The current v1 frontend is a demo: screens exist; they do not save to the CMS.

This portal is not done when the student UI looks finished. Each student CAP also needs a lecturer or staff path, or a verified old-CMS equivalent.

Agent / behaviour knowledge (canonical): docs/ai/frontend/student-portal/ in control-plane. Generate or refresh human docs from that tree using docs/ai/process/generate-documentation.md.

2. Actors

Student (authenticated). Upstream writers: Registry, Faculty/Lecturer, Bursary, support desks.

3. Information architecture

Campus-requested student features: timetable, announcements, study guides, notes, briefs, assignment submit, revision, past papers, policies.

4. Key flows

4.1 Registration and fees

sequenceDiagram
  actor S as Student
  participant P as Student portal
  participant API as Portal API
  participant CMS as Existing CMS
  actor B as Bursary

  S->>P: Select modules (CAP-10)
  P->>API: Validate rules atomically
  API->>CMS: Registration transaction
  CMS-->>P: Invoice / balance (CAP-45)
  S->>P: Submit bank-transfer proof (CAP-46)
  P->>API: Store file metadata plus bytes
  B->>CMS: Verify proof; allocate payment
  Note over P,CMS: Proof is never payment until Bursary allocates

4.2 Assignment handoff

sequenceDiagram
  actor L as Lecturer
  actor S as Student
  participant P as Portals
  participant CMS as CMS / file store

  L->>P: Publish brief with release rule (CAP-19)
  S->>P: Download authorised brief
  S->>P: Submit / replace / withdraw file (CAP-20)
  P->>CMS: Durable object plus receipt
  L->>P: Mark and publish feedback (CAP-28)
  S->>P: View published mark only

5. Design rules

1. Edits vs approvals (CAP-08). Some profile fields save directly; others raise a staff task. The split is a Registry policy, not a UI guess.
2. Documents (CAP-09). View/Download must deliver files. No-op buttons stay Placeholder.
3. Registration (CAP-10) is semester registration against legacy rules, not admissions. Atomic save: clash, credit, prerequisite checks in one CMS transaction.
4. Results (CAP-13, 28) show only published results. Marking is lecturer/staff.
5. Announcements (CAP-16) need a real feed, audience, and open/detail action. Preview cards without an open action are Partial.
6. Fees (CAP-45, 46). Ledger from CMS. Fictional banking details must not ship. Proof upload is metadata and bytes; staff verification is a separate state.
7. Learning files (CAP-17–22) require lecturer publish + authorised student access. A generic Materials list of no-op rows is not delivery.
8. Chat (CAP-25) is not Live while messages stay in one mock session.
9. Immigration (CAP-50) is case management, not a blank page or a mock eligibility widget.

6. Current baseline (selected)

From BASE-01…BASE-55. Full list in SDD-09.

Simplified “Frontend ready” on these rows is Demo or Partial. Do not report them as complete in the working group.

7. Remaining frontend estimates (student only)

From the simplified sheet, not a commitment:

Wiring and CMS work is separate and larger.

8. Acceptance (M3 student slice)

For each in-scope CAP:

• Student action persists in CMS or file store.
• Matching lecturer/staff action is Live or verified in old CMS.
• No sample ledger, no fictional bank, no mock session identity.
• Core mobile CAPs accepted on phone widths.

9. Related documents

Lecturer pair: SDD-06. Staff pair: SDD-07. Catalogue: SDD-11.