Who calls what

BookDirect is a property management system (hotels, shortlets, apartments are all property) built as three repos. The Next.js app talks to Core Backend (auth + some entity GETs) and Middleware Backend (availability, file-manager). Playbooks name Middleware as winner wherever that folder is live.

• Frontend — Marketplace — guest screens
• Frontend — Extranet — partner screens
• Middleware Backend — processors
• Core Backend — recommended Nellalink usage
• Search indexes — Middleware → Core list queries (city + one amenity tag)
• Amenity tick list — Frontend hard-codes slugs
• Project Management — activation matrix and ENV / Metadata Catalog index (turn a feature on)

Archived Convex/Next lives in _legacy/ and bookdirect-legacy-code.

flowchart LR
  subgraph fe [Frontend Next.js]
    GuestUI[Frontend Marketplace]
    OwnerUI[Frontend Extranet]
  end
  subgraph mw [Middleware Backend NestJS]
    Pay[payments]
    Refund[refunds]
    Mail[emails]
    Google[google-rates]
    Avail[availability]
  end
  subgraph core [Core Backend Laravel Nellalink]
    Auth[users and JWT]
    Entities[smart-meta-manager]
    Meta[meta-data]
  end
  GuestUI -->|"auth, CRUD entities"| core
  OwnerUI -->|"auth, CRUD entities"| core
  GuestUI -->|"pay, refund, email, rates, availability"| mw
  OwnerUI -->|"pay, refund, ARI, emails"| mw
  mw -->|"save or update entities"| core

Layers

Layer	Repo	Playbook
Frontend	frontend-bookdirect-user-app	Frontend — Marketplace · Frontend — Extranet
Middleware Backend	middleware-bookdirect-nestjs	Logic / Functions
Core Backend	backend-nellalink-laravel	Recommended usage
Project Management	this docs repo	Activation matrix · ENV / Metadata Catalog

Legacy reference (do not build new features here): bookdirect-legacy-code.

Routing preference

1. Only Core Backend has the operation → frontend calls Core Backend (register, login, create property in v1).
2. Middleware Backend later adds the same job (example: upload property that also pushes Google) → playbooks switch to Middleware Backend. Core Backend is what Middleware Backend calls, not what the frontend calls.
3. One winner. The old URL moves to Do not call (superseded).

That is why every iteration must re-read Core Backend explorer and Middleware Backend explorer before editing playbooks. See prompts/iterate-docs.md.

What must not happen

• Do not persist bookings or properties in Middleware Backend Mongo. The WIP branch feature/core-booking-platform-endpoints does this today — do not follow it.
• Do not add Paystack, Resend, or Google Hotel logic to Core Backend Laravel.
• Do not compute availability only in the browser. v1 winner is Middleware Backend availability/check, which reads Core Backend.

Folder map (Middleware Backend)

Enable each folder in config/routes.json and register it in src/common/loaders/feature-loader.ts.

Folder	Mount	Frontend calls it?
properties	/api/v1/nellalink/properties	Yes (winner; app may still hit Core — switch)
rates-packages	/api/v1/nellalink/rates-packages	Yes
bookings	/api/v1/nellalink/bookings	Yes
availability	/api/v1/bookdirect/availability	Yes
payments	/api/v1/bookdirect/payments	Yes
reservations	/api/v1/nellalink/reservations	Extranet
file-manager	/api/v1/nellalink/file-manager	Yes
refunds / emails / google-rates	not in routes.json	to implement