System Requirements Document for campusconnect-club

1. Introduction

CampusConnect is a small, student-level full-stack web application for college club and event management, built as an MCA final-semester team project by three students. It gives college students one place to register and log in, browse college clubs, view club details, join clubs, browse upcoming events, register for events, and review the clubs they joined and the events they registered for. It gives one administrator a simple console to log in, see totals for users, clubs, and events, add/edit/delete clubs and events, view users, and view event registrations.

The product intent is deliberately narrow: a working, understandable, complete small system that three beginners can build, explain, and defend in an MCA viva. The guiding priority order is SIMPLE over COMPLEX, WORKING over FANCY, UNDERSTANDABLE over ADVANCED, and COMPLETE over HUGE. No feature outside the requested set is added.

The audience is:

• Students of the college who want to discover and join clubs and register for events.
• Administrators (college staff) who maintain the club and event catalog and need to see who registered.

2. System Overview

CampusConnect is delivered as a browser-based web application with three parts:

• A React.js + Vite frontend written in plain JavaScript/JSX with CSS, using Axios for HTTP calls and React Router for navigation.
• A Node.js + Express.js backend exposing a small set of simple REST endpoints.
• A MySQL database with exactly five tables: users, clubs, events, registrations, club_members.

Authentication uses JWT with bcryptjs password hashing. After login the token is stored appropriately, the logged-in user is identified, student-specific APIs are protected, and admin APIs are protected. Only ADMIN can add/edit/delete clubs, add/edit/delete events, view users, and view registrations; students cannot access admin operations. Normal users must not be able to register as ADMIN — self-service registration always creates the STUDENT role.

2a. Product Interpretation and Delivery Boundary

Delivery ownership. CampusConnect is a first-party application: the React frontend and Express backend are owned and built by the project team, and the MySQL database is a hosted MySQL-compatible database. There is no provider-owned or external product surface in the current scope. Deployment is beginner-friendly: frontend on Vercel or Netlify, backend on Render or another simple equivalent, database on a hosted MySQL-compatible database. Docker, AWS infrastructure, Kubernetes, CI/CD, and complex cloud architecture are explicitly not required.

Identity and access. The application owns its own identity. Students establish identity through self-service registration (name, email, password) and the role is automatically STUDENT. Administrators do not self-register; an ADMIN account exists through the sample data / provisioning outside public student registration. Both roles then use Login for returning verification before protected work. Access is role-based at the API level: student-specific APIs require a valid logged-in user, and admin APIs require the ADMIN role. This is a two-role system only — STUDENT and ADMIN — and no other role exists.

Current vs. future boundary. Current scope is exactly the student and admin features listed in this document. The following are future improvements only and are not implemented: email notifications, club chat, event reminders, QR attendance, mobile application, online certificates, advanced analytics. Also explicitly out of scope for the current build: TypeScript, Next.js, Redux, MongoDB, Firebase, Docker/Kubernetes, microservices, GraphQL, Tailwind (unless absolutely necessary), AI/ML, payment systems, email OTP, Google OAuth, chat, notifications, WebSockets, complicated architecture/design patterns, and unnecessary libraries.

Narrow exclusions. No complicated admin pages beyond what is necessary. No unnecessary database tables beyond the five specified. No advanced abstractions, custom hooks unless genuinely needed, complicated state management, complex architecture, or unnecessary error-handling frameworks.

2c. Page Content and Component Coverage

Home

• Information/state: CampusConnect name/logo, a short introduction, and a simple college-themed design. Public entry surface reachable without login.
• Primary actions: "Explore Clubs" (navigates to Clubs), "View Events" (navigates to Events).
• Supporting actions: "Login / Register" link (navigates to Login and Register).
• Domain entities: none directly; introduces the product.
• Component responsibilities: Navbar.jsx (wordmark + navigation links), hero/intro block, action buttons, footer/quick links.
• States: loading (static content, no data fetch required); empty (not applicable); success (page renders); error (not applicable); recovery (not applicable).

Login

• Information/state: Email field, Password field, Login button. Public access surface.
• Primary actions: Submit credentials to log in.
• Supporting actions: Link to Register for new students.
• Domain entities: users (email, password, role).
• Component responsibilities: Login.jsx form, services/api.js call to POST /api/auth/login, token storage, redirect by role (student → Dashboard, admin → Admin).
• States: loading (submit in progress); empty (blank form); success (token stored, redirected); error (invalid login message); recovery (user corrects fields and resubmits).

Register

• Information/state: Name field, Email field, Password field, Register button. Role is automatically STUDENT and is not user-selectable. Public access surface.
• Primary actions: Submit registration to create a STUDENT account.
• Supporting actions: Link to Login for existing users.
• Domain entities: users (name, email, password, role = STUDENT).
• Component responsibilities: Register.jsx form, services/api.js call to POST /api/auth/register, success message, redirect to Login.
• States: loading (submit in progress); empty (blank form); success (account created, message shown); error (duplicate email, missing fields); recovery (user corrects fields and resubmits).

Dashboard

• Information/state: Welcome message, joined clubs count, registered events count, upcoming events list, quick links. Role-restricted to logged-in students.
• Primary actions: Navigate via quick links to Clubs, Events, My Clubs, My Events.
• Supporting actions: View an upcoming event's details.
• Domain entities: club_members (joined clubs count), registrations (registered events count), events (upcoming events).
• Component responsibilities: Dashboard.jsx, stat cards, upcoming events list, quick links, services/api.js calls to GET /api/my-clubs and GET /api/my-events and GET /api/events.
• States: loading (fetching counts and events); empty (zero joined clubs, zero registered events, no upcoming events — show friendly zero states); success (counts and list render); error (simple message if fetch fails); recovery (retry / navigate away).

Clubs

• Information/state: List of clubs showing club name, category, short description, and a "View Details" action. Role-restricted to logged-in students.
• Primary actions: "View Details" (navigates to Club Details for that club).
• Supporting actions: Browse the list.
• Domain entities: clubs (id, name, description, category).
• Component responsibilities: Clubs.jsx, ClubCard.jsx, services/api.js call to GET /api/clubs.
• States: loading (fetching clubs); empty (no clubs yet — friendly message); success (cards render); error (simple message); recovery (retry).

Club Details

