System Requirements Document for gaming-platform-nexora

1. Introduction

NEXORA is a production-quality, full-stack gaming platform with the tagline “Discover. Play. Connect.” It is delivered as a responsive web application, a real React Native + Expo Android application, and a real React Native + Expo iOS application — not a WebView wrapper. NEXORA is a real product with a backend, database, authentication, storage, and role-based workflows, not a static UI.

The product serves players who want to discover, track, review, and discuss games; independent developers who want to publish and measure their games; moderators who keep community content safe; and administrators who operate the marketplace. NEXORA is a legitimate marketplace: it does not host or distribute pirated or cracked copyrighted games, third-party games are linked through official authorized store/download links, and game file uploads are restricted to authorized developers or open-source games.

The audience is players aged roughly 16–35 who already live inside Discord, Twitch, and Steam, plus the developer, moderator, and admin operators who work inside the same dark, luminous world.

2. System Overview

NEXORA is composed of three client surfaces and one backend:

• Web app (nexora/apps/web): React, Vite, TypeScript, Tailwind CSS, React Router, TanStack Query, Axios, Framer Motion, Lucide.
• Mobile apps (nexora/apps/mobile): React Native + Expo, TypeScript, Expo Router, NativeWind, with app.json and eas.json prepared for EAS builds.
• API (nexora/apps/api): Node.js, Express, TypeScript, REST, JWT access/refresh tokens, bcrypt, Zod, Helmet, CORS, rate limiting.
• Data and storage: PostgreSQL with Prisma (models, relationships, indexes, migrations) and S3-compatible storage for images, videos, and authorized game files.

Shared packages live in nexora/packages/ui, nexora/packages/types, and nexora/packages/utils; Prisma lives in nexora/prisma; the repository also contains .env.example, docker-compose.yml, and README.md.

Four roles operate the platform: Gamer/User, Developer, Moderator, and Admin.

Current accepted behavior spans: a cinematic homepage with a hero carousel and content rails; game cards; a full game detail page; backend-powered Discover search with filters, sorting, and pagination; global search across games, developers, categories, and users with autocomplete and search history; a category and platform taxonomy; user profiles with editing and following; library and wishlist; reviews with duplicate prevention; community posts, comments, likes, follows, sharing, activity feed, and notifications; a developer portal with dashboard metrics and a Draft → Submitted → Review → Approved → Published workflow requiring admin approval; an admin panel with approvals, suspensions, review removal, category management, featuring, banner management, and report review; authentication with register, login, logout, JWT access/refresh tokens, bcrypt, forgot/reset password, email verification, protected routes, and role-based authorization; recommendations; payments-ready architecture with orders, purchases, payment status, coupons, promotions, and purchase history via an authorized provider such as Razorpay; seeded demo data; responsive web; performance and SEO requirements; and a defined build order.

Narrow exclusions and boundaries: no pirated or cracked copyrighted games may be hosted or distributed; third-party games must use official authorized store/download links; game uploads are limited to authorized developers or open-source games; copyrighted artwork must not be copied; raw card information must never be stored; passwords, secrets, and private data must never be exposed; and the product must not be claimed as live unless actually deployed.

2a. Product Interpretation and Delivery Boundary

NEXORA is delivered as first-party web and mobile clients over a first-party REST API. All browsing surfaces — Home, Discover, Games, Categories, Free Games, Upcoming, Search, and the game detail page — are publicly reachable without an account, because discovery is the product's front door. Durable, actor-specific state — wishlist, library, reviews, profile, notifications, purchases, community participation, developer portal, and admin operations — is bound to an application-owned identity so that a player's tracking, a developer's submissions, and an administrator's decisions remain attached to the correct person across sessions and devices.

Identity is established through Sign Up, verified through Email Verification, resumed through Login, and recovered through Account Recovery. Developer-only and admin-only surfaces are protected by role-based authorization; the Developer Application flow is the accepted path by which a gamer becomes an authorized developer, and admin approval is the accepted gate before any submitted game becomes Published.

Third-party game acquisition is not owned by NEXORA: for third-party titles, the platform routes the player to official authorized store/download links. Payment processing for legally sold games is owned by an authorized external provider such as Razorpay; NEXORA owns the order, purchase, payment-status, coupon, promotion, and purchase-history records but never stores raw card information. Malware/security scanning of uploaded game files is an integration point owned by an external scanning service.

Deployment is production-ready by configuration: web on Vercel/Cloudflare or equivalent, backend on Railway/Render/Fly/AWS or equivalent, managed PostgreSQL, S3-compatible storage, and mobile via Expo EAS. The product must not be described as live unless it has actually been deployed; otherwise exact deployment instructions are provided.

Future horizon (not current scope): the recommendation architecture must remain ready for future ML-based recommendations. No ML model is part of current acceptance.

2c. Page Content and Component Coverage

Home

• Information/state: Cinematic full-bleed hero carousel of featured game artwork with title, genre, rating, platforms, and description; content rails for Trending, Most Played, New Releases, Free Games, Multiplayer, Indie Spotlight, Coming Soon, Recommended, Editors' Choice, Developer Spotlight, and Community; footer.
• Primary actions: “Explore Game” and “Watch Trailer” on the active hero slide; carousel tick selection; rail scrolling; game card “View Game” and wishlist.
• Supporting actions: Navbar navigation (NEXORA, Home, Discover, Games, Categories, Free Games, Upcoming, Community, Search, Wishlist, Notifications, Profile); search entry; notification entry; profile entry.
• Domain entities: Game, GameScreenshot, GameTrailer, Category, Genre, Platform, Developer, Review (ratings), Wishlist, Post (community rail).
• Component responsibilities: Hero carousel with cross-fade between slides and a right-edge vertical tick rail; horizontal snap rails with fade masks and gradient hairline separators; game cards; navbar with active-state indicator; footer.
• States: Loading — skeleton rails and hero placeholder; Empty — a rail with no qualifying games collapses or shows a quiet empty label; Success — populated rails and hero; Error — a failed rail shows an inline retry without breaking the rest of the page; Recovery — retry re-fetches only the failed section.

Discover

• Information/state: Backend-powered result grid with live result count; active filter set; current sort; pagination or infinite scroll position.
• Primary actions: Apply filters (genre, platform, price, rating, release date, multiplayer, single-player, online/offline, free-to-play, indie, early access); sort by Popular, Newest, Rating, Reviews, Price; paginate or infinite-scroll.
• Supporting actions: Clear individual filters; clear all; open a game card.
• Domain entities: Game, Genre, Category, Platform, Review, Wishlist.
• Component responsibilities: 280px sticky glass filter rail with cyan hairline checkboxes and tabular result count; sticky sort bar; responsive 1/2/3/4-up card grid with staggered entrances on filter change.
• States: Loading — skeleton card grid; Empty — “no games match these filters” with a clear-filters action; Success — populated grid; Error — inline error with retry preserving the filter set; Recovery — retry re-runs the same query.

Games

• Information/state: The primary games catalog listing with card metadata (cover, title, genre, rating, platforms, price/free label).
• Primary actions: Browse, open a game card, wishlist from the card.
• Supporting actions: Navigate to Discover for filtered browsing; navigate to Categories.
• Domain entities: Game, Genre, Platform, Review, Wishlist.
• Component responsibilities: Card grid, pagination or infinite scroll, game card component.
• States: Loading — skeletons; Empty — catalog empty message; Success — populated catalog; Error — retry; Recovery — retry preserves scroll position where possible.

Categories

• Information/state: The accepted category taxonomy — Action, Adventure, RPG, Strategy, Racing, Sports, Simulation, Horror, Survival, Puzzle, Platformer, Fighting, Shooter, Casual, Multiplayer, MMO, Indie, Open World, Story Rich — and the platform taxonomy — Windows, macOS, Linux, Android, iOS, Web.
• Primary actions: Select a category or platform to browse matching games.
• Supporting actions: Combine a category selection with platform selection.
• Domain entities: Category, Genre, Platform, Game.
• Component responsibilities: Category tiles/chips, platform chips, resulting game grid.
• States: Loading — skeleton tiles and grid; Empty — category with no games yet; Success — populated; Error — retry; Recovery — retry preserves the selected category.

Free Games

• Information/state: Games offered as free-to-play or free acquisitions, with card metadata and a free label.
• Primary actions: Open a game card; wishlist.
• Supporting actions: Navigate to Discover with the free-to-play filter applied.
• Domain entities: Game, Genre, Platform, Review, Wishlist.
• Component responsibilities: Card grid, free-label badge treatment.
• States: Loading — skeletons; Empty — no free games currently listed; Success — populated; Error — retry; Recovery — retry.

Upcoming

• Information/state: Forthcoming games with release-date information and card metadata.
• Primary actions: Open a game card; wishlist an upcoming game.
• Supporting actions: Navigate to Discover with release-date sorting.
• Domain entities: Game, Genre, Platform, Wishlist.
• Component responsibilities: Card grid ordered by release date; release-date display.
• States: Loading — skeletons; Empty — no upcoming games; Success — populated; Error — retry; Recovery — retry.

Search

• Information/state: Query input, autocomplete suggestions across games, developers, categories, and users, and search history.
• Primary actions: Type a query; select an autocomplete suggestion; submit a search; select a history entry; clear history.
• Supporting actions: Navigate to a result's destination (game page, developer profile, category, user profile).
• Domain entities: Game, Developer, Category, User.
• Component responsibilities: Search input with autocomplete dropdown, grouped suggestion list, history list with clear control.
• States: Loading — inline suggestion spinner; Empty — no suggestions and no history; Success — grouped suggestions; Error — suggestion failure falls back to plain submit; Recovery — submitting the raw query still works.

/game/:slug

• Information/state: Banner; title/logo; rating; genre; developer; release date; platforms; price; description; screenshots; authorized trailer; system requirements; reviews; similar games; developer information.
• Primary actions: Get Game; Wishlist; Watch Trailer; write a review; mark a review helpful.
• Supporting actions: Open a similar game; open the developer's profile; open screenshots.
• Domain entities: Game, GameScreenshot, GameTrailer, Genre, Platform, Developer, Review, Wishlist, Library, Purchase, Order.
• Component responsibilities: Full-bleed banner hero; two-column body with 8 columns of description/screenshots/system requirements/reviews and a 4-column sticky glass purchase panel holding price, Get Game, Wishlist, and platform dots; review list and review composer; similar-games rail; developer information block.
• States: Loading — banner and body skeletons; Empty — no reviews yet, no screenshots, no trailer, or no similar games, each with a quiet label; Success — full detail; Error — unknown slug shows a not-found state with a route back to Discover; Recovery — retry re-fetches the game.
• Access: Publicly viewable. Get Game, Wishlist, and review submission require an established identity; for third-party games Get Game routes to the official authorized store/download link.

Community

• Information/state: Posts, comments, likes, follows, sharing, activity feed, and notifications.
• Primary actions: Create a post; comment; like; follow a user or developer; share a post; report a post or comment.
• Supporting actions: Open an author's profile; open the activity feed; open notifications.
• Domain entities: Post, Comment, Follow, Notification, Report, User, Developer.
• Component responsibilities: Composer, feed, post card with like/comment/share/report controls, comment thread, activity feed panel.
• States: Loading — feed skeletons; Empty — no posts yet with a composer prompt; Success — populated feed; Error — inline retry per post action; Recovery — failed post submission preserves the draft text.
• Access: Reading the feed is public; posting, commenting, liking, following, sharing, and reporting require an established identity. Moderators and Admins additionally act on reported content through Reports.

Profile

• Information/state: Avatar, username, bio, joined date, favourite games, library, wishlist, reviews, followers, following, and achievements.
• Primary actions: Edit profile; follow a user; follow a developer.
• Supporting actions: Open a game from favourite games, library, or wishlist; open a review; open the followers or following list.
• Domain entities: User, Developer, Follow, Game, Library, Wishlist, Review, Achievement, UserAchievement.
• Component responsibilities: Profile header with avatar and identity details; tabbed or sectioned content for favourite games, library, wishlist, reviews, followers, following, and achievements; edit-profile form.
• States: Loading — header and section skeletons; Empty — no favourite games, library, wishlist, reviews, followers, following, or achievements, each with a quiet label; Success — populated profile; Error — retry; Recovery — failed profile save preserves entered values.
• Access: Viewing a profile is public; editing your own profile and following require an established identity.

Wishlist

• Information/state: Wishlisted games with artwork, price, offers, rating, platform, and release date.
• Primary actions: Remove from wishlist; open a game; Get Game.
• Supporting actions: Navigate to Notifications to review release and price-change notifications.
• Domain entities: Wishlist, Game, Review, Platform, Notification.
• Component responsibilities: Wishlist grid/list with price, offer, rating, platform, and release-date fields; remove control.
• States: Loading — skeletons; Empty — “your wishlist is empty” with a link to Discover; Success — populated wishlist; Error — retry; Recovery — failed removal restores the item and shows an inline error.
• Access: Requires an established identity.

Library

• Information/state: Sections Playing, Completed, Favourite, Recently Played, and Want to Play.
• Primary actions: Move a game between sections; open a game; write a review from a library entry.
• Supporting actions: Open the game page; open Wishlist.
• Domain entities: Library, Game, Review, Achievement, UserAchievement.
• Component responsibilities: Section tabs, library entry cards, section-move control.
• States: Loading — skeletons; Empty — each section shows its own empty label; Success — populated sections; Error — retry; Recovery — failed section move reverts the entry and shows an inline error.
• Access: Requires an established identity.

Reviews

• Information/state: Review composer with 1–5 star rating, title, text, recommendation, playtime, and a helpful button on existing reviews; duplicate-review prevention state.
• Primary actions: Submit a review; mark a review helpful.
• Supporting actions: Open the reviewed game; open the reviewer's profile.
• Domain entities: Review, Game, User.
• Component responsibilities: Star rating control, title and text inputs, recommendation toggle, playtime field, submit control, helpful button, duplicate-review notice.
• States: Loading — existing reviews skeleton; Empty — no reviews for this game; Success — review appears in the list; Error — validation errors shown per field; Recovery — a duplicate-review attempt is blocked with a clear message and the existing review is surfaced.
• Access: Reading reviews is public; submitting a review and marking helpful require an established identity. Moderators and Admins can remove reviews.

Notifications

• Information/state: Release notifications, price-change notifications, and community notifications.
• Primary actions: Open the referenced game, post, or profile; mark as read.
• Supporting actions: Clear notifications.
• Domain entities: Notification, Game, Post, User.
• Component responsibilities: Notification list with type grouping, read state, and deep link to the referenced entity.
• States: Loading — skeletons; Empty — “no notifications yet”; Success — populated list; Error — retry; Recovery — retry preserves read state.
• Access: Requires an established identity.

Developer Application

• Information/state: Application form capturing the information required to become an authorized developer, and the current application status.
• Primary actions: Submit an application; view application status.
• Supporting actions: Return to Profile.
• Domain entities: DeveloperApplication, User, Developer.
• Component responsibilities: Application form with validation, status indicator.
• States: Loading — status skeleton; Empty — no application yet with the form shown; Success — submitted status displayed; Error — validation errors per field; Recovery — a rejected application shows the decision and allows a new submission.
• Access: Requires an established identity.

/developer

• Information/state: Dashboard metrics for Games, views, wishlists, ratings, reviews, downloads, and revenue.
• Primary actions: Open a game in Game Editor; open Submissions; start creating a game.
• Supporting actions: Navigate to the developer's public profile.
• Domain entities: Developer, Game, Review, Wishlist, Purchase, Order, Payment, GameSubmission.
• Component responsibilities: 240px left nav rail; dense metric tables with 40px rows and tabular numerals; metric summary cards.
• States: Loading — metric skeletons; Empty — a new developer with no games sees a create-first-game prompt; Success — populated metrics; Error — retry; Recovery — retry per metric block.
• Access: Requires an established identity with authorized developer access.

Game Editor

• Information/state: Game record fields — cover, banner, screenshots, trailer, description, genres, platforms, pricing, and system requirements — plus the current publishing state.
• Primary actions: Create a game; edit a game; upload cover, banner, screenshots, and trailer; save as Draft; submit for review.
• Supporting actions: Preview the game page; return to the dashboard.
• Domain entities: Game, GameScreenshot, GameTrailer, Genre, Platform, GameSubmission.
• Component responsibilities: Media upload controls with upload validation feedback, metadata form, pricing fields, system-requirements fields, save and submit controls, publishing-state indicator.
• States: Loading — form skeleton; Empty — new game with empty fields; Success — saved draft confirmation; Error — per-field validation and upload rejection messages; Recovery — failed uploads preserve other entered fields and allow retry.
• Access: Requires an established identity with authorized developer access. Only authorized developers may upload game files.

Submissions

• Information/state: The Draft → Submitted → Review → Approved → Published lifecycle state of each game, with review feedback where present.
• Primary actions: Submit a draft; withdraw or resubmit after rejection; open the game in Game Editor.
• Supporting actions: View admin decision notes.
• Domain entities: GameSubmission, Game, Developer.
• Component responsibilities: Submission list with state chips, decision notes, and per-item actions.
• States: Loading — list skeleton; Empty — no submissions yet; Success — populated list with current states; Error — retry; Recovery — a rejected submission shows the reason and offers resubmission.
• Access: Requires an established identity with authorized developer access; Admins see the same lifecycle from the approval side.

/admin

• Information/state: Platform-wide records for users, developers, games, reviews, reports, downloads, revenue, and pending submissions.
• Primary actions: Open Admin Moderation; open Reports; open a pending submission.
• Supporting actions: Filter and search administrative records.
• Domain entities: User, Developer, Game, Review, Report, Purchase, Order, Payment, GameSubmission.
• Component responsibilities: 240px left nav rail; dense data tables with 40px rows and tabular numerals; summary metric blocks.
• States: Loading — table skeletons; Empty — no records in a category; Success — populated tables; Error — retry; Recovery — retry per table.
• Access: Requires an established identity with admin role.

Admin Moderation

• Information/state: Pending game submissions, user and developer records, review records, category records, banner records, and featuring state.
• Primary actions: Approve or reject a game; suspend a user or developer; remove a review; manage categories; feature a game; manage banners.
• Supporting actions: Open the affected game, user, or developer record.
• Domain entities: Game, GameSubmission, User, Developer, Review, Category, Banner.
• Component responsibilities: Approval queue with decision controls, suspension controls, review removal control, category management controls, featuring toggle, banner management controls.
• States: Loading — queue skeletons; Empty — no pending items; Success — action confirmation and updated state; Error — action failure with retry; Recovery — a failed approval leaves the submission in its prior state.
• Access: Requires an established identity with admin role.

Reports

• Information/state: Reported community content with reporter, reason, and current status.
• Primary actions: Review a report; remove the reported review or content; resolve or dismiss the report.
• Supporting actions: Open the reported post, comment, or review; open the reporter's and author's profiles.
• Domain entities: Report, Post, Comment, Review, User.
• Component responsibilities: Report queue, report detail panel, resolution controls.
• States: Loading — queue skeleton; Empty — no open reports; Success — resolution recorded and item removed from the open queue; Error — retry; Recovery — a failed resolution keeps the report open.
• Access: Requires an established identity with moderator or admin role.

Purchases

• Information/state: Orders, purchases, payment status, coupons, promotions, and purchase history for legally sold games.
• Primary actions: Start a purchase for a legally sold game; apply a coupon or promotion; view purchase history and payment status.
• Supporting actions: Open the purchased game; open the order detail.
• Domain entities: Purchase, Order, Payment, Game, Coupon, Promotion.
• Component responsibilities: Purchase panel, coupon/promotion entry, order summary, payment-status indicator, purchase-history list.
• States: Loading — history skeleton; Empty — no purchases yet; Success — completed order with confirmed payment status; Error — declined or failed payment with a clear message; Recovery — a failed payment leaves the order unpaid and allows retry; raw card information is never stored.
• Access: Requires an established identity. Payment processing is performed by an authorized external provider such as Razorpay.

Login

