docs(contract): Fix formatting, typos, and add website link

Reviewed-on: #7

README.md

@@ -1,38 +1,40 @@
 # Learner Management System Frontend
 
-This is the frontend for a modular and responsive Learner Management System (LMS), built with Vanilla Typescript, Vite, and Bootstrap v5.3. It utilizes a widget-based system and a global API structure designed to interact with a backend server.
+This is the frontend for a modular and responsive Learner Management System (LMS), built with Vanilla Typescript, Vite, and Bootstrap v5.3. It utilizes a widget-based system and interacts with a dedicated backend server via a RESTful API using PAKE SRP for authentication.
 
 ## Features
 
-* **Modular Architecture:**  Organized into modules for easy maintainability and scalability.
+* **Modular Architecture:** Organized into distinct modules (widgets, layouts, pages, API) for maintainability and scalability.
-* **Responsive Design:** Built with Bootstrap 5.3 to ensure responsiveness across various devices.
+* **Responsive Design:** Uses Bootstrap 5.3 for a consistent experience across desktops, tablets, and mobiles.
-* **Widget System:**  Extensible widget system with two size types (default full-width and icon-type for sidebar).
+* **Widget System:** Extensible widgets with `default` (full-width) and `icon` (sidebar) sizes.
-* **Global API System:**  Clearly defined API structure for communication with a backend (currently mocked).
+* **API Integration:** Connects to a live backend API (default: `http://localhost:8080/api`) for data fetching and actions.
-* **Layout Modules:**  Pre-built layouts (Centered, Three-Column, Split-Column) for different page structures.
+* **Secure Authentication:** Implements Password-Authenticated Key Exchange (PAKE SRP) for secure login via the `thin-srp` library.
-* **Page Components:**  Includes pre-built pages for Login, Register, Dashboard, Settings, Admin, Profile, and Manage Students.
+* **Token-Based Sessions:** Manages user sessions using tokens obtained from the backend upon successful login (stored in localStorage by default).
-* **Topbar Module:**  Navigation and user profile dropdown.
+* **Layout Modules:** Provides pre-built layouts: `CenteredLayout`, `ThreeColumnLayout`, `SplitColumnLayout`.
-* **Modal Module:** (To be implemented) For reusable modal components.
+* **Core Pages:** Includes pages for Login, Register (info only), Dashboard, Profile, Account Settings (Modal), Admin Dashboard, Manage Students.
-* **Basic Authentication Flow:** Login and logout functionality with token-based session management (localStorage).
+* **Topbar Module:** Features main navigation and a user profile dropdown with account actions.
+* **Modal Module:** Provides a reusable container for modal dialogs (e.g., Account Settings, notifications).
 
 ## Technologies Used
 
-* **Vanilla Typescript:**  For a type-safe and maintainable codebase.
+* **Vanilla Typescript:** For a robust, type-safe, and maintainable codebase without framework overhead.
-* **Vite:**  For fast and efficient development and build process.
+* **Vite:** For an extremely fast development server and optimized build process.
-* **Bootstrap v5.3:**  For responsive layout and styling.
+* **Bootstrap v5.3:** For responsive layout, styling components, and utility classes.
-* **pnpm:**  Package manager for efficient dependency management.
+* **pnpm:** Efficient package manager for dependency management.
-* **argon2-browser:** (For demonstration purposes - **Backend Hashing Recommended**) For frontend password hashing demonstration (Argon2id). **Important:** In a production environment, password hashing should be performed on the backend for security reasons.
+* **thin-srp:** JavaScript client library for Secure Remote Password (SRP) protocol implementation.
 
 ## Prerequisites
 
 * **Node.js** (>= 18 recommended)
 * **pnpm** (Install globally: `npm install -g pnpm`)
+* **Running Backend:** The LMS backend service must be running (see backend README) and accessible (defaults to `http://localhost:8080`).
 
 ## Installation and Setup
 
 1. **Clone the repository:**
 
     ```bash
-    git clone <repository_url>
+    git clone <your-frontend-repository-url>
     cd lms-frontend
     ```
 
