Use one city tour card and one featured trip card with real FareHarbor buttons while keeping /trips as the visible commercial trip hub with four clear lanes.

Do not promote featured experiences into a separate primary business root.

Keep the commercial lanes visible and easy to scan.

Use button-driven modal execution only, with no embedded grids or calendars.

Make the travel bridge behave like the Trips booking surface.

Do not collapse booking, planning, and enquiry into one generic flow.

Keep the reverse handoff visible without weakening Trips.

Treat experiences as supporting inventory and preserve the trip-to-commerce bridge.

Check the current route structure before adjusting the booking surface.

Verify the existing lane components still match the intended surface.

Keep the booking behavior consistent across the two entry surfaces.

Preserve the commercial bridge before any UI work ships.

Confirm the live route still renders and keeps the read layers separate.

Avoid moving discovery inventory into the core execution root.

Use native Molino cards, Lightframe FareHarbor buttons, a read-only page, a preserved footer bridge back to /studio, and a supporting featured-experiences lane.

Treat app/trips/actions/trips.read.actions.ts as an obsolete reference surface unless a route imports it directly. The active /trips public read chain is:

• app/trips/page.tsx
• app/trips/actions/tripsLanding.actions.ts
• app/trips/lib/mapProjectSectionsToTripsSections.ts
• app/trips/components/TripsSectionRenderer.tsx
• app/trips/actions/trips.public.read.ts
• app/trips/actions/trips.list.read.actions.ts

getTripsPublicData() supplies featuredTrips, featuredCities, featuredExperiences, and publicTrips to the existing builder renderer.

Current implementation note:

• featuredTrips and publicTrips come from Prisma Trip rows where shareForOthers is true and startDate is not in the past.
• featuredTrips also requires featured true.
• trip pricing is attached through tripEngine(mapEntityToTripInput(trip)).
• featuredExperiences comes from active Prisma Experience rows with optional City relation.
• FareHarbor execution URLs are derived from Experience.externalId when present.
• the landing project slug is andalusian-trips-lab.

• /trips/page.tsx is a read-only orchestrator that renders registry-backed sections through TripsSectionRenderer.
• getTripsLandingSections() reads the builder project with slug andalusian-trips-lab and falls back to registry defaults when needed.
• mapProjectSectionsToTripsSections() filters invisible or unknown sections and preserves registry authority.
• getTripsPublicData() is the active lane projection for featured trips, public trips, featured cities, and featured experiences.

• createTripFromPlanner() creates a private my-trips project for the user if needed, resolves or creates the trip product type, persists Trip and TripCity records, and revalidates trip routes.
• updateTripFromPlanner() checks project owner before replacing TripCity rows and updating trip metadata.
• createTripJoin() stores a pricing snapshot, total services, total per person, and total group for the join request.
• recomputeTripJoins() can refresh pricing snapshots for all joins on a trip.
• quoteTripJoin() returns pricing, mapped line items, totals, and assumptions for enquiry/quote surfaces.

• quoteTripJoin() asks for hotel totals after calling mapTripPricingToLineItems(), but that mapper currently filters hotel rows out. Treat hotel quote totals as pending until the quote mapper preserves or separately handles hotel rows.
• TripPricing exists in Prisma, but the active public list attaches live computed tripEngine output rather than reading persisted TripPricing rows.
• The final path from trip quote/join into committed LineItem -> Offer -> Order records is not fully locked in one canonical action.

Lock the trip quote/join to committed LineItem/Offer behavior: decide whether hotels remain excluded from line items or become a separate line-item group, then make the quote totals and offer commit use the same rule.

Derive the city-tour lane from active experiences and their city metadata, not from a separate booking model.

Use the public trip projection for featured and broader trip cards.

Prompt starter companion:

Audit the Trips route as shipped today. Keep the four commercial lanes and the featured-experiences lane. Preserve Trips as the execution root, keep experiences as supporting inventory, and do not move pricing or booking authority out of Trip -> LineItem -> Offer -> Order. If you update the read layer, preserve the current lane structure and replace the temporary seed data deliberately rather than accidentally.

Trips

Trips is the canonical commercial planning and public booking surface for Molino trip experiences, including featured experiences as a supporting lane.

This feature exists so users can:

• browse trips and featured experiences
• open trip detail and join flows
• start booking or enquiry actions
• understand trip timing, pricing, and availability

Inside Molino App, this feature exists to:

• preserve trip canonical data
• expose a controlled public route surface
• connect planning, pricing, and booking overlays
• keep LineItems and projection flows stable
• keep experiences visible as reusable ingredients without moving execution authority out of Trips

There is an older full backend/API scope for travel operations that should be treated as product-intent reference material, not as a separate deployment target. Its useful scope includes users, cities, trips, trip cities, plans, trip-city-plan joins, items/experiences, participant details, costs, bookings, quotes, payments, hotels, landing pages, and external booking integrations.

Molino should preserve that intent while replacing the split backend shape with the existing Next.js stack. The goal is not to keep a parallel NestJS-style backend or duplicated service layer. The goal is to absorb the useful service boundaries into app/trips, Prisma models, server actions, route handlers where needed, document projection, and the existing Trip -> LineItem -> Offer -> Order commercial chain.

The Trip is the flexible journey record. It may be public, private, cloned, edited, quoted, booked, or projected into documents. A trip can include multiple cities, dates, participants, plans, costs, sessions, hotel options, and external booking references.

