FAQ

Can I run Sejong Pulse without every external integration configured?

Yes. The minimum local setup is the frontend, backend, and Supabase. Features such as search, calls, messaging, billing, recommendations, and advanced media flows require extra service configuration.

Where does authentication actually happen?

The login flow starts with Sejong credential verification, then the backend bootstraps or reuses a Supabase account and the frontend signs in through Supabase using the returned internal identity.

Where are the database schema and migrations?

The main schema snapshot is in stitch/backend/supabase_schema.sql, and incremental changes are in stitch/backend/migrations.

Where do recommendations come from?

Recommendation features are powered by Gorse, Redis-backed processing, and the repository’s recommendation worker and backfill scripts.

What powers the advisor?

The advisor uses the backend chat service and an OpenAI-compatible client configured against OpenRouter by default, plus local knowledge assets for campus and academic context.

Are the stitched prototype folders part of the production app?

No. The stitched prototype folders document UX direction and product concepts. The production runtime lives primarily in stitch/frontend and stitch/backend.

What is the purpose of experiments/sejong_portal_agent?

It is a separate experimental application for portal-agent work and should be treated independently from the main Sejong Pulse runtime unless the team intentionally promotes parts of it into production.

How do I publish the documentation?

This scaffold builds static HTML into docs/_build/html. You can publish that output with GitHub Pages, Netlify, or any static hosting platform when you are ready to add deployment automation.