# Phase 1 implementation plan

Status: delivery plan followed for the local Phase 1 implementation on 28 October 2026. The baseline and implementation sequence are retained below. See [implementation evidence](phase-1-implementation.md) for completed checks, data preservation and remaining school-specific setup. No production deployment was performed.

## Release outcome

A School Administrator prepares Courses, curricula, Sections and scheduled Subject Classes. Enrollment Staff or the Registrar prepares a Student's editable subject load. Finance Staff records manual clearance, with Finance Approver approval for past-debt arrangements. The Registrar finalizes enrollment and issues COR. Students and Teachers see the correct schedules and actual rosters. Teachers directly enter and finalize final subject grades for the next enrollment's prerequisite checks.

Registrar amendments produce new COR Versions and preserve the original, with graded subjects locked against drop/class changes. School Administrator rescheduling preserves issued CORs and checks all affected timetables. Registrar ending of Section membership frees only the Section place, without dropping subjects or deleting records.

Quizzes, assessments, grading-period results, grade calculations, teaching modules/materials, GPA/GWA, library workflows, native apps and product AI features remain deferred. Keep one application, existing scoped roles and database audit history; no workflow builder or separate service deployment is required for these flows.

## Baseline gaps addressed by Phase 1

| Area | State before Phase 1 | Implementation work |
| --- | --- | --- |
| Academic setup | Program, Subject, Curriculum and CurriculumSubject models exist. Requirements have year and free-text term labels; units already belong to Subject. | Present Courses clearly; add curriculum-specific Major/Minor classification and an explicit mapping between curriculum terms and dated periods. Preserve assigned published versions. |
| Enrollment calendar | AcademicPeriod has school year, year/semester kind, dates and enrollment-open flag. | Add/apply yearly or semester enrollment settings per school level, with clear applicable period selection. |
| Sections | CourseOffering has a free-text section label; there is no persistent Section/membership model. | Add continuing Sections, confirmed/ended membership history, intake availability and ordered suggestions. Keep original enrollment Section history. |
| Class sharing | Class selection requires the offering's program to equal the Student curriculum program. | Permit compatible shared Subject Classes when the actual subject belongs to each Student's curriculum. Keep Branch, period, school-level/policy compatibility and scope checks. |
| Scheduling | CourseOffering.schedule is free text. | Add weekday/start/end meeting entries and multiple weekly meetings where needed, Teacher/Student overlap checks and reasoned rescheduling. |
| Draft subject load | EnrollmentService selects classes manually. | Generate the curriculum-derived draft, match Section defaults, preserve staff edits and show unresolved requirements or unavailable classes. |
| Finance | FinanceService uses aggregate balance and ledger version; requests support settled/arrangement kinds. | Add explicit Cleared/On Hold decisions and preserve the prior-debt arrangement approval boundary. Review prior/current balance data before changing existing guard behavior. |
| COR and amendments | Finalization writes one COR snapshot; subject selection permits drafts only. | Retain issued COR Versions and add checked Registrar amendments without reopening the whole live enrollment as a draft. |
| Final grades | GradeService finalization requires complete assessment calculations, even for an adjusted official result. | Add direct entry/finalization without assessment dependencies, retaining Teacher authority, scale validation and corrections. Reuse existing grade history where appropriate. |
| Student records/access | Directory, profile, private files, academic history, role/Branch scope and audit services already exist. | Extend these views with the new Section, timetable, COR-version and manual-grade records without losing existing data or access checks. |

Primary existing owners: SetupService, EnrollmentService, FinanceService, GradeService, AccessService, PageService, StudentProfileService, SchoolRequest, the Enrollment/Course/Student policies, and the existing Setup, Enrollment, Course, Finance and Student profile pages. Extend these seams; add focused actions/policies for new operations rather than putting business checks in React pages.

## Delivery sequence

### 1. Preserve records and add the model foundations

Use additive migrations for Sections, current/ended membership, available Sections by Branch/Course/Year or Grade/period, Section-to-usual-class associations, class meetings, recorded capacity exceptions and COR version history. Store the proposed Section separately from confirmed membership. Preserve each finalized enrollment's historical Section and issued document.

Retain existing Student identities, memberships represented by historical data, final grades, correction history, transfer evidence, private files, financial entries and audit records. Existing CORs become retained initial versions with the same contents. Do not run destructive database resets or reseed retained application data.

Do not merge legacy groups solely because their text labels match: names can recur across Branches, Courses and intakes. Preserve the old class label until reviewed mappings are available. Free-text schedules and curriculum term labels need reviewed mapping; mark unresolved setup visibly instead of inventing times, subject classifications or term matches.

Keep final-grade scales and passing outcomes available without requiring assessment categories or conversion from calculated scores. Do not fabricate assessments to satisfy the old finalization path.

### 2. Make academic setup and schedules usable

School Administrator setup covers Courses, subjects/units, curriculum requirements/classification/prerequisites, dated periods and yearly/semester settings, Sections/availability/capacity, and Subject Classes/Teachers/meetings. The curriculum defines subjects, never weekly times.