Public users should see a clear travel offer. Internal users should manage the canonical operational state.

• Cities and destinations: spatial anchors such as Cordoba, Granada, Seville, Malaga, Morocco, or future destinations. Cities feed trips, plans, landing pages, public imagery, local notes, and session scheduling.
• Trips: full journey containers that can be created, edited, cloned, listed, previewed, assigned, published, and connected to city plans or schedules.
• Trip cities: ordered route structure inside a trip, including dates, nights, city purpose, and local rhythm.
• Plans: reusable itinerary blocks such as visits, guided walks, workshops, excursions, transfer days, free days, local evenings, and partner-led experiences.
• Trip city plans: the merge layer between a trip, a city, and a plan. This answers which available plans fit a city inside a specific trip.
• Items and experiences: public catalog units such as tours, sessions, workshops, partner services, or standalone bookable products. They may be published independently or surfaced along a route.
• Participant details: traveller names, party size, preferences, rooming notes, requirements, dietary needs, arrival context, and desired support level.
• Costs and estimated pricing: line-level commercial inputs for plans, services, hotels, guides, transport, margins, and optional extras. These should feed the pricing engine and downstream line items instead of being recomputed inside documents.
• Quotes: commercial offer versions generated from a trip plan. A quote can become a document, email draft, payment link, offer, or confirmation path.
• Bookings: accepted traveller intent for a trip, plan, or item. Molino should support both internal booking records and external booking references.
• Payments: gateway execution layer. Trips and quotes create payment intent; Stripe or another provider executes payment; Molino stores the external reference and status.
• Hotels: begin as structured options inside trips, plans, quotes, or line items. API search, geocoding, rate keys, and confirmations are later-stage integrations.
• Landing pages: public conversion surfaces generated from trips, cities, campaigns, featured routes, or partner offers.
• Users and profiles: travellers, admins, collaborators, sponsors, guides, or future subscribers, with ownership and access determining who can create, edit, quote, book, or view private details.
• FareHarbor and external booking: FareHarbor remains the parallel execution surface for core city sessions and standalone bookable experiences. Molino stores public CTA targets, booking modal links, external IDs, and confirmed references.

The important product pattern is the merge between trip bookings and session bookings. A single real dated session, such as a Cordoba walk or Granada visit, can accept standalone FareHarbor bookings while also belonging to a larger private or group trip.

When those streams meet in the same real session, the economics improve: independent travellers, trip participants, and local sessions can share guide time, capacity, and cultural value. This is a central revenue and viability pattern for the trips system.

• public trips page
• trip create/edit/view with persistent records
• page ID routing
• basic city and route structure
• featured trips
• featured cities
• experiences along the route
• manual or semi-structured trip planning CTA
• reusable content from older travel pages
• internal CRUD for trip records
• FareHarbor-compatible public booking links
• documentation and PRD visibility through the markdown renderer

• trip city ordering and nights
• plan blocks per city
• participant detail forms
• quote draft generation
• estimated pricing and cost line items
• trip schedule view
• trip cloning for reusable routes
• landing pages generated from trip records
• Google Doc trip proposal projection
• Sheet/Docs indexing for content and operations
• sponsor or partner-facing trip summaries
• admin workflow for reviewing and publishing trips

• Stripe checkout and invoice integration
• booking status workflows
• hotel API/search integration
• user accounts and traveller dashboards
• payment history
• calendar projection
• automated follow-up routines
• multi-party group trip matching
• advanced partner/supplier workflows
• API routes for external integrations
• subscription or sponsor-access layers

Any copied or referenced backend service shape should be translated into Molino's own Next.js architecture before production use. Do not split the codebase or deployment just to preserve the old API shape. Use the old backend as a map of domain intent, then implement the durable parts through local Prisma data, server actions, route handlers, trip engine helpers, document projection, and the commercial Trip -> LineItem -> Offer -> Order path.

• use app-native cards
• use FareHarbor booking button only
• open booking in Lightframe modal

• use app-native premium featured-trip card
• use FareHarbor booking button only
• open booking in Lightframe modal

• use in-app planner
• use quote or assisted planning
• use Molino trip-building logic

• use dedicated intake flow
• use dedicated application or request path
• do not default to a generic contact form

• routes: /trips, /trips/new, /trips/[tripId], /trips/[tripId]/edit, /trips/featured
• app folder: app/trips/
• actions: trip read, planner read/write, join create/recompute, landing read, draft creation
• types: trip.types.ts, trips.sections.types.ts, planner types
• integrations: FareHarbor-facing booking overlays, document/projection handoff, public trip API surfaces
• models: Trip, TripPricing, TripPost, PublicTrip, TripJoin, LineItem, Offer, Order
• related supporting input: featured experiences from the reusable experience catalog

• replacing the trip planner engine with a different product
• turning the public route into a generic CMS
• moving booking authority into client state

Merged the wider backend/API service scope into the active Trips PRD as a reference, while keeping the implementation rule clear: useful backend services should be translated into Molino's existing Next.js stack, not preserved as a separate NestJS-style backend or deployment. The reference now captures cities, trips, trip cities, plans, participant details, costs, quotes, bookings, payments, hotels, landing pages, users, FareHarbor, and the strategic merge between trip bookings and dated session bookings.