• Information/state: Club name, category, description, and a "Join Club" action. Role-restricted to logged-in students.
• Primary actions: "Join Club" (calls POST /api/clubs/:id/join).
• Supporting actions: Return to Clubs list.
• Domain entities: clubs (id, name, description, category), club_members (user_id, club_id).
• Component responsibilities: ClubDetails.jsx, services/api.js calls to GET /api/clubs/:id and POST /api/clubs/:id/join.
• States: loading (fetching club); empty (not applicable); success (club shown; join succeeds with confirmation); error (club not found, already joined club, unauthorized); recovery (message shown, user can navigate to My Clubs or retry).

My Clubs

• Information/state: List of clubs the logged-in student has joined. Role-restricted to logged-in students.
• Primary actions: View a joined club's details.
• Supporting actions: Navigate to Clubs to join more.
• Domain entities: club_members joined with clubs.
• Component responsibilities: MyClubs.jsx, ClubCard.jsx, services/api.js call to GET /api/my-clubs.
• States: loading (fetching joined clubs); empty (no joined clubs — friendly message with link to Clubs); success (list renders); error (simple message); recovery (retry).

Events

• Information/state: List of events showing event name, club, date, venue, and a "Register" action. Role-restricted to logged-in students.
• Primary actions: "Register" (calls POST /api/events/:id/register).
• Supporting actions: View event details.
• Domain entities: events (id, club_id, name, description, date, venue), clubs (name).
• Component responsibilities: Events.jsx, EventCard.jsx, services/api.js calls to GET /api/events and POST /api/events/:id/register.
• States: loading (fetching events); empty (no events yet — friendly message); success (list renders; registration succeeds with confirmation); error (event not found, already registered for event, unauthorized); recovery (message shown, user can navigate to My Events or retry).

Event Details

• Information/state: Event name, description, date, venue, and a "Register" action. Role-restricted to logged-in students.
• Primary actions: "Register" (calls POST /api/events/:id/register).
• Supporting actions: Return to Events list.
• Domain entities: events (id, club_id, name, description, date, venue), clubs (name).
• Component responsibilities: EventDetails.jsx, services/api.js calls to GET /api/events/:id and POST /api/events/:id/register.
• States: loading (fetching event); empty (not applicable); success (event shown; registration succeeds with confirmation); error (event not found, already registered for event, unauthorized); recovery (message shown, user can navigate to My Events or retry).

My Events

• Information/state: List of events the logged-in student has registered for. Role-restricted to logged-in students.
• Primary actions: View a registered event's details.
• Supporting actions: Navigate to Events to register for more.
• Domain entities: registrations joined with events and clubs.
• Component responsibilities: MyEvents.jsx, EventCard.jsx, services/api.js call to GET /api/my-events.
• States: loading (fetching registered events); empty (no registered events — friendly message with link to Events); success (list renders); error (simple message); recovery (retry).

Admin

• Information/state: Total users, total clubs, total events; add/edit/delete clubs; add/edit/delete events; view registrations. Role-restricted to ADMIN.
• Primary actions: Add club, edit club, delete club; add event, edit event, delete event; view registrations list.
• Supporting actions: View users list.
• Domain entities: users, clubs, events, registrations.
• Component responsibilities: Admin.jsx, admin forms for clubs and events, tables for users and registrations, services/api.js calls to GET /api/users, GET /api/clubs, GET /api/events, POST/PUT/DELETE /api/clubs, POST/PUT/DELETE /api/events.
• States: loading (fetching totals and lists); empty (no users/clubs/events/registrations — friendly messages); success (totals and tables render; add/edit/delete succeed with confirmation); error (missing fields, club not found, event not found, unauthorized admin operation); recovery (message shown, admin corrects input and resubmits).

3. Functional Requirements

Each requirement is a distinct story point with provenance, lifecycle facts, and observable acceptance.

Authentication and Identity

FR-1 — Student self-service registration As a Student, I should register with my name, email, and password so that I get a STUDENT account and can log in.

• Provenance: explicit
• Trigger/input: Name, Email, Password submitted from Register.
• Observable result: A new users row with role STUDENT; success message; redirect to Login.
• Access state: Public (no login required).
• Failure/recovery: Duplicate email → "email already registered" message; missing fields → "please fill all fields" message; user corrects and resubmits.
• Continuation: Log in with the new credentials.
• Acceptance: POST /api/auth/register creates a STUDENT user; role is never ADMIN from this path.

FR-2 — Role is automatically STUDENT on registration As a Student, I should have my role set automatically to STUDENT so that I cannot register as ADMIN.

• Provenance: explicit
• Trigger/input: Any registration submission.
• Observable result: users.role = 'STUDENT' for every self-registered account.
• Access state: Public.
• Failure/recovery: Any attempt to supply an ADMIN role is ignored/rejected; account is created as STUDENT.
• Continuation: Normal student login.
• Acceptance: No public registration path produces an ADMIN user.

FR-3 — Login for students and administrators As a Student or Admin, I should log in with email and password so that I reach my role-appropriate area.

• Provenance: explicit
• Trigger/input: Email and Password submitted from Login.
• Observable result: JWT token returned and stored; logged-in user identified; student redirected to Dashboard, admin redirected to Admin.
• Access state: Public.
• Failure/recovery: Invalid login → "invalid email or password" message; user retries.
• Continuation: Use protected features.
• Acceptance: POST /api/auth/login returns a token for valid credentials; invalid credentials are rejected with a friendly message.

FR-4 — Logout As a Student, I should log out so that my session ends.

• Provenance: explicit
• Trigger/input: Logout action in the navbar.
• Observable result: Stored token cleared; user returned to a public page (Home/Login).
• Access state: Logged-in.
• Failure/recovery: If already logged out, user simply sees public pages.
• Continuation: Log in again.
• Acceptance: After logout, protected pages are no longer accessible without logging in.

FR-5 — Protected student APIs As a Student, I should have my student-specific APIs protected so that only logged-in users can access them.

• Provenance: explicit
• Trigger/input: Any request to student-specific endpoints (/api/my-clubs, /api/my-events, join, register).
• Observable result: Request succeeds only with a valid JWT; otherwise rejected.
• Access state: Logged-in student.
• Failure/recovery: Missing/invalid token → unauthorized message; user logs in.
• Continuation: Retry the action after login.
• Acceptance: Requests without a valid token are rejected.

FR-6 — Protected admin APIs As an Admin, I should have admin APIs protected so that only ADMIN can perform admin operations.

• Provenance: explicit
• Trigger/input: Any request to admin endpoints (create/update/delete clubs and events, GET /api/users, view registrations).
• Observable result: Request succeeds only for a valid JWT with role ADMIN; otherwise rejected.
• Access state: Logged-in ADMIN.
• Failure/recovery: Student or anonymous request → "unauthorized admin operation" message.
• Continuation: Admin retries with valid admin session.
• Acceptance: Students cannot access admin operations.

