Vexlora Documentation Multipurpose Next.js Admin
Modules Routes
Multipurpose buyer handbook · v1.0.0

Vexlora, from first install to production integration.

This guide explains what Vexlora ships, where to edit it, how the 491 page routes (473 buyer-facing application screens, 17 foundation/reference screens and 1 redirect) and 19 dashboards relate, and where your own backend, payment, AI, authentication and data services connect. It is written for buyers who may be new to the codebase.

473 application screens 491 page routes 19 dashboards Next.js 16.3.1 React 19.2.8 Tailwind CSS 4.3.3 TypeScript 5.9.3

Start here

Vexlora is an admin-panel template, not a customer-facing storefront and not a production backend.

473
APPLICATION SCREENS

Buyer-facing application routes are counted separately from foundation/reference pages and redirects.

19
BUSINESS DASHBOARDS

Each dashboard has a distinct operating story while sharing one shell and design system.

0
PRODUCTION BACKENDS BUNDLED

Databases, secrets, authentication, money movement and AI execution remain buyer-owned.

The most important boundary

Vexlora illustrates administration UX, data contracts and integration handoffs. Replace sample/mock/browser state with your own server/API where production persistence, authorization or sensitive operations are required.

Counting note

The generated registry currently contains 491 page.tsx routes: 473 application screens, 17 foundation/reference screens and 1 redirect. For marketplace wording, do not present all 491 routes as buyer-facing application screens.

ThemeForest help-file format

Envato requires ThemeForest items to include beginner-friendly documentation covering installation, customization/use and asset credits, written in English as HTML or PDF. This offline portal is structured around those requirements. Official Envato guidance →

Recommended reading order

Install and run locally

Confirm your Node/npm environment and open the dashboard.

Rebrand centrally

Change product identity, theme tokens and layout from shared config files.

Understand module ownership

Learn which domain owns business records, payments, finance, integrations and AI actions.

Connect your backend

Swap the provider/storage layer without rewriting visual pages.

Certify before release

Run typecheck, lint, build and the included quality gates.

Installation

Use the lockfile for repeatable installs. The project declares Node.js >= 20.19.0.

Requirements

  • Node.js 20.19.0 or newer
  • npm with network access to install packages
  • Modern Chromium, Firefox or Safari browser
  • Git is optional but recommended for buyer changes

Included stack

Next.js 16.3.1, React 19.2.8, TypeScript 5.9.3, Tailwind CSS 4.3.3, Radix UI, React Hook Form, Zod, TanStack Table and Recharts.

Fresh install

npm ci
npm run dev

Open http://localhost:3000 . The default landing route redirects to /dashboard/executive .

Production verification

npm run typecheck
npm run lint
npm run build
npm start
npm ci vs npm install

For a clean release or CI-style verification, prefer npm ci because the package-lock is included. Buyers actively changing dependency versions may use npm install , then review and commit the lockfile change.

Environment file

# macOS / Linux
cp .env.example .env.local

# Windows PowerShell
Copy-Item .env.example .env.local

The .env.example file is the source of truth for the environment-variable names shipped with your source package. These hooks only extend development origins, CSP connections and trusted frame ancestors. Never place secret API keys in browser-exposed environment variables.

Project structure

The route layer stays thin; shared UI, business features, data adapters and configuration have separate ownership.

project-root/ ├── src/ │ ├── app/ # Next.js App Router routes │ ├── components/ │ │ ├── ui/ # shared primitives │ │ ├── layout/ # sidebar, topbar, shell │ │ ├── charts/ # shared chart infrastructure │ │ └── data-table/ # shared table engine │ ├── features/ # domain-owned components/data/types │ ├── config/ # product, navigation, layout, theme registries │ ├── data/ # application-level data providers │ ├── lib/ # framework-neutral utilities │ └── types/ # shared TypeScript contracts ├── public/ # local brand/sample assets ├── docs/ # engineering reference notes ├── documentation/ # this buyer documentation portal └── scripts/ # release and regression checks
Route composition rule

Keep page.tsx focused on composition. Put reusable UI, mock data, schemas, filters and business logic under src/features/<domain>/ .

Customize safely

Most buyer changes have a central entry point. Start there before editing many pages.

