RestroAI Documentation
v1.0.0 Changelog

Menu Management Phase 3

Phase 3 adds tenant-local menu management for paid restaurants: nested categories, items, variants, reusable modifiers, combos, branch pricing, service-mode availability, station routing, and optional AI descriptions. It remains setup-only and does not create POS orders, KDS tickets, QR ordering, inventory deduction, reservations, or reports.

Access

Menu screens are available only after tenant login and an active paid subscription. Use /r/{tenant}/menu for the command center and /r/{tenant}/menu/studio for the Pro Studio. Subscription-blocked tenants are redirected before menu routes are reached.

Data Model

Variant-Led Pricing

Price resolution is intentionally variant-led. The order is branch variant override, branch item override, variant price, then item base price. Branch pricing also controls service-mode visibility for dine-in, takeaway, delivery, and QR.

Pro Studio

The Studio view shows a category rail, searchable item cards, animated hover states, branch and service-mode filters, price-source badges, station badges, availability badges, and quick actions for item edit, preview, and pricing. Item cards can be drag-sorted and saved through the menu reorder endpoint.

Modifiers And Combos

Add-ons are implemented as modifier groups with type=add_on; no separate add-on table is used. Modifier groups can attach to categories for inheritance or directly to items. Combo rows keep child item, optional variant, quantity, included quantity, adjustment, and routing metadata ready for future POS phases.

Station Routing

Station routing uses item override first, then category default, then unassigned. The command center shows station coverage so menu teams can find uncategorized or unrouted items before POS/KDS phases.

AI Descriptions

AI menu descriptions are disabled by default. Enable the global provider in config/menu_ai.php or env variables, then enable tenant behavior through the menu_ai.enabled tenant setting. Provider keys stay in env/config, not tenant plaintext settings. HTTP provider calls are tested with fakes.

UI Conventions

All Phase 3 screens use shared Blade components, x-ui.page-header, shared table markup, tenant CSS assets, and the existing confirm Swal, loading Swal, then appToast result pattern for mutating actions.

Phase 3+ Operations Studio

Phase 3+ deepens menu management into a full operations workflow while staying setup-only. Published menu tables remain the active source, but bulk changes, imports, and staged edits move through revisions before publishing.

Draft Review Publish

Operations changes are staged through menu_revisions. A revision can be created by a bulk action, import commit, or future editor workflow. It does not touch the published menu until it is submitted, approved, added to a publish batch, and published.

Imports And Exports

Imports support CSV, XLSX, and JSON. CSV and XLSX are designed for restaurant admin spreadsheets; JSON preserves exact nested catalog structure for migration, backups, and developer-grade round trips.

Bulk Operations

The Pro Studio bulk toolbar stages mass edits without immediately changing the live menu. Supported item actions include status changes, archive/restore, featured/taxable flags, category or station reassignment, tag replacement, price adjustments, and duplication.

Every bulk operation follows the shared UI flow: confirm Swal yes/no, loading Swal, then appToast result notification. Permission checks, tenant isolation, active subscription gating, SKU/slug handling, and plan-sensitive behavior are enforced server-side.

Quality, Media, And AI

/r/{tenant}/menu/quality runs setup-only menu QA and stores findings in menu_quality_checks. Use this before publishing a large import or bulk edit.

  1. Open /r/{tenant}/menu/operations and review catalog health, QA warnings, drafts, and publish status.
  2. Use /r/{tenant}/menu/studio/pro for visual item review, bulk staging, media checks, and branch pricing inspection.
  3. Import CSV, XLSX, or JSON if needed, then validate and commit to draft revisions.
  4. Submit revisions for review, approve the valid ones, create a publish batch, and publish.
  5. Run QA again after publishing. Use rollback only when a published batch needs to be reverted.

Verification

php artisan test
php artisan route:list --path='r/'
npm run build