shanmukht9/skillgraph

1. Purpose and Application Shape

SkillGraph is a university talent-verification platform centered on proof-based student skills rather than CGPA. It presents role-specific dashboards for students, faculty, and recruiters, with the intended product model of a skill graph and recruiter-facing “Trust Ledger.” The repository currently contains a Next.js frontend plus a Supabase client integration; REST, AI, and graph backend implementations are not present in this tree.

2. Runtime and Entry Points

The application is a TypeScript Next.js App Router project. Global application framing and styling start at:

• app/layout.tsx

• app/globals.css

• app/page.tsx

app/page.tsx is the public landing/root route. The route filesystem under app/ defines all currently visible product flows.

3. Authentication Boundary

Authentication screens are isolated beneath the auth route segment:

• app/auth/login/page.tsx

• app/auth/signup/page.tsx

Supabase is the material external-service boundary and is initialized through:

• lib/supabase.ts

This client is the likely integration point for user identity, session state, and persisted platform data. The file tree does not show server-side auth middleware, API route handlers, or explicit role-enforcement logic; role-based access is presently represented primarily by separated dashboard routes.

4. Role-Based Dashboard Surface

The platform divides its primary experience by user role:

• app/dashboard/student/page.tsx

• app/dashboard/faculty/page.tsx

• app/dashboard/recruiter/page.tsx

This separation is architecture-defining: students build evidence-backed profiles, faculty administer or validate student activity, and recruiters consume searchable/verifiable candidate information. Navigation or post-login routing should select and protect these role-specific surfaces based on authenticated user metadata.

5. Student Skill-Profile Lifecycle

Student-facing routes define the profile construction workflow:

• app/dashboard/student/profile/page.tsx

• app/dashboard/student/skills/page.tsx

• app/dashboard/student/projects/page.tsx

The expected data flow is profile → declared/derived skills → projects as proof artifacts. These entities should ultimately feed the promised skill graph and trust model. AI-driven extraction and suggestions described in the README would naturally operate at the project/evidence-to-skill boundary, but no AI service or implementation is included.

6. Faculty Verification and Governance

Faculty operations are represented by:

• app/dashboard/faculty/students/page.tsx

• app/dashboard/faculty/requests/page.tsx

These routes imply a review boundary between student-submitted information and trusted institutional validation. Requests likely represent pending verification or administrative actions; approved outcomes should be the source of trust status exposed to recruiters. The concrete persistence schema and approval API are not present.

7. Recruiter Discovery and Trust Consumption

Recruiter capabilities are organized around candidate discovery and selection:

• app/dashboard/recruiter/search/page.tsx

• app/dashboard/recruiter/shortlist/page.tsx

The principal flow is search/filter over student skill evidence, inspect trusted profiles, then persist selected candidates in a shortlist. This is where graph-backed relationship queries—student, skill, project, verification, and institution—would be most consequential, though the repository currently exposes no graph database connector or query layer.

8. Missing Backend Boundaries

The README’s intended REST API, graph storage, AI layer, and university analytics are architectural targets rather than checked-in components. Current backend-facing code is limited to lib/supabase.ts. A downstream implementation should keep UI routes decoupled from data access, introduce authenticated role authorization at server boundaries, and model verification provenance separately from self-reported skills so recruiter trust decisions can be traced to evidence and faculty approval.