🎓 ConcordiaTracker

One calm home for everything a Concordia student has due — pulled out of the five different sites it's scattered across.

The problem · The solution · Highlights · Tech stack · Getting started · Architecture · Roadmap

Not affiliated with Concordia University.

---

ConcordiaTracker is a school-specific academic hub: a single, fast, keyboard-driven app that lifts every deadline, grade, and course detail out of the half-dozen disconnected systems a student logs into — so the answer to "what's actually due?" is one glance, not five tabs.

Project status. This is a production-quality front-end foundation: every screen, interaction, and animation is real and runs on a single in-memory mock-data module. The architecture is deliberately built so the planned Supabase backend (auth, Postgres, Realtime) slots in behind one swappable provider per feature — no UI rewrites required. See Architecture.

🎯 The problem: five different sites

A Concordia student's semester doesn't live in one place. The real information for a single term is fragmented across — at minimum — five different sites, each with its own login:

1. Moodle — assignments, some grades, course pages
2. eConcordia — other courses that live entirely outside Moodle
3. The Student Hub — registration, add/drop, official university dates
4. Publisher platforms — MyLab, Connect, WileyPLUS, and friends, where the weekly quizzes hide
5. PDF syllabi + professor emails — where the deadlines that actually matter are buried

There is no single, trustworthy view of what's due this week. Dates get missed not because students don't care, but because "the schedule" is smeared across five systems that don't talk to each other — and the most important dates are stuck inside a PDF or a one-line email.

💡 The solution

ConcordiaTracker collapses those five sites into one Concordia-specific home:

• Drop a syllabus, get a semester. A scripted parse extracts every assessment, weight, and deadline from a course outline and cascades it into the app — the product's hero moment.
• Every date carries its origin. A first-class provenance system badges each deadline as official, confirmed by N classmates, or unverified, so you know what to trust.
• One place for "what's due." A calm Today view, a month/week/agenda Calendar with toggleable personal + university layers, and editable Courses with real grade math.
• Calculators that actually compute. A free "what grade do I need to pass?" solver and a Pro GPA what-if slider — real arithmetic on the Concordia 4.30 scale, not vibes.
• Crowd-sourced syllabi. A blueprint marketplace lets you import a classmate's or professor's outline, with a "Waze for academics" peer date-correction layer when a deadline moves.
• A teacher portal. An invite-based, publish-only context where professors confirm the authoritative outline — which becomes the verified blueprint students import.

The front end is built in React + TypeScript; the backend is Supabase (Postgres, Auth, Realtime).

✨ Highlights

Things in here worth a closer look:

Feature	What's interesting
Syllabus parse-reveal	A scripted, reduced-motion-safe extraction animation — drop a PDF, watch dates cascade into the course.
Provenance everywhere	official / confirmed-by-N / unverified is a reusable, first-class UI primitive on every date.
Command palette	Cmd/Ctrl + K is the real navigation spine — typeahead, full keyboard a11y, focus-trapped, mobile bottom sheet.
Three separate auth contexts	Public marketing site · student app · teacher portal — deliberately never blended into one nav.
Grade math	A single source of truth (lib/gpa.ts) drives the banner grade, the grade-needed solver, and the GPA projector.
Blueprint supply pipe	A teacher's published outline is the verified blueprint students import — one record, not a copy.
Theming in one file	Tailwind v4 CSS-first @theme tokens; a refined dark theme + a Concordia maroon/gold theme swap at runtime.
Accessibility & motion	Keyboard nav, visible focus, ARIA roles, focus traps; CSS-only motion that respects prefers-reduced-motion.
Built to scale to a backend	Each stub (auth, follows, teacher invites, calendar sync) sits behind a single swappable provider.

There's also a self-running demo reel at /demo (a ~30-second auto-advancing tour built for screen recording).

🧰 Tech stack

Layer	Technology
Framework	React 19 + TypeScript 6 (strict mode)
Build tooling	Vite 8
Styling	Tailwind CSS v4 (CSS-first @theme, no tailwind.config.js)
Routing	React Router 7
State	React Context + hooks (no Redux)
Icons	lucide-react
Backend (integration phase)	Supabase — Postgres, Auth, Realtime

Data today is a single in-memory mock module so the whole app is explorable without a backend. Supabase is the designated production backend, and the codebase is structured to adopt it one provider at a time.

🚀 Getting started

Prerequisites: Node.js 20+ and npm.

# 1. Clone
git clone https://github.com/<your-username>/concordiatracker.git
cd concordiatracker

# 2. Install
npm install

# 3. Run the dev server (http://localhost:5173)
npm run dev

Script	What it does
npm run dev	Start the Vite dev server with HMR
npm run build	Type-check (tsc -b) and build for production
npm run preview	Preview the production build locally
npm run lint	Run ESLint over the project

No environment variables are needed yet — everything runs on mock data. (Supabase keys land here in the integration phase.)

🗂 Project structure

