Skip to content

RestaurantOS — Documentation Index

The product, in one paragraph

A guest sits at a table, scans the QR taped to it, sees that restaurant's menu, and orders — no app install. RestaurantOS is the multi-vendor platform behind that moment: one codebase serving any number of independent restaurants, each on their own subdomain or custom domain. The QR on the table is printed once and never changes; the menu, prices, table state and staff behind it are resolved live on every scan. That is what makes it a dynamic QR platform rather than a PDF menu with a QR on top.

New here? Read 00-core-loop.md first — it traces that one journey, scan to kitchen ticket, through the actual files, and is the fastest way to make the rest of this repository make sense.

🟢 বাংলা ভূমিকা: অতিথি টেবিলে বসে QR স্ক্যান করেন, সেই রেস্টুরেন্টের মেনু দেখেন, অর্ডার করেন — কোনো অ্যাপ ইনস্টল ছাড়াই। RestaurantOS হলো সেই মুহূর্তের পেছনের মাল্টি-ভেন্ডর প্ল্যাটফর্ম: একটিমাত্র কোডবেস অসংখ্য স্বাধীন রেস্টুরেন্ট চালায়, প্রত্যেকে নিজস্ব সাবডোমেইন বা নিজস্ব ডোমেইনে। টেবিলের QR একবারই ছাপা হয়, কখনো বদলায় না; কিন্তু তার পেছনের মেনু, দাম, টেবিলের অবস্থা ও স্টাফ প্রতিবার স্ক্যানে নতুন করে নির্ধারিত হয়। নতুন এসেছেন? আগে 00-core-loop.md পড়ুন।


This index ties together the 18 specification documents below, each written bilingually (English technical spec followed by a Bengali summary per section) so the docs are equally usable by international collaborators, Bengali-speaking stakeholders, and AI coding agents continuing this project's development.

🟢 বাংলা: নিচের ১৮টি ডকুমেন্টের প্রতিটি দ্বিভাষিক — প্রতিটি সেকশনে প্রথমে ইংরেজিতে টেকনিক্যাল স্পেসিফিকেশন, তারপর বাংলায় সারাংশ — যাতে আন্তর্জাতিক সহযোগী, বাংলাভাষী স্টেকহোল্ডার এবং AI কোডিং এজেন্ট সবার জন্যই সমানভাবে ব্যবহারযোগ্য হয়।


⚠️ Read This First

Current implementation reality: RestaurantOS today is a pure front-end build — Next.js 16, TypeScript, Tailwind CSS, Framer Motion, and static mock data + localStorage for all "persistence." There is no database, no auth, no payment gateway, and no real-time backend wired yet. Every document in this set describes both:

  1. What exists today (marked ✅), grounded in the actual src/ codebase, and
  2. The target production architecture (marked 📐) — Supabase (Postgres/Auth/Realtime), Prisma ORM, Vercel Domains API, Upstash Redis, and payment/SMS integrations — that these docs are written to guide, without requiring any rewrite of the existing UI layer.