FR-7 — Administrator access provisioning As an Admin, I should have an existing ADMIN account (from sample data / provisioning outside public registration) so that I can log in and manage the catalog.

• Provenance: required_inference
• Trigger/input: Admin credentials from database/sample.sql (one admin account) or deployment provisioning.
• Observable result: Admin can log in and reach the Admin page.
• Access state: Public login, ADMIN role required for admin pages.
• Failure/recovery: Invalid credentials → invalid login message.
• Continuation: Perform admin operations.
• Acceptance: An ADMIN account exists and is not creatable through public registration.

Student Features

FR-8 — View dashboard As a Student, I should see a dashboard with a welcome message, joined clubs count, registered events count, upcoming events, and quick links so that I get an at-a-glance summary.

• Provenance: explicit
• Trigger/input: Navigate to Dashboard after login.
• Observable result: Welcome message, joined clubs count, registered events count, upcoming events list, and quick links render.
• Access state: Logged-in student.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Use quick links to Clubs, Events, My Clubs, My Events.
• Acceptance: Counts reflect the student's club_members and registrations rows; upcoming events are listed.

FR-9 — View clubs As a Student, I should view the list of college clubs with name, category, and short description so that I can discover clubs.

• Provenance: explicit
• Trigger/input: Navigate to Clubs.
• Observable result: Club list renders with name, category, short description, and a "View Details" action per club.
• Access state: Logged-in student.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Open a club's details.
• Acceptance: GET /api/clubs returns the club list.

FR-10 — View club details As a Student, I should view a club's name, category, and description so that I can decide whether to join.

• Provenance: explicit
• Trigger/input: Select "View Details" on a club.
• Observable result: Club Details page shows name, category, description, and a "Join Club" action.
• Access state: Logged-in student.
• Failure/recovery: Club not found → "club not found" message; return to Clubs.
• Continuation: Join the club or go back.
• Acceptance: GET /api/clubs/:id returns the club.

FR-11 — Join a club As a Student, I should join a club so that it appears in My Clubs and counts on my dashboard.

• Provenance: explicit
• Trigger/input: "Join Club" on Club Details.
• Observable result: A club_members row is created for the logged-in student and the club; confirmation shown; joined clubs count increases.
• Access state: Logged-in student.
• Failure/recovery: Already joined club → "already joined this club" message; club not found → "club not found" message.
• Continuation: View My Clubs.
• Acceptance: POST /api/clubs/:id/join creates the membership; duplicate join is rejected with a friendly message.

FR-12 — View my clubs As a Student, I should view the clubs I have joined so that I can review my memberships.

• Provenance: explicit
• Trigger/input: Navigate to My Clubs.
• Observable result: List of joined clubs renders.
• Access state: Logged-in student.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Open a joined club's details or join more clubs.
• Acceptance: GET /api/my-clubs returns only the logged-in student's joined clubs.

FR-13 — View events As a Student, I should view upcoming events with event name, club, date, and venue so that I can find events to attend.

• Provenance: explicit
• Trigger/input: Navigate to Events.
• Observable result: Event list renders with event name, club, date, venue, and a "Register" action.
• Access state: Logged-in student.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Register for an event or open its details.
• Acceptance: GET /api/events returns the event list.

FR-14 — View event details As a Student, I should view an event's name, description, date, and venue so that I can decide whether to register.

• Provenance: explicit
• Trigger/input: Select an event.
• Observable result: Event Details page shows name, description, date, venue, and a "Register" action.
• Access state: Logged-in student.
• Failure/recovery: Event not found → "event not found" message; return to Events.
• Continuation: Register or go back.
• Acceptance: GET /api/events/:id returns the event.

FR-15 — Register for an event As a Student, I should register for an event so that it appears in My Events and counts on my dashboard.

• Provenance: explicit
• Trigger/input: "Register" on Events or Event Details.
• Observable result: A registrations row is created for the logged-in student and the event; confirmation shown; registered events count increases.
• Access state: Logged-in student.
• Failure/recovery: Already registered for event → "already registered for this event" message; event not found → "event not found" message.
• Continuation: View My Events.
• Acceptance: POST /api/events/:id/register creates the registration; duplicate registration is rejected with a friendly message.

FR-16 — View my events As a Student, I should view the events I have registered for so that I can review my registrations.

• Provenance: explicit
• Trigger/input: Navigate to My Events.
• Observable result: List of registered events renders.
• Access state: Logged-in student.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Open a registered event's details or register for more events.
• Acceptance: GET /api/my-events returns only the logged-in student's registered events.

Admin Features

FR-17 — View admin dashboard As an Admin, I should see total users, total clubs, and total events so that I get an at-a-glance summary of the system.

• Provenance: explicit
• Trigger/input: Navigate to Admin after admin login.
• Observable result: Total users, total clubs, and total events render.
• Access state: Logged-in ADMIN.
• Failure/recovery: Fetch failure → simple error message; retry.
• Continuation: Manage clubs and events, view users, view registrations.
• Acceptance: Totals reflect the users, clubs, and events tables.

FR-18 — Add a club As an Admin, I should add a club with name, description, and category so that students can discover and join it.

• Provenance: explicit
• Trigger/input: Add-club form on Admin.
• Observable result: A new clubs row is created; confirmation shown; club appears in the Clubs list.
• Access state: Logged-in ADMIN.
• Failure/recovery: Missing fields → "please fill all fields" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Edit or delete the club, or add another.
• Acceptance: POST /api/clubs creates the club for ADMIN only.

FR-19 — Edit a club As an Admin, I should edit a club's name, description, and category so that club information stays current.

• Provenance: explicit
• Trigger/input: Edit-club form on Admin.
• Observable result: The clubs row is updated; confirmation shown; updated values appear in the Clubs list and Club Details.
• Access state: Logged-in ADMIN.
• Failure/recovery: Club not found → "club not found" message; missing fields → "please fill all fields" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue managing clubs.
• Acceptance: PUT /api/clubs/:id updates the club for ADMIN only.

FR-20 — Delete a club As an Admin, I should delete a club so that outdated clubs are removed.

• Provenance: explicit
• Trigger/input: Delete action on Admin.
• Observable result: The clubs row is removed; confirmation shown; the club no longer appears in the Clubs list.
• Access state: Logged-in ADMIN.
• Failure/recovery: Club not found → "club not found" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue managing clubs.
• Acceptance: DELETE /api/clubs/:id removes the club for ADMIN only.

FR-21 — Add an event As an Admin, I should add an event with club, name, description, date, and venue so that students can register for it.

• Provenance: explicit
• Trigger/input: Add-event form on Admin.
• Observable result: A new events row is created; confirmation shown; event appears in the Events list.
• Access state: Logged-in ADMIN.
• Failure/recovery: Missing fields → "please fill all fields" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Edit or delete the event, or add another.
• Acceptance: POST /api/events creates the event for ADMIN only.

FR-22 — Edit an event As an Admin, I should edit an event's club, name, description, date, and venue so that event information stays current.

• Provenance: explicit
• Trigger/input: Edit-event form on Admin.
• Observable result: The events row is updated; confirmation shown; updated values appear in the Events list and Event Details.
• Access state: Logged-in ADMIN.
• Failure/recovery: Event not found → "event not found" message; missing fields → "please fill all fields" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue managing events.
• Acceptance: PUT /api/events/:id updates the event for ADMIN only.

FR-23 — Delete an event As an Admin, I should delete an event so that cancelled or outdated events are removed.

• Provenance: explicit
• Trigger/input: Delete action on Admin.
• Observable result: The events row is removed; confirmation shown; the event no longer appears in the Events list.
• Access state: Logged-in ADMIN.
• Failure/recovery: Event not found → "event not found" message; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue managing events.
• Acceptance: DELETE /api/events/:id removes the event for ADMIN only.

FR-24 — View users As an Admin, I should view the list of users so that I can see who is registered on the platform.

• Provenance: explicit
• Trigger/input: Navigate to the users section on Admin.
• Observable result: A list of users renders.
• Access state: Logged-in ADMIN.
• Failure/recovery: Fetch failure → simple error message; retry; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue admin work.
• Acceptance: GET /api/users returns the user list for ADMIN only.

FR-25 — View event registrations As an Admin, I should view event registrations so that I can see who registered for which event.

• Provenance: explicit
• Trigger/input: Navigate to the registrations section on Admin.
• Observable result: A list of registrations renders.
• Access state: Logged-in ADMIN.
• Failure/recovery: Fetch failure → simple error message; retry; unauthorized → "unauthorized admin operation" message.
• Continuation: Continue admin work.
• Acceptance: Registrations are visible to ADMIN only.

Data and Delivery

FR-26 — Database schema and sample data As the project team, we should provide database/schema.sql with CREATE TABLE statements and database/sample.sql with sample users, one admin account, clubs, events, and registrations so that the app can be set up and demoed.

• Provenance: explicit
• Trigger/input: Run schema.sql then sample.sql against MySQL.
• Observable result: The five tables exist and are populated with sample data including one admin account.
• Access state: Not applicable (setup step).
• Failure/recovery: SQL errors are corrected and re-run.
• Continuation: Start the backend and frontend.
• Acceptance: Only the five specified tables are created; sample data includes one admin account.

FR-27 — Environment variables As the project team, we should provide backend/.env.example with PORT=, DB_HOST=, DB_USER=, DB_PASSWORD=, DB_NAME=, JWT_SECRET= so that configuration is clear and secrets stay out of GitHub.

• Provenance: explicit
• Trigger/input: Copy .env.example to .env and fill values.
• Observable result: Backend reads configuration from environment variables.
• Access state: Not applicable (setup step).
• Failure/recovery: Missing values cause clear startup errors; developer fills them in.
• Continuation: Run the backend.
• Acceptance: .env.example contains exactly those keys; no real secrets are committed.

FR-28 — README As the project team, we should provide a README.md containing project description, features, technologies, folder structure, database setup, installation, frontend commands, backend commands, environment variables, API endpoints, team members, screenshots, deployment instructions, demo credentials, and future scope so that the project is easy to set up and explain.

• Provenance: explicit
• Trigger/input: Open README.md.
• Observable result: All listed sections are present.
• Access state: Not applicable (documentation).
• Failure/recovery: Missing sections are added.
• Continuation: Use the README to set up and demo the project.
• Acceptance: All listed sections exist.

FR-29 — MCA-level documentation content As the project team, we should prepare simple MCA-level documentation content for abstract, introduction, problem statement, objectives, scope, functional requirements, non-functional requirements, technology requirements, system architecture, ER diagram, use case diagram, data flow diagram, database design, module description, testing, screenshots, advantages, limitations, future scope, and conclusion so that the project can be submitted and explained in a viva.

• Provenance: explicit
• Trigger/input: Prepare the documentation.
• Observable result: All twenty listed items are covered.
• Access state: Not applicable (documentation).
• Failure/recovery: Missing items are added.
• Continuation: Submit / present.
• Acceptance: All twenty items are present.

FR-30 — Simple test cases As the project team, we should create simple test cases for registration, login, invalid login, view clubs, join club, view my clubs, view events, register for event, duplicate registration, admin add/edit/delete club, admin add/edit/delete event, and unauthorized admin access, using the format Test Case | Input | Expected Result | Actual Result | Status, so that the system can be verified.

• Provenance: explicit
• Trigger/input: Execute the test cases.
• Observable result: A completed test-case table.
• Access state: Not applicable (testing).
• Failure/recovery: Failing cases are fixed and re-tested.
• Continuation: Finalize the project.
• Acceptance: All listed test cases are covered in the specified format.

FR-31 — Step-by-step build process As the project team, we should build the project step-by-step without dumping thousands of lines of code at once, and for every file created later use the FILE: / PURPOSE: / complete code format, always providing the complete updated file when modifying an existing file, so that the final project runs without missing files or mismatched imports.

• Provenance: explicit
• Trigger/input: Follow the development order.
• Observable result: Consistent imports, filenames, routes, API endpoints, database fields, and component names.
• Access state: Not applicable (process).
• Failure/recovery: Inconsistencies are corrected.
• Continuation: Complete the build.
• Acceptance: The final project runs without missing files or mismatched imports.

4. User Personas

Student

Product context. A college student who uses CampusConnect on a phone between lectures or on a laptop in the library. They are not an administrator and have no management responsibilities. They arrive to find clubs and events and to sign up for them.

Primary goal. Become a member of the clubs they care about and a registrant for the events they want to attend, and be able to see both at a glance.

Distinct accepted responsibilities.

