rookie

Learn Computer Science. Build Real Skills.

Rookie is a learning platform for CS fundamentals — programming, DSA, databases, operating systems, networking, system design and web development. It combines a classroom, a roadmap, a coding platform and a personal learning dashboard into one daily loop:

Open it every morning and immediately know what you're learning today, which class you have, what to practice, how far along your roadmap you are, and what to do next.

---

Tech stack

Layer	Choice
Framework	Next.js 16 (App Router, Server Components, Server Actions, proxy.ts)
Language	TypeScript (strict)
UI	React 19, Tailwind CSS v4, shadcn-style components on radix-ui, Lucide icons, sonner toasts, cmdk command menu, Recharts
Forms	React Hook Form + Zod
Backend	Supabase — Postgres, Auth, Row Level Security, Realtime
Editor	CodeMirror 6 (@uiw/react-codemirror)

There is no separate API server: Next.js → Supabase → Postgres. Business rules that must hold no matter who calls (permissions, activity tracking, achievements, streaks) live in Postgres as RLS policies, triggers and RPC functions.

---

Architecture overview

Browser ──► Next.js (Server Components / Server Actions) ──► Supabase (PostgREST + Auth)
   │                                                               │
   └── Client Components (browser Supabase client, Realtime) ──────┤
                                                                   ▼
                                       Postgres: tables + RLS + triggers + RPCs

Key decisions

• Authorization lives in the database. Every table has RLS enabled; anything not explicitly allowed is denied. The UI also hides actions by role, and server actions re-check roles for better error messages, but the source of truth is supabase/migrations/*_rls.sql.
• No public signup. Admins create accounts (Admin → Users → Add user) through the admin_create_user database function, which re-checks is_admin(). Admins can also reset a user's password or delete the account. Supabase's own signup endpoint must be switched off in the dashboard so it can't be called directly. Email + password is the only login method.
• Roles are student and admin (a user_role enum on profiles). New users are always students. A trigger blocks role changes unless the caller is an admin; admins use the admin_set_role RPC.
• One activity system. Domain tables fire triggers (student_progress, coding_submissions, attendance, assignment_submissions, roadmap_node_progress) which call log_activity(). activity_logs has a unique (user_id, type, entity_id) key, so toggling a lesson on/off or re-solving a problem can't farm activity. Streaks, recent activity, achievements and analytics all read from this one log. Clients cannot write to it.
• Achievements are rows in achievements with JSON criteria (count of an activity type, streak length, attendance_rate). They're evaluated after each activity and unlocked automatically; unlocking creates a notification.
• Streaks count days (in the user's timezone) with at least one meaningful activity — lesson completed, problem solved, class attended, assignment submitted, roadmap topic completed. Achievement unlocks don't count.
• Class rosters = students enrolled in the class's course (course_enrollments). Classes with no course are open sessions visible to every student. Following a roadmap enrolls you in its courses.
• Assignment statuses: not started = no submission row; in_progress/submitted/reviewed are stored; late is derived from due_at. A trigger prevents students from grading themselves or editing reviewed work, and limits staff to grading fields.
• = personal agendas () + cohort agendas created by admins for a course (). Per-student completion lives in , so one cohort item can be completed individually by each student. Classes and assignment deadlines for the day are merged in at read time — no duplicated rows.

Code execution (coding platform)

The MVP deliberately does not run arbitrary code on the server. Execution sits behind a CodeRunner interface (src/services/execution):

• browser-js-runner — runs JavaScript in an isolated Web Worker in the student's own browser with a hard timeout and network APIs disabled.
• remote-runner — placeholder for a sandbox service (Judge0, Piston, Firecracker…). Configure NEXT_PUBLIC_CODE_RUNNER_URL to enable Java/Python. Without it, Java/Python submissions are stored with verdict pending.

Students can only read sample test cases (RLS). Hidden tests are staff-only and are meant to be executed by the future server-side judge. Until then, verdicts reported by the browser runner are trusted — fine for a learning MVP, not for competitive grading.

---

This is the beginning of the README. Read the rest at the original. Read the full README ↗