docsPROJECT MEMORY FOR CHATGPT
MenuList Project Handoff — Deep Memory Pack
Owner: New ChatGPT handoff
Date: 2026-05-18 (Asia/Kolkata)
Repo: /Users/danny/Projects/MenuListAi/menulist-core
This document is the single source memory for continuing this project in a new ChatGPT session. It is built from current repository truth (implementation + docs), not from assumptions.
0) Executive Summary
MenuList is an owner-relief public-business infrastructure for SMBs, built as a calm, default-authoritative system that keeps customer-facing menu and business information synchronized across public surfaces from one controlled source.
It is not a “dashboard-first SaaS”, not a generic QR menu generator, and not an AI showcase. The design intent is: owner does not need to monitor daily; MenuList defaults to being correct, consistent, and quiet.
Primary value is delivered through:
- Public truth infrastructure (public menu + OBP + discovery metadata)
- Multi-outlet/chain coherence
- Low-friction onboarding + publish path
- Trust by stability rather than complexity
1) Why this project exists (and what it is trying to solve)
1.1 Core business pain
SMB public presence is fragmented:
- Different representations across WhatsApp PDFs, social links, QR menus, official pages, Google/business directories, and print links
- Frequent stale values (prices/hours/items) and mismatch across outlets
- Owners have low tolerance for operational complexity and repetitive maintenance
- SMB owners care less about “features” and more about “no surprises in public"
1.2 Product answer
- Define a single operational source (project/menu + business details) as the public canonical basis.
- Publish to multiple customer surfaces with controlled consistency.
- Keep owner actions minimal; use controlled defaults.
- Use confidence-safe behavior: if uncertain, stop and preserve trust rather than overact.
1.3 “Why this over others”
MenuList is positioned as a public trust platform, not merely a publishing UI.
2) Who it is for (SMB owner POV + secondary users)
2.1 Primary ICP
- Non-technical owners/operations leaders of SMBs who need dependable public-facing information.
- Owners already using a menu/project source and suffering mismatch across digital surfaces.
- Chain operators or multi-location teams with central governance + outlet specialization needs.
2.2 Secondary ICPs
- Staff/admin teams managing public-facing accuracy and support requests.
- Resellers/enablement teams onboarding multiple stores.
- Internal operators validating pricing, uptime, and consistency.
2.3 Owner success criteria (this should drive decisions)
- Can owners understand the state in one look?
- Can they correct an issue without retraining the system?
- Can they trust that public outputs reflect official state?
- Are manual steps reduced (not increased)?
- Is there no need for repeated weekly cleanup by owner?
3) Product doctrine and governance (must obey)
3.1 Core doctrine files (highest authority after AGENTS)
__docs__/constitution/01-CORE-DOCTRINE.md__docs__/constitution/02-LANGUAGE-GOVERNANCE.md__docs__/constitution/10-communication-worldbuilding-doctrine.md__docs__/constitution/12-product-separation-doctrine.md__docs__/constitution/17-infrastructure-compounding-doctrine.mdAGENTS.md
3.2 Non-negotiable behavioral frame
- Default authority: system behavior is primary, owners are exception handlers.
- Silence > explanation: no over-explaining public decisions.
- No cognitive overload: copy is owner-readable, short, operational.
- Trust > engagement: no feature spam.
- No “I have to manage this” narrative.
3.3 Language constraints
MenuList public/UI/support copy must avoid:
- “AI-powered”, “smart”, “optimized”, “dynamic”, “recommendations”, “best practices” framing
- Responsibility-shifting phrasing (“you should/you need to…”)
- marketing hype language disconnected from observable behavior
Use neutral/calm phrasing and canonical phrases from doctrine such as:
- “No action needed.”
- “Menu state is stable.”
- “Handled automatically.”
- “Everything is running normally.”
3.4 Why this matters for AI work
Every assistant pass must preserve the above laws when creating copy, UI labels, support language, website blocks, and claims.
4) Technical architecture (end-to-end)
4.1 High-level architecture pattern
Next.js App Router monorepo split by route group + product + tenancy:
src/app/(website)/- Canonical public marketing website for MenuList (
menulist.ai, alias domains).
- Canonical public marketing website for MenuList (
src/app/(main)/- Authenticated owner/admin app.
src/app/(global-pages)/- Shared auth/public utility pages (signin/forgot-password/error pages used by owner flows).
src/app/client/[[...slug]]/- Tenant/public rendering for menus, official pages, custom domain/subdomain routes.
src/app/(canonica)/andsrc/app/sites/canonica/- Canonica route surface + marketing endpoint for
/sites/canonicathrough domain routing.
- Canonica route surface + marketing endpoint for
src/app/api/,src/app/widget/,src/app/feedback/, and utility roots such asscreen,manifest.webmanifest.
4.2 Routing and domain strategy
Routing controlled in:
src/constants/productDomains.tssrc/lib/multiTenant/domainResolver.tssrc/middleware.tssrc/constants/urls.ts
Observed behavior:
- Product domain routing:
canonica.appand other configured product hosts route via middleware to/sites/<productId>throughproductDomains.ts.- In local dev, product prefixes such as
/__canonica/...also resolve to/sites/canonica/....
- Tenant routing:
*.menulist.aiand validated custom domains resolve to tenant mode and rewrite into/client/....- Middleware injects tenant headers:
x-tenant-subdomain,x-tenant-custom-domain, andx-tenant-type.
- Platform/website routing:
menulist.ai,menulist.online, and configured aliases are served in website context.app.menulist.aiis part of platform host flow and enters owner app routing (via auth/layout behavior).
- Protection behavior:
- Direct
/sites/*hits are redirected in Vercel production. - Direct
/clienthits on platform hosts are redirected back to/.
- Direct
- Middleware bypasses routing for asset/API/system paths to avoid unsafe rewrites (
/api,/_next,/__canonica,/sites, etc.).
4.3 Security and header layer
- CSP, HSTS (env-sensitive), security headers, frame policy, referrer policy in middleware.
- API route and public route protections plus domain-aware cache behavior.
- Public client tenant routes include cache headers for public-menu/OBP responses.
4.4 Runtime layers
- Owner surface: React/Ant Design desktop + Redux state + SWR for data flows.
- Public customer surface: lightweight SSR/ISR behavior for menu pages and discovery files, plus schema + metadata generation.
- Mobile parity: Tailwind-driven mobile surfaces with dedicated mobile screens (no desktop-only hacks for mobile behavior).
5) Stack and execution constraints
5.1 Core stack (current package reality)
- Next.js 14.2.30, React 18.3.1, TypeScript strict mode.
- Firebase client 11.7.3, Firebase Admin 12.2.0, NextAuth 4.24.3.
- Ant Design 5.23.1 on desktop, Tailwind-driven mobile surfaces in the current desktop/mobile split.
- Redux Toolkit + Redux Persist, SWR, Sentry, Upstash, Zod.
5.2 Version policy
- AGENTS governs freeze/convention decisions. Runtime truth is
package.jsonin the current branch. - Do not introduce dependency/version changes unless required for security or explicit migration scope.
5.3 Local conventions and gotchas
- Use existing
react-icons/lupatterns (no new icon libraries). - Preserve client-side DAL-first patterns unless architecture demands server API.
- Feature flags in
src/config/features.tsfor runtime behavior rollouts. npx tsc --noEmit --incremental false+ lint + route-level UI checks on substantive changes.
6) Data model and major collections
6.1 Canonical collections map (src/constants/database.ts)
- Tenancy and identity:
tenants,stores,platformSummary - Menu/project:
projects,files,menuSnapshots,menuIntelligence,menuItemState,menuChangeLog - Decision/quality:
decisionBlocks - Public output/support:
assets,campaigns,publicMenuDrafts - Discovery/infrastructure:
analytics,businessEntityIndex - Reliability/ops:
ops_config,systemAlerts,systemHealth,schedulerRunLogs - Feedback/trust:
reviews,reviewsState,guestFeedback - Multi-outlet:
masterOperationalState,ownerControlUsage - Commerce:
pricingPlans,subscriptions,subscription_payments,payment_transactions,topups - Integrations and sync:
integrations,posDeliveryQueue,integration*namespaces in extension layers - AI/ops helper collections:
menulistAiOperations, plusAI_OPERATIONS_COLLECTIONSmapping in same module
6.2 Canonica separation
Canonical note:
- Canonica has isolated collections/configs (
CANONICA_*) and separate Firebase expectations. - It must not be mixed with MenuList operational logic unless explicitly in cross-product routing context.
6.3 State correctness and cache discipline
- Public-facing mutations must consider cache invalidation for menu/store/client-store routes.
- Shared cache helpers exist under
src/lib/cache/(publicClientCache.tsandswrLocalStorageProvider.ts). - Any flow touching
projects/storespublic truth requires post-write consistency checks.
7) Feature system map (practical coverage)
7.1 Core public business surfaces and operations
- Client Menu (QR/menu) and public menu output
- Official Business Page (OBP)
- Search/discovery infrastructure (SEO/AEO, schema, structured outputs, discovery files)
- Menu correctness/quality systems
- Decision and quality intelligence surfaces in public browsing
- Digital screens and customer-facing media assets
- Reviews/reputation and feedback loops
- Multi-location consistency and outlet inheritance
7.2 Menu creation and management pipeline
- Upload/file intake
- Extraction (menu/text inference)
- Item/media generation (AI-assisted helpers)
- Translation and description handling
- Project management and special menu workflows
- Temporary status / visibility controls
- Communication kit and quick-capture outputs
7.3 Operations, trust, and governance
- Roles/permissions
- Authentication and onboarding
- Compliance and public safety settings
- OBP and compliance page editing
- Security and API protections
- Owner control telemetry and usage tracking
- Pricing/subscription integrity and payment surfaces
7.4 Expansion and roadmap surface areas already documented
- POS sync and webhook sync
- Multi-chain permissions
- Messaging onboarding
- Reseller workflows
- Predictive/collaborative support infrastructure (Canonica-facing parts)
7.5 Where feature docs live
The canonical feature inventory is in __docs__/index.md.
Use it when adding/modifying features; expected docs set: _spec, _impl, _marketing, _website, _helpdoc, _firebase, _mobile-support, and tests where relevant.
8) Public website architecture (marketing layer)
8.1 Canonical website route group
src/app/(website)/with shared light theme + website providers.- Homepage is composed in
src/components/website/home/HomePage.tsx. - Supporting pages exist for pricing, features, how-it-works, trust-security, multi-location, about, contact, legal.
8.2 Homepage section order (canonical)
- Hero
- Revenue Path
- Interactive Workflow
- Problem
- Solution
- Stats
- Setup Relief
- Surfaces
- Search Discovery
- Customer Browse
- Analytics Insights
- Smart Features
- Prepared For You
- Business
- Industry
- FAQ
- Final CTA
- Sticky CTA
8.3 Website messaging direction
- Not a feature dump. Sequence is: pain → transformation → proof → workflow → trust.
- Avoid generic QR/menu-only positioning.
- Use calm infrastructure language; no false certainty about external ranking.
8.4 Current docs set for website
__docs__/main-website/main-website_content.md__docs__/main-website/main-website_impl.md__docs__/main-website/main-website_spec.md
8.5 SEO/AEO & discovery support
- Public discovery surfaces are in runtime and settings paths:
src/app/manifest.webmanifest/route.tssrc/app/sitemap.ts,src/app/client/sitemap.tssrc/app/client/robots.tssrc/app/api/seo/route.ts
- Website references discovery capability as positioning evidence without claiming guaranteed ranking outcomes.
8.6 Cross-check evidence updates
- Active route group map verified in
src/appnow includes:(website),(main),(canonica),(global-pages),client,sites,api,feedback,widget,screen,manifest.webmanifest, and utility roots. - Homepage ordering is verified in
src/components/website/home/HomePage.tsxas 18 sections (includingStickyCta). - Routing truth is verified against
src/middleware.ts,src/lib/multiTenant/domainResolver.ts, andsrc/constants/productDomains.ts. - Cache invalidation path is verified via
src/lib/cache/publicClientCache.tsandsrc/app/api/revalidate/menu/route.ts(menu-store-{id},store-{id},client-stores).
9) Mobile and parity expectations
- Any owner-visible change must consider mobile parity if it affects owner flows.
- Public customer surfaces rely on responsive behavior and low-friction interaction.
- Use touch-size and simplified navigation constraints (45+ px touch guidance in governance).
- If touching desktop logic for owner flow, verify mobile analog and any inherited sheet behavior.
10) Security/compliance/security-adjacent contracts
- Routing and middleware security headers are not optional; changes must preserve tenant resolution and API protections.
- API-protected routes use authentication guards in practice.
- Tenant isolation and access checks are mandatory for reads/writes.
- Sensitive behavior (AI operations, payment, publishing) should be surfaced via feature flags and runtime logs.
- Avoid editing critical security files without reading security rules first:
middleware auth,firestore.rules, and security helper modules.
11) Operational playbook for future ChatGPT sessions
11.1 Before changing anything
- Confirm user intent (owner-facing/public-facing/internal) and pick relevant surface.
- Open doctrine files first (
AGENTS.md,01-CORE-DOCTRINE,02-LANGUAGE-GOVERNANCE). - Check relevant
_impland_specfiles before UI implementation. - Confirm whether feature flags are involved.
- If public-facing behavior changes, check docs parity requirements.
- Validate cache and tenant routing impact before finalizing.
11.2 Always check after change
npx tsc --noEmit --incremental falsenpm run lint- At least one route-level browser check for touched owner/public/public website pages.
11.3 If in doubt
- Default to source-of-truth behavior over marketing embellishment.
- Preserve calm architecture; reduce decision surfaces for owners when possible.
12) Concrete file map (start here in any new session)
12.1 Governance + workflow (first open)
AGENTS.mdIDE_PROMPTS/MASTER-EXECUTION-PROMPT.mdIDE_PROMPTS/00. MASTER RULES & WORKFLOW.md__docs__/constitution/01-CORE-DOCTRINE.md__docs__/constitution/02-LANGUAGE-GOVERNANCE.md__docs__/index.md
12.2 Routing and architecture
src/middleware.tssrc/lib/multiTenant/domainResolver.tssrc/constants/urls.tssrc/constants/productDomains.ts
12.3 Public + website
src/app/(website)/layout.tsxsrc/app/(website)/page.tsxsrc/components/website/home/HomePage.tsxsrc/components/website/shared/WebsiteHeadline.tsx__docs__/main-website/main-website_content.md__docs__/main-website/main-website_impl.md
12.4 Tenant/public render
src/app/client/[[...slug]]/page.tsxsrc/app/client/[[...slug]]/MenuNotFoundFallback.tsxsrc/app/client/[[...slug]]/MenuBreadcrumb.tsxsrc/components/templates/website/clientWebsite/*src/lib/schema/index.ts
12.5 Feature execution and docs
- Corresponding feature folders under
__docs__/(feature-specific_spec/_impl/_helpdoc/_marketing/_website/_firebase/_mobile-supportdirectories) - Related DAL/template paths in
src/lib,src/components/templates/main-app, and mobile twin screens.
13) Non-technical narrative to reuse externally
When introducing this project to another agent or stakeholder, use this framing:
“MenuList is infrastructure that keeps your public menu/business truth correct without requiring daily owner intervention.”
If they push toward “AI menu builder” or “analytics dashboard” language, correct course immediately.
14) Stage posture (current and validated)
This repo has already used staged website build-up:
- Context synthesis
- Strategy brief
- Visual direction
- Implementation
- CRO/ refinement
- Asset pipeline
- Launch polish
- Growth/iteration stages
The canonical implementation now lives only in the active website route, not in historical backup files.
If you need me to generate a split version for cross-account transfer, I can create:
PROJECT_MEMORY_FOR_CHATGPT_OVERVIEW.md(2–3 pages)PROJECT_MEMORY_FOR_CHATGPT_TECHNICAL.md(stack + architecture)PROJECT_MEMORY_FOR_CHATGPT_FEATURES.md(feature-by-feature map)