• Stepper shape existed explicitly:
  • register/login
  • trip basics
  • city selection
• Trip basics included:
  • trip name
  • start date
  • expected participants
  • public/open-for-others toggle
  • featured toggle
  • hotel standard
  • double rooms
  • single rooms
  • main image
• Public/shared trip flow added:
  • target participants
  • estimated price per participant
• Admin/private edit flows also exposed:
  • minimum participants for public trips
  • featured/public controls
  • main image editing
• City rows carried more execution detail than the current planner surface:
  • city name
  • nights
  • local guide choice
  • tours choice
  • meals choice
  • package type
  • intercity transport
  • city transport
  • attached plan ids

• Public/shared trip authoring still needs a clearer current equivalent for:
  • target participants
  • public joinability thresholds
  • explicit per-person estimate preview
• City stop editing still lacks first-class current UI for:
  • transport mode selection
  • guide/tours/meals toggles
  • package type framing
• Provider quote input existed per city through TripCityQuoteForm:
  • accommodation
  • city transport
  • intercity transport
  • travel guide This is still relevant to later quote, supplier, or booking-bundle workflows.

• /cities was simple but useful:
  • published city listing only
• /cities/[name] carried a stronger city-detail pattern than the current Trips city page:
  • hero/banner image
  • longer editorial city narrative
  • multi-part description/content blocks
  • owner/admin edit path
  • embedded list of available local plans
  • bottom bridge back into broader city discovery

Current Molino already has:

• /trips/cities
• /trips/cities/[citySlug]

But the current implementation is still lighter than legacy:

• list page is present and clean
• detail page is present but mostly summary + local-plan links
• missing richer city story, image-led detail, and deeper city-to-plans presentation

• Trips landing components were visually tuned toward the locked Spaces/editorial baseline without changing global tokens.
• Image integration was improved across core landing sections with clearer aspect ratios, lighter card surfaces, and less cramped spacing.
• Featured experiences and plans now use a more Pinterest-like masonry rhythm for browsing, while featured trips and cities remain more structured and route-led.
• Weekly sessions and collaboration surfaces were brightened and given more breathing room so the page stays luminous rather than heavy or overly dark.
• The editorial features card row now acts as the first local candidate for a reusable Spaces-guided poster-card standard: contained images, varied aspect ratios, light surfaces, restrained borders/shadows, and a less square browsing rhythm.

• pages/featured was effectively a marketing/magazine/landing-page system backed by item-like lander payloads:
  • hero section
  • repeated sections with subtitle/title/description/image/cta/style
  • footer CTA
  • social links
• This was closer to a curated landing-builder than to canonical trip/product truth.

• Treat legacy featured as a reference for:
  • curated magazine-like campaign pages
  • item-driven landing content
  • reusable hero/section/footer structures
• Do not treat it as trip execution truth.
• Best current home is alongside:
  • Trips builder-backed marketing sections
  • /md or editorial surfaces
  • future curated campaign or feature pages

• /plans was a public list of published local plans plus a feature CTA.
• /plans/[id] combined several important commercial behaviors:
  • plan hero/detail narrative
  • choose date
  • set participant count
  • calculate per-person and group price view
  • standalone booking action
  • add to existing trip
  • create a new trip from the plan
  • city-context bridge

• In Molino, this maps mostly to Experience as the supporting inventory/entity.
• Keep the conceptual bridge:
  • experience/plan as standalone bookable or requestable unit
  • experience/plan as ingredient inside a Trip
• FareHarbor item shape should be treated as a projection/integration shape:
  • not canonical truth
  • but important enough to model explicitly in adapters/types

• pages/pro/collaborators.tsx and pages/pro/organisers.tsx were long-form partner/network landing pages.
• They covered:
  • local experts
  • organisers
  • guides
  • workshops
  • B2B/private groups
  • API/distribution language
  • collaboration/network positioning

• Best current home is /trips/network.
• Use as reference for the second narrative lane:
  • traveller/group organiser
  • local expert/provider/travel professional
• Preserve the provider/pro narrative without mixing it into the public trip-planning flow.

1. Enrich the current Trips planner/edit surface with the missing legacy stop/service fields, but keep TripPlannerContext and normalized stops as the authority.
2. Deepen /trips/cities/[citySlug] so it reads more like a real city landing with plans, not just a summary card wall.
3. Deepen /trips/plans/[planSlug] and Experience detail so standalone booking, add-to-trip, and trip-creation bridges are explicit again.
4. Use legacy pro and featured mostly as narrative/content references for /trips/network, builder sections, and curated campaign/editorial pages rather than as execution models.

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/TripsLandingSections.tsx
• app/trips/actions/trips.read.actions.ts
• app/trips/actions/trips.list.read.actions.ts

/trips/page.tsx supplies featuredTrips, featuredCities, and featuredExperiences to the direct landing stack while section content still comes from the andalusian-trips-lab builder project.

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 server orchestrator that fetches builder-backed section content and public projection data, then renders the direct TripsLandingSections stack.
• 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.

The older reference at https://latest-aelib.vercel.app/ establishes the target landing cadence:

• compact menu and immediate Al-Andalus brand signal
• stacked primary CTAs for daytime plans, private trip design, featured group trips, professional entry, and local network entry
• welcome section, then Travel / Learn / Experience pillars
• audience sections for travellers, local experts, and trip organisers
• group trip narrative, plan-your-trip section, featured cities, and update/news style content

Local /trips already carries the stronger framework base:

• builder-backed section content rendered through the direct TripsLandingSections stack
• public trip, featured city, and featured experience projection
• planner route at /trips/new with assistant-supported form completion
• FareHarbor-style execution links kept separate from trip truth
• detail page and edit page routes at /trips/[tripId] and /trips/[tripId]/edit

Trip edit mode now follows the owner/admin rule:

• owners can edit their own trip records
• admin can edit any trip
• non-owners cannot bootstrap the edit form or persist updates

Admin is currently resolved through ADMIN role or zaruqsummers@gmail.com.

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

• Added a small arrival/start-points binder near the top of /trips, before the broader “Choose how you want to begin” lane section.
• This binder now lives inside the Trips section registry/flow rather than outside the page architecture.
• This binder frames practical arrival logic first:
  • Madrid arrival and welcome-service connection
  • Malaga / Seville gateway connection
  • direct Cordoba start
• Purpose: make the trip lane feel more operational and route-aware before the user reaches the wider commercial lane chooser.
• The following lane section was also tightened so it reads less like a duplicate of the arrival binder and more like the actual commercial choice layer: booking a day plan, joining a group trip, planning a private route, or opening a partner path.

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.