• Information/state: Credential entry for returning users across all four roles.
• Primary actions: Submit credentials; navigate to Account Recovery; navigate to Sign Up.
• Supporting actions: Return to the previously intended destination after successful login.
• Domain entities: User, Developer, Moderator, Admin.
• Component responsibilities: Credential form with validation, error messaging, links to recovery and sign-up.
• States: Loading — submit disabled with progress; Empty — initial form; Success — session established and redirect to the intended destination; Error — invalid credentials message without revealing which field was wrong; Recovery — link to Account Recovery.
• Access: Anonymous.

Sign Up

• Information/state: Enrollment form for new gamers.
• Primary actions: Create an account; navigate to Login.
• Supporting actions: Proceed to Email Verification after registration.
• Domain entities: User.
• Component responsibilities: Registration form with validation, password rules, and terms acknowledgement.
• States: Loading — submit disabled with progress; Empty — initial form; Success — account created and verification prompted; Error — per-field validation and duplicate-account messaging; Recovery — failed submission preserves entered values.
• Access: Anonymous.

Account Recovery

• Information/state: Forgot-password request and reset-password completion.
• Primary actions: Request a reset; set a new password from the reset link.
• Supporting actions: Return to Login.
• Domain entities: User.
• Component responsibilities: Email request form, reset form with password rules, confirmation messaging.
• States: Loading — submit disabled with progress; Empty — initial request form; Success — reset link sent or password updated; Error — invalid or expired reset token with a path to request a new one; Recovery — request a fresh reset link.
• Access: Anonymous.

Email Verification

• Information/state: Verification status for a newly registered account.
• Primary actions: Confirm the verification link; request a new verification email.
• Supporting actions: Continue to Login after verification.
• Domain entities: User.
• Component responsibilities: Verification status panel, resend control.
• States: Loading — verifying; Empty — awaiting verification with resend available; Success — verified and prompted to log in; Error — expired or invalid token with resend; Recovery — resend a new verification email.
• Access: Anonymous.

3. Functional Requirements

FR-1 — Platform delivery. As a visitor, I should be able to use NEXORA on web, Android, and iOS as a real full-stack product rather than a static UI, so that discovery, tracking, and community work across my devices. (explicit)

• Trigger: opening the web app or installing the Android/iOS app.
• Observable result: the same accepted capabilities are reachable on all three clients, backed by the REST API and PostgreSQL.
• Failure/recovery: a client that cannot reach the API shows an error state with retry.
• Continuation: the visitor proceeds to browse or to Sign Up.

FR-2 — Legitimate catalog only. As a platform operator, I should ensure NEXORA does not host or distribute pirated or cracked copyrighted games, so that the marketplace stays lawful. (explicit)

• Trigger: any game record creation or publication.
• Observable result: no pirated or cracked copyrighted game is hosted or distributed.
• Failure/recovery: a submission that would violate this is rejected.
• Continuation: the developer may submit a compliant game.

FR-3 — Authorized third-party links. As a gamer, I should be taken to official authorized store/download links for third-party games, so that I acquire them legitimately. (explicit)

• Trigger: selecting Get Game on a third-party game.
• Observable result: navigation to the official authorized store/download link.
• Failure/recovery: an unavailable link shows an error with an alternative route back to the game page.
• Continuation: the gamer returns to NEXORA to track the game.

FR-4 — Restricted game uploads. As a platform operator, I should allow game uploads only for authorized developers or open-source games, so that uploaded files are legitimate. (explicit)

• Trigger: a game file upload attempt.
• Observable result: only authorized developers or open-source game workflows can upload game files.
• Failure/recovery: an unauthorized upload attempt is rejected with a clear message.
• Continuation: the user may apply through Developer Application.

FR-5 — Premium futuristic UI. As a gamer, I should experience a premium futuristic interface with a dark background, neon accents, glassmorphism, cinematic game artwork, rounded cards, smooth animations, modern typography, and full responsiveness, so that NEXORA feels like a real gaming startup. (explicit)

• Trigger: any page load.
• Observable result: the accepted visual system is applied consistently.
• Failure/recovery: reduced-motion preferences collapse animation to instant states.
• Continuation: the gamer browses normally.

FR-6 — Brand assets. As a platform operator, I should have a NEXORA logo, favicon, app icon, splash screen, and social preview built from an original abstract “N” + gaming/energy concept, so that the brand is consistent across web and mobile. (explicit)

• Trigger: asset generation and app packaging.
• Observable result: all five assets exist and are used by the web app, the mobile apps, and social previews.
• Failure/recovery: missing assets are treated as a build defect.
• Continuation: assets ship with the release.

FR-7 — Availability verification. As a platform operator, I should verify name/domain/app-store availability before launch, so that the brand can actually ship. (explicit)

• Trigger: pre-launch checklist.
• Observable result: availability is verified and recorded before launch.
• Failure/recovery: an unavailable name or handle blocks launch until resolved.
• Continuation: launch proceeds once verified.

FR-8 — Web stack. As a developer, I should build the web app with React, Vite, TypeScript, Tailwind CSS, React Router, TanStack Query, Axios, Framer Motion, and Lucide, so that the web client matches the accepted stack. (explicit)

• Observable result: the web app uses exactly these technologies.
• Failure/recovery: deviations are treated as defects.
• Continuation: the web app is built and deployed.

FR-9 — Mobile stack. As a developer, I should build real React Native + Expo Android and iOS apps with TypeScript, Expo Router, and NativeWind — not a WebView — so that mobile is a genuine native experience. (explicit)

• Observable result: native Android and iOS apps built from React Native + Expo.
• Failure/recovery: a WebView-based implementation is rejected.
• Continuation: the apps are built and distributed via EAS.

FR-10 — Backend stack. As a developer, I should build the backend with Node.js, Express, TypeScript, a REST API, JWT, bcrypt, Zod, Helmet, CORS, and rate limiting, so that the API matches the accepted stack. (explicit)

• Observable result: the API uses exactly these technologies.
• Failure/recovery: deviations are treated as defects.
• Continuation: the API serves all clients.

FR-11 — Database. As a developer, I should use PostgreSQL with Prisma, so that data is stored relationally with migrations. (explicit)

• Observable result: PostgreSQL is the datastore and Prisma is the ORM.
• Failure/recovery: migration failures block deployment and are surfaced.
• Continuation: migrations run as part of deployment.

FR-12 — Storage. As a developer, I should use S3-compatible storage for images, videos, and authorized game files, so that media is served reliably. (explicit)

• Observable result: media and authorized game files are stored in S3-compatible storage.
• Failure/recovery: upload failures surface an error and allow retry.
• Continuation: stored media is served through CDN-ready delivery.

FR-13 — Roles. As a platform operator, I should support the roles Gamer/User, Developer, Moderator, and Admin, so that each participant has the correct capabilities. (explicit)

• Observable result: role-based authorization governs protected surfaces.
• Failure/recovery: unauthorized access attempts are denied.
• Continuation: the user may apply for developer access if appropriate.

FR-14 — Homepage navbar. As a gamer, I should see a navbar containing NEXORA, Home, Discover, Games, Categories, Free Games, Upcoming, Community, Search, Wishlist, Notifications, and Profile, so that I can reach every primary destination. (explicit)

• Observable result: all listed navbar items are present and functional.
• Failure/recovery: a broken destination shows an error state with a route back.
• Continuation: the gamer navigates onward.

FR-15 — Hero carousel. As a gamer, I should see a hero carousel with game artwork, title, genre, rating, platforms, description, “Explore Game,” and “Watch Trailer,” so that featured games are immediately compelling. (explicit)

• Observable result: the hero rotates through featured games with all listed fields and both actions.
• Failure/recovery: a missing trailer disables “Watch Trailer” with a clear label.
• Continuation: “Explore Game” opens the game page.

FR-16 — Homepage sections. As a gamer, I should see Trending, Most Played, New Releases, Free Games, Multiplayer, Indie Spotlight, Coming Soon, Recommended, Editors' Choice, Developer Spotlight, Community, and Footer sections, so that I can browse by intent. (explicit)

• Observable result: all listed sections render with their content.
• Failure/recovery: a failed section shows an inline retry without breaking the page.
• Continuation: the gamer opens a game from any section.

FR-17 — Game cards. As a gamer, I should see cover, title, genre, rating, platforms, price/free label, wishlist, and a View Game button with hover effects on each game card, so that I can evaluate and act on a game at a glance. (explicit)

• Observable result: every card shows all listed fields and both controls.
• Failure/recovery: a missing cover falls back to a placeholder treatment.
• Continuation: View Game opens the game page; wishlist adds the game.

FR-18 — Game page. As a gamer, I should see banner, title/logo, rating, genre, developer, release date, platforms, price, Get Game, Wishlist, description, screenshots, authorized trailer, system requirements, reviews, similar games, and developer information at /game/:slug, so that I can fully evaluate a game. (explicit)

• Observable result: all listed elements render on the game page.
• Failure/recovery: an unknown slug shows a not-found state with a route back to Discover.
• Continuation: Get Game acquires the game or routes to the authorized store link; Wishlist saves it.

FR-19 — Discover. As a gamer, I should use backend-powered search, pagination, and filters at /discover for genre, platform, price, rating, release date, multiplayer, single-player, online/offline, free-to-play, indie, and early access, and sort by Popular, Newest, Rating, Reviews, and Price, so that I can narrow the catalog precisely. (explicit)

• Observable result: filters, sorting, and pagination are executed by the backend and reflected in the grid.
• Failure/recovery: a failed query shows an inline error with retry preserving the filter set.
• Continuation: the gamer opens a result.

FR-20 — Global search. As a gamer, I should search games, developers, categories, and users with autocomplete and search history, so that I can find anything quickly. (explicit)

• Observable result: grouped suggestions appear as I type and history is retained.
• Failure/recovery: suggestion failure falls back to plain query submission.
• Continuation: selecting a suggestion opens its destination.

FR-21 — Categories. As a gamer, I should browse Action, Adventure, RPG, Strategy, Racing, Sports, Simulation, Horror, Survival, Puzzle, Platformer, Fighting, Shooter, Casual, Multiplayer, MMO, Indie, Open World, and Story Rich, so that I can browse by genre. (explicit)

