Dual User Modes (Full vs. Light)
Relevant source files
The following files were used as context for generating this wiki page:
The GUC Resume Enhancer application supports two distinct user interaction modes: a comprehensive "Full Mode" for authenticated users and a "Light Mode" for quick, anonymous use. This dual-mode architecture allows the application to cater to different user needs, balancing rich, persistent features with ease of access.
Full Mode provides a complete, stateful experience with user accounts, resume history, and secure API key management. In contrast, Light Mode offers a way to interact with the application's AI capabilities without requiring account creation, by storing API keys locally in the user's browser. The main entry points on the homepage guide users toward one of these two paths.
Sources: README.md:19-22, 91-99, page.tsx:90-96
Feature Comparison
The following table summarizes the key differences between Full and Light modes.
| Feature | Full Mode (Authenticated) | Light Mode (Anonymous) |
|---|---|---|
| Authentication | Required (NextAuth) | Not required |
| Entry Point | /auth/signup or /auth/signin | /api-keys-light |
| API Key Storage | Securely in the database (encrypted) | Browser localStorage |
| Data Persistence | All data (resumes, history) saved to user account | Keys are lost if browser data is cleared. No resume history. |
| Key Features | Dashboard, Resume History, Settings, Diagnostics | Local API key management |
| Security | Session-based, encrypted keys, RLS policies | Keys stored in browser; less secure |
Sources: README.md:19-22, 91-99, api-keys-light/page.tsx:103-106, INTEGRATION_GUIDE.md:27-30
Full Mode (Authenticated)
Full Mode is the complete, feature-rich experience for registered users. It requires authentication and provides a persistent, personalized environment.
Sources: README.md:85-90
Authentication and Authorization
Access to Full Mode is gated by NextAuth. Users must sign up or sign in to access their dashboard and other features. API endpoints that handle sensitive operations, such as resume uploads and enhancements, are protected and require a valid user session.
The following diagram illustrates the authentication check on an API route.
This diagram shows the authentication check within API routes.
Sources: api/resumes/upload/route.ts:50-54, api/enhance-resume/[id]/route.ts:161-165
Data Persistence
All user-specific data, including uploaded resumes, enhancement history, and API keys, is stored in a PostgreSQL database, managed by the Prisma ORM. This ensures that user data is saved across sessions and devices.
Key database models for this mode include:
User: Stores user account information.Resume: Contains metadata about uploaded resumes.ResumeEnhancement: Records each AI enhancement performed.UserApiKey: Stores user-provided, encrypted API keys for AI providers.
Sources: README.md:113-118, INTEGRATION_GUIDE.md:65-69
Key Management
In Full Mode, user-provided API keys are encrypted and stored in the UserApiKey table in the database. This provides a secure way for users to manage their keys for different AI providers. The encryption is handled by functions in lib/crypto.ts.
Sources: README.md:25, INTEGRATION_GUIDE.md:30, api/enhance-resume/[id]/route.ts:193-194
User Flow
The typical user journey in Full Mode involves signing in, managing resumes and API keys through a central dashboard, and viewing past activity.
This diagram illustrates the sequence of events for a user uploading and enhancing a resume in Full Mode.
Sources: dashboard/_components/upload-section.tsx, enhance/[id]/_components/enhance-interface.tsx, api/resumes/upload/route.ts, api/enhance-resume/[id]/route.ts
Light Mode (Anonymous)
Light Mode is designed for quick, unauthenticated use. It allows users to manage API keys for AI providers without creating an account. The primary interface for this mode is the /api-keys-light page.
Sources: README.md:97-101, page.tsx:93-95
Local Storage for API Keys
The core of Light Mode is its client-side API key management. Instead of storing keys in a database, it uses the browser's localStorage. The localApiKeyStorage utility, defined in lib/api-key-storage.ts, provides methods to save, retrieve, and delete keys.
An alert on the page explicitly warns the user about this behavior:
API keys are stored in your browser's localStorage. They won't sync across devices and will be lost if you clear your browser data. For secure, persistent storage, sign in and use the full database mode.
Sources: api-keys-light/page.tsx:103-106, INTEGRATION_GUIDE.md:32
The structure for a stored API key in localStorage is as follows:
| Field | Type | Description |
|---|---|---|
id | string | A unique identifier for the key entry. |
provider | string | The AI provider (e.g., 'openai'). |
keyName | string | A user-defined name for the key. |
apiKey | string | The API key value. |
createdAt | string | ISO string timestamp of creation. |
isActive | boolean | Whether the key is currently active. |
Sources: api-keys-light/page.tsx:78
User Flow and Limitations
The flow for Light Mode is centered on the /api-keys-light page.
This diagram shows the simple process of adding an API key in Light Mode.
While the README.md suggests an immediate upload and enhancement flow for Light Mode, the API routes for uploading (/api/resumes/upload) and enhancing (/api/enhance-resume/[id]) are protected and require a valid user session from Full Mode. Therefore, the functionality of Light Mode, as implemented in the code, is limited to client-side management of API keys.
Sources: api-keys-light/page.tsx:84-93, api/resumes/upload/route.ts:50-54, api/enhance-resume/[id]/route.ts:161-165
Conclusion
The dual-mode system in GUC Resume Enhancer effectively separates concerns between two user archetypes. Full Mode offers a secure, persistent, and feature-rich platform for registered users who value history and convenience. Light Mode provides a frictionless entry point for users who wish to try the service without commitment, though its current implementation is focused on local API key management rather than a complete, unauthenticated enhancement workflow. This architecture provides flexibility and can be extended to support a fully anonymous enhancement process in the future if desired.