• Register with name, email, and password (role automatically STUDENT) and log in.
• Log out.
• View the dashboard with welcome message, joined clubs count, registered events count, upcoming events, and quick links.
• View clubs and club details.
• Join clubs.
• View My Clubs.
• View events and event details.
• Register for events.
• View My Events.

Relevant inputs or decisions. Which club to join; which event to register for; whether to log in or register first.

Interactions with other accepted participants. The Student's actions create durable state that the Admin later sees: joining a club creates a club_members row, and registering for an event creates a registrations row that appears in the Admin's registrations view. The Student does not interact with the Admin directly.

Observable success. My Clubs shows the joined clubs; My Events shows the registered events; the dashboard counts match; duplicate join/registration attempts are rejected with friendly messages.

What makes this role different. The Student is a consumer of the catalog: they browse, join, and register. They cannot create, edit, or delete clubs or events, cannot view users, and cannot view registrations.

Admin

Product context. A college staff member who maintains the club and event catalog and needs to see who registered. They work at a desk, not on a phone between lectures, and they need to read lists and tables without squinting.

Primary goal. Keep club and event data current and see who registered, with admin operations restricted to the ADMIN role.

Distinct accepted responsibilities.

• Log in (admin account exists through sample data / provisioning outside public registration).
• View the admin dashboard with total users, total clubs, and total events.
• Add/edit/delete clubs.
• Add/edit/delete events.
• View users.
• View event registrations.

Relevant inputs or decisions. Club name, description, category; event club, name, description, date, venue; which club or event to edit or delete.

Interactions with other accepted participants. The Admin sees the results of Student actions: the users list shows registered students, and the registrations view shows which students registered for which events. The Admin does not interact with students directly.

Observable success. Totals reflect the tables; added/edited clubs and events appear correctly in the student-facing lists; deleted items disappear; the registrations view shows student registrations.

What makes this role different. The Admin is a publisher and maintainer of the catalog with full create/update/delete authority and visibility into users and registrations. They do not join clubs or register for events.

5. Core User Flows

Flow 1 — Student registers and logs in

1. Student opens CampusConnect and lands on Home.
2. Student selects Login / Register and goes to Register.
3. Student enters Name, Email, and Password and submits.
4. System creates a users row with role STUDENT (role is not selectable) and shows a success message.
5. Student goes to Login, enters Email and Password, and submits.
6. System returns a JWT, stores it, identifies the student, and redirects to Dashboard.
7. Failure/recovery: Duplicate email or missing fields show a friendly message on Register; the student corrects the fields and resubmits. Invalid login shows a friendly message on Login; the student retries.
8. Continuation: Student uses the dashboard quick links.

Flow 2 — Student views dashboard

1. Student is logged in and on Dashboard.
2. System shows the welcome message, joined clubs count, registered events count, upcoming events, and quick links.
3. Student reads the summary and selects a quick link.
4. Failure/recovery: If counts or events fail to load, a simple error message is shown and the student can retry.
5. Continuation: Student navigates to Clubs, Events, My Clubs, or My Events.

Flow 3 — Student views clubs and club details

1. Student is logged in and navigates to Clubs.
2. System lists clubs with name, category, short description, and a "View Details" action.
3. Student selects View Details on a club.
4. System opens Club Details showing name, category, description, and a "Join Club" action.
5. Failure/recovery: If the club is not found, a "club not found" message is shown and the student returns to Clubs.
6. Continuation: Student joins the club or goes back to Clubs.

Flow 4 — Student joins a club

1. Student is on Club Details for a club they want to join.
2. Student selects Join Club.
3. System creates a club_members row for the logged-in student and the club and shows a confirmation.
4. Student's joined clubs count on Dashboard increases, and the club appears in My Clubs.
5. Failure/recovery: If the student already joined the club, an "already joined this club" message is shown. If the club is not found, a "club not found" message is shown.
6. Continuation: Student opens My Clubs to review memberships.

Flow 5 — Student views my clubs

1. Student is logged in and navigates to My Clubs.
2. System lists the clubs the student has joined.
3. Failure/recovery: If the student has joined no clubs, a friendly empty message with a link to Clubs is shown. If the fetch fails, a simple error message is shown and the student can retry.
4. Continuation: Student opens a joined club's details or goes to Clubs to join more.

Flow 6 — Student views events and event details

1. Student is logged in and navigates to Events.
2. System lists events with event name, club, date, venue, and a "Register" action.
3. Student selects an event to open Event Details, which shows name, description, date, venue, and a "Register" action.
4. Failure/recovery: If the event is not found, an "event not found" message is shown and the student returns to Events.
5. Continuation: Student registers for the event or goes back to Events.

Flow 7 — Student registers for an event

1. Student is on Events or Event Details for an event they want to attend.
2. Student selects Register.
3. System creates a registrations row for the logged-in student and the event and shows a confirmation.
4. Student's registered events count on Dashboard increases, and the event appears in My Events.
5. Failure/recovery: If the student already registered for the event, an "already registered for this event" message is shown. If the event is not found, an "event not found" message is shown.
6. Continuation: Student opens My Events to review registrations.

Flow 8 — Student views my events

1. Student is logged in and navigates to My Events.
2. System lists the events the student has registered for.
3. Failure/recovery: If the student has registered for no events, a friendly empty message with a link to Events is shown. If the fetch fails, a simple error message is shown and the student can retry.
4. Continuation: Student opens a registered event's details or goes to Events to register for more.

Flow 9 — Student logs out

1. Student is logged in and selects Logout in the navbar.
2. System clears the stored token and returns the student to a public page.
3. Failure/recovery: If the student is already logged out, public pages are shown normally.
4. Continuation: Student can log in again.

Flow 10 — Admin logs in and views the admin dashboard

1. Admin opens CampusConnect and goes to Login.
2. Admin enters the admin Email and Password and submits.
3. System returns a JWT, stores it, identifies the admin, and redirects to Admin.
4. System shows total users, total clubs, and total events.
5. Failure/recovery: Invalid login shows a friendly message; the admin retries.
6. Continuation: Admin manages clubs and events, views users, and views registrations.

Flow 11 — Admin adds, edits, and deletes a club

1. Admin is on Admin.
2. Admin opens the add-club form, enters name, description, and category, and submits.
3. System creates a clubs row and shows a confirmation; the club appears in the student-facing Clubs list.
4. Admin selects a club to edit, changes name, description, or category, and submits; the clubs row is updated and the updated values appear in Clubs and Club Details.
5. Admin selects a club to delete; the clubs row is removed and the club no longer appears in the Clubs list.
6. Failure/recovery: Missing fields show a "please fill all fields" message; a missing club shows a "club not found" message; a non-admin request shows an "unauthorized admin operation" message.
7. Continuation: Admin continues managing clubs.

Flow 12 — Admin adds, edits, and deletes an event

1. Admin is on Admin.
2. Admin opens the add-event form, enters club, name, description, date, and venue, and submits.
3. System creates an events row and shows a confirmation; the event appears in the student-facing Events list.
4. Admin selects an event to edit, changes club, name, description, date, or venue, and submits; the events row is updated and the updated values appear in Events and Event Details.
5. Admin selects an event to delete; the events row is removed and the event no longer appears in the Events list.
6. Failure/recovery: Missing fields show a "please fill all fields" message; a missing event shows an "event not found" message; a non-admin request shows an "unauthorized admin operation" message.
7. Continuation: Admin continues managing events.

Flow 13 — Admin views users and event registrations

1. Admin is on Admin.
2. Admin opens the users section; the list of users renders.
3. Admin opens the registrations section; the list of event registrations renders, showing which students registered for which events.
4. Failure/recovery: If a fetch fails, a simple error message is shown and the admin can retry. A non-admin request shows an "unauthorized admin operation" message.
5. Continuation: Admin continues admin work.

Flow 14 — Team sets up and runs the project

1. Team runs database/schema.sql to create the five tables, then database/sample.sql to load sample users, one admin account, clubs, events, and registrations.
2. Team copies backend/.env.example to .env and fills PORT, DB_HOST, DB_USER, DB_PASSWORD, DB_NAME, JWT_SECRET.
3. Team starts the backend (Node/Express) and the frontend (React/Vite).
4. Team follows the development order: frontend, backend, MySQL connection, tables, register/login, student dashboard, clubs, club joining, events, event registration, admin operations, connect everything, test everything, deployment.
5. Failure/recovery: SQL or configuration errors are corrected and the steps are re-run.
6. Continuation: Team runs the test cases and deploys (frontend on Vercel or Netlify, backend on Render or another simple equivalent, database on a hosted MySQL-compatible database).

6. Visuals Colors and Theme

The creative direction is authoritative for this section: typographic infrastructure after Erik Spiekermann — a campus wayfinding system, not a SaaS dashboard. The muse is Erik Spiekermann; the headline idea is clear signage on a campus you already know — a campus noticeboard and a transit map at once, where a student finds "Robotics Club" or "Hackathon, Fri 4pm, Seminar Hall 2" instantly and the admin reads a table of registrations without squinting.

Colour tokens (light mode).

Category coding (four flat line colours, used only as 4px top rules and small pill fills on club cards).

No blue-on-white SaaS gradient anywhere; colour is flat, printed, and coded. No extra accent hues are invented ad hoc.

Typography. Headings Fira Sans Bold (700) at tight -0.02em tracking, sentence case, never all-caps for headlines; all-caps only for 11–12px micro-labels with 0.14em letterspacing (section eyebrows, table headers, category pills). Body Fira Sans. Weight contrast does the hierarchy work — 700 headings against 400 body against 600 for buttons and data values — rather than size alone. Numerals set tabular in the dashboard stat cards and admin tables so counts align in a column.

Type scale. 1.25 modular on a 16px base — 48px display (mobile 30px) for the home hero, 32px page titles (mobile 24px), 22px section headings, 18px card titles, 16px body, 14px metadata, 12px all-caps labels. Line-height 1.15 for display, 1.25 for headings, 1.6 for body copy. Everything via clamp() so 375px never overflows.

Shape language. Orderly and printed, not soft. 4px radii on buttons and inputs, 6px on cards. 1px #DDD8CF hairlines everywhere instead of shadows: card outlines, table row rules, the divider under the navbar, the rule above every section eyebrow. Category is always expressed as a 4px flat colour rule across the top edge of a club card or as a small all-caps pill. Buttons are solid rectangles with a 2px bottom edge in a darker shade of their own colour, so they read as physical keys. No blobs, no glass, no 24px pill buttons, no hover-lift.

Spacing rhythm. A visible 12-column grid with a 1100px max content width and 24px gutters (16px at mobile) — columns and alignment are the decoration. Clubs and Events are dense 3-up grids at 1280px, 2-up at 768px, 1-up at 375px.

Imagery style. Almost no photography — this is a signage system. The visual vocabulary is pictograms and diagrams: a small set of 24px stroke icons drawn on a 2px grid (a club flag, a calendar block, a venue pin, a person, a checklist), used identically in nav, cards, and tables. Category is carried by the flat line colours plus a simple geometric mark per category (a circuit square for Technology, a stage curve for Cultural, a pitch circle for Sports, a brush diagonal for Arts) — all buildable as inline SVG. The only photographic element permitted is a single wide, slightly desaturated campus photograph on the Home hero's right column, cropped to the grid and overlaid with the three coded line strips; if no photo is available, that column is pure flat colour blocks. No stock people, no illustrations of characters, no 3D.

7. Signature Design Concept

The Home first screen is a station board, not a SaaS hero.

Full-bleed warm paper #F4F1EC ground, no gradient, no blob. Left two-thirds, flush-left:

• A 12px all-caps eyebrow COLLEGE CLUB & EVENT MANAGEMENT with a 3px #E8442A rule above it.
• Beneath it the wordmark-scale headline CampusConnect set in Fira Sans Bold at 48px mobile / 96px desktop with -0.02em tracking, allowed to run to the viewport edge.
• Then a single 18px ink line of plain introduction: "Find your club. Register for the event. Show up."
• Then two solid buttons side by side — Explore Clubs in #0B3C8C with a 2px darker bottom edge, View Events as a white button with a 1px #1A1A1A border — and a plain text link Login / Register beneath them.

Right one-third: three stacked full-width colour strips, each 56px tall and edge-to-edge inside its column — #0B3C8C, #E8442A, #1F7A4D — each carrying a white all-caps label and a right-aligned count (24 CLUBS, 11 EVENTS, JOINED: 3), reading like a departures board.

A hairline rule runs the full container width under the whole hero, and the first ruled list of upcoming events begins immediately below it, so the fold ends on data rather than on decoration.

At 375px the strips stack beneath the headline as a full-width three-row board and the headline clamps to 48px, staying entirely inside the viewport.

Signature moves carried across the app.