• Observable result: all listed categories are available for browsing.
• Failure/recovery: an empty category shows a quiet empty label.
• Continuation: the gamer opens a game.

FR-22 — Platforms. As a gamer, I should browse and filter by Windows, macOS, Linux, Android, iOS, and Web, so that I only see games for my platforms. (explicit)

• Observable result: all listed platforms are available as browse and filter values.
• Failure/recovery: an empty platform result shows a quiet empty label.
• Continuation: the gamer opens a game.

FR-23 — Profile. As a gamer, I should see avatar, username, bio, joined date, favourite games, library, wishlist, reviews, followers, following, and achievements on a profile, so that I can present and review my activity. (explicit)

• Observable result: all listed profile elements render.
• Failure/recovery: empty sections show quiet labels.
• Continuation: the gamer edits the profile or follows someone.

FR-24 — Profile editing and following. As a gamer, I should edit my profile and follow users and developers, so that my identity and relationships stay current. (explicit)

• Observable result: edits persist and follow relationships are recorded.
• Failure/recovery: a failed save preserves entered values and shows an inline error.
• Continuation: the gamer returns to the profile.

FR-25 — Library sections. As a gamer, I should organize games into Playing, Completed, Favourite, Recently Played, and Want to Play, so that my library reflects how I actually play. (explicit)

• Observable result: each game can be placed in a section and moved between sections.
• Failure/recovery: a failed move reverts the entry and shows an inline error.
• Continuation: the gamer opens the game or writes a review.

FR-26 — Wishlist. As a gamer, I should see artwork, price, offers, rating, platform, and release date for wishlisted games, so that I can decide when to buy. (explicit)

• Observable result: all listed fields render for each wishlist entry.
• Failure/recovery: a failed removal restores the item and shows an inline error.
• Continuation: the gamer opens the game or checks notifications.

FR-27 — Release and price notifications. As a gamer, I should receive notifications for releases and price changes, so that I do not miss a wishlisted game. (explicit)

• Observable result: release and price-change notifications appear in Notifications.
• Failure/recovery: a failed notification fetch shows retry.
• Continuation: the gamer opens the referenced game.

FR-28 — Reviews. As a gamer, I should rate 1–5 stars and write a review with title, text, recommendation, playtime, and a helpful button, so that I can share my assessment. (explicit)

• Observable result: the review is stored with all listed fields and appears on the game page.
• Failure/recovery: validation errors are shown per field; a failed submission preserves the draft.
• Continuation: the review appears in the game's review list.

FR-29 — Duplicate review prevention. As a platform operator, I should prevent duplicate reviews, so that ratings stay honest. (explicit)

• Trigger: a second review submission for the same game by the same user.
• Observable result: the duplicate is blocked and the existing review is surfaced.
• Failure/recovery: the block message explains why and links to the existing review.
• Continuation: the gamer may edit or view the existing review.

FR-30 — Community. As a gamer, I should create posts, comment, like, follow, share, view an activity feed, and receive notifications, so that I can connect with other players. (explicit)

• Observable result: posts, comments, likes, follows, shares, activity, and notifications are recorded and displayed.
• Failure/recovery: a failed post submission preserves the draft text.
• Continuation: the gamer continues in the feed.

FR-31 — Developer portal dashboard. As a developer, I should see games, views, wishlists, ratings, reviews, downloads, and revenue at /developer, so that I can measure my games. (explicit)

• Observable result: all listed metrics render.
• Failure/recovery: a failed metric block shows retry without breaking the rest.
• Continuation: the developer opens a game in Game Editor.

FR-32 — Game creation and media. As a developer, I should create games and upload cover, banner, screenshots, and trailer, and add description, genres, platforms, pricing, and system requirements, so that my game page is complete. (explicit)

• Observable result: the game record stores all listed fields and media.
• Failure/recovery: upload validation failures are surfaced per file and other fields are preserved.
• Continuation: the developer saves a draft or submits for review.

FR-33 — Publishing workflow. As a developer, I should move a game through Draft → Submitted → Review → Approved → Published, so that publication follows the accepted process. (explicit)

• Observable result: the game's state advances only through the accepted transitions.
• Failure/recovery: a rejected submission shows the reason and allows resubmission.
• Continuation: an approved game becomes Published.

FR-34 — Admin approval required. As an admin, I should be the only actor who can move a submitted game to Published, so that nothing publishes without approval. (explicit)

• Observable result: no game becomes Published without admin approval.
• Failure/recovery: an attempted bypass is denied.
• Continuation: the developer sees the approved state.

FR-35 — Admin panel. As an admin, I should see users, developers, games, reviews, reports, downloads, revenue, and pending submissions at /admin, so that I can operate the platform. (explicit)

• Observable result: all listed record categories render.
• Failure/recovery: a failed table shows retry.
• Continuation: the admin opens Admin Moderation or Reports.

FR-36 — Admin actions. As an admin, I should approve/reject games, suspend users/developers, remove reviews, manage categories, feature games, manage banners, and review reports, so that I can govern the marketplace. (explicit)

• Observable result: each action takes effect and is reflected in the affected records.
• Failure/recovery: a failed action leaves the record in its prior state and shows an error.
• Continuation: the admin continues moderating.

FR-37 — Authentication. As a user, I should register, log in, log out, use JWT access/refresh tokens, benefit from bcrypt password hashing, reset a forgotten password, verify my email, and be protected by protected routes and role-based authorization, so that my account is secure. (explicit)

• Observable result: all listed authentication capabilities work end to end.
• Failure/recovery: invalid credentials, expired tokens, and expired reset links each produce a clear recovery path.
• Continuation: the user reaches the intended protected destination.

FR-38 — No secret exposure. As a platform operator, I should never expose passwords, secrets, or private data, so that users are protected. (explicit)

• Observable result: no API response or client surface exposes passwords, secrets, or private data.
• Failure/recovery: an exposure is treated as a critical defect.
• Continuation: the platform continues to operate.

FR-39 — Prisma models. As a developer, I should define Prisma models for User, Developer, Game, Category, Genre, Platform, GameScreenshot, GameTrailer, Review, Wishlist, Library, Follow, Comment, Post, Notification, Report, DeveloperApplication, GameSubmission, Purchase, Order, Payment, Achievement, and UserAchievement with relationships, indexes, and migrations, so that the data layer matches the accepted schema. (explicit)

• Observable result: all listed models exist with relationships, indexes, and migrations.
• Failure/recovery: migration failures block deployment and are surfaced.
• Continuation: the API uses these models.

FR-40 — REST API. As a developer, I should provide APIs for authentication, games, search, wishlist, library, reviews, developers, admin, and health, including POST /api/auth/register, POST /api/auth/login, GET /api/auth/me, GET /api/games, GET /api/games/:slug, POST /api/games, PUT /api/games/:id, GET /api/search?q=, GET /api/wishlist, POST /api/wishlist/:gameId, GET /api/library, POST /api/library/:gameId, POST /api/games/:gameId/reviews, GET /api/games/:gameId/reviews, POST /api/developers/apply, GET /api/developers/dashboard, POST /api/developers/games, GET /api/admin/users, GET /api/admin/games, PUT /api/admin/games/:id/approve, and GET /api/health, so that all clients have a stable contract. (explicit)

• Observable result: every listed route exists and behaves per its purpose.
• Failure/recovery: validation and authorization failures return clear errors.
• Continuation: clients consume the API.

FR-41 — Recommendations. As a gamer, I should receive recommendations based on favourite genres, wishlist, library, ratings, recently viewed/played, popularity, and similar games, so that I discover games I will like. (explicit)

• Observable result: recommended games appear on Home and the game page's similar-games area.
• Failure/recovery: a failed recommendation fetch hides the rail rather than breaking the page.
• Continuation: the gamer opens a recommended game.

FR-42 — Future ML readiness. As a developer, I should keep the recommendation architecture ready for future ML recommendations, so that the model can be upgraded later without redesign. (explicit, future)

• Observable result: the recommendation layer is structured for a future ML model.
• Failure/recovery: not applicable in current scope.
• Continuation: future work replaces the current heuristic.

FR-43 — Mobile apps. As a gamer, I should use real React Native + Expo Android and iOS apps with bottom navigation Home | Discover | Library | Wishlist | Profile, plus search, game details, wishlist, library, reviews, profiles, push notifications, deep links, and sharing, so that mobile is a first-class experience. (explicit)

• Observable result: all listed mobile capabilities work in the native apps.
• Failure/recovery: a failed deep link falls back to the app home.
• Continuation: the gamer continues in the app.

FR-44 — Mobile configuration. As a developer, I should prepare app.json and eas.json, so that EAS builds and submissions work. (explicit)

• Observable result: both files exist and are valid for EAS.
• Failure/recovery: invalid configuration blocks the build and is surfaced.
• Continuation: builds proceed via EAS.

FR-45 — Media policy. As a platform operator, I should use fictional games and properly licensed assets and never copy copyrighted artwork, so that the platform is legally clean. (explicit)

• Observable result: all media is fictional or properly licensed.
• Failure/recovery: unlicensed media is rejected before publication.
• Continuation: compliant media is published.

FR-46 — Media types. As a gamer, I should see game covers, banners, screenshots, trailers, developer logos, avatars, and app icons, so that the catalog is visually complete. (explicit)

• Observable result: all listed media types are supported and rendered.
• Failure/recovery: missing media falls back to a placeholder treatment.
• Continuation: the gamer continues browsing.

FR-47 — Media delivery. As a gamer, I should benefit from lazy loading, optimized images, and CDN-ready storage, so that media loads fast. (explicit)

• Observable result: below-the-fold media is lazy loaded and served optimized from CDN-ready storage.
• Failure/recovery: a failed image load shows a placeholder.
• Continuation: the page remains usable.

FR-48 — Security. As a platform operator, I should implement Helmet, CORS, rate limiting, Zod validation, secure authentication, authorization, upload validation, request limits, and secure environment variables, so that the platform is hardened. (explicit)

• Observable result: all listed controls are active.
• Failure/recovery: a rejected request returns a clear error without leaking internals.
• Continuation: legitimate traffic proceeds.

