MenuList — Technical Architecture Memory Pack

Purpose: onboarding reference for implementation, architecture, routing, and operational constraints.

1) Core architecture

MenuList is a Next.js App Router codebase with multiple route groups:

src/app/(website)/
Public marketing/site pages for the product and legal/marketing surfaces.
src/app/(main)/
Authenticated owner/admin product app.
src/app/client/[[...slug]]/
Tenant/public customer-facing rendering for menus and official pages.
src/app/(global-pages)/
Shared global app routes (signin/error/forgot-password, etc.).
src/app/sites/canonica
Canonica-siloed product route area (do not blend with MenuList logic).

Resolver/domain mapping:
- src/lib/multiTenant/domainResolver.ts
- src/constants/productDomains.ts
- src/constants/urls.ts
Request transformation / headers:
- src/middleware.ts
- tenant context headers like x-tenant-subdomain, x-tenant-custom-domain
Domain behavior is strict by product and should not be changed casually:
- MenuList website domain vs platform domain vs tenant/public slugs
- Canonica route separation preserved

Owner app: React + Ant Design, Redux Toolkit, shared hooks/DAL
Public menu/OBP rendering: route-based tenant rendering with generated metadata/schema and discovery surfaces
Mobile layer: dedicated mobile surfaces with Tailwind and shared business logic from desktop where possible; avoid desktop-only assumptions

Primary data patterns in src/constants/database.ts map:

Tenancy: platformSummary, tenants, stores
Menu and truth: projects, files, menuSnapshots, menuItemState, menuChangeLog, menuIntelligence
Public entities: publicMenuDrafts, assets, campaigns, campaignExports
Decision/quality: decisionBlocks
Discovery: businessEntityIndex, applicationLogs, errorLogs
Public operations: analytics, feedback, guestFeedback, reviews, reviewsState
Infrastructure and controls: ops_config, systemHealth, systemAlerts, schedulerRunLogs, ownerControlUsage
Billing: pricingPlans, subscriptions, subscription_payments, payment_transactions, topups
Auth/data support: users, usersSchedules, AI_OPERATIONS_COLLECTIONS collections (aiCreditTransactions, etc.)
Chain/multi-location: masterOperationalState, integrations, posDeliveryQueue, messagingOnboarding*, businessEntityIndex

Important: avoid changing collection contracts without audit against runtime + docs.

Maintain tenant isolation on every read/write path.
Use auth/session guards as implemented for protected routes.
Input validation and schema checks (runtime + boundary validation) should not be bypassed.
Follow the project security rule files before touching auth/middleware/firestore-sensitive code.
Public APIs must preserve safe public output behavior and avoid leaking sensitive content.

Any write path touching public truth (especially projects/stores) should consider cache invalidation for:

menu/store public cache tags
client/public cache helpers in src/lib/cache/publicClientCache.ts and src/lib/cache/swrLocalStorageProvider.ts
invalidation behavior in client writes and server/API paths that render tenant pages

Skipping cache invalidation is a common regression source for stale public content.

Next.js App Router with next runtime (14.2.x policy in AGENTS + actual package.json dependency: 14.2.30)
Firebase/Firestore/Auth (client: 11.7.3, admin: 12.2.0)
NextAuth 4.24.3
Redux Toolkit + Redux Persist
TypeScript strict mode + Zod-style validations where applicable
Sentry + instrumentation modules in production paths

No unnecessary framework/library swaps for “modernization” unless explicitly required.

Use existing reusable primitives before introducing new ones.
Feature work with runtime impact should map to src/config/features.ts.
Use react-icons/lu (Lucide) only for iconography.
Keep mobile touch targets accessible (large, clear interactions).
Run type and lint checks for meaningful edits:
- npx tsc --noEmit --incremental false
- npm run lint

For any touched behavior: