Sign in

ANU enrolment, rebuilt

A one-week prototype of a slice of ANU’s enrolment system. Sign in as one student, see what your degree still requires, browse next semester’s course catalogue, and enrol in what you’re allowed to take. Courses whose prerequisites you haven’t met say so, in words, naming the requirement that’s missing. Courses needing departmental approval offer to request a permission code instead of enrolling.

Sign in with the demo account: alex.tran@anu.edu.au / enrol-2027.

What good looks like here

The one line that has to be true is the one CI checks least directly and the one a marker checks most directly: if you enrol, then reload, you’re still enrolled. spec/enrolment.test.ts proves it the way a person would, over two separate HTTP requests, never by reading the database back.

The rest of good means: three screens (Your Program, Enrol, Current enrolment) never disagree about whether a course is available, because all three call the same courseStatus function. A blocked course names the actual requirement it’s missing, not a generic refusal. Every reversible action (Withdraw, Cancel request) sits on the same row as the action that created it, not on a separate management screen. Every page answers 200 to a signed-out visitor, because the real system’s catalogue and program pages are public too, and because the deploy probe curls / without following redirects.

What I chose not to build: multiple students, an approver who acts on a pending permission request, unit-count prerequisites (only AND/OR trees of course codes), and courses counting toward more than one requirement group. That last one is a deliberate simplification: a course belongs to at most one group, so progress arithmetic never double-counts, at the cost of not showing a course that could count toward two.

Contrast, spacing and the 44px target are enforced by eye against the interface rules in CLAUDE.md, not by an automated check: the accessibility scan runs in a headless DOM that can’t see colour, so contrast is a judgement call I made at both marking viewports, not a passing test. What is checked mechanically: every route returns the right status signed in and signed out, every course status precedence, the prerequisite evaluator’s logic, and the enrolment round trip above.

The course catalogue is hand-authored dummy data standing in for the handbook. Nothing is scraped, and there is no second user to demonstrate multi-user behaviour.