FR-49 — Developer-only game file uploads. As a platform operator, I should allow only authorized developers to upload game files, so that uploaded content is trustworthy. (explicit)

• Observable result: non-authorized upload attempts are denied.
• Failure/recovery: the denial message explains the requirement and links to Developer Application.
• Continuation: an authorized developer uploads successfully.

FR-50 — Malware scanning integration point. As a platform operator, I should have a malware/security scanning integration point for uploaded files, so that scanning can be wired in. (explicit)

• Observable result: an integration point exists in the upload pipeline.
• Failure/recovery: a scan failure blocks publication of the affected file.
• Continuation: a clean file proceeds.

FR-51 — Payments architecture. As a gamer, I should be able to purchase legally sold games through orders, purchases, payment status, coupons, promotions, and purchase history, so that buying is straightforward. (explicit)

• Observable result: orders, purchases, payment status, coupons, promotions, and purchase history are recorded.
• Failure/recovery: a failed or declined payment leaves the order unpaid and allows retry.
• Continuation: a successful purchase appears in purchase history.

FR-52 — Authorized payment provider. As a platform operator, I should prepare integration with an authorized provider such as Razorpay, so that payments are processed legitimately. (explicit)

• Observable result: the payment integration targets an authorized provider.
• Failure/recovery: provider errors surface a clear message and allow retry.
• Continuation: successful payments complete the order.

FR-53 — No raw card storage. As a platform operator, I should never store raw card information, so that cardholders are protected. (explicit)

• Observable result: no raw card data is persisted anywhere in NEXORA.
• Failure/recovery: any attempt to persist raw card data is treated as a critical defect.
• Continuation: payment processing continues through the provider.

FR-54 — Demo data. As a developer, I should seed 50 fictional games, 15 developers, 10+ categories, 100 reviews, and 30 demo users, including the example games Neon Drift, Shadow Protocol, Void Runner, Kingdoms Beyond, Cyber Realm, Pixel Frontier, Dark Horizon, Astro Clash, Mystic Valley, and Velocity X, so that the platform is demonstrable. (explicit)

• Observable result: the seed produces exactly these counts and includes the named example games.
• Failure/recovery: a failed seed reports the failing step.
• Continuation: the seeded platform is browsable.

FR-55 — Responsive web. As a gamer, I should use NEXORA on mobile, tablet, laptop, desktop, and ultrawide screens with no horizontal overflow, so that the layout always fits. (explicit)

• Observable result: no horizontal overflow at any supported viewport.
• Failure/recovery: an overflow is treated as a defect.
• Continuation: the gamer continues browsing.

FR-56 — Performance. As a gamer, I should benefit from lazy loading, skeleton loaders, pagination, API caching, code splitting, optimized database queries, optimized images, and infinite scrolling where appropriate, so that the platform feels fast. (explicit)

• Observable result: all listed techniques are applied where appropriate.
• Failure/recovery: a slow query or image surfaces a loading state rather than a blank screen.
• Continuation: content resolves.

FR-57 — SEO. As a platform operator, I should provide metadata, Open Graph, social cards, sitemap, robots.txt, canonical URLs, and structured data, so that NEXORA is discoverable and shareable. (explicit)

• Observable result: all listed SEO artifacts exist and are correct.
• Failure/recovery: a missing artifact is treated as a defect.
• Continuation: crawlers and social platforms index the site.

FR-58 — Project structure. As a developer, I should use nexora/apps/web, nexora/apps/mobile, nexora/apps/api, nexora/packages/ui, nexora/packages/types, nexora/packages/utils, nexora/prisma, .env.example, docker-compose.yml, and README.md, so that the repository matches the accepted layout. (explicit)

• Observable result: all listed paths exist.
• Failure/recovery: a missing path is treated as a defect.
• Continuation: development proceeds in the accepted structure.

FR-59 — Deployment. As a platform operator, I should deploy production-ready with web on Vercel/Cloudflare or equivalent, backend on Railway/Render/Fly/AWS or equivalent, managed PostgreSQL, S3-compatible storage, and mobile via Expo EAS, so that NEXORA can run in production. (explicit)

• Observable result: the deployment targets are configured as listed.
• Failure/recovery: a failed deployment surfaces the failing step.
• Continuation: the deployed product is reachable.

FR-60 — No false liveness claims. As a platform operator, I should not claim the product is live unless it is actually deployed; if deployment is available I should deploy it and provide the real URLs, otherwise I should provide exact deployment instructions. (explicit)

• Observable result: either real deployed URLs or exact deployment instructions are provided, never a false liveness claim.
• Failure/recovery: an unverified claim is corrected.
• Continuation: the operator follows the provided instructions.

FR-61 — End-to-end testing. As a developer, I should test the complete flow Register → Login → Search → View Game → Wishlist → Library → Review → Developer Registration → Submit Game → Admin Approval → Published Game, so that the core journey works. (explicit)

• Observable result: the full flow passes end to end.
• Failure/recovery: a failing step is fixed before release.
• Continuation: the flow completes with a Published game.

FR-62 — Defect cleanup. As a developer, I should fix all broken imports, TypeScript errors, console errors, API errors, authentication problems, and responsive issues, so that the product is clean. (explicit)

• Observable result: none of the listed defect classes remain.
• Failure/recovery: a discovered defect is fixed and re-verified.
• Continuation: the product ships clean.

FR-63 — Build order. As a developer, I should build in the order Database → Backend → Authentication → Web UI → Game Marketplace → Search → Wishlist/Library → Community → Developer Portal → Admin Panel → Mobile Apps → Testing → Deployment, so that dependencies are respected. (explicit)

• Observable result: the build proceeds in the accepted order.
• Failure/recovery: a blocked stage is resolved before proceeding.
• Continuation: the next stage begins.

FR-64 — Handover documentation. As a platform operator, I should receive setup commands, environment variables, database setup, demo credentials, API documentation, web commands, Android/iOS build commands, and deployment instructions, so that the project can be run and shipped. (explicit)

• Observable result: all listed documentation is provided.
• Failure/recovery: a missing item is supplied.
• Continuation: the operator runs and deploys the project.

FR-65 — Sign Up. As a gamer, I should create an account through Sign Up, so that I can build durable wishlist, library, review, and community state. (required_inference)

• Trigger: selecting Sign Up.
• Observable result: an account is created and email verification is prompted.
• Failure/recovery: validation errors are shown per field and entered values are preserved.
• Continuation: the gamer verifies email and logs in.

FR-66 — Login. As any persona, I should log in to resume my protected work, so that my state stays bound to me. (required_inference)

• Trigger: selecting Login.
• Observable result: a session is established and the intended destination opens.
• Failure/recovery: invalid credentials show a non-revealing error and a path to Account Recovery.
• Continuation: the persona continues their work.

FR-67 — Account Recovery. As any persona, I should reset a forgotten password, so that I can regain access. (required_inference)

• Trigger: selecting Forgot password.
• Observable result: a reset link is sent and a new password can be set.
• Failure/recovery: an expired or invalid token offers a fresh request.
• Continuation: the persona logs in with the new password.

FR-68 — Email Verification. As any persona, I should verify my email, so that my account is trusted. (required_inference)

• Trigger: opening the verification link.
• Observable result: the account is marked verified.
• Failure/recovery: an expired token offers a resend.
• Continuation: the persona logs in.

FR-69 — Developer Application. As a gamer, I should apply for developer access, so that I can publish games. (required_inference)

• Trigger: submitting a Developer Application.
• Observable result: the application is recorded and its status is visible.
• Failure/recovery: a rejected application shows the decision and allows resubmission.
• Continuation: an approved applicant gains authorized developer access.

FR-70 — Authorized developer gate. As a platform operator, I should require authorized developer status before developer-only upload and publishing workflows, so that only vetted developers publish. (required_inference)

• Trigger: accessing /developer, Game Editor, or Submissions without authorized developer status.
• Observable result: access is denied and the Developer Application path is offered.
• Failure/recovery: the denial is clear and non-revealing.
• Continuation: the user applies or returns to browsing.

FR-71 — Admin approval gate. As a platform operator, I should require admin approval before a submitted game becomes Published, so that nothing publishes unreviewed. (required_inference)

• Trigger: a game in Submitted or Review state.
• Observable result: the game remains unpublished until an admin approves it.
• Failure/recovery: a rejection returns the game to the developer with a reason.
• Continuation: the developer resubmits or the game publishes.

FR-72 — Authorized external store links. As a gamer, I should be routed to authorized external store/download links for third-party games, so that acquisition is legitimate. (required_inference)

• Trigger: selecting Get Game on a third-party game.
• Observable result: the official authorized store/download link opens.
• Failure/recovery: an unavailable link shows an error with a route back.
• Continuation: the gamer returns to NEXORA.

FR-73 — Authorized payment processing. As a gamer, I should have my payment processed by an authorized provider, so that my purchase is legitimate and my card data is safe. (required_inference)

• Trigger: completing a purchase for a legally sold game.
• Observable result: the provider processes the payment and NEXORA records the order and payment status.
• Failure/recovery: a declined payment leaves the order unpaid and allows retry.
• Continuation: a successful purchase appears in purchase history.

FR-74 — Backend persistence and authorization. As a developer, I should persist protected durable workflows with validation, authorization, and migrations, so that state is correct and access is enforced. (required_inference)

• Trigger: any protected write.
• Observable result: the write is validated, authorized, and persisted.
• Failure/recovery: a validation or authorization failure returns a clear error and no partial write.
• Continuation: the client retries or corrects the input.

4. User Personas

Gamer/User

A player who arrives to find something worth playing and to stay connected to the games and people they care about. Their product context is the discovery loop: browse Home rails, filter in Discover, land on a game page, and decide. Their primary goal is to discover games, track them, and engage with the community.

Distinct accepted responsibilities: browsing and searching the catalog; viewing game pages; adding games to Wishlist; organizing games into Library sections Playing, Completed, Favourite, Recently Played, and Want to Play; writing 1–5 star reviews with title, text, recommendation, and playtime, and marking reviews helpful; following users and developers; creating posts, commenting, liking, sharing, and reading the activity feed; receiving release and price-change notifications; editing their profile; and purchasing legally sold games.