Brand identity · one file

Edit src/config/product.ts to change the product name, admin name, company, tagline, logo path, export prefix and browser-storage prefix.

productConfig.name = "Your Admin"
productConfig.companyName = "Your Company"
productConfig.brand.logoSrc = "/brand/your-logo.svg"

Colors, radius, font

Use semantic tokens in src/app/globals.css and presets in src/config/presentation.ts . Avoid page-by-page hardcoded colors.

Default layout

Edit src/config/layout-engine.ts . Supported navigation: vertical/horizontal; sidebar: standard/compact/mini; content: boxed/full; header: sticky/fixed.

Topbar sample account

Replace launcher/user/notification sample data in src/config/application-shell.ts . The signed-in profile screen is separate from generic User Management.

Do

  • Change semantic design tokens
  • Reuse shared components and feature patterns
  • Keep business data feature-owned
  • Run quality gates after structural changes

Do not

  • Add random page-specific CSS files
  • Scatter API credentials through React code
  • Duplicate DataTable or chart engines per page
  • Put production card/CVV or banking secrets in browser state

Shell & navigation

Sidebar, breadcrumbs, command discovery and much of the topbar are driven by shared registries.

Navigation

Edit the matching area file under src/config/navigation/ . The composer is src/config/navigation.ts .

Shell

src/components/layout/ contains desktop/mobile navigation and topbar pieces.

Search

Global search flattens the same navigation tree, so labels and routes remain synchronized.

Add a permanent navigation item

Create the page route first.

Place it under src/app/(dashboard)/…/page.tsx .

Add the navigation item.

Use the correct group file in src/config/navigation/ .

Regenerate and validate.

Run the registry and route gates.

npm run registry:generate
npm run check:routes
npm run check:screen-registry
Contextual routes

Create, edit, details and preview screens usually should not become permanent sidebar destinations. Link to them from the owning workspace.

The 19 dashboards

Dashboards share shell/theme/responsive foundations, but their composition, charts and operating questions are deliberately different.

Executive

Leadership posture, board signals, growth quality and strategic decisions.

/dashboard/executive

SaaS

MRR, ARR, churn, retention, activation and subscription growth.

/dashboard/saas

eCommerce

Sales, orders, conversion, fulfillment and commerce health.

/dashboard/ecommerce

CRM

Pipeline, forecast, account health, activities and seller performance.

/dashboard/crm

Analytics

Traffic, engagement, conversion, attribution and realtime signals.

/dashboard/analytics

Finance

Treasury, cash flow, close readiness, receivables and spend.

/dashboard/finance

Projects

Portfolio delivery, project capacity, milestones and blockers.

/dashboard/projects

Marketing

Campaign performance, channel mix, creative quality and growth.

/dashboard/marketing

HR

Workforce, recruiting, attendance, payroll and learning.

/dashboard/hr

Support

Queues, SLA, agent operations, self-service and escalation.

/dashboard/support

Logistics

Shipments, carrier performance, network flow and exceptions.

/dashboard/logistics

Inventory

Stock health, replenishment, aging, transfer and count controls.

/dashboard/inventory

ERP

Procurement, suppliers, warehouse, MRP, sales and finance handoffs.

/dashboard/erp

Energy

Grid, demand, metering, storage, assets and sustainability.

/dashboard/energy

Construction

Portfolio, site operations, workforce, safety and cost.

/dashboard/construction

Hospital

Patient flow, ICU, beds, theatre, staffing and revenue cycle.

/dashboard/hospital

Education

Enrollment, attendance, learning outcomes, faculty and fees.

/dashboard/education

Real Estate

Portfolio, occupancy, leasing, listings, deals and cash flow.

/dashboard/real-estate

AI

Models, agents, usage, cost, governance and business impact.

/dashboard/ai
Customization path

Dashboard pages live under src/app/(dashboard)/dashboard/<name>/ ; business data/charts live under src/features/dashboards/ ; shared chart behavior lives under src/components/charts/ and src/config/chart-system.ts .

How the modules relate

Vexlora avoids duplicating ownership. A business domain owns why something happens; shared control planes own cross-cutting execution.

Commerce order to money and fulfillment