src/
├── app/            # Cross-cutting providers + hooks (the swappable backend seam)
│   └── providers/  #   AppData, Theme, Settings, Follows, Teacher, …
├── components/     # Shared UI primitives (Card, Select, DateTimePicker, ModalShell, …)
├── data/           # The single mock-data module + domain types
├── features/       # Screen-level features, one folder each
│   ├── today/      #   the launch view
│   ├── courses/    #   course list, detail, grade editor, blueprint browser
│   ├── calendar/   #   month / week / agenda, layered
│   ├── community/  #   campus-events aggregator + org profiles
│   ├── teacher/    #   the invite-based teacher portal
│   ├── settings/   #   profile, billing, usage, legal
│   └── landing/    #   the public marketing site
├── layouts/        # The three context shells (public / student / teacher)
├── lib/            # Pure logic: gpa, grade, date, course-color, …
└── index.css       # ALL design tokens (colors, type, spacing) — reskin in one file

🏛 Architecture

A few decisions that make the codebase pleasant to grow:

• Three deliberately separate contexts — public marketing, the student app (exactly four tabs: Today · Courses · Calendar · Community), and a plainer teacher portal — never blended into one navigation.
• One mock-data module, one write surface. All in-session mutations (grades, statuses, follows, teacher publishes) flow through context providers that clone a single seed, so there's exactly one place state lives.
• Designed for a clean Supabase swap. Backend-dependent pieces — authentication, the follow graph, teacher invites/approval, calendar sync, notifications — are isolated behind one provider each. Re-implementing that single file against Supabase connects the feature with no UI changes. These seams are flagged in-code as connection-phase.
• All design tokens in one file. Colors, type scale, spacing, and radii are CSS custom properties in index.css, exposed to Tailwind via @theme inline; re-skinning or adding a theme is a one-file change.
• Discipline. TypeScript strict on, files kept small and single-purpose, motion CSS-only and reduced-motion safe.

🛣 Roadmap

The front end is feature-complete on mock data. The next phase wires the backend:

• Supabase Auth — replace mock sign-in across all three contexts
• Postgres schema + RLS — courses, assessments, blueprints, provenance, follows
• Realtime — peer date-corrections and the "confirmed by N students" counts, live
• Teacher invites & approval — real single-use, email-bound, expiring tokens
• Stripe — the semester pass / monthly billing made real
• A real syllabus parser — swap the scripted reveal for genuine extraction

🤖 Development & AI assistance

Built with the assistance of Claude Code for refactoring and feature implementation.

🗂 Where outlines come from

Most blueprints are uploaded by students. A slice of them are read automatically from eConcordia, Concordia's online-course platform, which publishes the current term's outline for every online course as a public PDF.

Why this source. Concordia's Open Data has no outline endpoint at all, and its schedule feed currently stops at Winter 2026 — it cannot even tell us which sections are running this term. eConcordia can.

The slug trick

The outline URL is not derived from the course code. Each card on courses.aspx carries a thumbnail whose filename is the key:

COMM 305 → /home/src/assets/images/courses/managerial_accounting.jpg
         → https://www.econcordia.com/outlines/managerial_accounting.pdf

So discovery has to go through the catalogue page; you cannot construct an outline URL from a code.

The postback gotcha — and why we do not need a browser

The semester filter is an ASP.NET postback (__doPostBack on ctl00$main_content$CourseList$ddlSemester), so plain curl on the bare page only ever returns the default term. The usual advice is to drive it with Playwright.

Measured on 15 Sep 2026: that is not necessary. The page also accepts the semester as an ordinary query parameter — courses.aspx?semester=123 returns all 58 Winter cards with no cookies, no VIEWSTATE and no postback. That matters beyond tidiness: Playwright cannot run in the serverless function this job lives in, and the repo keeps exactly one runtime dependency on purpose.

One thing that does not work: ?semester=All Courses silently returns the default set, so the semesters are walked one at a time — which is what we want anyway, since the semester is how the term gets attributed. The year is read off the option label (Fall/Winter (September 8, 2026 - April 12, 2027)), never from our own clock.

Pieces

Path	What it does
api/_econcordia.ts	Catalogue parsing, slug → URL, polite fetch, dependency-free PDF text extraction
api/_outline-extract.ts	Outline text → assessment scheme (same model as /api/parse-syllabus)
api/sync-outlines.ts	The job: discover, then parse a bounded batch
db/outline_sync.sql	outline_sources ledger, source_url column, the 6-hourly cron
scripts/scrape-outlines.mjs	Local runner — coverage report + PDFs + text, no keys needed

npm run scrape:outlines -- --semester 121   # Fall, into .outlines/
npm run test:econcordia                     # the pure parsing, against captured markup

Rules it will not break

• Coverage is logged per course (ok / missing / no_text / parse_failed) so a silent regression is visible. select * from outline_coverage();
• ~1 request/second, one catalogue fetch per semester per run, and an unchanged PDF (matched by SHA-256) costs one GET and no model call.
• A scheme whose weights do not total ~100 is dropped, not published. It would go out under a verified badge, and wrong numbers a student trusts are worse than no numbers.
• Dates are never inferred. "Week 4" and "TBA" import as no date.
• It only ever writes rows it owns (user_id is null, author = 'Course outline'). Student uploads and the whole upload flow are untouched, and a course with no eConcordia outline behaves exactly as it does today.

📄 License & usage

© 2026 Alex Degryse — All rights reserved.

This repository is public for portfolio review only. It is not open source: you're welcome to read the code, but copying, modifying, redistributing, or reusing it in another project is not permitted without written permission. See LICENSE.