• Category as transit line: every club card and event row carries a 4px flat colour rule across its top edge drawn from the fixed four-colour code, with the category name repeated as a 12px all-caps pill — so the Clubs grid reads as a map legend, not a card wall.
• The nav is wayfinding: a solid #0B3C8C bar where each link sits on a 3px bottom rule that switches to #E8442A for the current route, and the wordmark is set in Fira Sans Bold with a small square "station" mark to its left — no hamburger drawer on desktop, a single wrapping link row at 375px.
• Numbered stat cards on Dashboard and Admin: three cards with a 12px all-caps label above a 56px tabular-numeral figure in Fira Sans Bold, separated by vertical hairlines rather than shadows, so "Joined clubs 3 / Registered events 5 / Upcoming 4" scans in one glance.
• Ruled data rows instead of cards for lists: My Clubs, My Events, Upcoming Events, and the admin registration table are hairline-separated rows with aligned label/value columns (name left, category or date centre, action right), the whole row tinting to #F4F1EC on hover — the same row component reused everywhere, which is also the cheapest thing for three students to build.
• The all-caps eyebrow + hairline rule page header, repeated identically on Clubs, Events, My Clubs, My Events, and Admin: a 12px letterspaced label, a 32px title, then a full-width 1px #DDD8CF rule that the section content hangs from — the app's one typographic gesture, and it makes every page feel like the same institution.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the Home station board — the wordmark-scale "CampusConnect" headline on the left two-thirds and the three stacked coded line strips (Clubs / Events / My Campus) on the right one-third, over the warm paper ground.
• Input → transformation → outcome thesis: on first paint, the ruled list rows below the hero fade up in a 40ms stagger, so the page resolves from headline to data — the visitor's eye travels from the wordmark to the first upcoming event without any scroll-linked effect. The three line strips are static flat colour blocks; their labels and counts are always readable.
• Motion vocabulary: functional and short — 120–180ms ease-out on state changes only: button colour and 2px bottom-edge shift on press, the active-nav bottom rule sliding in, a card's hairline darkening to its category colour on hover, form error text appearing with a 120ms fade. One purposeful entrance per page: the ruled list rows fade up in 40ms stagger on first paint. No parallax, no scroll-linked effects, no bouncy easing, no animated blobs.
• Composed first frame: full-bleed #F4F1EC ground; 12px all-caps eyebrow with a 3px #E8442A rule above it; "CampusConnect" in Fira Sans Bold at 96px desktop / 48px mobile; the single 18px ink introduction line; the two solid buttons and the plain text link; the three stacked 56px colour strips on the right; a full-width hairline rule under the hero; the first ruled list of upcoming events beginning immediately below it.
• Reduced-motion state: under prefers-reduced-motion all transitions collapse to instant state changes and the staggered row reveal is disabled; the hero renders as a fully static station board with every label, count, and control readable and in place.

9. Non-Functional Requirements

NFR-1 — Simplicity and student-level scope The project must stay EASY, SMALL, CLEAN, QUICK, and understandable for MCA students; it must not be over-engineered. Priority order: SIMPLE over COMPLEX, WORKING over FANCY, UNDERSTANDABLE over ADVANCED, COMPLETE over HUGE.

• Provenance: explicit. Rationale: explicit hard constraint in the authoritative user evidence.

NFR-2 — No unrequested features No features beyond the requested set may be added.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-3 — Technology restrictions Do not use TypeScript, Next.js, Redux, MongoDB, Firebase, Docker/Kubernetes, microservices, GraphQL, Tailwind unless absolutely necessary, AI/ML, payment systems, email OTP, Google OAuth, chat, notifications, WebSockets, complicated architecture/design patterns, or unnecessary libraries.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-4 — Role restriction Only two roles exist: STUDENT and ADMIN. Normal users MUST NOT be able to register as ADMIN.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-5 — Admin-only operations Only ADMIN can add/edit/delete clubs, add/edit/delete events, view users, and view registrations; students cannot access admin operations.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-6 — Database table restriction Use only the five specified tables (users, clubs, events, registrations, club_members); do not create unnecessary tables.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-7 — Simple admin pages Do not create complicated admin pages unless necessary.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-8 — Beginner-friendly deployment Deployment must not require Docker, AWS infrastructure, Kubernetes, CI/CD, or complex cloud architecture.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-9 — Secret hygiene Never put real secrets in GitHub.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-10 — Future scope not implemented Do not implement email notifications, club chat, event reminders, QR attendance, mobile application, online certificates, or advanced analytics.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-11 — Step-by-step output discipline Do not dump thousands of lines of code at once; build step-by-step, and for the first response provide only the folder structure, database schema, API list, 3-member task division, and development plan.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-12 — Beginner-friendly code style Use simple functions, simple React components, straightforward Express routes, simple SQL queries, clear variable names, and comments where useful. Avoid advanced abstractions, custom hooks unless genuinely needed, complicated state management, complex architecture, and unnecessary error-handling frameworks. Every file/function/API/component must have a clear purpose.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-13 — Basic error handling only Only basic error handling is needed: invalid login, duplicate email, missing fields, club not found, event not found, already joined club, already registered for event, unauthorized admin operation. Return simple, user-friendly messages.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-14 — Responsive UI The UI must work reasonably on desktop, laptop, tablet, and mobile, and must not look like a huge enterprise application.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-15 — Readable text and controls at every viewport Headlines, wordmarks, labels, numbers, cards' text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the creative direction asks, as long as they cover no readable text or control. Under prefers-reduced-motion, provide a usable static arrangement.

• Provenance: explicit (creative direction). Rationale: accessibility and legibility constraint.

NFR-16 — Consistent naming and imports All imports, filenames, routes, API endpoints, database fields, and component names must stay consistent; the final project must run without missing files or mismatched imports.

• Provenance: explicit. Rationale: explicit hard constraint.

NFR-17 — Password hashing Passwords must be hashed with bcryptjs.

• Provenance: explicit. Rationale: explicit technology and security constraint.

NFR-18 — JWT authentication Authentication must use JWT; after login the token is stored appropriately, the logged-in user is identified, student-specific APIs are protected, and admin APIs are protected.

• Provenance: explicit. Rationale: explicit technology and security constraint.

10. Tech Stack

Frontend (source-specified).

• React.js
• Vite
• JavaScript
• JSX/HTML
• CSS
• Axios
• React Router

Backend (source-specified).

• Node.js
• Express.js

Database (source-specified).

• MySQL

Other (source-specified).

• JWT authentication
• bcryptjs for password hashing
• Git/GitHub

Project structure (source-specified).

