Scaffold initial Next.js web app

[BASIC-BIT]

Problem

VRDex has a locked frontend direction (Next.js + TypeScript), but there is not yet a concrete web-app scaffold in the repo.

Because this repo is expected to grow into a multi-surface codebase (Next.js, Convex, docs, infra, verification tooling), the first scaffold should set a clean baseline without prematurely freezing bigger architecture decisions.

Current recommendation

Use the current stable Next.js release via create-next-app@latest, but choose the scaffold options intentionally instead of blindly accepting every default.

Current bootstrap choices for this issue:

• create the app as a workspace-friendly web surface under apps/web
• use TypeScript
• use the App Router
• use ESLint
• use Tailwind CSS as a lightweight styling foundation, not as a full design-system commitment
• use a src/ directory so application code stays separated from repo/package config
• keep the default @/* import alias unless a stronger repo-wide alias standard emerges
• use normal next dev / next build scripts and rely on current Next.js defaults rather than adding stale explicit Turbopack flags
• do not enable React Compiler in this first scaffold pass; leave that for later once the app has real render/perf pressure

Scope

• scaffold the initial Next.js app in-repo
• use the latest stable Next.js version available at implementation time
• establish a workspace-ready structure that keeps room for later app, docs, backend, and shared-package growth
• create a minimal but intentional app shell or landing page so the app runs visibly
• add the minimum scripts and config needed for local development and future integration work
• keep the structure friendly to later Convex, auth, billing, and Vercel integration
• document the chosen scaffold decisions so follow-on issues inherit the same baseline

Non-goals

• full design system or polished product UI
• Convex integration
• auth implementation
• billing implementation
• Vercel deployment setup
• Docusaurus setup
• production-ready infrastructure or environment management
• extracting shared packages before there is real duplication pressure
• enabling optional Next.js features just because they are available in the generator

Acceptance criteria

• a Next.js app exists in the repo and runs locally
• the app uses TypeScript
• the scaffold uses the App Router
• the app lives in a workspace-friendly location that will not fight later repo growth
• the initial structure includes a clear app entry point and minimal folder layout for future product work
• there is a visible placeholder page or shell confirming the app bootstrapped correctly
• the repo includes the basic scripts needed to run, lint, and build the app during local development
• the scaffold does not prematurely lock in unnecessary UI/framework complexity beyond the current stack direction
• the bootstrap choices are documented clearly enough to guide #54, #55, #56, and #59

Definition of ready

• Problem: VRDex needs a real web-app surface so follow-on backend, deployment, auth, and product-page issues stop depending on hypothetical structure.
• Scope: create the initial Next.js app scaffold and document the baseline conventions it establishes.
• Non-goals: do not pull Convex, auth, billing, deployment, or major UI-system work into this slice.
• Dependencies: no hard blocker; should stay aligned with docs/planning/engineering-strategy.md, docs/agentic/definition-of-ready.md, and the follow-on bootstrap chain #54, #55, #56, #59.
• Verification: local app run, lint pass, production build pass, and updated setup docs; visual evidence is lightweight here because the UI scope is only a placeholder shell.
• Rollout: direct ship is fine; this is repo/bootstrap work and does not need a feature flag.
• Signals: not needed yet beyond confirming the scaffold is usable by follow-on implementation issues.
• Review notes: normal review is enough; keep an eye on whether the scaffold choices accidentally overreach into architecture decisions that belong in later issues.

Likely docs to update

• README.md
• docs/planning/engineering-strategy.md
• docs/README.md
• any app-specific onboarding/setup doc created during implementation

Soft dependencies

• none strictly required before scaffolding
• should stay aligned with the locked stack direction in docs/planning/engineering-strategy.md
• should remain compatible with the verification baseline expected by #59

Soft dependents

• #54 Bootstrap initial Convex backend
• #55 Wire initial Next.js app to Convex backend
• #56 Bootstrap initial Vercel deployment path
• #59 Bootstrap repository verification tooling and developer guardrails
• later auth/bootstrap and public page issues