skyspace

plan adder
schedule
course override
courses
plan
study abroad/gap semester
settings

Inspiration

Rice students plan a degree with a PDF, a spreadsheet, and many browser tabs. Two student tools that helped with this have shut down. We wanted one tool that does the three jobs: find courses, fit them into a schedule, and check the plan against the real degree requirements.

What it does

Skyspace has three pages.

Catalog. Search the current term. Filter by distribution group, day, time, and open seats. Open a section to see seats, prerequisites, and which requirement it fills in your plan.
Schedule. Add many candidate courses for one term. Hide a course to test a combination. The grid marks time conflicts and full sections. Copy the CRNs to paste into Esther.
Plan. Drag courses across terms. The engine checks every rule of your major and the university requirements. It warns; it never blocks. When it cannot verify a rule, it says so and asks you to check.

Sign in with a Rice email code. Work done before sign-in moves to your account.

How we built it

Backend: seven Rust crates in one workspace. skyspace-core holds the rule engine and conflict detection. It is pure: no I/O, no clock, no randomness. The same crate compiles to WebAssembly, so the browser and the server run the same evaluation.
Data: scrapers pull the public Rice course pages on timers. They wait 150 ms between requests and archive every response. A replay command re-parses the archive after a parser fix.
API: Axum over Postgres. The API only reads the database. It never calls Rice during a request.
Frontend: React and the Astryx design system. A data-source layer lets the app run on a built-in demo fixture or on the live API.
Deploy: one docker compose up starts Postgres, migrations, the API, the cron jobs, and Caddy with TLS.

Challenges we ran into

Rice reuses CRNs across terms, so a CRN alone is not an identifier. Every lookup carries the term.
58 percent of sections have no meeting time. Hiding them by default would hide 90 percent of music courses, so the filter is subject-aware.
Requirement text in the catalog contains rules a program cannot verify, such as "from at least two departments." We made these visible self-checks instead of silent passes.

Accomplishments that we're proud of

The browser and the server cannot contradict each other about a plan. It is one function in one crate.
A course moved before its prerequisite gets a warning within one frame of the drop.
The system says "cannot verify" out loud. It never marks a rule met on a guess.
A full stack, from scraper to TLS, in one compose file.

What we learned

A pure core is not only good design. It is what makes the same code run in two places.
Honest data is harder than fast data. "Not polled" and "zero seats" are different facts and must look different.
Archive everything from day one. History cannot be added later.