Platform overview

What is mitabl?
mitabl is a home-cooked food marketplace platform connecting Foodies (customers) and Cooks operating virtual kitchens (miKitchens).

What products are in this repository?
The mono-repo includes a Laravel backend API and operations console, a Flutter mobile app for Foodie and Cook journeys, and a static marketing website.

What is the runtime topology at a glance?
Mobile app traffic goes to backend API routes, website pages are static marketing pages, and operations teams use the Filament admin console.

Website vs backend vs admin boundaries

Is the website transactional?
No. The website is for public marketing and legal content, while transactional operations are owned by backend APIs consumed by mobile and admin surfaces.

How does ingress split traffic?
nginx routes / to marketing-web, /api/ to backend-api, and /admin/ to ops-admin.

Where is persistence handled?
Backend is the persistence authority for platform entities; the website does not require a runtime database to render pages.

Mobile app capabilities (Foodie/Cook)

Can one app support both personas?
Yes. The Flutter app is a single binary with Foodie-facing pages and Cook-facing pages.

What can Foodies do?
Foodies can discover kitchens, browse menu items, place orders, manage cards and payments, and submit reviews.

What can Cooks do?
Cooks can manage miKitchen profiles, certificates, menu availability, and incoming order handling through role-gated routes under authenticated /api/v2 (with a small set of legacy v1 routes during migration) groups.

Support ticket lifecycle and CRM handling

How are support tickets created and updated?
Backend public routes support ticket create/read/reply with dedicated throttle middleware on intake, reads, and replies.

What is the operational lifecycle for ticket handling?
CRM SOP status progression is open -> in_progress -> pending_user -> resolved -> closed, with resolution summaries required for closure.

How are replies and internal collaboration separated?
Ops teams use public replies for requester-visible communication and internal notes for private context; internal notes are never customer-visible.

Security/privacy and ingress controls

Which ingress protections are documented?
Ingress terminates TLS and applies security headers including HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and X-XSS-Protection.

How is admin ingress protected?
/admin/ is restricted to trusted private network ranges, unsupported HTTP methods are rejected, and responses are marked Cache-Control: no-store.

How is API access separated from admin web identities?
The backend route model uses API authentication middleware for mobile routes and a dedicated web admin surface at /admin.

Account, ordering, payments (high-level)

What account actions are publicly available?
Public API capabilities include login, registration, OTP verification/resend, password reset request, and health checks.

What ordering capabilities are available after authentication?
Authenticated route groups include order creation, order details, cancellation with reason, and role-gated customer and restaurant operations.

How are payments handled at a high level?
The backend stack includes Stripe integration and customer payment/card route capabilities for marketplace checkout flows.