Add CourseTask prerequisites for regular interview self-registration

Preferred deadline

September 30, 2026, before registration opens for the first regular ownership interview.

Problem

Regular interview self-registration currently checks the registration window, student status, and duplicate registration, but cannot require completion of earlier CourseTasks.

The current registration endpoint calls registerStudentToInterview, which checks that the student is active and not already registered. The separate manual addInterviewPair flow already creates interviewer–student pairs independently.

The course needs to reserve volunteer interview capacity for students who have qualifying practical or earlier assessment evidence while preserving unconditional administrative pairing for exceptional cases.

This condition belongs to the regular Interview CourseTask administration form, not the dynamic interview-definition JSON. Eligibility is evaluated before an interview pair and conducting form exist.

Configuration

For a regular Interview CourseTask, add a multi-select field such as Required completed tasks.

Conceptually:

type InterviewRegistrationPrerequisites = {
  mode: 'all';
  courseTaskIds: number[];
};

Rules:

• Any other CourseTask from the same course is selectable, whether its result type is score or pass-fail.
• Every selected task must qualify; an arbitrary AND/OR condition builder is not required.
• The interview CourseTask itself cannot be selected.
• Cross-course references are invalid.
• Direct and indirect prerequisite cycles must be rejected because another Interview CourseTask may itself have prerequisites.
• An empty prerequisite list preserves current registration behavior.

Suggested administration UI:

Registration prerequisites

Required completed tasks
[ P3 — Networked JavaScript Application × ]
[ I2 — JavaScript ownership interview     × ]

Students must qualify in every selected task before self-registration.

The selector should show enough context to distinguish similarly named tasks, such as task name, type, result type, and deadline.

Qualification rules

At student self-registration time, evaluate every configured prerequisite atomically:

The following do not qualify:

• missing/no result;
• score equal to 0;
• Failed status;
• pending, cancelled, or errored checker execution.

The eligibility service must resolve the effective result through the correct existing result source for the selected CourseTask type. This may include TaskResult, TaskInterviewResult, or another existing result store. Clients must not infer eligibility themselves from one particular table or nullable field.

The rule consumes the final task result. For a score-backed pass/fail task from #3094, it uses the derived Passed/Failed status, not the hidden internal percentage directly.

Student registration flow

The backend registration endpoint remains authoritative.

When prerequisites are not met, return a stable error code and enough safe information for the student UI to explain what remains:

{
  "code": "INTERVIEW_PREREQUISITES_NOT_MET",
  "message": "Complete the required tasks before registering.",
  "unmetPrerequisites": [
    {
      "courseTaskId": 123,
      "name": "P3 — Networked JavaScript Application",
      "resultType": "pass-fail",
      "state": "failed"
    },
    {
      "courseTaskId": 124,
      "name": "I2 — JavaScript ownership interview",
      "resultType": "score",
      "state": "missing"
    }
  ]
}

Student UI behavior:

• keep the interview and registration dates visible;
• disable registration while requirements are unmet;
• show which tasks must still qualify;
• refresh eligibility after a prerequisite result changes;
• still rely on the registration POST check to prevent stale-client or concurrent-request bypass.

A successful registration remains registered. Distribution should not silently re-evaluate and remove it if a prerequisite result changes later. Administrators can cancel a registration or pair manually when necessary.

Administrative assignment

Course managers and administrators may always:

• create an interview pair manually, regardless of prerequisite results or self-registration state;
• add a student to the interview waitlist manually when that workflow is available.

Administrative assignment:

• does not need an eligibility-override flag;
• does not create a fake prerequisite result;
• does not mark the student as self-registered;
• must not call or be blocked by the self-registration prerequisite check;
• records that the pair/waitlist entry was created administratively and by whom;
• does not require a structured justification.

Non-administrative Mentor or Interviewer actions do not receive this unconditional bypass. If existing mentor pair-management access is retained, it must not be able to assign an ineligible student unless the actor also has manager/admin authority.

Validation and lifecycle

• Referenced tasks must belong to the same course and remain addressable by stable CourseTask IDs.
• Prevent saving self-references or prerequisite cycles.
• If a referenced CourseTask is later disabled, student registration remains blocked and the Interview CourseTask is flagged for administrators rather than silently treating it as satisfied.
• Deleting or detaching a referenced CourseTask must either be prevented or require first removing the reference.
• Updating prerequisites affects future self-registration only; it does not mutate existing registrations or pairs.
• Registration creation and duplicate detection should remain atomic under concurrent requests.

Acceptance criteria

• An administrator can select zero or more same-course CourseTasks as prerequisites on a regular Interview CourseTask.
• Both score and pass-fail CourseTasks are selectable.
• Pass/fail prerequisites require Passed.
• Scored prerequisites require an effective score greater than 0.
• Missing, zero, failed, pending, cancelled, and error states do not qualify.
• All configured prerequisites must qualify.
• The backend resolves results correctly across supported CourseTask/result-storage types.
• Self-reference, cross-course references, and direct or indirect cycles are rejected.
• The student UI explains unmet prerequisites and refreshes when results change.
• The registration endpoint independently enforces eligibility.
• Existing successful registrations are not silently revoked by later result changes.
• Course managers and administrators can create a pair or waitlist entry regardless of prerequisites.
• Administrative assignment does not alter prerequisite results or create fake self-registration.
• Existing interviews without prerequisites behave unchanged.
• Technical Screening is unchanged.
• Tests cover scored/pass-fail/missing states, multiple prerequisites, result-source resolution, invalid references, cycles, concurrent registration, distribution, and unconditional administrative assignment.

Scope boundary

• Applies to regular task/ownership interviews, not Technical Screening.
• Depends on #3094 for first-class score-backed pass/fail CourseTask results.
• Does not implement a general course-progression graph or certificate rules.
• Does not add prerequisites to starting or conducting the interview after a pair already exists.