Relevant inputs and decisions: which filters to apply, which game to open, whether to wishlist or add to library, what rating and recommendation to give, whom to follow, and whether to buy now or wait for a price change.

Interactions with other accepted participants: they read developer information on game pages, follow developers, see developer-published games, and interact with other gamers through posts, comments, likes, and follows. They are the audience for moderator and admin decisions that remove content or suspend accounts.

Observable success: a populated wishlist and library, published reviews on game pages, a following/followers list, community activity, and notifications for the games they track.

Developer

An independent game maker who has been authorized to publish on NEXORA. Their product context is the developer portal: a dashboard of metrics and a game editor that produces submissions for admin review. Their primary goal is to publish games and measure how they perform.

Distinct accepted responsibilities: applying for developer access; tracking games, views, wishlists, ratings, reviews, downloads, and revenue on the dashboard; creating games with cover, banner, screenshots, trailer, description, genres, platforms, pricing, and system requirements; moving games through Draft → Submitted → Review → Approved → Published; and uploading game files as an authorized developer.

Relevant inputs and decisions: what media and metadata to provide, what price to set, when to submit for review, and how to respond to a rejection.

Interactions with other accepted participants: they depend on admin approval before publication, they see gamer reviews and wishlist activity in their metrics, and their public developer information appears on game pages where gamers can follow them.

Observable success: a Published game, growing views, wishlists, ratings, reviews, downloads, and revenue, and a clean submission history.

Moderator

A community safety operator. Their product context is the moderation workspace inside the admin surfaces, focused on reviews and reports. Their primary goal is to keep the platform safe by acting on reported content.

Distinct accepted responsibilities: reviewing community content and reports; removing reviews; and handling reported posts and comments.

Relevant inputs and decisions: which reports are valid, whether content violates platform rules, and whether to remove content or dismiss a report.

Interactions with other accepted participants: they act on content created by gamers and developers, and they work alongside admins who own the broader platform controls.

Observable success: a cleared report queue, removed violating content, and a community feed that stays usable.

Admin

The platform operator. Their product context is the admin panel and moderation surfaces, working in dense tables with tabular numerals. Their primary goal is to operate the marketplace and keep it lawful and healthy.

Distinct accepted responsibilities: overseeing users, developers, games, reviews, reports, downloads, revenue, and pending submissions; approving or rejecting games; suspending users and developers; removing reviews; managing categories; featuring games; managing banners; and reviewing reports. Admin approval is required before a submitted game is published.

Relevant inputs and decisions: whether a submission meets platform standards, whether an account should be suspended, which games to feature, which banners to run, and how to resolve reports.

Interactions with other accepted participants: they gate developer publication, they act on gamer and developer accounts and content, and they share the reports workspace with moderators.

Observable success: a short pending-submission queue, a resolved report queue, a curated featured set, and a marketplace with no pirated or cracked content.

5. Core User Flows

Flow 1 — Gamer discovers and evaluates a game

