16 — Backend Cutover Plan & Readiness Checklist

Status: 📐 The plan for leaving the frontend-only phase. Nothing here has started. Read 15 for where code goes, 07 for the schema, 14 for Supabase. This doc is what order, what replaces what, and how we know each step is done.

🟢 বাংলা ভূমিকা: ফ্রন্টএন্ড-অনলি পর্ব থেকে বেরোনোর পরিকল্পনা — কোন ক্রমে কাজ হবে, আজকের কোন localStorage key বা mock ফাংশন কোন টেবিল/কোয়েরি দিয়ে বদলাবে, আর প্রতিটা ধাপ "শেষ" কখন বলা যাবে। কোড কোথায় যাবে তা ১৫-তে, স্কিমা ০৭-এ, Supabase ১৪-তে।

1. Readiness — what is already true before day one

🟢 বাংলা সারাংশ: প্রথম দিনের আগেই যা তৈরি: সব স্ক্রিন ব্রাউজারে যাচাই করা, সব পেজ একটা async লেয়ার দিয়ে পড়ে, প্রতিটা entity-র জন্য একটা hook, pure লজিক আলাদা ও টেস্ট করা, স্কিমা prisma validate পাস, সিকিউরিটি SQL Postgres 17-এ পরীক্ষিত। বাকি: অ্যাকাউন্ট, সিক্রেট আর ডোমেইন — এগুলো কোড না, ব্যবসার মালিকের কাজ।

2. Order of work

Each phase ends deployable. The site never has a "half on localStorage, half broken" state in production: a phase ships behind nothing but its own completeness, because until a hook is cut over, it keeps working exactly as today.

Phases 4, 6 and 7 can run in parallel between people; 0 → 1 → 2 → 3 cannot — each is the ground the next stands on.

🟢 বাংলা সারাংশ: প্রতিটা পর্ব শেষে সাইট deploy করার মতো অবস্থায় থাকে — যে hook এখনো কাটওভার হয়নি সেটা আজকের মতোই কাজ করে। ক্রম: (০) ভিত্তি — ডিপেনডেন্সি, স্কিমা, সিকিউরিটি মাইগ্রেশন; (১) পড়া — সিড করা ডাটাবেজের বিরুদ্ধে সব ২০৭ E2E পাস, কোনো পেজ না বদলে; (২) অথ — সার্ভারে যাচাই, SessionGuard মুছে ফেলা; (৩) মূল লুপ — স্ক্যান, অর্ডার, রিয়েলটাইম; (৪) মালিকের write; (৫) টাকা; (৬) প্ল্যাটফর্ম; (৭) অপারেশন; (৮) কাস্টম ডোমেইন। ০→১→২→৩ ধারাবাহিক; ৪, ৬, ৭ সমান্তরালে চলতে পারে।

3. What replaces what

3.1 localStorage keys → tables

Verification for §3.1: after phase 4/6, grep -rn '"ros-' src/hooks must list only the keys marked stays. That grep is the done-check, not a feeling.

3.2 src/lib/data → queries

The components listed at the bottom of src/lib/data/tenant.ts that still import mock-data directly are phase-1 work too: each gets its data as a prop from its page, and cart-sheet.tsx's reads move into placeOrder (it currently decides the next order number and promo validity in the browser — exactly what §15/5 forbids).

3.3 Derived values — never stored

🟢 বাংলা সারাংশ: §৩.১-এ আজকের প্রতিটা localStorage key-র পাশে লেখা আছে সেটা কোন টেবিলে যাবে, নাকি ইচ্ছাকৃতভাবে ব্রাউজারেই থাকবে। কাজ শেষের প্রমাণ একটা grep: src/hooks-এ শুধু "stays" চিহ্নিত key-গুলো থাকবে। §৩.২-এ src/lib/data-র প্রতিটা ফাংশন কোন কোয়েরি হবে, আর §৩.৩-এ UI-র যেসব সংখ্যা কখনো কলাম হিসেবে সংরক্ষিত হবে না (MRR, আজকের অর্ডার, রেটিং ইত্যাদি — সব কোয়েরিতে হিসাব হয়)।

4. Decisions and accounts the business must supply

These block phases, and none of them is a coding question.