This split is intentional and load-bearing: every hook in src/hooks/* is designed so its external interface stays identical when its internals swap from localStorage to a real backend call — see 02-folder-and-routing.md and 07-database-schema-and-erd.md for the specifics of this contract.

🟢 বাংলা সারাংশ: RestaurantOS এখন পুরোপুরি ফ্রন্টএন্ড — কোনো ডাটাবেজ, অথেন্টিকেশন, পেমেন্ট গেটওয়ে, বা রিয়েল-টাইম ব্যাকএন্ড এখনো যুক্ত হয়নি। সব ডেটা localStorage-এ থাকে। এই ডকুমেন্টগুলো একসাথে দুটো জিনিস বর্ণনা করে — (১) এখন কী আছে (✅ চিহ্নিত), এবং (২) ভবিষ্যতে কী বানানো হবে (📐 চিহ্নিত)। প্রতিটি হুকের বাইরের ইন্টারফেস অপরিবর্তিত রেখে শুধু ভেতরের ইমপ্লিমেন্টেশন পরিবর্তন করে ব্যাকএন্ড যুক্ত করা হবে — তাই UI কম্পোনেন্ট পরিবর্তন করতে হবে না।


📚 Document Set

#DocumentCoversStatus
00The Core LoopWhat the product actually is, and the scan → menu → order journey traced through the real files✅ Start here
01System OverviewProduct vision, tech stack, architecture diagram, persona/surface map, implementation status✅ Reflects current build
02Folder Structure & RoutingAntiGravity folder architecture, full route table, proxy.ts subdomain resolver, hooks reference✅ Reflects current build
03Platform Admin SpecTenants, Plan Builder, Feature Flags & plan-whitelisting, VIP overrides, Impersonation, Invoicing✅ Reflects current build
04Restaurant Dashboard SpecMenu, Orders, Tables/QR, POS, Staff, Inventory, CRM, Reservations, Promos/CMS, Analytics, Settings✅ Reflects current build
05Customer Menu & Allergy Engine/table QR entry, menu browsing, allergy/diet filter, cart, split-bill, gamification✅ Reflects current build
06Kitchen, Waiter & Rider AppsKDS, pickup screen, waiter app, rider app, the shared real-time order backbone✅ Reflects current build
07Database Schema & ERDValidated Prisma schema (49 tables), four Mermaid ERDs, conventions, derived values, indexes📐 Target design · prisma validate clean
08Payment & SMS IntegrationsbKash/Nagad/Stripe IPN webhooks, SMS/WhatsApp dispatch, ESC/POS thermal KOT printing📐 Target design
09Caching & PerformancePer-route rendering strategy, Upstash Redis cache keys, Core Web Vitals targets🟡 Rendering split is real (§0); caching layer still target design
10DevOps & CI/CD PipelineVercel hosting, Vercel Domains API automation, GitHub Actions, Prisma migration strategy📐 Target design
11Testing & QA StrategyTesting pyramid, Vitest/Playwright/RTL setup, critical user journeys, multi-tenant test data✅ All three layers built — see the doc's status line for current counts
12Security Audit & Rate LimitingThreat model, RLS defense-in-depth, Upstash rate limiting, OWASP Top 10 mapping, launch checklist📐 Target design
13Domains, Routing & Every LinkHow a hostname becomes a restaurant, all 47 routes, where every link goes, local + Vercel setup, custom domains, troubleshooting✅ Routing built and tested · 🟡 custom-domain final hop needs backend
14Supabase SetupProjects, env vars, the app_server role, RLS model, auth (email, MFA, shift PIN), Storage, Realtime, cron — with the isolation assertions it passed📐 Target design · SQL tested on Postgres 17
15Backend Architecture & ModulesTarget folder structure, 21 modules and their dependency rules, tenancy wrapper, placeOrder anatomy, error/validation/money/time conventions📐 Target design
17Production ReadinessLaunch checklist: what is done (with evidence), what the backend blocks, operational/legal/design gates, performance targets🟡 Live checklist
18The Design RefreshThe canvas-and-panels language, every surface it reached, the new routes and localStorage keys, and the rules the new pieces follow✅ Shipped on ui-polish
16Backend Cutover PlanReadiness, phase order with done-checks, every ros-* key and src/lib/data function → table/query, seeding, accounts the business must supply📐 Plan — start here for backend work

Pre-existing companion documents (English-only, complementary — not part of this bilingual set): feature-lists.md, srs.md, roadmap.md.

🟢 বাংলা সারাংশ: উপরের টেবিলে ১৭টি ডকুমেন্টের তালিকা ও প্রতিটির বিষয়বস্তু দেওয়া আছে। ০১-০৬ নম্বর ডকুমেন্ট বর্তমান বাস্তবায়িত কোডবেস প্রতিফলিত করে (✅), আর ০৭-১২ নম্বর ডকুমেন্ট ভবিষ্যতের টার্গেট আর্কিটেকচার বর্ণনা করে (📐)। এছাড়া তিনটি পুরনো ইংরেজি-ভাষী কমপ্যানিয়ন ডকুমেন্টও আছে যা এই দ্বিভাষিক সেটের অংশ নয় কিন্তু পরিপূরক।


🧭 How to Use This Documentation

If you're a human contributor:

  • Start with 00 to see what the product is and how one scan becomes a kitchen ticket, then 01 for the big picture and 02 for the folder/routing conventions — before touching any code.
  • Jump directly to the doc matching the module you're working on (03-06 for existing features, 07-12 for backend/infra work).

If you're an AI coding agent (Claude, Copilot, or similar) picking up this project:

  • Read 00, 01 and 02 first, always — 00 gives you the product's one load-bearing journey so the rest has something to hang on; 01 and 02 establish ground truth about the folder structure, the proxy.ts subdomain resolver, and the hooks convention every other document assumes.
  • Never assume a backend exists unless you've verified it in the current codebase — docs 07-12 are forward-looking specs, not descriptions of shipped code. Cross-check against src/hooks/*.ts (all currently localStorage-backed) before writing code that assumes a real API/database.
  • Preserve hook external interfaces when implementing any backend feature described in these docs — the whole migration strategy (see 16 §3) depends on components never needing to change when a hook's internals are swapped.
  • Respect the plan-whitelist nullable-array semantic (SubscriptionPlanDef.featureFlagIds / SubscriptionPlan.featureFlagIds) exactly as documented in 03 §4 and 07 §3 — empty/undefined means unrestricted, not no features. This is the single most consequential subtlety to get wrong.
  • Keep new docs bilingual if extending this set — English technical content per section, followed by a 🟢 **বাংলা সারাংশ:** summary paragraph; code/schema blocks stay English-only.
  • See also the repo-root CLAUDE.md and AGENTS.md files for must-read agent operating conventions that complement (and take precedence for process/workflow matters over) the technical content here.

🟢 বাংলা সারাংশ: মানুষ কন্ট্রিবিউটরদের জন্য পরামর্শ: প্রথমে ০১ ও ০২ পড়ুন, তারপর যে মডিউলে কাজ করছেন সেই ডকুমেন্টে যান। AI এজেন্টদের জন্য: সবসময় ০১-০২ আগে পড়ুন, কখনো ধরে নেবেন না যে ব্যাকএন্ড আছে (০৭-১২ শুধু ভবিষ্যতের পরিকল্পনা, বাস্তবায়িত কোড নয়) — কোড লেখার আগে src/hooks/*.ts চেক করুন। যেকোনো ব্যাকএন্ড ফিচার বানানোর সময় হুকের বাইরের ইন্টারফেস অপরিবর্তিত রাখুন, এবং featureFlagIds খালি থাকার মানে "কোনো নিষেধাজ্ঞা নেই" — এই নিয়ম ভুলভাবে পরিবর্তন করবেন না। নতুন ডকুমেন্ট লিখলে একই দ্বিভাষিক ফরম্যাট বজায় রাখুন। এছাড়া রুট-লেভেলের CLAUDE.md ও AGENTS.md-ও পড়ুন।


🗺️ Quick Cross-Reference: Feature → Doc

Looking for...Go to
Full route list / URL structure02 §3
The design language, what each surface looks like now, the new keys/routes18
proxy.ts subdomain/custom-domain logic02 §5
Pricing plans & feature flag whitelisting03 §3-4
Impersonation ("View As Restaurant")03 §6
Menu builder / BOM / food costing04 §3
Promo campaigns & drag-and-drop landing CMS04 §12
Dynamic per-table QR & token rotation05 §2
Allergy/diet filter matching logic05 §4
Cross-surface real-time order sync (KDS/Waiter/Rider)06 §1
Full Prisma schema / ERD07 §2-3
bKash/Nagad/Stripe webhook code08 §1
Redis cache keys & TTLs09 §2
Vercel Domains API custom domain automation10 §1
Critical E2E test journeys11 §3
Pre-launch security checklist12 §5

🟢 বাংলা সারাংশ: কোনো নির্দিষ্ট ফিচার খুঁজলে উপরের টেবিল থেকে সরাসরি সংশ্লিষ্ট ডকুমেন্ট ও সেকশনে যেতে পারেন — যেমন রাউট লিস্ট চাইলে ০২ নম্বর ডকুমেন্টের §৩-এ, প্রাইসিং প্ল্যান/ফিচার ফ্ল্যাগের জন্য ০৩ নম্বরের §৩-৪-এ, ইত্যাদি।