1. The gamer opens NEXORA and lands on Home. The cinematic hero carousel shows a featured game with artwork, title, genre, rating, platforms, and description.
2. The gamer selects a carousel tick to cross-fade to another featured game, or scrolls a rail (Trending, Most Played, New Releases, Free Games, Multiplayer, Indie Spotlight, Coming Soon, Recommended, Editors' Choice, Developer Spotlight, Community).
3. The gamer selects View Game on a game card, opening /game/:slug.
4. On the game page the gamer reads the banner, title/logo, rating, genre, developer, release date, platforms, price, description, screenshots, authorized trailer, system requirements, reviews, similar games, and developer information.
5. The gamer selects Watch Trailer to view the authorized trailer, or opens a screenshot.
6. The gamer selects a similar game to continue exploring, or returns to Discover.
7. Result: the gamer has evaluated the game and can act on it.
8. Failure/recovery: if the slug is unknown, a not-found state appears with a route back to Discover; if the trailer is unavailable, the control is disabled with a clear label.

Flow 2 — Gamer filters the catalog in Discover

1. The gamer opens Discover.
2. The gamer applies filters in the 280px sticky filter rail: genre, platform, price, rating, release date, multiplayer, single-player, online/offline, free-to-play, indie, and early access.
3. The gamer selects a sort: Popular, Newest, Rating, Reviews, or Price.
4. The result grid re-flows with staggered card entrances and the live result count updates in tabular numerals.
5. The gamer paginates or infinite-scrolls to see more results.
6. Result: the gamer has a narrowed result set.
7. Failure/recovery: a failed query shows an inline error with retry that preserves the filter set; an empty result set offers a clear-filters action.
8. Continuation: the gamer opens a result or adjusts filters.

Flow 3 — Gamer searches globally

1. The gamer opens Search from the navbar.
2. The gamer types a query; grouped autocomplete suggestions appear for games, developers, categories, and users.
3. The gamer selects a suggestion, or submits the raw query.
4. The gamer's search history is retained and can be cleared.
5. Result: the gamer reaches the intended game, developer, category, or user.
6. Failure/recovery: if suggestions fail, plain query submission still works.
7. Continuation: the gamer opens a result.

Flow 4 — Gamer creates an account and verifies email

1. The gamer selects Sign Up.
2. The gamer completes the registration form; per-field validation runs.
3. On success, the gamer is prompted to verify email and lands on Email Verification.
4. The gamer opens the verification link; the account is marked verified.
5. The gamer proceeds to Login and signs in.
6. Result: an established identity with access to protected surfaces.
7. Failure/recovery: an expired verification token offers a resend; a duplicate account shows a clear message without revealing private data.
8. Continuation: the gamer returns to the game they were viewing.

Flow 5 — Gamer logs in and recovers a forgotten password

1. The gamer opens Login and submits credentials.
2. On success, the session is established and the previously intended destination opens.
3. If the gamer has forgotten the password, they open Account Recovery, request a reset, and set a new password from the link.
4. The gamer returns to Login and signs in with the new password.
5. Result: access restored.
6. Failure/recovery: invalid credentials show a non-revealing error; an expired reset token offers a fresh request.

Flow 6 — Gamer wishlists a game and receives price/release notifications

1. From a game card or the game page, the gamer selects Wishlist.
2. The game appears in Wishlist with artwork, price, offers, rating, platform, and release date.
3. When the game's price changes or it releases, a notification appears in Notifications.
4. The gamer opens the notification and lands on the game page.
5. Result: the gamer is informed and can act.
6. Failure/recovery: a failed removal restores the item and shows an inline error.
7. Continuation: the gamer selects Get Game.

Flow 7 — Gamer acquires a game

1. On /game/:slug, the gamer selects Get Game in the sticky glass purchase panel.
2. For a third-party game, NEXORA routes the gamer to the official authorized store/download link.
3. For a legally sold game, the gamer proceeds through Purchases, applies a coupon or promotion if available, and completes payment through the authorized provider such as Razorpay.
4. The order, purchase, and payment status are recorded; the purchase appears in purchase history.
5. Result: the gamer owns the game and can add it to Library.
6. Failure/recovery: a declined or failed payment leaves the order unpaid and allows retry; raw card information is never stored.
7. Continuation: the gamer organizes the game in Library.

Flow 8 — Gamer organizes the library

1. The gamer opens Library.
2. The gamer moves a game into Playing, Completed, Favourite, Recently Played, or Want to Play.
3. The game appears in the selected section.
4. Result: the library reflects how the gamer plays.
5. Failure/recovery: a failed move reverts the entry and shows an inline error.
6. Continuation: the gamer opens the game or writes a review.

Flow 9 — Gamer writes a review

1. From the game page or a library entry, the gamer opens Reviews.
2. The gamer selects a 1–5 star rating and enters a title, text, recommendation, and playtime.
3. The gamer submits the review.
4. The review appears on the game page's review list.
5. Another gamer marks the review helpful.
6. Result: the review is published with all listed fields.
7. Failure/recovery: per-field validation errors are shown and the draft is preserved; a duplicate review for the same game is blocked and the existing review is surfaced.
8. Continuation: the gamer returns to the game page.

Flow 10 — Gamer participates in the community

1. The gamer opens Community.
2. The gamer creates a post, or comments on, likes, shares, or reports an existing post.
3. The gamer follows another user or a developer.
4. The activity feed and Notifications reflect the new activity.
5. Result: the gamer's participation is recorded and visible.
6. Failure/recovery: a failed post submission preserves the draft text.
7. Continuation: the gamer continues in the feed.

Flow 11 — Gamer edits profile and follows

1. The gamer opens Profile and sees avatar, username, bio, joined date, favourite games, library, wishlist, reviews, followers, following, and achievements.
2. The gamer edits profile details and saves.
3. The gamer follows a user or a developer.
4. Result: the profile and relationships are updated.
5. Failure/recovery: a failed save preserves entered values and shows an inline error.
6. Continuation: the gamer returns to browsing.

Flow 12 — Gamer applies to become a developer

1. The gamer opens Developer Application.
2. The gamer completes and submits the application.
3. The application status is visible on the page.
4. Result: the application is recorded for review.
5. Failure/recovery: per-field validation errors are shown; a rejected application shows the decision and allows resubmission.
6. Continuation: on approval, the gamer gains authorized developer access.

Flow 13 — Developer creates a game and submits it

1. The authorized developer opens /developer and reviews games, views, wishlists, ratings, reviews, downloads, and revenue.
2. The developer opens Game Editor and creates a game, uploading cover, banner, screenshots, and trailer, and adding description, genres, platforms, pricing, and system requirements.
3. The developer saves the game as a Draft.
4. The developer opens Submissions and submits the draft; the state becomes Submitted, then Review.
5. Result: the game is queued for admin approval.
6. Failure/recovery: upload validation failures are surfaced per file and other entered fields are preserved; a rejected submission shows the reason and allows resubmission.
7. Continuation: the developer waits for the admin decision.

Flow 14 — Admin approves a submitted game

1. The admin opens /admin and sees users, developers, games, reviews, reports, downloads, revenue, and pending submissions.
2. The admin opens Admin Moderation and reviews a pending submission.
3. The admin approves the game; the state becomes Approved, then Published.
4. The game appears in the catalog and on Home rails.
5. Result: the game is live and the developer sees the approved state.
6. Failure/recovery: a failed approval leaves the submission in its prior state and shows an error; a rejection returns the game to the developer with a reason.
7. Continuation: the developer monitors metrics on /developer.

Flow 15 — Moderator handles a report

1. The moderator opens Reports and sees reported community content with reporter, reason, and status.
2. The moderator opens the reported post, comment, or review.
3. The moderator removes the violating review or content, or dismisses the report.
4. Result: the report is resolved and removed from the open queue.
5. Failure/recovery: a failed resolution keeps the report open and shows an error.
6. Continuation: the moderator continues through the queue.

Flow 16 — Admin governs the marketplace

1. The admin opens Admin Moderation.
2. The admin suspends a user or developer, removes a review, manages categories, features a game, or manages banners.
3. Each action takes effect and is reflected in the affected records.
4. Result: the marketplace reflects the admin's decisions.
5. Failure/recovery: a failed action leaves the record in its prior state and shows an error.
6. Continuation: the admin returns to /admin.

Flow 17 — Mobile gamer uses the native apps

1. The gamer opens the NEXORA Android or iOS app and lands on Home via bottom navigation Home | Discover | Library | Wishlist | Profile.
2. The gamer searches, opens game details, wishlists a game, organizes the library, writes a review, and views profiles.
3. The gamer receives a push notification for a release or price change and opens it through a deep link.
4. The gamer shares a game or post.
5. Result: the same accepted capabilities work natively on mobile.
6. Failure/recovery: a failed deep link falls back to the app home.
7. Continuation: the gamer continues in the app.

Flow 18 — End-to-end acceptance test

1. Register → Login → Search → View Game → Wishlist → Library → Review → Developer Registration → Submit Game → Admin Approval → Published Game.
2. Each step is executed against the running stack.
3. Result: the flow completes with a Published game.
4. Failure/recovery: any broken import, TypeScript error, console error, API error, authentication problem, or responsive issue found during the run is fixed and re-verified.

6. Visuals Colors and Theme

Muse: Gleb Kuznetsov. Headline: a dark void where the game itself is the light source.

The register is premium-futuristic, high-energy, and slightly awe-inducing: dark, luminous, motion-first. The emotional goal is “this is where the next game I love is waiting.” The same world stays legible and calm enough for developers in the portal and moderators and admins in dense tables.

Palette (dark mode)

The ground is a near-black void with a faint indigo cast (#05060E), never pure #000. Glass panels are #0D1024 at 55–70% opacity with a 1px rgba(255,255,255,0.08) top light edge and a 24px backdrop blur; they sit as floating layers, never as flat cards. Cyan #00E5FF is the system light — focus rings, active nav rail, progress bars, rating stars, primary CTA fill on hover. Magenta #FF2E97 is the hot accent used sparingly and only for desire: “Free,” discount badges, the wishlist heart when active, live-now dots, and the second stop of every gradient. Violet #7A5CFF appears only inside glows and gradient midpoints, never as flat UI fill. Body text #EAF0FF at 92% opacity for paragraphs; #8A93C4 for metadata and labels. Contrast: #EAF0FF on #05060E is >15:1; cyan on near-black is >11:1; magenta is used for text only at 18px+ semibold or larger. Proportion: 70% void, 20% glass surface, 8% cyan, 2% magenta.

Typography

• Headings: Space Grotesk 500–700, uppercase for section eyebrows and card eyebrows with 0.14em tracking, tight −0.02em tracking and 0.95 line-height at display sizes so multi-line game titles stack as a block.
• Body: Sora 400 at 16–17px with 1.65 line-height — geometric enough to feel engineered, humanist enough to read 300-word reviews.
• Numerals: tabular everywhere (ratings, prices, playtime, dashboard metrics) via font-variant-numeric: tabular-nums.
• Micro-labels, filters, and HUD chips: Sora 600 uppercase 11px at 0.18em tracking.
• Scale: 1.25 modular on a 4px baseline. Display 40/56/88/120 (clamp), H1 32/44/64, H2 24/32/40, H3 20/24/28, body 15/16/17, meta 12/13/14, micro 11. Mobile display floor is 40px; desktop hero ceiling is 120px. Never smaller than 11px anywhere.

Shape language

Engineered softness inside a dark void. Cards are 20px radius on desktop, 16px on mobile, with a 1px luminous top edge and a 1px rgba(0,0,0,0.6) bottom edge so each panel reads as a lit physical slab. Buttons are 12px radius (not pills — pills read too friendly for this register); the primary CTA is a cyan fill with a 1px cyan glow at 0 0 24px rgba(0,229,255,0.35). Chips and filter tokens are 8px radius with hairline borders. Game covers keep a 16px radius with a 1px inner hairline and a bottom gradient scrim so titles stay readable over any artwork. Dividers are 1px rgba(255,255,255,0.06). Nothing is fully circular except avatars, platform dots, and the notification badge.

Layout

A 12-column grid on a 1440 max-width container with 24px gutters (16px at 375px), but the hero breaks the grid entirely: full-bleed to the viewport edges with content locked to a 6-column left block. The homepage is a vertical sequence of horizontal rails — each section (Trending, Most Played, New Releases, Free Games, Multiplayer, Indie Spotlight, Coming Soon, Recommended, Editors' Choice) is a horizontally scrollable row of 200px-wide (mobile) to 280px-wide (desktop) cover cards with a snap point and a fade mask at both edges. Magenta/cyan gradient hairlines separate rails instead of whitespace. Discover is the opposite: a strict two-column shell — a 280px sticky filter rail on the left (glass panel, scrolls independently) and a 3/4-up responsive card grid on the right with a sticky sort bar. The game page is a full-bleed banner hero, then a two-column body: 8 columns of description/screenshots/reviews, 4 columns of a sticky glass purchase panel with price, Get Game, Wishlist, and platform icons. Developer and admin consoles keep the same dark glass language but compress to a 240px left nav rail plus dense data tables with 40px rows and tabular numerals — no light-mode escape hatch.

Imagery

Fictional, self-generated game artwork only — abstract 3D key art: volumetric nebulae, low-poly terrain, chrome ship hulls, neon city canyons, particle storms, glass shards. Every cover is a 3:4 composition with a strong single light source and a deep black surround so it sits naturally in the void. Banners are 21:9 cinematic crops with a subject pushed to the right third and negative space on the left where the title block lands. Screenshots are in-engine-style renders at 16:9. Developer logos are geometric monograms in cyan/magenta on transparent. Avatars are procedural gradient orbs with an initial, never stock photos of people. All imagery is served from S3-compatible storage with a CDN, WebP/AVIF, srcset at 320/640/960/1280, and lazy loading below the fold. No real copyrighted game art, ever.

Avoid: any blue–indigo primary (#2563EB, #4F46E5, #6366F1, #7C3AED) on white; Inter, Roboto, Arial, Helvetica, Poppins, or system-ui as heading or body fonts; a centred hero with headline + subtext + button over a gradient blob; a uniform grid of identical hover-lift cards with the same shadow on every section; light-mode dashboards or white admin panels; real copyrighted game artwork, logos, screenshots, or trailers; flat, unstyled rails that wrap instead of scrolling; any horizontal page overflow at 375px; full-saturation magenta used as a large background fill.

7. Signature Design Concept

The Lit Slab in the Void — the NEXORA first screen.

The first screen is a full-bleed cinematic scene, not a centred headline stack. A 21:9 fictional game key art fills the viewport edge to edge, darkened by a 55% black gradient from the left and a 30% vignette; the artwork drifts on a slow parallax loop. Locked to the left 6 of 12 columns sits the content block, bottom-aligned to the viewport:

• an 11px cyan uppercase eyebrow with the genre and rating (ACTION RPG · 4.8 ★ · 12.4K REVIEWS),
• the game title in Space Grotesk 700 at clamp(40px, 9vw, 120px) with −0.03em tracking and 0.95 line-height, wrapping to at most two lines,
• a 60-word description capped at 46ch in #EAF0FF at 92%,
• a row of platform dots (Windows, macOS, Android, iOS, Web) as 28px glass circles with hairline borders,
• two buttons: a cyan-filled Explore Game with a 24px cyan glow, and a transparent Watch Trailer with a 1px cyan border and a play glyph.

A vertical stack of 5 carousel ticks sits at the far right edge, the active one a 24px cyan bar, the rest 1px hairlines — selecting any tick cross-fades the whole scene over 700ms. A thin cyan hairline runs along the very bottom of the hero, and a “Scroll” micro-label with a 12px cyan chevron sits bottom-centre. On mobile the artwork crops to 4:5 with the subject pushed to the top third and the content block sits below it in the void, title at 40px, buttons full-width stacked — nothing is ever covered or clipped.

The signature moves that carry the concept through the product:

• Every rail (Trending, Most Played, New Releases, Free Games, Multiplayer, Indie Spotlight, Coming Soon, Recommended, Editors' Choice) is a horizontally scrollable, snap-aligned row of 3:4 cover cards with fade masks at both edges and a cyan/magenta gradient hairline above it instead of a section heading rule.
• The game card is a lit slab: 20px radius, 1px luminous top edge, cover cross-fading to a second screenshot on hover, a 6px lift, a magenta wishlist heart that pops and holds, and a View Game bar that slides up from the bottom edge of the card over 300ms.
• The sticky glass purchase panel on /game/:slug — 4 columns wide, 24px backdrop blur, price in tabular numerals at 40px, cyan Get Game button with a 24px glow, and a platform-dot row — stays pinned as the description, screenshots, system requirements, and reviews scroll past it.
• The Discover filter rail is a 280px independently scrolling glass column with cyan hairline checkboxes and a live result count in tabular numerals, while the grid on the right re-flows 1/2/3/4-up with staggered 60ms card entrances on every filter change.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the full-bleed 21:9 fictional game key art of the active hero slide, with the game title block bottom-left in Space Grotesk 700.
• Input → transformation → outcome thesis: as the visitor moves the pointer across the hero, the scene tilts up to 4deg toward the pointer while the background artwork drifts 12px on a 20s loop and the foreground title stays fixed; selecting a right-edge tick cross-fades the entire scene over 700ms to the next featured game, updating artwork, title, genre, rating, platforms, and description together. The outcome is a hero that reads as a living game world rather than a static banner, using only accepted hero content and controls.
• Motion vocabulary: one continuous slow parallax; a 4deg pointer tilt; a 700ms cross-fade between slides; a 200ms cyan underline wipe for the active nav state; a 240ms route fade with a 1px cyan progress hairline at the top of the viewport; scroll-driven card reveals with a 24px rise and 0→1 opacity over 480ms cubic-bezier(0.22,1,0.36,1), staggered 60ms per index and capped at 8 items; a 6px card hover lift with a 300ms cover cross-fade; a magenta wishlist heart that pops and holds.
• Composed first frame: the 21:9 key art fills the viewport edge to edge, darkened by a 55% black gradient from the left and a 30% vignette; the content block sits bottom-left in the left 6 of 12 columns with the cyan eyebrow, the large title, the 46ch description, the platform-dot row, and the two buttons; the 5-tick rail sits at the far right edge with the active tick as a 24px cyan bar; the cyan hairline runs along the bottom of the hero with the “Scroll” micro-label and chevron bottom-centre.
• Reduced-motion state: under prefers-reduced-motion, the parallax loop, pointer tilt, and staggered reveals collapse to instant opacity-only states; the hero shows a single static slide with the tick rail still selectable; rails stop auto-motion and become horizontally scrollable rows (overflow-x: auto) whose items wrap or scroll into full view, so every item remains fully readable.

9. Non-Functional Requirements

NFR-1 — Security controls. Helmet, CORS, rate limiting, Zod validation, secure authentication, authorization, upload validation, request limits, and secure environment variables must all be active. (explicit) Rationale: the platform handles accounts, uploads, and payments.

NFR-2 — Secret and private-data protection. Passwords, secrets, and private data must never be exposed. (explicit) Rationale: explicit hard constraint.

NFR-3 — Card data protection. Raw card information must never be stored. (explicit) Rationale: explicit hard constraint; payment processing is delegated to an authorized provider.

NFR-4 — Upload authorization. Only authorized developers can upload game files. (explicit) Rationale: explicit hard constraint.

NFR-5 — Malware scanning integration point. A malware/security scanning integration point must exist in the upload pipeline. (explicit) Rationale: explicit requirement for uploaded file safety.

NFR-6 — Responsive web. The web app must support mobile, tablet, laptop, desktop, and ultrawide screens with no horizontal overflow. (explicit) Rationale: explicit requirement.

NFR-7 — Performance techniques. Lazy loading, skeleton loaders, pagination, API caching, code splitting, optimized database queries, optimized images, and infinite scrolling where appropriate must be applied. (explicit) Rationale: explicit requirement.

NFR-8 — SEO artifacts. Metadata, Open Graph, social cards, sitemap, robots.txt, canonical URLs, and structured data must be present. (explicit) Rationale: explicit requirement.

NFR-9 — Media licensing. Only fictional games and properly licensed assets may be used; copyrighted artwork must not be copied. (explicit) Rationale: explicit hard constraint.

NFR-10 — Media delivery. Media must be served from S3-compatible CDN-ready storage with lazy loading and optimized images. (explicit) Rationale: explicit requirement.

NFR-11 — Data integrity. Prisma models must define relationships, indexes, and migrations. (explicit) Rationale: explicit requirement.

NFR-12 — Deployment readiness. The product must be production-ready with the accepted deployment targets, and must not be claimed live unless actually deployed. (explicit) Rationale: explicit hard constraint.

NFR-13 — Defect-free build. Broken imports, TypeScript errors, console errors, API errors, authentication problems, and responsive issues must be fixed. (explicit) Rationale: explicit requirement.

NFR-14 — Recommendation extensibility. The recommendation architecture must remain ready for future ML recommendations. (explicit, future) Rationale: explicit future requirement.

NFR-15 — Access continuity. Protected durable state must remain bound to the correct participant across sessions and devices. (required_inference) Rationale: indispensable for wishlist, library, reviews, submissions, and administrative decisions to be trustworthy.

NFR-16 — Readable content at every viewport. Headlines, wordmarks, labels, numbers, item images, cards, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering them. Crops, bleeds, and off-edge placement are for decoration only. Moving and scrollable content may cross the viewport edge by design, judged by whether it actually moves and whether every item becomes fully readable as it passes; with prefers-reduced-motion it stops and shows whole items. (explicit, from creative direction) Rationale: explicit readability rule that takes precedence over crop or bleed gestures.

10. Tech Stack

Web (nexora/apps/web): React, Vite, TypeScript, Tailwind CSS, React Router, TanStack Query, Axios, Framer Motion, Lucide. (explicit)

Mobile (nexora/apps/mobile): React Native + Expo, TypeScript, Expo Router, NativeWind; real Android/iOS apps, not a WebView; app.json and eas.json prepared for EAS. (explicit)

Backend (nexora/apps/api): Node.js, Express, TypeScript, REST API, JWT access/refresh tokens, bcrypt, Zod, Helmet, CORS, rate limiting. (explicit)

Database: PostgreSQL with Prisma (models, relationships, indexes, migrations). (explicit)

Storage: S3-compatible storage for images, videos, and authorized game files, CDN-ready. (explicit)

Shared packages: nexora/packages/ui, nexora/packages/types, nexora/packages/utils. (explicit)

Repository root: nexora/prisma, .env.example, docker-compose.yml, README.md. (explicit)

Payments: integration prepared with an authorized provider such as Razorpay; raw card information is never stored. (explicit)

Deployment: web on Vercel/Cloudflare or equivalent; backend on Railway/Render/Fly/AWS or equivalent; managed PostgreSQL; S3-compatible storage; mobile via Expo EAS. (explicit)

Testing: end-to-end verification of Register → Login → Search → View Game → Wishlist → Library → Review → Developer Registration → Submit Game → Admin Approval → Published Game. (explicit)

11. Assumptions and Constraints

Constraints (binding)

• Do not host or distribute pirated or cracked copyrighted games. (explicit)
• For third-party games, use official authorized store/download links. (explicit)
• Allow game uploads only for authorized developers or open-source games. (explicit)
• Only authorized developers can upload game files. (explicit)
• Never expose passwords, secrets, or private data. (explicit)
• Never store raw card information. (explicit)
• Do not copy copyrighted artwork; use fictional games and properly licensed assets. (explicit)
• Admin approval is required before a submitted game is published. (explicit)
• Prevent duplicate reviews. (explicit)
• Do not claim the product is live unless actually deployed. (explicit)
• Verify name/domain/app-store availability before launch. (explicit)
• No horizontal overflow across mobile, tablet, laptop, desktop, and ultrawide screens. (explicit)
• Mobile apps must be real React Native + Expo apps, not a WebView. (explicit)

Assumptions (narrow, labeled)

• [Assumption] Browsing surfaces — Home, Discover, Games, Categories, Free Games, Upcoming, Search, and /game/:slug — are publicly reachable without an account, because discovery is the product's front door and no source states otherwise.
• [Assumption] Durable actor-specific state (wishlist, library, reviews, profile, notifications, purchases, community participation, developer portal, admin operations) requires an established application identity so that state remains bound to the correct participant. (required_inference)
• [Assumption] Developer-only and admin-only surfaces are protected by role-based authorization; the Developer Application flow is the accepted path to authorized developer status. (required_inference)
• [Assumption] Payment processing is performed by an authorized external provider such as Razorpay; NEXORA owns order, purchase, payment-status, coupon, promotion, and purchase-history records only. (required_inference)
• [Assumption] Malware/security scanning of uploaded game files is an external integration point; NEXORA owns the integration point, not the scanner. (explicit)
• [Assumption] For third-party games, acquisition is owned by the official authorized store/download destination, not by NEXORA. (explicit)
• [Assumption] ML-based recommendations are a future horizon; current recommendations use favourite genres, wishlist, library, ratings, recently viewed/played, popularity, and similar games. (explicit)
• [Default — not specified by user] Exact seed values for the 50 fictional games beyond the ten named examples, the 15 developer identities, the 10+ categories beyond the listed taxonomy, the 100 reviews, and the 30 demo users are generated as fictional, licensed content consistent with the media policy.
• [Default — not specified by user] Exact copy for legal pages, terms, and privacy text is not specified and is out of current scope beyond the stated constraints.

12. Glossary

• NEXORA — The gaming platform defined by this document, tagline “Discover. Play. Connect.”
• Gamer/User — The player persona who discovers, tracks, reviews, and discusses games.
• Developer — An authorized game maker who publishes games and reads dashboard metrics.
• Moderator — A community safety operator who handles reviews and reports.
• Admin — The platform operator who approves games, suspends accounts, manages categories, features games, manages banners, and reviews reports.
• Draft → Submitted → Review → Approved → Published — The accepted publishing workflow; admin approval is required before Published.
• Developer Application — The accepted path by which a gamer becomes an authorized developer.
• Authorized developer — A developer whose application has been approved and who may upload game files and publish games.
• Authorized store/download link — The official third-party destination used for acquiring third-party games.
• Library — The gamer's organization of games into Playing, Completed, Favourite, Recently Played, and Want to Play.
• Wishlist — The gamer's saved games with artwork, price, offers, rating, platform, and release date.
• Helpful button — The control by which a gamer marks another gamer's review as helpful.
• Duplicate review prevention — The rule that a gamer may not submit a second review for the same game.
• Report — A record of reported community content reviewed by moderators and admins.
• Purchase / Order / Payment — The records of a legally sold game acquisition, with payment status, coupons, promotions, and purchase history.
• Authorized payment provider — An external provider such as Razorpay that processes payments; raw card information is never stored by NEXORA.
• Malware/security scanning integration point — The pipeline hook where uploaded files are scanned before publication.
• Recommendations — Suggested games derived from favourite genres, wishlist, library, ratings, recently viewed/played, popularity, and similar games, with architecture ready for future ML.
• S3-compatible storage — The object storage used for images, videos, and authorized game files, served CDN-ready.
• EAS — Expo Application Services, used to build and distribute the Android and iOS apps.
• Deep link — A mobile link that opens a specific NEXORA destination inside the native app.