devforge

byGidiDev

# DevForge — Full Production Platform Build Prompt ## Project Vision DevForge is a gamified developer growth platform where developers forge real coding skill through ranked coding challenges, and get verified for hiring based on proven performance rather than a resume alone. Build the complete platform — ranked challenges AND verified hiring — as one cohesive production system, not split into phases. ## Tech Stack **Backend** - Django + Django REST Framework - PostgreSQL - JWT auth (`djangorestframework-simplejwt`) - `django-cors-headers`, `python-decouple`, `django-filter`, `Pillow`, `gunicorn` **Frontend** - React + Vite - Tailwind CSS - React Router - Axios with a JWT-aware interceptor (auto-attach access token, auto-refresh on expiry) **Deployment target** - Backend: Dockerized, host-agnostic (Railway/Render/VPS) - Frontend: static build, deployable to Vercel - Fully environment-based config — no hardcoded URLs, keys, or secrets anywhere ## Core Features **Developer side** 1. Registration & login (JWT) 2. Profile with score, rank, bio, avatar 3. Challenge catalog — browsable, filterable by category and difficulty 4. Challenge detail page 5. Submission flow — attempt a challenge, get scored, see pass/fail 6. Automatic rank recalculation on passed submissions (Django signal) 7. Leaderboard — ranked list of users by total score 8. Dashboard — rank, score, submission history 9. Verification status — once a developer crosses a defined threshold (e.g. passes N challenges at a minimum difficulty/rank), they become "Verified" **Employer / hiring side** 10. Employer registration & login (separate role from Developer) 11. Employer dashboard — post jobs, view applicants 12. Job postings — title, description, required verification level/category, salary range (optional) 13. Developers can browse jobs and apply (only if they meet the job's verification requirement, or apply anyway with a "below threshold" flag — your call, but be explicit about which) 14. Employers can browse/search verified developers directly (filter by rank, category strength, verification level) instead of waiting for applications 15. Application tracking — status per application (applied / viewed / shortlisted / rejected / hired) ## Data Model ``` Category - id (PK), name (unique) User (Django's built-in User model) - extended via Profile with a role distinguishing Developer vs Employer Profile - id (PK), user (OneToOne → User) - role (choices: developer / employer) - total_score (int, default 0), rank (int, default 0) - bio (text, optional), avatar (image, optional) - is_verified (bool, default False) - verification_level (choices: none / bronze / silver / gold — or similar tiering) Challenge - id (PK), title, description (text) - category (FK → Category, nullable, on_delete=SET_NULL) - difficulty (easy / medium / hard), points (int, default 10) - created_at (auto) Submission - id (PK) - user (FK → User, related_name="submissions") - challenge (FK → Challenge, related_name="submissions") - status (passed / failed / pending, default pending) - score_awarded (int, default 0) - submitted_at (auto, newest first) Company - id (PK), owner (FK → User, the employer account) - name, description, website (optional), logo (image, optional) Job - id (PK), company (FK → Company, related_name="jobs") - title, description - required_category (FK → Category, nullable) - required_verification_level (choices: none / bronze / silver / gold) - salary_range (optional, string or two int fields — your call) - created_at (auto), is_active (bool, default True) Application - id (PK) - job (FK → Job, related_name="applications") - developer (FK → User, related_name="applications") - status (choices: applied / viewed / shortlisted / rejected / hired, default applied) - applied_at (auto) ``` **Relationships:** Category 1:N Challenge · User 1:1 Profile · User 1:N Submission · Challenge 1:N Submission · Company 1:N Job · Job 1:N Application · User(developer) 1:N Application **Verification logic:** implement as a Django signal or service function triggered after rank recalculation — check the developer's passed-submission history against verification thresholds and update `Profile.is_verified` / `verification_level` accordingly. Keep thresholds as named constants/config, not magic numbers scattered in code. ## Backend API Requirements **Auth & profile** - `POST /api/auth/register/` (accepts role: developer or employer) - `POST /api/auth/login/`, `POST /api/auth/refresh/` - `GET/PATCH /api/profile/me/` **Challenges** - `GET /api/categories/` - `GET /api/challenges/` (filter by category, difficulty) - `GET /api/challenges/<id>/` - `POST /api/challenges/<id>/submit/` (authenticated, developer only) - `GET /api/leaderboard/` - `GET /api/profile/me/submissions/` **Hiring** - `POST /api/companies/` (employer only) - `GET/PATCH /api/companies/me/` - `POST /api/jobs/` (employer only) - `GET /api/jobs/` (public, filterable by category/verification level) - `GET /api/jobs/<id>/` - `POST /api/jobs/<id>/apply/` (developer only) - `GET /api/jobs/<id>/applications/` (employer only, own jobs) - `PATCH /api/applications/<id>/` (employer updates status) - `GET /api/developers/` (employer-facing search — filter by verification level, category strength, rank) ## Frontend Pages/Routes **Public** - `/` — landing page explaining both sides (developers + employers) - `/register` (role selection: developer or employer), `/login` - `/challenges`, `/challenges/:id` - `/leaderboard` - `/jobs`, `/jobs/:id` **Developer (protected)** - `/dashboard` — rank, score, submission history, verification status - `/applications` — jobs applied to, with status **Employer (protected)** - `/employer/dashboard` — company profile, posted jobs - `/employer/jobs/new`, `/employer/jobs/:id/applicants` - `/employer/developers` — search/browse verified developers - 404 page Role-based route protection is required: a developer should not be able to access `/employer/*` routes and vice versa. ## Non-negotiable engineering standards **Backend** - DRF conventions throughout: serializers, generic views/viewsets, explicit permission classes per role - Role-based permissions enforced server-side, not just hidden in the frontend UI - All secrets via `.env` / `python-decouple` - Rank recalculation and verification logic via Django signals, not inline in views - `requirements.txt` (pinned) and `.env.example` - Django admin registered for all models **Frontend** - Component-based structure, no monolithic files - Protected + role-based routes, redirecting appropriately - JWT stored securely (httpOnly cookie preferred; if localStorage, document the tradeoff) - Loading and error states on every API call - Responsive, mobile-first Tailwind - No hardcoded API URLs — `VITE_API_URL` env variable **Both** - `backend/` and `frontend/` as separate top-level folders, each independently runnable - Root `README.md` with full setup instructions for both - CORS configured for both local dev and the deployed frontend origin ## Deliverables 1. Full backend: models, migrations, all API endpoints, role-based permissions, admin registration 2. Full frontend: all routes/pages for both developer and employer sides, full API integration, role-based auth flow 3. `requirements.txt` and `package.json` with pinned/locked versions 4. `.env.example` for both backend and frontend 5. Dockerfile for backend (gunicorn, production-ready) 6. Root `README.md`: project overview, setup for both apps, migration steps, how to run both dev servers together Build this as one complete, cohesive platform — do not stub out or fake the hiring side. Prioritize working, idiomatic, secure code over cleverness. Ask before introducing any dependency not listed above.