eCommerce Order / customer intent
Payment Core Pay-in / routing
Finance Settlement / accounting
Inventory + Logistics Stock / fulfillment

SaaS customer lifecycle

SaaS Plan / subscription
CRM Account / renewal
Support Service / health
Finance + Payments Invoice / collection

Outgoing obligation

HR / ERP / Projects / Construction Approved obligation
Finance Payable / funding
Payment Core Payout rail

AI operating layer

Business module Safe context
AI copilot / agent Reason / propose
Human approval Governed action
Buyer API Server-side write
Reporting ownership

Finance Reports owns financial statements, eCommerce Reports owns commerce reports, CRM Reports owns sales/customer reporting, and Analytics Reports owns cross-module correlation.

Replace mock data with your API

Vexlora keeps presentation independent from a production database. Pages should depend on typed providers/repositories, not hardcoded fetch logic.

Page / Feature UI composition
dataProvider application contract
Repository mock or REST
Your API auth + validation + DB

Default provider

src/data/provider.ts points to sample repositories.

REST example

src/data/rest-provider.ts and src/lib/data/rest-repository.ts illustrate the handoff.

Expected list shape

type PaginatedResult<T> = {
  items: T[]
  page: number
  pageSize: number
  total: number
  totalPages: number
}
Never expose server secrets

Authentication credentials, database URLs, payment secrets, AI provider secrets and signing keys belong in your backend/server environment, not in frontend source or browser storage.

eCommerce & Online Store

The eCommerce suite owns product/order/inventory/checkout/marketplace operations. Online Store is an admin-side content/navigation configurator for a buyer-owned storefront.

Core eCommerce

Products, Orders, Inventory, Checkout & Pricing, Marketplace, Reports and Commerce AI.

Engineering reference →

Online Store Studio

Overview, Menus & Navigation, Pages, Blog, Testimonials, Contact us and Popups.

Detailed reference →

Mega-menu flow

Source library pages / products / posts / categories / brands / image
Builder drag / nest / reorder
Behavior direct · dropdown · mega 2–6 col
Your storefront render / animate / persist

Static Pages

Use the Online Store Pages workspace for About, Privacy, Terms and other storefront pages. The HTML editor supports source/preview modes, inline/featured media, SEO and publication controls. Production HTML should be sanitized according to your backend policy.

Blog / media

Blog supports categories, archives, featured images, social-link handoff and Menu Builder sources. Browser image handling is sample-oriented; replace it with your media/CDN API for production.

No customer-facing storefront is bundled

The menu builder and content studio expose admin configuration. Your Next.js storefront owns final navigation rendering, animation, routing, content delivery and consent/analytics behavior.

Payments & money movement

Payment Core is provider-neutral infrastructure. Finance remains the accounting/reconciliation owner; business domains own the document that explains why money moves.

Business document order / invoice / fee / rent / payroll
Payment Core pay-in / split / payout / adjustment
Provider + backend secure execution
Finance settlement / ledger / reconciliation

Payment Core workspaces

Transactions, Methods, Providers, Accounts, Marketplace, Checkout, Routing, Refunds & Disputes, Payout Routing and Domain Flows.

Frontend can show

  • provider capability and status
  • masked method/account references
  • routing and checkout configuration
  • refund/dispute workflow presentation

Backend must own

  • API secrets and tokens
  • raw card/CVV handling through compliant provider surfaces
  • webhook signature verification
  • idempotency and amount validation
  • actual money movement

See PAYMENT_CORE.md , PAYMENT_INFRASTRUCTURE_2026.md and ECOMMERCE_CHECKOUT_PAYMENTS.md .

AI platform

AI is a flagship operating layer with dedicated workspaces plus contextual copilots across business modules.

Build

Agents, automations, prompts, knowledge, models and media workflows.

Govern

Safety, approvals, identity/access, evaluation, policy and observability.

Operate

Runs, usage/cost, reliability, production operations and cross-module actions.

Contextual action model

Read safe module context
Reason model / RAG
Propose explain action
Approve human / policy
Execute buyer server
Provider boundary

The bundled template contains no production AI provider secret and does not execute privileged business writes. Connect your model gateway, RAG service and action API server-side.

Start with AI_FLAGSHIP.md , AI_CROSS_MODULE.md and the specialized AI engineering notes in docs/AI_*.md .