Use structured weekday/start/end meeting entries, supporting multiple meetings for one class. Check Teacher overlaps during setup and rescheduling. A shared class is one booking and one capacity, regardless of how many Sections normally use it. Teacher timetables remain read-only for teaching permission.

Rescheduling requires a reason and checks every actually enrolled Student's other classes as well as the Teacher's assignments. Save old/new times and audit details together; reject conflicts without partial changes. Current timetables show saved new times, while issued COR Versions retain their original contents.

Follow the existing Figma-based shared components and readable responsive layout. Use school role names and clear subject/class labels. Reuse current account/Branch permissions; a future Dean receives capacity approval only through its explicit permission and scope, not a Registrar permission bundle.

### 3. Build the curriculum-to-draft enrollment flow

Identify Student, Branch, Course or school-level offering, Year/Grade, assigned curriculum and dated enrollment period. Match the applicable curriculum term explicitly; a curriculum term is not the same thing as this year's calendar dates.

Returning Students retain their current Section. For an incoming Student without one, suggest the first eligible Section with space in the School Administrator's available-section order. Prefill the Section's eligible usual classes for the required subjects. Leave missing/ambiguous class choices visible for review. Students without a Section retain a manual class-selection path.

Exclude unmet-prerequisite subjects with reasons. Apply approved transfer credits to an editable draft, preserving unrelated selections. Retain explicit warning-only retakes and staff adjustments across refreshes. Merely selecting a prerequisite in the same draft does not satisfy it, and a new failed retake does not cancel an earlier valid pass.

Integrate manual transfer-credit review into the Student/enrollment context using the existing evidence and Registrar approval workflow. External titles, codes and units do not automatically prove or disprove equivalency. Approval alone does not put the Student on an attended class roster.

### 4. Finalize with clearance and consistent capacity checks

Finance Staff records Cleared or On Hold for the enrollment and records the decision details. On Hold, missing or invalidated clearance blocks Registrar finalization. Past debt requires settlement or a Finance Approver's documented arrangement; an ordinary Cleared label cannot waive that approval. Changes to relevant financial records require clearance review.

Review the existing ledger's prior/current-term distinction before enabling this workflow. Aggregate current charges must not be assumed to prove past debt, and ambiguous legacy records must not be silently treated as debt-free. Keep the debt approval boundary explicit, with meaningful fixtures for past debt, current-term requirements and approved/unapproved arrangements. Automatic tuition assessment is outside Phase 1.

Drafts reserve neither Section places nor Subject Class seats. Existing confirmed current Section members count once even before their next enrollment is finalized. Recheck all limits and timetable/academic/financial conditions when finalizing. Persist an explicit capacity exception for its Student, target assignment and context, with authorized approver and reason; do not reuse it as blanket approval.

Commit confirmed enrollment, any new Section membership, class selections, COR Version and audit events together. Use consistent locking/checks across finalization, amendments and rescheduling so competing actions cannot exceed capacity or produce an unreviewed timetable. A failed operation leaves the current confirmed records unchanged.

### 5. Add amendments, direct grades and membership ending

Registrar amendments add/drop subjects or switch a class only with a reason and the full eligibility/capacity/timetable/financial checks. Accepted changes update current rosters and issue a new COR Version, retaining earlier versions and before/after history. Do not create a duplicate same-period enrollment.

For each Student, finalized final grades lock the affected subject against dropping or class switching, whether the result passes or fails. Other ungraded subjects remain amendable. Teacher corrections preserve official history and do not reopen the Registrar's lock or transfer a grade to another class.

Direct grade input lets the assigned Teacher save and finalize one official final result per enrolled Student/Subject Class attempt, validating the school's allowed grade values and passing outcomes. There is no quiz, assessment, period-weight or calculation dependency. Student views and subsequent prerequisite checks use finalized results; a missing/draft result is not a pass.

Registrar ending of current Section membership requires a reason and retained end history. Decrease only the Section membership count; keep subject enrollments, actual rosters, Subject Class seat counts, grades, CORs and audit history. Do not automatically promote, graduate or withdraw the Student from classes, and do not silently restore ended membership during draft refresh/finalization.

### 6. Finish scoped views, reports and release verification

Keep the Student directory/profile and private file workflows. Add clear current Section versus enrollment-history labels, current timetables, current/earlier COR Versions and official final results. Teacher views show My Schedule, actual My Classes rosters and manual Final Grades.

Use basic enrollment status/counts, Student lists, class rosters, Student/Teacher schedules, clearance lists, COR print views and final-grade lists. Reuse existing print/export support where appropriate; bespoke school templates can be reviewed separately. Counts, details, files and exports follow the same record scopes.

The existing assessment/material routes and UI are broader than Phase 1. Enforce the release boundary in server access and navigation while preserving retained data. Keep final historical results available through their authorized records. Do not claim the simplified release is complete because deferred menus are merely hidden.

