Introduces modules/hospitality with 54 routes, BFF proxy, capability-gated nav, CRUD factory, and architecture validation docs. Co-authored-by: Cursor <cursoragent@cursor.com>
68 lines
3.0 KiB
Markdown
68 lines
3.0 KiB
Markdown
# Hospitality Validation Report
|
||
|
||
**Date:** 2026-07-26
|
||
**Scope:** Torbat Food frontend (`frontend/modules/hospitality`, `app/hospitality`)
|
||
|
||
## Automated checks
|
||
|
||
| Check | Command | Result |
|
||
|-------|---------|--------|
|
||
| Route scaffold | `node scripts/validate-hospitality-routes.mjs` | ✅ 54 routes, all feature files present |
|
||
| ESLint (hospitality) | `npm run lint` | ✅ No hospitality warnings |
|
||
| TypeScript (hospitality) | `npm run typecheck` | ✅ No hospitality errors |
|
||
| API client generated | `scripts/gen-hospitality-api.mjs` | ✅ All Phase 12.0–12.8 resources |
|
||
| BFF proxy | `app/api/hospitality/[...path]/route.ts` | ✅ Present |
|
||
|
||
## Architecture compliance
|
||
|
||
| Rule | Status |
|
||
|------|--------|
|
||
| Business logic in `modules/hospitality/` | ✅ |
|
||
| Thin routes in `app/hospitality/` | ✅ |
|
||
| No backend modifications | ✅ |
|
||
| No cross-module imports | ✅ |
|
||
| Shared DS only (`@/components/ds`) | ✅ |
|
||
| Real API (no mocks) | ✅ |
|
||
| Tenant header via API client | ✅ |
|
||
| Bundle feature gating | ✅ `HospitalityBundleGate` + nav filter |
|
||
|
||
## Page quality gates
|
||
|
||
| Gate | Coverage |
|
||
|------|----------|
|
||
| Loading state | ✅ `loading.tsx` per route + query loaders |
|
||
| Error state | ✅ `error.tsx` + `HospitalityPageError` |
|
||
| Empty state | ✅ DataTable + EmptyState |
|
||
| Permission state | ✅ 403 handling in page error |
|
||
| Bundle disabled | ✅ EmptyState in bundle gate |
|
||
| Search | ✅ HospitalityTablePage |
|
||
| Pagination | ✅ List page toolbar |
|
||
| Export | ✅ CSV export helper |
|
||
| Breadcrumb | ✅ HospitalityBreadcrumbs |
|
||
| Create dialog | ✅ Where API supports create |
|
||
| Delete confirm | ✅ Where API supports remove |
|
||
|
||
## API connection matrix
|
||
|
||
All list pages call `hospitalityApi.{resource}.list(tenantId)` against live backend paths under `/api/v1/*`.
|
||
|
||
Action endpoints wired in API client:
|
||
|
||
- `reservations.updateStatus`, `waitlist.updateStatus`, `kitchenTickets.updateStatus`
|
||
- `posShifts.close`, `posTickets.void`, `qrOrderingSessions.submit`
|
||
- `tenantBundles.activate/deactivate`, `featureToggles.upsert`, `analyticsSnapshots.refresh`
|
||
|
||
## Known limitations (honest)
|
||
|
||
1. **Generic create forms** — Many resources require `venue_id` / foreign keys; create dialogs use minimal fields; extend per-resource as needed.
|
||
2. **No update API** on Phase 12.1+ catalog entities — edit actions only where backend PATCH exists (venues, branches, menus, configurations).
|
||
3. **Customers / marketplace** — Mapped to connector registrations/dispatches (no native CRM customer aggregate in hospitality DB).
|
||
4. **Platform typecheck** — Pre-existing CRM resolver errors unrelated to hospitality.
|
||
5. **Runtime E2E** — Requires hospitality service running on :8009 with valid tenant JWT.
|
||
|
||
## Recommendations
|
||
|
||
1. Add resource-specific create wizards (venue picker, menu item with category).
|
||
2. Add `validate-hospitality` to CI alongside `validate:architecture`.
|
||
3. Extend ESLint boundary rules for `modules/hospitality`.
|