@@ -42,85 +44,86 @@ This is the frontend for a modular and responsive Learner Management System (LMS
     pnpm install
     ```
 
-3. **Start the development server:**
+3. **Configure API Base URL (Optional):**
+    * If your backend runs on a different address or port, update the `API_BASE_URL` constant in `src/api/api.ts`.
+
+4. **Start the development server:**
 
     ```bash
     pnpm dev
     ```
 
-    This will start the Vite development server. Open your browser and navigate to the address provided in the console (usually `http://localhost:5173/`).
+    This will start the Vite development server. Open your browser and navigate to the address provided (usually `http://localhost:5173`).
 
 ## Project Structure
 
 ```bash
 lms-frontend/
 ├── index.html          # Main HTML entry point
-├── pnpm-lock.yaml      # pnpm lock file for dependency management
+├── package.json        # Project dependencies and scripts
-├── pnpm-workspace.yaml # pnpm workspace configuration
+├── pnpm-lock.yaml      # pnpm lock file
-├── public/             # Public assets (images, etc.)
+├── public/             # Static assets served directly
 ├── README.md           # This README file
 ├── src/                # Source code directory
-│   ├── api/              # API interaction functions (mocked in api.ts)
+│   ├── api/
-│   ├── assets/           # Static assets (images, icons)
+│   │   └── api.ts      # Functions for interacting with the backend API (SRP, data fetching)
-│   ├── components/       # Reusable components
+│   ├── assets/         # Static assets processed by Vite (images, icons)
-│   │   ├── layouts/      # Page layout components (CenteredLayout, ThreeColumnLayout, SplitColumnLayout)
+│   ├── components/
-│   │   ├── modules/      # Modules (TopbarModule, ModalModule - to be implemented)
+│   │   ├── layouts/    # Page layout components
-│   │   ├── widgets/      # Widget components (LoginWidget, ButtonWidget, etc.)
+│   │   ├── modules/    # Larger UI modules (TopbarModule, ModalModule)
-│   ├── main.ts           # Main entry point for the application
+│   │   └── widgets/    # Reusable UI widgets
-│   ├── pages/            # Page components (LoginPage, DashboardPage, etc.)
+│   ├── main.ts         # Application entry point, initializes router/app state
-│   ├── styles/           # Global styles and Bootstrap import (index.css)
+│   ├── pages/          # Page-level components/logic
-│   ├── types/            # Typescript interfaces (Widget.ts, User.ts)
+│   ├── styles/
-│   ├── utils/            # Utility functions (api.ts, auth.ts)
+│   │   └── index.css   # Global styles, Bootstrap import
-│   ├── vite-env.d.ts     # Vite environment declaration
+│   ├── types/          # TypeScript interfaces and type definitions
-├── tsconfig.json       # Typescript configuration
+│   ├── utils/
-├── vite.config.ts      # Vite configuration
+│   │   └── utils.ts    # Utility functions (auth state management, storage)
+│   └── vite-env.d.ts   # Vite environment type declarations
+├── tsconfig.json       # TypeScript configuration
+├── tsconfig.node.json  # TypeScript configuration for Node contexts (e.g., Vite config)
+└── vite.config.ts      # Vite build tool configuration
 ```
 
 ## Widget System
 
-The frontend is built around a widget system. Widgets are independent, reusable components that display specific information or functionality.
+The UI is composed of reusable widgets found in `src/components/widgets/`. Each widget encapsulates specific functionality or displays data. They support different sizes (`default`, `icon`) for adaptability within various layouts.
-
-* **Widget Sizes:**
-  * `default`: Full column width, suitable for most widgets.
-  * `icon`: Smaller size, designed for use in collapsed sidebars or icon-based menus.
-
-* **Widget Components:** Located in `src/components/widgets/`.  Examples include:
-  * `LoginWidget`:  Login form.
-  * `RegisterWidget`:  Registration information display.
-  * `ButtonWidget`:  Reusable button component.
-  * `StudentCountWidget`, `TeacherCountWidget`, `ProfileInfoWidget`, `PostFeedWidget`, `StudentTableWidget`, `TuitionFeeWidget`: Placeholder widgets to be implemented.
 
 ## API System
 
-The frontend is designed to interact with a backend through a global API system defined in `src/utils/api.ts`.
+Defined in `src/api/api.ts`, this module handles all communication with the backend API.
 
-* **Current Implementation:** The `api.ts` file currently contains **mocked API calls** for demonstration purposes. It simulates API responses using timeouts and hardcoded data.
+* **Live Interaction:** Functions use `fetch` to make requests to the running backend (default: `http://localhost:8080/api`).
-* **Backend Integration:** To connect to a real backend, you will need to replace the mocked API calls in `api.ts` with actual `fetch` requests to your backend endpoints.
+* **SRP Flow:** The `login` function implements the two-step SRP authentication handshake with the backend.
-* **Expected Backend Endpoints (Example):**
+* **Authenticated Requests:** Other API functions automatically include the stored authentication token in the `Authorization: Bearer <token>` header for protected endpoints.
-  * `POST /api/login`: User login.
+* **Error Handling:** Includes basic error handling and detection of unauthorized (401) responses.
-  * `GET /api/user`: Get user data (requires authentication).
+* **Key Endpoints Used:**
-  * `POST /api/logout`: User logout.
+  * `POST /api/auth/srp/start`
-  * `/api/students`, `/api/teachers`, `/api/admin/students`, etc.: Endpoints for managing students, teachers, and other LMS data.
+  * `POST /api/auth/srp/verify`
+  * `POST /api/auth/logout`
+  * `GET /api/profile/{user_id}`
+  * `PUT /api/profile/settings`
+  * `GET /api/admin/dashboard`
+  * `GET /api/admin/students`
+  * `GET /api/admin/students/{student_id}/financials`
 
-## Backend Considerations
+## Backend Interaction Notes
 
-* **Password Hashing (Backend Recommended):**  While `argon2-browser` is included for frontend password hashing demonstration, **it is strongly recommended to implement password hashing (using Argon2id or similar) and salting on the backend for enhanced security.** The frontend should send passwords securely (HTTPS) to the backend, and the backend should handle the hashing and verification process.
+* **Authentication:** The backend handles the secure verification of passwords using SRP. The frontend never stores or hashes the raw password itself after the initial SRP calculation during login.
-* **Authentication and Authorization:** The backend should implement robust authentication (e.g., JWT or session-based) and authorization mechanisms to secure API endpoints and protect sensitive data.
+* **Authorization:** Access to specific API endpoints (e.g., admin routes) is controlled by the backend based on the user's role/permissions associated with their session token.
-* **Database:** The database schema outlined in the initial prompt should be implemented on the backend to store user data, course information, enrollments, etc. (Refer to the initial prompt for database schema details).
+* **Data Source:** All dynamic data (user info, student lists, etc.) is fetched from the backend, which interacts with the MariaDB database.
-* **Backend Technology:** You can choose any suitable backend technology (Node.js, Python, Java, PHP, etc.) to build the API endpoints and connect to the database.
 
 ## Further Development
 
-* **Implement Modal Module:** Create a reusable `ModalModule` component in `src/components/modules/ModalModule.ts` to handle modals for various purposes (e.g., classrooms under construction, account settings).
+* **Complete Widget Functionality:** Ensure all widgets fetch and display real data from the backend API.
-* **Complete Widget Implementations:** Implement the remaining placeholder widgets in `src/components/widgets/` (e.g., `StudentCountWidget`, `TeacherCountWidget`, `ProfileInfoWidget`, `PostFeedWidget`, `StudentTableWidget`, `TuitionFeeWidget`) to display actual data from the backend.
+* **Admin Page Enhancements:** Implement full CRUD operations for student/teacher management, filtering, batch actions, and enrollment assignments.
-* **Account Settings Modal:** Develop the Account Settings Modal to allow users to edit their profile information and change passwords.
+* **Student Table Widget:** Integrate a robust table library (e.g., Tabulator, TanStack Table) for improved sorting, filtering, and pagination.
-* **Admin Page Functionality:** Implement the functionality for the Admin page, including student and teacher management, using appropriate widgets and API calls.
+* **Classrooms Module:** Build out the Classrooms feature beyond the placeholder modal.
-* **Student Table Widget:** Integrate a table library (e.g., Tabulator, DataTables) into the `StudentTableWidget` for enhanced table features like sorting, filtering, and pagination.
+* **Robust Error Handling:** Implement more comprehensive error handling and user feedback mechanisms throughout the UI.
-* **Classrooms Page/Modal:**  Implement the Classrooms feature, potentially starting with a modal indicating "Under Construction" as initially requested, and then expanding to a full Classrooms page with relevant widgets.
+* **Client-Side Validation:** Add more input validation for forms (e.g., account settings).
-* **Form Validation:** Add client-side form validation to login, registration (if implemented), and account settings forms for better user experience.
+* **UI/UX Polish:** Refine styling, transitions, and interactions for a smoother user experience.
-* **Error Handling:** Improve error handling in API calls and display user-friendly error messages.
+* **Testing:** Implement unit and potentially end-to-end tests.
-* **Styling and UI Polish:** Enhance the visual design and user interface with custom CSS and Bootstrap components to create a polished and professional LMS frontend.
+* **State Management:** For larger applications, consider introducing a dedicated state management library (like Zustand, Pinia, Redux Toolkit) instead of relying solely on `utils.ts`.
-* **Backend Integration:** Replace the mocked API calls with real API calls to your backend endpoints to connect the frontend to the backend data and functionality.
 
 ## Contributing
 
@@ -128,4 +131,4 @@ The frontend is designed to interact with a backend through a global API system
 
 ## License
 
-[View the License](./LICENSE)
+[View MIT License](./LICENSE)

docs/CONTRACT.md

@@ -1,14 +1,15 @@
 # **SOFTWARE DEVELOPMENT AND IMPLEMENTATION AGREEMENT**
 
 **Parties:**  
-(3-5 Year Term)
+(Term: 3-5 Years, To be finalized based on Support/Maintenance period post-delivery)
-This Software Development and Implementation Agreement (the "**Agreement**") is entered into effective as of **[Date - e.g., January 1, 2024]** (the "**Effective Date**"), by and between:
 
-Cell Tech, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Funda Dalipe, San Jose, Antique.
+This Software Development and Implementation Agreement (the "**Agreement**") is entered into effective as of **[Date - e.g., August 5, 2024]** (the "**Effective Date**"), by and between:
+
+**CellTech**, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Funda Dalipe, San Jose, Antique (hereinafter referred to as "**Developer**"), and online at https://gitea.opossum-arcturus.ts.net/CellTech.
 
 AND
 
-Western Institute of Technology, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Lapaz, Iloilo City.
+**Western Institute of Technology**, a Partnership organized and existing under the laws of the Republic of the Philippines, with its principal place of business at Lapaz, Iloilo City (hereinafter referred to as "**Client**").
 
 (Developer and Client may be referred to individually as a "**Party**" and collectively as the "**Parties**").
 
@@ -26,41 +27,65 @@ C.  Client desires to engage Developer to perform such software development and
 
 ## ARTICLE 1: DEFINITIONS
 
-*(Optional: Add definitions for key terms used throughout the agreement if needed for clarity, e.g., "Acceptance Criteria," "Deliverables," "Sprint," "Intellectual Property," etc.)*
+For the purposes of this Agreement, the following terms shall have the meanings ascribed to them below:
+
+1.1 **"Acceptance Criteria"** means the specific, measurable criteria defined in this Agreement or mutually agreed upon test plans, which the System must meet to be formally accepted by the Client.
+
+1.2 **"Agile"** refers to the iterative and incremental software development methodology described in Section 2.2.
+
+1.3 **"Confidential Information"** has the meaning set forth in Article 10.
+
+1.4 **"Deliverables"** means the specific items, including software code, documentation, reports, and training materials, that Developer is obligated to provide to Client under this Agreement, as further detailed in Section 4.3.
+
+1.5 **"Intellectual Property"** means any and all patents, copyrights, trademarks, trade secrets, database rights, design rights, and other proprietary rights, whether registered or unregistered.
+
+1.6 **"LMS"** or **"System"** means the custom Learner Management System software to be developed and implemented by Developer for Client pursuant to this Agreement.
+
+1.7 **"OPAQUE"** refers to the Oblivious Pseudo-Random Function (OPRF) based Asymmetric Password-Authenticated Key Exchange protocol intended for user authentication within the System.
+
+1.8 **"PAKE"** means Password-Authenticated Key Exchange, a class of cryptographic protocols allowing two parties to establish a shared cryptographic key based on a user's password without transmitting the password itself. OPAQUE is a type of PAKE protocol.
+
+1.9 **"Services"** means the software design, development, implementation, testing, training, documentation, and delivery services related to the System to be performed by Developer under this Agreement.
+
+1.10 **"Sprint"** means a time-boxed iteration (typically 2-4 weeks) within the Agile development process during which a defined amount of work is completed and made ready for review.
+
+1.11 **"Source Code"** means the human-readable programming language instructions used to create the System software.
+
+1.12 **"UAT"** means User Acceptance Testing, the process by which Client validates that the System meets the agreed-upon requirements and Acceptance Criteria.
 
 ## ARTICLE 2: SCOPE OF SERVICES
 
-2.1 **General Scope:** Developer shall perform the Services necessary to design, develop, test, and implement the System as described in this Agreement and its Exhibits. The System is intended to function as a Learner Management System providing functionalities for learners, instructors, and administrators.
+2.1 **General Scope:** Developer shall perform the Services necessary to design, develop, test, implement, and deliver the System as described in this Agreement and its Exhibits. The System is intended to function as a comprehensive Learner Management System providing functionalities for learners, instructors, and administrators of Western Institute of Technology.
 
 2.2 **Development Methodology:** Developer shall utilize an Agile (Iterative and Incremental) Software Development Life Cycle (SDLC) methodology for the performance of the Services.
 
-> a.  **Process:** The project will be broken down into smaller, manageable cycles ("**Sprints**," typically 2-4 weeks). Each Sprint will generally include planning, design, development, testing, and stakeholder review, aiming to produce a potentially shippable increment of the System.
+> a.  **Process:** The project will be broken down into Sprints. Each Sprint will generally include planning, design, development, testing, and stakeholder review, aiming to produce a potentially shippable increment of the System. Sprint duration will be mutually agreed upon, typically **[e.g., two (2)]** weeks.
 >
 > b.  **Rationale:** This methodology is selected to provide adaptability to evolving requirements, facilitate early and frequent feedback from Client, foster collaboration and transparency, manage risks effectively, and maintain focus on user needs.
 >
-> c.  **Project Management:** Developer shall employ project management practices consistent with the Agile methodology, including but not limited to backlog grooming, sprint planning, daily stand-ups (as appropriate), sprint reviews, and retrospectives. Regular communication and progress reporting shall be provided to Client. *(<!-- PLACEHOLDER: Specify reporting frequency and format -->)*. Project tracking will utilize [<!-- PLACEHOLDER: Specify tool, e.g., Jira, Trello -->].
+> c.  **Project Management:** Developer shall employ project management practices consistent with the Agile methodology. Developer shall provide Client with **[e.g., weekly progress summaries via email and bi-weekly Sprint review meetings]**. Project tracking and backlog management will utilize **[Specify Tool, e.g., Trello, Jira, Asana, GitHub Projects - requires agreement]**, to which Client representatives will be granted appropriate access.
 
 2.3 **Key System Features and Characteristics:** The System developed under this Agreement shall aim to possess the following features and characteristics:
 
 > a.  **Technology Stack:**
 >
-> > i.  Frontend: [Specify frontend tech: e.g., Vite Vanilla, React/Vue, etc.]
+> > i.  Frontend: Vite utilizing Vanilla TypeScript and Bootstrap v5.3.
 > >
 > > ii. Backend: Rust utilizing the Actix framework.
 > >
-> > iii. Database: MariaDB.
+> > iii. Database: MariaDB (version 10 or later compatible version).
 > >
 > > iv. Deployment Environment: Containerized using Docker and orchestrated via Docker Compose.
 >
-> b.  **Performance & Scalability:** The architecture is designed for efficient performance and to accommodate future growth in user base and data volume.
+> b.  **Performance & Scalability:** The architecture is designed for efficient performance under expected load conditions (to be reasonably defined) and to accommodate future growth in user base and data volume anticipated by the Client over the Agreement term.
 >
-> c.  **Security:** Development practices will incorporate security considerations, including secure authentication mechanisms (e.g., PAKE SRP planned for initial implementation), data validation, and adherence to standard secure coding practices. *(<!-- PLACEHOLDER: Detail specific security standards or requirements if applicable -->)*.
+> c.  **Security:** Development practices will incorporate security considerations, including secure authentication mechanisms (specifically, the **OPAQUE** PAKE protocol), secure session management, input validation, protection against common web vulnerabilities (e.g., Cross-Site Scripting, SQL Injection), and adherence to standard secure coding practices. The Parties shall mutually agree upon any specific additional security standards or penetration testing requirements, if necessary.
 >
-> d.  **User Interface (UI) and User Experience (UX):** The System shall feature an intuitive, responsive user interface adaptable to various screen sizes (desktop, tablet, mobile) and designed according to the principles outlined in Section 3.1 and Exhibit A. Adherence to accessibility guidelines (e.g., WCAG) will be pursued where practicable. *(<!-- PLACEHOLDER: Specify required level of WCAG compliance if any -->)*.
+> d.  **User Interface (UI) and User Experience (UX):** The System shall feature an intuitive, responsive user interface adaptable to various screen sizes (desktop, tablet, mobile) and designed according to the principles outlined in Section 3.1 and Exhibit A. Adherence to Web Content Accessibility Guidelines (WCAG) **[Specify required level, e.g., 2.1 Level AA]** will be pursued where reasonably practicable within the scope and budget.
 >
-> e.  **Modularity:** The System architecture promotes modularity to facilitate future enhancements and integrations.
+> e.  **Modularity:** The System architecture, including the frontend widget system and backend service structure, promotes modularity to facilitate future enhancements, maintenance, and potential integrations.
 
-2.4 **Video Demonstration:** As part of the development process or deliverables, Developer shall provide Client with a video demonstration showcasing core System functionalities, user roles (learner, instructor, administrator), and key workflows, substantially covering the items listed below:
+2.4 **Video Demonstration:** As part of the Deliverables, Developer shall provide Client with a video demonstration (e.g., screen recording with narration) showcasing core System functionalities, user roles (learner, instructor, administrator), and key workflows, substantially covering the items listed below:
 
 > a.  Platform Navigation and Layout.
 >
@@ -68,165 +93,189 @@ C.  Client desires to engage Developer to perform such software development and
 >
 > c.  Core Feature Highlights (Dashboard, Profiles, Course Interaction, Admin Interfaces).
 >
->d.  Interface Responsiveness.
+> d.  Interface Responsiveness.
 
-2.5 **Excluded Services:** *(<!-- PLACEHOLDER: Explicitly list any services NOT included, e.g., ongoing hosting beyond initial deployment, content creation, extensive data migration from legacy systems unless specified, hardware procurement, third-party software licenses -->)*.
+2.5 **Excluded Services:** Unless otherwise explicitly agreed upon in a written Change Order (Article 6), the Services under this Agreement **do not** include:
+> a. Ongoing hosting services, server maintenance, or domain name registration/renewal fees beyond the initial deployment and stabilization period defined in Phase 4 of Exhibit C.
+>
+> b. Creation or curation of educational content (course materials, quizzes, etc.) to be loaded into the LMS.
+>
+> c. Extensive data migration services from legacy systems beyond [Define scope, e.g., "basic assistance with data mapping and import validation for user data provided in a pre-agreed format" or "data migration services as detailed in a separate Statement of Work"]. Client is responsible for data extraction and cleansing from source systems unless otherwise agreed.
+>
+> d. Procurement or management of hardware infrastructure required by Client outside the scope of the development and deployment process.
+>
+> e. Licenses for any third-party software required by Client for its own operations that may interact with the LMS, unless such software is directly embedded by Developer as part of the System Deliverable and its licensing terms are passed through.
 
 ## ARTICLE 3: SYSTEM SPECIFICATIONS AND ARCHITECTURE
 
-3.1 **User Interface (UI) Layout and Flow:** The general layout principles and high-level component relationships for the System's user interface are conceptually depicted in **Exhibit A (User Interface Flow Diagram)**, incorporated herein by reference. Key layout components include a persistent Header, a contextual Sidebar (where applicable), a Main Content Area, and a Footer. Specific screen designs and detailed UI specifications will be developed and refined during the Sprints, subject to Client review and feedback.
+3.1 **User Interface (UI) Layout and Flow:** The general layout principles and high-level component relationships for the System's user interface are conceptually depicted in **Exhibit A (User Interface Flow Diagram)**, incorporated herein by reference. Key layout components include a persistent Header, a contextual Sidebar (where applicable), a Main Content Area, and a Footer. Specific screen designs and detailed UI specifications will be developed and refined during the Sprints, subject to Client review and feedback during Sprint Reviews.
 
-3.2 **Backend Architecture:** The high-level backend architecture, illustrating the interaction between the Actix framework, database (MariaDB), and other core components within the planned containerized environment, is conceptually depicted in **Exhibit B (Backend Architecture Diagram)**, incorporated herein by reference. *(<!-- FOR INTERNAL TEAM USE: Exhibit B is based on the Mermaid diagram provided. Ensure final Exhibit accurately reflects implementation. Note Auth Middleware & Production State Management as items needing completion/refinement -->)*.
+3.2 **Backend Architecture:** The high-level backend architecture, illustrating the interaction between the Actix framework, MariaDB database, OPAQUE authentication flow, and other core components within the planned containerized environment, is conceptually depicted in **Exhibit B (Backend Architecture Diagram)**, incorporated herein by reference.
 
-3.3 **Technical Specifications:** *(<!-- PLACEHOLDER: Reference a separate document or Exhibit detailing more granular technical specifications if available/required, e.g., API specifications, detailed data models, specific performance benchmarks -->)*.
+3.3 **Technical Specifications:** Detailed technical specifications, including specific API endpoint definitions, data model schemas, and performance guidelines, may be documented collaboratively by the Parties during the project lifecycle, potentially in a shared repository or document store ([Specify if needed, e.g., "maintained in the project's shared Confluence space"]), and referenced herein upon mutual agreement. Initial database schema is based on requirements outlined during project initiation.
 
 ## ARTICLE 4: PROJECT TIMELINE AND DELIVERABLES
 
-4.1 **Estimated Timeline:** The estimated timeline for the completion of the Services is approximately **[Calculate total weeks from Gantt, e.g., 35 weeks]**, commencing from the Effective Date or an otherwise agreed-upon project start date. A detailed breakdown of phases, estimated task durations, and dependencies is illustrated in the Gantt chart provided as **Exhibit C (Project Timeline Gantt Chart)**, incorporated herein by reference.
+4.1 **Estimated Timeline:** The estimated timeline for the completion of the Services is approximately **Thirty-Five (35) weeks**, commencing from the agreed-upon project start date. A detailed breakdown of phases, estimated task durations, and dependencies is illustrated in the Gantt chart provided as **Exhibit C (Project Timeline Gantt Chart)**, incorporated herein by reference.
 
-4.2 **Acknowledgement of Estimates:** Client acknowledges that the timeline provided in Exhibit C is an estimate based on the initial Scope of Services and the Agile methodology. Timelines may be adjusted based on the evolution of requirements, Client feedback, unforeseen complexities, or mutually agreed-upon changes processed via the Change Management procedure (Article 6).
+4.2 **Acknowledgement of Estimates:** Client acknowledges that the timeline provided in Exhibit C is an estimate based on the initial Scope of Services, assumptions about requirements stability, and the Agile methodology. Timelines may be adjusted based on the outcomes of Sprints, the complexity of features prioritized, Client feedback responsiveness, unforeseen technical challenges, or mutually agreed-upon Change Requests processed via the Change Management procedure (Article 6). Developer shall promptly communicate any anticipated significant deviations from the estimated timeline.
 
 4.3 **Key Deliverables:** Major deliverables under this Agreement include:
 
-  > a.  Access to incremental System builds for review at the end of relevant Sprints.
+  > a.  Access to functional System increments for review and feedback at the conclusion of relevant Sprints (typically via a staging environment).
   >
-  > b.  The final, deployed System software meeting the Acceptance Criteria (Article 5).
+  > b.  The final, deployed System software meeting the Acceptance Criteria (Article 5), delivered to the agreed production environment.
   >
   > c.  The Video Demonstration (as per Section 2.4).
   >
-  > d.  System Documentation, including user guides for administrators, instructors, and learners, and technical documentation sufficient for ongoing maintenance and operation. *(<!-- PLACEHOLDER: Specify level of detail required for documentation -->)*.
+  > d.  System Documentation, comprising:
+  > >   i. User Manuals: Guides for administrators, instructors, and learners covering core functionalities.
+  > >
+  > >   ii. Technical Documentation: Including deployment instructions, system architecture overview, API endpoint documentation (e.g., generated OpenAPI spec), and database schema description, sufficient to enable technically skilled personnel to operate, maintain, and potentially extend the System. The specific level of detail shall be **[e.g., "standard industry practice for systems of similar complexity" or specify further detail if required]**.
   >
-  > e.  Source Code for the developed System. *(<!-- PLACEHOLDER: Confirm source code escrow requirements if any -->)*.
+  > e.  Source Code for the custom-developed portions of the System delivered under this Agreement, provided via **[Specify method, e.g., access to a Git repository, digital media transfer]**. Source code escrow requirements, if any, must be separately agreed upon in writing.
   >
-  > f.  Training materials and sessions as specified in Section 4.4.
+  > f.  Training materials and delivery of training sessions as specified in Section 4.4.
 
-4.4 **Training and Handover:** Upon successful deployment, Developer shall provide:
+4.4 **Training and Handover:** Upon successful deployment (Go-Live milestone in Exhibit C), Developer shall provide:
 
-  > a.  Training for Client's designated administrators and instructors. *(<!-- PLACEHOLDER: Specify format, duration, and number of sessions/attendees -->)*.
+  > a.  Training for Client's designated administrators and instructors, covering system administration, course management, user management, and key instructional features. This training shall consist of **[Specify format, duration, number of sessions, e.g., "up to two (2) remote training sessions, each lasting approximately three (3) hours, for a maximum of ten (10) Client attendees per session"]**.
   >
-  > b.  Onboarding materials (e.g., documentation, potentially videos) for learners.
+  > b.  Onboarding materials suitable for learners, such as a concise user guide document and potentially referencing the Video Demonstration.
   >
-  > c.  A formal handover process concluding the development phase.
+  > c.  A formal handover meeting and documentation transfer concluding the development and deployment phases outlined in Exhibit C.
 
 ## ARTICLE 5: TESTING AND ACCEPTANCE
 
-5.1 **Testing:** Developer shall perform internal testing throughout the development process, including unit, integration, and functional testing, appropriate to the Agile methodology.
+5.1 **Testing:** Developer shall perform internal testing throughout the development process, appropriate to the Agile methodology. This includes developer testing (e.g., unit tests where applicable), integration testing of components, and functional testing against requirements defined for each Sprint.
 
-5.2 **User Acceptance Testing (UAT):** Client shall be responsible for conducting UAT upon notification from Developer that specific features, modules, or the System as a whole are ready for review. Client shall perform UAT in accordance with agreed-upon test plans or criteria. *(<!-- PLACEHOLDER: Define the UAT period duration and process for reporting issues -->)*.
+5.2 **User Acceptance Testing (UAT):** Client shall be responsible for conducting UAT. Developer shall notify Client when specific features, modules, or System increments are ready for UAT (typically at the end of Sprints or designated UAT phases as shown in Exhibit C). Client shall perform UAT in accordance with mutually agreed-upon test plans or use cases based on the Acceptance Criteria. Client shall have **[Specify duration, e.g., ten (10) business days]** from such notification to conduct UAT for the provided increment and report any identified material defects or non-conformities ("**Defects**") to Developer in writing via the agreed project tracking tool ([Tool name from 2.2.c]). Failure to report Defects within the specified period may be deemed acceptance of that increment for the purpose of proceeding with development, without prejudice to addressing Defects identified later within the Warranty Period.
 
-5.3 **Acceptance Criteria:** The System shall be deemed accepted by Client upon the earlier of: (a) Client providing written notice of acceptance; or (b) Client using the System in a live production environment for purposes other than UAT; or (c) the expiration of the final UAT period without Client providing written notice of material non-conformities preventing acceptance. *(<!-- PLACEHOLDER: Define specific, measurable Acceptance Criteria if possible, potentially in an Exhibit -->)*.
+5.3 **Acceptance Criteria:** The System (or relevant increment) shall be deemed formally accepted by Client upon the earliest occurrence of:
+  > (a) Client providing Developer with written notice of acceptance; or
+  >
+  > (b) Client using the delivered System or increment in a live production environment for its intended operational purposes (excluding UAT activities); or
+  >
+  > (c) The expiration of the final UAT period for the complete System (as per the timeline in Exhibit C) without Client providing written notice of material Defects that prevent acceptance according to the agreed Acceptance Criteria.
+  >
+  > Acceptance Criteria shall primarily be based on the functional requirements defined in the project backlog and specifications developed during the Sprints, demonstrating that the System operates substantially as intended.
 
-5.4 **Defect Resolution:** Developer shall use commercially reasonable efforts to correct any material defects or non-conformities to the agreed specifications identified during UAT and reported by Client in accordance with the agreed process.
+5.4 **Defect Resolution:** Developer shall use commercially reasonable efforts to correct any material Defects identified during UAT and properly reported by Client within the agreed timeframe. Defect prioritization and resolution timelines will be managed as part of the Agile backlog grooming and sprint planning process. Resolution of minor defects or cosmetic issues may be deferred to subsequent Sprints or the Warranty Period by mutual agreement.
 
 ## ARTICLE 6: CHANGE MANAGEMENT
 
-6.1 **Change Request Process:** Recognizing the iterative nature of the Agile methodology, changes to the Scope of Services, requirements, or specifications may arise. All requests for changes ("**Change Requests**") must be submitted in writing.
+6.1 **Change Request Process:** Both Parties acknowledge that requirements may evolve. Any proposed change to the agreed-upon Scope of Services, features, specifications, or Deliverables after the initial baseline established during planning ("**Change Request**") must be submitted in writing by either Party to the other Party's designated project contact.
 
-6.2 **Impact Assessment:** Developer shall assess the impact of each Change Request on the project scope, timeline, and cost. Developer will provide Client with a written analysis of the impact and any associated cost adjustments or schedule modifications.
+6.2 **Impact Assessment:** Upon receipt of a Change Request, Developer shall promptly assess its potential impact on the project scope, technical feasibility, estimated timeline, resource allocation, and overall project cost. Developer will provide Client with a written impact analysis, including any proposed adjustments to fees or schedule, within **[e.g., five (5) business days]**, or a longer period if mutually agreed for complex requests.
 
-6.3 **Approval:** No Change Request shall be implemented by Developer unless and until both Parties have mutually agreed upon the change, its impact, and any associated adjustments in writing (e.g., via a formal Change Order document).
+6.3 **Approval:** Developer shall not proceed with implementing any Change Request until both Parties have formally agreed in writing (e.g., through a signed Change Order document referencing this Agreement) to the Change Request itself, its assessed impact, and any associated adjustments to the Agreement's terms, including fees and timeline. Approved Change Orders shall become part of this Agreement.
 
 ## ARTICLE 7: PROJECT CONSIDERATIONS AND RISK MITIGATION
 
-7.1 **Potential Scope Evolution:** Client acknowledges that the flexibility of the Agile process requires diligent scope management by both Parties to control project timelines and costs. The Change Management process (Article 6) is the agreed mechanism for managing scope adjustments.
+7.1 **Potential Scope Evolution:** Client acknowledges that the flexibility inherent in the Agile process necessitates active participation and decisive feedback from Client representatives to manage scope effectively. Both Parties agree to utilize the Change Management process (Article 6) diligently to ensure that scope adjustments are intentional, documented, and their impacts understood and agreed upon, thereby mitigating risks to project timelines and budget.
 
 7.2 **Initial Setup and Data Migration:**
 
-  > a.  Client is responsible for necessary preparations for System implementation, including user account provisioning (unless otherwise agreed) and ensuring readiness of any required infrastructure not provided by Developer.
+  > a.  Client Responsibilities: Client is responsible for providing necessary access to its infrastructure (if applicable), timely feedback, subject matter expertise, and ensuring user readiness for the System implementation. Client shall designate key personnel to participate in project meetings, reviews, and UAT.
   >
-  > b.  If data migration from existing systems is required and included in the Scope of Services *(<!-- PLACEHOLDER: Confirm if data migration is in scope -->)*, Client shall cooperate fully with Developer, providing data in the required format and participating in validation. Developer and Client will collaboratively develop a specific Data Migration Plan. The complexity of data migration may impact the project timeline and effort.
+  > b.  Data Migration: **[Select ONE option based on agreement, requires confirmation]:**
+  >   *   **Option 1 (Migration Not Included/Basic Assistance):** Data migration from Client's existing systems is not included in the scope of Services under the base Fees. Developer may provide reasonable assistance with defining data formats or validating imported data, subject to separate agreement or Change Order if significant effort is required. Client is primarily responsible for extracting, cleansing, formatting, and importing its data.
+  >   *   **Option 2 (Migration Included - Define Scope):** Data migration services for [Specify data types, e.g., user profiles, basic course structures] from [Specify source system(s)] are included in the Scope of Services. A detailed Data Migration Plan outlining responsibilities, formats, timelines, and validation procedures shall be developed collaboratively by the Parties early in the project. Client remains responsible for the accuracy and completeness of source data provided. Complexities discovered during migration may necessitate a Change Request.
   >
-  > c.  Developer shall provide reasonable onboarding support, training (as per Section 4.4), and documentation to facilitate a smooth transition.
+  > c.  Support and Training: Developer commits to providing the onboarding support, training, and documentation outlined in Articles 2, 4, and associated Exhibits to mitigate challenges associated with system transition and user adoption.
 
 ## ARTICLE 8: FEES AND PAYMENT SCHEDULE
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+**8.1 Fees and Payment Terms:** **The total fees, billing rates (if applicable), invoicing procedures, and payment schedule for the Services rendered under this Agreement shall be detailed in a separate Payment Schedule document (designated as Exhibit D), which shall be mutually agreed upon by the Parties in writing and incorporated herein by reference upon execution.** Exhibit D shall specify currency (Philippine Peso - PHP, unless otherwise agreed), payment milestones or frequency, and payment terms (e.g., Net 30 days from invoice date).
 
-8.1 **Fees:** Detail the total project cost or the billing rate (e.g., Time & Materials with a cap, Fixed Fee). Specify currency.
+8.2 **Expenses:** Unless otherwise specified in Exhibit D, Developer shall bear its own general overhead costs. Any direct, out-of-pocket expenses reasonably incurred by Developer specifically for the project (e.g., pre-approved travel, specific third-party software licenses necessary for the deliverable) shall be reimbursable by Client only if pre-approved by Client in writing. Invoices for approved expenses shall include supporting documentation.
 
-8.2 **Payment Schedule:** Outline milestones or dates for invoicing and payment terms (e.g., Net 30 days). Include details for initial deposit, milestone payments, final payment.
+8.3 **Taxes:** Each Party shall be responsible for its own taxes imposed by relevant authorities. Fees specified in Exhibit D are exclusive of any applicable Value Added Tax (VAT) or other sales taxes, which, if applicable, shall be added to Developer's invoices and paid by Client.
-
-8.3 **Expenses:** Specify how expenses (e.g., travel, third-party licenses) will be handled – included in fees or reimbursed separately. Require pre-approval for significant expenses.
-
-8.4 **Taxes:** State which party is responsible for applicable taxes.
 
 ## ARTICLE 9: INTELLECTUAL PROPERTY RIGHTS
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+9.1 **Ownership of Custom Developed System:** Subject to Client's full payment of all fees due under this Agreement and Developer's reservation of rights in Pre-Existing IP (Section 9.2), Developer hereby assigns to Client all right, title, and interest in and to the custom Source Code and associated Deliverables specifically created by Developer for Client under this Agreement (the "**Custom Developed IP**").
 
-9.1 **Ownership of Deliverables:** Typically, upon full payment, ownership of the custom code developed specifically for the Client (the System) transfers to the Client. Clearly define this.
+9.2 **Developer's Pre-Existing Intellectual Property:** Developer shall retain all right, title, and interest in and to any software, code, libraries, tools, methodologies, know-how, or other intellectual property owned or licensed by Developer prior to the Effective Date or developed independently of this Agreement ("**Developer Pre-Existing IP**"), even if incorporated into the System or used in performing the Services.
 
-9.2 **Developer's Pre-Existing IP:** State that Developer retains ownership of its pre-existing tools, libraries, frameworks, know-how, and code used in the project but grants Client a license to use them as integrated into the System. Define the scope of this license (e.g., perpetual, non-exclusive, royalty-free).
+9.3 **License to Developer Pre-Existing IP:** To the extent Developer Pre-Existing IP is incorporated into the System Deliverables, Developer hereby grants Client a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to use, reproduce, modify, and create derivative works of such Developer Pre-Existing IP solely as necessary for Client to use, operate, maintain, and enhance the System for its internal educational and administrative purposes. This license is non-transferable except to a successor of Client's entire business related to the System.
 
-9.3 **Third-Party Materials:** Address ownership and licensing of any third-party components (e.g., open-source libraries) used. Client typically receives these under their respective licenses.
+9.4 **Third-Party Materials:** Any third-party software or materials, including open-source software components, incorporated into the System shall be subject to the terms and conditions of their respective licenses. Developer shall identify any significant third-party components and their licenses to Client upon request or as part of the documentation Deliverable. Client's use of the System is subject to compliance with such third-party licenses.
 
 ## ARTICLE 10: CONFIDENTIALITY
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+10.1 **Definition:** "**Confidential Information**" means any non-public information disclosed by one Party ("**Disclosing Party**") to the other Party ("**Receiving Party**") under this Agreement, whether orally or in writing, that is designated as confidential or that reasonably should be understood to be confidential given the nature of the information and the circumstances of disclosure. This includes, but is not limited to, business plans, financial information, customer lists, personnel information, technical data, trade secrets, know-how, source code (for Developer's pre-existing IP), and the terms of this Agreement.
 
-10.1 **Definition of Confidential Information:** Define what constitutes confidential information for both Parties.
+10.2 **Obligations:** The Receiving Party agrees to: (a) use the Confidential Information solely for the purpose of performing its obligations or exercising its rights under this Agreement; (b) not disclose the Confidential Information to any third party without the prior written consent of the Disclosing Party, except to its employees, contractors, or legal/financial advisors who have a need to know and are bound by confidentiality obligations at least as restrictive as those herein; and (c) protect the Confidential Information from unauthorized use or disclosure using at least the same degree of care that it uses to protect its own confidential information of like importance, but not less than a reasonable degree of care.
 
-10.2 **Obligations:** State the receiving Party's obligation to protect the disclosing Party's confidential information, using a reasonable degree of care.
+10.3 **Exclusions:** The obligations under this Article shall not apply to information that the Receiving Party can demonstrate: (a) was already lawfully known to the Receiving Party at the time of disclosure, free of any obligation of confidentiality; (b) is or becomes publicly known through no wrongful act of the Receiving Party; (c) is rightfully received from a third party without restriction and without breach of this Agreement; or (d) was independently developed by the Receiving Party without reference to or use of the Disclosing Party's Confidential Information.
 
-10.3 **Exclusions:** List standard exclusions (e.g., publicly known information, independently developed, required by law).
+10.4 **Required Disclosure:** If the Receiving Party is compelled by law, regulation, or court order to disclose any Confidential Information, it shall provide the Disclosing Party with prompt prior written notice (to the extent legally permissible) to allow the Disclosing Party an opportunity to seek a protective order or other appropriate remedy.
 
-10.4 **Duration:** Specify the duration of the confidentiality obligations (e.g., a number of years after agreement termination).
+10.5 **Duration:** The confidentiality obligations set forth herein shall survive the termination or expiration of this Agreement for a period of **[e.g., five (5)]** years. Obligations related to trade secrets shall survive indefinitely as long as they remain trade secrets under applicable law.
 
 ## ARTICLE 11: WARRANTIES AND DISCLAIMERS
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+11.1 **Developer Warranties:** Developer warrants to Client that:
-
+  > a.  **Performance Warranty:** For a period of **[Specify duration, e.g., ninety (90) days]** following the date of final Acceptance of the complete System by Client ("**Warranty Period**"), the System will perform substantially in accordance with the material functional specifications agreed upon by the Parties under this Agreement when operated in the intended environment. Client's sole and exclusive remedy, and Developer's entire liability, for breach of this warranty shall be for Developer to use commercially reasonable efforts to correct or provide a workaround for any reproducible, material non-conformity reported by Client in writing during the Warranty Period. This warranty does not cover defects arising from misuse, modification by Client or third parties not authorized by Developer, accidents, or failure to operate the System in accordance with documentation or specified requirements.
-11.1 **Developer Warranties:**
-
-  > a.  **Performance Warranty:** Developer typically warrants that the System will perform substantially in accordance with the agreed specifications for a limited period (e.g., 90 days) after Acceptance ("Warranty Period"). Detail the remedy (e.g., Developer will correct defects).
   >
-  > b.  **Authority:** Warrant that Developer has the right and authority to enter into this Agreement.
+  > b.  **Authority:** Developer has the full right, power, and authority to enter into this Agreement and perform its obligations hereunder.
   >
-  > c.  **Non-Infringement:** Warrant that, to Developer's knowledge, the custom-developed portions of the System do not infringe on third-party IP rights. *(Often subject to limitations)*.
+  > c.  **Service Performance:** The Services will be performed in a professional and workmanlike manner, consistent with generally accepted industry standards.
+  >
+  > d.  **Non-Infringement:** To Developer's knowledge, the Custom Developed IP delivered under this Agreement does not infringe upon any valid patent, copyright, or trade secret of any third party existing under the laws of the Republic of the Philippines as of the Effective Date. Developer makes no warranty regarding infringement related to Developer Pre-Existing IP or any third-party materials.
 
-11.2 **Disclaimers:** **EXCEPT FOR THE EXPRESS WARRANTIES STATED HEREIN, DEVELOPER DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.** State that the System is provided "AS IS" after the Warranty Period.
+11.2 **Disclaimers:** **EXCEPT FOR THE EXPRESS WARRANTIES SET FORTH IN SECTION 11.1, THE SYSTEM, SERVICES, AND DELIVERABLES ARE PROVIDED "AS IS." DEVELOPER HEREBY DISCLAIMS ALL OTHER WARRANTIES, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE, AND NON-INFRINGEMENT WITH RESPECT TO THE SYSTEM AS A WHOLE OR ANY THIRD-PARTY COMPONENTS. DEVELOPER DOES NOT WARRANT THAT THE SYSTEM WILL BE ERROR-FREE, UNINTERRUPTED, OR MEET ALL OF CLIENT'S REQUIREMENTS.**
 
 ## ARTICLE 12: LIMITATION OF LIABILITY
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+12.1 **Exclusion of Indirect Damages:** **IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY OR ANY THIRD PARTY FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, PUNITIVE, OR EXEMPLARY DAMAGES (INCLUDING, BUT NOT LIMITED TO, LOST PROFITS, LOST REVENUE, LOST DATA, LOSS OF GOODWILL, OR BUSINESS INTERRUPTION) ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT OR THE USE OR PERFORMANCE OF THE SYSTEM OR SERVICES, REGARDLESS OF THE THEORY OF LIABILITY (CONTRACT, TORT, OR OTHERWISE), EVEN IF SUCH PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.**
 
-12.1 **Exclusion of Certain Damages:** **NEITHER PARTY SHALL BE LIABLE TO THE OTHER FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES (INCLUDING LOST PROFITS) ARISING OUT OF OR RELATING TO THIS AGREEMENT, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.**
+12.2 **Cap on Direct Damages:** **EXCEPT FOR LIABILITY ARISING FROM A PARTY'S BREACH OF ITS CONFIDENTIALITY OBLIGATIONS (ARTICLE 10), INDEMNIFICATION OBLIGATIONS (IF ANY - NOT CURRENTLY INCLUDED, CONSIDER ADDING), OR INFRINGEMENT OF THE OTHER PARTY'S INTELLECTUAL PROPERTY RIGHTS, EACH PARTY'S TOTAL AGGREGATE LIABILITY TO THE OTHER PARTY FOR ALL CLAIMS FOR DIRECT DAMAGES ARISING OUT OF OR RELATING TO THIS AGREEMENT, WHETHER IN CONTRACT, TORT, OR OTHERWISE, SHALL NOT EXCEED THE TOTAL AMOUNT OF FEES ACTUALLY PAID BY CLIENT TO DEVELOPER UNDER THIS AGREEMENT DURING THE TWELVE (12) MONTH PERIOD PRECEDING THE EVENT GIVING RISE TO THE CLAIM.** *(Note: This cap is often heavily negotiated. Alternatives include a fixed amount or excluding certain types of direct damages).*
 
-12.2 **Cap on Direct Damages:** **EACH PARTY'S TOTAL CUMULATIVE LIABILITY FOR DIRECT DAMAGES ARISING OUT OF OR RELATING TO THIS AGREEMENT SHALL BE LIMITED TO THE TOTAL FEES PAID OR PAYABLE BY CLIENT TO DEVELOPER UNDER THIS AGREEMENT.** *(This amount is often heavily negotiated)*.
+12.3 **Basis of Bargain:** The Parties acknowledge that the limitations of liability and disclaimers of warranties set forth in this Agreement reflect the agreed-upon allocation of risk between the Parties and form an essential basis of the bargain, without which Developer would not have entered into this Agreement on the terms provided.
-
-12.3 **Exceptions:** Specify exceptions to limitations (e.g., breach of confidentiality, indemnification obligations, infringement).
 
 ## ARTICLE 13: TERM AND TERMINATION
 
-*(<!-- PLACEHOLDER: THIS IS A CRITICAL SECTION -->)*
+13.1 **Term:** This Agreement shall commence on the Effective Date and shall continue until all Services are completed, the System is Accepted, final payment has been made, and the Warranty Period has expired, unless terminated earlier pursuant to the terms of this Article 13. The initial intended development and deployment term is estimated in Exhibit C. The overall Agreement duration might extend based on mutually agreed support terms beyond the initial delivery (as suggested by the "3-5 Year Term" note, which requires separate definition, likely in a Support Agreement).
 
-13.1 **Term:** The Agreement commences on the Effective Date and continues until the Services are completed and final payment is made, unless terminated earlier as provided herein.
+13.2 **Termination for Cause:** Either Party may terminate this Agreement upon written notice if the other Party materially breaches any provision of this Agreement and fails to cure such breach within **[Specify cure period, e.g., thirty (30) calendar days]** after receiving written notice specifying the breach in reasonable detail. Material breaches include, but are not limited to, failure to make timely payments (by Client) or failure to meet key milestones or Deliverable requirements after reasonable opportunity to cure (by Developer).
 
-13.2 **Termination for Cause:** Either Party may terminate if the other Party materially breaches the Agreement and fails to cure within a specified period (e.g., 30 days) after written notice.
+13.3 **Termination for Convenience:** **[Choose ONE option or delete if not applicable]:**
+  *   **Option A (Client Only):** Client may terminate this Agreement without cause at any time upon **[Specify notice period, e.g., thirty (30) days']** prior written notice to Developer.
+  *   **Option B (Mutual):** Either Party may terminate this Agreement without cause at any time upon **[Specify notice period, e.g., sixty (60) days']** prior written notice to the other Party.
+  *   **Option C (No Convenience Termination):** (No clause added).
 
-13.3 **Termination for Convenience:** *(Optional)* Allow either Party (or just Client) to terminate without cause upon written notice (e.g., 30 or 60 days). Specify consequences (e.g., payment for work performed).
+13.4 **Effect of Termination:** Upon termination or expiration of this Agreement for any reason:
-
+  > a.  Developer shall cease performing Services and shall promptly deliver to Client all completed Deliverables and work-in-progress, including Source Code for Custom Developed IP up to the date of termination.
-13.4 **Effect of Termination:** Detail obligations upon termination (e.g., return of confidential information, final payments for work done, delivery of work-in-progress).
+  >
+  > b.  Client shall pay Developer for all Services performed and accepted Deliverables provided up to the effective date of termination, plus any pre-approved, non-cancelable expenses incurred. If termination is by Client for convenience (if Option A or B is chosen), Client shall also pay **[Specify additional amount, e.g., "a termination fee equivalent to X% of the remaining estimated project fees" or "for the work completed during the notice period"]**.
+  >
+  > c.  Each Party shall promptly return or, at the Disclosing Party's request, destroy all Confidential Information of the other Party in its possession or control.
+  >
+  > d.  Any provisions of this Agreement that by their nature should survive termination (including, but not limited to, Articles 9, 10, 11.2, 12, 14, and payment obligations accrued prior to termination) shall survive.
 
 ## ARTICLE 14: MISCELLANEOUS
 
-14.1 **Governing Law:** Specify the jurisdiction whose laws will govern the Agreement (e.g., "State of [Your Jurisdiction], without regard to its conflict of laws principles").
+14.1 **Governing Law:** This Agreement and any disputes arising out of or relating to it shall be governed by and construed in accordance with the laws of the **Republic of the Philippines**, without regard to its conflict of laws principles.
 
-14.2 **Dispute Resolution:** Outline the process for resolving disputes (e.g., negotiation, mediation, arbitration, litigation) and specify the venue/location.
+14.2 **Dispute Resolution:** The Parties agree to attempt to resolve any dispute, controversy, or claim arising out of or relating to this Agreement amicably through good faith negotiation between authorized representatives. If negotiation fails within **[e.g., thirty (30) days]**, the Parties agree **[Choose ONE: e.g., "to submit the dispute to mediation under the rules of [Specify Mediation Body in the Philippines] before resorting to litigation" OR "that the exclusive venue for any legal action shall be the competent courts of [Specify City, e.g., Iloilo City], Philippines"]**.
 
-14.3 **Notices:** Define how formal notices must be sent between the Parties (e.g., certified mail, email with confirmation).
+14.3 **Notices:** All notices, requests, demands, and other communications required or permitted under this Agreement shall be in writing and shall be deemed effectively given: (a) upon personal delivery; (b) upon transmission by electronic mail to the addresses specified below (provided confirmation of receipt is obtained); or (c) three (3) business days after deposit with a reputable overnight courier or registered mail, postage prepaid, addressed to the Parties at their respective addresses first set forth above, or to such other address as a Party may designate by notice.
+    > **To Developer:** Attn: [Name/Title], Email: [Email Address]
+    > **To Client:** Attn: [Name/Title], Email: [Email Address]
 
-14.4 **Entire Agreement:** State that this Agreement (including Exhibits) constitutes the entire understanding between the Parties and supersedes all prior discussions or agreements.
+14.4 **Entire Agreement:** This Agreement, including all Exhibits attached hereto (which are incorporated herein by reference), constitutes the entire agreement between the Parties with respect to the subject matter hereof and supersedes all prior or contemporaneous proposals, understandings, representations, warranties, covenants, and agreements, whether written or oral, relating thereto.
 
-14.5 **Amendments:** Specify that any changes must be in writing and signed by both Parties.
+14.5 **Amendments:** No amendment, modification, or waiver of any provision of this Agreement shall be effective unless in writing and signed by duly authorized representatives of both Parties.
 
-14.6 **Assignment:** State whether either Party can assign its rights or obligations under the Agreement (usually requires consent).
+14.6 **Assignment:** Neither Party may assign or transfer this Agreement or any of its rights or obligations hereunder, without the prior written consent of the other Party, which consent shall not be unreasonably withheld or delayed. Notwithstanding the foregoing, either Party may assign this Agreement without consent in connection with a merger, acquisition, or sale of all or substantially all of its assets related to this Agreement, provided the assignee agrees in writing to be bound by the terms hereof.
 
-14.7 **Severability:** If any part of the Agreement is found invalid, the rest remains in effect.
+14.7 **Severability:** If any provision of this Agreement is held by a court of competent jurisdiction to be invalid, illegal, or unenforceable, the validity, legality, and enforceability of the remaining provisions shall not in any way be affected or impaired thereby, and such provision shall be deemed modified to the minimum extent necessary to make it valid, legal, and enforceable.
 
-14.8 **Force Majeure:** Address delays caused by events beyond reasonable control.
+14.8 **Force Majeure:** Neither Party shall be liable for any failure or delay in performing its obligations hereunder (except for payment obligations) if such failure or delay is caused by circumstances beyond its reasonable control, including but not limited to acts of God, war, terrorism, strikes, labor disputes, pandemics, epidemics, government orders, fire, flood, earthquake, or internet service provider failures ("**Force Majeure Event**"). The affected Party shall provide prompt notice to the other Party and shall use reasonable efforts to resume performance as soon as practicable. If a Force Majeure Event continues for more than **[e.g., sixty (60) days]**, the non-affected Party may terminate this Agreement upon written notice.
 
-14.9 **Relationship of Parties:** State that Developer is an independent contractor, not an employee or partner of Client.
+14.9 **Relationship of Parties:** Developer is an independent contractor, and nothing in this Agreement shall be construed as creating an employment, partnership, joint venture, or agency relationship between Developer and Client. Neither Party has the authority to bind the other Party in any respect.
 
 ## ARTICLE 15: EXHIBITS
 
@@ -235,22 +284,28 @@ The following Exhibits are attached hereto and incorporated by reference into th
 *   **Exhibit A:** User Interface Flow Diagram
 *   **Exhibit B:** Backend Architecture Diagram
 *   **Exhibit C:** Project Timeline Gantt Chart
-* *(<!-- PLACEHOLDER: List any other Exhibits, e.g., Detailed Specifications, Payment Schedule, Acceptance Criteria Document -->)*
+*   **Exhibit D:** Payment Schedule *(To be mutually agreed upon and attached)*
 
 **IN WITNESS WHEREOF,** the Parties hereto have caused this Software Development and Implementation Agreement to be executed by their duly authorized representatives as of the Effective Date.
 
-**[CLIENT COMPANY: Western Institute of Technology]**
+**[CLIENT: Western Institute of Technology]**
 
+By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
 Name: Mark Glen C. Guides  
-Date: 08/04/2025
+Title: [Client Representative Title]  
+Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
 
-**[CELL TECH]** (Developer)
+**[DEVELOPER: Cell Tech]**
 
-Name: Jose DanielG. Percy
+By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
+Name: Jose Daniel G. Percy  
+Title: [Partner / Authorized Representative]  
+Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
 
+By: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_  
 Name: Rekcel M. Endencia  
-
+Title: [Partner / Authorized Representative]  
-Date: 08/04/2025
+Date: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
 
 ---
 

index.html

@@ -4,6 +4,9 @@
     <meta charset="UTF-8">
     <meta name="viewport" content="width=device-width, initial-scale=1.0">
     <title>LMS Prototype</title>
+    <link rel="preconnect" href="https://fonts.googleapis.com">
+    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
+    <link href="https://fonts.googleapis.com/css2?family=Roboto:ital,wght@0,100..900;1,100..900&display=swap" rel="stylesheet">
     <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bootstrap@5.3.2/dist/css/bootstrap.min.css">
     <link rel="stylesheet" href="/src/style.css">
 </head>

src/components/CompositeWidget.ts

@@ -1,30 +0,0 @@
-// components/MergedWidget.ts
-import { Widget } from './Widget';
-
-export class MergedWidget extends Widget {
-    private children: Widget[] = [];
-
-    constructor(sizeType: 'default' | 'icon' = 'default') {
-        super(sizeType);
-    }
-
-    addWidget(widget: Widget): void {
-        this.children.push(widget);
-    }
-
-    render(): HTMLElement {
-        // Clear current container contents (in case render is called more than once)
-        this.container.innerHTML = '';
-
-        for (const widget of this.children) {
-            const rendered = widget.render();
-
-            // Move child nodes (not the container itself)
-            while (rendered.firstChild) {
-                this.container.appendChild(rendered.firstChild);
-            }
-        }
-
-        return this.container;
-    }
-}

src/components/TopBar.ts

@@ -4,11 +4,13 @@ import { globalAPI, ApiResponse, ProfileResponseData } from '../api/api'; // Imp
 
 export class TopBar {
     private container: HTMLElement;
+    private menuItems: Array<HTMLElement>;
     private profileDropdownVisible: boolean = false;
     private profileData: ProfileResponseData | null = null;
 
     constructor() {
         this.container = createElement('nav');
+        this.menuItems = [];
         this.container.classList.add('top-bar', 'navbar', 'navbar-expand-lg', 'navbar-light', 'bg-darker', 'mb-3', 'px-4');
         this.fetchProfileData();
     }
@@ -29,6 +31,19 @@ export class TopBar {
         }
     }
 
+    addMenuItem(text: string, href: string) {
+        const menuItem = createElement('li');
+        menuItem.classList.add('nav-item');
+        const itemLink = createElement('a');
+        itemLink.classList.add('nav-link');
+
+        itemLink.href = href;
+        itemLink.textContent = text;
+
+        menuItem.appendChild(itemLink);
+        this.menuItems.push(menuItem)
+    }
+
     render(): HTMLElement {
         this.container.innerHTML = '';
 
@@ -54,33 +69,9 @@ export class TopBar {
         const menuPages = createElement('ul');
         menuPages.classList.add('navbar-nav', 'me-auto', 'mb-2', 'mb-lg-0');
 
-        const dashboardMenuItem = createElement('li');
+        for (const item of this.menuItems) {
-        dashboardMenuItem.classList.add('nav-item');
+            menuPages.appendChild(item);
-        const dashboardLink = createElement('a');
+        }
-        dashboardLink.classList.add('nav-link');
-        dashboardLink.href = '#/dashboard';
-        dashboardLink.textContent = 'Dashboard';
-        dashboardMenuItem.appendChild(dashboardLink);
-        menuPages.appendChild(dashboardMenuItem);
-
-        const classroomsMenuItem = createElement('li');
-        classroomsMenuItem.classList.add('nav-item');
-        const classroomsLink = createElement('a');
-        classroomsLink.classList.add('nav-link');
-        classroomsLink.href = '#/classrooms';
-        classroomsLink.textContent = 'Classrooms';
-        classroomsMenuItem.appendChild(classroomsLink);
-        menuPages.appendChild(classroomsMenuItem);
-
-        const adminMenuItem = createElement('li');
-        adminMenuItem.classList.add('nav-item');
-        const adminLink = createElement('a');
-        adminLink.classList.add('nav-link');
-        adminLink.href = '#/admin';
-        adminLink.textContent = 'Admin';
-        adminMenuItem.appendChild(adminLink);
-        menuPages.appendChild(adminMenuItem);
-
 
         const profileSection = createElement('div');
         profileSection.classList.add('d-flex', 'align-items-center', 'ms-auto');

src/pages/DashboardPage.ts

@@ -7,9 +7,9 @@ import { createElement } from '../utils/utils';
 class WelcomeWidget extends Widget {
     render(): HTMLElement {
         const widgetDiv = createElement('div');
-        widgetDiv.classList.add('widget');
+        widgetDiv.classList.add('widget', 'welcome-widget');
         widgetDiv.innerHTML = `
-            <div class="widget-header">Welcome to the Dashboard</div>
+            <div class="widget-header centered-header">Welcome to the Dashboard</div>
             <div class="widget-body">
                 This is your dashboard. More widgets will be added here.
             </div>
@@ -21,7 +21,7 @@ class WelcomeWidget extends Widget {
 class QuickLinksWidget extends Widget {
     render(): HTMLElement {
         const widgetDiv = createElement('div');
-        widgetDiv.classList.add('widget');
+        widgetDiv.classList.add('widget', 'quick-links-widget');
         widgetDiv.innerHTML = `
             <div class="widget-header">Quick Links</div>
             <div class="widget-body">
@@ -36,21 +36,20 @@ class QuickLinksWidget extends Widget {
     }
 }
 
-class PlaceholderWidget extends Widget { // Corrected placeholder widget definition
+class PlaceholderWidget extends Widget {
     render(): HTMLElement {
         const div = createElement('div');
-        div.classList.add('widget');
+        div.classList.add('widget', 'placeholder-widget');
         div.textContent = 'Placeholder Widget';
         return div;
     }
 }
 
-
 export const renderDashboardPage = () => {
     const layout = new ThreeColumnLayout();
     const welcomeWidget = new WelcomeWidget();
     const quickLinksWidget = new QuickLinksWidget();
-    const placeholderWidget = new PlaceholderWidget(); // Use the corrected PlaceholderWidget class
+    const placeholderWidget = new PlaceholderWidget();
 
     layout.setColumn1Content(welcomeWidget.render());
     layout.setColumn2Content(quickLinksWidget.render());

src/style.css

@@ -1,4 +1,4 @@
-/* Global styles */
+/* --- Global styles --- */
 h1,
 h2,
 h3,
@@ -12,26 +12,14 @@ body {
     margin: 0;
     padding: 0;
     overflow: hidden;
-    font-family: sans-serif;
+    font-family: 'Roboto', sans-serif;
-}
-
-.scrolling-background {
-  position: fixed;
-  top: 0;
-  left: 0;
-  width: 100%;            /* Ensure it covers full width */
-  height: 100vh;          /* Full viewport height */
-  background-image: url('./assets/bg1.jpg');
-  background-repeat: repeat-x;
-  background-size: auto 100%;  /* Maintain width and fill height */
-  animation: scroll-bg 30s linear infinite;
-  z-index: -2;
 }
 
 @keyframes scroll-bg {
     from {
         background-position: 0 0;
     }
+
     to {
         background-position: -100% 0;
     }
@@ -47,6 +35,21 @@ body {
     z-index: -1;
 }
 
+.scrolling-background {
+    position: fixed;
+    top: 0;
+    left: 0;
+    width: 100%;
+    height: 100vh;
+    background-image: url('./assets/after-sunset-minimal-4k-zm-3840x2400.jpg');
+    background-repeat: repeat-x;
+    background-size: auto 100%;
+    animation: scroll-bg 30s linear infinite;
+    z-index: -2;
+}
+
+/* --- Widget Styling --- */
+
 .widget {
     border: 1px solid rgb(0, 0, 0, 0.20);
     background-color: rgb(31, 35, 39, 0.9);
@@ -55,21 +58,23 @@ body {
     border-radius: 5px;
 }
 
+.centered-header {
+    font-size: 24px;
+    text-align: center;
+}
+
 .widget-header {
     margin-bottom: 10px;
     font-weight: bold;
 }
 
-.widget-body {
-    /* Widget body styles */
-}
 
 .icon-widget {
     padding: 10px;
     text-align: center;
 }
 
-/* Layout Specific Styles */
+/* --- Layout Specific Styles --- */
 .centered-layout {
     display: flex;
     justify-content: center;
@@ -98,7 +103,7 @@ body {
 }
 
 
-/* Modal Styles */
+/* --- Modal Styles --- */
 .modal-overlay {
     position: fixed;
     top: 0;
@@ -125,7 +130,7 @@ body {
     /* Maximum width */
 }
 
-/* Responsive adjustments (example) */
+/* --- Responsive adjustments (example) --- */
 @media (max-width: 768px) {
     .three-column-layout {
         grid-template-columns: 1fr;
@@ -142,3 +147,39 @@ body {
         /* Stack even if collapsed */
     }
 }
+
+/* --- Custom styles --- */
+
+.login-container {
+    background-image: url('./assets/images.jpg');
+    /* Replace with your logo path */
+    background-repeat: no-repeat;
+    background-position: center top;
+    /* Center the logo at the top */
+    background-size: 80x 80px;
+    /* Adjust the size of the logo */
+    padding-top: 60px;
+    /* Add padding to create space for the logo */
+    text-align: center;
+    /* Center text and form elements */
+}
+
+.logo {
+    display: block;
+    margin: 0 auto 20px;
+    /* Center the logo and add space below */
+    max-width: 100px;
+    /* Adjust the size as needed */
+    width: 80px;
+    /* Set the width of the logo */
+    height: 80px;
+    /* Set the height of the logo */
+    border-radius: 50%;
+    /* Make the logo circular */
+    background-image: url('./assets/images.jpg');
+    /* Replace with your logo path */
+    background-size: cover;
+    /* Cover the entire area */
+    margin: 0 auto 20px;
+    /* Center the logo and add space below */
+}

src/widgets/LoginWidget.ts

@@ -11,52 +11,40 @@ export class LoginWidget extends Widget {
     render(): HTMLElement {
         this.container.innerHTML = '';
 
+        // Create a logo container
+        const logoContainer = createElement('div') as HTMLElement;
+        logoContainer.classList.add('logo'); // Add class for circular logo
+        this.container.appendChild(logoContainer);
+
+        // Create header
         const header = createElement('h2');
         header.classList.add('widget-header');
         header.textContent = 'Login';
+        this.container.appendChild(header);
 
+        // Create form
         const form = createElement('form');
-        const userIdInputGroup = createElement('div');
-        userIdInputGroup.classList.add('mb-3');
-        const userIdLabel = createElement('label') as HTMLLabelElement; // Cast first
-        userIdLabel.classList.add('form-label');
-        userIdLabel.htmlFor = 'userId'; // Set htmlFor as property
-        userIdLabel.textContent = 'Student ID';
-        const userIdInput = createElement('input') as HTMLInputElement;
-        userIdInput.type = 'text';
-        userIdInput.classList.add('form-control');
-        userIdInput.id = 'userId';
-        userIdInput.placeholder = '123456';
-        userIdInputGroup.appendChild(userIdLabel);
-        userIdInputGroup.appendChild(userIdInput);
 
-        const passwordInputGroup = createElement('div');
+        // User ID input group
-        passwordInputGroup.classList.add('mb-3');
+        const userIdInputGroup = this.createInputGroup('userId', 'Student ID', 'text', 'Student ID');
-        const passwordLabel = createElement('label') as HTMLLabelElement; // Cast first
+        form.appendChild(userIdInputGroup);
-        passwordLabel.classList.add('form-label');
-        passwordLabel.htmlFor = 'password'; // Set htmlFor as property
-        passwordLabel.textContent = 'Password';
-        const passwordInput = createElement('input') as HTMLInputElement;
-        passwordInput.type = 'password';
-        passwordInput.classList.add('form-control');
-        passwordInput.id = 'password';
-        passwordInput.placeholder = 'Password';
-        passwordInputGroup.appendChild(passwordLabel);
-        passwordInputGroup.appendChild(passwordInput);
 
+        // Password input group
+        const passwordInputGroup = this.createInputGroup('password', 'Password', 'password', 'Password');
+        form.appendChild(passwordInputGroup);
+
+        // Login button
         const loginButton = createElement('button');
         loginButton.type = 'submit';
         loginButton.classList.add('btn', 'btn-primary');
         loginButton.textContent = 'Login';
-
-        form.appendChild(userIdInputGroup);
-        form.appendChild(passwordInputGroup);
         form.appendChild(loginButton);
 
+        // Form submission handler
         form.addEventListener('submit', async (event) => {
             event.preventDefault();
-            const userId = userIdInput.value;
+            const userId = (userIdInputGroup.querySelector('input') as HTMLInputElement).value;
-            const password = passwordInput.value;
+            const password = (passwordInputGroup.querySelector('input') as HTMLInputElement).value;
 
             try {
                 const response: ApiResponse<LoginResponseData> = await globalAPI.login({ userId, password });
@@ -71,8 +59,28 @@ export class LoginWidget extends Widget {
             }
         });
 
-        this.container.appendChild(header);
         this.container.appendChild(form);
         return this.container;
     }
+
+    private createInputGroup(id: string, labelText: string, inputType: string, placeholder: string): HTMLElement {
+        const inputGroup = createElement('div');
+        inputGroup.classList.add('mb-3');
+
+        const label = createElement('label') as HTMLLabelElement;
+        label.classList.add('form-label');
+        label.htmlFor = id;
+        label.textContent = labelText;
+
+        const input = createElement('input') as HTMLInputElement;
+        input.type = inputType;
+        input.classList.add('form-control');
+        input.id = id;
+        input.placeholder = placeholder;
+
+        inputGroup.appendChild(label);
+        inputGroup.appendChild(input);
+
+        return inputGroup;
+    }
 }

src/widgets/RegisterWidget.ts

@@ -7,11 +7,11 @@ export class RegisterWidget extends Widget {
 
     constructor(message?: string) {
         super();
-        this.message = message || "For registration, please contact your department head for further instructions.";
+        this.message = message || "";
     }
 
     render(): HTMLElement {
-        this.container.innerHTML = ''; // Clear previous content
+        this.container.innerHTML = ''; 
 
         const header = createElement('h2');
         header.classList.add('widget-header');
@@ -24,7 +24,7 @@ export class RegisterWidget extends Widget {
         const button = createElement('button');
         button.classList.add('btn', 'btn-secondary');
         button.textContent = 'Register';
-        button.disabled = true;
+        
         button.addEventListener('click', () => {
             navigateTo('/register');
         });