Trips Area — Detailed Module Plan for Molino Index / Al-Andalus Experience Stage Update TripsMLV1.0 20260418
- Identity and scope
The Trips area is the first-class public and commercial surface of the application.
Externally, this surface is presented as Al-Andalus Experience: • trips • city experiences • shared departures • local sessions • travel planning • partner network
Internally, it is powered by the broader Molino platform, but that platform identity stays backstage. The Trips area should therefore be documented as a self-sufficient business module with its own: • landing and conversion logic • commercial entities • planning flows • operational scheduling • offer and export flows • external booking bridges • partner/collaborator pathways
- Main mission of the Trips area
The Trips area exists to do five things well:
A. Attract
Bring the user into the right path: • plan a custom trip • join a featured/shared trip • browse cities and experiences • connect as guide / artisan / partner / collaborator
B. Compose
Allow routes and city-based experiences to be assembled into real trip products.
C. Sell
Support commercial conversion through: • estimates • offers • booking paths • shared-trip participation • external booking bridges where relevant
D. Operate
Support the real execution layer: • scheduled sessions • attendance • trip days / itineraries • rooming and hotel support • confirmations and thresholds
E. Project
Generate outputs: • trip schedules • offer documents • PDFs • email/calendar packages • later operational reports and artifacts
⸻
- High-level module structure
The Trips area should be understood as the following coordinated system:
Trips Landing / Public Front Door -> Cities / Experiences / Sessions Discovery -> Custom Trip Planner -> Featured / Shared Trips -> Trip Detail + Schedule -> Join Flow -> Offer / Booking / Payment Bridge -> Hotel Support -> External Publication / FareHarbor Mapping -> Office Automation / Exports
⸻
- Canonical domain section
4.1 Concept / content layer
This is the cognitive and delivery-support layer.
Entities • ConceptCard • CardContent • ConceptGroup • SessionStack • SessionPath • Deliverable
Purpose • define guided knowledge and narrative • support: • study • training • onboarding • scripts • posters • guidebooks • delivery assets
Rule
This layer defines how something is understood and delivered, not how it is scheduled or sold.
⸻
4.2 Experience layer
This is the reusable commercial template layer.
Entity • Experience
Purpose
A reusable commercial unit tied to a city, equivalent in role to a FareHarbor item template.
Responsibilities • what is sold • city association • base pricing model • category/type • duration • collaborator draftability • future external publication mapping
Rule
An Experience is reusable and not date-bound.
⸻
4.3 Commercial sessions / agenda layer
This is the real dated operating layer.
Entities • GroupSession • GroupSessionAttendee • CalendarEvent • AgendaNote • MapLocation
Purpose
Represent real, scheduled, capacity-bound commercial occurrences.
GroupSession role • one scheduled occurrence of an Experience • one date, place, guide, capacity window • the actual session where delivery happens
Rule
GroupSession is the atomic operational unit of the city/session system.
Trip participants and independent travellers may attend the same GroupSession.
⸻
4.4 Trips aggregation layer
This is the multi-city commercial packaging layer.
Entities • Trip • TripCity • TripCityExperience or TripCityPlan • TripDay • Offer • Order
Purpose
Represent the commercial route product: • multi-stop • packaged • priced • shared or private • exportable • joinable • externally mappable
Rule
Trips bundle and sequence Experiences and/or GroupSessions. Trips do not define session existence.
⸻
4.5 Locked one-line domain definition
ConceptCards define how it is understood, Experiences define what is sold, GroupSessions define when it happens, and Trips define how it is bundled.
⸻
- Public product surfaces inside Trips
5.1 Trips landing page
Primary entry point. Purpose: • route user intent • explain the model • show featured inventory • surface partner pathways • convert attention into planner / trip / session / partner actions
5.2 Featured/shared trips
Public catalog of joinable trips.
5.3 Custom trip planner
The private/custom commercial entrypoint.
5.4 Trip detail
Trip summary, route, experiences, booking mode, pricing framing.
5.5 Trip schedule
Day-by-day itinerary projection.
5.6 Professionals / partners page
Supply-side and network entrypoint.
5.7 Cities and experiences discovery
City hubs and reusable product units.
⸻
- Trips landing page — section architecture
Recommended canonical sections: 1. trip_hero 2. trip_pathways 3. trip_how_it_works 4. trip_featured_group_trips 5. trip_featured_cities 6. trip_featured_experiences 7. trip_plan_your_trip 8. trip_for_partners 9. trip_updates 10. trip_final_cta
6.1 trip_hero
Purpose: • immediate positioning • main CTA triad
Main CTAs: • Plan Your Trip • Join Featured Trips • For Guides & Partners
6.2 trip_pathways
Purpose: Route users by intent: • custom/private traveller • shared trip traveller • guide/artisan/partner • later optional city experiences browser
6.3 trip_how_it_works
Purpose: Explain the city-rhythm/shared-session model in simple terms.
6.4 trip_featured_group_trips
Purpose: Show real joinable inventory.
6.5 trip_featured_cities
Purpose: Introduce cities as hubs of rhythm, experience, and narrative.
6.6 trip_featured_experiences
Purpose: Show reusable commercial units and trip ingredients.
6.7 trip_plan_your_trip
Purpose: Drive the strongest private-trip conversion.
6.8 trip_for_partners
Purpose: Invite guides, artisans, collaborators, and local partners into the system.
6.9 trip_updates
Purpose: Keep the system current and alive.
6.10 trip_final_cta
Purpose: Close with the same core pathways.
⸻
- Core CTA routing map
CTA — Plan Your Trip
Route
/trips/new
Purpose
Custom/private trip creation.
Backend/interface requirements • canonical cities selector • route-stop composer • price estimation • save Trip + TripCities • generate TripDays
⸻
CTA — Join Featured Trips
Route
/trips/featured
Purpose
Browse shared/joinable trips.
Backend/interface requirements • public trip cards • trip booking mode resolution • route summary • joinability information
⸻
CTA — View Trip
Route
/trips/[tripId]
Purpose
Inspect one trip product.
Backend/interface requirements • trip aggregate • route stops • selected experiences/sessions • commercial framing • export/offer options later
⸻
CTA — View Schedule
Route
/trips/[tripId]/schedule
Purpose
Day-by-day projection of the trip.
Backend/interface requirements • TripDays generation • city descriptions • attached experiences or featured plans • hotel support hooks later
⸻
CTA — Explore City
Route
/cities/[slug]
Purpose
City-level narrative and inventory discovery.
Backend/interface requirements • city narrative • featured experiences • later session agenda • later planner prefill shortcuts
⸻
CTA — Browse Experiences
Route
/experiences
Purpose
Explore reusable city-linked commercial units.
⸻
CTA — For Guides & Partners
Route
/trips/professionals
Purpose
Supply-side onboarding and collaboration route.
⸻
- Canonical flows
8.1 Public discovery flow
Landing → choose path → reach planner, featured trips, cities, experiences, or partner page
8.2 Custom trip flow
Landing → /trips/new → define trip basics → add trip cities → configure services → save trip → view trip detail → schedule → later offer/export
8.3 Shared/public trip flow
Landing → /trips/featured → trip detail → schedule → join / inquire / book externally
8.4 Join flow
User selects shared trip → enters participant and rooming preferences → quote/repricing logic runs → join record created → later booking/payment/confirmation
8.5 Partner/collaborator flow
Landing → partners page → later contribute or draft Experiences → future review/approval/publishing pipeline
⸻
- Trips planning and authoring surfaces
There are two valid authoring surfaces.
9.1 Standalone planner surface
Route: • /trips/new • later /trips/planner/[draftId]
Purpose: • create/save actual trip entities • support public/private trip creation workflows
9.2 Virtual Document Instrument surface
Purpose: • internal planning • proposal generation • AI-assisted composition • document-native trip planning • export companion
Rule
The document instrument is a valid companion or authoring surface, but the Trips planner must work independently of it.
Document generation/export is optional, not mandatory.
⸻
- Trips planner specification
10.1 Replace the generic form
The generic Zod-based CRUD form is not the correct main UX for Trips.
/trips/new must become the real custom trip planner.
10.2 Planner MLV inputs
Trip header • title • startDate • numPax • hotelStandard • numDoubleRooms • numSingleRooms • later share/public mode • later targetParticipants
Per stop (TripCity) • cityId • cityName display • nights • intercityTransportCode • cityTransportCode • choiceGuide • choiceTours • later selected experiences
10.3 UX model
The planner is a route-stop composer: • add city • remove city • focus/edit one stop • live estimate preview • save
10.4 Immediate dependencies • minimum Cities module • Trip creation action • TripCity creation • estimate helper • TripDays generation helper
⸻
- Cities, Experiences, and TripCityExperience
11.1 Cities
Canonical truth for place identity.
Minimum early requirements: • id • name • slug • descriptions • main image • narrative fields used by TripDays
11.2 Experiences
Current Molino working surface for what older versions called city plans.
Role • reusable commercial unit • city-linked • trip ingredient • future FareHarbor item candidate • collaborator/partner draftable
Important note
For current Molino phase: • CityPlan can be understood conceptually • Experience is the implementation surface
11.3 TripCityExperience
Attachment between a trip stop and selected experiences.
Role • which Experiences are included in which city stop • allows trips to bundle city-linked products meaningfully
⸻
- TripDays
TripDays should be generated early.
Purpose
A shared projection for: • public schedules • exports • documents • later hotel support
Generation inputs • Trip • TripCities • city narrative fields • selected TripCityExperiences or featured city experiences fallback
Rule
TripDays can begin as generated view models before becoming any persisted read model if needed.
⸻
- Pricing and estimation
Explicit pricing buckets
Preserve these: • intercity transport • city transport • guide/support • tours • ground services total • hotel estimate • single supplement • total per traveller • total group
Shared-trip repricing
Preserve optional strategy: • price shifts as more people join • shared group economics improve • same session, different participation mode
This is a real commercial feature, not a side note.
⸻
- Hotels within Trips
Hotels are not the core product truth, but are a first-class support subsystem.
Early support • hotel standards • room counts • estimates
Intermediate support • external booking links • per-city booking support
Later support • bed requirements • block/release/confirm lifecycle • hotel API booking module
Rule
Trips core remains about route, sessions, experiences, guidance, and commercial packaging. Hotels support those flows without becoming the main authority.
⸻
- Booking, offers, and orders
Trips owns • trip composition • route structure • estimate • publication/share state
Offers own • commercial proposal state • pre-confirmation quote packaging
Orders own • confirmed transactional state
Payments own • Stripe / checkout / payment lifecycle
Rule
Offers and Orders are first-class commercial layers and must remain distinct from trip truth.
⸻
- FareHarbor and external channels
FareHarbor is an external publication/distribution surface, not internal truth.
Experiences
map most naturally to FareHarbor Items.
GroupSessions
can be the real scheduled agenda layer that external channels reflect or consume later.
Trips
can be: • public bundles • marketing-visible routes • externally linked where appropriate • internally quoted where appropriate
Rule
Do not let FareHarbor define internal model boundaries.
⸻
- Office automation / AppScript role for Trips
AppScript should remain a stateless external execution layer.
Good trip-related uses • export trip offer doc • export trip pdf • send trip email package • create trip calendar event • log exports • share generated docs
Rule
Molino computes payloads. AppScript renders/sends/logs.
⸻
- Roles and capability interpretation inside Trips
Platform roles still govern authority • admin • operator • editor • member • guest
Travel/commercial profiles active in Trips • traveller • organiser • provider • collaborator • partner
Trips-specific interpretation
Traveller • browse trips • join trips • see own schedules/bookings later
Organiser • create trips • configure routes • build offers • export docs • manage schedules
Provider • respond to requests • support services and supply-side operations
Collaborator • draft experiences • contribute content or local product supply • support documentation and onboarding
Partner • broader network role • affiliate, guide, artisan, local operator
Rule
Role controls authority. Profile controls workflow surface. Capability controls visible tools and actions.
⸻
- Main implementation order for Trips area
Phase 1
Trips landing + CTA routing
Phase 2
Cities minimum authority
Phase 3
Replace /trips/new with real trip planner
Phase 4
Persist Trip + TripCities
Phase 5
Generate TripDays and ship /trips/[tripId]/schedule
Phase 6
Experiences as current CityPlan surface
Phase 7
TripCityExperience attachments
Phase 8
Featured/shared trips and join flow
Phase 9
Offer builder bridge
Phase 10
Booking/payment continuation
Phase 11
FareHarbor/manual channel bridge
Phase 12
Hotel support improvements
Phase 13
Office automation exports
⸻
- Non-negotiable rules for Trips area • no Prisma outside actions • no mutation in pages • no API routes for internal plumbing • no FareHarbor-first architecture • no hotel-first architecture • no confusing SessionCards with GroupSessions • no confusing Experiences with GroupSessions • no confusing Virtual Documents with Google Docs • no business logic in Apps Script • compute in app, project externally
⸻
- Final one-line definition of the Trips area
The Trips area is the public and commercial Al-Andalus Experience surface of Molino Index, where cities, experiences, sessions, routes, offers, and exports are composed into sellable travel products and real operational journeys.
If you want, the next step is for me to turn this into a tighter trips.md style spec with markdown headings only, ready to paste directly into your main documentation.
- Historical Notes Reconciled and Confirmed by Current Implementation
The older trips, document, and asset-planning notes remain broadly valid and now resolve into a clearer canonical structure for TripsMLV1.0.
22.1 Trips are semantic authorities with multiple projections
A Trip is not only a route container or booking shell. It is the semantic authority from which multiple downstream projections can be generated: • TripDays / schedule • pricing rows • transferable line items • offers • booking and payment payloads • later PDFs, posters, postcards, itinerary sheets, and agent briefs
Rule
Trip truth remains route composition, service intent, and packaging logic. Commercial, booking, and editorial outputs are projections.
⸻
22.2 Pricing convergence is now a real implementation goal
Older versions already contained partial pricing logic across: • legacy frontend forms • NestJS backend • spreadsheets / Apps Script style reasoning • document-side draft structures
These are now converging into one canonical pricing path:22. Historical Notes Reconciled and Confirmed by Current Implementation
The older trips, document, and asset-planning notes remain broadly valid and now resolve into a clearer canonical structure for TripsMLV1.0.
22.1 Trips are semantic authorities with multiple projections
A Trip is not only a route container or booking shell. It is the semantic authority from which multiple downstream projections can be generated: • TripDays / schedule • pricing rows • transferable line items • offers • booking and payment payloads • later PDFs, posters, postcards, itinerary sheets, and agent briefs
Rule
Trip truth remains route composition, service intent, and packaging logic. Commercial, booking, and editorial outputs are projections.
⸻
22.2 Pricing convergence is now a real implementation goal
Older versions already contained partial pricing logic across: • legacy frontend forms • NestJS backend • spreadsheets / Apps Script style reasoning • document-side draft structures
These are now converging into one canonical pricing path:
TripInput -> tripEngine -> TripPricingOutput -> LineItems Rule
No downstream entity should manually recompute trip pricing once canonical trip pricing rows and line items exist.
⸻
22.3 Canonical pricing buckets remain locked
The historical pricing structure remains valid and should be preserved as explicit buckets: • intercity transport • city transport • guide/support • tours • hotel estimate or hotel inclusion • single room supplement • total per traveller • total group
Rule
These buckets are not presentation-only. They are the commercial breakdown layer that must remain portable into offers, orders, bookings, payments, and exports.
⸻
22.4 Line items are the commercial transfer surface
Older notes around offers, quote packaging, and downstream booking logic now resolve more clearly:
Trip pricing must be transferable as canonical line items.
That means: • Trip computes pricing • pricing rows map into line items • line items can be attached to Offer • later copied or projected into Order / Booking / Payment flows • no manual rewriting of the same commercial data downstream
Rule
LineItems are the transferable commercial backbone between Trips and the rest of the commercial system.
⸻
22.5 Trips remain independent of the Document Instrument
Older notes explored document-native trip creation and trip planning from the document system. That remains valid as a companion authoring surface, but it is no longer the required primary route.
Current rule: • the standalone planner must independently create and persist real Trip entities • the Document Instrument may later author, mirror, export, or assist with trip semantics • document generation/export is optional, not required for trip existence
Rule
Trips must work independently of the document route, even if document-native planning remains a valid companion workflow.
⸻
22.6 External channels remain projections, not truth
Older notes correctly framed booking systems and external channels as non-authoritative projections.
This remains locked for: • FareHarbor • booking widgets • hotel links • manual supplier arrangements • partner / affiliate channels
Rule
External channels may consume, reflect, or publish trip outputs, but they must not define internal model boundaries or internal truth.
⸻
22.7 Trips are compatible with the broader asset-family logic
Older “Document Instrument → Asset Pipeline” notes remain strategically relevant.
Trips may later emit an asset family including: • trip schedules • itinerary PDFs • offer documents • posters • postcards • agent briefs • onboarding or participant packs
Rule
These outputs are derived assets and must not introduce new semantic authority.
⸻
22.8 Experiences remain the reusable unit; Trips remain the bundle
Older “city plan” logic is now better understood through the current model.
Current reconciliation: • Experiences are reusable city-linked commercial units • GroupSessions are real dated operating occurrences • Trips are multi-stop commercial bundles • TripCityExperience is the attachment layer between stop and reusable unit
Rule
Trips aggregate and sequence reusable units. They do not replace the reusable unit layer.
⸻
22.9 TripDays are confirmed as an early generated projection
Older schedule notes and prior FE itinerary pages confirm that TripDays should exist early, even before a fully persisted read model is required.
TripDays currently serve: • public schedule rendering • route explanation • commercial framing • export readiness • later booking and hotel support surfaces
Rule
TripDays may begin as generated view models and only become persisted if operational needs justify it.
⸻
22.10 Hotel logic remains a support subsystem, not the main authority
Earlier notes and current engine work both confirm the same principle:
Hotels are a first-class support subsystem, but not the semantic core of Trips.
Current hotel modes should remain structurally possible: • included • excluded • estimate_only
This supports: • service-only trip pricing • hotel-estimate trip pricing • later manual or external hotel booking flows • later assisted hotel support links or widgets
Rule
Hotel logic must remain pluggable and optional without destabilising trip truth.
⸻
22.11 Shared trip repricing remains a real feature
The older public-trip logic and current planning both support the same commercial idea: • prices can improve as more participants join • group economics affect the per-traveller outcome • one trip may have both route truth and dynamic participation economics
Rule
Shared-trip repricing is not a side note or marketing flourish. It is a real commercial behavior that should remain compatible with canonical pricing and line-item projections.
⸻
22.12 Standalone planner first, richer planner later
The older notes about step-based forms, stop editing, live preview, and document-side orchestration now reconcile as follows:
Current minimum truth: • standalone route-stop planner • live estimate preview • Trip + TripCities persistence • TripDays projection • Trip detail and schedule rendering
Later enrichment: • richer stop editing UX • sidebar orchestrator patterns • per-stop experiences • join flow refinement • export and offer continuation
Rule
The current planner must be sufficient as an independent commercial entrypoint before further orchestration features are layered in.
⸻
22.13 Current canonical technical direction
The following technical direction is now explicitly confirmed:
Trip planner input -> canonical TripInput mapping -> tripEngine -> TripPricingOutput -> line-item projection -> Trip detail / schedule / offer bridge / booking continuation Supporting generated projections: • TripDays for schedule • line items for commerce • later documents and exports for external use
Rule
Trips now sit at the intersection of semantic truth, commercial projection, and public presentation, but must keep those layers distinct.
⸻
22.14 Updated implementation interpretation from historical notes
The old notes were not discarded; they now resolve into these confirmed positions: • Trips are semantic entities, not just booking records • pricing must converge into one engine • line items are the transferable commercial surface • external booking channels are projections, not truth • the document instrument is a companion route, not the only route • asset-family outputs are a later extension, not the immediate core
⸻
22.15 Updated next-phase refinement
Historical notes suggest a slightly clearer near-term sequence after current MLV progress: • Offer builder bridge from canonical trip line items • booking / payment continuation using canonical pricing outputs • hotel mode improvement and optionality • TripCityExperience integration into engine input • channel / rate profile overlays • exports and asset-family outputs
Rule
Each next phase should consume canonical trip truth and canonical pricing outputs, not rebuild them separately.