coe-nthu/ipedu_scholarship_system

1. This is a Next.js App Router repository with a clear split between server-rendered pages, client-facing interactive components, and API route handlers under app/. The root layout and global styles live in app/layout.tsx and app/globals.css, and the top-level UI is composed from page routes rather than a separate backend service.

2. The public-facing scholarship site is organized as a set of program-specific pages under app/scholarships/* plus a scholarship selection client component. These pages are likely the entry point for applicants to choose a program and submit data, with shared form/configuration logic kept in lib/scholarship-* modules.

3. Scholarship application submission is handled by dedicated API routes under app/api/scholarships/*. The key flow appears to be: applicant form data goes to the scholarship API, file uploads are coordinated through an upload-url endpoint, and a confirmation-email endpoint sends transactional confirmation after submission.

4. The administrative back office lives in app/dashboard/* and is backed by a larger set of dashboard APIs under app/api/dashboard/*. This includes login/logout, password reset and password change, account management, authorized email management, scholarship program management, journal indexes, NSTC journals, downloads, verification, and correction-email handling. The dashboard is therefore not just a view layer; it is the operational console for editing and exporting system data.

5. Authentication is a first-class subsystem. There are explicit routes for dashboard login, logout, verification, password reset request/confirm, and an auth callback under app/auth/callback. A proxy.ts file suggests request-time protection or routing guards, and lib/auth.ts centralizes auth logic. The presence of auth-code-error and authorized-emails implies controlled access based on email allowlists and verification codes rather than open self-signup.

6. The data layer is Supabase-backed. The repository contains lib/supabase/client.ts and lib/supabase/server.ts for client/server access patterns, plus a substantial supabase/ directory with schema and maintenance SQL. That points to Supabase as the main persistence and storage boundary, with the app talking to it directly from route handlers and server components.

7. The supabase/ folder is also part of the architecture, not just deployment trivia. It includes schema definition, storage policy scripts, schema sync scripts, and migration-like SQL for authorized emails, NSTC core journal records, and scholarship description fixes. This indicates the repo treats database structure and storage policies as versioned infrastructure alongside application code.

8. Email delivery is separated into its own utility layer under lib/email/resend.ts. In practice, this supports confirmation and correction workflows from scholarship-related APIs and probably dashboard-driven notifications. Resend is the external transactional email service in the system boundary.

9. There is a dedicated publications/import subsystem. app/api/publications/fetch exposes publication lookup, while lib/doi.ts, lib/journal-index-service.ts, lib/journal-index-import.ts, lib/nstc-core-service.ts, and lib/nstc-core-import.ts suggest ingestion and normalization pipelines for external publication metadata and journal index data. This is a backend enrichment layer rather than a user-facing feature.

10. The dashboard UI has several stateful presentation components: tables, tabs, detail views, program switchers, and admin panels under app/dashboard/*. These components consume API data and present operational workflows such as reviewing applications, switching scholarship programs, and displaying downloadable records.

11. Shared domain logic is concentrated in lib/. Files like validation.ts, verification.ts, scholarship-settings.ts, scholarship-settings-server.ts, scholarship-form-options.ts, scholarship-language.ts, departments.ts, and dashboard-application-display.ts hold the rules that multiple routes and components depend on. This is the main boundary where form rules, localization, allowed values, and display normalization are kept consistent across frontend and backend.

12. The component architecture is mostly built on a reusable UI kit under components/ui/, with a few higher-level app components such as auth-button, language-toggle, and database-multi-select. This indicates a component-driven frontend with a strong shared design system, likely used across both applicant-facing pages and the admin dashboard.

13. Operationally, the repo also includes Node scripts for dashboard account generation, password hashing, and password update generation. Those scripts reinforce that account/admin lifecycle is managed as part of the project rather than through an external admin console.

14. One important architectural note: the repository structure in the README references Prisma and older route locations, but the actual tree shows a Supabase-based implementation and a much broader dashboard/API surface. For diagramming, the current source tree should be treated as authoritative: Next.js App Router front end + API routes, Supabase persistence/storage, Resend email, and a protected admin dashboard.