CampusConnect/
  frontend/
    public/
    src/
      components/
        Navbar.jsx
        ClubCard.jsx
        EventCard.jsx
      pages/
        Home.jsx
        Login.jsx
        Register.jsx
        Dashboard.jsx
        Clubs.jsx
        ClubDetails.jsx
        MyClubs.jsx
        Events.jsx
        EventDetails.jsx
        MyEvents.jsx
        Admin.jsx
      services/
        api.js
      App.jsx
      main.jsx
      index.css
    package.json
    vite.config.js

  backend/
    routes/
      auth.js
      clubs.js
      events.js
    controllers/
      auth.js
      clubs.js
      events.js
    middleware/
      auth.js
    config/
      db.js
    server.js
    package.json
    .env.example

  database/
    schema.sql
    sample.sql

  README.md
  .gitignore

Filenames are kept short and student-friendly.

Deployment (source-specified).

• Frontend: Vercel or Netlify
• Backend: Render or another simple equivalent
• Database: Hosted MySQL-compatible database

Explicitly not used: TypeScript, Next.js, Redux, MongoDB, Firebase, Docker/Kubernetes, microservices, GraphQL, Tailwind unless absolutely necessary, AI/ML, payment systems, email OTP, Google OAuth, chat, notifications, WebSockets, complicated architecture/design patterns, unnecessary libraries.

11. Assumptions and Constraints

Assumptions.

• A1 — The team has access to a MySQL-compatible database (local for development, hosted for deployment) and can run database/schema.sql and database/sample.sql. (Assumption — narrow, consistent with the source deployment requirement.)
• A2 — An ADMIN account exists through database/sample.sql (one admin account) or deployment provisioning; it is not created through public registration. (required_inference — required to make the accepted admin journey executable.)
• A3 — The frontend and backend are deployed separately and the frontend is configured to call the backend's base URL. (Assumption — narrow, consistent with the source deployment requirement.)
• A4 — The app is used by a small college population; no scaling, caching, or performance-tuning work is required. (Assumption — narrow, consistent with the "small, simple" constraint.)

Constraints.

• C1 — Keep the project EASY, SMALL, CLEAN, QUICK, and understandable for MCA students; do not over-engineer it. SIMPLE > COMPLEX, WORKING > FANCY, UNDERSTANDABLE > ADVANCED, COMPLETE > HUGE.
• C2 — Do not add features that are not requested.
• C3 — Do not use TypeScript, Next.js, Redux, MongoDB, Firebase, Docker/Kubernetes, microservices, GraphQL, Tailwind unless absolutely necessary, AI/ML, payment systems, email OTP, Google OAuth, chat, notifications, WebSockets, complicated architecture/design patterns, or unnecessary libraries.
• C4 — Only two roles: STUDENT and ADMIN. Normal users MUST NOT be able to register as ADMIN.
• C5 — Only ADMIN can add/edit/delete clubs, add/edit/delete events, view users, and view registrations; students cannot access admin operations.
• C6 — Use only the five specified tables; do not create unnecessary tables.
• C7 — Do not create complicated admin pages unless necessary.
• C8 — Do not require Docker, AWS infrastructure, Kubernetes, CI/CD, or complex cloud architecture for deployment.
• C9 — Never put real secrets in GitHub.
• C10 — Do not implement future-scope items: email notifications, club chat, event reminders, QR attendance, mobile application, online certificates, advanced analytics.
• C11 — Do not dump thousands of lines of code at once; build step-by-step, and for the first response provide only the folder structure, database schema, API list, 3-member task division, and development plan.
• C12 — Avoid advanced abstractions, custom hooks unless genuinely needed, complicated state management, complex architecture, and unnecessary error-handling frameworks.
• C13 — The generic indigo/blue-on-white SaaS template is forbidden for this project; the creative direction's palette, fonts, surfaces, tone, and layout are authoritative for the visual layer.

Team division (source-specified).

• Member 1 / Leader: Authentication, Dashboard, Admin, Database, Integration, GitHub management.
• Member 2: Clubs, Club details, Join club, My clubs.
• Member 3: Events, Event details, Event registration, My events.
• Suggested branches: main, leader-auth, member2-clubs, member3-events.
• Meaningful commits such as: "Added login page", "Added club API", "Added event registration", "Fixed dashboard".

Development order (source-specified).

1. Create React/Vite frontend
2. Create Node/Express backend
3. Connect backend to MySQL
4. Create database tables
5. Register/login
6. Student dashboard
7. Clubs
8. Club joining
9. Events
10. Event registration
11. Admin operations
12. Connect everything
13. Test everything
14. Deployment

Do not jump into advanced features.

Future scope (mention only; do not implement).

• Email notifications
• Club chat
• Event reminders
• QR attendance
• Mobile application
• Online certificates
• Advanced analytics

12. Glossary

• CampusConnect — The college club and event management web application described in this document.
• Student — The accepted persona who registers, logs in, browses clubs and events, joins clubs, registers for events, and reviews My Clubs and My Events.
• Admin — The accepted persona who logs in, views the admin dashboard, manages clubs and events, views users, and views event registrations.
• STUDENT / ADMIN — The only two roles in the system. Self-service registration always creates STUDENT.
• JWT — JSON Web Token used to authenticate requests after login.
• bcryptjs — The library used to hash passwords.
• Club — A college club with id, name, description, and category.
• Event — A college event with id, club_id, name, description, date, and venue.
• Membership — A row in club_members linking a user to a club they joined.
• Registration — A row in registrations linking a user to an event they registered for.
• My Clubs — The page listing the logged-in student's joined clubs.
• My Events — The page listing the logged-in student's registered events.
• Dashboard — The student page showing welcome message, joined clubs count, registered events count, upcoming events, and quick links.
• Admin page — The administrator page showing total users, total clubs, total events, club and event management, users, and registrations.
• schema.sql — The SQL file containing CREATE TABLE statements for the five tables.
• sample.sql — The SQL file containing sample users, one admin account, clubs, events, and registrations.
• API endpoint — A simple, understandable REST path exposed by the Express backend (for example POST /api/auth/login).
• Hairline — A 1px #DDD8CF rule used instead of shadows for card outlines, table row rules, and section dividers.
• Category line — The 4px flat colour rule across the top edge of a club card or event row, drawn from the fixed four-colour category code (Technology #0B3C8C, Cultural #E8442A, Sports #1F7A4D, Arts #C9860B).
• Eyebrow — The 12px all-caps letterspaced label that sits above a page title, followed by a full-width hairline rule.