🟢 বাংলা সারাংশ: কোড না, ব্যবসার সিদ্ধান্ত ও অ্যাকাউন্ট — এগুলো ছাড়া পর্বগুলো আটকে থাকবে: Supabase প্রজেক্ট (মুম্বাই বা সিঙ্গাপুর রিজিয়ন), Vercel ও wildcard ডোমেইন, ইমেইল সেন্ডার, SMS গেটওয়ে, bKash/Nagad/Stripe মার্চেন্ট অ্যাকাউন্ট (সময় লাগে — আগে শুরু করুন), Upstash, আসল আইনি টেক্সট, আর অতিথির ফোন নম্বর কতদিন রাখা হবে সেই সিদ্ধান্ত।

5. Seeding

prisma/seed.ts is the bridge that makes phase 1 provable: the database starts with exactly the data the E2E suite already asserts against.

• Import the mock arrays from src/lib/mock-data/* (they are plain TS — the seed reuses them rather than copying).
• Keep every mock id (tn_swadh_ghar, sg-…, ff-16, plan ids starter…). Tests, deep links and FEATURE.* constants refer to them.
• Generate what the mocks don't have: zones from the distinct zone ids (the five seeded ones get labelKey), qrToken from the mock table, one order_counters row per tenant starting above the highest mock number, staff_members.pinHash from demoPin(staffId) so the staff-login screen keeps working in staging.
• Run in one transaction per tenant under withPlatform; upsert everywhere so the seed is re-runnable.
• Never run against production: the script refuses unless DATABASE_URL's host matches the local or staging project.

🟢 বাংলা সারাংশ: সিড স্ক্রিপ্ট mock-data থেকে হুবহু একই ডেটা ডাটাবেজে বসায়, mock id অপরিবর্তিত রেখে — যাতে বর্তমান E2E টেস্টগুলো ডাটাবেজের বিরুদ্ধেও চলে। mock-এ যা নেই (zone, order counter, PIN hash) তা তৈরি করে। বারবার চালানো যায় (upsert), আর প্রোডাকশনে চলতে অস্বীকার করে।

6. Testing the backend

New E2E journeys the backend makes possible — none can be written today because they need two devices sharing state:

1. Guest phone places an order → kitchen tablet shows it, no reload.
2. Owner changes a price on the laptop → the next scan on a phone shows it.
3. Owner rotates a table's QR → the old URL is refused, the new one works.
4. Two guests submit at the same instant → consecutive order numbers.
5. Manager of tenant A cannot load any tenant B URL (404, not 403 — existence is not leaked).

🟢 বাংলা সারাংশ: বিদ্যমান ৩২২টা ইউনিট টেস্ট আর ২০৭টা E2E অপরিবর্তিত থাকবে। নতুন: mapper টেস্ট, PGlite দিয়ে service ও সিকিউরিটি টেস্ট (Docker ছাড়াই দ্রুত), আর Supabase লোকাল স্ট্যাকে ইন্টিগ্রেশন টেস্ট। ব্যাকএন্ড আসার পরেই যেসব journey লেখা সম্ভব: অতিথির অর্ডার রিলোড ছাড়া কিচেনে দেখা, দাম বদলালে পরের স্ক্যানে দেখা, পুরনো QR প্রত্যাখ্যাত হওয়া, একসাথে দুটো অর্ডারে পরপর নম্বর, আর অন্য টেন্যান্টের URL-এ 404।

7. Deliberately later

Designed-for but not in phases 0–8, so nobody builds them by accident: shared live table carts (one cart across several phones — needs a carts table and presence), offline-first POS with sync (docs/roadmap Phase 25), delivery aggregator ingest, multi-currency per tenant, AI insights. The schema leaves room for each without a breaking migration.

🟢 বাংলা সারাংশ: যা ইচ্ছাকৃতভাবে পরে: একাধিক ফোনে একটাই লাইভ টেবিল কার্ট, অফলাইন-ফার্স্ট POS, ডেলিভারি অ্যাগ্রিগেটর, টেন্যান্ট প্রতি একাধিক মুদ্রা, AI ইনসাইট। স্কিমায় এগুলোর জায়গা আছে, ভাঙা মাইগ্রেশন ছাড়াই যোগ করা যাবে।