## Worked example: college semester cycle

These are illustrative school settings, not external curriculum or grading standards.

1. School Administrator configures College as semester-based, a dated first semester, a published Course A curriculum with Year 1/first-semester requirements, and Sections 1-A then 1-B. Section 1-A is at 39/40. ENG101 is a three-unit shared subject and has one offered class for both Sections; Course B can reference it with a different Major/Minor classification.
2. Enrollment Staff finds Ana's school-wide Student Record. Her incoming draft suggests 1-A, applies the curriculum subjects and usual eligible classes, and remains editable. A transferee's approved external equivalency would mark its mapped local subject Credited; merely uploading a transcript would not.
3. Finance Staff records On Hold until payment conditions are met. If Ana has past debt, the Finance Approver must approve a documented arrangement or settlement must be recorded before valid Cleared status permits enrollment.
4. Registrar finalizes after all checks. Ana becomes the 40th confirmed member, actual class seats are counted once, and COR version 1 is issued. A competing draft loses an unavailable last place and requires review; it is not silently reassigned.
5. A needed switch of an ungraded class is handled as a Registrar amendment, with checks and a reason. COR version 2 becomes the current document, while version 1 and the amendment audit history remain retained. Shared class rosters reflect actual enrollment, not every Section member.
6. The assigned Teacher directly records a final grade, for example an allowed numeric value that the school's policy explicitly marks Passed. Once finalized, Registrar drop/class-switch actions for that graded subject are blocked. A Teacher correction retains the original result and reasoned history.
7. A new second-semester enrollment uses the appropriate curriculum term, new class offerings and valid prior passing results or approved credits. Ana retains her Student identity, assigned curriculum and continuing Section. Do not automatically promote her Year/Grade or reuse old class seats. An intentional later retake warns but preserves the original passing history.

## Worked example: yearly high school and membership ending

1. School Administrator configures a high-school level as yearly and prepares the dated school-year offerings. Registrar confirms the returning Student's Year/Grade manually, retaining the existing Section and assigned curriculum. The yearly load produces one enrollment/COR cycle; there is no quarterly gradebook in Phase 1.
2. School Administrator proposes a meeting-time change. A conflict for any enrolled Student or the assigned Teacher rejects the change. A valid reasoned change updates current schedules and retains the issued COR and old/new times in audit history.
3. Teachers enter final subject results directly under the assigned percentage or numeric policy. These finalized results and approved credits inform the next year's draft; the calendar alone does not promote the Student.
4. When the Student leaves the group or graduates, Registrar ends Section membership with a reason. The Section count decreases, but existing subject enrollments and class rosters stay intact. Their class places are not freed by this action alone. Earlier enrollment Section labels, grades, COR Versions and audit history remain available under their existing permissions.

## Verification gates

| Gate | Required evidence |
| --- | --- |
| Retained data | Additive migrations preserve existing Student IDs, COR contents, final grades/corrections, financial records and private files; ambiguous legacy mappings are visible for review. |
| Setup and cycle | Yearly and semester levels select the correct curriculum subjects and dated classes; Section availability/order and Major/Minor classification follow their own settings. |
| Shared classes | Same subject/units across Courses, curriculum-specific classification, one Teacher booking/roster and one combined class capacity; attending another group's class never changes Section membership. |
| Draft behavior | Eligible defaults, visible prerequisite exclusions, approved-credit cleanup, warning-only retakes, preserved staff edits and no silent restoration of ended membership. |
| Capacity/concurrency | Competing last-place finalizations cannot overfill; Section and class limits stay independent; explicit exceptions require the right approver, target and reason. |
| Finance | Cleared/On Hold enforcement, valid prior-debt arrangement approval, unauthorized approval denial and clearance review after financial-record changes. |
| Schedule changes | Every affected enrolled Student and Teacher checked; conflicts reject atomically; valid change updates current views and retains original COR/audit history. |
| Amendments/COR | Reasoned checked update, correct rosters, new retained COR Version, no partial change on failure, and no drop/switch for finalized passing or failing grades. |
| Direct grades | Teacher-only manual input without assessments, policy-valid values, draft/official separation, reasoned corrections and next-period prerequisite use. |
| Membership ending | Registrar/reason required; only Section capacity freed; subject enrollments, actual rosters, grades and history retained. |
| Access/audit | Branch/department/class/Student scopes on views and direct requests, future Dean grant limited to its permission, private files protected and database audit events retained. |
| Rendered workflow | Exercise incoming and returning college/high-school flows in the browser at desktop and phone widths; verify real tables/forms, COR history, schedules, rosters, messages and navigation. |

Use meaningful feature/integration checks and the isolated PostgreSQL test database for transaction/locking behavior. Do not reset the retained application database. Existing earlier gradebook tests are historical evidence; rerun applicable checks and add coverage for the corrected workflows. Production deployment, school-specific data import and real-user acceptance remain separate from local source/build/browser verification.