Authentication, users & RBAC

The template includes complete identity/admin presentations, but real session issuance and authorization must be integrated by the buyer.

Authentication screens

Sign in, registration, recovery, verification, OTP, 2FA, magic link and social-login presentation.

Administration

Users, profile/details, activity, sessions, login history, devices, API-key inventory, roles, permissions, teams and departments.

Authorization is server-side

A frontend checkbox or hidden menu item is not a security boundary. Re-evaluate permissions on every sensitive backend request.

Reference: AUTH_RBAC.md and IDENTITY_ACCESS_2026.md .

Forms, tables & charts

Vexlora centralizes interaction engines so buyers change business content without forking foundations.

Forms

React Hook Form + Zod patterns. Preserve labels, errors, aria-invalid and server revalidation.

Data tables

Shared pagination, sorting, selection, visibility and responsive patterns under src/components/data-table/ .

Charts

Recharts components use shared chart tokens/config. Keep chart data feature-owned.

Engineering references: FORMS.md , DATA_TABLE.md , CHARTS.md .

Localization & RTL

Locale definitions and formatting are centralized. Direction uses logical start/end utilities so LTR and RTL share the same components.

Locale config

src/config/i18n.ts defines supported locale behavior.

Formatting

src/lib/i18n/format.ts owns number/date/currency formatting helpers.

npm run check:i18n-rtl
Styling rule

Prefer logical utilities such as start/end, ms/me and ps/pe instead of hardcoding left/right in reusable UI.

Responsive, accessibility & quality

Responsive adaptation is intentionally limited to 320–1280px. Above 1280px, preserve the original desktop composition; larger widths should be spot-checked for overflow or regressions without redesigning the layout.

Viewport verification matrix

320 375 430 640 768 1024 1280 1366 1440 1536 1920 px
Layout preservation rule

From 320–1280px, apply only the minimum fixes needed for real responsive issues. Above 1280px, do not reorder blocks, change dashboard composition, make cards full-width, or alter established desktop card geometry.

Responsive checks

  • No page-level horizontal overflow
  • Charts/cards keep readable minimum geometry
  • Tables use mobile cards or explicit overflow
  • Dialogs remain usable at short viewport heights
  • Topbar/sidebar actions remain reachable

Accessibility checks

  • Keyboard-only navigation
  • Visible focus states
  • Named icon buttons and form controls
  • 200%/400% zoom/reflow
  • Screen-reader landmarks, dialogs and tables
npm run check:responsive
npm run check:accessibility

Security architecture

Vexlora includes defensive browser defaults and a buyer-facing Security Center, while clearly separating frontend safeguards from production security controls.

Included frontend defaults

CSP, nosniff, referrer policy, permissions policy, cross-origin opener policy, file preflight, typed validation and masked credential presentations.

Buyer-owned production controls

Secret vaults, database authorization, WAF/rate limiting, webhook verification, malware scanning, server validation, session issuance and audit persistence.

CSP environment hooks

# Copy .env.example to .env.local, then configure only the keys you need.
# Keep the exact variable names shipped in .env.example.

This keeps the documentation accurate if the product prefix is renamed in a future release; .env.example remains authoritative.

ThemeForest preview

The default frame-ancestor policy allows the ThemeForest preview parent while avoiding broad unrestricted embedding. Add only explicitly trusted origins.

Reference: HIGH_SECURITY.md .

Media, images & asset credits

Sample assets are isolated so buyers can replace them without rewriting page logic. Redistribution evidence must be handled carefully before marketplace submission.

Brand assets

Place buyer-owned logos under public/brand/ and reference them through productConfig.brand.logoSrc .

Sample imagery

Product, construction and real-estate images live under public/images/ . See the dedicated credits page before redistribution.

Asset release status

The v1.0.0 source records the Pexels product-photo sources. Real Estate and Construction imagery still requires author-side replacement or retained redistribution/license evidence before final ThemeForest submission. Use the dedicated asset register as the release source of truth.

Open Assets & Credits →

Add a new page or module

Use the existing route group and shared foundations; do not create a parallel admin shell.

Create the route.

src/app/(dashboard)/your-area/page.tsx

Create feature ownership.

Put components, data, schemas and types under src/features/your-area/ .

Compose shared foundations.

Use PageHeader, Card, DataTable, forms and chart primitives.

Add navigation only if permanent.

Update the correct file under src/config/navigation/ .

Regenerate + certify.

Run registry and quality checks.

npm run registry:generate
npm run check
npm run test:critical
npm run typecheck
npm run lint
npm run build

Build & deployment

Vexlora is a standard Next.js application. Choose a host that supports the Next.js runtime you intend to use.

Managed Next.js host

Connect the repository, install with the lockfile and use the standard Next.js build command. Configure environment values in the host dashboard.

Node server / container

Install dependencies, run npm run build , then serve with npm start behind your reverse proxy/TLS layer.

npm ci
npm run build
npm start
Before production

Replace sample storage and mock providers where durable data is required; integrate authentication/authorization; configure server secrets; verify CSP/API origins; and re-run accessibility, responsive and security checks.

Updates & upgrade safety

Keep buyer customization centralized and use version control so source upgrades can be merged predictably.

Recommended workflow

  • Commit your current customization
  • Read the new release notes
  • Apply the new source in a separate branch/folder
  • Reapply central config changes first
  • Run upgrade cleanup/preflight gates
  • Run typecheck, lint and build

Protected architecture

The project includes upgrade cleanup/preflight scripts that protect canonical routes and remove retired aliases/files during in-place upgrades.

npm run upgrade:preflight
npm run check:upgrade-preflight-safety
npm run check

Release QA & certification

The source includes a large automated regression suite in addition to TypeScript, ESLint and the Next.js production build.

Buyer release sequence

npm ci
npm run typecheck
npm run lint
npm run build
npm run check
npm run test:critical

# Combined project certification gate
npm run certify

Source gates

Styles, architecture, responsive, accessibility, performance, buyer customization and maintainability.

Domain gates

eCommerce, payments, AI, CRM, Finance, HR, Hospital, Education, Real Estate and other suites.

Registry gates

Routes, navigation ownership, duplicates and critical page smoke tests.

Do not substitute static checks for a production build.

A release is strongest when TypeScript, ESLint, Next.js build and the project-specific gates all pass in the buyer's installed dependency environment.

Troubleshooting

Start with the exact failing command and message. Avoid deleting lockfiles or changing dependencies before understanding the error.

Problem What to check Recommended action
Fresh install mismatch Node version, package-lock, partial node_modules Remove node_modules and run npm ci again.
Stale Next.js types/cache .next , tsconfig.tsbuildinfo Run npm run clean , then typecheck/build again.
Navigation gate fails Route exists but registry/navigation is stale Run npm run registry:generate , then review the intended navigation owner.
Browser-storage sample behaves strangely Old sample state from an earlier release Use the relevant reset action or clear the Vexlora sample storage for local testing.
CSP blocks an API Production API/WebSocket origin is not allowed Add only the required API/WebSocket origin to the CSP connect-source variable defined in .env.example .
Upload works in sample but must persist Browser adapter is not a production media service Connect the picker to your own upload/CDN API and store safe returned URLs/IDs.

Frequently asked questions

Short answers to the questions buyers most often have when adapting a large admin template.

Does Vexlora include a backend?

No. It is a frontend-only admin template with mock/sample state and integration-ready contracts.

Can I use it with my existing Next.js storefront?

Yes. The admin is intentionally isolated. Online Store exposes content/navigation configuration; your storefront owns customer-facing rendering.

Can I use a REST, GraphQL or different backend?

Yes. The visual layer is provider-neutral. Adapt the data/integration boundary to your backend.

Are payments live?

No. Payment Core is configuration/workflow UI. Connect actual providers and webhooks through secure server code.

Is AI required?

No. Core business workflows remain usable without an AI provider. AI is an optional flagship enhancement layer.

Where do I change the brand?

Start with src/config/product.ts , then update semantic theme tokens if needed.

Engineering references included with the source

The docs/ directory contains detailed architecture notes for AI, payments, eCommerce, CRM, data layer, security, accessibility, responsive behavior, settings, reporting, industry suites and more. This buyer portal summarizes those contracts; the Markdown files provide implementation depth.